Why is "./" used when executing a program?

Question

If I have a program named foo, why do I need to say ./foo and not simply foo? Doesn't ./ just mean within the current directory?

Answer 1

When you type in just a command – eg. foo – the shell (usually bash) will only look for it in certain directories – like /bin, /usr/bin, /usr/X11R6/bin and so on. It will typically not look in your "current directory" (ie. "." ) because of security concerns (especially if you're root). If "." is added, it should be added to the end of the search-path.

If you want to run a executable that's not in this search-path, you need to specify the whole absolute or relative path to the command. For example:

/home/bok/foo   # Absolute in my homedir

~/src/bar  # Shorthand for my homedir and a subdir in it

../Download/foobar  # Relative path – up one step, then down in Download

Or – if the command is in my current directory – simply add a ./:

./foo

The search-path for bash is stored in the PATH environmental-variable, so you can see it by typing:

echo $PATH

To add "." – which you really shouldn't do – type:

export PATH="$PATH:."

The PATH is searched in order, so if there are several executables with the same name in different directories, it's the one in the directory first in the PATH that the shell will execute.

First after looking in all the listed directories, will you get a "command not found" error.

+++

The problem with adding the current directory – . – to the PATH, is that you don't really know if an executable in a "non standard" directory you may just happen to be in should be executed or not.

Lets say I'm evil an make a destructive program that delete as many files as possible and leave it in my home directory – or worse, in /tmp... I call this program sl – a common miss-type of ls – and wait.

Some random user is in /tmp, and miss-spells ls with sl. With a normal PATH – without . – nothing happens, except he gets an error for "command not found". If he got '.' at the end of his PATH, then he won't get an error for typing the command. Instead my sl command will run, and delete all the files he owns. If he happens to be root, the command will be able to delete much of the system. (This is why root really should make it a rule to always use the full path of commands, rather than trusting PATH.)

If he had placed '.' first in his PATH and I made program called ls (correct spelling) and put it in a directory, then it would be my program – not the normal ls – that would be run if he typed ls in that directory. Because bash would look in the current directory (.) first – before looking in the system-directories with the genuine ls.