[32342] in Perl-Users-Digest
Perl-Users Digest, Issue: 3609 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Feb 11 21:13:07 2012
Date: Sat, 11 Feb 2012 18:12:51 -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 Sat, 11 Feb 2012 Volume: 11 Number: 3609
Today's topics:
Re: Lifetime of my variables? <ben@morrow.me.uk>
Re: Lifetime of my variables? <ben@morrow.me.uk>
Re: Lifetime of my variables? <rweikusat@mssgmbh.com>
Re: Lifetime of my variables? <ben@morrow.me.uk>
Re: Lifetime of my variables? (Seymour J.)
Re: Lifetime of my variables? (Seymour J.)
Re: Lifetime of my variables? (Seymour J.)
Re: Lifetime of my variables? <ben@morrow.me.uk>
Remove all HTML but keep <p> tags <rdw204@gmail.com>
Re: Remove all HTML but keep <p> tags <glex_no-spam@qwest-spam-no.invalid>
Re: Remove all HTML but keep <p> tags <jurgenex@hotmail.com>
Re: Remove all HTML but keep <p> tags <hjp-usenet2@hjp.at>
WWW::Mechanize submit_form does not return expected <justin.1201@purestblue.com>
Re: WWW::Mechanize submit_form does not return expected <glex_no-spam@qwest-spam-no.invalid>
Re: WWW::Mechanize submit_form does not return expected <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 8 Feb 2012 14:45:13 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Lifetime of my variables?
Message-Id: <pcea09-v14.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <bks809-vcl2.ln1@anubis.morrow.me.uk>, on 02/08/2012
> at 12:35 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Otherwise you'll need to define doReceived outside the loop and pass
> >$prevHELO in as a parameter.
>
> Will moving the declaration before the while loop and explicitly
> initializing the variable to undef at the beginning of the loop work?
I'm still not entirely clear as to what you are trying to acheive: do
you want the value preserved across iterations of the foreach loop but
reset each time you restart the while loop? In that case yes, what you
suggest will work, but it's not a good way to write it.
In the first place, you still have sub doReceived inside the while loop.
Since it can't really be usefully considered to be within the scope of
the loop, it shouldn't be there.
Secondly, $prevHELO is now effectively a global you are using as a
parameter to doReceived. This is bad style for all the usual reasons, so
you should pass it as a normal parameter instead. Unless I've
misunderstood your logic, this isn't difficult:
> my $prevHELO;
>
> mailfile: while (my $mailfile=shift) {
> undef $prevHELO;
$prevHELO logically belongs to (one iteration of) the while loop, so
this was the right place to declare it.
my $prevHELO;
> ...
> foreach (@Received[$ReceivedIx..$#Received]) {
> ...
> doReceived($+{FROM}, $+{HELO} // $+{IP}, $+{RDNS} // '', $+{IP},
> $+{BY1}, $+{BY2} // '') || last;
Here, however, you need to pass it to doReceived explicitly rather than
assuming it can pick it up implicitly. The logic *is* a little awkward,
given that you want to 'last', but not enormously so. One way of writing
it would be
my $HELO = $+{HELO} // $+{IP};
my $more = doReceived($+{FROM}, $prevHELO, $HELO, ...);
$prevHELO = $HELO;
$more or last;
Another would be to return the new value for $prevHELO, which would be
better if you don't always want to set it to the HELO value passed in.
Yet another would be to pass a *ref* to $prevHELO, which doReceived can
use to set the value for itself; that's a little obscure, since it's
really just a hidden form of return value, but there are occasions where
the flexibility is useful.
Ben
------------------------------
Date: Wed, 8 Feb 2012 17:45:12 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Lifetime of my variables?
Message-Id: <8uoa09-5p5.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <s58909-86q2.ln1@anubis.morrow.me.uk>, on 02/08/2012
> at 03:53 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Um, *what* are you doing here?
>
> Well, what I'm *trying* to do is to have a single variable named
> $prevHELO that is used inside the while loop and maintained by the
> subroutine. I thought that Rainer was suggesting that I prefix the
> package name when using the variable inside the subroutine.
While that would work, at least if you included the 'undef $prevHELO'
you suggested xthread, it has no advantages over the file-scoped lexical
you were using there. As a general rule of thumb the only reason to ever
use package globals is if you (or some module, like Exporter) need to
get at the variable from outside the current file.
Ben
------------------------------
Date: Wed, 08 Feb 2012 18:01:17 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Lifetime of my variables?
Message-Id: <878vkdw6fm.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>> In <s58909-86q2.ln1@anubis.morrow.me.uk>, on 02/08/2012
>> at 03:53 AM, Ben Morrow <ben@morrow.me.uk> said:
>>
>> >Um, *what* are you doing here?
>>
>> Well, what I'm *trying* to do is to have a single variable named
>> $prevHELO that is used inside the while loop and maintained by the
>> subroutine. I thought that Rainer was suggesting that I prefix the
>> package name when using the variable inside the subroutine.
>
> While that would work, at least if you included the 'undef $prevHELO'
> you suggested xthread,
It will also work when localizing $prevHELO during each loop-iteration.
> it has no advantages over the file-scoped lexical you were using
> there.
It has actually disadvantages: A my-Variable is accessed by indexing
into the appropriate lexical pad, ie, the name is resolved at compile
time, while accesing something which resides in the symbol table of
the package requires a symbol table aka 'hash' lookup.
> As a general rule of thumb the only reason to ever use package
> globals is if you (or some module, like Exporter) need to get at the
> variable from outside the current file.
The other reason would be local: It is possible to create a binding
for a package-global variable which only exists during the dynamic
extent of the lexical scope that established it.
------------------------------
Date: Wed, 8 Feb 2012 18:26:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Lifetime of my variables?
Message-Id: <2bra09-5g6.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <bks809-vcl2.ln1@anubis.morrow.me.uk>, on 02/08/2012
> at 12:35 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >(In detail: because the while loop is at the top level of the
> >program, and because perl doesn't quite treat blocks which aren't
> >subs as true blocks, it doesn't realise that $prevHELO is declared
> >in a section of code which might run more than once.)
>
> Is that reportable as a bug, and is it still the case in Perl 6?
[I realise I didn't answer this bit...]
No, there would be no point reporting it as a bug. Anyone who might be
capable of fixing it is already well aware this is how perl behaves, and
why.
It's a performance tradeoff: in order to avoid the (relatively large)
overhead of setting up a new lexical pad and pulling down the outer
lexicals every time a block is entered, perl cheats and lifts the
lexicals for a block up into the innermost surrounding sub. A certain
amount of bookkeeping is required to make sure they don't end up visible
when they shouldn't have been, but nearly all of that happens at compile
time. Once a block has been compiled it's rather difficult to work out
which section of code a given lexical was originally attached to.
I don't know if it's still the case in Perl 6 (I don't know much about
it) but I suspect not. I believe that at least in principle all blocks
is Perl 6 are true lexical closures; while I'm certain the various
implementations do a certain amount of cheating (since otherwise
performance would be appalling) I suspect the continuation-based control
flow means they are obliged to keep more careful track of lexical scopes
at runtime.
Ben
------------------------------
Date: Wed, 08 Feb 2012 15:27:53 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Lifetime of my variables?
Message-Id: <4f32dac9$5$fuzhry+tra$mr2ice@news.patriot.net>
In <2bra09-5g6.ln1@anubis.morrow.me.uk>, on 02/08/2012
at 06:26 PM, Ben Morrow <ben@morrow.me.uk> said:
>I don't know if it's still the case in Perl 6 (I don't know much
>about it) but I suspect not.
Thanks. In the meantime, I've moved the subroutines and the variables
they refer to out of the loop amd that seems to have taken care of
things.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 08 Feb 2012 15:51:34 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Lifetime of my variables?
Message-Id: <4f32e056$2$fuzhry+tra$mr2ice@news.patriot.net>
In <pcea09-v14.ln1@anubis.morrow.me.uk>, on 02/08/2012
at 02:45 PM, Ben Morrow <ben@morrow.me.uk> said:
>I'm still not entirely clear as to what you are trying to acheive: do
>you want the value preserved across iterations of the foreach loop
>but reset each time you restart the while loop?
Yes.
>In that case yes, what you suggest will work, but it's not a
>good way to write it.
The alternatives I'm aware of all seem more awkward.
>so you should pass it as a normal parameter instead.
I'd have to pass it as a reference, which seems more awkward than
having it in a common scope.
> my $HELO = $+{HELO} // $+{IP};
> my $more = doReceived($+{FROM}, $prevHELO, $HELO, ...);
> $prevHELO = $HELO;
> $more or last;
That would defeat my intent of relegating the logic to the subroutine.
>Another would be to return the new value for $prevHELO, which would
>be better if you don't always want to set it to the HELO value
>passed in.
There is more than one variable that must be updated.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 10 Feb 2012 10:27:39 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Lifetime of my variables?
Message-Id: <4f35376b$3$fuzhry+tra$mr2ice@news.patriot.net>
In <2bra09-5g6.ln1@anubis.morrow.me.uk>, on 02/08/2012
at 06:26 PM, Ben Morrow <ben@morrow.me.uk> said:
>No, there would be no point reporting it as a bug. Anyone who might
>be capable of fixing it is already well aware this is how perl
>behaves, and why.
What about the fact that neither use strcit nor use warnings catches
it?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 10 Feb 2012 20:37:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Lifetime of my variables?
Message-Id: <opbg09-ph32.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <2bra09-5g6.ln1@anubis.morrow.me.uk>, on 02/08/2012
> at 06:26 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >No, there would be no point reporting it as a bug. Anyone who might
> >be capable of fixing it is already well aware this is how perl
> >behaves, and why.
>
> What about the fact that neither use strcit nor use warnings catches
> it?
Again, that's well known. For instance, pad.c (which handles lexicals)
has this comment (in S_pad_findlex)
/* set PAD_FAKELEX_MULTI if this lex can have multiple
* instances. For now, we just test !CvUNIQUE(cv), but
* ideally, we should detect my's declared within loops
* etc - this would allow a wider range of 'not stayed
* shared' warnings. We also treated already-compiled
* lexes as not multi as viewed from evals. */
which precisely explains the problem.
Warnings are generally considered best-effort, given that (in principle)
they're only warning you about things you ought to have known already.
If a few cases are missed because it would be rather difficult to catch
them, that's considered an acceptable trade-off.
Ben
------------------------------
Date: Fri, 10 Feb 2012 13:24:57 -0800 (PST)
From: Rob <rdw204@gmail.com>
Subject: Remove all HTML but keep <p> tags
Message-Id: <cda1f483-3d78-44a0-a3a2-e484307bc2b5@c6g2000vbk.googlegroups.com>
I am looking for a perl REGEX statement to remove all the HTML from a
string except for the <p> tags. It would have to leave the <p> (and
the </p>) tags but also longer ones such as <p style=...> etc. I
haven't been able to find anything similar online for this.
Can anyone help with a suitable REGEX for this? I have tried a few
things but had no success.
Any help would be much appreciated.
Rob
------------------------------
Date: Fri, 10 Feb 2012 16:02:55 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Remove all HTML but keep <p> tags
Message-Id: <4f35940f$0$52252$815e3792@news.qwest.net>
On 02/10/12 15:24, Rob wrote:
> I am looking for a perl REGEX statement to remove all the HTML from a
> string except for the<p> tags. It would have to leave the<p> (and
> the</p>) tags but also longer ones such as<p style=...> etc. I
> haven't been able to find anything similar online for this.
>
> Can anyone help with a suitable REGEX for this? I have tried a few
> things but had no success.
>
> Any help would be much appreciated.
>
> Rob
Depending on how complex the 'string' is, you probably want to
avoid a regular expression solution and use a parser.e.g.
HTML::Parser.
Read the documentation and take a look a some of the examples
in the distribution, like hstrip and htext.
------------------------------
Date: Fri, 10 Feb 2012 16:41:32 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Remove all HTML but keep <p> tags
Message-Id: <v4ebj7pnigcit6qosk64uid8t7rkbqqiq4@4ax.com>
Rob <rdw204@gmail.com> wrote:
>I am looking for a perl REGEX statement to remove all the HTML from a
Please see the FAQ and the many, many archived posts why HTML and REGEX
is not a viable combination.
>string except for the <p> tags. It would have to leave the <p> (and
>the </p>) tags but also longer ones such as <p style=...> etc. I
>haven't been able to find anything similar online for this.
>
>Can anyone help with a suitable REGEX for this? I have tried a few
>things but had no success.
That is not surprising because it cannot be done for arbitrary HTML. For
further details please read up on the Chomsky hierarchy of languages.
jue
------------------------------
Date: Sat, 11 Feb 2012 10:06:50 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Remove all HTML but keep <p> tags
Message-Id: <slrnjjcbta.b0c.hjp-usenet2@hrunkner.hjp.at>
[As J. Gleixner has already pointed out, there are HTML parsers
available for perl - doing this with a regexp is almost certainly not
the best way to do this]
On 2012-02-11 00:41, Jürgen Exner <jurgenex@hotmail.com> wrote:
> Rob <rdw204@gmail.com> wrote:
>>I am looking for a perl REGEX statement to remove all the HTML from a
>
> Please see the FAQ and the many, many archived posts why HTML and REGEX
> is not a viable combination.
>
>>string except for the <p> tags. It would have to leave the <p> (and
>>the </p>) tags but also longer ones such as <p style=...> etc. I
>>haven't been able to find anything similar online for this.
What exactly do you mean by "remove all html except <p> tags"?
What would the result of processing the following (simple) file be?
<html>
<head>
<title>
A test
</title>
</head>
<body>
<h1> A test </h1> <h2> for Robs script </h2>
<p>
The quick brown fox jumps over the lazy dog.
</p>
<table>
<tr>
<td>
<p>
upper left
</p>
<p>
lower left
</p>
</td>
<td>
<p>
right
</p>
</td>
</tr>
</table>
<!--
<p>
This is not a paragraph
</p>
-->
<p>
Over & out!
</p>
</body>
</html>
>>Can anyone help with a suitable REGEX for this? I have tried a few
>>things but had no success.
Well, what have you tried?
Some tips:
* Start with a formal grammar of what you want to match.
I usually use some form of BNF.
* Don't try to write the whole Regexp at once. Use one Regexp
for every production in your grammar and use variable substitution
to build more complex regexps (there is a parallel thread about
matching RFC5322 headers with some examples).
* Use /x and comments.
> That is not surprising because it cannot be done for arbitrary HTML. For
> further details please read up on the Chomsky hierarchy of languages.
Care to explain how the difference between regular and context-free
grammars is relevant to the task at hand? And you know of course that
Perl regexps are a superset of regular expressions, so that even if the
task is impossible with a regular expression, it may still be possible
with a regexp (has anyone tried to prove that regexps are/are not
equivalent to context-free grammars lately?).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Fri, 10 Feb 2012 10:12:45 +0000
From: Justin C <justin.1201@purestblue.com>
Subject: WWW::Mechanize submit_form does not return expected
Message-Id: <t57f09-n32.ln1@zem.masonsmusic.co.uk>
The web-page I'm automating with mech is not returning the same data
that it returns when accessed with a browser. The java-script on the
form page, as far as I can see, does no more than sanitize what the user
enters, I can't see how it could possibly be telling the server that the
request is not a real person. I've got $mech->agent_alias('Mac Safari')
so it should think the request is from a real browser. I'm returning
input for all form fields (including the default values for the hidden
fields). I don't know where to go from here.
Any suggestions will be gratefully received. What follows is only for
anyone who would like to know, in detail, what's going on. My code is at
the bottom of this message.
Here's an overview of why I'm doing what I am: The site I'm trying to
automate is an EU governmental one. My employer has recently been hit
with a VAT bill because one of our customers de-registered for VAT early
last year and therefore we shouldn't be sending goods VAT-free. The
customer didn't tell us, and we're liable for unpaid VAT. Our government
site suggest regular checking of customer VAT numbers against the EU
database to avoid this. There is a module on CPAN that can give a
valid/invalid result for VAT details, but I want to capture the
certificate the site issues because it has a consultation number as
proof of checking the VAT status, without which the certificate is
useless, it could easily have been fraudulently made. The only part of
the data that's missing when I use mech is the consultation number, the
vital part that proves you did carry out the check.
The web-page that contains the form I'm mechanising is at
<URL:http://ec.europa.eu/taxation_customs/vies/vieshome.do?selectedLanguage=EN>
subsitute that last EN for your preferred language code, ES, FR, DE, DK,
etc., you can find the form in the source by searching on "viesquer.do".
The CPAN module that gets halfway there is
Business::Tax::VAT::Validation. I didn't discover this until I'd almost
completed my program, but it doesn't provide the consultation number
which can be used as a defence if challenged by the VAT authorities.
Here's the code I'm using, VAT numbers omitted for privacy, if anyone
wants to run this, and can't find any valid data to use, please let me
know by email and I'll send some data that works, I just don't want to
put other people's data 'out there':
my $cust = shift;
# an array ref. $_->[0] = our customer identifier - not submitted, just
# happens to be in the array.
# $_->[1] = 2 letter country EU code
# $_->[2] = customer VAT number
my %requester = (
state => 'GB', # 2 letter country EU code
vat_no => '', # a valid VAT number for the country
# - removed for privacy reasons.
);
my $mech = WWW::Mechanize->new();
# Set a sensible UA - don't want to be thought of as a bot
$mech->agent_alias('Mac Safari');
# load the page containing the form
$mech->get($site_root);
# fill-in and submit the form
$mech->submit_form(
form_name => 'frmVat',
fields => {
ms => $cust->[1],
iso => $cust->[1],
vat => $cust->[2],
reqeusterMs => $requester{state},
requesterIso => $requester{state},
requesterVat => $requester{vat_no},
BtnSubmitVat => 'Verify',
name => '',
companyType => '',
street1 => '',
postcode => '',
city => '',
}
);
return \$mech->content;
__end__
Thank you for any help you can give.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 10 Feb 2012 10:20:37 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: WWW::Mechanize submit_form does not return expected
Message-Id: <4f3543d5$0$9083$815e3792@news.qwest.net>
On 02/10/12 04:12, Justin C wrote:
> The web-page I'm automating with mech is not returning the same data
> that it returns when accessed with a browser. The java-script on the
> form page, as far as I can see, does no more than sanitize what the user
> enters, I can't see how it could possibly be telling the server that the
> request is not a real person. I've got $mech->agent_alias('Mac Safari')
> so it should think the request is from a real browser. I'm returning
> input for all form fields (including the default values for the hidden
> fields). I don't know where to go from here.
[...]
Firefox with the Firebug Plug-in might help you find if you're
sending values differently. You easily can see what's sent and the
response in the Console tab.
If that matches what you're sending, then possibly what's returned
is processed by Javascript before being displayed to the browser, and
that would be the next thing to examine.
------------------------------
Date: Fri, 10 Feb 2012 13:24:58 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: WWW::Mechanize submit_form does not return expected
Message-Id: <slrnjjarqd.m7b.tadmc@tadbox.sbcglobal.net>
J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> On 02/10/12 04:12, Justin C wrote:
>> The web-page I'm automating with mech is not returning the same data
>> that it returns when accessed with a browser. The java-script on the
>> form page, as far as I can see, does no more than sanitize what the user
>> enters, I can't see how it could possibly be telling the server that the
>> request is not a real person. I've got $mech->agent_alias('Mac Safari')
>> so it should think the request is from a real browser. I'm returning
>> input for all form fields (including the default values for the hidden
>> fields). I don't know where to go from here.
> [...]
>
> Firefox with the Firebug Plug-in might help you find if you're
> sending values differently. You easily can see what's sent and the
> response in the Console tab.
>
> If that matches what you're sending, then possibly what's returned
> is processed by Javascript before being displayed to the browser, and
> that would be the next thing to examine.
I'd use the "web scraping proxy" from AT&T:
http://www2.research.att.com/sw/tools/wsp/
It logs HTTP requests/responses in the form of Perl code (UserAgent).
Then we don't need to know what all the JS does, we just need to know
how to construct the request we want...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3609
***************************************
