up vote 3 down vote favorite
share [g+] share [fb]

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 abc.py different from ./abc.py ?

link|improve this question
feedback

migrated from stackoverflow.com Apr 13 '11 at 13:07

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

5 Answers

up vote 22 down vote

./abc.py means "Execute the abc.py file that is in the current directory."

abc.py means "Execute whatever abc.py file you find first in the shell's directory search path."

link|improve this answer
8  
This is relevant because many times the current directory isn't in the search path, so if you try to run abc.py you will get an error. – Javier Badia Apr 13 '11 at 14:00
6  
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
feedback
up vote 15 down vote

abc.py has to be in the command search path (i.e. in one of the directories specified in the PATH environment variable). ./abc.py is an exact path: it executes abc.py 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.

link|improve this answer
feedback
up vote 5 down vote

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.

link|improve this answer
2  
Actually, it's not the OS, but the command shell. – Marcin Apr 13 '11 at 14:48
2  
@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
feedback
up vote 0 down vote

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.

link|improve this answer
feedback
up vote -1 down vote

You only need to do ./abc.py 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.

link|improve this answer
1  
@Jefromi: Sorry, how do you know which shell I, or the OP are using? – Marcin Apr 13 '11 at 14:16
5  
@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
2  
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
4  
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
6  
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
show 8 more comments
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.