Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!ninja!sys1!sneaky!gordon
From: gordon@sneaky.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Finding where an executable was run
Message-ID: <-63169371@sneaky>
Date: 17 May 88 18:18:00 GMT
References: <4527@hoptoad.uucp>
Lines: 22
Nf-ID: #R:hoptoad.uucp:4527:sneaky:-63169371:000:1190
Nf-From: sneaky.UUCP!gordon    May 17 13:18:00 1988


> The convention used by ksh-i is to put the full pathname used to exec a file
> in the environment variable "_". This makes a lot of sense to me, and seems
> as good an example of prior art as anything else out there. It is also cleaner
> than most of the suggestions we've seen so far in this discussion, not
> requiring any change to the kernel or the C calling conventions.

Great.  Now all the programs that use one of the forms of "exec" have to
fiddle with the environment (remove the old value of $_, if present, and
add a new one).  Either that, or you change the exec*() family of library
interface routines (you don't really want this in the kernel, do you?) to do
it for you, and relink *EVERYTHING*.  (Does anyone REALLY want exec*()
to call malloc()?  Anyone got a good alternative?)

If you just put the code in the shells (remember, uucico is a commonly
used shell), then I would expect mass confusion when /bin/cc is invoked and 
$_ comes out as "/bin/make".  Or maybe it ends up undefined.  There are 
lots of programs out there that don't use a shell if the command is simple 
enough to parse and exec by itself.

					Gordon L. Burditt
					...!ihnp4!sys1!sneaky!gordon