[18200] in Perl-Users-Digest
Perl-Users Digest, Issue: 368 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 27 14:10:47 2001
Date: Tue, 27 Feb 2001 11:10:26 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <983301025-v10-i368@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 27 Feb 2001 Volume: 10 Number: 368
Today's topics:
Re: Perl program review request <flavell@mail.cern.ch>
Re: Perl program review request (Tad McClellan)
Re: Perl program review request <flavell@mail.cern.ch>
Re: Perl program review request nobull@mail.com
Re: Perl program review request <comdog@panix.com>
Re: Perl program review request <uri@sysarch.com>
Re: Please Help with 10 line programm -- beginner quest <godzilla@stomp.stomp.tokyo>
PWS and Perl <mark_shutt@hotmail.com>
Re: Sendmail / Windows Question nobull@mail.com
Re: Sorting by date nobull@mail.com
Re: timeout connect() with select? <perlCHEESE@CHEESEatlaswebmail.com>
Re: timeout connect() with select? <perlCHEESE@CHEESEatlaswebmail.com>
Re: timeout connect() with select? <perlCHEESE@CHEESEatlaswebmail.com>
Re: timeout connect() with select? <perlCHEESE@CHEESEatlaswebmail.com>
Re: timeout connect() with select? <perlCHEESE@CHEESEatlaswebmail.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 27 Feb 2001 17:20:44 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Perl program review request
Message-Id: <Pine.LNX.4.30.0102271712290.3744-100000@lxplus003.cern.ch>
On Tue, 27 Feb 2001, Tad McClellan wrote:
> die "'$percent' contains no digit chars!" unless $percent =~ /(\d+)/;
Am I allowed to say that I find it really _grating_ to see
that kind of syntax used,
<exception handling> unless <something that should succeed>;
Much rather see it expressed the other way around, which in Perl
can usefully be
<something that should succeed> or <exception handling>;
all the best
------------------------------
Date: Tue, 27 Feb 2001 17:28:46 GMT
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Perl program review request
Message-Id: <slrn99nlkc.akm.tadmc@tadmc26.august.net>
Alan J. Flavell <flavell@mail.cern.ch> wrote:
>On Tue, 27 Feb 2001, Tad McClellan wrote:
>
>> die "'$percent' contains no digit chars!" unless $percent =~ /(\d+)/;
>
>Am I allowed to say that I find it really _grating_ to see
>that kind of syntax used,
Sure, just as I am allowed to ignore your preference <grin>.
> <exception handling> unless <something that should succeed>;
Emphasizes that an exception might happen here.
Reads kind of Englishy ("die unless matched").
>Much rather see it expressed the other way around, which in Perl
>can usefully be
>
> <something that should succeed> or <exception handling>;
Emphasizes that a pattern match is expected to succeed here.
Programmer must remember the short-circuit behavior when the word
"or" is used in Perl code.
I rabidly avoid using and/or as control structures as a general
principle (to be broken only occasionally).
So, if I wanted to emphasize normal flow, I would use
unless ( <something that should succeed> )
{ <exception handling> }
I _prefer_ to highlight the unexpected things (exceptions) in
my code, so I can find them in the code when they throw something
that I need to chase down.
In other words, I chose they way I did after conscious thought
about what was important to me. I 'spose other folks might
prefer to emphasize the normal flow. Doesn't seem important
enough to get religious about though.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 27 Feb 2001 19:05:55 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Perl program review request
Message-Id: <Pine.LNX.4.30.0102271845090.3744-100000@lxplus003.cern.ch>
On Tue, 27 Feb 2001, Tad McClellan wrote:
> Sure, just as I am allowed to ignore your preference <grin>.
fair enough
> > <exception handling> unless <something that should succeed>;
>
> Emphasizes that an exception might happen here.
Well, on the read-from-left-to-right principle, the reader starts by
thinking "good lord, he wants to die" and then getting to the
conditional and having to re-think "oh no he doesn't, that was meant
to be the exception".
> Reads kind of Englishy ("die unless matched").
Yes, like the kind of navigator who shouts to the driver "TURN RIGHT.....
....after about three quarters of a mile".
> >Much rather see it expressed the other way around, which in Perl
> >can usefully be
> >
> > <something that should succeed> or <exception handling>;
>
> Emphasizes that a pattern match is expected to succeed here.
Well, at least it emphasises that it is _intended_ to succeed
(optimists v. pessimists?).
> Programmer must remember the short-circuit behavior when the word
> "or" is used in Perl code.
Yes; but that idiom seems to me a neat way of controlling a
single statement.
I was on the point of also including your next alternative:
> I rabidly avoid using and/or as control structures as a general
> principle (to be broken only occasionally).
Hmmm! It seemed to be quite a usual idiom in Perl, it's interesting
that it doesn't meet with universal approval.
> So, if I wanted to emphasize normal flow, I would use
>
> unless ( <something that should succeed> )
> { <exception handling> }
That's fine by me too. I'm not quite sure why Perl doesn't
support a single-statement variant without the curly brackets, but
c'est la vie.
> I _prefer_ to highlight the unexpected things (exceptions) in
> my code,
That makes good sense, yes.
> Doesn't seem important enough to get religious about though.
I hope I didn't give that impression.
Cut off your head! unless you want to take my advice. ;-}
------------------------------
Date: 27 Feb 2001 18:10:23 +0000
From: nobull@mail.com
Subject: Re: Perl program review request
Message-Id: <u9itlwov3k.fsf@wcl-l.bham.ac.uk>
wfeidt@his.com (Bill Feidt) writes:
> If folks would care to review and comment on my most
> recent Perl programming effort, I'd be pleased to have
> the input. clpm has been a wonderful learning tool
> for me, even though I normally only lurk. Thank you
> all for being here and for sharing your wisdom and
> experience.
> http://www.cpcug.org/dialup/shdisk.txt
You use nested loops traversing the input file once for each
interation of the outer loop. It would be better to traverse the input
once and build an appropriate Perl data structure and then iterate
over that. Do not be affraid of using the implict $_ argument to
simplify code.
my %infil;
while (<INFIL>) {
chomp;
my @record = split /\|/;
push @{$infil{$record[1]}} => \@record;
}
for ( @infil{@elements} ) {
my $prevpct;
for ( @$_ ) {
my ($date2, $volume, $percent) = @$_;
# and so on...
}
}
In addition to the the above drastic rearrangement for this particular
program I have a few largely cosmetic comments about your general Perl
programming style.
> #!/usr/local/bin/perl -w
>
> use strict;
Good so far! If you do not require compatibility with versions
earlier than 5.6 then -w is better replaced with "use warnings" (for
details "perldoc perllexwarn").
> my @elements = (
> '\|\/\|',
> "usr",
Since these are to be used as regular expressions it would be more
transparent to say:
my @elements = (
qr/\|\/\|/,
qr/usr/,
That said, I question the need for regular expresions at all.
> my $date = `date`;
You may want to consider using:
my $date = localtime;
> &HEAD;
As a simple function call this should usully be written HEAD() unless
you expressly want to suppress @_ handling.
> foreach (@elements) {
> my $object = $_;
More simply written as:
foreach my $object (@elements) {
> my ($line, $prevpct);
> $prevpct = "";
> foreach $line (<INFIL>) {
> chomp $line;
I prefer to keep the my() as close as possible to the first use of the
variable.
Better to process one line at a time rather then slurp the whole file
into a list. However, in this case, since you are traversing the file
several times you may do better to slurp it into an array - depends
how big it is.
All other things being equal it is better to use undefined rather than
a null string to represent the concept of the variable $prevpct being
undefined.
my $prevpct;
while( my $line = <INFIL>) {
chomp $line;
OR
# outside outer loop
my @infil=<INFIL>;
chomp(@infil);
# within outer loop
my $prevpct;
for my $line (@infil) {
This is also a situation where I'd be tempted to use the implicit $_
in place of $line.
> if ($line =~ $object) {
I think it aids readability to write this as:
if ($line =~ /$object/) {
That said I don't think regex is the right approach.
> if ($line =~ $object) {
> my ($date2, $volume, $percent);
> ($date2, $volume, $percent) = split (/\|/, $line);
More efficient to have $object contain the actual volume name complete
with leading slash then simply use string equality:
my ($date2, $volume, $percent) = split (/\|/, $line);
if ( $volume eq $object ) {
You could be be really Perlish and say:
my ($date2, $volume, $percent) = split (/\|/, $line);
next unless $volume eq $object;
> $percent =~ /(\d+)/;
Since you go on to use $1 several more times over the next few lines
I'd probably have given it a name. In general use $_, $1 and so on if
and only if it makes code more readable.
Also you are assuming the pattern will always match. I think it aids
maintainability/readability to slap in a "or die" wherever you have a
m// or s/// that you are assuming will always match. If your
assumption ever fails then you'll get an error at the line where the
match is rather than weird behaviour further down the code.
my ($p) = $percent =~ /(\d+)/ or die;
> $percent = "<span class=\"emph\">$1<\/span>\%";
The characters '/' and '%' do not need quoting in double-qouted strings.
> my $shim = " " x (12 - length($volume))
> $line = $date2." ".$volume.$shim.$percent;
> print OUTFIL "$line\n";
This is more conveniently written as:
printf OUTFIL "%s %-12s%s\n",$date2,$volume,$percent;
Note that because $line is an iterator variable in a for() then it is
actually an alias for an element of the list over which you are
iterating. In your original code this didn't matter because you
weren't iterating over lvalues. However if you'd slurped the file
into an array as discussed above then modifying $line would be a
definite no-no.
> open (INFIL, "/homec/wfeidt/tbin2/diskts.ts")
Rather than re-open()ing a filehandle to rewind it it would be more
transparent to simply seek(INFIL,0,0).
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Tue, 27 Feb 2001 13:44:46 -0500
From: brian d foy <comdog@panix.com>
Subject: Re: Perl program review request
Message-Id: <comdog-C8D7B0.13444627022001@news.panix.com>
In article <Pine.LNX.4.30.0102271845090.3744-100000@lxplus003.cern.ch>,
"Alan J. Flavell" <flavell@mail.cern.ch> wrote:
> On Tue, 27 Feb 2001, Tad McClellan wrote:
> > > <exception handling> unless <something that should succeed>;
> > Emphasizes that an exception might happen here.
> Well, on the read-from-left-to-right principle, the reader starts by
> thinking "good lord, he wants to die" and then getting to the
> conditional and having to re-think "oh no he doesn't, that was meant
> to be the exception".
that's the point. you say "good lord" then pay close attention
to what it about to happen. of course, crying wolf would defeat
that purpose.
it's a common way of doing things in Perl.
--
brian d foy <comdog@panix.com>
------------------------------
Date: Tue, 27 Feb 2001 18:53:10 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Perl program review request
Message-Id: <x7u25gez56.fsf@home.sysarch.com>
>>>>> "AJF" == Alan J Flavell <flavell@mail.cern.ch> writes:
>> unless ( <something that should succeed> )
>> { <exception handling> }
AJF> That's fine by me too. I'm not quite sure why Perl doesn't
AJF> support a single-statement variant without the curly brackets, but
AJF> c'est la vie.
oh gawd! that is one of perl's most saving graces (among a myriad of
others) over c - the requirement of braces for any code following a
condtional statement (not conditional expression). i always used braces
in c and it bothers me to see the tons of code without them just
dangling and making it harder for humans to parse it, especially when
you have a complex nested set of them which are mixed between braced
and unbraced code (look at much of gnu code for that).
larry recognized the stupidity of that and made braces required. no more
trying to match which statement belongs to which condition. no visual
misdirection caused by poor indenting (shades of python), etc.
as for conditional expressions, i use both 'or' and 'unless' and 'if' in
various ways. it depends on the code and how i am reading it.
today i wrote the classic skip a blank line as:
next if $line =~ /^\s*$/ ;
this reads poorly to me:
$line =~ /^\s*$/ and next ;
but i do opens like:
open( FOO, 'bar' ) || die "flaming death" ;
larry decided to make perl very readable in english but how you
emphasize which part is more important was left up to the coder. it
varies depending on your style.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Tue, 27 Feb 2001 09:16:59 -0800
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Please Help with 10 line programm -- beginner questions Thanks Guys
Message-Id: <3A9BE10B.DF80749C@stomp.stomp.tokyo>
Bart Lateur wrote:
> Kiralynne Schilitubi wrote:
> >> Not true. "strict" ONLY has an effect on the parsing of the program.
> >> Once compiled, the program will run exactly just as fastwith as without
> >> "strict". As for crashing, the same applies: the compiled code is
> >> exactly the same, so there's not one single reason on why it should
> >> crash more often.
> >This is untrue. My tests show a significant average 1.64 percent slow
> >down of a script using a very simple code snippet.
> My applologies. There is at least ONE area where "strict" has a runtime
> effect: it makes sure you don't use a string as a reference (symbolic
> references). I would think that you'd only see a slowdown, if any, if
> you are indeed using references. But since symbolic references need to
> be treated differently anyway, than real references, I can't see how
> this can affect the ordinary case, because the script needs to test for
> it in any case. There only difference should occur IF you're using
> symbolic references.
(snipped)
I have not tested other aspects of strict. I cannot comment if
other features of strict cause this type of slowdown. I would
surmise strict's other features do cause memory bloat, this
seems a logical given.
My overall theme is strict is a useful development tool for
those who need help and, this tool should be used cautiously.
When a script reaches a near final or a final stage, warnings
and strict should be removed; they serve no good purpose.
Here at home, I am an accomplished welder. I enjoy creating
metal sculptures, some award winning. Both gas and electric
welding are useful tools. Both can also severely burn your
fingers to a crisp, if used without caution.
A tool is only as useful as its wielder's talent.
Godzilla!
------------------------------
Date: Tue, 27 Feb 2001 17:30:12 -0000
From: Mark <mark_shutt@hotmail.com>
Subject: PWS and Perl
Message-Id: <t9np14jgve9jea@corp.supernews.com>
I am trying to run MS Personal Web Server on Win98 and run Perl CGI
scripts. I have my registry correct to execute Perl, but it still isn't
working. I am getting a "the page cannot be displayed" error. I am
browsing the directory so it is definately there..and the script executes
fine (a simple print statement with HTML headers) on a different web
server. Does anyone know what may be missing? What needs to be done to
ensure proper installation of MS PWS and ActivePerl?
Thanks.
Mark
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: 27 Feb 2001 17:49:40 +0000
From: nobull@mail.com
Subject: Re: Sendmail / Windows Question
Message-Id: <u9k86cow23.fsf@wcl-l.bham.ac.uk>
sryder@webryder.com (Shawn Ryder) writes:
> I have the following script created to simply submit an email form
> from Flash to the script and send it to the designated email address
> which is set inside the Flash file - but I realize that it only works
> with UNIX, how do I get it to work correctly in a windows enviroment ?
Get Sendmail or a Sendmail clone for Windows or use one of the other
methods of sending mail that you'll find on CPAN or in the FAQ.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 27 Feb 2001 17:47:24 +0000
From: nobull@mail.com
Subject: Re: Sorting by date
Message-Id: <u9n1b8ow5v.fsf@wcl-l.bham.ac.uk>
"Brian J" <sorryno@email.at.all> writes:
> I'm writing a forum where each topic is stored as a .txt file, and would
> like to know if there is a way to sort or read the files into the order
> they were last modified so that they could be displayed in such a way.
There is no shorthand way.
There is a Perl function stat() that gets information about a file including last
modifiation date of a file as seconds since the start of the epoch.
There is a Perl function sort() that will sort a list according to
arbirary ordering criteria. There are pleanty of examples in the
documentation.
Combining these appropriately is left as an exercise for the reader.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Mon, 26 Feb 2001 23:14:10 +1100
From: "h." <perlCHEESE@CHEESEatlaswebmail.com>
Subject: Re: timeout connect() with select?
Message-Id: <3a9bc809@nexus.comcen.com.au>
Anno Siegel wrote in message <97dc0n$i65$1@mamenchi.zrz.TU-Berlin.DE>...
>Here you're using $eout in the position where the file numbers
>to be checked for errors are expected. Also, you're setting it
>to the integer 1, but it must be a bit string of file numbers.
>You should acquaint yourself with select by reading perldoc select
>and man select.
Ok. I read the man pages, they are written for C, of course.
In C, the 3rd argument to select has something to do with
"exceptions", not "errors". - eg. signals as well as errors.
The if the connect() call fails for a socket handle, then the
socket immediately becomes readable and writable.
Seems weird to me, but that's what the documentation says.
That's why I've been putting the file descriptor (whatever
that is) in the third argument for the select call.
I could not find the select perl doc, could someone please let me know where
I can find it. Also, if someone could please let me know what perldoc
explains
what a file number is and what a file descriptor is, I'd appreciate it. All
the documentation I've read for select() mentions file numbers, file
descriptors, et. al.
I fear I'll never be able to understand select() until I can get a solid
handle on what
a file descriptor is, and what it looks like and how it functions on the bit
level.
p.s. Please note that my main goal is to understand, not just to find a way.
>Anno
Thanks for your help, Anno.
------------------------------
Date: Mon, 26 Feb 2001 23:14:10 +1100
From: "h." <perlCHEESE@CHEESEatlaswebmail.com>
Subject: Re: timeout connect() with select?
Message-Id: <3a9bcf61@nexus.comcen.com.au>
Anno Siegel wrote in message <97dc0n$i65$1@mamenchi.zrz.TU-Berlin.DE>...
>Here you're using $eout in the position where the file numbers
>to be checked for errors are expected. Also, you're setting it
>to the integer 1, but it must be a bit string of file numbers.
>You should acquaint yourself with select by reading perldoc select
>and man select.
Ok. I read the man pages, they are written for C, of course.
In C, the 3rd argument to select has something to do with
"exceptions", not "errors". - eg. signals as well as errors.
The if the connect() call fails for a socket handle, then the
socket immediately becomes readable and writable.
Seems weird to me, but that's what the documentation says.
That's why I've been putting the file descriptor (whatever
that is) in the third argument for the select call.
I could not find the select perl doc, could someone please let me know where
I can find it. Also, if someone could please let me know what perldoc
explains
what a file number is and what a file descriptor is, I'd appreciate it. All
the documentation I've read for select() mentions file numbers, file
descriptors, et. al.
I fear I'll never be able to understand select() until I can get a solid
handle on what
a file descriptor is, and what it looks like and how it functions on the bit
level.
p.s. Please note that my main goal is to understand, not just to find a way.
>Anno
Thanks for your help, Anno.
------------------------------
Date: Mon, 26 Feb 2001 23:14:10 +1100
From: "h." <perlCHEESE@CHEESEatlaswebmail.com>
Subject: Re: timeout connect() with select?
Message-Id: <3a9bd6ca@nexus.comcen.com.au>
Anno Siegel wrote in message <97dc0n$i65$1@mamenchi.zrz.TU-Berlin.DE>...
>Here you're using $eout in the position where the file numbers
>to be checked for errors are expected. Also, you're setting it
>to the integer 1, but it must be a bit string of file numbers.
>You should acquaint yourself with select by reading perldoc select
>and man select.
Ok. I read the man pages, they are written for C, of course.
In C, the 3rd argument to select has something to do with
"exceptions", not "errors". - eg. signals as well as errors.
The if the connect() call fails for a socket handle, then the
socket immediately becomes readable and writable.
Seems weird to me, but that's what the documentation says.
That's why I've been putting the file descriptor (whatever
that is) in the third argument for the select call.
I could not find the select perl doc, could someone please let me know where
I can find it. Also, if someone could please let me know what perldoc
explains
what a file number is and what a file descriptor is, I'd appreciate it. All
the documentation I've read for select() mentions file numbers, file
descriptors, et. al.
I fear I'll never be able to understand select() until I can get a solid
handle on what
a file descriptor is, and what it looks like and how it functions on the bit
level.
p.s. Please note that my main goal is to understand, not just to find a way.
>Anno
Thanks for your help, Anno.
------------------------------
Date: Mon, 26 Feb 2001 23:14:10 +1100
From: "h." <perlCHEESE@CHEESEatlaswebmail.com>
Subject: Re: timeout connect() with select?
Message-Id: <3a9bde1b@nexus.comcen.com.au>
Anno Siegel wrote in message <97dc0n$i65$1@mamenchi.zrz.TU-Berlin.DE>...
>Here you're using $eout in the position where the file numbers
>to be checked for errors are expected. Also, you're setting it
>to the integer 1, but it must be a bit string of file numbers.
>You should acquaint yourself with select by reading perldoc select
>and man select.
Ok. I read the man pages, they are written for C, of course.
In C, the 3rd argument to select has something to do with
"exceptions", not "errors". - eg. signals as well as errors.
The if the connect() call fails for a socket handle, then the
socket immediately becomes readable and writable.
Seems weird to me, but that's what the documentation says.
That's why I've been putting the file descriptor (whatever
that is) in the third argument for the select call.
I could not find the select perl doc, could someone please let me know where
I can find it. Also, if someone could please let me know what perldoc
explains
what a file number is and what a file descriptor is, I'd appreciate it. All
the documentation I've read for select() mentions file numbers, file
descriptors, et. al.
I fear I'll never be able to understand select() until I can get a solid
handle on what
a file descriptor is, and what it looks like and how it functions on the bit
level.
p.s. Please note that my main goal is to understand, not just to find a way.
>Anno
Thanks for your help, Anno.
------------------------------
Date: Mon, 26 Feb 2001 23:14:10 +1100
From: "h." <perlCHEESE@CHEESEatlaswebmail.com>
Subject: Re: timeout connect() with select?
Message-Id: <3a9be569@nexus.comcen.com.au>
Anno Siegel wrote in message <97dc0n$i65$1@mamenchi.zrz.TU-Berlin.DE>...
>Here you're using $eout in the position where the file numbers
>to be checked for errors are expected. Also, you're setting it
>to the integer 1, but it must be a bit string of file numbers.
>You should acquaint yourself with select by reading perldoc select
>and man select.
Ok. I read the man pages, they are written for C, of course.
In C, the 3rd argument to select has something to do with
"exceptions", not "errors". - eg. signals as well as errors.
The if the connect() call fails for a socket handle, then the
socket immediately becomes readable and writable.
Seems weird to me, but that's what the documentation says.
That's why I've been putting the file descriptor (whatever
that is) in the third argument for the select call.
I could not find the select perl doc, could someone please let me know where
I can find it. Also, if someone could please let me know what perldoc
explains
what a file number is and what a file descriptor is, I'd appreciate it. All
the documentation I've read for select() mentions file numbers, file
descriptors, et. al.
I fear I'll never be able to understand select() until I can get a solid
handle on what
a file descriptor is, and what it looks like and how it functions on the bit
level.
p.s. Please note that my main goal is to understand, not just to find a way.
>Anno
Thanks for your help, Anno.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 368
**************************************
