1

Is there ever a benefit to preceding a path with ./ (dot slash)?

In most cases, cd ./home is equivalent to cd home (and also cd ./././././home). Is there ever a case where these two paths would NOT evaluate to the same path? Is there some benefit or drawback to either having or NOT having ./ at the beginning of a folder or file path?

What if from inside a program or script, I wanted open a config file, i'm hard coding a file to open, should it be:

resource/config.txt

OR

./resource/config.txt

Does POSIX (or common Unix implementations) give any semantic difference between opening these two paths?

kevlarjacket
  • 407
  • For arbitrary commands, there is a definite benefit to using a ./ prefix. Filenames that start with - is the most obvious case, but there are others. – Wildcard Dec 14 '16 at 21:38
  • 1
    This simply isn't a duplicate of the other question and it never was. – Michael Homer Dec 15 '16 at 04:49
  • That said, it's now been edited into more of a programming question than it started and might be endangered from that direction, so I've edited a sentence on the end to make it asking explicitly about "UNIX C API and System Interfaces" so that it's clearly on-topic. – Michael Homer Dec 15 '16 at 04:54
  • ... although the specific case might be better as a new question, to avoid invalidating the existing answers to the broader question, and the original should just be reopened as it was. – Michael Homer Dec 15 '16 at 04:54

3 Answers3

4

There are at least two reasons to do ./something.

  1. You have a program that you want to run. It's inconveniently named something like "test" or "cat" or "ps". Ordinarily, shells look up program names in directories in the PATHenvironment variable. To execute your test, you have to type ./test, otherwise /usr/bin/test or some such will execute. That can be very confusing.

  2. You don't have . in your PATH environment variable because you don't want to accidentally execute a program while you are poking around the file system. Really awful people could leave a script ls in some directory. The file ls could contain rm -rf $HOME. If your PATH has "." in the right place, the awful person might be able to trick you into deleting everything in your home directory. You can certainly put "." as the last entry in PATH, but it's possible to devise circumstances where "." in PATH causes problems. So, to run a program whose executable resides in the current working directory, you have to prefix its file name with "./".

  • I never really understood why the ./ was necessary for files that got executed until I read this - its actually quite simple. The ./ is necessary whenever an include path is involved. i.e. it becomes necessary to resolve ambiguities arising from files of the same name existing on the include path as well as the current working directory, nice. – the_velour_fog Dec 14 '16 at 22:38
  • 1
    I agree with both reasons, but to elaborate on the first reason, the bash shell looks for programs to execute in the following order: aliases, functions, builtins, and lastly directories in PATH. (cf. man bash). – twan163 Dec 14 '16 at 23:13
3

./ is indeed always the current working directory. However, it is (for good reason) generally not added to the PATH. This means that if you have a script or binary in your current working directory that you want to run, you need to use ./script.sh rather than script.sh for it to run.

DopeGhoti
  • 76,081
2
vagrant@host:~$ pwd
/home/vagrant
vagrant@host:~$ mkdir foobar
vagrant@host:~$ mkdir foobar/~
vagrant@host:~$ cd foobar
vagrant@host:~/foobar$ cd ./~
vagrant@host:~/foobar/~$ pwd
/home/vagrant/foobar/~
vagrant@host:~/foobar/~$ cd ~
vagrant@host:~$ pwd
/home/vagrant
vagrant@host:~$ cd foobar
vagrant@host:~/foobar$ cd ~
vagrant@host:~$ pwd
/home/vagrant
vagrant@host:~$

As @DopeGhoti @Wildcard and others have indicated, sometimes it is handy to be very specific about what directory you are in and what your target is. The ./ and ../ constructs provide that.

StandardEyre
  • 511