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