[28902] in Perl-Users-Digest
Perl-Users Digest, Issue: 146 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 16 18:10:18 2007
Date: Fri, 16 Feb 2007 15:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 16 Feb 2007 Volume: 11 Number: 146
Today's topics:
Re: How to extract .tar files in different directory? au.danji@gmail.com
Re: New to Perl, OOP inheritance <petermichaux@gmail.com>
Re: Perl thread question <ecarlson@vmware.com>
Re: Perl thread question <ecarlson@vmware.com>
Re: Perl thread question <thepoet_nospam@arcor.de>
Re: Perl thread question <ecarlson@vmware.com>
Re: Regexp for email addresses. <bik.mido@tiscalinet.it>
Re: Regexp for email addresses. <abigail@abigail.be>
Re: Sending a local attachment via email form <rvtol+news@isolution.nl>
Re: set a variable with a specified element of an arra <rvtol+news@isolution.nl>
Re: Uninstall a module? <bik.mido@tiscalinet.it>
Re: Uninstall a module? <bart.lateur@pandora.be>
Re: Uninstall a module? <greg.ferguson@icrossing.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 16 Feb 2007 13:40:11 -0800
From: au.danji@gmail.com
Subject: Re: How to extract .tar files in different directory?
Message-Id: <1171662010.820620.11600@q2g2000cwa.googlegroups.com>
On Feb 16, 12:24 pm, "Mumia W." <paduille.4060.mumia.w
+nos...@earthlink.net> wrote:
> On 02/16/2007 08:42 AM, au.da...@gmail.com wrote:
>
> > On Feb 15, 4:29 pm, "mar...@gmail.com" <mar...@gmail.com> wrote:
> >> [...]
> >> From perl you can execute any unix command using system("cmd").
>
> >> Regards,
> >> Manish
>
> > Thanks for all reply, actually, I am running my script in windows XP,
> > so I can not use unix cmd.
>
> You can install the Perl module Archive::Tarto help you with thetarfiles.
>
> --
> Windows Vista and your freedom in conflict:http://www.regdeveloper.co.uk/2006/10/29/microsoft_vista_eula_analysis/
Thank for everyone's reply!!
Below is my perl code, which can unzip all .tar file from
one directory, however, since I have around 20 .tar files
in this directory(each one is 100MB), when the script running,
my pc becomes really slow, I guess that because Perl put them
into the memory, could anyone tell me if I can extract these big
.tar files without using large amount of my PC memory? Thanks!
This is my code:
=============================================================
opendir(DIR,"$localpath") || die("cannot open $localpath");
foreach $direntry (readdir(DIR))
{
if ($direntry =~ /tar/)
{
print "direntry tar is: $direntry\n";
if ($tar->read("$localpath/$direntry",1))
{
print "read $direntry successfully\n";
}
if ($tar->extract())
{
print "extract $direntry successfully\n";
}
}
}
=================================================================
Also I try to put the unziped files into a different folder, but the
$tar->extract_file is not working like below code, what is wrong with
that?
$tar->extract_file("$localpath/1.tar","$localpath/extract/test");
thanks a lot!
------------------------------
Date: 16 Feb 2007 15:05:12 -0800
From: "Peter Michaux" <petermichaux@gmail.com>
Subject: Re: New to Perl, OOP inheritance
Message-Id: <1171667112.443950.112030@s48g2000cws.googlegroups.com>
On Feb 16, 1:06 am, anno4...@radom.zrz.tu-berlin.de wrote:
> Peter Michaux <petermich...@gmail.com> wrote in comp.lang.perl.misc:
>
> > Hi,
>
> > I'm new to Perl (from C, JavaScript, Ruby) and going through the Camel
> > book.
>
> > Below is my an example of trying to write Ruby/Java style class-based
> > inheritance in Perl. (In JavaScript, Ruby and Java I would write like
> > this <URL:http://peter.michaux.ca/article/1>) The first eight lines
> > of each new subroutine below seems quite clunky. I'm trying to make it
> > so the new can be called either to instantiate a new object or be
> > called as super from a child class's constructor. I only want to name
> > the parent class once in the @ISA and use SUPER everywhere else so I
> > can change the inheritance chain easily.
>
> So if ->new is called as an object method it (re-)initializes the
> object. That's a reasonable approach, though it might be clearer
> to have separate methods (object method ->init, class method ->new)
> for that.
>
>
>
> > package Person;
>
> > sub new {
> > my $invocant = shift;
> > my $this;
> > if (ref($invocant)) {
> > $this = $invocant;
> > } else {
> > $this = {};
> > bless($this, $invocant);
> > }
> > my ($name) = @_;
> > $this->{name} = $name;
> > return $this;
> > }
>
> > sub toString {
> > $this = shift;
> > return $this->{name};
> > }
>
> > # ---------------------------------------------
>
> > package Employee;
> > our @ISA = ('Person');
>
> > sub new {
> > my $invocant = shift;
> > my $this;
> > if (ref($invocant)) {
> > $this = $invocant;
> > } else {
> > $this = {};
> > bless($this, $invocant);
> > }
> > my ($name, $id) = @_;
>
> > $this->SUPER::new($name);
> > $this->{id} = $id;
> > return $this;
> > }
>
> > sub toString {
> > my $this = shift;
> > return $this->SUPER::toString() . ': ' . $this->{id};
> > }
>
> > # ---------------------------------------------
>
> > $ted = Employee->new('Ted', 10);
> > print ($ted->toString(), "\n");
>
> > Any suggestions to clean up the clunky parts of the new subroutines? I
> > expect that some will say "this is not how you do OOP Inheritance in
> > Perl." Other options?
>
> You can pack most of the "clunky part" in one statement:
>
> sub new {
> my $invocant = shift;
> my $this = ref( $invocant) ? $invocant : bless {}, $invocant;
> my ($name) = @_;
> # ...
> }
>
> Anno
Thanks for the reply. Good to know I wasn't way out in left field.
Peter
------------------------------
Date: 16 Feb 2007 11:20:32 -0800
From: "Eric" <ecarlson@vmware.com>
Subject: Re: Perl thread question
Message-Id: <1171653632.342994.187160@p10g2000cwp.googlegroups.com>
On Feb 16, 11:04 am, Christian Winter <thepoet_nos...@arcor.de> wrote:
> Eric wrote:
> > Hello,
>
> > I was given a task that requires me to launch multiple executions of
> > the same script using different args as input. Instead of waiting for
> > the first to complete before starting the second one, I need to run
> > them in their own thread (i.e. parallel).
>
> [...]
>
> > It turns out that I need the result of the subroutine to determine if
> > the login, logout was successful. So I tried using the join function
> > as follows:
>
> > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> > use Config;
> > use threads;
>
> > my @cmdline = ("log_on_off.exp mach003-con",
> > "log_on_off.exp mach022-con",
> > "log_on_off.exp mach030-con");
>
> > foreach (@cmdline) {
> > my $thr = threads->new(\&runExpectScript, $_);
> > my $retResponse = $thr->join;
> > }
>
> > sub runExpectScript {
> > my $cmd = $_;
> > my $runScript = `$cmd`;
>
> > if ($runScript =~ m/successful/) {
> > print "SUCCESS\n";
> > } else {
> > print "FAILURE\n";
> > }
> > }
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > When I run this Perl script in the background, I never see more than
> > one log_on_off.exp process running at any time. According to the
> > document I am using as a learning tool (http://perldoc.perl.org/
> > perlthrtut.html), the join function waits for the thread to exit
> > before continuing. I interpret this as saying that the second command
> > will not be started until the first returns, which defeats the purpose
> > of my using Perl threads to begin with, since these commands are being
> > executed serially (which is no different than running them in a loop
> > without even using Perl threads). Is my interpretation correct?
>
> Yes. You're mixing up two different things here: the execution
> of the threads and the collection of their results. In your example
> you're in fact waiting for the result of one thread before starting
> the next one and making the use of threads obsolete.
>
> If you want to parallelise threads, you have to first start all of
> them, then collect all of them, like with
>
> my @thrdlist;
>
> foreach( 0 .. $#cmdline )
> {
> $thrdlist[$_] = threads->new( \&runExpectScript, $cmdline[$_] );
>
> }
>
> my @responses;
>
> foreach( 0 .. $#cmdline )
> {
> $responses[$_] = $thrdlist[$_]->join();
>
> }
>
> In that example the threads are all fired as quickly as Perl permits,
> then the result collection loop runs until all of them are finished
> and their results can be fetched.
>
> Note that it does hardly matter in what order the threads finish, as
> when one of the first threads takes longer than later ones they simply
> wait in the queue until they are join()ed. So the speed loss is just
> the execution time of the remaining loop iterations (fetching the
> return value and destroying the thread).
>
> > Is there any way I can execute these commands and parse the input in
> > their own thread instead of waiting for the previous command to
> > finish? Of course, if this can be done, I need to be able to determine
> > what thread returned what value.
>
> That threads topic can give a lot of headache, that I know from
> experience, but usually things tend to be a lot simpler than one
> would have thought :)
>
> btw., I noticed that in your script you have
> sub runExpectScript {
> my $cmd = $_;
>
> You surely want to use
> my $cmd = shift;
> or
> my $cmd = $_[0];
> here, as it's more of an accident that $_ holds the correct value at
> this point and the correct place to look for subroutine args is @_.
>
> -Chris- Hide quoted text -
>
> - Show quoted text -
Thanks for your response, Chris. After I submitted my initial entry, I
had an enlightenment and tried the following:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#!/usr/bin/perl
use strict;
use warnings;
use Config;
use threads;
$Config{useithreads} or die "Recompile Perl with threads to run this
program.";
# Put all of the command line args in an array.
my @cmdline = ("log_on_off.exp mach003_con",
"log_on_off.exp mach022_con",
"log_on_off.exp mach030_con");
# Execute each command in the array in it's own thread.
foreach (@cmdline) {
my $thr = threads->new(\&runExpectScript, $_);
sleep 1;
print "Value of \$thr is: $$thr\n";
my $ps = system("ps"); ##
}
# Specify the join function for each thread in the list.
for my $t (threads->list) {
print "Value of \$t is: $$t\n"; ##
$t->join;
}
sub runExpectScript {
my $cmd = shift;
print "The command line is: $cmd\n";
my $runScript = `$cmd`;
#print "The contents of \$runScript are: $runScript\n";
if ($runScript =~ m/successful/) {
print "SUCCESS: $_\n";
} else {
print "FAILURE: $_\n";
}
}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This seems to work. Here is the output I get:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
$ m.pl
The command line is: log_on_off.exp pdp003 pdp003-ilo
Value of $thr is: 140820824
PID TTY TIME CMD
2150 pts/1 00:00:24 bash
4194 pts/1 00:00:00 m.pl
4196 pts/1 00:00:00 log_on_off.exp
4235 pts/1 00:00:00 ps
The command line is: log_on_off.exp pdp022 pdp022-ilo
Value of $thr is: 141287696
PID TTY TIME CMD
2150 pts/1 00:00:24 bash
4194 pts/1 00:00:00 m.pl
4196 pts/1 00:00:00 log_on_off.exp
4237 pts/1 00:00:00 log_on_off.exp
4276 pts/1 00:00:00 ps
The command line is: log_on_off.exp osdc-pdp030 osdc-pdp030-ilo
Value of $thr is: 141228056
PID TTY TIME CMD
2150 pts/1 00:00:24 bash
4194 pts/1 00:00:00 m.pl
4196 pts/1 00:00:00 log_on_off.exp
4237 pts/1 00:00:00 log_on_off.exp
4278 pts/1 00:00:00 log_on_off.exp
4316 pts/1 00:00:00 ps
Value of $t is: 140820824
SUCCESS: log_on_off.exp pdp003 pdp003-ilo
Value of $t is: 141287696
SUCCESS: log_on_off.exp osdc-pdp030 osdc-pdp030-ilo
SUCCESS: log_on_off.exp pdp022 pdp022-ilo
Value of $t is: 141228056
[ecarlson@ecarlson-dev1 remboot]$
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As you can see, it appears that the processes are all started and
running as separate processes, as I would expect. The results are not
given in any particular order (which is ok), but appear to be
associated with the correct process based on command line. (I tried
some failure conditions and found that they match up.) The main
difference between my and your approach is that you went to extra
effort to identify each process by a number, which is probably a more
sure way than what I did. Do you feel that my approach will work
despite the fact that I didn't do this?
Thanks.
Eric
------------------------------
Date: 16 Feb 2007 11:32:54 -0800
From: "Eric" <ecarlson@vmware.com>
Subject: Re: Perl thread question
Message-Id: <1171654374.139309.25190@t69g2000cwt.googlegroups.com>
On Feb 16, 10:31 am, "J. Gleixner" <glex_no-s...@qwest-spam-
no.invalid> wrote:
> Parallel::ForkManagerEric wrote:
> > Hello,
>
> > I was given a task that requires me to launch multiple executions of
> > the same script using different args as input. Instead of waiting for
> > the first to complete before starting the second one, I need to run
> > them in their own thread (i.e. parallel).
>
> Maybe take a look at Parallel::ForkManager.
Thanks for your response. This is certainly worth my looking into, if
anything for future reference.
Eric
------------------------------
Date: Fri, 16 Feb 2007 21:29:40 +0100
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Perl thread question
Message-Id: <45d6142b$0$20295$9b4e6d93@newsspool3.arcor-online.net>
Eric wrote:
[fire-first-collect-later code snipped]
> PID TTY TIME CMD
> 2150 pts/1 00:00:24 bash
> 4194 pts/1 00:00:00 m.pl
> 4196 pts/1 00:00:00 log_on_off.exp
> 4237 pts/1 00:00:00 log_on_off.exp
> 4278 pts/1 00:00:00 log_on_off.exp
> 4316 pts/1 00:00:00 ps
> Value of $t is: 140820824
> SUCCESS: log_on_off.exp pdp003 pdp003-ilo
> Value of $t is: 141287696
> SUCCESS: log_on_off.exp osdc-pdp030 osdc-pdp030-ilo
> SUCCESS: log_on_off.exp pdp022 pdp022-ilo
> Value of $t is: 141228056
> [ecarlson@ecarlson-dev1 remboot]$
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> As you can see, it appears that the processes are all started and
> running as separate processes, as I would expect. The results are not
> given in any particular order (which is ok), but appear to be
> associated with the correct process based on command line. (I tried
> some failure conditions and found that they match up.) The main
> difference between my and your approach is that you went to extra
> effort to identify each process by a number, which is probably a more
> sure way than what I did. Do you feel that my approach will work
> despite the fact that I didn't do this?
If you're only going for some lines of text to the screen, I don't
see why not. Though you could also return a more complex data
structure that holds both the task identification and the result and
avoid the counter this way - like always, TMTOWTDI[1] - if you
want to work on the results some more later on in your script.
But I see in your code that you're still using $_ in the subroutine
and laying out traps for yourself (and I admit not being completely
clean there with my own example). Especially with threads, where
things may happen in random order, it's always wise to keep from
$_ as far as possible. Shift into variables in the sub, and use a
named iterator in the loops, like
foreach my $count ( 0 .. $#cmdline ) {
do_something_with( $count );
}
or
foreach my $nextcommand ( @commandline ) {
do_something_with( $nextcommand );
}
or tracing back random errors may become a hell of a job once the
projects get a bit more complex.
-Chris
1) There's More Than One Way To Do It, the Perl(5?) philosophy.
------------------------------
Date: 16 Feb 2007 12:46:31 -0800
From: "Eric" <ecarlson@vmware.com>
Subject: Re: Perl thread question
Message-Id: <1171658791.437941.257070@v45g2000cwv.googlegroups.com>
On Feb 16, 12:29 pm, Christian Winter <thepoet_nos...@arcor.de> wrote:
> Eric wrote:
>
> [fire-first-collect-later code snipped]
>
>
>
>
>
> > PID TTY TIME CMD
> > 2150 pts/1 00:00:24 bash
> > 4194 pts/1 00:00:00 m.pl
> > 4196 pts/1 00:00:00 log_on_off.exp
> > 4237 pts/1 00:00:00 log_on_off.exp
> > 4278 pts/1 00:00:00 log_on_off.exp
> > 4316 pts/1 00:00:00 ps
> > Value of $t is: 140820824
> > SUCCESS: log_on_off.exp pdp003 pdp003-ilo
> > Value of $t is: 141287696
> > SUCCESS: log_on_off.exp osdc-pdp030 osdc-pdp030-ilo
> > SUCCESS: log_on_off.exp pdp022 pdp022-ilo
> > Value of $t is: 141228056
> > [ecarlson@ecarlson-dev1 remboot]$
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > As you can see, it appears that the processes are all started and
> > running as separate processes, as I would expect. The results are not
> > given in any particular order (which is ok), but appear to be
> > associated with the correct process based on command line. (I tried
> > some failure conditions and found that they match up.) The main
> > difference between my and your approach is that you went to extra
> > effort to identify each process by a number, which is probably a more
> > sure way than what I did. Do you feel that my approach will work
> > despite the fact that I didn't do this?
>
> If you're only going for some lines of text to the screen, I don't
> see why not. Though you could also return a more complex data
> structure that holds both the task identification and the result and
> avoid the counter this way - like always, TMTOWTDI[1] - if you
> want to work on the results some more later on in your script.
>
> But I see in your code that you're still using $_ in the subroutine
> and laying out traps for yourself (and I admit not being completely
> clean there with my own example). Especially with threads, where
> things may happen in random order, it's always wise to keep from
> $_ as far as possible. Shift into variables in the sub, and use a
> named iterator in the loops, like
>
> foreach my $count ( 0 .. $#cmdline ) {
> do_something_with( $count );
>
> }
>
> or
>
> foreach my $nextcommand ( @commandline ) {
> do_something_with( $nextcommand );
>
> }
>
> or tracing back random errors may become a hell of a job once the
> projects get a bit more complex.
>
> -Chris
>
> 1) There's More Than One Way To Do It, the Perl(5?) philosophy.- Hide quoted text -
>
> - Show quoted text -
Good point on the $_, Chris. I usually try to take the Perl shortcut
to doing things. But sometimes that may not always be the best
approach, and possibly threads is one such case where it is not the
wisest thing to do.
Eric
------------------------------
Date: Fri, 16 Feb 2007 21:28:12 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Regexp for email addresses.
Message-Id: <6l4ct292brb4d3jtjho2181hg7kj0nfsks@4ax.com>
On Fri, 16 Feb 2007 17:24:56 +0100, "Petr Vileta"
<stoupa@practisoft.cz> wrote:
>> :: > use 5.9.5; # In fact, you need the newest blead.
[snip]
>> :: > --
>> :: > perl -wlpe '}{$_=$.}{' file # Count the number of lines.
[snip]
>> See perlrun, or do a google search for it. It has been explained
>> many times.
>>
>Can you post here some link to pages where this is explained? I have Perl
>5.6.1 and code not work for me, I haven't perldoc for 5.9.5 and google not
>accept these characters in search phrase.
http://www.google.it/search?q=%22count+the+number+of+lines%22+abigail
However 5.9.5 was required for the code in the body of the post. The
code being discussed here was part of the .sig: I don't have a 5.6.1
available but I'm sure it will work under the latter too. Read perlrun
for your installation of Perl and you will find the answer anyway.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 16 Feb 2007 21:42:22 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Regexp for email addresses.
Message-Id: <slrnetc99a.gs.abigail@alexandra.abigail.be>
Petr Vileta (stoupa@practisoft.cz) wrote on MMMMCMXVII September MCMXCIII
in <URL:news:er4nad$3108$1@ns.felk.cvut.cz>:
`` "Abigail" <abigail@abigail.be> píse v diskusním príspevku
`` news:slrnetaqep.ijp.abigail@alexandra.abigail.be...
`` > cmic (cmic@caramail.com) wrote on MMMMCMXVI September MCMXCIII in
`` > <URL:news:1171579379.110397.135680@v33g2000cwv.googlegroups.com>:
`` > :: Hello
`` > ::
`` > :: On 14 fév, 22:55, Abigail <abig...@abigail.be> wrote:
`` > :: > use 5.9.5; # In fact, you need the newest blead.
`` > :: >
`` > :: ...skipped
`` > :: > --
`` > :: > perl -wlpe '}{$_=$.}{' file # Count the number of lines.
`` > :: ^^^^^^^^^^^^^
`` > ::
`` > :: As a Perl beginner, i'm a bit surprised to see this working. Could you
`` > :: explain why (and how) these "counter-intuitive" } and { works ? And
`` >
`` > See perlrun, or do a google search for it. It has been explained
`` > many times.
`` >
`` Can you post here some link to pages where this is explained? I have Perl
`` 5.6.1 and code not work for me, I haven't perldoc for 5.9.5 and google not
`` accept these characters in search phrase.
The sig works for Perl 5.000 and all versions since.
Abigail
--
srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"
------------------------------
Date: Fri, 16 Feb 2007 21:39:50 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Sending a local attachment via email form
Message-Id: <er58f9.1co.1@news.isolution.nl>
john.swilting schreef:
> #!/usr/bin/perl -w
>
> use strict;
Better:
#!/usr/bin/perl
use warnings; # see perllexwarn
use strict;
> my $info = $attachement;
> $info = $ue->fileinfo;
Why set $info twice?
> my $dumper = print Dumper $info;
Why set $dumper to the return value of print?
> }elsif($attachement eq undef){
ITYM:
}
elsif (!defined $attachement) {
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 16 Feb 2007 21:43:58 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: set a variable with a specified element of an array...and all elements that follows
Message-Id: <er58on.9g.1@news.isolution.nl>
Mirco Wahab schreef:
> # concatenate elements into string
> my $over7s = join ',', @array[$index-1 .. @array-1];
ITYM:
my $over7s = join ',', @array[$index-1 .. $#array];
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 16 Feb 2007 21:31:07 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Uninstall a module?
Message-Id: <f05ct2d0v1o37ocrrm3047m3aiidugakb5@4ax.com>
On Thu, 15 Feb 2007 14:40:29 -0800, merlyn@stonehenge.com (Randal L.
Schwartz) wrote:
>The CPAN and CPANPLUS installers are just that... installers. They are not
>package managers, although they have a bit of dependency-chasing built in.
>(And they can never be package managers, because they don't care if two
>different CPAN distros both write to the same file.)
>
>Your only safe bet is to roll back via some other mechanism, like a backup
>archive.
However CPANPLUS has a mechanism for creating (Linux) distro specific
packages on the fly. Probably this is not the case for the OP. But if
one is under Linux and uses this feature, then he may use his distro's
specific package managing tool(s) to uninstall modules. Never tried,
just guessing!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 16 Feb 2007 21:06:29 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Uninstall a module?
Message-Id: <u47ct2paarju10ujnhfejkpc2sb7ucdi2i@4ax.com>
Tracey wrote:
>I force installed DBD::mysql when I shouldn't have and have broken
>just about everything I had running on this particular server. I'm
>getting 'perl:relocation error' all over the place. Any idea how I
>restore this or uninstall it and get my server back to normal?
You may try to partially install it again, at least, make it. That way
you can see what files are added, and then, delete them manually.
But of course, that won't restore the files you accidently overwrite.
Your best option, in that case, is to install an older version of the
DBD::mysql module, but this time, do it properly. Well, unless you
happend to have a backup archive ready...
--
Bart.
------------------------------
Date: 16 Feb 2007 15:04:49 -0800
From: "gf" <greg.ferguson@icrossing.com>
Subject: Re: Uninstall a module?
Message-Id: <1171667089.221531.319230@l53g2000cwa.googlegroups.com>
On Feb 15, 3:40 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> Your only safe bet is to roll back via some other mechanism, like a backup
> archive.
That makes me think that cpan's autobundle command might come in
handy.
(That's cpan the app, not CPAN the site.)
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 146
**************************************
