Windows vs. Linux GCC argv[0] value [duplicate]

Question

Possible Duplicate:
Get path of executable

I'm programming on Windows using MinGW, gcc 4.4.3. When I use the main function like this:

int main(int argc, char* argv[]){
    cout << "path is " << argv[0] << endl;
}

On Windows I get a full path like this: "C:/dev/stuff/bin/Test". When I run the same application on Linux, however, I get some sort of relative path: "bin/Test". It's breaking my application! Any idea on how to make sure the path is absolute on both systems?

Answer 1

No, there isn't. Under most shells on Linux, argv[0] contains exactly what the user typed to run the binary. This allows binaries to do different things depending on what the user types.

For example, a program with several different command-line commands may install the binary once, and then hard-link the various different commands to the same binary. For example, on my system:

$ ls -l /usr/bin/git*
-rwxr-xr-x  109 root  wheel  2500640 16 May 18:44 /usr/bin/git
-rwxr-xr-x    2 root  wheel   121453 16 May 18:43 /usr/bin/git-cvsserver
-rwxr-xr-x  109 root  wheel  2500640 16 May 18:44 /usr/bin/git-receive-pack
-rwxr-xr-x    2 root  wheel  1021264 16 May 18:44 /usr/bin/git-shell
-rwxr-xr-x  109 root  wheel  2500640 16 May 18:44 /usr/bin/git-upload-archive
-rwxr-xr-x    2 root  wheel  1042560 16 May 18:44 /usr/bin/git-upload-pack
-rwxr-xr-x    1 root  wheel   323897 16 May 18:43 /usr/bin/gitk

Notice how some of these files have exactly the same size. More investigation reveals:

$ stat /usr/bin/git
234881026 459240 -rwxr-xr-x 109 root wheel 0 2500640 "Oct 29 08:51:50 2011" "May 16 18:44:05 2011" "Jul 26 20:28:29 2011" "May 16 18:44:05 2011" 4096 4888 0 /usr/bin/git
$ stat /usr/bin/git-receive-pack 
234881026 459240 -rwxr-xr-x 109 root wheel 0 2500640 "Oct 29 08:51:50 2011" "May 16 18:44:05 2011" "Jul 26 20:28:29 2011" "May 16 18:44:05 2011" 4096 4888 0 /usr/bin/git-receive-pack

The inode number (459240) is identical and so these are two links to the same file on disk. When run, the binary uses the contents of argv[0] to determine which function to execute. You can see this (sort of) in the code for Git's main().

Answer 2

argv array

argv[0] is a parameter like any others: it can be an arbitrary NUL terminated byte string. It can be the empty string. It is whatever the launching process wants.

By default, the shell with set argv[0] to whatever is used to name the program: a name looked-up in $PATH, a relative or an absolute path. It can be a symbolic link or a regular file.

To invoke a program with some other value, with zsh (dunno with other shells) use:

ARGV0=whatever_you_want some_program arguments

If you really need the path to the executable, you cannot use the command line on Unix.

Linux only

On Linux: /proc/self/exe is a symbolic link to the executable file.

You can readlink it. You can also stat or open it directly.

Renaming and soft link

A normal soft link is a dumb string, and doesn't know what happens to its target (if it exists at all). But the /proc/self/exe soft link is magic.

In case of renaming, the soft-but-magic-link will follow renaming. In case there are several hard links, it will follow the name of the particular hard link that was used. (So different hard links to the same file are not perfectly equivalent under Linux.)

If this hard link is unlinked, I think " (deleted)" is appended to the value of the symbolic link. Note that this is a valid file name, so another unrelated file could have that name.

In any case, the symbolic link is a hard link to the file, so you can stat or open it directly.

I don't think you can count on anything on a network file system if the binary is renamed or unlinked on another system than the one where the executable is launched.

Security considerations

When your program gets to use the /proc/self/exe special file, it is possible for the file used to launch your program to be unlinked or renamed. This should be taken seriously in case the program is privileged (SUID or Set Capabilities): even if the user doesn't have write access to the original "Set Something" binary, he may be able to make a hard link to it if he has write access to a directory on the same file system, so he may be able to change the name if a running privileged binary.

By the time you readlink, the value returned may refer to another file. (Of course, there is always an unavoidable race condition with opening the result of readlink.)

As usual, NFS does not provides all the same guaranties that local file systems have.