Re: Execing perl?

[Paul D. Smith]

Final notes.  Further discussion via private email, or Perl lists,
please.

%% prj@po.cwru.edu (Paul Jarc) writes:

  pj> You don't care where perl is installed.  You care whether a single
  pj> path is *a* (not *the*) name of perl, on all systems.  So on each
  pj> system, create a /command directory, and put a symlink to perl
  pj> there.  Then use #!/command/perl in your scripts.

I can't do that.

  pj> (This won't help for systems you don't control, but I don't know
  pj> whether that matters.)

It definitely matters... it's the whole point.  I already have a
single well-known directory that works cross-platform for systems I
control.  It's all the rest that are the problem.

I want to write a single script, which appears at some (but not the
same) location on the filesystems of users all over the company (read:
the world), via the magic of NFS or rsync.

Most sites have Perl installed in different places: some in /bin, some
/usr/bin, some in /usr/local/bin, some in /usr/global/bin, some in
/opt/perl-5.6.0/bin, some in even more obscure places.

I simply cannot force desktop users and local system admins all over the
world, some of whom I've never even heard of (we have an anonymous rsync
server to distribute these things--I don't even know all the people who
might be downloading them, or where they put them locally) to rebuild
all their tools for my convenience.  Likewise, I'm certainly not going
to undertake to find the systems necessary to build Perl for all these
platforms and distribute the binaries myself--that defeats the purpose.

It's just about all I can manage to get them to put both the directory
with my scripts and the directory with their local Perl in their PATH at
the same time... anything more complicated than that is out of the
question.

  >> How frustrating!  Other interpreters all have straightforward ways of
  >> doing this.

  pj> Such as?  This problem doesn't depend on the interpreter; a script
  pj> has to have *some* absolute path in the #! line.  Using /bin/sh is
  pj> still using an absolute path of an interpreter.

Yes, but /bin/sh appears on every UNIX system.  /usr/bin/env looks OK,
too, but I'm not sure.

You can easily do this with Tcl, etc: you simply need some way to have a
command that looks like a shell exec command to the shell, but is
ignored by the script.  There are various tricky ways to make this work,
depending on the language.

The thing that causes this to break is Perl's attempt to support sh-bang
on systems that don't otherwise support it (combined, I guess, with the
Linux kernel's unique way of parsing sh-bang arguments).  If Perl didn't
have that weird behavior when the word "perl" doesn't appear on the
first line of the script, it would work fine.


After poking around on the web (knowing that the problem was with Linux
in particular gave me a different Google search text) I found this
stanza on a Perl intro page from Cal Tech (which, by the way, also makes
the mistake of blaming bash for this problem--I'll email the author),
and this appears to work on all the systems I've tried it on:

  #!/bin/sh
  #! -*-perl-*-
  eval 'exec perl -x -wS $0 ${1+"$@"}'
    if 0;

The trick is using two lines _plus_ the -x option, which see in "man
perlrun".

Not sure if this is Bash FAQ material or not: it's not really a Bash
issue but due to the circumstances (Linux being the only UNIX that uses
Bash as its /bin/sh) it seems to be a common mistake to blame Bash.


%% William Bloom <william.bloom@pegs.com> writes:

  wb> Trying to build and distribute Perl scripts without
  wb> knowledge of the target system's real Perl path is a problem
  wb> that Perl package developers have met and, happily, dealt
  wb> with already.  Grab almost any Perl package from
  wb> ftp.cpan.org, unarchive it, study the Makefile.PL (whose
  wb> contents follow a standard convention), and you'll see how
  wb> it's done.

I've written many Perl packages, including ones thousands of lines long
containing 15+ distinct Perl OO classes, using sockets for
client/server, DBI/DBD, etc.  I know Makefile.PL.

That is not a solution.  I don't have any access to 99.9% of the systems
involved.  The people using the scripts mostly don't have any special
privileges on their workstations.  The IS folks have no use for or
interest in installing these tools in general.  That leaves it (in your
scenario) up to everyone to individually run the installer and put the
results in their own directories.  That also means every time a new
version is released, all those users have to rebuild and re-install.
Many of the people using the scripts are logging into UNIX workstations
from the NT systems on their desktops, and wouldn't know Perl from a
hole in the wall.

And, of course, there is not just one script and one package, but
many... I can either distribute them separately and have that mess, or I
can bundle them all up and be making a new release every two days for
some script change or another... that everyone then has to install.

It's great that you have a sufficiently technical and responsive user
base (or sufficiently static packages) that you can require them to
build all the packages themselves and that works for you, but that isn't
the case here :(.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.