running perl scripts on U6000/50
Quote:
>> Hi - I've installed PERL 4.00 on a Unisys 6000/50 (Convergent Technologies)
>> (AT&T SV.3.2) system, and have a problem: I can't run perl scripts in the
>> usual ways:
>> -> putting #!/bin/perl at the top of the script doesn't work - it gets
>> run as a /bin/sh script instead.
>> -> putting : use /bin/perl at the top gives the same result.
>> -> setting SHELL=/bin/perl and doing either of the above does the same thing.
>> => only 'perl <scriptname>' will actually run a perl script, ANY perl
>> script. That's the only way, and that's not acceptable for me.
>Pete also called the Unisys suppport center with this question, and just
>happened to reach me. I'm one of about 3 Unix analysts with net access,
>although hopefully this will change in the not-too-distant future.
>I tried the #! contruct on all the systems I could get my paws on. I
>created a two-line file:
> #! /bin/csh
> setenv TERM vt100
>...and ran it as an executable under the Bourne shell (substituting the
>correct path to csh where appropriate). The results, to let you know:
>Unisys 5000/55 running 3.00.01, an SVR3: it worked
>Unisys 5000/70 running Centix, an SVR3: it failed
>Unisys 5000/95 running 6.03, an SVR3: it failed
>Unisys 6000/55 running 3.00.12.15, an SVR3: it failed
>Unisys 6000/65 running SVR4: it worked
>Unisys 7000/40 running 3.00.01, a mutant SysV/BSD combo: it worked
>SCO ODT 1.0 with almost no patches: it failed
>I guess the question boils down to one of standards. Does anyone know
>whether this construct is a documented standard, an accepted convention, or
>just a gentleman's agreement?
>BTW, I'm happy to say that in this particular case I actually DO speak for
>the company, although I'm speaking through my own channels (this public
>access system), not the company's. It's the opposite of most net.posts, eh?
I believe the command interpreter notation is a BSD-ism commonly found in
BSD-4.x, SunOS, and any other Berkeley derived UNIX. The majority of Unisys
UNIXes were derived from AT&T System V code and therefore don't understand
the interpreter notation. Therefore, the 6000/7x8x running Dynix, the
6000/35/65s running SVR4, and the 7000s running CCI's variant of BSD 4.2
will understand "#!". 6000/10/3x/5xs running SVR3 (2.20-3.00.13),
S series running CTIX, and 5000s running SVR2&3 should not understand "#!".
I don't know why the 5000/55 under SVR3 understands "#!"; its probably
something NCR added.
In SVR4, and presumably BSD and SunOS, the command interpreter notation
is detected and acted upon by the kernel exec routine (intpexec). The "#!"
is a "magic" number the kernel understands, just like the magic numbers
for COFF and ELF executables. The "#!" notation is documented in
exec(2) [SVR4/BSD derivatives only].
The ":use " notation will not work within sh (or csh) since ":" is the
null statement token. Everything after the ":" to the newline is ignored.
The colon's behavior is documented in sh(1).
Setting SHELL equal to "/usr/bin/perl" shouldn't work either. To my
knowledge, SHELL is not used by the actual shell, that is, when sh
spawns a new shell via exec or the explicit subshell tokens "(" and ")",
it does not consult SHELL. The SHELL variable is used by editors (vi, emacs),
mailers (elm), news readers (rn), and other interactive applications
for "shell escape" options.
An interesting aside is that the csh determines whether a script should
be run under "sh" or "csh" by looking at the script's first character.
If the first character is a "#" the script should be run under "csh",
otherwise it should be run under "sh". Therefore,
: use /foo/bar
TERM=vt100
vi fred
will run under "sh" while
# use foo/bar
TERM=vt100
vi fred
will run (and produce an error) under "csh". This is confusing!
Doesn't "#! /usr/bin/perl" begin with a "#"? Well, yes... The shells
(csh and sh) first try to run scripts via exec(filename...). If exec
fails (ie. the kernel doesn't see a "#!" on the first line), then the
shell takes over and tries to run the script itself. In the case of csh,
it looks at the first character and either runs "csh" or "sh". The Bourne
shell doesn't even bother to look at the first character, it just executes
statements.
Short term solutions (hopefully SVR4+ is the long term solution):
1. Start interpreter scripts with the interpreter (eg. perl -f perl-script).
2. Encapsulate the interpreter scripts in a Bourne shell script (eg.
: /sbin/sh script
/usr/bin/nawk '$1 ~ /foo/ { print "foo",$0 }
$1 ~ /bar/ { print "bar",$0 }' $1).
Hope this was helpful.
- Erik
Erik Sean Nolte
Product Integration
Unisys Corp., Salt Lake City, UT