How to get name of the executable or module
Karim Atiki
I'm writing a linux application which loads several DSO modules.
Also in one of these DLL, I would like to know the name of the client
exe.
For the Windows developer, I'm looking for a function such like
GetModuleFilename().
Does it exist under Linux ?
Thanks,
Karim
James Cownie
readlink on "/proc/self/exe" will give you _one_ of the names of
the initial executable. (With hard links the same executable can have
arbitrarily many names, of course).
-- Jim
James Cownie <jco...@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
Lew Pitcher
>Karim Atiki wrote:
>> I'm writing a linux application which loads several DSO modules.
>> Also in one of these DLL, I would like to know the name of the client
>> exe.
>> For the Windows developer, I'm looking for a function such like
>> GetModuleFilename().
>>
>> Does it exist under Linux ?
>
>readlink on "/proc/self/exe" will give you _one_ of the names of
>the initial executable. (With hard links the same executable can have
>arbitrarily many names, of course).
If the binary were unlinked from the fs while it is running, would
/proc/self/exe be of any use?
Lew Pitcher
IT Consultant, Development Services
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
James Cownie
>
> On Thu, 05 Apr 2001 11:15:27 GMT, James Cownie <jco...@etnus.com> wrote:
>
> >Karim Atiki wrote:
> >> I'm writing a linux application which loads several DSO modules.
> >> Also in one of these DLL, I would like to know the name of the client
> >> exe.
> >> For the Windows developer, I'm looking for a function such like
> >> GetModuleFilename().
> >>
> >> Does it exist under Linux ?
> >
> >readlink on "/proc/self/exe" will give you _one_ of the names of
> >the initial executable. (With hard links the same executable can have
> >arbitrarily many names, of course).
>
> If the binary were unlinked from the fs while it is running, would
> /proc/self/exe be of any use?
>
Well, /proc/self/exe is just a symbolic link, so if you unlink the image
while the process is running it will simply become a dangling symbolic link.
The readlink will still work, and will still return the value of the link
(the name of the file). If that's all you wanted (which was the original question),
then it's still working.
If you want a guaranteed way to _open_ the original executable in the face
of it being unlinked then this isn't it.
John Reiser
> For the Windows developer, I'm looking for a function such like
> GetModuleFilename().
The filename at the time of the execve() system call appears
as "the highest-addressed character string in the address space".
Go to the fixed end of the stack (0xc0000000 or 0x80000000
in many x86 distributions), and start working your way back.
First there is an int of 0, then a char of 0, then the filename,
then a char of 0. The address of the fixed end of the stack
can be determined by finding the terminating 0 pointer at the
end of the initial array of pointers to environment variables,
then rounding up to PAGE_SIZE.
In the kernel sources, consult fs/exec.c do_execve() for reference
to binprm.filename, and fs/binfmt_elf.c for load_elf_binary().
The filename is of "historical interest" only: the instant
_before_ the new module gets control, another process can change
the association between the name and any bits that may reside
in the filesystem (by doing an unlink, etc.) The bits themselves
can still be accessed via /proc/self/exe.
--
John Reiser, jre...@BitWagon.com
Grant Edwards
>> I'm writing a linux application which loads several DSO
>> modules. Also in one of these DLL, I would like to know the
>> name of the client exe.
>>
>> Does it exist under Linux ?
>
>readlink on "/proc/self/exe" will give you _one_ of the names of
>the initial executable. (With hard links the same executable can have
>arbitrarily many names, of course).
Including zero names, BTW.
--
Grant Edwards grante Yow! .. I'll make you
at an ASHTRAY!!
visi.com
Gene McCulley
You can't do this portably, but GNU libc defines an extension that is useful
in this case. In errno.h, there is defined program_invocation_name and
program_invocation_short_name. These get set up before the call to main.
This is handy when you have library code that needs to know argv[0], but
doesn't want to put a requirement on calling code to hand it down. You have
to define _GNU_SOURCE to get access to it because most distributions of Linux
don't enable the GNU extensions by default. See the GNU libc documentation
for more details. Example follows:
#define _GNU_SOURCE
#include <stdio.h>
#include <errno.h>
int main(int argc, char *argv[])
{
printf("program_invocation_name: %s\n", program_invocation_name);
printf("program_invocation_short_name: %s\n",
program_invocation_short_name);
return 0;
}
--
Gene McCulley http://enki.org/~mcculley/ Voice: 407-260-1166
Systems Engineer gmcc...@lynuxworks.com Fax: 407-650-2951
LynuxWorks, Inc. http://www.lynuxworks.com/ Cell: 407-230-0888
Arthur H. Gold
>
> Karim Atiki wrote:
> > I'm writing a linux application which loads several DSO modules.
> > Also in one of these DLL, I would like to know the name of the client
> > exe.
> > For the Windows developer, I'm looking for a function such like
> > GetModuleFilename().
> >
> > Does it exist under Linux ?
For a system that supports the /proc (pseudo)filesystem you
could do:
#include <stdlib.h>
#include <unistd.h>
char * get_exe_name()
static char buf[PATH_MAX];
int rslt = readlink("/proc/self/exe", buf, PATH_MAX);
if ( rslt < 0 || rslt >= PATH_MAX ) {
return NULL;
}
buf[rslt] = '\0';
return buf;
}
HTH,
--ag
>
> You can't do this portably, but GNU libc defines an extension that is useful
> in this case. In errno.h, there is defined program_invocation_name and
> program_invocation_short_name. These get set up before the call to main.
> This is handy when you have library code that needs to know argv[0], but
> doesn't want to put a requirement on calling code to hand it down. You have
> to define _GNU_SOURCE to get access to it because most distributions of Linux
> don't enable the GNU extensions by default. See the GNU libc documentation
> for more details. Example follows:
>
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <errno.h>
>
> int main(int argc, char *argv[])
> {
> printf("program_invocation_name: %s\n", program_invocation_name);
> printf("program_invocation_short_name: %s\n",
> program_invocation_short_name);
> return 0;
> }
>
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:ag...@bga.com or mailto:ag...@cs.utexas.edu
--
Clone Bernie!
Nate Eldredge
> Karim Atiki wrote:
> > I'm writing a linux application which loads several DSO modules.
> > Also in one of these DLL, I would like to know the name of the client
> > exe.
> > For the Windows developer, I'm looking for a function such like
> > GetModuleFilename().
> >
> > Does it exist under Linux ?
>
> You can't do this portably, but GNU libc defines an extension that is useful
> in this case. In errno.h, there is defined program_invocation_name and
> program_invocation_short_name. These get set up before the call to main.
> This is handy when you have library code that needs to know argv[0], but
> doesn't want to put a requirement on calling code to hand it down. You have
> to define _GNU_SOURCE to get access to it because most distributions of Linux
> don't enable the GNU extensions by default. See the GNU libc documentation
> for more details. Example follows:
argv[0] won't necessarily tell you the filename of the executable. It
could be anything, depending on how the program was invoked. (Yes, I
mean *anything*; read the man page for execve if you don't believe
me.)
/proc/self/exe will always be a link pointing to your binary (though
`readlink' won't necessarily return the binary's filename; it may have
been deleted, for instance). However, this feature is not portable
beyond Linux.
--
Nate Eldredge
neld...@hmc.edu
hushui
> Gene McCulley wrote:
>>
>> Karim Atiki wrote:
>> > I'm writing a linux application which loads several DSO modules.
>> > Also in one of these DLL, I would like to know the name of the client
>> > exe.
>> > For the Windows developer, I'm looking for a function such like
>> > GetModuleFilename().
>> >
>> > Does it exist under Linux ?
> For a system that supports the /proc (pseudo)filesystem you
> could do:
The following does not work . Why??
While reading /proc/self/exe ,the function returns NULL .
Arthur H. Gold
>
> Arthur H. Gold <ag...@bga.com> wrote:
> > Gene McCulley wrote:
> >>
> >> Karim Atiki wrote:
> >> > I'm writing a linux application which loads several DSO modules.
> >> > Also in one of these DLL, I would like to know the name of the client
> >> > exe.
> >> > For the Windows developer, I'm looking for a function such like
> >> > GetModuleFilename().
> >> >
> >> > Does it exist under Linux ?
>
> > For a system that supports the /proc (pseudo)filesystem you
> > could do:
> The following does not work . Why??
> While reading /proc/self/exe ,the function returns NULL .
>
> > #include <stdlib.h>
> > #include <unistd.h>
>
> > char * get_exe_name()
> > static char buf[PATH_MAX];
> > int rslt = readlink("/proc/self/exe", buf, PATH_MAX);
> > if ( rslt < 0 || rslt >= PATH_MAX ) {
> > return NULL;
> > }
> > buf[rslt] = '\0';
> > return buf;
> > }
>
least):
#include <stdlib.h>
#include <unistd.h>
#ifndef PATH_MAX
#define PATH_MAX 1024
#endif
char * get_exe_name() {
static char buf[PATH_MAX];
int rslt = readlink("/proc/self/exe", buf, PATH_MAX);
if ( rslt < 0 || rslt >= PATH_MAX ) {
return NULL;
}
buf[rslt] = '\0';
return buf;
}
int main( void ) {
char * exe_name = get_exe_name();
puts( exe_name );
return 0;
}
HTH,
--ag
Paul Kimoto
> You have
> to define _GNU_SOURCE to get access to it because most distributions of Linux
> don't enable the GNU extensions by default.
This is (probably) because the glibc developers (you know, the GNU people)
don't enable them by default. As /usr/include/features.h says, "the
default is all but _GNU_SOURCE" (in version 2.1.3, and similar text in
2.2.2).
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
Norman Black
> could do:
>
> #include <stdlib.h>
> #include <unistd.h>
>
> char * get_exe_name()
> static char buf[PATH_MAX];
> int rslt = readlink("/proc/self/exe", buf, PATH_MAX);
> if ( rslt < 0 || rslt >= PATH_MAX ) {
> return NULL;
I think this is Linux only (>= 2.1 I think).
Certainly Solaris 8 does not have an "exe" item in the proc directory tree
of a process.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
Arthur H. Gold
>
> > For a system that supports the /proc (pseudo)filesystem you
> > could do:
> >
> > #include <stdlib.h>
> > #include <unistd.h>
> >
> > char * get_exe_name() {
> > static char buf[PATH_MAX];
> > int rslt = readlink("/proc/self/exe", buf, PATH_MAX);
> > if ( rslt < 0 || rslt >= PATH_MAX ) {
> > return NULL;
>
> I think this is Linux only (>= 2.1 I think).
> Certainly Solaris 8 does not have an "exe" item in the proc directory tree
> of a process.
But this _is_ comp.os.linux.development.apps
^^^^^
(and I did mention the `/proc' caveat)
--ag
Norman Black
> > > could do:
> But this _is_ comp.os.linux.development.apps
> ^^^^^
It sounded to me like you were saying "a system" as in "a 'Unix' system"
that supports /proc. Many are concerned with Unix portability, as I am, and
I misinterpreted your statement as possibly implying portability beyond
Linux.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"Arthur H. Gold" <ag...@bga.com> wrote in message
news:3AE88706...@bga.com...