From: Nick Stoughton <yyyyy@xxxxxxxxxxxxxxx>
I am happy to lead a discussion of this in the WG15 mailing list,
and if there is general agreement from there to raise it at
the next Austin Group meeting as something we need to vote on.
Good. I don't think I am on this WG15 mailing list.
Probably you can tell me how to get on it?
From: "H. Peter Anvin" <yyy@xxxxxxxxxxxxx>
Keld Jørn Simonsen wrote:
> Everybody supports #! - why not standardize it?
This was my fault -- I was going to write a standardizable spec and
dropped the ball on it. Real life caught up with me, unfortunately.
I'll try to get it done.
Maybe my text fragment below is usable.
From: David Korn <yyy@xxxxxxxxxxxxxxxx>
> Everybody supports #! - why not standardize it?
I don't support #! because it puts absolute pathnames
inside scripts.
It need not. Some Unix flavours allow #!perl.
------------------------------------------------------------------
How does one find perl?
(i) ugly tricks like
: # -*- Perl -*-
eval 'exec perl -w -S $0 ${1+"$@"}'
if 0;
(ii) agreeing on some path
(iia) agree that perl is in /usr/bin/perl :-)
(iib) have a directory /interpreters with symlinks
(iic) a nice and rather portable solution: write
#!/usr/bin/env perl
Here one needs only to agree on the single path /usr/bin/env.
(iii) view shell scripts as just some type of binary, where there exist
things for the a.out loader, for the ELF loader, for the java interpreter,
but also things for sh, csh, awk, perl, python, wish, expect, ...
These binaries are recognized by their first few bytes, and the system
recognizes things starting out #!/usr/local/bin/perl as a perl binary
and invokes perl (which happens to live in /usr/bin/perl).
On Linux this works (for suitable kernels):
echo ':perl:M::#!/usr/local/bin/perl::/usr/bin/perl:' \
> /proc/sys/fs/binfmt_misc/register
(iv) make sure execlp does the right thing.
------------------------------------------------------------------
Strawman proposal for a fragment of text for the description of exec.
The <I>exec</I> functions replace the current process image with
a new process image. There is no return from a successful <I>exec</I>,
because the calling process image is overlaid by the new process image.
This new process image is either constructed directly from the
file identified by the first argument to the <I>exec</I> function
or is the process image of an interpreter invoked in order to
execute the file.
When a compiled C-language program is executed as a result of this call ...
...
The arguments specified by a program with one of the <I>exec</I>
functions are passed on to the new process image in the corresponding
<I>main</I>() arguments.
When the first argument to the <I>exec</I> function is a text file
starting with the two symbols #! then its first line is parsed
according to
#![<whitespace>]<interpreter name>[<whitespace><string>]
(where the square brackets indicate an optional part and
<interpreter name> does not contain whitespace)
and the interpreter identified by <interpreter name> is invoked
as if by the same <I>exec</I>-type function, with arguments
<I>narg0</I>,... (or argument array <I>nargv</I>[]) determined as follows.
<I>narg0</I> is set to <interpreter name>.
If <string> is present, <I>narg1</I> is set to <string>.
The next argument is set to the first argument (<I>path</I> or <I>file</I>)
the <I>exec</I> function was invoked with.
The remaining arguments are set to the arguments (if any)
following the <I>arg0</I> of the original call.
The <I>arg0</I> of the original call is discarded.
If the process image is not recognized as a valid executable object,
<I>execlp</I>() and <I>execvp</I>() use the contents of that file
as standard input to a command interpreter conforming to <I>system</I>().
In this case the command interpreter becomes the new process image.
The argument <I>path</I> points to a pathname that identifies
the program to be executed.
The argument <I>file</I> is used to construct a pathname that identifies
the program to be executed. If the <I>file</I> argument contains a slash
character ...
Andries
|