From: Paul D. Smith (pausmith@nortelnetworks.com) Subject: Re: Execing perl? Newsgroups: gnu.bash.bug Date: 2001-07-11 14:30:16 PST 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 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 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.