finding executable's own filename

[zloba]

i'm looking for a way to obtain the executable's filename of the current process. particularly for various types of Unix (hints for Windows are also welcome).

this would be useful to locate files associated with a program.

is there a general Unix way to get the filename? or at least different ways for different Unixes? please share any that you know.

i know there's the /proc filesystem for Linux, but that isn't very portable. i guess it can be used if there are no better alternatives..

looking at argv [ 0 ] - even less clean, because it's likely incomplete, and has to be reconstructed - tricky and unreliable.

for Windows, GetModuleFileName() can be used, afaik.

[Solar]

is there a general Unix way to get the filename?

argv[ 0 ].

looking at argv [ 0 ] - even less clean, because it's likely incomplete, and has to be reconstructed - tricky and unreliable.

Inhowfar incomplete? Why would you have to reconstruct it? If you're looking for a fully qualified file name (instead of a relative one), you might want to use getenv( "PWD" ) to get the current directory - at least under Unixes.

[zloba_guest]

argv [ 0 ] - Inhowfar incomplete?

completely incomplete. when you invoke a program in the $PATH, using only the name - that's what argv [ 0 ] will be, without path, or it could be a relative path.

i would have to reconstruct it using the same algorithm shell used to run the binary, and then what if it's a symlink?

If you're looking for a fully qualified file name (instead of a relative one),

exactly.

you might want to use getenv( "PWD" ) to get the current directory - at least under Unixes.

that's current working directory, it has exactly nothing to do with the executable path, unless you invoke it as ./path/to/binary

when you invoke "ls", do you cd /bin ?

Why would you have to reconstruct it?

quoting myself,

this would be useful to locate files associated with a program.

such as resource files, bundled binaries, libraries, etc.

[zloba_guest]

i suppose there isn't a "general unix way", not a clean one anyway...

[Candy]

i suppose there isn't a "general unix way", not a clean one anyway...

I believe the generic way to allocate resources for your file is to compile it with a prefix-dir (such as "/usr/", "/", "/usr/local/" or "c:\Program Files") and to append your program name and then to put your files there.

[Solar]

completely incomplete. when you invoke a program in the $PATH, using only the name - that's what argv [ 0 ] will be, without path, or it could be a relative path.

Ah, OK.

this would be useful to locate files associated with a program.

such as resource files, bundled binaries, libraries, etc.

Then you're approaching this wrongly, at least for the Unix world. Unix has a path for binaries, it has a path for libraries, and ressource files are ususally located somewhere in a compiled-in path where your program should be looking for them.

Other than that, there's "which".

I know this all doesn't really sound helpful, but AFAIK Unix doesn't cater for something like [tt]PROGDIR:[/tt] under AmigaOS...

[zloba]

Then you're approaching this wrongly, at least for the Unix world. Unix has a path for binaries, it has a path for libraries, and ressource files are ususally located somewhere in a compiled-in path where your program should be looking for them.

I believe the generic way to allocate resources for your file is to compile it with a prefix-dir

that's what i'm trying to avoid. it's like global variables vs. objects..

but AFAIK Unix doesn't cater for something like PROGDIR: under AmigaOS...

i'm thinking about wrapper binaries or scripts that would pass certain information to the main executable, via environment or arguments.

<rant:>

it's not just about resources, but more importantly, config and data - so that there may be multiple instances of a program and multiple instances of data, independently of each other (executable path isn't good for data, unless there is a mapping {program-instance,user}=>data)

this is largely inspired by running various versions of things like Apache and MySQL simultaneously and with separate instances of data. it can be accomplished by pointing them to a specific config file, preferrably without having to do so by hand each time.

MySQL wants to be started from within the directory where it was unpacked - apparently that's how it finds itself.

funny how programs distributed as binaries manage to work well and be portable (location-independent and multi-platform), unlike pure Unix-way programs.

[JoeKayzA]

Btw, you could also take the content of argv[ 0 ] and give it to 'which'. This will always give you the absolute path of your executable, but it depends on 'which' to be installed....I can think of several programs that do so, however.

cheers Joe

[zloba]

Btw, you could also take the content of argv[ 0 ] and give it to 'which'. This will always give you the absolute path of your executable

then i would have to fork a child, handle its input..
and "which" doesn't handle symlinks, or relative filenames - only those in $PATH.

i think it will have to be wrappers - like Windows shortcuts with their options. perhaps using a special #!interpreter, so they can contain data instead of code.

[JoeKayzA]

then i would have to fork a child, handle its input..

It's a lot of work for a 'trivial' task, yes..

and "which" doesn't handle symlinks, or relative filenames - only those in $PATH.

That's not true: 'which' handles relative filenames just fine, I tested this before posting. How should it 'handle' symlinks? It treats symlinks to directories as seperate directories, but isn't this the expected behaviour?

cheers Joe

[zloba]

'which' handles relative filenames just fine (..) How should it 'handle' symlinks?

'handle' meaning dereferencing them, at least when it comes to the final executable.
i was looking for a fully qualified (or at least relative) path to the final binary (its actual base directory).

Code: Select all

$ make hello
cc     hello.c   -o hello
$ mkdir subdir
$ cp hello subdir/hello
$ ln -s subdir/hello hello-link
$ which ./hello-link 
./hello-link
# ^ desired: location of hello (the target executable)
# whether absolute or at least relative, so it can be associated with subdir where it is

this result of "hello-link" doesn't tell that "hello" is installed in "subdir"..

i guess this is how it's executed - dereferencing is done by the OS routines when actually loading the file - but it's not very useful as such.

[Pype.Clicker]

well, considering the possible complexity of a "generic" approach compared to reading link value of "/proc/self/exe", i'd suggest you detect at compile time whether "/proc/self/exe" works and fall back to "readlink `which $ARGV[0]`" when the former is not available.