Is the "./" statement just a throwback?

theKbStockpiler · 03-05-2011, 10:28 PM

If I'm in a directory and I want to move into the next directory I just type it in raw without the relative ./ All I use is cd "next directory" enter. So my point is that I can not find a purpose for the "./" statement other than to state it on paper ;or the like as , ./directory/directory (from whatever current directory) I was in. Is the "./" statement for an older version of BASH?

Is this correct? Thanks in advance!

frankbell · 03-05-2011, 10:48 PM

Oddly enough, I was just reading about this today.

If this is the file structure

Code:

dir1
----subdir1
----subdir2
--------subdir2sub1
--------subdir2sub2

and I'm in dir1

it has always been the case that I could move from dir1 to subdir1 by typing

Code:

cd subdir1

Where I think ./ really comes into play is when I want to manipulate a file.

Instead of typing

Code:

vi /complete-path-to/filename

or

Code:

cp /complete-path-to/filename /complete-path-to-subdirectory/filename

I can type

Code:

vi ./filename

or

Code:

cp ./filename ./path-to-some-subdirectory/filename

Does this make sense?

jschiwal · 03-05-2011, 10:53 PM

You will need to use "./" to precede a program you want to run in the current directory. "./" isn't a statement. You are simply giving the current directory "." at the start. Both ways end up having the same meaning, that's all.

Telengard · 03-05-2011, 11:33 PM

To expand just a little bit on jschiwal's point, consider the following.

One Unix tradition is to add "." to $PATH so that shell scripts may be run from the current working directory. On all the Ubuntu systems I have used "." is not in $PATH by default. So when I want to run a shell script from the current working directory I cannot just write

Code:

$ myscript

Instead I must write

Code:

$ ./myscript

theKbStockpiler · 03-05-2011, 11:39 PM

I refered to it "./" as a statement because I did'nt know what else to call it."Piece of garbage with no explanation". I Still can't find a use for it. Apparently I understand the description as well as anyone else but If BASH is in a directory It is redundant to use it because it will change from that directory to the next without using it.

cd /home/kbs -while in home is the same as

cd kbs

"kbs@localhost ~]$ cd /home/kbs
[kbs@localhost ~]$ pwd
/home/kbs
[kbs@localhost ~]$ cd Documents
[kbs@localhost Documents]$ pwd
/home/kbs/Documents
[kbs@localhost Documents]$"

If not in home (or the known beginning of the directory) than you can't use a relative path so what is the point? Bash knows where it is without the "./" it would seem.

MrCode · 03-05-2011, 11:41 PM

@Telengard

I think what you're talking about is applicable to just about any Linux/UNIX-like system, not just Ubuntu...I can't think of any instance where I've been able to run an executable in the current working directory (be it a shell script/binary/whatever) just by providing its filename alone; I've always had to precede it with the "./" shortcut for "current directory".

EDIT:

Quote:

cd /home/kbs -while in home is the same as

cd /kbs

Actually, no, these aren't equivalent, even if you're already in /home. There is a shortcut for /home/$(whoami), though: you might already know it as "~".

"cd /kbs" will make bash attempt to switch to a directory called "kbs" from the root of the filesystem.

AFAIK the way running executables without providing their full path or "./" works is that bash checks for the existence of the file in the director(y|ies) pointed to by $PATH, and if it's not there, it gives a "command not found" (or in some cases, "<executable>: No such file or directory") error.

To anyone who knows better: feel free to correct me.

ntubski · 03-05-2011, 11:50 PM

Quote:

Originally Posted by frankbell

Instead of typing

Code:

vi /complete-path-to/filename

or

Code:

cp /complete-path-to/filename /complete-path-to-subdirectory/filename

I can type

Code:

vi ./filename

or

Code:

cp ./filename ./path-to-some-subdirectory/filename

You could just as well do

Code:

vi filename

or

Code:

cp filename path-to-some-subdirectory/filename

Any command which takes a path will probably accept a relative path, which effectively means there is an implicit "./" prepended to the path by default. Using "./" just makes it explicit. Note that this is a feature of open(2) system call, so it is not a bash thing, but a Linux thing.

Telengard · 03-05-2011, 11:51 PM

Quote:

Originally Posted by MrCode

@Telengard
I think what you're talking about is applicable to just about any Linux/UNIX-like system, not just Ubuntu...

I'm informed by a couple of sources. My primary source is my own experiences on Debian, Ubuntu, Slackware, Red Hat, and Fedora. Not all of those systems were mine to administer, so I don't know whether the admin changed the default settings or not. The Red Hat system in particular used some variant of traditional sh, and not Bash.

My other source of information is The UNIX Programming Environment by Kernighan and Pike. They mention adding "." to $PATH for convenience early in the book. It is a fine read by the way. Even though some of the examples are steeped in archaic Unix-isms, Linux CLI newbies can learn a great deal from it.

MrCode · 03-05-2011, 11:55 PM

Quote:

I'm informed by a couple of sources. My primary source is my own experiences on Debian, Ubuntu, Slackware, Red Hat, and Fedora. Not all of those systems were mine to administer, so I don't know whether the admin changed the default settings or not. The Red Hat system in particular used some variant of traditional sh, and not Bash.

I was just talking about WRT the whole "./" syntax, not necessarily adding "." to $PATH, but thanks for the info anyway.

EDIT: One interesting idiosyncrasy(?) that I've noticed is that one can directly execute a binary/shell script that exists within a subdirectory of the CWD by referring to it relative to the current working directory (i.e. without having to use "./"). For example, if one has a script in /home/joe/Scripts/something.sh, and the're currently in /home/joe, they can simply execute the script like this:

Code:

$ Scripts/something.sh

theKbStockpiler · 03-06-2011, 12:02 AM

One of the guides I'm referencing is http://www.linux-tutorial.info/modul...tent&pageid=17

They really don't include enough info to grasp it. I remember ./configure and know it won't work without it but I think it is NOT completely part of the same thing. It is still part of the purpose of this thread. If you don't want to permanently modify the search path you have to include the "./" . If you modify it you don't have to include the "./" . It's just like opening up gedit in bash without typing "./" before it I think. A lot of these guides and tutorials heavily borrow from other guides and tutorials and I think some stuff gets outdated and no one gives it any mind. Java is not working. Imagine an emotioncon of your choice "here".

Telengard · 03-06-2011, 12:04 AM

Quote:

Originally Posted by ntubski

Any command which takes a path will probably accept a relative path, which effectively means there is an implicit "./" prepended to the path by default. Using "./" just makes it explicit. Note that this is a feature of open(2) system call, so it is not a bash thing, but a Linux thing.

And that pretty much explains it

ntubski · 03-06-2011, 08:02 AM

Quote:

Originally Posted by MrCode

EDIT: One interesting idiosyncrasy(?) that I've noticed is that one can directly execute a binary/shell script that exists within a subdirectory of the CWD by referring to it relative to the current working directory (i.e. without having to use "./"). For example, if one has a script in /home/joe/Scripts/something.sh, and the're currently in /home/joe, they can simply execute the script like this:

Code:

$ Scripts/something.sh

Yes, there is nothing special about "./", it's just a way to specify a file current in the current directory using a slash:

Quote:

If the name is neither a shell function nor a builtin, and contains no slashes, Bash searches each element of $PATH for a directory containing an executable file by that name.

Command Search and Execution

Quote:

Originally Posted by theKbStockpiler

One of the guides I'm referencing is http://www.linux-tutorial.info/modul...tent&pageid=17

That explains things pretty well, except that it has one incorrect statement:

Quote:

When you input the path yourself (either a command or a file) The shell interprets each component of a pathname before passing it to the appropriate command.

There is no expansion of pathname components by the shell, as I said before this is a feature of the open() system call (and other calls that take paths), not bash. See path_resolution(2)

frankbell · 03-07-2011, 07:22 PM

Thank you all for the fascinating discussion. I've learned a lot.

Telengard · 03-11-2011, 10:13 PM

I found an example where ./ is used effectively to prevent problems with expansion of filenames which may begin with -.

http://mywiki.wooledge.org/BashPitfa...leading_dashes

I tried this in Konsole.

Code:

foo$ echo foo > -bar
foo$ ls
-bar
foo$ rm -bar
rm: invalid option -- b
Try `rm ./-bar' to remove the file `-bar'.
Try `rm --help' for more information.
foo$ rm ./-bar
foo$

rkelsen · 03-12-2011, 04:01 AM

If you use the CLI long enough, you will find the need for absolute addressing.