Why do we use "./" (dot slash) to execute a file in Linux/UNIX?

If you mean, why do you need ./ at the start – that’s because (unlike in Windows), the current directory isn’t part of your path by default. If you run:

$ ls

your shell looks for ls in the directories in your PATH environment variable (echo $PATH to see it), and runs the first executable called ls that it finds. If you type:

$ a.out

the shell will do likewise – but it probably won’t find an executable called a.out. You need to tell the shell where a.out is – it it’s in the current directory (.) then the path is ./a.out.

If you’re asking why it’s called “a.out”, that’s just the default output file name for gcc. You can change it with the -o command line arg. For example:

$ gcc test.c -o test
$ ./test

The literal answer is as others have given: because the current directory isn’t in your $PATH.

But why? In short, it’s for security. If you’re looking in someone else’s home directory (or /tmp), and type just gcc or ls, you want to know you’re running the real one, not a malicious version your prankster friend has written which erases all your files. Another example would be test or [, which might override those commands in shell scripts, if your shell doesn’t have those as built-ins.

Having . as the last entry in your path is a bit safer, but there are other attacks which make use of that. An easy one is to exploit common typos, like sl or ls-l. Or, find a common command that happens to be not installed on this system — vim, for example, since sysadmins are of above-average likelyhood to type that.

Does this sound too theoretical? It largely is, but it definitely can happen in reality, especially on multi-user systems. In fact, here is an example from this site where an administrator switched to a users’ home directory and found ps to be masked by an executable of that name.

You can try to add :. to your $PATH variable.

Try ALT+F2 and type: gksudo gedit /etc/environment if running Linux/GTK (this is what you have if using Ubuntu).

HOWEVER, I strongly advise you NOT to do that. It’s bad bad bad and bad.

You know, that kind of things work like this since 1970. There is a reason why the current directory isn’t included in the $PATH.

. is the current directory

.something would be a hidden file (Type “ALT+” to make them appear in Nautilus, or try “ls -la“.

./someProgram.sh is what you type to RUN an executable someProgram.sh in the current directory.

.somethingElse would mean that you have a hidden executable in the current directory, which is a bad idea.

The more complete rule is actually: if any slash / is in the path, don’t search PATH

Before we go into the rationale, you should first know about this fact: running either of:

bin/someprog

or:

/bin/someprog

or:

cd bin
./myexec

execute bin/someprog without searching the PATH variable for the exact same reason: all of bin/someprog, /bin/someprog and ./someprog have a slash / in them.

someprog alone does not have a slash /, and therefore searches only in PATH.

POSIX 7 specifies this rule at: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

PATH

[…] If the pathname being sought contains a <slash>, the search through the path prefixes shall not be performed.

Rationale for the / POSIX PATH rule

Suppose that running:

someprog

would search:

• relative to CWD first
• relative to PATH after

Then, if you wanted to run /bin/someprog from your distro, and you did:

someprog

it would sometimes work, but others it would fail, because you might be in a directory that contains another unrelated someprog program.

Therefore, you would soon learn that this is not reliable, and you would end up always using absolute paths when you want to use PATH, therefore defeating the purpose of PATH.

This is also why having relative paths in your PATH is a really bad idea. I’m looking at you, node_modules/bin.

Conversely, suppose that running:

./someprog

Would search:

• relative to PATH first
• relative to CWD after

Then, if you just downloaded a script someprog from a git repository and wanted to run it from CWD, you would never be sure that this is the actual program that would run, because maybe your distro has a:

/bin/someprog

which is in you PATH from some package you installed after drinking too much after Christmas last year.

Therefore, once again, you would be forced to always run local scripts relative to CWD with full paths to know what you are running:

"$(pwd)/someprog"

which would be extremely annoying as well.

Another rule that you might be tempted to come up with would be:

relative paths use only PATH, absolute paths only CWD

but once again this forces users to always use absolute paths for non-PATH scripts with "$(pwd)/someprog".

The / path search rule offers a simple to remember solution to the about problem:

• slash: don’t use PATH
• no slash: only use PATH

which makes it super easy to always know what you are running, by relying on the fact that files in the current directory can be expressed either as ./somefile or somefile, and so it gives special meaning to one of them.

Sometimes, is slightly annoying that you cannot search for some/prog relative to PATH, but I don’t see a saner solution to this.

I have been reading Linux manuals since 1999, and none of the security arguments make any sense. The real reason is that Linux allows any file to be executed, of any extension. The whole reason you have extensions is to avoid clicking on any file, or calling any file, on accident.

In Windows, you have exe, bats, which any user knows not to click on, unless they put them there themselves or wrote the program. Problem solved. However, there is an idiot warning now days that you are running an exe. A good application firewall allows rules for running new untrusted applications, as well as which folders it can write to.

I don’t know where most folks get their ideas of security.

1. I need to see the extension.
2. run an application firewall (I am not talking an internet or network firewall), which is way better than permissions, or at least needs to be layers on top.