Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!limes From: limes@sun.com (Greg Limes) Newsgroups: comp.unix.wizards Subject: Re: Reading the symbol table of the currently running executable Message-ID: Date: 15 Sep 89 01:42:07 GMT References: <9104@june.cs.washington.edu> <6131@lynx.UUCP> <920@aoa.UUCP> Sender: news@sun.Eng.Sun.COM Organization: Sun Microsystems, Inc. Lines: 43 In-reply-to: mbr@aoa.UUCP's message of 8 Sep 89 21:11:55 GMT In article <920@aoa.UUCP> mbr@aoa.UUCP (Mark Rosenthal) writes: In article limes@sun.com (Greg Limes) writes: >In article <6131@lynx.UUCP> mitch@lynx.uucp (Mitch Bunnell) writes: > >> In article <9104@june.cs.washington.edu> bcn@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@sun.com ...!sun!limes 73327,2473 [choose one]