[19560] in Perl-Users-Digest
Perl-Users Digest, Issue: 1755 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Sep 16 11:05:31 2001
Date: Sun, 16 Sep 2001 08:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1000652706-v10-i1755@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 16 Sep 2001 Volume: 10 Number: 1755
Today's topics:
Re: Cannot run perl scripts in Apache when file opened (EED)
change dir the dir of Favorites.. <the@executioner.tmfweb.nl>
expression evaluation problem <bcaligari@fireforged.com>
Re: expression evaluation problem <joe+usenet@sunstarsys.com>
Re: foreach problem ? <iltzu@sci.invalid>
Re: Mail parser: Can it be faster? <Tassilo.Parseval@post.rwth-aachen.de>
Re: Mail parser: Can it be faster? <bart.lateur@skynet.be>
Re: Mail parser: Can it be faster? <Tassilo.Parseval@post.rwth-aachen.de>
News about war in usa here <gogetit@free.fr>
Numbers and strings oddities question <bfarnell@gte.net>
Re: Numbers and strings oddities question <jbritain@home.com>
Re: Numbers and strings oddities question <dtweed@acm.org>
Re: process stopping --> start script <goldbb2@earthlink.net>
Re: Q: When to use eval for calling object subroutines? <c.hintze@gmx.net>
Similar file finder <sun_tong@users.sourceforge.net>
Thank you. <Kalle Anka@markisspecialisten.com>
Re: Those quite handy FAQ posts <tintin@snowy.calculus>
Re: Using 'use lib' to throw an arbitrary directory int <bart.lateur@skynet.be>
XML::RSS Can't access DESTROY field in object <tintinx@here.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Sep 2001 14:24:23 +0200
From: "Alexander Farber (EED)" <eedalf@eed.ericsson.se>
Subject: Re: Cannot run perl scripts in Apache when file opened via Samba
Message-Id: <3BA499F7.9759A12E@eed.ericsson.se>
AcCeSsDeNiEd wrote:
> If I have a perl file opened on my Win98 machine, it will not run via the web (Apache)
> I do not need to save or change the contents. Just opening it creates the problem.
> I can use any program in Win98 to open the file. The problem is still there.
> [Fri Sep 14 00:27:05 2001] [error] (26)Text file busy: exec of /cgi-bin/script.pl failed
I believe, if a program opens file in Windows,
then you can't acccess it from another program
------------------------------
Date: Sun, 16 Sep 2001 12:17:32 +0200
From: "The Executioner" <the@executioner.tmfweb.nl>
Subject: change dir the dir of Favorites..
Message-Id: <9o1u6l$h58$1@azure.nl.gxn.net>
How can I change the location of the dir of Favorites?
Thanks, Maarten
------------------------------
Date: Sun, 16 Sep 2001 10:20:55 -0000
From: "B. Caligari" <bcaligari@fireforged.com>
Subject: expression evaluation problem
Message-Id: <9o1tvq01gum@enews4.newsguy.com>
While going through a C syle guide, I came across a supposedly
ambiguous expression
a[i] = i++;
I did some tests with gcc, and got a result where, if before the
expression is evaluated, i == 1, a[1] is assigned the value of 1.
While trying to figure out the dynamics of that expression,
I tried out the equivalent in Perl.
$a[$n] = $n++;
This time around, $a[2] was assigned the value of 1!!
How does this evaluate under Perl's expression evaluation rules?
Any illumination really appreciated!! I tried to figure it out on my
own but I got even more confused.
B
------------------------------
Date: 16 Sep 2001 10:52:22 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: expression evaluation problem
Message-Id: <m3pu8r2no9.fsf@mumonkan.sunstarsys.com>
"B. Caligari" <bcaligari@fireforged.com> writes:
> While going through a C syle guide, I came across a supposedly
> ambiguous expression
>
> a[i] = i++;
>
> I did some tests with gcc, and got a result where, if before the
> expression is evaluated, i == 1, a[1] is assigned the value of 1.
It is also possible that a demon might fly out of your nose. :)
The above expression violates the C standard, and a C compiler is
not obliged to treat that expression, nor any program that uses it,
in a consistent manner. See the comp.lang.c faq, and/or search the
archives there for numerous discussions of this issue (a good keyword
to use might be "sequence point").
> While trying to figure out the dynamics of that expression,
> I tried out the equivalent in Perl.
> $a[$n] = $n++;
>
> This time around, $a[2] was assigned the value of 1!!
>
> How does this evaluate under Perl's expression evaluation rules?
% perl -Dt -wle '$a[$n] = $n++'
EXECUTING...
(-e:0) enter
(-e:0) nextstate
(-e:1) gvsv(main::n)
(-e:1) postinc
(-e:1) gv(main::a)
(-e:1) rv2av
(-e:1) gvsv(main::n)
(-e:1) aelem
(-e:1) sassign
(-e:1) leave
However, IMO you shouldn't rely on this result as a definitive
statement on how Perl "evaluates" that expression. Like C (but
unlike Java), Perl doesn't define an order of evaluation for
most of its binary operators, so AFAIK in different contexts
you *may* get different results.
Besides, it's very confusing for a human reader to decipher what
your intent is. Either
$a[$n+1] = $n;
++$n;
or
$a[$n] = $n;
++$n;
is IMO much easier to read.
--
Joe Schaefer "The only thing to do with good advice is pass it on; it is
never of any use to oneself."
-- Oscar Wilde
------------------------------
Date: 16 Sep 2001 13:51:57 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: foreach problem ?
Message-Id: <1000648245.7380@itz.pp.sci.fi>
In article <3BA3AF73.EBA0C01B@acm.org>, Dave Tweed wrote:
>"[per media] Wolfgang Nagele" wrote:
>> I have the following Code ...
>
>> use MIME::Lite;
>
>This might as well be outside the loop. After the first iteration,
>it's a no-op anyway.
Makes no difference. It's executed as soon as it's compiled, and then
stripped away by the compiler. By the time the loop starts, it's no
longer there at all.
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Sun, 16 Sep 2001 11:10:16 +0200
From: Tassilo von Parseval <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: Mail parser: Can it be faster?
Message-Id: <3BA46C78.6050103@post.rwth-aachen.de>
David Coppit wrote:
> Hi all,
>
> I'm the author of grepmail (http://grepmail.sf.net/). Over the years
> I've gotten it to be fairly fast, but the primary bottleneck in grepmail
> is still parsing the mbox-style mailbox file. The algorithm is a little
> complicated because I try to identify unquoted "From" lines that are
> part of included messages. However, I only touch any line in the file once.
>
> I've reimplemented the algorithm using Inline::C (uber-cool!) to get
> about a 30% speedup, depending on the machine. I've also tried various
> tweaks like sysread to get it to go faster, but haven't seen any
> improvement. (I even tried adapting the odd memory allocation scheme in
> GNU grep for my C implementation--I think it tries to allocate on page
> boundaries or something.)
First of all, you are a little moderate with your module. ;-) My
benchmarks have shown that it is *at least* four times as quick as any
other Perl mail-parseing module. See the benchmark in the docs to
Mail::MboxParser where I just let several modules extract the raw
messages from a mailbox. I did not include Mail::Cclient though since I
was frequently hit by segfaults caused by this module.
> Can anyone suggest techniques to get this code to run faster? The
> interface should stay basically the same (status, email scalar, line
> number), but you can maybe exploit the fact that this isn't a random
> access read.
Indeed. I remember Mark Overmeer talking about this quite often but from
what I see it is not done thus in his current Mail::Box.
The problem with mbox-parsing is (according to the experiences with my
module) is any form of binary attachement. Since I use a few reg-exes on a
whole line, each of these REs is also applied to the encoded attachements even
though no real relevant information can be deduced from that.
Have you experimented with the "Content-length: "-field? It is not a
mandatory header-field but most emails have it. I thought of a mixture
between line- and character-wise reading:
(this is pseudo-code and not going to work)
while (<MBOX>) {
....
my $pos = tell MBOX if /^Content-length: (\d+)/i;
seek MBOX, $1, SEEK_CUR;
}
A little conceptual test just showed that seek() can also be used with
<> (I wasn't sure about it).
This would especially speed up things a lot if the mailbox contains
large emails since anything than the header of the first entity
(speaking in MIME-terms) would be skipped.
Since grepmail of course captures an email (and not just counts them),
you would have to implement the above by trying to use the "Lines:
"-field. Determing, how many lines are yet to come and making an
inner-loop inside the while-block over these lines to store them away.
Thus you'd not have to apply all the regexes and tests on these lines as
well. You already know they belong to the message.
[snipped code save for:]
> # See if we accidentally stopped on an unescaped "From my mother".
> if ($NEXT_EMAIL !~ /^From\s.*\d:\d+:\d.* \d{4}/)
Isn't the escaping of From-lines in the body the job of the
mail-transport agent? Not sure about it but I remember having read
something about that in RFC822.
Tassilo
--
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};
------------------------------
Date: Sun, 16 Sep 2001 10:42:09 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Mail parser: Can it be faster?
Message-Id: <u809qtsju7lu2ftn2jvbt7pom4350p6t0e@4ax.com>
[I haven't actually looked at the OP's code, but:]
Tassilo von Parseval wrote:
>The problem with mbox-parsing is (according to the experiences with my
>module) is any form of binary attachement. Since I use a few reg-exes on a
>whole line, each of these REs is also applied to the encoded attachements even
>though no real relevant information can be deduced from that.
For this, the ".." operator in scalar context is ideal. You can do
things like:
while(<LINE>) {
if(/$start_of_ignore/ .. /$end_of_ignore/) {
... # this is not relevant here
} elsif(/$actuel_test/) {
... # got a relevant line!
}
}
You can ignore entire attachments this way, all you need is to be able
to recognise the start and the end of such an attachment. All the
processing can then be done in one single loop.
--
Bart.
------------------------------
Date: Sun, 16 Sep 2001 13:18:38 +0200
From: Tassilo von Parseval <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: Mail parser: Can it be faster?
Message-Id: <3BA48A8E.6050504@post.rwth-aachen.de>
Bart Lateur wrote:
> For this, the ".." operator in scalar context is ideal. You can do
> things like:
>
> while(<LINE>) {
> if(/$start_of_ignore/ .. /$end_of_ignore/) {
> ... # this is not relevant here
> } elsif(/$actuel_test/) {
> ... # got a relevant line!
> }
> }
>
> You can ignore entire attachments this way, all you need is to be able
> to recognise the start and the end of such an attachment. All the
> processing can then be done in one single loop.
Ah, you are right. That's a good and quite prototypical use of the
binary '..' operator. It makes code more compact and probably quicker.
Tassilo
--
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};
------------------------------
Date: Sun, 16 Sep 2001 14:24:15 GMT
From: "WAR IN USA" <gogetit@free.fr>
Subject: News about war in usa here
Message-Id: <jC2p7.3233$_M7.3289176@nnrp5.proxad.net>
http://www.warinusa.com02.com
------------------------------
Date: Sun, 16 Sep 2001 11:57:15 GMT
From: Brian Farnell <bfarnell@gte.net>
Subject: Numbers and strings oddities question
Message-Id: <3BA493E3.B0E914C1@gte.net>
Can anyone point me to a reference for why this happens or explain it?
I was playing with the fact that Perl converts between numbers and
strings as needed depending on the operation and I got some unexpected
results:
1) given $s = "fred", and these not being sequential lines in a program,
but done one at a time in an experiment:
$s ++; #yields free, that I understand
$s --; #yields -1 (?!)
$s += 1; #yields 1 , shouldn't that be the same as $s ++?
$s += 5; #yields 5 (at least we have a pattern)
$s *=1; #yields 0
$s *=3; #yields 0 (again a pattern, but why?)
I understand that I would get very different results if I used $s =
"3fred"; but I'm unclear why the first example works and the others
don't, especially why the third example fails. Is there a way to make
them work or an alternate syntax to accomplish the same thing? Is the
++ feature designed to work for a particular reason, and if so, what
possible use would that be?
I guess this question falls into the same useless whatif category my
Biology proffessor used to make fun of me for, "If frogs had hip pockets
would they carry .44s and shoot snakes when they tried to eat them?" he
always would reply. I'm just curious, I'm learning Perl, going back
through the Llama book and trying every weird variation mentioned in the
text and I ran across this.
Also, where do I get the newsgroup FAQ for this group and is there a
more apropriate group to be in with strange and/or newbie questions like
this?
Regards,
Brian
------------------------------
Date: Sun, 16 Sep 2001 12:20:46 GMT
From: Jim Britain <jbritain@home.com>
Subject: Re: Numbers and strings oddities question
Message-Id: <9g59qt0mup1mneso11teegsj6di5pha5ai@4ax.com>
On Sun, 16 Sep 2001 11:57:15 GMT, Brian Farnell <bfarnell@gte.net>
wrote:
>Can anyone point me to a reference for why this happens or explain it?
>
>I was playing with the fact that Perl converts between numbers and
>strings as needed depending on the operation and I got some unexpected
>results:
>
>1) given $s = "fred", and these not being sequential lines in a program,
>but done one at a time in an experiment:
>
>$s ++; #yields free, that I understand
>$s --; #yields -1 (?!)
A string cannot be decremented the variable is converted to $numeric
equivalent equal to zero, and then decremented.
>$s += 1; #yields 1 , shouldn't that be the same as $s ++?
No, increment is valid on both character and numeric values, but this
is an addition operation. Hence autovivication of the numeric
variable $s -- there are actually two $s now, one numeric, and one
string.
>$s += 5; #yields 5 (at least we have a pattern)
AHA! -- (same as last time!!)
>$s *=1; #yields 0
zero times one = ??
>$s *=3; #yields 0 (again a pattern, but why?)
(same as last time, except now we have 3 zeroes adding up to ??)
------------------------------
Date: Sun, 16 Sep 2001 12:36:19 GMT
From: Dave Tweed <dtweed@acm.org>
Subject: Re: Numbers and strings oddities question
Message-Id: <3BA49B83.335CB1CF@acm.org>
Brian Farnell wrote:
> $s ++; #yields free, that I understand
So you understand that ++ is "magical" when applied to strings of a
certain format. If you read just a little further (perldoc perlop,
under "Auto-increment and Auto-decrement"), you'll find that -- is
not magical in the same way. None of the other arithmetic operators
are either.
> $s --; #yields -1 (?!)
> $s += 1; #yields 1 , shouldn't that be the same as $s ++?
> $s += 5; #yields 5 (at least we have a pattern)
> $s *=1; #yields 0
> $s *=3; #yields 0 (again a pattern, but why?)
For all of these, which are numerical operations, the value of $s is
taken to be 0. All of these results are consistent with that.
-- Dave Tweed
------------------------------
Date: Sun, 16 Sep 2001 10:09:25 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: process stopping --> start script
Message-Id: <3BA4B295.A669FA66@earthlink.net>
Luke Vanderfluit wrote:
>
> Hi,
>
> I can't get this working
> I've simplified the script to:
>
> #!/usr/bin/perl
>
> use IPC::Open3;
> open(DEVNULL, "<", "/dev/null");
> my $s = open3(">&STDOUT", "<&DEVNULL", ">&STDERR", "keepLinkUp");
> print $s;
>
> the os complains that open has too many arguments.
No, perl complains that open has too many arguments. Perl is not the os.
The reason for this error is that you are using an old version of perl,
which does not permit the three-argument form.
Upgrade your perl.
--
"I think not," said Descartes, and promptly disappeared.
------------------------------
Date: Sun, 16 Sep 2001 09:27:42 +0200
From: Clemens Hintze <c.hintze@gmx.net>
Subject: Re: Q: When to use eval for calling object subroutines?
Message-Id: <3BA4546E.4D557FB0@gmx.net>
B Wooster wrote:
(...)
> foreach $group (@groups)
> {
> # Why is this eval needed?
> eval
> {
> $group->debug($group->debug || $debug);
> print "\n", "== ", $group->name, " --> ", $dir, "\n";
> ....
> };
> }
>
> So my question is this: is the above eval needed?
> Looks to me $group->name should be usable without a eval,
> is that correct?
Yep! But this eval is used for catching exceptions. Please have a look
to
perldoc -f eval
second paragraph ...
>
> Thanks!
HTH,
Clemens.
------------------------------
Date: 15 Sep 2001 17:04:46 -0300
From: * Tong * <sun_tong@users.sourceforge.net>
Subject: Similar file finder
Message-Id: <sa8bskc8bkx.fsf@suntong.personal.users.sourceforge.net>
Hi,
I'm planing to write a "Similar file finder", which will walks along
the given dirs to find all similar files within it.
- First I want to know if anybody has written similar tools already.
Searching intensively in news archive, I can only located such
request/respond in newsgroups: comp.graphics.apps.paint-shop-pro
(what a strange place to find such kind of program :->)
http://groups.google.com/groups?hl=en&threadm=LhAh4.11633%24NU6.569262%40tw12.nn.bcandid.com&rnum=56&prev=/groups%3Fq%3Dfile%2Bsimilar%2Bcompare%2Bscript%2BOR%2Bprogram%26num%3D50%26hl%3Den%26start%3D50%26sa%3DN
,----- [quotes from above thread] ---
| Now you can down load any number of similar files and run the program to
| compare the incoming files against the list of "got that one" Even if
| someone renamed the file the program will recognize that and rename it to
| the correct name...
|
| If you want to get an idea of how powerful this tool is just substitute the
| word "font" in the above paragraph with any file extension you like (.jpg
| .gif .bmp .mp3 .mpg .avi etc.)
|
| How it works inside is kind of technical( I don't understand all of
| it)... so far the program has worked on every file type I have tried
| it on.
`-----
I did not include the DOS program's name here because what seems as
such an amazing tools to a PSP user is just a CRC checksum
comparing program. I'm sure most of us here can hack one in just
minutes.
What's in my mind is much more powerful than it. It can not only
find out *identical* files but also find out similar files. Ok, what
are similar files? Files that have different file name, time and
size (might be content also), and yet they represent same thing.
Is such program really necessary? Why would files that have
different name, time and size represent same thing? Well, does words
like "Napster", "Gnutella" ring the bell? Different names for same
file are not rare at all. Different version (.txt, .html, or .pdf)
and different compression methods (.zip, .gz, .tar.gz, .bip2) make
it even worse. And let alone there are partial downloads floating
around everywhere. Moreover, sample rate make a huge different in
MP3 files, even if they sound no much different to human ears.
One poster said (in above thread):
,-----
| I have over 200 cd that I have burned full of different files. Also three
| HD's. There is not a duplicate of any file anywhere on any of my storage
| mediums.
`-----
Well, I have much much less collection than s/he did, but I'm sure
more than 10% of my collection are duplicated similar files,
and the percentage is very likely above that.
Ok, hope that I've made myself clear enough. I'm determined to write
one, and publish it on my Xpt project web page as freeware. Before
doing that, I want to know what kind of aid are already out there,
what kind of wheels I do not need to reinvent. Suggestions, tips and
code snippets are warmly appreciated.
Thanks
--
Tong (remove underscore(s) to reply)
*niX Power Tools Project: http://xpt.sourceforge.net/
- All free contribution & collection
------------------------------
Date: Sun, 16 Sep 2001 09:03:00 GMT
From: "Kalle Anka" <Kalle Anka@markisspecialisten.com>
Subject: Thank you.
Message-Id: <8VZo7.5245$sn6.542290@newsc.telia.net>
Perfect.
Thank you...
------------------------------
Date: Sun, 16 Sep 2001 22:08:50 +1000
From: "Tintin" <tintin@snowy.calculus>
Subject: Re: Those quite handy FAQ posts
Message-Id: <mE0p7.10$5D2.580671@news.interact.net.au>
"Rinus Luijmes" <digirini@xs4all.nl> wrote in message
news:hcl4qtkkcqcf6dneqtgm4vamkk3j9s3hjf@4ax.com...
> Hello,
> I've been lurking in this group for a while since I'm a newbie and I
> already learned a lot by collection all those automatic FAQ-posts in
> this group. A great invention that could be handy for some other
> newsgroups too.
A lot of the technical groups already have FAQ postings.
------------------------------
Date: Sun, 16 Sep 2001 12:44:24 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Using 'use lib' to throw an arbitrary directory into @INC at runtime?
Message-Id: <pb79qtcoco204ldbetgmergl6n83ho3iaj@4ax.com>
Weston Cann wrote:
>use lib $arbitraryDir;
>
>This doesn't seem to work... should it?
Only if $arbitraryDir is already set when this line gets compiled.
Setting the variable in a BEGIN block *above* this line will do.
my $arbitraryDir;
BEGIN {
$arbitraryDir = ("/home/john/lib", "/home/jeff/lib",
"/home/pete/lib")[int rand 3];
}
use lib $arbitraryDir;
$, = "; ";
print "\@INC: @INC\n";
You'll see one of those three lib directories at the front of @INC. Now
*that* is what I call "arbitrary".
--
Bart.
------------------------------
Date: Sun, 16 Sep 2001 12:59:48 +0100
From: "TintinX" <tintinx@here.com>
Subject: XML::RSS Can't access DESTROY field in object
Message-Id: <Yu0p7.9775$QV4.278301@news11-gui.server.ntli.net>
Does anyone know what this means?
It's reporting the error on rss2html.pl at line 0 (??) when I try and pass a
URL with an rdf file to parse?
The script parsed perfectly the first time, but since then it produces this
error.
TIA
----------
TintinX
------------------------------
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 1755
***************************************
