Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!weiser.pa@Xerox.COM
From: weiser.pa@Xerox.COM
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <10605@brl-adm.ARPA>
Date: Tue, 1-Dec-87 12:02:17 EST
Article-I.D.: brl-adm.10605
Posted: Tue Dec  1 12:02:17 1987
Date-Received: Fri, 4-Dec-87 06:43:15 EST
Sender: news@brl-adm.ARPA
Lines: 24

"Richard A. O'Keefe"  (and others) point out, any method that
requires that a file to be executed by a special call can be simulated by using
environment variables or other means to first remember the file being executed,
then do the exec.

As Chris T. points out, this is really not adequate, since you simply may not
know ahead of time that the program you are running will want to figure out
where it is running from.  A /dev scheme will work ok, or a new system call
"givemeanfdfromwhereIam running".

As a workaround, I do the following in the dynamical loading/linking system I
wrote for the Portable Cedar project at PARC: any program which wants to inquire
about its load status is run from a shell script which invokes it via its full
path name.  Then by looking at argv[0] it can find the file from which it is
running.  In other words, program 'foo' in /usr/local/bin is really the script 
	#/bin/csh -f
	exec /usr/lib/foo.real

This way folks with /usr/local/bin on their path can just say 'foo' to run it,
but the real foo gets run with a full path name.  Note that the execer doesn't
have to do anything special to run foo, but foo has to be careful to install
itself in the world in a special way.

-mark