>>>>> "Chris" == Chris Devers <[EMAIL PROTECTED]> writes:
Chris> My understanding is that the Python idiom is to avoid putting the full Chris> path, in favor of something like Chris> #!/usr/bin/env python This won't work if env is not in /usr/bin (like say, /bin/env). Chris> #!env python This won't work if env is not in your current directory! (odds on that, 0% unless you're cd'ed to /usr/bin or /bin, see above.) The problem is that #! is a low-level action. I actually dislike the way "env" is bandied about as the solution. One problem is that while Perl may be in *my* PATH for an unusual location, it's not neccessarily in *your* PATH. And it may not even be the same Perl! I have four versions of Perl installed on my laptop here, and depending on how my PATH is shuffled, I'll get an entirely different version of Perl. (This is the same problem with depending on the PERL5LIB env variable. You should put "use lib" *in* the program instead.) Another problem is that it's a double fork... the kernel launches env, and env launches Perl... *every* time. For a command launched once per day, no biggy, but imagine a CGI script launched 10 times a second. If you use Makefile.PL to install your script, you can simply put #!perl on the first line, and that'll be *rewritten* at install time to be the "right thing" to launch the same Perl that launched your Makefile.PL. Very cool. More people should use this. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
