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.