Jan-Benedict Glaw [off-list ref] writes:
My personal oppinion is to call perl scripts as `perl foo.pl' and thus
let the user decide (by means of setting $PATH) which perl incarnation
she wants to use.
Sounds sane, and I was wrong.
We should be able to do that for perl (we cannot in general do
that for GNU tools since some people seem to like renaming them
from foo to gfoo).
Michal, is there a reason you do not want to have the version of
perl you teach git tools via #! lines with PERL_PATH on your $PATH?
Hello,
On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
Michal, is there a reason you do not want to have the version of
perl you teach git tools via #! lines with PERL_PATH on your $PATH?
I have no problem with that. I can set $PATH.
But then I'd suggest to change magic #!
from #!/usr/bin/perl
to #!/usr/bin/env perl
for *.perl
It that what you meant?
M.
PS: Please note that
#!/usr/bin/env perl -w
will not work on some platforms (at least on HP-UX)...
--
Michal Rokos
NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone: +420 267 224 311
fax: +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
quoted
quoted
quoted
quoted
"Michal" == Michal Rokos [off-list ref] writes:
Michal> I have no problem with that. I can set $PATH.
Michal> But then I'd suggest to change magic #!
Michal> from #!/usr/bin/perl
Michal> to #!/usr/bin/env perl
Michal> for *.perl
Michal> It that what you meant?
No, don't do that. Use the path to Perl that they chose during
configuration because
(a) it might not be the first one in PATH
(b) even if it's the first one in *my* path, it might not be the
first one in *everyone's* path
(c) env requires an *extra* fork/exec
(d) some systems don't have env
The env hack is a nice hack, but it's just a hack. Don't
rely on it when the right thing is nearby.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[off-list ref] <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!
On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz [off-list ref] wrote:
quoted
quoted
quoted
quoted
quoted
"Michal" == Michal Rokos [off-list ref] writes:
Michal> I have no problem with that. I can set $PATH.
Michal> But then I'd suggest to change magic #!
Michal> from #!/usr/bin/perl
Michal> to #!/usr/bin/env perl
Michal> for *.perl
Michal> It that what you meant?
No, don't do that. Use the path to Perl that they chose during
configuration because
(a) it might not be the first one in PATH
If you want to execute some binary that's not first in path, you'd
better *always* call that explicit.
(b) even if it's the first one in *my* path, it might not be the
first one in *everyone's* path
Communication problem. Machine's administrator should offer a working
git installation. If a user chooses to build his own git, he'd better
make sure that all the environment is properly set-up, too.
(c) env requires an *extra* fork/exec
Only an extra exec.
(d) some systems don't have env
Huh? Show me a system that has no /usr/bin/env, but a working POSIX
shell in /bin/sh .
The env hack is a nice hack, but it's just a hack. Don't
rely on it when the right thing is nearby.
What's the right thing? The right thing is to explicitely call the
interpreter, not using the shellbang at all.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));