Is there a need for PERL in /usr/contrib/bin/perl?

[Alzhy]

Planning to remove it in favor of a version (5.6.1) that'll install in /opt or /usr/local or /usr/bin ...

Is it needed for something else?

[Patrick Wallek]

I would leave that version of Perl there. It is version 4, I think. I believe it is used for utilities like q4. It's not really hurting anything.

If you want to make sure that the new perl gets found before the old, 1) specify an explicit path to /opt/perl/bin/perl and/or 2) make sure the /opt/perl/bin occurrs BEFORE /usr/contrib/bin in your $PATH

[Steven E. Protter]

This is a definite don't touch.

If you have a httpd server or any common gateway interface programs, they may look for perl in /usr/contrib/bin

You would be surprised how many little utilities and scripts that won't work right with Perl 5.6.1 will break if you remove perl.

Just for a list, try this:

find / -exec grep -l '/usr/contrib/bin/perl' {} \;

You might be surprised at the results.

Also, if you are standardizing on a Perl version, you might want to consider Perl 5.8.0, though it is a dot-zero release.

That doesn't mean ripping out the older perls.

SEP

[Sridhar Bhaskarla]

Hi,

As Patrick said, it is mainly for Q4 analysis. I would leave it there though it may not work for many utilities.

-Sri

[Stanimir]

Hi
You could release it at least if
you have any scripts,pointed to
this revision.
Regards

[Alan Turner]

I've deleted /usr/contrib/bin/perl (directed to do so by a set of paranoid security types) - not noticed any problems in my systems so far.
However, I'm not using httpd or cgi (running MTOE).

[Ralph Grothe]

As said by the others,
the Perl in /usr/contrib/bin mainly serves for HP custom scripts, of which most themself reside beneath /usr/contrib

e.g.

# find /usr/contrib -type f -name \*.pl|wc -l
426

and mainly serve Q4 analysis

# find /usr/contrib/Q4 -type f -name \*.pl|wc -l
424

The Perl in /usr/contrib/bin on an 11.00 box is quite dated

# /usr/contrib/bin/perl -v

This is perl, version 4.0

$RCSfile: perl.c,v $$Revision: 4.0.1.8 $$Date: 1993/02/05 19:39:30 $
Patch level: 36

Copyright (c) 1989, 1990, 1991, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 4.0 source kit.


whereas on an 11i box they already shipped a more recent Perl 5.005.

Because of the dated Perl 4 interpreter (this was before references were introduced in Perl, which dramatically expanded and changed Perl's capabilities and coding style (viz. LoLs, OO etc.)), the code of these HP scripts is really awfull by now, and most of it would even be regarded as deprecated in the Perl community.
Thus, if you are looking for code to learn from how to improve your Perl coding technique and style, I'd suggest to better not consider those scripts.

On the other hand current Perl versions (e.g. 5, 5.6, 5.8) should still be able to compile and execute the old Perl 4 scripts.
So I guess the main reason, why in reality this many times isn't the case is probably owe to wrong paths.
But to save you from trouble I as well would advise to keep the old Perl in /usr/contrib, so that HP scripts still would work, and for your users install a current Perl (they may even expect it).
Then let a symlink from /usr/bin/perl point to your current perl, e.g. to /opt/perl5/bin/perl.

Maybe there isn't even a need for you to install a recent Perl, and you have it already installed but it left unnoticed so far because it weren't in your users' paths.

Just try this

# /usr/sbin/swlist -l fileset -a state -a revision perl
# Initializing...
# Contacting target "moron"...
#
# Target: moron:/
#

# perl B.5.6.1.C
# perl.Perl5 B.5.6.1.C
perl.Perl5.PERL-RUN B.5.6.1.C configured

[Scot Bean]

Do watch your/users $PATH variable.

Can be very confusing trying to program in Perl and hitting these 2 very different versions.