Sign up ×

I've been using Linux & Mac for sometime now and I always wonder - Why do we have to execute a program like ./progname . I know Unix treats every thing as a file and it stores the filename in a table which points to the file's inode number.

But how is different from ./ ?

share|improve this question

migrated from Apr 13 '11 at 13:07

This question came from our site for professional and enthusiast programmers.

5 Answers 5

./ means "Execute the file that is in the current directory." means "Execute whatever file you find first in the shell's directory search path."

share|improve this answer
This is relevant because many times the current directory isn't in the search path, so if you try to run you will get an error. – Javier Apr 13 '11 at 14:00
Also, the main reason that people use "./" is that it is considered a security vulnerability to include the current directory in the path of directories to be searched so people usually do not expect the current directory to be searched, and usually do not put . in PATH. – William Pursell Apr 13 '11 at 14:47 has to be in the command search path (i.e. in one of the directories specified in the PATH environment variable). ./ is an exact path: it executes from the current directory (.).

In the Unix world it is considered a bad practice to have the current directory in the path, since it allows for extremely simple malicious attacks, where a well placed executable named after a common Unix command (or common mispellings thereof) would be inadvertently executed by an unsuspecting user.

E.g. a rather improbable, but most illustrating example is that where an attacker could leave an executable named rm in /tmp and wait for a system administrator to attempt to empty the /tmp directory.

share|improve this answer

The OS looks for the program to execute in all the directories listed in the $PATH-variable. The local directory "./" usually is not in the PATH. You can add it, but this has security implications.

If you add "./" to your PATH, someone can place a program called "vi" in a directory and wait until someone tries to edit something in this directory with vi - and the program gets executed with the permissions of the user that just got tricked... On a single-user system this might not be a severe issue, but it is still bad practice.

share|improve this answer
Actually, it's not the OS, but the command shell. – Marcin Apr 13 '11 at 14:48
@Marcin: It depends. Shells tend to do the lookup themselves (in order to cache it for later), but a program can hand it over to the OS by using execvp() instead of execv(). – grawity Apr 14 '11 at 5:10
The trick only works if . is at the beginning of the path, not at the end. – grawity Apr 14 '11 at 5:10
@grawity: I stand corrected. – Marcin Apr 14 '11 at 9:13

You need to invoke as ./progname if current working directory (CWD) is not in $PATH, if CWD is in $PATH invocation of form 'progname' would just work fine.

share|improve this answer

You only need to do ./ if . is not in your $path. $path is the environment variable that tells your shell where to look for programmes when you enter them as commands. You could use a different shell that has certain locations built-in, if you wanted.

share|improve this answer
@Jefromi: Sorry, how do you know which shell I, or the OP are using? – Marcin Apr 13 '11 at 14:16
@Marcin: It's not a matter of shell; it's POSIX. "Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications." If your shell isn't case sensitive, it's broken - and it's not bash, dash, sh, ksh, zsh, tcsh, or csh. Good luck finding *nix users who aren't using one of those. – Jefromi Apr 13 '11 at 14:44
Further, POSIX says: "Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore)..." and explicitly mentions PATH and what it should mean. – Jefromi Apr 13 '11 at 14:47
I'm not talking about 100% POSIX compliance, I'm talking about compliance with this one tiny portion which everyone complies with. If you're going to make the argument that what matters is practice, not standards, find me the *nix system that in practice is case insensitive. (And no, it's not just a matter of shell - the underlying system is involved.) – Jefromi Apr 13 '11 at 14:52
The energy spent nitpicking here could have been spent replacing $path with $PATH thus helping write a comprehensive answer. Just saying :-) – sam hocevar Apr 13 '11 at 15:20

Your Answer


