Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: #!/usr/bin/perl vs. -*- perl -*-

by Argel (Prior)
on Jan 20, 2009 at 18:53 UTC ( [id://737639]=note: print w/replies, xml ) Need Help??


in reply to #!/usr/bin/perl vs. -*- perl -*-

Barring some special circumstances you should really be hardcoding the perl you are using. And even if there are cross-platform compatibility issues that still doesn't justify leaving it up to your PATH because you can detect the system you are on and then run a hardcoded perl from within your wrapper shell script. Or alternatively you can modify the environment from within the shell script to make sure the perl you want will be first in your path (don't forget to check for aliases too). Rolling the dice is for role-playing games, not work! :-)

Elda Taluta; Sarks Sark; Ark Arks

Replies are listed 'Best First'.
Re^2: #!/usr/bin/perl vs. -*- perl -*-
by Porculus (Hermit) on Feb 05, 2009 at 19:04 UTC
    Barring some special circumstances you should really be hardcoding the perl you are using.

    Why, might I ask? I've scratched my head over this for several minutes and I simply can't think of a good reason for doing this, except in the unusual case where you have multiple incompatible Perl interpreters installed at the same time.

    I certainly don't see how it could be a security thing. If someone's capable of adding a malicious perl binary to the $PATH of someone with superuser privileges, then the machine is probably rooted already.

    And even if there are cross-platform compatibility issues that still doesn't justify leaving it up to your PATH because you can detect the system you are on and then run a hardcoded perl from within your wrapper shell script.

    I'm not sure why you assume there's a wrapper shell script. I've never had any desire to use such a thing. #! /usr/bin/env perl works just fine.

    Where you have a heterogeneous set of environments, the last thing you want is a fragile script that lists half a dozen or more different magic filenames, and breaks if you upgrade a system. One of the nice things about Perl is that it lets you get away from shell scripts, which are a nightmare to make portable!

    And that's without even getting into the situation I'm commonly in, where I don't know what systems my scripts are going to run on. Sure, I could write a fragile shell script, and then when someone wants to run the script on Cygwin I could add another special case, and then when someone wants to run it on Solaris I could add yet another special case... or, you know, I could just put #! /usr/bin/env perl and it would just work on all the most common platforms, letting me reserve special-case handling for actual special cases.

      Why? It's good system administration, that's why. As I said in my original post, "rolling the dice is for role-playing games, not work!" In other words, you do not leave things to chance for things running in production. If you cannot grasp that concept then you just do not have enough system administration experience. You may want to read some "best practices" type books, such as "The Practice of System and Network Administration 2nd Ed" (publisher and Amazon links). Or work in a shop with several other developers and multiple Perl installations for some hands on experience.

      Your argument against a "fragile" wrapper script makes little sense because the entire system is "fragile". For example, you are concerned that an upgrade may break your wrapper script when an upgrade to the system will more likely break your Perl script.

      Your argument against a big complicated wrapper script also does not hold water. If the environments your code may run in are that different then you are going to have to do something about it anyway. If not then it is not going to be a complicated script. You are also moving into the realm of distributing code where a build environment would be more appropriate. What do you think happens when you do a "perl Makefile.PL"? Or a "./configure"?? Someone else has spent time figuring out how to resolve environment related issues for you. Quite frankly, it sounds like you are used to using packages created by others and thus have not been exposed to the work that went into making them. Have you ever tried compiling Perl or GCC?

      But at the heart of it all is that principle that you make sure you know what your production code is doing and what it is relying on.

      Elda Taluta; Sarks Sark; Ark Arks

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://737639]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2024-03-28 18:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found