Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: POSIX execlfd and execvfd proposal
Message-ID: <298@cresswell.quintus.UUCP>
Date: Mon, 30-Nov-87 19:10:50 EST
Article-I.D.: cresswel.298
Posted: Mon Nov 30 19:10:50 1987
Date-Received: Thu, 3-Dec-87 20:01:40 EST
References: <18491@linus.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 22
Summary: what about shell scripts

In article <18491@linus.UUCP>, ramsdell@linus.UUCP (John D. Ramsdell)
suggests two new variants of the already confusing exec() family,
which leave the executable file open with its fd in "extern int boot_fd"
of the new image.

But what happens if the file being executed is a shell script?

There isn't the slightest need for this, anyway.  You can already
obtain pretty much the effect he described by writing your own
execlfd or execvfd which
	- determines the identity of the file
	- opens it, yielding FD
	- adds "BOOTFD="FD to the new environment
	- calls the appropriate exec() with the new environment
Then the called program can just getenv("BOOTFD").

IEEE 1003.1 s 3.1.2.2 explicitly says "The argument arg0 should point
to a filename that is associated with the process being started by
one of the exec functions."  If the calling program is careful to
obey this rule, particularly if it is careful to pass the absolute
file name of the called program, the called program can open its
own file if it wants to without the need for any new exec variant.