SCRIPTDIR: is it used?
Paul Slootman
various machines here. On a SCO Xenix 386 system, I was wondering
how to get perl scripts installed in SCRIPTDIR to work ('#!/usr/lbin/perl'
doesn't work, neither does ':use /usr/lbin/perl'). I thought that
having defined SCRIPTDIR, I could invoke perl with the name of the
script I want executed, and perl would be able to find it. But, alas,
it doesn't work. I then wondered what SCRIPTDIR is used for:
$ grep -l SCRIPTDIR *
config.H
config.h
config_h.SH
It doesn't get used anywhere! Is this right? What are the plans for
SCRIPTDIR, then?
One more point: on one of the systems here, there *is* a sys/socket.h,
but no netdb.h (i.e. sockets can be used, but there is no networking :-(
This causes doio.c to barf. This is something that may be rare, but
nevertheless could be fixed relatively easily in Configure, I suppose.
--
----------------
:sloo...@dri.nl : When you get to the point where you think that nothing
:+ 31 5496 88831 : is impossible, try pushing toothpaste back into a tube
----------------
Bill Campbell
>I've finally got round to bringing perl up to patchlevel 10 on the
>various machines here. On a SCO Xenix 386 system, I was wondering
>how to get perl scripts installed in SCRIPTDIR to work ('#!/usr/lbin/perl'
>doesn't work, neither does ':use /usr/lbin/perl'). I thought that
>having defined SCRIPTDIR, I could invoke perl with the name of the
>script I want executed, and perl would be able to find it. But, alas,
>it doesn't work. I then wondered what SCRIPTDIR is used for:
I've messed around quit a bit to get a working header for SCO
Xenix and perl. This is what I've found works reliably
-------cut--cut---
:
#!/usr/local/bin/perl
eval ' exec /usr/local/bin/perl -S $0 "$@" '
if $running_under_some_shell;
shift if(join("", @ARGV) eq ""); # Xenix Kludge
----end--end
The "$@" makes multi-word arguments like -s "SUBJECT LINE" work
properly. If you use $* these get broken into individual
arguments and getopts doesn't work properly.
The shift is necessary to make things work properly when using
getopts.pl. Without it when(<>) {...} doesn't work if there
aren't any arguments. It says 'cannot open :' if you try to read
from the standard input.
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591
Larry Wall
: I've finally got round to bringing perl up to patchlevel 10 on the
: various machines here. On a SCO Xenix 386 system, I was wondering
: how to get perl scripts installed in SCRIPTDIR to work ('#!/usr/lbin/perl'
: doesn't work, neither does ':use /usr/lbin/perl').
Xenix doesn't recognize the shebang (#!) magic number. The ":use" is
merely a comment to sh, and has no special meaning to any OS anywhere.
People have thought that, since Configure sometimes puts that at the
front of a script, it must be a magical incantation, but it isn't.
Getting a Perl script running in any context under Xenix is a bit of a
pain, since Xenix is a one-word oxymoron. But the following
incantation ought to work. It's a four-language hack (counting SCO csh
as a fourth language because it (blech!) reverses the meanings of ||
and &&--see the "true" line below):
#!/usr/lbin/perl
"true" || eval 'exec /usr/lbin/perl -S $0 $argv:q';
eval '(exit $?0)' && eval 'exec /usr/lbin/perl -S $0 ${1+"$@"}'
& eval 'exec /usr/lbin/perl -S $0 $argv:q'
if $running_under_some_shell;
This guarantees that perl gets executed eventually, whether the script
is started via #!, or starts running under any of sh, csh, SCO csh or perl.
No, I'm not going to explain it. If you can't figure it out, you didn't
want to know anyway... :-)
You can write a script to insert this gobbldygook at the front of
another script, to save wear and tear on your keyboard. See the eg/nih
program for a more simpleminded example.
: I thought that
: having defined SCRIPTDIR, I could invoke perl with the name of the
: script I want executed, and perl would be able to find it. But, alas,
: it doesn't work.
Perl doesn't generally have to look for scripts, since you either say
perl FILENAME
or you use the shebang notation, which also passes the filename of the
script to perl as the first argument. SCRIPTDIR isn't useful for
this--you're kind of thinking of it inside out. In general, the
problem isn't for perl to find the script, but for the script to find
perl. Hence the #! gizmo specifies where perl is, on systems that
support it.
And scripts can be anywhere. Why should perl limit itself to executing
scripts in SCRIPTDIR?
: I then wondered what SCRIPTDIR is used for:
:
: $ grep -l SCRIPTDIR *
: config.H
: config.h
: config_h.SH
:
: It doesn't get used anywhere! Is this right? What are the plans for
: SCRIPTDIR, then?
SCRIPTDIR is merely the cpp symbol corresponding to the shell variable
$scriptdir, set in config.sh. It's there for the convenience of any
package that happens to want to copy scripts into a standard location.
Perl itself has no desire to copy scripts into a standard location, so
it doesn't use it. Some of the installation scripts are more likely
to use it, but even in this case, there's a separate variable for
where to actually install the scripts, and that's more likely to be used.
The $scriptdir variable is where the scripts actually reside, in case
the installation programs wanted to test to see if there was already
one there. The perl installation scripts don't bother.
: One more point: on one of the systems here, there *is* a sys/socket.h,
: but no netdb.h (i.e. sockets can be used, but there is no networking :-(
: This causes doio.c to barf. This is something that may be rare, but
: nevertheless could be fixed relatively easily in Configure, I suppose.
It's a never-ending battle. Configure is a lieutenant with good
tactics trying to cover for the generals' bad strategy...
[Unfortunately, the generals' stratagy is to let the current army rot,
and raise their standards over in the next county. Those of us trying to
organize an orderly retreat of the old army now have to fight on more
fronts...]
Larry
Ronald S H Khoo
> sloo...@dri.nl (Paul Slootman) writes:
> It's a four-language hack (counting SCO csh
> as a fourth language because it (blech!) reverses the meanings of ||
> and &&--see the "true" line below):
Actually, that not quite right. Chris Torek once explained how
the return value got misplaced from the BSD 2.8 (???) csh, from which many
System V csh's are derived (probably because it was "too hard" to remove
job control from the 4BSD csh :-) but I can't remember Chris's explanation,
nor can I find a copy of his posting :-(
Anyway, simply swapping the || and && operators in the binary doesn't help.
I've tried. The correct fix is probably to install tcsh 6.00 as /bin/csh.
Hm. That's a good idea.
> "true" || eval 'exec /usr/lbin/perl -S $0 $argv:q';
This won't work either. 2BSD csh doesn't seem to have had eval:
script 'typescript' started on Tue Aug 13 13:44:54 BST 1991
% true || eval 'exec /bin/echo hello'
eval: Command not found.
% script 'typescript' ended on Tue Aug 13 13:45:43 BST 1991
(This typescript was generated on a box running SCO Unix System V/3.2)
--
Ronald Khoo <ron...@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
Larry Wall
: Anyway, simply swapping the || and && operators in the binary doesn't help.
: I've tried.
So have I. :-(
But I was referring to the symptoms, not the cause. Effectively, the
meanings of || and && are reversed.
: The correct fix is probably to install tcsh 6.00 as /bin/csh.
: Hm. That's a good idea.
:
: > "true" || eval 'exec /usr/lbin/perl -S $0 $argv:q';
:
: This won't work either. 2BSD csh doesn't seem to have had eval:
Okay, change that line to
"true" || exec /usr/lbin/perl -S $0 $argv:q;
It appears that it's okay to interpolate the non-existent $argv under the
other shells. It's only csh that gets upset at sh's ${1-"$@"}, not the other
way around.
Larry
Larry Wall
: In <1991Aug7.1...@dri.nl> sloo...@dri.nl (Paul Slootman) writes:
:
: >I've finally got round to bringing perl up to patchlevel 10 on the
: >various machines here. On a SCO Xenix 386 system, I was wondering
: >how to get perl scripts installed in SCRIPTDIR to work ('#!/usr/lbin/perl'
: >doesn't work, neither does ':use /usr/lbin/perl'). I thought that
: >having defined SCRIPTDIR, I could invoke perl with the name of the
: >script I want executed, and perl would be able to find it. But, alas,
: >it doesn't work. I then wondered what SCRIPTDIR is used for:
:
: I've messed around quit a bit to get a working header for SCO
: Xenix and perl. This is what I've found works reliably
: -------cut--cut---
: :
: #!/usr/local/bin/perl
: eval ' exec /usr/local/bin/perl -S $0 "$@" '
: if $running_under_some_shell;
: shift if(join("", @ARGV) eq ""); # Xenix Kludge
:
: ----end--end
:
: The "$@" makes multi-word arguments like -s "SUBJECT LINE" work
: properly. If you use $* these get broken into individual
: arguments and getopts doesn't work properly.
:
: The shift is necessary to make things work properly when using
: getopts.pl. Without it when(<>) {...} doesn't work if there
: aren't any arguments. It says 'cannot open :' if you try to read
: from the standard input.
That's because of a standard bug in sh. The standard workaround is
to say ${1+"$@"}. Then you don't need the shift. But it still won't
work under csh...
Larry
Larry Wall
: Okay, change that line to
:
: "true" || exec /usr/lbin/perl -S $0 $argv:q;
:
: It appears that it's okay to interpolate the non-existent $argv under the
: other shells. It's only csh that gets upset at sh's ${1-"$@"}, not the other
: way around.
Urk. That's not legal Perl, which is the point of all this. Sigh.
No eval, eh? I'm inclined to agree with you--the way to fix SCO csh is
to install a different csh.
Larry
Ronald S H Khoo
> Urk. That's not legal Perl, which is the point of all this. Sigh.
Sigh. In fact, Doug Gwyn's comment in an earlier incarnation of this
thread seems to me to be correct: don't use #!, let /bin/sh execute
whatever interpreter for you. However, there is a problem.
Perl currently *requires* #! on the top line if you have it setuid and
you say perl -S. Larry, what about a compromise? Allow the #! line to
come on line 2 iff line 1 contains only a : or : use /bin/sh ?
> No eval, eh?
Nope. I believe the reason for this is the lack of eval in v6 /bin/sh,
which was the basis for csh. Not that I ever used v6, so I can't confirm
this ...
> I'm inclined to agree with you--the way to fix SCO csh is
> to install a different csh.
Hey, it's nothing to do with SCO. Most System III/System V (R < 4)
machines that have csh at all have this ancient 2BSD csh. SCO just
pass it on, and being the most ubiquitous peecee unix, tends to get
noticed a bit. So PLEASE stop bashing SCO for this, Larry ?
There's plenty of things that *are* their fault, but this ain't one of them.
Fortunately, tcsh is now freely available, and does work on SCO, so we're OK.