Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^2: Stupid question

by flexvault (Monsignor)
on May 12, 2012 at 10:32 UTC ( [id://970161]=note: print w/replies, xml ) Need Help??

in reply to (tye)Re: Stupid question
in thread Stupid question


    #!/usr/bin/perl is the standard place for Perl as declared by Larry himself. Even if you install /usr/local/bin/perl, please also put a link in /usr/bin and please use #!/usr/bin/perl in scripts that you make public

Please consider in the *nix world of today, you may make your system useless if you do the above. Changing the default system "perl" is quite dangerous. 5 years ago, I would agree, but today it's better to link the other way around if you're not installing a different Perl. Just my 2 cents.

Thank you

"Well done is better than well said." - Benjamin Franklin

Replies are listed 'Best First'.
Re^3: Stupid question (/usr/bin/perl)
by tye (Sage) on May 12, 2012 at 17:34 UTC

    All I suggested is that there be a /usr/bin/perl (if there is any version of Perl installed). I don't see how there being a /usr/bin/perl would make a modern Unix system "useless".

    - tye        


      I guess I didn't explain myself properly.

      Several of the newer versions of *nix distributions seem to be shipping a vendor updated "safer" Perl in /usr/bin. If you replace this "safer" Perl with a "compiled by you" Perl without the vendor's "patches", many of the system utilities that require the "safer" Perl just don't work.

      So my new rules would be:

      • Never use or touch the /usr/bin/perl
      • Always use a known version of Perl ( best to compile yourself ).
      • Preferred location is /usr/local/bin/perl ( I usually link to the known Perl. )

      This is not what I would like, but it is necessary. In the past 2 years, I've had to re-install 3 different new distros that after installing a newer Perl as /usr/bin/perl many utilities just don't work. I used to routinely install a new Perl as /usr/bin/perl. I don't do that anymore!
      Note: Sorry to admit I did this 3 times, but old habits are hard to break.

      How many times on PM do you see comments of "...doesn't work...", followed by " on my system...". I'm pointing to the difference may be in using the vendor supplied Perl.

      This is not a Perl problem!

      I have said many times that Perl is getting better and better. I have never changed Perl code, nor do I see any need to. When I compile Perl myself, it works as documented.

      Thank you

      "Well done is better than well said." - Benjamin Franklin

        I've written elsewhere about not messing with the provided-by-the-OS Perl. And I was not advocating messing with it here.

        There are dozens of systems I work with. Most of them have a /usr/bin and most of them have Perl. I don't believe there is a single system that I've worked with recently that has Perl and has /usr/bin that doesn't have a /usr/bin/perl. Tons of systems I work with don't have a /usr/local/bin/perl. So, if I'm going to put a path to Perl in a #! line of something that isn't destined for a specific system (or specific group of systems), then I'm going to use /usr/bin/perl as that path.

        My preference would be for modern Unix kernels to handle a simple #!perl as "find 'perl' in $PATH and run that". But I have yet to see a kernel that supports such. I've seen people do "#!/usr/bin/env perl" but I've also seen systems that have /bin/env and don't have /usr/bin/env. And it seems both like hackish and imprecise thing to do.

        I have a lot of little utilities that don't make many demands of Perl and those, even when I put such on a specific system, I usually leave them pointed at /usr/bin/perl and I don't recall ever having a problem with that.

        I work with a lot of large-scale systems of Perl code. Each of those have a version of Perl dedicated to them (along with a stable of specific versions of specific Perl modules). So those versions usually don't end up as /usr/local/bin/perl since sometimes you end up with two different subsystems running on the same box and they might not depend on the same build of Perl. But I also don't post such things to the public.

        So my preference is for public postings of Perl scripts to start with #!/usr/bin/perl. I actually use Perl scripts even on systems that don't have a dedicated "for some application" version of Perl installed on them.

        But it isn't a terribly strong preference. My expectation is that the #! line will often have to be eventually modified. But I'd rather start with a #! that is most likely to at least be present on most systems.

        - tye        

Re^3: Stupid question
by aaron_baugher (Curate) on May 12, 2012 at 11:50 UTC

    Whichever direction you link it, that would seem to present a problem. If you're installing a separate perl because you want to leave the stock perl pristine for the OS to use, well, the OS will expect to find the stock perl in /usr/bin/perl. If /usr/bin/perl is a link to /usr/local/bin/perl (or wherever), then the OS will be using your local version, so you might as well have just replaced the stock version with your own version, right?

    Another thought: if you symlink /usr/bin/perl to somewhere else, can you trust that an OS upgrade of the stock perl won't clobber your symlink?

    Aaron B.
    Available for small or large Perl jobs; see my home node.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-04-25 04:43 GMT
Find Nodes?
    Voting Booth?

    No recent polls found