[31308] in Perl-Users-Digest
Perl-Users Digest, Issue: 2553 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 15 00:14:19 2009
Date: Fri, 14 Aug 2009 21:14:11 -0700 (PDT)
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, 14 Aug 2009 Volume: 11 Number: 2553
Today's topics:
Recursion and ${*digit*} variables <google@markginsburg.com>
Re: Recursion and ${*digit*} variables <ben@morrow.me.uk>
Re: Recursion and ${*digit*} variables <derykus@gmail.com>
Re: Recursion and ${*digit*} variables <google@markginsburg.com>
Re: Recursion and ${*digit*} variables <derykus@gmail.com>
Re: Recursion and ${*digit*} variables <derykus@gmail.com>
Re: Recursion and ${*digit*} variables <derykus@gmail.com>
Re: Recursion and ${*digit*} variables sln@netherlands.com
Re: Recursion and ${*digit*} variables sln@netherlands.com
Re: Recursion and ${*digit*} variables sln@netherlands.com
Re: Recursion and ${*digit*} variables <nat.k@gm.ml>
Re: Script Hangs on use Win32::OLE::Const <nospam@somewhere.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Aug 2009 11:49:39 -0700 (PDT)
From: Mark <google@markginsburg.com>
Subject: Recursion and ${*digit*} variables
Message-Id: <d89fff8b-48bf-4fee-9d7d-26f848dd0f60@o6g2000yqj.googlegroups.com>
It appears that new ${*digit*} variables are not created when the same
subroutine is re-entered. Is this to be expected?
use strict ;
use warnings;
my $line = 'abc';
doit();
exit;
sub doit {
# local($1); # adding this doesn't appear to have an effect
$line =~ /(.)/ || die "no match";
print "bef \$1 =$1\n";
$line = substr($line,1);
doit() if length($line);
my $thing = $1; # WRONG! $1 has been changed by recursive call to
doit()
print "aft \$1 =$1\n";
}
Output:
bef $1 =a
bef $1 =b
bef $1 =c
aft $1 =c
aft $1 =c
aft $1 =c
Expected output:
bef $1 =a
bef $1 =b
bef $1 =c
aft $1 =c
aft $1 =b
aft $1 =a
------------------------------
Date: Fri, 14 Aug 2009 22:22:19 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <b51hl6-rvf1.ln1@osiris.mauzo.dyndns.org>
Quoth Mark <google@markginsburg.com>:
> It appears that new ${*digit*} variables are not created when the same
> subroutine is re-entered. Is this to be expected?
I would expect any sub call (that performed a successful match) to
clobber $N. Is that not the case?
Ben
------------------------------
Date: Fri, 14 Aug 2009 14:46:58 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <5bba8df6-5117-48a4-a565-2e5beaef546a@a37g2000prf.googlegroups.com>
On Aug 14, 11:49=A0am, Mark <goo...@markginsburg.com> wrote:
> It appears that new ${*digit*} variables are not created when the same
> subroutine is re-entered. =A0Is this to be expected?
>
> use strict ;
> use warnings;
>
> my $line =3D 'abc';
> doit();
> exit;
>
> sub doit {
> # =A0 local($1); =A0# adding this doesn't appear to have an effect
> =A0 =A0 $line =3D~ /(.)/ || die "no match";
> =A0 =A0 print "bef \$1 =A0=3D$1\n";
>
> =A0 =A0 $line =3D substr($line,1);
> =A0 =A0 doit() if length($line);
>
> =A0 =A0 my $thing =3D $1; # WRONG! $1 has been changed by recursive call =
to
> doit()
>
> =A0 =A0 print "aft \$1 =A0=3D$1\n";
>
> }
>
> Output:
> bef $1 =A0=3Da
> bef $1 =A0=3Db
> bef $1 =A0=3Dc
> aft $1 =A0=3Dc
> aft $1 =A0=3Dc
> aft $1 =A0=3Dc
>
> Expected output:
> bef $1 =A0=3Da
> bef $1 =A0=3Db
> bef $1 =A0=3Dc
> aft $1 =A0=3Dc
> aft $1 =A0=3Db
> aft $1 =A0=3Da
No, this came up in a recent thread. Even if a match fails
within a given scope, a previously successful backref isn't
cleared:
my $s=3D'a';
for (1..2){
print $s=3D~/(.)/ ? "match:$1" : "no match:$1";
$s=3Dsubstr($s,1);
}
__END__
match:a
no match:a
--
Charles DeRykus
------------------------------
Date: Fri, 14 Aug 2009 16:10:30 -0700 (PDT)
From: Mark <google@markginsburg.com>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <1e488072-20dd-444e-a2db-f2ecb38b820b@2g2000prl.googlegroups.com>
> I would expect any sub call (that performed a successful match) to
> clobber $N. Is that not the case?
No, I don't believe that is the case. When I remove the recursion, it
works as I expect, the local $N retains its value.
For example:
use strict ;
use warnings;
my $line = 'abc';
doit();
exit;
sub doit {
$line =~ /(.)/ || die "no match";
print "bef1 \$1 =$1\n";
$line = substr($line,1);
doit2() if length($line);
print "aft1 \$1 =$1\n";
}
sub doit2 {
$line =~ /(.)/ || die "no match";
print "bef2 \$1 =$1\n";
$line = substr($line,1);
print "aft2 \$1 =$1\n";
}
Output:
bef1 $1 =a
bef2 $1 =b
aft2 $1 =b
aft1 $1 =a
------------------------------
Date: Fri, 14 Aug 2009 16:17:32 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <ffaa7b1b-cf31-4a61-b1e3-010316024202@l5g2000pra.googlegroups.com>
On Aug 14, 2:46=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
> On Aug 14, 11:49=A0am, Mark <goo...@markginsburg.com> wrote:
>
>
>
> > It appears that new ${*digit*} variables are not created when the same
> > subroutine is re-entered. =A0Is this to be expected?
>
> > use strict ;
> > use warnings;
>
> > my $line =3D 'abc';
> > doit();
> > exit;
>
> > sub doit {
> > # =A0 local($1); =A0# adding this doesn't appear to have an effect
> > =A0 =A0 $line =3D~ /(.)/ || die "no match";
> > =A0 =A0 print "bef \$1 =A0=3D$1\n";
>
> > =A0 =A0 $line =3D substr($line,1);
> > =A0 =A0 doit() if length($line);
>
> > =A0 =A0 my $thing =3D $1; # WRONG! $1 has been changed by recursive cal=
l to
> > doit()
>
> > =A0 =A0 print "aft \$1 =A0=3D$1\n";
>
> > }
>
> > Output:
> > bef $1 =A0=3Da
> > bef $1 =A0=3Db
> > bef $1 =A0=3Dc
> > aft $1 =A0=3Dc
> > aft $1 =A0=3Dc
> > aft $1 =A0=3Dc
>
> > Expected output:
> > bef $1 =A0=3Da
> > bef $1 =A0=3Db
> > bef $1 =A0=3Dc
> > aft $1 =A0=3Dc
> > aft $1 =A0=3Db
> > aft $1 =A0=3Da
>
> No, this came up in a recent thread. Even if a match fails
> within a given scope, a previously successful backref isn't
> cleared:
>
> my $s=3D'a';
> for (1..2){
> =A0 print $s=3D~/(.)/ ? "match:$1" : "no match:$1";
> =A0 $s=3Dsubstr($s,1);}
>
> __END__
>
> match:a
> no match:a
Just to expand that explanation a bit more:
sub doit {
$line =3D~ /(.)/ || die "no match";
print "bef \$1 =3D$1\n"; # matches succeed initially
$line =3D substr($line,1); # as $line gets emptied
doit() if length($line); # and doit() recurses
my $thing =3D $1; # WRONG! ..
print "aft \$1 =3D$1\n";
}
By the time the recursion starts to unwind, $line has
been drained and the match fails. Because the final "c"
matched successfully though, $1 doesn't get cleared.
So you see the trailing series of "c" printed.
--
Charles DeRykus
------------------------------
Date: Fri, 14 Aug 2009 16:32:14 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <5726be03-5715-4b54-8558-62593419b79d@g1g2000pra.googlegroups.com>
On Aug 14, 4:17=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
> On Aug 14, 2:46=A0pm, "C.DeRykus" <dery...@gmail.com> wrote:
>
>
>
> > On Aug 14, 11:49=A0am, Mark <goo...@markginsburg.com> wrote:
>
> > > It appears that new ${*digit*} variables are not created when the sam=
e
> > > subroutine is re-entered. =A0Is this to be expected?
>
> > > use strict ;
> > > use warnings;
>
> > > my $line =3D 'abc';
> > > doit();
> > > exit;
>
> > > sub doit {
> > > # =A0 local($1); =A0# adding this doesn't appear to have an effect
> > > =A0 =A0 $line =3D~ /(.)/ || die "no match";
> > > =A0 =A0 print "bef \$1 =A0=3D$1\n";
>
> > > =A0 =A0 $line =3D substr($line,1);
> > > =A0 =A0 doit() if length($line);
>
> > > =A0 =A0 my $thing =3D $1; # WRONG! $1 has been changed by recursive c=
all to
> > > doit()
>
> > > =A0 =A0 print "aft \$1 =A0=3D$1\n";
>
> > > }
>
> > > Output:
> > > bef $1 =A0=3Da
> > > bef $1 =A0=3Db
> > > bef $1 =A0=3Dc
> > > aft $1 =A0=3Dc
> > > aft $1 =A0=3Dc
> > > aft $1 =A0=3Dc
>
> > > Expected output:
> > > bef $1 =A0=3Da
> > > bef $1 =A0=3Db
> > > bef $1 =A0=3Dc
> > > aft $1 =A0=3Dc
> > > aft $1 =A0=3Db
> > > aft $1 =A0=3Da
>
> > No, this came up in a recent thread. Even if a match fails
> > within a given scope, a previously successful backref isn't
> > cleared:
>
> > my $s=3D'a';
> > for (1..2){
> > =A0 print $s=3D~/(.)/ ? "match:$1" : "no match:$1";
> > =A0 $s=3Dsubstr($s,1);}
>
> > __END__
>
> > match:a
> > no match:a
>
> Just to expand that explanation a bit more:
>
> sub doit {
> =A0 $line =3D~ /(.)/ || die "no match";
>
> =A0 print "bef \$1 =A0=3D$1\n"; =A0 =A0# matches succeed initially
> =A0 $line =3D substr($line,1); =A0 # as $line gets emptied
> =A0 doit() if length($line); =A0 # and doit() recurses
> =A0 my $thing =3D $1; # WRONG! ..
>
> =A0 print "aft \$1 =A0=3D$1\n";
>
> }
>
> By the time the recursion starts to unwind, $line has
> been drained and the match fails. Because the final "c"
> matched successfully though, $1 doesn't get cleared.
> So you see the trailing series of "c" printed.
>
No. I need to rethink that...
--
Charles DeRykus
------------------------------
Date: Fri, 14 Aug 2009 17:29:17 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <dc1a27d7-07b4-4a8e-8196-5973e2ee6308@f20g2000prn.googlegroups.com>
On Aug 14, 4:10=A0pm, Mark <goo...@markginsburg.com> wrote:
> > I would expect any sub call (that performed a successful match) to
> > clobber $N. Is that not the case?
>
> No, I don't believe that is the case. =A0When I remove the recursion, it
> works as I expect, the local $N retains its value.
> For example:
>
> use strict ;
> use warnings;
>
> my $line =3D 'abc';
>
> doit();
>
> exit;
>
> sub doit {
> =A0 =A0 $line =3D~ /(.)/ || die "no match";
> =A0 =A0 print "bef1 \$1 =A0=3D$1\n";
>
> =A0 =A0 $line =3D substr($line,1);
> =A0 =A0 doit2() if length($line);
>
> =A0 =A0 print "aft1 \$1 =A0=3D$1\n";
>
> }
>
> sub doit2 {
> =A0 =A0 $line =3D~ /(.)/ || die "no match";
> =A0 =A0 print "bef2 \$1 =A0=3D$1\n";
>
> =A0 =A0 $line =3D substr($line,1);
>
> =A0 =A0 print "aft2 \$1 =A0=3D$1\n";
>
> }
>
> Output:
> bef1 $1 =A0=3Da
> bef2 $1 =A0=3Db
> aft2 $1 =A0=3Db
> aft1 $1 =A0=3Da
Hopefully I'm not mis-firing again but doit2() would introduce
a new scope with its own set of $N matches which won't be affected
by successful matches in other scopes. But in doit()'s scope,
successful $N matches self-clobber as mentioned.
--
Charles DeRykus
------------------------------
Date: Fri, 14 Aug 2009 18:16:28 -0700
From: sln@netherlands.com
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <ob2c85lgks22d0tm9qnn0tnodj91i4jhqh@4ax.com>
On Fri, 14 Aug 2009 11:49:39 -0700 (PDT), Mark <google@markginsburg.com> wrote:
>It appears that new ${*digit*} variables are not created when the same
>subroutine is re-entered. Is this to be expected?
>
>use strict ;
>use warnings;
>
>my $line = 'abc';
>doit();
>exit;
>
>sub doit {
># local($1); # adding this doesn't appear to have an effect
> $line =~ /(.)/ || die "no match";
> print "bef \$1 =$1\n";
>
> $line = substr($line,1);
> doit() if length($line);
>
> my $thing = $1; # WRONG! $1 has been changed by recursive call to
>doit()
>
> print "aft \$1 =$1\n";
>}
>
>
>Output:
>bef $1 =a
>bef $1 =b
>bef $1 =c
>aft $1 =c
>aft $1 =c
>aft $1 =c
>
>Expected output:
>bef $1 =a
>bef $1 =b
>bef $1 =c
>aft $1 =c
>aft $1 =b
>aft $1 =a
Apparently there is only 1 set of N vars per scope,
looks like its set at compile time.
So you can't stack them in the way of a recursion.
This seems to hold down memory consumption and the cost
of state.
Usually, when you recurse a function, everything starts a new.
A new regular expression evaluation and gleaning results.
In that scope, the last N vars are retained, the results aren't
stacked.
The results you obtained are not faulty, nor the result of a bad match.
The last state of N vars were retained when the stack unwound.
Remember, 1 scope, 1 set of N vars.
Poor example follows.
-sln
======================================================
Output:
sub b - before = b
sub c - before = c
sub d - before = d
sub e - before = e(e)
sub d - before = d
sub e - before = f(f)
sub d - before = d
sub e - before = g(g)
sub d - before = d
sub e - before = h(h)
sub e - after = h(h)
sub d - after = d
sub e - after = h(g)
sub d - after = d
sub e - after = h(f)
sub d - after = d
sub e - after = h(e)
sub d - after = d
sub c - after = c
sub b - after = b
========================================================
use strict ;
use warnings;
my $cnt = 0;
my $regx = qr/(.)/;
$cnt = 0;
my $Estr = 'e';
b();
sub b
{
my $str = 'b';
$str =~ /$regx/;
print "sub b - before = $1\n";
c();
print "sub b - after = $1\n";
}
sub c
{
my $str = 'c';
$str =~ /$regx/;
print "sub c - before = $1\n";
d();
print "sub c - after = $1\n";
}
sub d
{
my $str = 'd';
$str =~ /$regx/;
print "sub d - before = $1\n";
e();
print "sub d - after = $1\n";
}
sub e
{
++$Estr if (++$cnt > 1);
$Estr =~ /$regx/;
my $tmp = $1;
print "sub e - before = $1($tmp)\n";
print "\n" if ($cnt >= 4);
d() if ($cnt < 4);
print "sub e - after = $1($tmp)\n";
}
------------------------------
Date: Fri, 14 Aug 2009 18:30:51 -0700
From: sln@netherlands.com
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <el3c85dmvkp027rsenfmecq2uphmnj0f05@4ax.com>
On Fri, 14 Aug 2009 16:17:32 -0700 (PDT), "C.DeRykus" <derykus@gmail.com> wrote:
>On Aug 14, 2:46 pm, "C.DeRykus" <dery...@gmail.com> wrote:
>> On Aug 14, 11:49 am, Mark <goo...@markginsburg.com> wrote:
>>
>>
>>
>> > It appears that new ${*digit*} variables are not created when the same
>> > subroutine is re-entered. Is this to be expected?
>>
>> > use strict ;
>> > use warnings;
>>
>> > my $line = 'abc';
>> > doit();
>> > exit;
>>
>> > sub doit {
>> > # local($1); # adding this doesn't appear to have an effect
>> > $line =~ /(.)/ || die "no match";
>> > print "bef \$1 =$1\n";
>>
>> > $line = substr($line,1);
>> > doit() if length($line);
>>
>> > my $thing = $1; # WRONG! $1 has been changed by recursive call to
>> > doit()
>>
>> > print "aft \$1 =$1\n";
>>
>> > }
>>
>> > Output:
>> > bef $1 =a
>> > bef $1 =b
>> > bef $1 =c
>> > aft $1 =c
>> > aft $1 =c
>> > aft $1 =c
>>
>> > Expected output:
>> > bef $1 =a
>> > bef $1 =b
>> > bef $1 =c
>> > aft $1 =c
>> > aft $1 =b
>> > aft $1 =a
>>
>> No, this came up in a recent thread. Even if a match fails
>> within a given scope, a previously successful backref isn't
>> cleared:
>>
>> my $s='a';
>> for (1..2){
>> print $s=~/(.)/ ? "match:$1" : "no match:$1";
>> $s=substr($s,1);}
>>
>> __END__
>>
>> match:a
>> no match:a
>
>
>Just to expand that explanation a bit more:
>
>sub doit {
> $line =~ /(.)/ || die "no match";
>
> print "bef \$1 =$1\n"; # matches succeed initially
> $line = substr($line,1); # as $line gets emptied
> doit() if length($line); # and doit() recurses
> my $thing = $1; # WRONG! ..
>
> print "aft \$1 =$1\n";
>}
>
>By the time the recursion starts to unwind, $line has
>been drained and the match fails. Because the final "c"
>matched successfully though, $1 doesn't get cleared.
>So you see the trailing series of "c" printed.
Matching had nothing to do with why his $1 contained 'c'
when the stack unwound.
The reason is he keeps reenterring the same scope block.
In terms of N vars, there is only one scope block so
the N vars keep thier last state.
N var state is not stacked, it only has scope.
-sln
------------------------------
Date: Fri, 14 Aug 2009 18:34:00 -0700
From: sln@netherlands.com
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <uv3c85l7ibklv2lk5c4d7359qvhugrdnj7@4ax.com>
On Fri, 14 Aug 2009 18:30:51 -0700, sln@netherlands.com wrote:
>On Fri, 14 Aug 2009 16:17:32 -0700 (PDT), "C.DeRykus" <derykus@gmail.com> wrote:
>
>>On Aug 14, 2:46 pm, "C.DeRykus" <dery...@gmail.com> wrote:
>>> On Aug 14, 11:49 am, Mark <goo...@markginsburg.com> wrote:
>>>
>>>
>>>
>>> > It appears that new ${*digit*} variables are not created when the same
>>> > subroutine is re-entered. Is this to be expected?
>>>
>>> > use strict ;
>>> > use warnings;
>>>
>>> > my $line = 'abc';
>>> > doit();
>>> > exit;
>>>
>>> > sub doit {
>>> > # local($1); # adding this doesn't appear to have an effect
>>> > $line =~ /(.)/ || die "no match";
>>> > print "bef \$1 =$1\n";
>>>
>>> > $line = substr($line,1);
>>> > doit() if length($line);
>>>
>>> > my $thing = $1; # WRONG! $1 has been changed by recursive call to
>>> > doit()
>>>
>>> > print "aft \$1 =$1\n";
>>>
>>> > }
>>>
>>> > Output:
>>> > bef $1 =a
>>> > bef $1 =b
>>> > bef $1 =c
>>> > aft $1 =c
>>> > aft $1 =c
>>> > aft $1 =c
>>>
>>> > Expected output:
>>> > bef $1 =a
>>> > bef $1 =b
>>> > bef $1 =c
>>> > aft $1 =c
>>> > aft $1 =b
>>> > aft $1 =a
>>>
>>> No, this came up in a recent thread. Even if a match fails
>>> within a given scope, a previously successful backref isn't
>>> cleared:
>>>
>>> my $s='a';
>>> for (1..2){
>>> print $s=~/(.)/ ? "match:$1" : "no match:$1";
>>> $s=substr($s,1);}
>>>
>>> __END__
>>>
>>> match:a
>>> no match:a
>>
>>
>>Just to expand that explanation a bit more:
>>
>>sub doit {
>> $line =~ /(.)/ || die "no match";
>>
>> print "bef \$1 =$1\n"; # matches succeed initially
>> $line = substr($line,1); # as $line gets emptied
>> doit() if length($line); # and doit() recurses
>> my $thing = $1; # WRONG! ..
>>
>> print "aft \$1 =$1\n";
>>}
>>
>>By the time the recursion starts to unwind, $line has
>>been drained and the match fails. Because the final "c"
>>matched successfully though, $1 doesn't get cleared.
>>So you see the trailing series of "c" printed.
>
>Matching had nothing to do with why his $1 contained 'c'
>when the stack unwound.
>
>The reason is he keeps reenterring the same scope block.
>In terms of N vars, there is only one scope block so
>the N vars keep thier last state.
>
>N var state is not stacked, it only has scope.
>
>-sln
Aparently, for the N vars, the scope remained the same, it
never left. Kind of makes sense.
-sln
------------------------------
Date: Fri, 14 Aug 2009 20:13:04 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Recursion and ${*digit*} variables
Message-Id: <4Jphm.143341$zq1.19819@newsfe22.iad>
sln@netherlands.com wrote:
> Aparently, for the N vars, the scope remained the same, it
> never left. Kind of makes sense.
> -sln
Apparently you forgot how to snip huge quotes for a few word reply.
------------------------------
Date: Fri, 14 Aug 2009 18:54:37 -0400
From: "Thrill5" <nospam@somewhere.com>
Subject: Re: Script Hangs on use Win32::OLE::Const
Message-Id: <h64qfe$bls$1@news.eternal-september.org>
"TomW" <thomas.e.welch@boeing.com> wrote in message
news:938e70a3-5ba3-41b7-ba61-f959ac9b1d86@w6g2000yqw.googlegroups.com...
> I've been using win32::ole for some time to automate PowerPoint
> (Office 2003) on a server. I know it's not recommended but I'm stuck
> with it. It's been working well for several years but sometime over
> the last few days it stopped working. I've tracked down the possible
> problem to this statement:
>
> use Win32::OLE::Const 'Microsoft Office 11.0 Object Library';
>
> For some unknown reason the above statement now causes the script to
> hang. It will eventually time out. I'm at a total loss as to why
> this is happening. The version of office has not changed. I even
> reinstalled Perl from a clean image and it still hangs. Has anyone
> ever encountered anything like this ? I have checked the event viewer
> and there is no record of any error. Could it be the module is now
> unable to communicate with PowerPoint and that causes the hang up ?
> I'm stumped. Thanks in advance for any help.
Have you installed any OS or Office patches on the server lately? The Win32
modules are wrappers to call Windows DLL subroutines and a patch could have
disabled some functionality or broken something.
------------------------------
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 2553
***************************************
