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".
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.
"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.
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?
Available for small or large Perl jobs; see my home node.