>From: yyyyyyyyyyyyyyy@xxxxxx
>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)
How about having /etc/interpreters with a list of valid interpreters:
sh /usr/bin/sh
perl /opt/local/bin/perl
...
and allowing either absolute path names (legacy mode) or simple fileenames
(e.g. "perl") which then must mach an entry in /etc/interpreters.
/etc/interpreters in this case must be read by the kernel but I don't think
that it should be a real problem. Solaris e.g. already reads /etc/name_to_major
and similar.
So a script starting with
#!/usr/local/bin/perl
might not run because /usr/local/bin does not exists.
A script starting with
#!perl
would call /opt/local/bin/perl
and a script starting with
#!somebin
would be declared illegal.
Jörg
EMail:yyyyy@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
yy@xxxxxxxxxxxxxxx (uni) If you don't have iso-8859-1
yyyyyyyyy@xxxxxxxxxxxx (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
|