[31128] in Perl-Users-Digest
Perl-Users Digest, Issue: 2373 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Apr 28 18:10:17 2009
Date: Tue, 28 Apr 2009 15:09:06 -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 Tue, 28 Apr 2009 Volume: 11 Number: 2373
Today's topics:
Re: How to find duplicate in certain fields of array?? <maustin@firstdbasource.com>
Re: Is there a better way to convert foreign characters (Tim McDaniel)
Re: Is there a better way to convert foreign characters <noreply@gunnar.cc>
Re: Is there a better way to convert foreign characters <ben@morrow.me.uk>
Re: Is there a better way to convert foreign characters <noreply@gunnar.cc>
Re: Is there a better way to convert foreign characters <jurgenex@hotmail.com>
Re: Is there a better way to convert foreign characters <nospam-abuse@ilyaz.org>
Re: Is there a better way to convert foreign characters <ben@morrow.me.uk>
Re: Perl is too slow - A statement <hjp-usenet2@hjp.at>
Re: Perl is too slow - A statement <uri@stemsystems.com>
Re: Perl is too slow - A statement <cwilbur@chromatico.net>
Re: Perl is too slow - A statement <tzz@lifelogs.com>
perl tk - pass function inside button <slick.users@gmail.com>
Re: perl tk - pass function inside button <1usa@llenroc.ude.invalid>
Re: Problem in parsing from a pipe <hjp-usenet2@hjp.at>
Re: Problem in parsing from a pipe <ben@morrow.me.uk>
Re: What perlop doesn't tell you about indirect method <Peter@PSDT.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 28 Apr 2009 11:30:59 -0500
From: Michael Austin <maustin@firstdbasource.com>
Subject: Re: How to find duplicate in certain fields of array??
Message-Id: <cbGJl.15356$hc1.2719@flpi150.ffdc.sbc.com>
somebody wrote:
> On Tue, 28 Apr 2009 00:19:18 +0200, Dr.Ruud wrote:
>
>> somebody wrote:
>>
>>> for ($i=3; $i <= 6; $i++) {
>>> push (@array, "$row[$i]");
>>> }
>> Equivalent:
>>
>> push @array, @row[ 3 .. 6 ];
>>
>
> That's a much more compact syntax. But now how do you find duplicates in
> $row[3], 4, 5, and 6? I need to determine that there are 2 WILLIAM in
> the first row, and 2 HARRIS in the forth row.
>
> -Thanks
>
> __DATA__
> CA|6299| |WILLIAM| |S|SMITH WILLIAM|
> DE|6209| |MANNY|J|MORALES|JR.|
> WA|1838| |KATHLEEN| |MCDONALD| |
> OH|3968| |JR|SCOTT HARRIS|HARRIS|JR|
>
put the data in a real database and NORMALIZE the data and you won't
have these issues. If this is "dirty" data from some other source and
you need to load it into a DB, then I suggest some very heavy reading
and testing and more testing and test again.
As stated, while you think "there are duplicates", they are indeed NOT
duplicate except as pointed out already JR/JR are the only truly
duplicate columns. Now your real problem is that you will need to break
each column space delimited and trimed in each row into an array and
then perform the required duplicates test.
code left to the imagination of the OP.
------------------------------
Date: Tue, 28 Apr 2009 16:12:51 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <gt79u3$bn6$1@reader1.panix.com>
In article <slrngvdkm3.hk.hjp-usenet2@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>In a single-byte encoding which is a superset of ASCII
>(e.g. ISO-8859-X) the code works, because lc is a noop on all
>accented characters.
!?!?! So, even if the local is set to Latin-1, lc('A') produces 'a',
but lc([A with acute accent]) is [A with acute accent]?! What sort of
nonsense is that?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 28 Apr 2009 18:31:21 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <75opaqF18jpv6U1@mid.individual.net>
Peter J. Holzer wrote:
> On 2009-04-23 19:38, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>> Tim McDaniel wrote:
>>> In article <751lqvF1647sbU1@mid.individual.net>, Gunnar Hjalmarsson
>>> <noreply@gunnar.cc> wrote:
>>>> ( $word = lc $value ) =~ tr/àâÀéèëêÉÊçÇîïôÔùû/aaaeeeeeecciioouu/;
>>>
>>> The above assigns the lowercase translation of $value to $word, and
>>> then does a tr/// on $word, right?
<snip>
>>> Then there should be no need for the capitalized characters in the
>>> tr///, because there shouldn't be any to match.
>>
>> That's true only if a suitable locale is enabled.
>
> Or if the $value is a character string.
Hmm.. Yes, so it seems. I wasn't aware of that.
<snip>
> (of course I really think you should use character strings if you do
> operations on characters, and not muck around with byte strings)
So far, I haven't bothered with encoding/decoding when I have been
working with Latin-1. Are you saying that encoding/decoding is advisable
even if you are not dealing with UTF-8 or some other encoding with wide
characters?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 28 Apr 2009 17:58:41 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <17pjc6-b1a.ln1@osiris.mauzo.dyndns.org>
Quoth tmcd@panix.com:
> In article <slrngvdkm3.hk.hjp-usenet2@hrunkner.hjp.at>,
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> >In a single-byte encoding which is a superset of ASCII
> >(e.g. ISO-8859-X) the code works, because lc is a noop on all
> >accented characters.
>
> !?!?! So, even if the local is set to Latin-1, lc('A') produces 'a',
> but lc([A with acute accent]) is [A with acute accent]?! What sort of
> nonsense is that?
You can say
use locale;
to get locale-aware character functions, but you have to be *very*
careful not to mix it with Perl's Unicode. The results are not terribly
well defined.
Ben
------------------------------
Date: Tue, 28 Apr 2009 19:08:55 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <75orh8F192oerU1@mid.individual.net>
Tim McDaniel wrote:
> In article <slrngvdkm3.hk.hjp-usenet2@hrunkner.hjp.at>,
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> In a single-byte encoding which is a superset of ASCII
>> (e.g. ISO-8859-X) the code works, because lc is a noop on all
>> accented characters.
>
> !?!?! So, even if the local is set to Latin-1, lc('A') produces 'a',
> but lc([A with acute accent]) is [A with acute accent]?!
No.
$ perl -MPOSIX -le '
setlocale LC_CTYPE, "sv_SE.iso88591";
print lc "ÀÉÊÇÔ";
use locale;
print lc "ÀÉÊÇÔ";
'
ÀÉÊÇÔ
àéêçô
$
But there was no playing with locales in the code we were discussing.
> What sort of nonsense is that?
Quoting out of context?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 28 Apr 2009 10:46:59 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <00gev4tjfq2si9vattthnreu96cujfu8hb@4ax.com>
tmcd@panix.com (Tim McDaniel) wrote:
>!?!?! So, even if the local is set to Latin-1, lc('A') produces 'a',
>but lc([A with acute accent]) is [A with acute accent]?! What sort of
>nonsense is that?
Aside of the other replies please keep in mind that for some letters
there is no upper case or lower case equivalent letter.
Just one example would be the German sharp s: ß, which never occurs at
the beginning of a word and if capitalized in an all-uppercase word
would be written as a double S: SS.
There are also examples where two lower-case letters are mapped to the
same upper-case letter. How do you map the upper-case letter back into
lower case without knowing the context, i.e. the word it is used in?
jue
------------------------------
Date: Tue, 28 Apr 2009 20:53:42 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngverdf.9gc.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> If $value is a byte string and no locale is in effect, lc on a non-ASCII
> string is poorly defined.
??? In absense of `use locale', lc should convert to lower-case using
Unicode case-conversion tables. What is "poorly defined" in this semantic?
> In a single-byte encoding which is a superset of ASCII (e.g. ISO-8859-X)
> the code works, because lc is a noop on all accented characters.
What exactly do you mean here?
>perl -Mcharnames=latin -wle "print qq(\N{AE})"
Æ
>perl -Mcharnames=latin -wle "print lc qq(\N{AE})"
æ
I must be missing something...
Yours,
Ilya
------------------------------
Date: Tue, 28 Apr 2009 22:42:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <0r9kc6-r6c.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2009-04-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> > If $value is a byte string and no locale is in effect, lc on a non-ASCII
> > string is poorly defined.
>
> ??? In absense of `use locale', lc should convert to lower-case using
> Unicode case-conversion tables. What is "poorly defined" in this semantic?
>
> > In a single-byte encoding which is a superset of ASCII (e.g. ISO-8859-X)
> > the code works, because lc is a noop on all accented characters.
>
> What exactly do you mean here?
>
> >perl -Mcharnames=latin -wle "print qq(\N{AE})"
> Æ
> >perl -Mcharnames=latin -wle "print lc qq(\N{AE})"
> æ
>
> I must be missing something...
Peter is talking about byte strings. \N produces utf8 strings, even if
it didn't need to.
Ben
------------------------------
Date: Tue, 28 Apr 2009 15:19:41 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Perl is too slow - A statement
Message-Id: <slrngve0je.34g.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-27 21:14, cherryplankton <cherryplankton@gmail.com> wrote:
><mercurish@googlemail.com> wrote:
>> We hear this all too common:
>> "I have one huge problem with Perl; it is too slow."
>>
>> But is Perl realy slow, could perl be slow at all?
>>
>> The problem is that most programmers associate an implementation of a
>> programming
>> language with the language it self. The current interpreter is too
>> slow and hence programmers
>> think that 'Perl' is too slow.
[...]
> You want to see slow? Try a bad SQL join called from PHP with Firefox on
> a slow one-core machine.
If you have a bad SQL join it is completely irrelevant whether you call
it from PHP or Perl or C, and whether your PHP/Perl/C code is in turn
invoked by a request from Firefox or Opera or IE. All your PHP/Perl/C
code will do is wait while the RDBMS is slogging through gigabytes of
data, and all your browser will do is wait for your PHP/Perl/C code.
hp
------------------------------
Date: Tue, 28 Apr 2009 11:25:17 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl is too slow - A statement
Message-Id: <87tz48yf4y.fsf@quad.sysarch.com>
>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
b> Uri Guttman wrote:
>> it also shows you have no clue about what is important these
>> days. development time is way more expensive than running time. you can
>> always get a faster computer but you rarely can speed up a development
>> schedule.
b> Agreed; further, algorithm developement gives
b> greater speed up than "cycle counting".
better algorithms is not the same as dev time vs cpu time. in the olden
days cpu time was expensive and programs were smaller so you had to pay
for cpu usage and it was monitored carefully. today cpu time is dirt
cheap so it is rarely accounted but programs are larger and take more
labor costs to write.
b> Jon Bentley, in a rather old book, shows a quicksort
b> in Basic on a TRS-80 outrunning a fully optimised
b> bubble sort on a Cray-1 (*)
that would also depend on the data set size. i am sure the picked a size
large enough to make that happen. you are comparing O(N log N) to O( N
** 2) and the bubble sort will grow much faster until its slow algorithm
swamps the cpu speed differences.
b> (*) I did say the book was old!
the point is still valid even if the boxes are antiquated.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 28 Apr 2009 12:31:41 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Perl is too slow - A statement
Message-Id: <864ow8loya.fsf@mithril.chromatico.net>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> If you have a bad SQL join it is completely irrelevant whether
PJH> you call it from PHP or Perl or C, and whether your PHP/Perl/C
PJH> code is in turn invoked by a request from Firefox or Opera or
PJH> IE. All your PHP/Perl/C code will do is wait while the RDBMS is
PJH> slogging through gigabytes of data, and all your browser will
PJH> do is wait for your PHP/Perl/C code.
Which touches off another argument: even if you have a *good* SQL join,
and your database is perfectly tuned, the I/O will still probably take
an order of magnitude more time than any computation you do with the
data.
In other words: it doesn't really matter if a tight loop executes in 3
milliseconds or 10 milliseconds, if it takes 300 milliseconds before you
get the data you need to operate on from the database.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 28 Apr 2009 13:05:03 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Perl is too slow - A statement
Message-Id: <86ocugr6wg.fsf@lifelogs.com>
On Mon, 27 Apr 2009 11:58:56 -0400 Uri Guttman <uri@stemsystems.com> wrote:
UG> development time is way more expensive than running time. you can
UG> always get a faster computer but you rarely can speed up a
UG> development schedule.
There are many cases where Perl is simply the wrong tool because the
equivalent C or C++ or even assembler code would run many times faster.
Inlining the C code is not the answer if 95% of the code is
time-critical. So you write a library and call it from Perl; at that
point you're not writing code in Perl but calling it from Perl.
This is unavoidable. There will always be the need to run as fast as
possible for particular tasks, at the expense of development schedule
and whatever else falls under the carriage. This is not a Perl vs. X
problem, it's a niche that Perl and many others just don't fill.
The important thing is to realize when Perl is appropriate and when it
isn't. Unfortunately the single best way to predict this is to have
done it already, so prototyping time-critical Perl code with the real
data is really important.
Ted
------------------------------
Date: Tue, 28 Apr 2009 10:39:29 -0700 (PDT)
From: Slickuser <slick.users@gmail.com>
Subject: perl tk - pass function inside button
Message-Id: <8703c486-548f-44e0-a181-95943a5d7edd@u39g2000pru.googlegroups.com>
I have this generic function to add a button to the main Tk window.
How do I pass this correction function in when a button is press for
this Button?
add_button('test a',1,0,\&test_a);
add_button('test b',1,1,\&test_b);
sub add_button ( $$$$)
{
my ($text,$row,$col,$cmd) = @_;
$main->Button
(
-text => $text,
-command =>\&function_pass
## pass in user command?
##\&test_a
### \&test_b
)
->grid
(
-row => $row,
-column => $col
);
}
------------------------------
Date: Tue, 28 Apr 2009 21:51:21 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: perl tk - pass function inside button
Message-Id: <Xns9BFBB59F04227asu1cornelledu@127.0.0.1>
Slickuser <slick.users@gmail.com> wrote in news:8703c486-548f-44e0-a181-
95943a5d7edd@u39g2000pru.googlegroups.com:
> I have this generic function to add a button to the main Tk window.
> How do I pass this correction function in when a button is press for
> this Button?
I can't make sense of this paragraph no matter how many times I read it.
> add_button('test a',1,0,\&test_a);
> add_button('test b',1,1,\&test_b);
>
> sub add_button ( $$$$)
Why are you using a prototype?
> {
> my ($text,$row,$col,$cmd) = @_;
> $main->Button
> (
> -text => $text,
> -command =>\&function_pass
> ## pass in user command?
> ##\&test_a
> ### \&test_b
> )
Shouldn't you be referring to the fourth argument passed to add_button
(which is in $cmd)? What the heck is function_pass?
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Tue, 28 Apr 2009 15:57:58 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Problem in parsing from a pipe
Message-Id: <slrngve2r6.34g.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-27 19:44, January Weiner <january.weiner@gmail.com> wrote:
> On 2009-04-24, Eric Pozharski <whynot@pozharski.name> wrote:
>> On 2009-04-22, January Weiner <january.weiner@gmail.com> wrote:
>>> On 2009-04-21, Eric Pozharski <whynot@pozharski.name> wrote:
>>>> Think 3-args B<open>, it's safer.
>>>
>>> Why?
>>
>> perl -wle '$cmd = q|rm -rf /; true|; open $fh, "$cmd|" or die $!'
>> Name "main::fh" used only once: possible typo at -e line 1.
>> rm: cannot remove root directory `/'
>
> Maybe I'm not too bright, but I don't get it :( Would you mind being a
> little more verbose? I mean, you can do the same with 3 arg open:
>
> perl -wle '$cmd = q|rm -rf /; true|; open( $fh, "-|", "$cmd" ) or die $!'
>
> Where is the difference?
None that I can see at the moment. But there is a diffence between
my $file = get_filename_from_user();
open $fh, "$cmd $file|" or die;
and
my $file = get_filename_from_user();
open $fh, '-|', $cmd, $file or die;
In the first case, if the user enters "/dev/null; rm -rf /" as the file
name, the command "rm -rf /" will be executed, while in the second case
the single argument "/dev/null; rm -rf /" will be passed to $cmd (which
will probably complain that there is no file with this name).
Of course, if the user already has a shell and invokes your script
interactively, that doesn't make any difference, either: The user can
simply invoke "rm -rf /" from the shell with exactly the same result.
However it is a good idea to err on the side of caution, because some
time later you might want to reuse your code in a library, CGI script
or cron job and then you must be paranoid to avoid having your system
wiped out by accident or malice. So get into the practice of being
paranoid!
> And anyway, I have always thought that preventing malicious input from the
> users should be happening on an altogether different level, starting with
> at least using taint mode -- am I wrong?
That, too. But taint mode is only a tool which helps you to detect
untrusted input. It isn't foolproof.
>
>> Define "quite large". As of second, I think, it's possible to go
>> through pattern one match per time (but not at 3AM).
>
> $ du -hs human_est.out
> 1.2G human_est.out
> $ du -hs nr
> 3.5G nr
>
>> And a piece of advice. If you're going to stay here, anytime think of
>> C<use File::Slurp;>, and find a good reason against. Because sooner or
>> later, you'll be adviced of it anyway.
>
> Maybe, but this is not going to happen. I want to stop reading a huge file
> after I have collected all the information that I need from it - why should
> I slurp 3.5 gb if I have what I need after reading 10k?
You shouldn't. There are situations where it is a good idea to read the
whole file into memory and there are situations where it isn't. Clearly
if you only need the first 10k of a 3.5GB file it would be insane to
all of it into memory. Even if you need to read the whole file it it
probably better to read it line by line. But that depends on your data
and what information you need to extract. "Always slurp" is just as
idiotic as "always read line by line".
hp
------------------------------
Date: Tue, 28 Apr 2009 17:02:41 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Problem in parsing from a pipe
Message-Id: <1uljc6-5b8.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2009-04-27 19:44, January Weiner <january.weiner@gmail.com> wrote:
> > On 2009-04-24, Eric Pozharski <whynot@pozharski.name> wrote:
> >> On 2009-04-22, January Weiner <january.weiner@gmail.com> wrote:
> >>> On 2009-04-21, Eric Pozharski <whynot@pozharski.name> wrote:
> >>>> Think 3-args B<open>, it's safer.
> >>>
> >>> Why?
> >>
> >> perl -wle '$cmd = q|rm -rf /; true|; open $fh, "$cmd|" or die $!'
> >> Name "main::fh" used only once: possible typo at -e line 1.
> >> rm: cannot remove root directory `/'
> >
> > Maybe I'm not too bright, but I don't get it :( Would you mind being a
> > little more verbose? I mean, you can do the same with 3 arg open:
> >
> > perl -wle '$cmd = q|rm -rf /; true|; open( $fh, "-|", "$cmd" ) or die $!'
> >
> > Where is the difference?
>
> None that I can see at the moment. But there is a diffence between
>
> my $file = get_filename_from_user();
> open $fh, "$cmd $file|" or die;
>
> and
>
> my $file = get_filename_from_user();
> open $fh, '-|', $cmd, $file or die;
It's well worth noting, actually, that (exactly-) 3-arg piped opens are
still unsafe, since they still invoke the shell. Quite what you're
supposed to do if you want to invoke a command without arguments safely
I'm not sure. Something like
open my $fh, "-|" or exec $cmd $cmd;
(note the lack of comma in the arguments to exec) perhaps, which is ugly
and (probably) unportable.
Of course, if you're execing a command taken from (untrusted) user input
you're insane anyway :). system LIST and open "-|" are meant for
situations like
open my $SYMBOLS, "-|", "nm", $lib;
where you'd like to avoid needing to check $lib for shell metachars. If
you can assume that 1. your path is safe and 2. nm will treat arguments
as filenames (or at least never do anything dangerous) you can quite
safely pass that untrusted input without validation.
Ben
------------------------------
Date: Tue, 28 Apr 2009 12:28:29 GMT
From: Peter Scott <Peter@PSDT.com>
Subject: Re: What perlop doesn't tell you about indirect method calls
Message-Id: <NDCJl.58392$g%5.57760@newsfe23.iad>
On Tue, 28 Apr 2009 06:24:58 +0200, Bo Lindbergh wrote:
> Then what adjective should be used to distinguish between
>
> $object -> method (@args)
>
> and
>
> $object -> $methodname (@args)
>
> ?
Symbolic method call?
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
------------------------------
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 2373
***************************************
