Reading the symbol table of the currently running executable

[Greg Limes]

In article <920 at aoa.UUCP> mbr at aoa.UUCP (Mark Rosenthal) writes:
   In article <LIMES.89Sep7153103 at ouroborous.wseng.sun.com> limes at sun.com (Greg Limes) writes:
   >In article <6131 at lynx.UUCP> mitch at lynx.uucp (Mitch Bunnell) writes:
   >
   >> In article <9104 at june.cs.washington.edu> bcn at cs.washington.edu (Clifford Neuman) writes:
   >> >  2) Obtaining the full path name of the presently running executable.
   >
   >> 2 - Not possible.
   >
   >Back before I knew this was impossible, I wrote the following piece of
   >support code. It has been doing the impossible for me for quite some
   >time (geez, has it been that long?) with limitations as stated.

   Your approach works if the program was exec'd by a reasonably well-behaved
   program.  'sh' and 'csh' fall into this category.  Unfortunately, your code
   (or anybody else's) fails to solve the general case.

After receiving several pieces of mail -- as usual with postings of
findx(), generally ranging from flames to thanks -- I finally went
back and re-read the disclaimers at the top.

It appears that I nuked the section that described in detail the
assumptions that findx() made and the ways that these assumptions
might break down, and some specific limits on the utility of the
routine based on those assumptions.

Boiling it all down: findx() assumes you have a list of candidate
directories in the form of a normal $PATH, and the name of a file to
be found within those directories.

If your application keeps a name or list of names under which it can
be installed, it can dispense with looking in argv[0] for the name;
similarly, if your application keeps a directory or list of
directories under which it could be installed you can dispense with
querying the $PATH variable.

As Mark notes, there is no way of getting the *one*true*name* of the
binary out of the kernel, and even if you could (which he does not
note), you can still be in a position where the binary has been
replaced by something else (consider a binary that has been updated
with a new version).
--
-- Greg Limes	limes at sun.com	...!sun!limes	73327,2473	[choose one]