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 ?
Utsav
Posted 2011-04-13T13:01:21.810
Reputation: 183
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."
Kristopher Johnson
Posted 2011-04-13T13:01:21.810
Reputation: 1 570
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.
thkala
Posted 2011-04-13T13:01:21.810
Reputation: 1 769
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.
Demento
Posted 2011-04-13T13:01:21.810
Reputation: 278
2Actually, it's not the OS, but the command shell. – Marcin – 2011-04-13T14:48:42.307
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(). – user1686 – 2011-04-14T05:10:30.203
The trick only works if . is at the beginning of the path, not at the end. – user1686 – 2011-04-14T05:10:56.710
@grawity: I stand corrected. – Marcin – 2011-04-14T09:13:03.833
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.
sateesh
Posted 2011-04-13T13:01:21.810
Reputation: 136
-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.
Marcin
Posted 2011-04-13T13:01:21.810
Reputation: 2 495
-1: environment variable names are case sensitive. – Cascabel – 2011-04-13T13:06:55.453
1@Jefromi: Sorry, how do you know which shell I, or the OP are using? – Marcin – 2011-04-13T14:16:44.537
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 – 2011-04-13T14:44:47.7202Further, 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 – 2011-04-13T14:47:17.173
@Jefromi - if it's not case sensitive, it isn't broken, it just isn't 100% POSIX compliant. I'll give you a nickel if you can find me someone who really cares about 100% posix compliance. Also, you just admitted it is a matter of the shell. – Marcin – 2011-04-13T14:47:24.850
4I'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 – 2011-04-13T14:52:04.660
6The energy spent nitpicking here could have been spent replacing $path with $PATH thus helping write a comprehensive answer. Just saying :-) – sam hocevar – 2011-04-13T15:20:42.867
@jefromi: The underlying system is involved in the names of files (including directories, etc.) You were nitpicking about the name of shell variables (a shell could of course still export a proper environment with upper case variables). – Marcin – 2011-04-13T18:14:41.227
@Sam Hocevar: Yes, but now future readers will learn a lot more about the structure of how shells, environments, and filesystems interact ;) – Marcin – 2011-04-13T18:17:25.110
@Marcin: Be careful what you're telling future readers - I think you have a bit more homework to do. Certainly you could write a shell which itself would use case-insensitive environment variables. But what do you think happens when you call getenv in C? Yes, on some platforms that ends up being case-insensitive, but not on the *nixes I know. I'm fairly certain there's nothing a shell can do about that. (Programs don't even have to have been started from within a shell! What about the first shell?) – Cascabel – 2011-04-13T21:37:50.887
@Jefromi: Did you not read, or did you simply not understand my last reply to you? Nothing you just said adds to what I wrote, except that you have introduced the concept of a case-insensitive getenv environment. Incidentally, you're wrong that there's nothing a shell can do to deal with being hosted on a case sensitive platform: to the extent that there is a convention about certain variables being in a certain case, the shell can export them in the correct case. – Marcin – 2011-04-13T23:37:01.983
@Marcin: I think it may be you who did not understand, but I don't think it's worth any further discussion in this forum. – Cascabel – 2011-04-14T02:43:21.040
@Jefromi: Nice. Refuse to engage when called on not bothering to read properly. I hope it made you feel big. – Marcin – 2011-04-14T09:08:22.103
10This is relevant because many times the current directory isn't in the search path, so if you try to run
abc.pyyou will get an error. – Javier – 2011-04-13T14:00:46.3807Also, 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 – 2011-04-13T14:47:48.050