<offtopic>
From: Andi Kleen <yy@xxxxxx>:
> This would need another system call to load the path names into the kernel.
No, if this is a file (or directory) that is often read, its contents
will be in cache.
From David Korn <yyy@xxxxxxxxxxxxxxxx>:
> > It need not. Some Unix flavours allow #!perl.
> Yes, but the problem with this is that the system needs to
> do a PATH search for perl
Yes, just like for execlp. Nothing wrong with that.
If you know a path, you give it explicitly and things are efficient.
Otherwise you make the system do a PATH search, and things at least work.
</offtopic>
From Jason Zions <yyyyyyyy@xxxxxxxxxxxxx>:
> The charter for the Austin Group project is to merge what already
> has been approved into a single, coherent, common document.
> Doing anything else is out of scope, *and should remain so*.
Reasonable enough. The present #! discussion touched two points
where I feel the present text must be improved. Let me start describing
one point where the current text is somewhat erroneous and somewhat
self-contradictory, and where I think we can be more precise and more correct.
The present exec text:
The exec functions shall replace the current process image with a new process
image.
The new image is constructed from a regular, executable file called the new
process
image file.
...
The argument path points to a path name that identifies the new process image
file.
...
If the process image file is not a valid executable object, execlp( ) and
execvp( )
use the contents of that file as standard input to a command interpreter
conforming
to system( ). In this case, the command interpreter becomes the new process
image.
The third quoted fragment contradicts the second quoted fragment (and also the
first).
It is unclear what "the process image file" refers to. Everywhere else the
reference
is to "the new process image file".
Proposal:
The exec functions shall replace the current process image with a new process
image.
There is no return from a successful exec because the calling process image
is overlaid by the new process image.
This new process image is either constructed directly from the
regular, executable file identified by the first argument to the exec function
or is the process image of an interpreter invoked in order to
execute that file.
When a compiled C-language program is executed as a result of this call
...
If the file identified by the first argument to the exec function is not a
valid executable object, execlp() and execvp() use the contents of that file
as standard input to a command interpreter conforming to system().
In this case, the command interpreter becomes the new process image.
This is worded in such a way that the currently supported part is described
correctly, and, moreover, the use of #! is not outlawed so that current systems
that already support #! become compliant, and, in case #! is ever added to the
standard,
this fragment of text can remain unchanged.
Andries
mcvax!aeb
|