On Fri, 2 Dec 2005, Adriano Ferreira wrote:
> What's the rationale for hardwiring the Perl executable pathname into
> the Perl interpreter? It is some oddity to guarantee Perl can find its
> library via a relative path? Is it a safety thing?
Yeah, basically.
Historically, Unix users could depend on a copy of Perl in /usr/bin from
their vendor, and maybe a custom-installed one somewhere like /opt/bin
or /usr/local/bin. With that in mind, using one of those paths usually
would do something useful.
My understanding is that the Python idiom is to avoid putting the full
path, in favor of something like
#!/usr/bin/env python
#!env python
on grounds that Python may not be quite as common, but you could depend
on the `env` command being available, so as long as `python` was in the
$PATH somewhere, invoking it this way should work. That makes sense, but
now that I think about it I'm not clear why they don't just use
#!python
which seems like it should amount to the same thing.
Anyway, there isn't anything stopping you from doing the same sort of
thing with your Perl scripts, but, out of habit as much as anything
else, this isn't how most Perl hackers write their code. I don't see
much harm in it though, and I could picture it making some scripts more
portable if they're going to be running on systems where you can't
depend on a copy of the Perl binary being in one of the usual places.
--
Chris Devers
zOm
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
