Relative pathname for executable file


I’m teaching myself Fortran and I compiled my first program. When I went to run the file at the command line I changed to the directory of the file and entered the filename and nothing happened.
After searching a bit I found I had to enter


and not just


My question is, what is the significance of using ./ as I thought it just meant the path was relative?
Is just entering the filename of an executable file not valid, even though you’re in the directory of the target file?


To be able to run a program without the ./, the program must exist in your path. By default, the current working directory is not in the path. You can check your path by doing (in a terminal)

echo $PATH

. If you would like to make it so that your current directory is in your path, you can add the following to the .bashrc file in your home directory (note that the dot in the filename makes it hidden)

export PATH=$PATH:.

Note the :. , that is the part that adds to your path.

This practice is however not considered to be harmless. Especialy do not add **. **(current directory) to your PATH in the case of root!

Think of *root *standing somewhere in a directory being owned by ‘some user’ (*root *can go everywhere can’t she/he?). And this ‘some user’ has an executable called ls there. Imagin what would happen if root tried a ‘simple’ *ls *there.

Thanks elserj and hcvv.

As I understand it, if the path of an executable is not defined in $PATH, you must explicitly include the full pathname of the file to execute it, which adding ./ does. I also tested this by typing at the command prompt


which also executed the file with no problems.

You are correct but one detail.

It is not required to type an absolute path, it may be relative. In fact ./ is relative (it does not start with /).

But you are correct, when you do not provide a path yourself, the shell will look at your PATH environment variable and search from left to right in all the directories until it finds a file of the name you gave and then try to execute it.

And it is the inclusion of relative pathes in the PATH variable (and ./ is the most (mis)used one here) that can create havoc because it depends upon what your working directory is at the very moment you call something where it will end up somewhere relative to that working directory.

Thanks hcvv,

That’s what I meant. :wink:

I believe you are correct, however, if the path is changed so that . is the last directory in the path as I showed, shouldn’t the other ls be used first? In other words, doesn’t the system just use the first one that comes up in the path, so if multiple executables exist in the path, whichever is listed first in the path is used? It seems to me that in that case, it would not be a security issue since root’s path can not be changed by the user. If I am incorrect, please let me know.

It’s less risky but there is still the possibility to take advantage of typing mistakes. The user could plant a command which is close to an existing command, e.g. nestat, when root meant to type netstat. The nestat command would then silently grant the user root privileges (one way is to bless a command as root setuid), and then exit with “nestat not found”. Nothing would seem amiss.

And what about the root who wanted to type

ls -d

but typed


which showed to be a program of a user (mistyping is of course allways a deadly sin for root). Even if the user did not plant a dangerous program it would at least be embarassing for root and bad for his reputation.

This . is thought to be dangerous allready for at least 30 years.