[Pdx-pm] [csieh at fnal.gov: Re: Horribly Broken RHEL5/SL5 Perl]
J. Shirley
jshirley at gmail.com
Tue Aug 26 14:59:41 PDT 2008
On Tue, Aug 26, 2008 at 2:41 PM, Greg Petras <gpetme at gmail.com> wrote:
> On Tue, Aug 26, 2008 at 1:52 PM, J. Shirley <jshirley at gmail.com> wrote:
> [snip]
>> And then when you want to run or change your perl for your application
>> in a controlled manner, you modify your paths in every script? If you
>> happen to miss one, you run an inconsistent environment?
>
> This is what QA and controlled builds are for, no? I guess it could be
> argued either way - either put the path to the perl interpreter in
> your build scripts or put the profile settings in the build scripts.
> Is env "how it's done"? I'm relatively new to Perl (last 5 years), so
> it'd be nice to hear from some others on how they do things.
>
(Sorry for the spam, Greg! I'm used to ml's setting reply-to... *thin excuse!*)
If QA can catch everything, sure. I wouldn't bet on it. Controlled
builds should setup the proper production environment, which could be
a single-use, version specific perl build plus modules:
/opt/Application-$VERSION/bin
Then you setup your PATH = be that, and you don't have to do any
monkeying around. Again, the usefulness of this only shines when you
-need- multiple perls. When that need arises, /usr/bin/env can't be
beaten out as the "right" choice.
>> If you're not managing your paths in your application and production
>> environments, you can't claim that you are being "more secure". You're
>> simply being vague and hoping for the best.
>
> Being explicit with a #!/path/to/perl is not vague, in my opinion.
>
The only thing "explicit" is which perl interpreter you are invoking,
which to me does seem much more vague (is it real, a symlink, who
knows?). Unless your build puts the path to the perl interpreter
there, you're taking something for granted (and thus, is vague).
mst, the author of local::lib and many other very very good packages,
and generally big braned dude with a chainsaw, probably has a lot of
more cohesive arguments than I do about /usr/bin/env. I'm trying to
pester him to write up an article on it... hopefully we can see it.
-J
--
J. Shirley :: jshirley at gmail.com :: Killing two stones with one bird...
http://www.toeat.com
More information about the Pdx-pm-list
mailing list