[22334] in Perl-Users-Digest
Perl-Users Digest, Issue: 4555 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 12 06:10:49 2003
Date: Wed, 12 Feb 2003 03:10:10 -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 Wed, 12 Feb 2003 Volume: 10 Number: 4555
Today's topics:
Re: strict and warnings <tassilo.parseval@post.rwth-aachen.de>
Re: strict and warnings <abigail@abigail.nl>
Re: strict and warnings <tassilo.parseval@post.rwth-aachen.de>
Re: strict and warnings <bart.lateur@pandora.be>
Re: strict and warnings <bart.lateur@pandora.be>
Re: Test if directory is accessable, other Q's (Joe Smith)
Re: Wanted: open source documentation reviewer <murat.uenalan@gmx.de>
Re: Warnings in modules (Tad McClellan)
Re: Warnings in modules <tassilo.parseval@post.rwth-aachen.de>
Re: Warnings in modules <goldbb2@earthlink.net>
Re: Warnings in modules <abigail@abigail.nl>
Re: Warnings in modules <tassilo.parseval@post.rwth-aachen.de>
Wierd error with Java, JNI and embedded perl on linux <jlagrue@netscape.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Feb 2003 07:07:58 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: strict and warnings
Message-Id: <b2crse$c6s$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
> Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on MMMCDLI September
> MCMXCIII in <URL:news:tWd2a.10634$LY2.631198@newsc.telia.net>:
> ][
> ][ Fortunately, in this case, there are no warnings to remove; neither
> ][ would the module give rise to any warnings if it was enabled. :) I just
> ][ mentioned it in response to your asking why not -w. After all, some CPAN
> ][ modules include 'use warnings;', and one of the reasons for bringing up
> ][ this subject was that I wondered if enabling warnings in the module
> ][ would be considered an improvement. Obviously you think I'd better
> ][ refrain from enabling it.
>
>
> I'd suggest you enable them. The person running a program that would
> make use of such a module could always turn the warnings off by
> using the -X switch.
And such could no longer use warnings in his own code. I don't quite see
why a module should active warnings. After all, a module is just an
interface and in those cases where it's not strictly necessary a user
shouldn't be bothered with anything that happens inside a module. The
author has to ensure that the module works as described in the
documentation shipped with it. That - theoretically - includes those
cases where perl would rise warnings if they were enabled.
Other than that, warnings serve the purpose to find potential bugs in a
piece of Perl code. A module on the other hand is third party software
and only a few users will actually look into the source and correct any
errors that could be indicated by warnings.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 12 Feb 2003 08:12:07 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: strict and warnings
Message-Id: <slrnb4k0en.lq3.abigail@alexandra.abigail.nl>
Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
MMMCDLII September MCMXCIII in <URL:news:b2crse$c6s$1@nets3.rz.RWTH-Aachen.DE>:
"" Also sprach Abigail:
""
"" > Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on MMMCDLI September
"" > MCMXCIII in <URL:news:tWd2a.10634$LY2.631198@newsc.telia.net>:
"" > ][
"" > ][ Fortunately, in this case, there are no warnings to remove; neither
"" > ][ would the module give rise to any warnings if it was enabled. :) I just
"" > ][ mentioned it in response to your asking why not -w. After all, some CPAN
"" > ][ modules include 'use warnings;', and one of the reasons for bringing up
"" > ][ this subject was that I wondered if enabling warnings in the module
"" > ][ would be considered an improvement. Obviously you think I'd better
"" > ][ refrain from enabling it.
"" >
"" >
"" > I'd suggest you enable them. The person running a program that would
"" > make use of such a module could always turn the warnings off by
"" > using the -X switch.
""
"" And such could no longer use warnings in his own code. I don't quite see
"" why a module should active warnings. After all, a module is just an
"" interface and in those cases where it's not strictly necessary a user
"" shouldn't be bothered with anything that happens inside a module. The
"" author has to ensure that the module works as described in the
"" documentation shipped with it. That - theoretically - includes those
"" cases where perl would rise warnings if they were enabled.
""
"" Other than that, warnings serve the purpose to find potential bugs in a
"" piece of Perl code. A module on the other hand is third party software
"" and only a few users will actually look into the source and correct any
"" errors that could be indicated by warnings.
That's like saying you prefer Windows because of its error messages
of the form "General Protection Fault" and "An error has occurred",
instead of more details.
Even if I don't peek in the module, I rather send a bug report with
a generated warning than a report "it doesn't work". I also rather
get a report with a warning than without.
Abigail
--
perl -MTime::JulianDay -lwe'@r=reverse(M=>(0)x99=>CM=>(0)x399=>D=>(0)x99=>CD=>(
0)x299=>C=>(0)x9=>XC=>(0)x39=>L=>(0)x9=>XL=>(0)x29=>X=>IX=>0=>0=>0=>V=>IV=>0=>0
=>I=>$==-2449231+gm_julian_day+time);do{until($=<$#r){$_.=$r[$#r];$=-=$#r}for(;
!$r[--$#r];){}}while$=;$,="\x20";print+$_=>September=>MCMXCIII=>=>=>=>=>=>=>=>'
------------------------------
Date: 12 Feb 2003 08:33:38 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: strict and warnings
Message-Id: <b2d0t2$gss$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Abigail:
> Tassilo v. Parseval (tassilo.parseval@post.rwth-aachen.de) wrote on
> MMMCDLII September MCMXCIII in <URL:news:b2crse$c6s$1@nets3.rz.RWTH-Aachen.DE>:
> "" Also sprach Abigail:
> "" > I'd suggest you enable them. The person running a program that would
> "" > make use of such a module could always turn the warnings off by
> "" > using the -X switch.
> ""
> "" And such could no longer use warnings in his own code. I don't quite see
> "" why a module should active warnings. After all, a module is just an
> "" interface and in those cases where it's not strictly necessary a user
> "" shouldn't be bothered with anything that happens inside a module. The
> "" author has to ensure that the module works as described in the
> "" documentation shipped with it. That - theoretically - includes those
> "" cases where perl would rise warnings if they were enabled.
> ""
> "" Other than that, warnings serve the purpose to find potential bugs in a
> "" piece of Perl code. A module on the other hand is third party software
> "" and only a few users will actually look into the source and correct any
> "" errors that could be indicated by warnings.
>
> That's like saying you prefer Windows because of its error messages
> of the form "General Protection Fault" and "An error has occurred",
> instead of more details.
What you say is that you prefer warning messages pop up all over the
place whenever something unexpected but harmless has happened on the
internals. Unlike a "General Protection Fault", a warning is not fatal
(it has fatal consequences only sometimes).
> Even if I don't peek in the module, I rather send a bug report with
> a generated warning than a report "it doesn't work". I also rather
> get a report with a warning than without.
Quite understandably. But that doesn't mean that you should annoy the
user with warnings. A user should send you a report whenever a bug shows
up. If you as a module maintainer feel that you have too few
information to fix the problem, you can still ask him to re-run the code
with -w or provide some other information needed for debugging. I do
that all the time, slightly succesfully I'd say.
I know that bug-free code virtually doesn't exist. My implication is
that we should still assume that it works 99% of the time (this mileage
varies) and not vice versa.
Hmmh, when you compile some piece of software, do you always compile it
with debugging flags? I guess you don't because you don't like the
performance hit and increeasd size of the object-code caused by it. I,
for one, want my stderr stream to be clean when using Perl modules.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 12 Feb 2003 10:41:43 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: strict and warnings
Message-Id: <i49k4vs3brcoj595p80g8nbku5fjprrku9@4ax.com>
Tassilo v. Parseval wrote:
>After several runs of the above I see that sometimes 'warn' is quicker,
>sometimes 'no_warn'.
It's called "noise". Things like these can't be measured 100% reliably.
A CPU's behaviour is not 100% determinate, with that cache and with
influence of background processes and all...
--
Bart.
------------------------------
Date: Wed, 12 Feb 2003 10:53:56 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: strict and warnings
Message-Id: <jb9k4vop7u8ksasfarc9dgs2fsbvciekd3@4ax.com>
Tassilo v. Parseval wrote:
>What you say is that you prefer warning messages pop up all over the
>place whenever something unexpected but harmless has happened on the
>internals.
Not so. For example, I use XML::Writer, to er, generate XML --
obviously, and *it* produces warnings internally if *my* data I pass it
is undefined. I should not do that. It would have been better still if
it used Carp for that, and pointed to the place in *my* script where I
call XML::Writer's methods in an unclean way. But still, this is
something, indicating *something* is wrong with my data, somewhere.
If you want to go ahead and abuse a module, you can still localise
warnings in the block where you call the module, by doing
{
local $^W;
... #some quircky code
}
I don't know what this does in relation to "use warnings", I don't use
it that often -- or even, at all. I thought the latter was lexical in
nature. Hmm...
--
Bart.
------------------------------
Date: Wed, 12 Feb 2003 08:03:23 GMT
From: inwap@inwap.com (Joe Smith)
Subject: Re: Test if directory is accessable, other Q's
Message-Id: <fdn2a.3965$io.152926@iad-read.news.verio.net>
In article <1109_1044645935@nntp.lucent.com>, Kris Dugan <cjdugan<--> wrote:
>Q2:
>I have a report that has a format (using FileHandle,
>and the methods format_name and format_top_name).
>During this report, I no longer want to use the TOP format.
Some tricks you can do with formats:
$- = 0; # Force next write() to have a page break
and
$- = 2 ** 31; # Supress TOP format for 2,147,483,648 lines
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
------------------------------
Date: Wed, 12 Feb 2003 10:02:24 +0100
From: "Murat Ünalan" <murat.uenalan@gmx.de>
Subject: Re: Wanted: open source documentation reviewer
Message-Id: <b2d2iv$4pi$02$1@news.t-online.com>
> The person I'm looking for is a programmer, and has Perl
Goto http://jobs.perl.org
You are wrong here.
Murat
------------------------------
Date: Tue, 11 Feb 2003 21:21:46 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Warnings in modules
Message-Id: <slrnb4jfea.20l.tadmc@magna.augustmail.com>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> In the thread "strict and warnings", two different viewpoints were
> stated as regards the advisable in enabling warnings in a Perl module.
>
> Tassilo v. Parseval wrote:
>> In this case
This is a qualifier on what follows, so we need the context
that preceded it...
... which appears to be: if you need backward compatability for
for perls that are more than 3 years old (ie. before 5.6.0).
>> please remove the warnings altogether. A module isn't
>> supposed to produce unexpected output at all. It's not very helpful for
>> the user of your module, either. It'll rather confuse them.
>
> Abigail wrote:
>> The only place warnings can turned off is in bugfree code.
>> Do you produce bugfree code?
>> ...
>> I'd suggest you enable them. The person running a program that would
>> make use of such a module could always turn the warnings off by
>> using the -X switch.
>
> Please guys... I'm just a beginner, and consider you to be experts. Whom
> should I trust most? ;-)
Larry and the p5p.
Type:
man perl
and scroll down to the BUGS section. :-)
perlmodlib.pod says:
Try to C<use warnings;> (or C<use warnings qw(...);>).
Remember that you can add C<no warnings qw(...);> to individual blocks
of code that need less warnings.
and perlmodstyle.pod says:
Your module should run successfully under the strict pragma and
should run without generating any warnings.
If your module is so super-duper that it forces folks to upgrade
their perl-of-historical-interest in order to use it, then you
will have contributed to making the world a better place. :-)
Put "use warnings" (and "use strict") in your module, along with:
require v5.6.0;
so folks will know what is required in order to make use of your module.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 12 Feb 2003 07:26:01 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Warnings in modules
Message-Id: <b2csu9$d07$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Tad McClellan:
> Put "use warnings" (and "use strict") in your module, along with:
>
> require v5.6.0;
>
> so folks will know what is required in order to make use of your module.
Err, and just exclude all people with a pre-5.6.0 Perl for the sake of
a few warnings?
Here's a little story that I went through some weeks ago:
I wanted to compile a piece of C-software that I retrieved through CVS
on FreeBSD. I needed to run autogen.sh which in turn needed Perl later
in the process. The Perl stuff however (only 5.005_03 installed on this
FreeBSD machine) used a too recent File::Copy module that already
provided File::Copy::move(). File::Copy shipped with 5.005_03 doesn't
yet have a move() function so I thought I could simply install a more
recent one from CPAN. The problem was that File::Copy is no separate
module. Instead I had to steal Copy.pm from 5.8.0 which didn't work
simply because it had a) 'use 5.006', b) 'use warnings' and c) a couple
of occurences of our() in the code. After removing a) and b) and
changing c) to 'use vars' it also worked on my ancient 5.005_03. There
was no reason to make File::Copy non-backwards-compatible other than
deliberately making trouble.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 12 Feb 2003 02:45:54 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Warnings in modules
Message-Id: <3E49FBB2.9DF0D12A@earthlink.net>
"Tassilo v. Parseval" wrote:
>
> Also sprach Tad McClellan:
>
> > Put "use warnings" (and "use strict") in your module, along with:
> >
> > require v5.6.0;
> >
> > so folks will know what is required in order to make use of your module.
>
> Err, and just exclude all people with a pre-5.6.0 Perl for the sake of
> a few warnings?
>
> Here's a little story that I went through some weeks ago:
> I wanted to compile a piece of C-software that I retrieved through CVS
> on FreeBSD. I needed to run autogen.sh which in turn needed Perl later
> in the process. The Perl stuff however (only 5.005_03 installed on this
> FreeBSD machine) used a too recent File::Copy module that already
> provided File::Copy::move(). File::Copy shipped with 5.005_03 doesn't
> yet have a move() function so I thought I could simply install a more
> recent one from CPAN. The problem was that File::Copy is no separate
> module. Instead I had to steal Copy.pm from 5.8.0 which didn't work
> simply because it had a) 'use 5.006', b) 'use warnings' and c) a couple
> of occurences of our() in the code. After removing a) and b) and
> changing c) to 'use vars' it also worked on my ancient 5.005_03. There
> was no reason to make File::Copy non-backwards-compatible other than
> deliberately making trouble.
I'm sure that if it had a seperate life from perl, on CPAN, it would
have been written to be backwards compatible... but if a module only
exists as part of the perl distribution, then IMHO there's no harm in
it using features of that version of perl.
--
"So, who beat the clueless idiot today?"
"Well, we flipped for it, but when Kuno
landed, he wasn't in any shape to fight."
"Next time, try flipping a *coin.*"
------------------------------
Date: 12 Feb 2003 08:16:10 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Warnings in modules
Message-Id: <slrnb4k0m9.lq3.abigail@alexandra.abigail.nl>
Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on MMMCDLII September
MCMXCIII in <URL:news:o9i2a.10673$LY2.632340@newsc.telia.net>:
@@ In the thread "strict and warnings", two different viewpoints were
@@ stated as regards the advisable in enabling warnings in a Perl module.
@@
@@ Tassilo v. Parseval wrote:
@@ > In this case please remove the warnings altogether. A module isn't
@@ > supposed to produce unexpected output at all. It's not very helpful for
@@ > the user of your module, either. It'll rather confuse them.
@@
@@ Abigail wrote:
@@ > The only place warnings can turned off is in bugfree code.
@@ > Do you produce bugfree code?
@@ > ...
@@ > I'd suggest you enable them. The person running a program that would
@@ > make use of such a module could always turn the warnings off by
@@ > using the -X switch.
@@
@@ Please guys... I'm just a beginner, and consider you to be experts. Whom
@@ should I trust most? ;-)
Me, of course. And I'm totally objective. ;-)
You don't have to trust me. But I gave a motivation. And I think
the motivation is more useful than the conclusion.
Abigail
--
perl -Mstrict -we '$_ = "goto O.print chop;\n=rekcaH lreP rehtona tsuJ";O1:eval'
------------------------------
Date: 12 Feb 2003 08:46:15 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: Warnings in modules
Message-Id: <b2d1kn$hmt$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Gunnar Hjalmarsson:
> In the thread "strict and warnings", two different viewpoints were
> stated as regards the advisable in enabling warnings in a Perl module.
>
> Tassilo v. Parseval wrote:
>> In this case please remove the warnings altogether. A module isn't
>> supposed to produce unexpected output at all. It's not very helpful for
>> the user of your module, either. It'll rather confuse them.
>
> Abigail wrote:
>> The only place warnings can turned off is in bugfree code.
>> Do you produce bugfree code?
>> ...
>> I'd suggest you enable them. The person running a program that would
>> make use of such a module could always turn the warnings off by
>> using the -X switch.
>
> Please guys... I'm just a beginner, and consider you to be experts. Whom
> should I trust most? ;-)
If expertship matters, trust Abigail. If arguments matter, try to come
up with a conclusion of your own based on what he, also Tad and I
consider reasons for and against. As always, there doesn't seem to be an
absolute truth.
There are probably even hybrid-solutions that could be worth
considering. I could think of letting the user decide whether he wants
warnings with an interface such as that:
use Your::Module debug => 1;
or a function:
Your::Module::debug(1);
that will set $^W.
The first way would require to write a custom import() method where you
first check whether 'debug' is set and afterwards call SUPER::import()
if your module inherits from Exporter (didn't try but should work).
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Wed, 12 Feb 2003 08:28:28 +0000
From: John Lagrue <jlagrue@netscape.net>
Subject: Wierd error with Java, JNI and embedded perl on linux
Message-Id: <5Dn2a.40$%K.24@newsfep1-gui.server.ntli.net>
I have an application that is written in java but uses embedded perl via
JNI to had small perl scriptlets.
This works fine on AIX, Solaris and Win2K. But I have run into a problem
when porting it to Linux.
What happens is that I get a segment violation deep inside the system
calls that result from calling libperl.so. I have walked through the
code with java and C++ debuggers and am certain that all the data that
my program passes into the perl calls is correct. I am baffled at this
point. Here is the relevant parts of the dump: can anyone throw any
light on this?
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4016E206
Function=(null)+0x4016E206
Library=/lib/libc.so.6
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
at
com.checkfree.isolutions.interpreter.perl.PerlInterface.parse(Native Method)
at
com.checkfree.isolutions.interpreter.perl.PerlInterface.parse(PerlInterface.java:97)
at
com.checkfree.isolutions.interpreter.perl.PerlInterface.<init>(PerlInterface.java:42)
at
com.checkfree.isolutions.interpreter.perl.PerlInterpreter.init(PerlInterpreter.java:144)
at
com.checkfree.isolutions.interpreter.perl.PerlInterpreter.get(PerlInterpreter.java:112)
at
com.checkfree.isolutions.interpreter.perl.PerlScript.evalAsVoid(PerlScript.java:133)
at
com.checkfree.isolutions.interpreter.perl.PerlScript.evalAsInt(PerlScript.java:123)
at perl.test.TestPerl.mainline(TestPerl.java:78)
at
com.checkfree.isolutions.application.framework.Application.run(Application.java:627)
at java.lang.Thread.run(Thread.java:536)
Part of the dynamic library list
4c8b1000-4c8b4000 r-xp 00000000 08:02 434473
/home/bgadmin/v4.1.2b/bin/libCFiJNIPerl.so
4c8b4000-4c8b5000 rw-p 00003000 08:02 434473
/home/bgadmin/v4.1.2b/bin/libCFiJNIPerl.so
4c8b5000-4c8b7000 r-xp 00000000 08:02 434489
/home/bgadmin/v4.1.2b/bin/libCFiPerl.so
4c8b7000-4c8b8000 rw-p 00001000 08:02 434489
/home/bgadmin/v4.1.2b/bin/libCFiPerl.so
4c8b8000-4c9a2000 r-xp 00000000 08:02 354758
/usr/local/lib/perl5/5.8.0/i686-linux/CORE/libperl.so
4c9a2000-4c9ad000 rw-p 000e9000 08:02 354758
/usr/local/lib/perl5/5.8.0/i686-linux/CORE/libperl.so
4c9af000-4c9b4000 r-xp 00000000 08:02 48000 /lib/libcrypt-2.2.93.so
4c9b4000-4c9b5000 rw-p 00004000 08:02 48000 /lib/libcrypt-2.2.93.so
4c9dc000-4c9de000 r-xp 00000000 08:02 48040 /lib/libutil-2.2.93.so
4c9de000-4c9df000 rw-p 00001000 08:02 48040 /lib/libutil-2.2.93.so
------------------------------
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.
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 V10 Issue 4555
***************************************
