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 ---