On Thursday, August 15, 2002, at 06:21 , Kee Hinckley wrote:
[..]
> Of course this kind of solution is inherently dangerous given that
> /usr/bin/perl and /usr/local/bin/perl may be different versions for good
> reasons, and letting the interpreter executed depend on a user's path can
> get you in trouble.
I can understand why 'developers' will want to have
'multiple instances of perl' floating around on
their machine - and one way would be to do this
with the split between the prefix /usr/local and /usr.
{ I would argue against such a strategy - and advocate
the older path of /usr/unsupported - IF one needs to
have a 'commonly shared' 'development environment'. }
but I am not at all sure that this is a reasonable
approach of 'production servers/hosts' - where the
'currently supported releases' should 'just work'
for 'the user community'.
As such, keeping /usr/bin/perl and /usr/local/bin/perl
as the same - either by hard link or symbolic link -
would save a lot of heartache for users and the IT staff.
This approach also saves on the problem of using scripts that
were originally rigged with
#!/usr/bin/perl
#!/usr/local/bin/perl
and not having to worry about backward compatibility.
{ I accept that we still have some 'port forward' issues
from macPerl into the OSX way.... }
{ sub_text - yes, IF one has perl4 code - it should
explode into flames, scream and DIE, and you should
just replace it... this will be true when the developers
are about to release Perl7 and we all speak of these
as the Golden Days of Perl5... }
ciao
drieux
---
