KEVIN ZEMBOWER [[EMAIL PROTECTED]] quoth:
*>
*>Any suggestions on cleaning up this mess? Can I just delete
*>/usr/bin/perl and link it to /usr/local/bin/perl, or is there a more
*>elaborate, better solution?
If this is a Solaris 8 box then I'd recommend leaving /usr/bin/perl alone
and adjusting your path so that the /usr/local/bin/perl is first in line
or you could just do a 'pkgrm' of SUNWpl5{m|p|u}. If not you could rename
the /usr/bin/perl to something and create the link..then wait to see what
breaks. Since you don't know which perl has which module, it's best to
rename the perl binary first as there could be a few things depending on
that perl and its libraries...and that will give you a chance to keep
things running while you sort out the mess.
*>Also, are you saying in general that there should never be a need to
*>force the directory that CPAN installs into, or to change the contents
*>of @INC? If there's still a need to sometimes do either of these, I'd
*>still welcome anyone to suggest how to do them, as well as how to check
*>if the make_install_arg is still set.
/usr/bin/perl -MCPAN and /usr/local/bin/perl -MCPAN use 2
different perls and 2 different libs so they don't conflict with one
another. You can configure CPAN.pm to pass arguments to the Makefile,
like you would on the command line, via the makepl_arg, e.g.
o conf makepl_arg "LIB=/foo/bar PREFIX=/some/other/dir"
But, no, generally you shouldn't ever need to futz with @INC or the make
args for CPAN.pm. See the CPAN pod for more info on the various
configuration options.
I usually have 3 or 4 different installations on any given box and have
come to reflexively type 'perl -V' just to make sure the perl I'm using is
the perl I want but it's more than possible to have several Perl versions
on a system without a problem...well, other than keeping them straight
sometimes :)
e.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
