Page 1 of 1
finding executable's own filename
Posted: Wed Jan 25, 2006 11:26 pm
by 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.
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 9:59 am
by Solar
zloba wrote:
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.
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 11:41 am
by 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.
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 11:46 am
by zloba_guest
i suppose there isn't a "general unix way", not a clean one anyway...
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 2:05 pm
by Candy
zloba_guest wrote:
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.
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 4:20 pm
by Solar
zloba_guest wrote:
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...
Re:finding executable's own filename
Posted: Thu Jan 26, 2006 9:23 pm
by 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.
Re:finding executable's own filename
Posted: Fri Jan 27, 2006 1:05 am
by 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
Re:finding executable's own filename
Posted: Fri Jan 27, 2006 10:52 pm
by 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.
Re:finding executable's own filename
Posted: Sat Jan 28, 2006 7:06 am
by JoeKayzA
zloba wrote:
then i would have to fork a child, handle its input..
It's a lot of work for a 'trivial' task, yes..
zloba wrote:
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
Re:finding executable's own filename
Posted: Sat Jan 28, 2006 7:52 am
by 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.
Re:finding executable's own filename
Posted: Mon Jan 30, 2006 5:12 am
by 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.