sudo and cpan
Okay, I seem to have forgotten how to use CPAN. Where are the detailed instructions? (perldoc cpan only gets me a page.) And while I'm making noise, When you have perl 5.6 as the system perl (/usr/bin) and perl 5.8 as a parallel install in /usr/local/bin, you want to set your user's path to put /usr/local/bin in front of /usr/bin before you run cpan, so cpan doesn't get confused, right? What's the difference between perl -mCPAN (or whatever that was) and /usr/local/bin/cpan? Is it normal for cpan to not ask to be set up after a fresh install of 5.8.4? It prompted me to install Bundle::cpan, but didn't run through the list of ftp services and so on, etc. that I remember from previous times. Does cpan have to be run as root? What happened when I tried to install Bundle::cpan as an admin user, then ran sudo cpan? Was I supposed to do a clean or something first? It installed the second time, when I sudoed it, didn't fail any tests, but skipped some tests because I didn't tell it the location of any ftp servers to test off of and things like that. I was surprised that it didn't seem to know my local host name. Now it seems to be unable to release the locks when I quit unless I start sudoed. And I can't find the instructions about querying which modules are installed, either. Maybe it'd help if I had gotten more sleep last night. -- Joel Rees
Re: sudo and cpan
On 2004.5.6, at 08:08 PM, Joel Rees wrote:
Okay, I seem to have forgotten how to use CPAN. Where are the detailed
instructions?
(perldoc cpan only gets me a page.)
And while I'm making noise,
When you have perl 5.6 as the system perl (/usr/bin) and perl 5.8 as a
parallel install in /usr/local/bin, you want to set your user's path
to put /usr/local/bin in front of /usr/bin before you run cpan, so
cpan doesn't get confused, right?
What I'm thinking about is learning enough sh to split the path and
insert /usr/local/bin in the middle, because I really don't want to put
set path=(/bin /sbin /usr/local/bin /usr/bin /usr/sbin)
in my users's .bash_profile, etc. It's not like it's going to change or
anything, but it just feels wrong.
set path=(/usr/local/bin ${path})
also feels wrong. It avoids walking on the system provided path, but it
gives /usr/local/bin priority over /sbin. If everything in /sbin should
be called by full path anyway, why is /sbin in the path at all?
Maybe this is really a question for a security list.
What's the difference between perl -mCPAN (or whatever that was) and
/usr/local/bin/cpan?
perl -MCPAN -e shell
is interactive.
Is it normal for cpan to not ask to be set up after a fresh install of
5.8.4? It prompted me to install Bundle::cpan, but didn't run through
the list of ftp services and so on, etc. that I remember from previous
times.
Evidentally I don't run CPAN non-interactively very much.
Does cpan have to be run as root? What happened when I tried to
install Bundle::cpan as an admin user, then ran sudo cpan? Was I
supposed to do a clean or something first? It installed the second
time, when I sudoed it, didn't fail any tests, but skipped some tests
because I didn't tell it the location of any ftp servers to test off
of and things like that. I was surprised that it didn't seem to know
my local host name. Now it seems to be unable to release the locks
when I quit unless I start sudoed.
Still don't find much on this one.
And I can't find the instructions about querying which modules are
installed, either.
Okay,
perldoc perllocal
perldoc perlmodlib
Maybe it'd help if I had gotten more sleep last night.
Reading the faq helps, too.
--
Joel Rees
Re: sudo and cpan
On May 6, 2004, at 7:08 AM, Joel Rees wrote: When you have perl 5.6 as the system perl (/usr/bin) and perl 5.8 as a parallel install in /usr/local/bin, you want to set your user's path to put /usr/local/bin in front of /usr/bin before you run cpan, so cpan doesn't get confused, right? The 'cpan' script is tied to its particular perl interpreter. In your case, if you run /usr/local/bin/cpan you will get /usr/local/bin/perl (the 5.6) and if you run /usr/bin/cpan you will get /usr/local/bin/perl (5.8). You can also readjust your PATH to pick the right one as you described. It isn't so much that cpan will get confused, but rather that the 'cpan' script knows its perl, and perl will normally only install modules into its library directories. (or is is cpan knows its perl and perl will only ask modules to install themselves into perl's installation directories.) /usr/bin/cpan is simply a small perl script, so you can easily examine what it does. Basically it just parses command line arguments and then calls the CPAN.pm module.
Re: sudo and cpan
On Thu, 6 May 2004, Joel Rees wrote:
On 2004.5.6, at 08:08 PM, Joel Rees wrote:
What I'm thinking about is learning enough sh to split the path and
insert /usr/local/bin in the middle, because I really don't want to put
set path=(/bin /sbin /usr/local/bin /usr/bin /usr/sbin)
in my users's .bash_profile, etc. It's not like it's going to change or
anything, but it just feels wrong.
Why? It looks reasonable to me.
My only quibble is the order you have these in. There are different
schools of thought on this, but my personal preference is like this:
set path=( ~/bin /usr/local/bin /usr/bin /bin /usr/sbin /sbin )
The idea being that I want my own stuff first, then things that I
installed system wide; after that I want the system installed user level
commands in /{usr,}/bin; finally the system commands in /{usr,}/sbin.
This way, things I put in my home ~/bin dir override everything else,
and things I installed for all users in /usr/local come next. At the end
of the list are system commands that a normal user doesn't hit very
often, and in the middle are stock commands that the system provides.
Actually, I use Fink, so I put /sw/bin after /usr/local/bin, and
/sw/sbin just before /usr/sbin. The same reasoning applies: Fink stuff
feels a little bit more system-y to me than things I put in
/usr/local, so I want them farther back in the list, but on the other
hand they are customizations so they should be ahead of system stuff.
Make sense?
Like I say, there are different schools of thought, and some people
wouldn't use the order I prefer. I think this hierarchy makes sense.
set path=(/usr/local/bin ${path})
also feels wrong. It avoids walking on the system provided path, but it
gives /usr/local/bin priority over /sbin.
That's a good thing! Look at what you have in /sbin -- most of those
commands are rarely if ever touched by regular users; the closest most
people ever get is running some program -- probably with a GUI -- that
calls one of these /sbin commands in the background.
If for some reason you wanted to override the behavior of, say,
/sbin/mount, then you could write a shell or Perl script in
/usr/local/bin/mount. That way, if you were working in the shell, you'd
have your enhanced version of 'mount', but non-interactive scripts that
need these commands would still be able to poke directly at /sbin/mount.
[NB: making scripts or aliases with the same name as a system command is
an iffy idea that can lead to all kinds of subtle problems, so I'm just
using this as an illustrative example of what *could* be done, rather
than what *should* be done -- personally, I think doing this kind of
thing is a bad, bad idea that will bite you in the ass later.]
If everything in /sbin should
be called by full path anyway, why is /sbin in the path at all?
Well, some people do actually omit it from their path for that reason.
It isn't such a bad idea, either -- many of the commands in there really
shouldn't be poked at unless you know what you're doing, and if you do
know what you're doing then five extra characters is no big deal.
But anyway, back to your original question. Your /usr/bin/cpan should
just be a little Perl script that amounts to little more than this:
$ /usr/bin/perl -MCPAN -e shell
If you have a newer version of Perl in /usr/local, try this
$ sudo /usr/local/bin/perl -MCPAN -e shell
And you should end up with about the same behavior.
--
Chris Devers
Re: sudo and cpan
On 2004.5.6, at 09:58 PM, Chris Devers wrote: ... But anyway, back to your original question. Your /usr/bin/cpan should just be a little Perl script that amounts to little more than this: $ /usr/bin/perl -MCPAN -e shell hmm. I could have sworn I'd ended up with non-interactive behavior when I just ran /usr/local/cpan. Maybe it was just that all the defaults were already set from installing 5.8.4 from source. Thanks. Any thoughts about the file locks left over when I run without sudo and quit? This doesn't happen when I'm running cpan as a non-amin user. Or maybe I should say it doesn't happen as a user other than the one I installed as, but I haven't tried running as a non-install admin user yet. I'm thinking too hard, I know. Time to install XML and get back to work. -- Joel Rees
Re: sudo and cpan
On Thu, 6 May 2004, Joel Rees wrote: Thanks. Any thoughts about the file locks left over when I run without sudo and quit? Your CPAN home directory should be something like ~/.cpan/ -- look in there for a lock file, possibly owned by root. Delete it while the CPAN shell isn't running (use sudo if necessary), then try again. This sort of thing can happen if the CPAN shell crashed or was forced to quit with a `kill -9` or something along those lines. No big deal... As a test, I just ran CPAN in one terminal, then another. I got this: $ sudo cpan There seems to be running another CPAN process (pid 1847). Contacting... Other job is running. You may want to kill it and delete the lockfile, maybe. On UNIX try: kill 1847 rm /tmp/.cpan/.lock $ If that's the error you're getting, it contains the solution. First, see if the CPAN process (in this case, 1847) is still hanging around, and if you can't get to it (it's running in a window at home you're logged in from work, or it was in a window that crashed, etc) then kill the stuck job (`kill 1847`, `sudo kill 1847`, `kill -9 1847`, `sudo kill -9 1847`, in increasing order of desperation) and try again. If you don't have a Perl or CPAN job running at the process ID noted, then the lockfile is out of date -- maybe your whole system crashed and this lockfile is lingering from before your last reboot. In that case, follow the second suggestion offered and remove the .lock file. Are you not getting an error message to the effect of what I put here? I'm thinking too hard, I know. Time to install XML and get back to work. Heh, now you have two problems! :) -- Chris Devers
Re: sudo and cpan
Hi! I am new to the list. Here is what I have learned so far about perl and the Mac. 1.) My experience with Mac OS X is that you need to heavily modify your PATH. If you add /usr/bin to the path you can just type perl -MCPAN -eshell. I also verified that the size of perl matched the perl version I wanted to use, but you could also check the link. 2.) I ran into the sudo CPAN problem as well, but root access isn't necesary if you are on the first account you created with the system. This account has admin (wheel equivelent) privledges by default. If you delete your .cpan directory(most likely under your ~ directory) and rerun perl -MCPAN -eshell it will create a new .cpan that wont require sudo to run. --- Joel Rees [EMAIL PROTECTED] wrote: On 2004.5.6, at 09:58 PM, Chris Devers wrote: ... But anyway, back to your original question. Your /usr/bin/cpan should just be a little Perl script that amounts to little more than this: $ /usr/bin/perl -MCPAN -e shell hmm. I could have sworn I'd ended up with non-interactive behavior when I just ran /usr/local/cpan. Maybe it was just that all the defaults were already set from installing 5.8.4 from source. Thanks. Any thoughts about the file locks left over when I run without sudo and quit? This doesn't happen when I'm running cpan as a non-amin user. Or maybe I should say it doesn't happen as a user other than the one I installed as, but I haven't tried running as a non-install admin user yet. I'm thinking too hard, I know. Time to install XML and get back to work. -- Joel Rees __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
