rm55+@andrew.cmu.edu (Rudolph T. Maceyko) (05/08/90)
Hi. I'm trying to use PERL in a multiple-machine (VAX, rt, sun) environment, same OS, though (Andrew, if you know it). Anyway, because of symlink resolution and kernel limits on #! pathnames, my PERL scripts began with #!/bin/csh -f eval "exec /usr/contributed/bin/perl -S $0 $*" if $running_under_some_shell; Well, after patchlevel 15 was installed, all of my scripts began to hang, without doing anything (i.e., no output). I have nothing to do with installing PERL here, by the way. Anyway, it seems that PERL is looking at the "magic number" when it shouldn't be. Actually, it's not only LOOKING, but EXECUTING the pathname as if it were the KERNEL! #!/bin/csh -fx reports an infinite loop of exec'king. What reasoning was behind this change, or, if it wasn't changed, why isn't this implemented intuitively (kernel looks at magic number, PERL ignores it -- it's a comment)? Anyway, the change occurred after an upgrade from 8 to 15. The "fix" is to remove the #! altogether and let the evel "exec ..." / if $running_under_some_shell; do its trick from the shell. Still PERL shouldn't play with the #! line -- how does it know when to stop? Rudy +---------+ : +-----+ : Rudy Maceyko : : +-+ : : rm55+@andrew.cmu.edu : : : +-+ : rtmst@unix.cis.pitt.edu +-+ +-+-+-+
tytso@athena.mit.edu (Theodore Ts'o) (05/09/90)
From: rm55+@andrew.cmu.edu (Rudolph T. Maceyko) Date: 7 May 90 18:08:01 GMT Hi. I'm trying to use PERL in a multiple-machine (VAX, rt, sun) environment, same OS, though (Andrew, if you know it). Anyway, because of symlink resolution and kernel limits on #! pathnames, my PERL scripts began with #!/bin/csh -f eval "exec /usr/contributed/bin/perl -S $0 $*" if $running_under_some_shell; Yup, my scripts used to do the same thing, for the same reason. (It's nice to know I'm not alone....) When I commented about this (in this very forum), I got back comments of "fix your kernel" (hah!) and "that's gross don't do that". I am told that the reason why perl does this is because of some obscure security reason.... If you don't believe me, try this: "perl <name of bourne shell script>" and watch perl use /bin/sh as the interpreter of the shell script. Granted this is a nice feature, but if I invoke "perl perl_script", I generally want perl to be the interpreter --- no questions asked. How about 'perl "-Yes, I Really Want To Use Perl" perl_script'? :-) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!
tneff@bfmny0.UU.NET (Tom Neff) (05/09/90)
I see people's problems, but I CAN'T BELIEVE it's not possible to install Perl somewhere with a shorter name on sites with this kernel limitation! I mean, what makes Perl so special? Any interpreter on such a system is going to have this problem if people see fit to install it in /some/longwinded/directory. At all events you DO have the source, why not just comment out the part that does it, for private use at your site? Look at lines 245-281 in toke.c. [Not speaking for Larry on this at all, just MHO]
rm55+@andrew.cmu.edu (Rudolph T. Maceyko) (05/10/90)
Here's one for you. Say I have a PERL script which begins with #!/short/path/to/perl ;-> ... Does PERL get invoked TWICE in order to execute the script? Once from the kernel, and once again by PERL? And, if so, how does PERL know when to stop, since it'll see the #! again? Rudy +---------+ : +-----+ : Rudy Maceyko : : +-+ : : rm55+@andrew.cmu.edu : : : +-+ : rtmst@unix.cis.pitt.edu +-+ +-+-+-+
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (05/10/90)
In article <saG7MtO00WB40Nw3NM@andrew.cmu.edu> rm55+@andrew.cmu.edu (Rudolph T. Maceyko) writes:
: Here's one for you. Say I have a PERL script which begins with
: #!/short/path/to/perl ;-> ... Does PERL get invoked TWICE in order to
: execute the script? Once from the kernel, and once again by PERL?
: And, if so, how does PERL know when to stop, since it'll see the #!
: again?
Well, it seems obvious from its current behavior that it has to stop some
time, so it might as well stop before the first extra exec...
I quote the following three lines from toke.c for your amusement:
if (line == 1) {
if (*s == '#' && s[1] == '!') {
if (!in_eval && !instr(s,"perl") && instr(origargv[0],"perl")) {
Larry