Xref: utzoo comp.unix.wizards:8388 comp.sources.d:2079
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.unix.wizards,comp.sources.d
Subject: Re: Finding where an executable was run from -- a proposal.
Message-ID: <52873@sun.uucp>
Date: 11 May 88 21:25:03 GMT
References: <67@uvaarpa.virginia.edu> <6800012@cpe> <4527@hoptoad.uucp>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 23

In article <4527@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>If exec() would pass this value to the executed program, say as
>argv[-1], then a program could reliably know its own name, and apply a
>simple transformation to it to find its data files (e.g. for program
>"XXXXXX/foo", its data files are found in "XXXXXX/lib/foo/whatever").
>This works for all values of XXXXXX, whether absolute or relative.
>For a subsystem like uucp, you would turn e.g. XXXXXX/uucico into
>XXXXXX/lib/uucp/whatever (replace program name with subsystem name).

In Turbo-C, Borland passes the complete path name of the program
executed as argv[0].  This may be specific to Turbo-C, or may be
general across MS-DOS.  Are there any programs that this would break?

>If anyone implements this, I recommend providing a #define AV_EXECNAME -1
>and documenting that argv[AV_EXECNAME] is the pathname given to exec().
>No sense embedding another magic number (-1) into programs...

... and defining AV_EXECNAME as (0) would make this work for Turbo-C and
any other environments that do as I described above. As things stand
now, if argv[0][0] is '/' then that string is *usually* the name of the
executing program.
-- 
   Greg Limes
#include