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