[32678] in Perl-Users-Digest
Perl-Users Digest, Issue: 3954 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 24 14:14:25 2013
Date: Fri, 24 May 2013 11:14:15 -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, 24 May 2013 Volume: 11 Number: 3954
Today's topics:
Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <rvtol+usenet@xs4all.nl>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <ben@morrow.me.uk>
Re: Signals and local $@ <rvtol+usenet@xs4all.nl>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <rweikusat@mssgmbh.com>
Re: Signals and local $@ <rweikusat@mssgmbh.com>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <ben@morrow.me.uk>
Re: Signals and local $@ <ben@morrow.me.uk>
Re: Signals and local $@ <rweikusat@mssgmbh.com>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Signals and local $@ <adrien.barreau@live.fr>
Re: Would anyone teach me perl? <dailey.kohtz@gmail.com>
Re: Would anyone teach me perl? <jurgenex@hotmail.com>
Re: Would anyone teach me perl? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 24 May 2013 13:05:33 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Signals and local $@
Message-Id: <knnha4$el9$1@dont-email.me>
Hello all.
I'm trying to write a little wrapper which properly handles a call with
a timeout.
Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
or less take some parts of Try::Tiny ideas just to do a proper eval).
Here is the thing I don't know how to deal with.
# ---
#!/usr/bin/perl
use strict;
use warnings;
sub sleep10
{
local $@;
sleep 10;
}
{
eval {
local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
alarm 2;
sleep10();
};
alarm 0;
print "Err: $@\n";
}
# ---
That script does its timeout after 2 seconds, but prints "Err :".
I don't find a way not to loose my handler error message if the code I
try to protect localize $@.
I don't even know if I have a chance to achieve that.
Might somebody help me a bit about that? :)
Thanks.
Adrien.
------------------------------
Date: Fri, 24 May 2013 15:08:16 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Signals and local $@
Message-Id: <519f6641$0$15938$e4fe514c@news2.news.xs4all.nl>
On 24/05/2013 13:05, Adrien BARREAU wrote:
> Hello all.
>
>
> I'm trying to write a little wrapper which properly handles a call with
> a timeout.
>
> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
> or less take some parts of Try::Tiny ideas just to do a proper eval).
>
> Here is the thing I don't know how to deal with.
>
> # ---
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> sub sleep10
> {
> local $@;
> sleep 10;
> }
>
> {
> eval {
> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
> alarm 2;
> sleep10();
> };
>
> alarm 0;
> print "Err: $@\n";
> }
> # ---
>
> That script does its timeout after 2 seconds, but prints "Err :".
> I don't find a way not to loose my handler error message if the code I
> try to protect localize $@.
> I don't even know if I have a chance to achieve that.
>
> Might somebody help me a bit about that? :)
You are doing many things wrong in the above. Try::Tiny is meant for
coders that don't know how to do it properly, so why don't you just use
that?
Be aware that (the value of) $@ has no meaning, unless there has been an
error detected.
my $ok;
eval {
$ok = can_die();
1; # success
}
or do {
my $eval_error = $@ || 'Zombie Error';
warn $eval_error;
};
So only use $@ when eval{} tells you that you can.
--
Ruud
In stead of 'local $@', consider push @@, $@;
------------------------------
Date: Fri, 24 May 2013 16:13:33 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <knnsak$cop$1@dont-email.me>
On 05/24/2013 03:08 PM, Dr.Ruud wrote:
> On 24/05/2013 13:05, Adrien BARREAU wrote:
>> Hello all.
>>
>>
>> I'm trying to write a little wrapper which properly handles a call with
>> a timeout.
>>
>> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
>> or less take some parts of Try::Tiny ideas just to do a proper eval).
>>
>> Here is the thing I don't know how to deal with.
>>
>> # ---
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> sub sleep10
>> {
>> local $@;
>> sleep 10;
>> }
>>
>> {
>> eval {
>> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
>> alarm 2;
>> sleep10();
>> };
>>
>> alarm 0;
>> print "Err: $@\n";
>> }
>> # ---
>>
>> That script does its timeout after 2 seconds, but prints "Err :".
>> I don't find a way not to loose my handler error message if the code I
>> try to protect localize $@.
>> I don't even know if I have a chance to achieve that.
>>
>> Might somebody help me a bit about that? :)
>
> You are doing many things wrong in the above. Try::Tiny is meant for
> coders that don't know how to do it properly, so why don't you just use
> that?
Well, at first, if I never learn, I'll never know, will I?
And I can not install Try::Tiny. If it had been an option, I wouldn't
have tried by myself.
>
> Be aware that (the value of) $@ has no meaning, unless there has been an
> error detected.
>
>
> my $ok;
>
> eval {
> $ok = can_die();
> 1; # success
> }
> or do {
> my $eval_error = $@ || 'Zombie Error';
> warn $eval_error;
> };
>
> So only use $@ when eval{} tells you that you can.
>
>
I'm not thinking something else.
It seems that my code works, and follows the same pattern you just wrote.
The only thing that troubles me is the very case I wrote: if "can_die()"
localize $@ and receive a signal that makes it die.
Thanks for responding :).
------------------------------
Date: Fri, 24 May 2013 15:36:02 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Signals and local $@
Message-Id: <ifa47a-0cn2.ln1@anubis.morrow.me.uk>
Quoth Adrien BARREAU <adrien.barreau@live.fr>:
> On 05/24/2013 03:08 PM, Dr.Ruud wrote:
> > On 24/05/2013 13:05, Adrien BARREAU wrote:
> >>
> >> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
> >> or less take some parts of Try::Tiny ideas just to do a proper eval).
> >
> > You are doing many things wrong in the above. Try::Tiny is meant for
> > coders that don't know how to do it properly, so why don't you just use
> > that?
>
> Well, at first, if I never learn, I'll never know, will I?
> And I can not install Try::Tiny. If it had been an option, I wouldn't
> have tried by myself.
Try::Tiny is one .pm file. If you can run perl at all you can install it
somewhere and add that somewhere to @INC.
Ben
------------------------------
Date: Fri, 24 May 2013 16:51:17 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Signals and local $@
Message-Id: <519f7e65$0$15893$e4fe514c@news2.news.xs4all.nl>
On 24/05/2013 16:13, Adrien BARREAU wrote:
> On 05/24/2013 03:08 PM, Dr.Ruud wrote:
>> So only use $@ when eval{} tells you that you can.
>
> I'm not thinking something else.
Your code shows differently.
> It seems that my code works, and follows the same pattern you just wrote.
It doesn't.
> The only thing that troubles me is the very case I wrote: if "can_die()"
> localize $@ and receive a signal that makes it die.
If that troubles you, then go and find out what localize does.
After that: Why are you localizing $@?
--
Ruud
------------------------------
Date: Fri, 24 May 2013 17:21:54 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno0ap$4fa$1@dont-email.me>
On 05/24/2013 04:36 PM, Ben Morrow wrote:
>
> Quoth Adrien BARREAU<adrien.barreau@live.fr>:
>> On 05/24/2013 03:08 PM, Dr.Ruud wrote:
>>> On 24/05/2013 13:05, Adrien BARREAU wrote:
>>>>
>>>> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
>>>> or less take some parts of Try::Tiny ideas just to do a proper eval).
>>>
>>> You are doing many things wrong in the above. Try::Tiny is meant for
>>> coders that don't know how to do it properly, so why don't you just use
>>> that?
>>
>> Well, at first, if I never learn, I'll never know, will I?
>> And I can not install Try::Tiny. If it had been an option, I wouldn't
>> have tried by myself.
>
> Try::Tiny is one .pm file. If you can run perl at all you can install it
> somewhere and add that somewhere to @INC.
>
> Ben
>
Of course, but this is meant to run on some computer where adding new
CPAN files is not an option.
That's not my choice and I can't help it.
So it became a precondition: I must do without it.
Adrien.
------------------------------
Date: Fri, 24 May 2013 17:27:45 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno0lo$68g$1@dont-email.me>
On 05/24/2013 04:51 PM, Dr.Ruud wrote:
> On 24/05/2013 16:13, Adrien BARREAU wrote:
>> On 05/24/2013 03:08 PM, Dr.Ruud wrote:
>
>>> So only use $@ when eval{} tells you that you can.
>>
>> I'm not thinking something else.
>
> Your code shows differently.
>
>
>> It seems that my code works, and follows the same pattern you just wrote.
>
> It doesn't.
>
>
>> The only thing that troubles me is the very case I wrote: if "can_die()"
>> localize $@ and receive a signal that makes it die.
>
> If that troubles you, then go and find out what localize does.
> After that: Why are you localizing $@?
>
My introduction was: "I'm trying to write a little wrapper which
properly handles a call with a timeout.".
Some forgotten detail: "a call" meant "a call I don't write".
It's meant to be a little part of some API, somewhere.
I found that, if there is a localization of $@ in "the call", my wrapper
fails.
I'm trying to figure if I can do better. Nothing more.
Adrien.
------------------------------
Date: Fri, 24 May 2013 16:32:12 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Signals and local $@
Message-Id: <87vc68qtqb.fsf@sapphire.mobileactivedefense.com>
"Dr.Ruud" <rvtol+usenet@xs4all.nl> writes:
[...]
> Be aware that (the value of) $@ has no meaning, unless there has been
> an error detected.
Please be aware of the fact that this it absolute, total, utter
rubbish, cf
If there is a syntax error or runtime error, or a "die"
statement is executed, "eval" returns an undefined value in
scalar context or an empty list in list context, and $@ is set
to the error message. If there was no error, $@ is guaranteed
to be a null string.
[perdoc -f eval]
In particular, eval might return 'an undefined value or an empty list'
for other reasons than 'an error occured', namely, when the last
statement executed by the eval returned undef.
------------------------------
Date: Fri, 24 May 2013 16:46:11 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Signals and local $@
Message-Id: <87hahsqt30.fsf@sapphire.mobileactivedefense.com>
Adrien BARREAU <adrien.barreau@live.fr> writes:
[...]
> I'm trying to write a little wrapper which properly handles a call
> with a timeout.
>
> Since I'm on a 5.10.1, I take care of all eval{} pitfalls I know (more
> or less take some parts of Try::Tiny ideas just to do a proper eval).
>
> Here is the thing I don't know how to deal with.
>
> # ---
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> sub sleep10
> {
> local $@;
> sleep 10;
> }
>
> {
> eval {
> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
> alarm 2;
> sleep10();
> };
>
> alarm 0;
> print "Err: $@\n";
> }
> # ---
>
> That script does its timeout after 2 seconds, but prints "Err :".
This is inherently racy: With your code above, the SIGALRM could
happend after the handler was deinstalled when exiting the eval but
before the running alarm was cancelled. This would the terminate the
process because the default action for SIGALRM would occur.
The problem with $@ being cleared can be fixed by removing the 'local $@'
from the sleep10 routine:
----------------
#!/usr/bin/perl
use strict;
use warnings;
sub sleep10
{
sleep 10;
}
{
eval {
local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
alarm 2;
sleep10();
};
alarm 0;
print "Err: $@\n";
};
----------------
because otherwise, assuming the die is executed while sleep10 is
'running', it will modifiy the localized version of $@.
------------------------------
Date: Fri, 24 May 2013 18:22:55 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno3t6$phr$1@dont-email.me>
On 05/24/2013 05:46 PM, Rainer Weikusat wrote:
>
> This is inherently racy: With your code above, the SIGALRM could
> happend after the handler was deinstalled when exiting the eval but
> before the running alarm was cancelled. This would the terminate the
> process because the default action for SIGALRM would occur.
>
> The problem with $@ being cleared can be fixed by removing the 'local $@'
> from the sleep10 routine:
>
> ----------------
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> sub sleep10
> {
> sleep 10;
> }
>
> {
> eval {
> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
> alarm 2;
> sleep10();
> };
>
> alarm 0;
> print "Err: $@\n";
> };
> ----------------
>
> because otherwise, assuming the die is executed while sleep10 is
> 'running', it will modifiy the localized version of $@.
That's what I thought, but I hoped to find a way to protect it.
As far as I understand, none exists. Is that true?
------------------------------
Date: Fri, 24 May 2013 17:58:59 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Signals and local $@
Message-Id: <jri47a-0op2.ln1@anubis.morrow.me.uk>
Quoth Adrien BARREAU <adrien.barreau@live.fr>:
>
> My introduction was: "I'm trying to write a little wrapper which
> properly handles a call with a timeout.".
> Some forgotten detail: "a call" meant "a call I don't write".
> It's meant to be a little part of some API, somewhere.
>
> I found that, if there is a localization of $@ in "the call", my wrapper
> fails.
>
> I'm trying to figure if I can do better. Nothing more.
If you must work around this sort of thing, you can do so by using your
own variable:
sub make_call {
my $alarmed;
$SIG{ALRM} = sub { $alarmed = 1 };
try { ... }
catch {
if ($alarmed) { ... }
};
}
IMHO code which localises $@ without rethrowing any exceptions it
doesn't handle is broken, and you would be better off simply documenting
that this doesn't work.
Ben
------------------------------
Date: Fri, 24 May 2013 17:54:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Signals and local $@
Message-Id: <2ji47a-0op2.ln1@anubis.morrow.me.uk>
Quoth Adrien BARREAU <adrien.barreau@live.fr>:
> On 05/24/2013 04:36 PM, Ben Morrow wrote:
> >
> > Try::Tiny is one .pm file. If you can run perl at all you can install it
> > somewhere and add that somewhere to @INC.
>
> Of course, but this is meant to run on some computer where adding new
> CPAN files is not an option.
> That's not my choice and I can't help it.
>
> So it became a precondition: I must do without it.
So copy the code out of Try/Tiny.pm into your own script.
More generally, this sort of restriction can usually be worked around
with a little thought, and it's usually worth doing so. For instance,
PAR::Packer provides the pp utility, and pp -P will pack a script and
any pure-Perl modules it uses into a single Perl file. (It doesn't
always work perfectly--some modules do some rather strange things--but
it works well for simple cases.)
Ben
------------------------------
Date: Fri, 24 May 2013 18:21:24 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Signals and local $@
Message-Id: <87sj1cpa3v.fsf@sapphire.mobileactivedefense.com>
Adrien BARREAU <adrien.barreau@live.fr> writes:
> On 05/24/2013 05:46 PM, Rainer Weikusat wrote:
>> This is inherently racy: With your code above, the SIGALRM could
>> happend after the handler was deinstalled when exiting the eval but
>> before the running alarm was cancelled. This would the terminate the
>> process because the default action for SIGALRM would occur.
>>
>> The problem with $@ being cleared can be fixed by removing the 'local $@'
>> from the sleep10 routine:
>>
>> ----------------
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>>
>> sub sleep10
>> {
>> sleep 10;
>> }
>>
>> {
>> eval {
>> local $SIG{'ALRM'} = sub { die "Here comes the death\n"; };
>> alarm 2;
>> sleep10();
>> };
>>
>> alarm 0;
>> print "Err: $@\n";
>> };
>> ----------------
>>
>> because otherwise, assuming the die is executed while sleep10 is
>> 'running', it will modifiy the localized version of $@.
>
> That's what I thought, but I hoped to find a way to protect it.
> As far as I understand, none exists. Is that true?
*If* the die is executed while a scope with a localized $@ is active,
it will change the value of the localized $@ and this change will be
undone as part of the stack-unwinding which happens when exiting that
scope.
------------------------------
Date: Fri, 24 May 2013 19:31:05 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno7sv$h3d$1@dont-email.me>
On 05/24/2013 07:21 PM, Rainer Weikusat wrote:
>>>
>>> because otherwise, assuming the die is executed while sleep10 is
>>> 'running', it will modifiy the localized version of $@.
>>
>> That's what I thought, but I hoped to find a way to protect it.
>> As far as I understand, none exists. Is that true?
>
> *If* the die is executed while a scope with a localized $@ is active,
> it will change the value of the localized $@ and this change will be
> undone as part of the stack-unwinding which happens when exiting that
> scope.
>
Thank you for your answers :).
Adrien.
------------------------------
Date: Fri, 24 May 2013 19:33:54 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno829$h3d$2@dont-email.me>
On 05/24/2013 06:54 PM, Ben Morrow wrote:
>
> Quoth Adrien BARREAU<adrien.barreau@live.fr>:
>> On 05/24/2013 04:36 PM, Ben Morrow wrote:
>>>
>>> Try::Tiny is one .pm file. If you can run perl at all you can install it
>>> somewhere and add that somewhere to @INC.
>>
>> Of course, but this is meant to run on some computer where adding new
>> CPAN files is not an option.
>> That's not my choice and I can't help it.
>>
>> So it became a precondition: I must do without it.
>
> So copy the code out of Try/Tiny.pm into your own script.
>
> More generally, this sort of restriction can usually be worked around
> with a little thought, and it's usually worth doing so. For instance,
> PAR::Packer provides the pp utility, and pp -P will pack a script and
> any pure-Perl modules it uses into a single Perl file. (It doesn't
> always work perfectly--some modules do some rather strange things--but
> it works well for simple cases.)
>
> Ben
>
Once again, I agree about that idea, but I'm not allowed to do that either.
I'll take a look to PAR, you described some interesting stuff (for other
developments).
Thanks :).
------------------------------
Date: Fri, 24 May 2013 19:34:51 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Re: Signals and local $@
Message-Id: <kno841$h3d$3@dont-email.me>
On 05/24/2013 06:58 PM, Ben Morrow wrote:
>
> Quoth Adrien BARREAU<adrien.barreau@live.fr>:
>>
>> My introduction was: "I'm trying to write a little wrapper which
>> properly handles a call with a timeout.".
>> Some forgotten detail: "a call" meant "a call I don't write".
>> It's meant to be a little part of some API, somewhere.
>>
>> I found that, if there is a localization of $@ in "the call", my wrapper
>> fails.
>>
>> I'm trying to figure if I can do better. Nothing more.
>
> If you must work around this sort of thing, you can do so by using your
> own variable:
>
> sub make_call {
> my $alarmed;
> $SIG{ALRM} = sub { $alarmed = 1 };
> try { ... }
> catch {
> if ($alarmed) { ... }
> };
> }
>
> IMHO code which localises $@ without rethrowing any exceptions it
> doesn't handle is broken, and you would be better off simply documenting
> that this doesn't work.
>
> Ben
>
I did not think about that variable idea, thanks.
I know the kind of thing I try to protect my code against is very dirty.
I try my best, I'll document everything else, indeed.
Adrien.
------------------------------
Date: Thu, 23 May 2013 16:31:14 -0700 (PDT)
From: Dailey Kohtz <dailey.kohtz@gmail.com>
Subject: Re: Would anyone teach me perl?
Message-Id: <8f67eebb-fb9d-4e96-9bb4-2a7192e9210f@googlegroups.com>
I know I have the books, but I really want some help... like a tutor
------------------------------
Date: Thu, 23 May 2013 19:31:51 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Would anyone teach me perl?
Message-Id: <2hjtp8lv7kon3p5e88p377dkjjar2sh2tg@4ax.com>
Dailey Kohtz <dailey.kohtz@gmail.com> wrote:
>I've practiced enough to do a helloworld program,but I've had trouble. I have the v5 and second adition O'Rielly.
>titles:
>Learning Perl
>Programming Perl
>Perl Cookbook
>----------------------------------------------------------------------------------
> Can anyone put the time in to teaching me to program?
You are aware that "programming" (aka Computer Science) is a
fully-featured university-level degree, are you?
Granted, you don't need a degree in hydro-dynamics to install a water
pipe either, but at the very least you should be very clear to yourself
and to others what exactly you are looking for.
Learning programming: wrong approach and wrong NG. Get some training at
a community college or adult education center or whatever is being
offered in your area. You will be far better off face-to-face with an
actual teacher and well-structured class.
Learning Perl: Well, if you know how to program then Perl is just
another imperative programming language in the tradition of your typical
scripting or shell languages. You should have learned about the typical
concepts of those languages during your programming training.
Reading through Programming Perl will teach you how to code each of
those concept in Perl and while doing so you will also encounter and
learn about Perl-specific features which are not commonly found in other
languages one by one.
> Are you willing to help me even though I'm don't know how?
If you trying to learn Perl and if you don't understand a specific
concept or language feature then -after consulting the usual self-help
like man pages- this NG is a very good place to ask specific, targeted
questions.
jue
------------------------------
Date: Fri, 24 May 2013 03:38:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Would anyone teach me perl?
Message-Id: <bd037a-2rf2.ln1@anubis.morrow.me.uk>
Quoth Dailey Kohtz <dailey.kohtz@gmail.com>:
> I know I have the books, but I really want some help... like a tutor
If you can't learn Perl from Learning Perl you should do the world a
favour and stop trying. I'm sorry if this seems rude, but there are
already far too many people in the world who know just enough
programming to be dangerous without having any real understanding of the
underlying concepts.
Ben
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3954
***************************************
