Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^4: Stupid question (/usr/bin/perl)

by flexvault (Monsignor)
on May 13, 2012 at 08:16 UTC ( [id://970253]=note: print w/replies, xml ) Need Help??


in reply to Re^3: Stupid question (/usr/bin/perl)
in thread Stupid question

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 "...works 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

Replies are listed 'Best First'.
Re^5: Stupid question (/usr/bin/perl)
by tye (Sage) on May 13, 2012 at 22:22 UTC

    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        

      tye,

      Sounds like we do similar types of work, except now most of the time I'm building new systems. For some reason the new distros use Perl 5.10.x, which I've found to have a lot of problems. I would rather have 5.8.8 than a 5.10.x. However, I install 5.12.2 as my preference. Experimenting with 5.14.x, I have had problems with CPAN mods compiling.

      All of this is normal in a changing world, but what I don't like is the vendors modifying Perl to fix their crappy scripts.

      I think if your just take all the defaults with compiling a new Perl, it will be installed in /usr/local/bin.

      I wasn't trying to find fault with your statements as much as pointing to the new problem of using vendor modified Perl.

      All the best...Ed

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

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2024-03-19 02:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found