Why do we use
./filename to execute a file in linux?
Why not just enter it like other commands
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
In Linux, UNIX and related operating systems,
. denotes the current directory. Since you want to run a file in your current directory and that directory is not in your
$PATH, you need the
./ bit to tell the shell where the executable is. So,
./foo means run the executable called
foo that is in this directory.
The literal answer is as others have given: because the current directory isn't in your
But why? In short, it's for security. If you're looking in someone else's home directory (or /tmp), and type just
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
[, which might override those commands in shell scripts, if your shell doesn't have those as built-ins.
. 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
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.
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:
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:
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
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
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 "
./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
Before we go into the rationale, you should first know about this fact: running either of:
cd bin ./myexec
bin/someprog without searching the
PATH variable for the exact same reason: all of
./someprog have a slash
/ in them.
someprog alone does not have a slash
/, and therefore searches only in
POSIX 7 specifies this rule at: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
Rationale for the
/ POSIX PATH rule
Suppose that running:
Then, if you wanted to run
/bin/someprog from your distro, and you did:
it would sometimes work, but others it would fail, because you might be in a directory that contains another unrelated
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,
Conversely, suppose that running:
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:
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:
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
/ path search rule offers a simple to remember solution to the about problem:
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, 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.