exec() with executable shell scripts

[Guy Harris]

>Bingo.  When exec() is invoked, it expects to find a "magic number" in the
>beginning of the file somewhere that identifies to the kernel that this is
>something that can be loaded into core and be executed directly by the
>processor.

Correct.  Some more modern UNIX systems do, however, have a magic
number, namely "#!", that tells the system "the rest of this line is a
pathname of an interpreter program, such as a shell, and an
optional argument; run *that* program and give it the name of *this*
file as an argument, after the optional argument if it's present."  This
allows you to "exec" shell scripts, "awk" scripts, Makefiles, "ftp"
scripts, etc. (and, if you're feeling *REALLY* perverse, edit files by
typing their name as a command...).

>When shell scripts are invoked, the shell must be exec'ed somehow
>to interpret the text in the file.

Yup.  On systems with "#!", this can be done by using it; the pathname
of the shell is in the "#!" line (e.g., "#! /bin/sh").  On systems
without "#!", this is generally done by having the code that calls
"exec" recognize the ENOEXEC error (which says "well, you had all the
right permissions to run this file, but it doesn't have a magic number)
and then "exec" the shell, handing it the name of the script as an
argument.

>I believe that the one exception on most systems is the case where the
>file length is zero, whereby the process just returns the true exit
>status.

Nope.  No UNIX system I know of makes such an exception; the reason a
zero-length file can be executed by the shell is that the shell uses the
ENOEXEC trick listed above.

>I notice that true on a SysV system is length zero.

Not in later versions; it's filled up with a humongo copyright notice
that looks *REALLY SILLY*, given that the entire file consists of its
copyright notice!