[32929] in Perl-Users-Digest
Perl-Users Digest, Issue: 4206 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 4 05:17:33 2014
Date: Sun, 4 May 2014 02:17: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 Sun, 4 May 2014 Volume: 11 Number: 4206
Today's topics:
Re: How do I get the text that is found by a regular ex scottcabit@gmail.com
Re: How do I get the text that is found by a regular ex <rweikusat@mobileactivedefense.com>
Re: How do I get the text that is found by a regular ex <jimsgibson@gmail.com>
Re: How do I get the text that is found by a regular ex <rweikusat@mobileactivedefense.com>
Re: IO::Socket client <hjp-usenet3@hjp.at>
Re: IO::Socket client <rweikusat@mobileactivedefense.com>
Re: IO::Socket client <news@todbe.com>
Re: IO::Socket client <rweikusat@mobileactivedefense.com>
Re: IO::Socket client <hjp-usenet3@hjp.at>
Re: IO::Socket client <hjp-usenet3@hjp.at>
Re: IO::Socket client <news@todbe.com>
Re: IO::Socket client <news@todbe.com>
Re: More general programming than perl... <justin.1401@purestblue.com>
Re: More general programming than perl... <justin.1401@purestblue.com>
Re: More general programming than perl... <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 2 May 2014 07:38:43 -0700 (PDT)
From: scottcabit@gmail.com
Subject: Re: How do I get the text that is found by a regular expression?
Message-Id: <b95672c2-c2d7-472e-b199-a4c840a6d47d@googlegroups.com>
Hi,
The regular expression does not seem to work. Here is what I've tried....
# The following pattern finds all document numbers
$find->{Text} = m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
if ($find->Execute()) {
my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
my $docnums_count = @docnums;
print $docnums_count;
}
So, I get into the $find-Execute so the expression is being ound in the word document, but once inside,
my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
never finds any occurrences of the regular expression. I also tried it without the trailing gs. Same result. print $docnums_count always prints 0.
Any ideas?
Thanks
------------------------------
Date: Fri, 02 May 2014 16:14:45 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How do I get the text that is found by a regular expression?
Message-Id: <874n18us9m.fsf@sable.mobileactivedefense.com>
scottcabit@gmail.com writes:
> The regular expression does not seem to work. Here is what I've tried....
>
> # The following pattern finds all document numbers
> $find->{Text} = m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
For how much longer to you plan to repost this particular piece of "code
which doesn't make any sense" (preferably without context so that "Happy
guessing hour!" never ends)?
> if ($find->Execute()) {
> my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
> my $docnums_count = @docnums;
> print $docnums_count;
> }
>
> So, I get into the $find-Execute so the expression is being ound in
> the word document,
... but nobody knows what $find->Execute actually does (Judging from the
more complete example you posted last time, it ought to be 'some kind of
OLE method of some kind of object returned by a 'document' OLE method of
MS-Word. In any case, you're assigning the result of a pattern match
agains $_ which contains the filename File::Find currently returned to
$find->{Text}. This will usually be undef but might be one in case of
'strange circumstances'. And Microsoft DOES NOT publish documentation on
this, at least not anywhere on the web where it could be found with a
reasonable amount of searching.
> but once inside,
> my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
>
> never finds any occurrences of the regular expression.
Nobody knows what $content happens to be but given the broken way in
which you're trying to use this unknown 'presumably find something which
is some sort of text', chances are that the code inside the block is
never executed, anyway.
> Any ideas?
"Stop trying".
------------------------------
Date: Fri, 02 May 2014 11:36:22 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: How do I get the text that is found by a regular expression?
Message-Id: <020520141136223888%jimsgibson@gmail.com>
In article <b95672c2-c2d7-472e-b199-a4c840a6d47d@googlegroups.com>,
<scottcabit@gmail.com> wrote:
> Hi,
>
> The regular expression does not seem to work. Here is what I've tried....
>
> # The following pattern finds all document numbers
> $find->{Text} = m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
That needs to be:
$find->{Text} =~ m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
Note the use of the binding operator '=~' instead of assignment '='
> if ($find->Execute()) {
> my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
> my $docnums_count = @docnums;
> print $docnums_count;
> }
>
> So, I get into the $find-Execute so the expression is being ound in the
> word document, but once inside,
> my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
What is in $content? What relation does $content have with the
previously used $find->{Text}? What is in $find, anyway?
> never finds any occurrences of the regular expression. I also tried it
> without the trailing gs. Same result. print $docnums_count always prints 0.
>
> Any ideas?
I suggest you separate the tasks of 1) fetching the document and 2)
parsing the document looking for document numbers. Put the content of
your document into a Perl scalar variable (e.g., $content), print that,
and then attempt to extract document numbers from that. That should
take only a short program, which you could post in its entirety here.
Then we wouldn't have to guess what the rest of your program is doing,
Something like this:
#!/usr/bin/perl
use strict;
use warnings;
my $content = 'stuff ... 123-4567-ABC ... more stuff';
print "$content\n";
my @docnums = $content =~ /(\d{3}-\d{4}-\w{3})/gs;
print "@docnums\n";
--
Jim Gibson
------------------------------
Date: Fri, 02 May 2014 20:16:07 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How do I get the text that is found by a regular expression?
Message-Id: <87vbtot2iw.fsf@sable.mobileactivedefense.com>
Jim Gibson <jimsgibson@gmail.com> writes:
> In article <b95672c2-c2d7-472e-b199-a4c840a6d47d@googlegroups.com>,
> <scottcabit@gmail.com> wrote:
>
>> Hi,
>>
>> The regular expression does not seem to work. Here is what I've tried....
>>
>> # The following pattern finds all document numbers
>> $find->{Text} = m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
>
> That needs to be:
> $find->{Text} =~ m/(\d{3}-\d{4}-\w{3})/; #\d{3})/;
>
> Note the use of the binding operator '=~' instead of assignment '='
Judging from 'glimpses on other people web postings', $find likely
refers to an object which can be used to 'find' something in the
associated document and $find->{Text} seems to be what $find is
supposed to look for (and the OP likely believes that he is "assigning
the regex" to this, not the result of evaluating the match, and that
this would 'magically' cause the OLE-object represented by $find to do
'PCRE-matching' instead of whatever it usually does).
------------------------------
Date: Fri, 2 May 2014 12:41:39 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: IO::Socket client
Message-Id: <slrnlm6tj3.s9h.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-02 10:01, $Bill <news@todbe.com> wrote:
> On 5/2/2014 02:03, Peter J. Holzer wrote:
>>
>> You haven't answered any of my points. Neither have you given a reason
>> why "telling the server what you are going to do" would have to be in a
>> separate message, nor have you answered whether the above is one message
>> or two (or five). And for the latter question I would like to see a
>> better reason than "because rfc 2616 says so".
>
> Sure I did. Using more than 1 msg necessitates state info and probably
> maintaining an open socket.
Ok, again:
Question 1: Why does "telling the server what you are going to do"
have to be in a separate message?
"Using more than 1 msg necessitates state info and probably
maintaining an open socket." doesn't answer the question. On the
contrary, it argues that you should tell the server in the same
message, not in a separate message. It doesn't even try to
argue why this would be impossible.
Question 2: Is the above one message or two or five?
"Using more than 1 msg necessitates state info and probably
maintaining an open socket." doesn't answer the question. The
answer would have to be include one of the numbers I suggested
(or possibly a different number).
So. No, you haven't.
>>> You don't have to keep state information on the socket (or keep the same
>>> socket open for that matter).
>>
>> How does the state information needed to read the HTTP response above
>> change whether you view it as one or two (or five) messages?
>
> You don't need state info if there's only 1 msg.
You keep repeating this but you don't give any reason for it. The
sequence of bytes on the wire doesn't change. Why would the amount of
state info change? In any case you need two pieces of state info:
* Whether you are in the header/message 1 or the body/message 2
* If you are in the latter, how much you have already read.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Fri, 02 May 2014 13:41:23 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: IO::Socket client
Message-Id: <871twcz72k.fsf@sable.mobileactivedefense.com>
"$Bill" <news@todbe.com> writes:
> On 5/2/2014 02:03, Peter J. Holzer wrote:
>>
>> You haven't answered any of my points. Neither have you given a reason
>> why "telling the server what you are going to do" would have to be in a
>> separate message, nor have you answered whether the above is one message
>> or two (or five). And for the latter question I would like to see a
>> better reason than "because rfc 2616 says so".
>
> Sure I did. Using more than 1 msg necessitates state info and probably
> maintaining an open socket.
If 'an open socket' wasn't supposed to be maintained, the whole question
would be moot as 'closing the socket' would/ could mark the end of 'the
current message'.
>>> You don't have to keep state information on the socket (or keep the same
>>> socket open for that matter).
>>
>> How does the state information needed to read the HTTP response above
>> change whether you view it as one or two (or five) messages?
>
> You don't need state info if there's only 1 msg.
[...]
> I think you just want to argue. I was responding to George's scenario:
>
> when you want complex things like.
>
> -- hey client, I am going to send you a file so big
> ++ ok server
I think you misunderstood that and that George was providing simplified
examples of his actual messages, eg, that 'hey client, I am going to
send you a file so big' is supposed to refer to something like sending a
header with a command code of 'file falling from the sky' and a size,
followed by the file data and that '++ok server' is the client telling
the server that it has processed/ downloaded the file and is ready for
the next protocol exchange (unusually organized here because the
server seems to be active instead of acting on client requests but even
this might be an impression accidentally caused by the textual form).
------------------------------
Date: Fri, 02 May 2014 06:46:04 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: IO::Socket client
Message-Id: <lk07iu$vn8$1@dont-email.me>
On 5/2/2014 03:41, Peter J. Holzer wrote:
>
> Ok, again:
>
> Question 1: Why does "telling the server what you are going to do"
> have to be in a separate message?
I never said it did - George implied that with his scenario.
> Question 2: Is the above one message or two or five?
Not sure what you are referring to 'the above' - it can be one using my scenario
or more using others.
> So. No, you haven't.
Yes I have - you just want to keep arguing about it.
>> You don't need state info if there's only 1 msg.
>
> You keep repeating this but you don't give any reason for it. The
> sequence of bytes on the wire doesn't change. Why would the amount of
> state info change? In any case you need two pieces of state info:
>
> * Whether you are in the header/message 1 or the body/message 2
> * If you are in the latter, how much you have already read.
If the control is in the header of the msg, there is no need to maintain
state because the operation is completed at the time of the msg. Using
a different protocol (implied by George's scenario):
-- now lets exchange some small control messages
++ ok server
-- now get a big serialized data structure
++ not everything is defined
-- ops client I did not like your answer, wait for three messages for me
You have to remember info between msgs because the transaction is not yet
complete. And that's the last time I'm saying it. If you think George's scenario
doesn't imply that, then we disagree on what George said/implied and that's OK too.
I;m not going over it again.
------------------------------
Date: Fri, 02 May 2014 16:00:24 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: IO::Socket client
Message-Id: <87bnvgusxj.fsf@sable.mobileactivedefense.com>
"$Bill" <news@todbe.com> writes:
[...]
>> You keep repeating this but you don't give any reason for it. The
>> sequence of bytes on the wire doesn't change. Why would the amount of
>> state info change? In any case you need two pieces of state info:
>>
>> * Whether you are in the header/message 1 or the body/message 2
>> * If you are in the latter, how much you have already read.
>
> If the control is in the header of the msg, there is no need to maintain
> state because the operation is completed at the time of the msg.
This can only ever be true (for IPv4) if each 'msg', including all
protocol-specific framing, has a size of at most 64K and in practice,
for TCP, the limit is 1460 bytes or less. As soon as the SDUs become
larger than that, state has to be maintained for processing them as
this will require multiple receive operations.
------------------------------
Date: Fri, 2 May 2014 20:30:04 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: IO::Socket client
Message-Id: <slrnlm7p1c.hdd.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-02 13:46, $Bill <news@todbe.com> wrote:
> On 5/2/2014 03:41, Peter J. Holzer wrote:
>> Ok, again:
>>
>> Question 1: Why does "telling the server what you are going to do"
>> have to be in a separate message?
>
> I never said it did - George implied that with his scenario.
No, I don't think he did. He wrote:
| -- hey client, I am going to send you a file so big
| ++ ok server
(and some similar exchanges). AFAICS he didn't imply anywhere that "I am
going to send you a file so big" and the file itself were two separate
messages. But you apparently assumed that he did, so I pointed out that
you were making unfounded assumptions.
>> Question 2: Is the above one message or two or five?
>
> Not sure what you are referring to 'the above'
HTTP response I posted. Here it is again:
200 OK
Content-Type: text/html
Size: 1234
<html>...
> - it can be one using my scenario or more using others.
Now I'm not sure what you mean by "it". Assuming you mean the HTTP
response: Right. It could be one or several. Now why does processing the
absolutely identical sequence of bytes more state information when you
view it as several messages instead of only one? It is exactly the same
and of course it can be processed in exactly the same way.
>> So. No, you haven't.
>
> Yes I have - you just want to keep arguing about it.
>
>>> You don't need state info if there's only 1 msg.
>>
>> You keep repeating this but you don't give any reason for it. The
>> sequence of bytes on the wire doesn't change. Why would the amount of
>> state info change? In any case you need two pieces of state info:
>>
>> * Whether you are in the header/message 1 or the body/message 2
>> * If you are in the latter, how much you have already read.
>
> If the control is in the header of the msg, there is no need to maintain
> state because the operation is completed at the time of the msg.
You still need to maintain state while processing the message. And - I
repeat myself - you need exactly the same state. You need to be able to
recognize the end of the HTTP header and the end of the HTTP body (for
which you need information from the HTTP header (the size) and a counter
for how many bytes of the body you have already read. This doesn't
change whether you view that as one message consisting of two parts or
two separate messages.
> And that's the last time I'm saying it. If you think George's
> scenario doesn't imply that, then we disagree on what George
> said/implied and that's OK too.
Yes, we disagree on that. I have now repeatedly asked why you think that
George said/implied that and you have never answered that question.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Fri, 2 May 2014 22:25:20 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: IO::Socket client
Message-Id: <slrnlm7vpg.gs2.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-02 13:46, $Bill <news@todbe.com> wrote:
> On 5/2/2014 03:41, Peter J. Holzer wrote:
>> Ok, again:
>>
>> Question 1: Why does "telling the server what you are going to do"
>> have to be in a separate message?
>
> I never said it did - George implied that with his scenario.
No, I don't think he did. He wrote:
| -- hey client, I am going to send you a file so big
| ++ ok server
(and some similar exchanges). AFAICS he didn't imply anywhere that "I am
going to send you a file so big" and the file itself were two separate
messages. But you apparently assumed that he did, so I pointed out that
you were making unfounded assumptions.
>> Question 2: Is the above one message or two or five?
>
> Not sure what you are referring to 'the above'
HTTP response I posted. Here it is again:
200 OK
Content-Type: text/html
Size: 1234
<html>...
> - it can be one using my scenario or more using others.
Now I'm not sure what you mean by "it". Assuming you mean the HTTP
response: Right. It could be one or several. Now why does processing the
absolutely identical sequence of bytes need more state information when
you view it as several messages instead of only one? It is exactly the
same and of course it can be processed in exactly the same way.
>>> You don't need state info if there's only 1 msg.
>>
>> You keep repeating this but you don't give any reason for it. The
>> sequence of bytes on the wire doesn't change. Why would the amount of
>> state info change? In any case you need two pieces of state info:
>>
>> * Whether you are in the header/message 1 or the body/message 2
>> * If you are in the latter, how much you have already read.
>
> If the control is in the header of the msg, there is no need to maintain
> state because the operation is completed at the time of the msg.
You still need to maintain state while processing the message. And - I
repeat myself - you need exactly the same state. You need to be able to
recognize the end of the HTTP header and the end of the HTTP body (for
which you need information from the HTTP header (the size) and a counter
for how many bytes of the body you have already read. This doesn't
change whether you view that as one message consisting of two parts or
two separate messages.
> And that's the last time I'm saying it. If you think George's
> scenario doesn't imply that, then we disagree on what George
> said/implied and that's OK too.
Yes, we disagree on that. I have now repeatedly asked why you think that
George said/implied that and you have never answered that question.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Fri, 02 May 2014 16:36:18 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: IO::Socket client
Message-Id: <lk1a5m$vd7$1@dont-email.me>
On 5/2/2014 08:00, Rainer Weikusat wrote:
> "$Bill" <news@todbe.com> writes:
>
> [...]
>
>>> You keep repeating this but you don't give any reason for it. The
>>> sequence of bytes on the wire doesn't change. Why would the amount of
>>> state info change? In any case you need two pieces of state info:
>>>
>>> * Whether you are in the header/message 1 or the body/message 2
>>> * If you are in the latter, how much you have already read.
>>
>> If the control is in the header of the msg, there is no need to maintain
>> state because the operation is completed at the time of the msg.
>
> This can only ever be true (for IPv4) if each 'msg', including all
> protocol-specific framing, has a size of at most 64K and in practice,
> for TCP, the limit is 1460 bytes or less. As soon as the SDUs become
> larger than that, state has to be maintained for processing them as
> this will require multiple receive operations.
If you assume record oriented msgs rather than streams, you could accumulate
larger msgs with virtually minimal state info with sufficient storage
(requiring mult I/O operations of course).
It would require accumulating the ENTIRE msg before starting to process it OR
to process part of the msg (knowing what it is) and maintaining some small
state info while accumulating the rest of the data.
File xfers pretty much always require some state info to keep track of what
file each msg is part of or you could segment the file and avoid that too
for the most part.
UDP messages could also be used, but I prefer to impose a record header and
use TCP/IP streams - you just need sufficient buffering or keeping of state
info (which is pretty much mandatory for an unsegmented file xfer).
------------------------------
Date: Fri, 02 May 2014 16:47:09 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: IO::Socket client
Message-Id: <lk1aq1$30i$1@dont-email.me>
One last time Peter - my take of George's scenario was that it was overly
complicated requiring multiple transactions to complete which I deemed
unnecessary if true. If your take was different, that's fine and there
is no need for to keep arguing a moot point.
I was not referring to the underlying protocol, but the task level protocol.
Whether you have to read one or more segments of data (mult I/O transactions)
wasn't the issue and would require buffering and state info to accomplish in
a stream env if there weren't sufficient smarts above that layer to handle it
(eg: segmenting a file xfer).
I won't respond to any more discussion on this subject without a change in
specific topic.
------------------------------
Date: Fri, 2 May 2014 11:46:33 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: More general programming than perl...
Message-Id: <9l9c3b-7ll.ln1@zem.masonsmusic.co.uk>
On 2014-05-02, Eric Pozharski <whynot@pozharski.name> wrote:
> with <q32a3b-iec.ln1@zem.masonsmusic.co.uk> Justin C wrote:
>> On 2014-05-01, Eric Pozharski <whynot@pozharski.name> wrote:
>>> with <be373b-kaa.ln1@zem.masonsmusic.co.uk> Justin C wrote:
>
>>>> I need to prepare a "Latest Products" document, the ...
>>> Please, define "document".
>> I am not sure it is relevant to the question I asked, but my
>> document is actually an Excel spreadsheet which will be printed
>> as a PDF.
>
> "Document", being defined, defines "page". From your conversations with
> others I'm glad to find out that your "document" looks more like
> text/plain (wrapped in application/pdf) then application/pdf itself.
> You don't need Excel for this. Or perl -- Excel would be closer to
> pages than perl.
Though we print the document for customers the original Excel
file is also available to download from our web-site, and
some customers are used to it that way, I wouldn't want to
take that away from those that like it that way - who may
have programs that read the file and 'do stuff' with the data.
My preference would be for LaTeX to produce it, because I
know it can do better typesetting than anything else in my
toolbox, but that doesn't get around the desire to still
support those who like the Excel file... maybe two files, a
'pretty' PDF and a plain Excel file. Hmmm.
I'm going to enjoy this!
Justin.
--
Justin C, by the sea.
------------------------------
Date: Fri, 2 May 2014 11:48:31 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: More general programming than perl...
Message-Id: <vo9c3b-7ll.ln1@zem.masonsmusic.co.uk>
On 2014-04-30, Justin C <justin.1401@purestblue.com> wrote:
>
> I need to prepare a "Latest Products" document, the
> contents are coming from a database, I've got to fill the
> document with the latest and stop when the document is 24
> pages, however, the document runs chronologically from
> oldest to newest. I'm trying to work out how I can decide
> which item/date to put at the start of the document, so I
> don't run out of data before 24 pages, or over-run 24
> pages.
[snip]
Thank you to all who have made suggestions. I have some
interesting things to think about, and you have all helped
me better understand what I have to achieve.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Sat, 03 May 2014 13:50:58 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: More general programming than perl...
Message-Id: <slrnlm9igi.64g.whynot@orphan.zombinet>
with <9l9c3b-7ll.ln1@zem.masonsmusic.co.uk> Justin C wrote:
*SKIP*
> I'm going to enjoy this!
No, you won't. It will be terrible pain.
p.s. I'm doing typesetting for living. And yes, it's texlive and
friends.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
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 4206
***************************************
