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

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. Shirley :: jshirley at gmail.com :: Killing two stones with one bird...

More information about the Pdx-pm-list mailing list