Henry B. Hotz wrote:
> At 9:54 AM -0800 2/13/98, Colin Wood wrote:
> >Bill Studenmund wrote:
> >> On Mon, 9 Feb 1998, Fabiano Petrone wrote:
> >> > 1. I've tried a simple pipe like "who | wc -l" and it works OK. I've saved
> >> > this pipe in a file on /root/pub (call it "file") and I've chmoded it as
> >> > executable with "chmod +x file".
> >> > well, the problem is that when I call "file" from the prompt #, the system
> >> > respond "file : not such command" : why?
> >>
> >> The top line of a shell script (your command) needs to be "#! /bin/sh".
> >> Actually, it can be /bin/csh or /bin/tcsh or /bin/ksh as you wish (or even
> >> #! /usr/local/bin/perl for a perl script). But you have to stick the
> >> command which runs the script in the top line. You didn't do that, so the
> >> system's confused.
> >
> >Actually, the error he's getting in this case is a result of not having
> >/root/pub in his path.  I believe that Unix systems are defined to use
> >/bin/sh as the interpreter for executables which they cannot figure out a
> >magic number.  At least, it certainly works that way on my AIX machine
> >here at work.
> 
> I thought both you guys knew this so maybe I'm wrong.
> 
> Executable files are handled by the current shell (usually csh for netbsd,
> but usually sh for system scripts on other systems).  All standard, current
> unix shells are programmed to look for a special format comment line at the
> beginning of any script and if it points to a valid shell to switch to that
> shell instead of processing the script themselves.

Actually, I'm pretty sure that all the shell does is pass it's arguments
to exec() once it's handled all the shell metacharacters.  The actual
deciphering of the magic number and the handoff to an interpreter (if its
a text file instead of an excutable binary) is handled by exec(), which is
either implemented in a library or the kernel itself (I don't know which
without checking the source, but I think it's in libc under NetBSD).
Looking at the source for /bin/sh, it appears to support doing the
interpretation itself if it's not built into the kernel.  I'm pretty sure
we have it built into the kernel (via execvp()).  Someone please correct
me if I'm wrong.

> Since the test case he used is valid in any standard Unix shell he probably
> doesn't have "." in his $PATH.  (Maybe he read that warning about not
> having "." in the root path and did something about it!)

Well, in this case, he didn't say that he was in the /root/pub directory,
so I didn't assume that ./file would work.  Do we ship with "." in root's
path by default?

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.