5

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 ?

5 Answers 5

24

./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."

2
  • 11
    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
    Apr 13, 2011 at 14:00
  • 8
    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. Apr 13, 2011 at 14:47
16

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.

5

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.

4
  • 2
    Actually, it's not the OS, but the command shell.
    – Marcin
    Apr 13, 2011 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(). Apr 14, 2011 at 5:10
  • The trick only works if . is at the beginning of the path, not at the end. Apr 14, 2011 at 5:10
  • @grawity: I stand corrected.
    – Marcin
    Apr 14, 2011 at 9:13
0

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.

-1

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.

13
  • 1
    @Jefromi: Sorry, how do you know which shell I, or the OP are using?
    – Marcin
    Apr 13, 2011 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.
    – Cascabel
    Apr 13, 2011 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.
    – Cascabel
    Apr 13, 2011 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.)
    – Cascabel
    Apr 13, 2011 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 :-) Apr 13, 2011 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .