[32674] in Perl-Users-Digest
Perl-Users Digest, Issue: 3950 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 17 05:17:57 2013
Date: Fri, 17 May 2013 02:17:24 -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 Fri, 17 May 2013 Volume: 11 Number: 3950
Today's topics:
Efficiency of s///e? (Tim McDaniel)
Re: Efficiency of s///e? <derykus@gmail.com>
Re: Efficiency of s///e? <ben@morrow.me.uk>
is there a really simple cgi chat anywhere? <visphatesjava@gmail.com>
Re: is there a really simple cgi chat anywhere? <visphatesjava@gmail.com>
Re: oh perlbal you!!! you got what i need....but you do <visphatesjava@gmail.com>
Perl regex - How to make my greedy quantifier greedier? <cibalo@gmx.co.uk>
Re: Perl regex - How to make my greedy quantifier greed <damien.wyart@free.fr>
Re: Perl regex - How to make my greedy quantifier greed <thepoet_nospam@arcor.de>
Re: utf8 <rweikusat@mssgmbh.com>
Re: utf8 <rweikusat@mssgmbh.com>
Re: utf8 <manfred.lotz@arcor.de>
Re: utf8 <hhr-m@web.de>
Re: utf8 <hhr-m@web.de>
Re: utf8 <rweikusat@mssgmbh.com>
Re: Why do Perl programmers make more money than Python <visphatesjava@gmail.com>
Re: Why do Perl programmers make more money than Python <visphatesjava@gmail.com>
Re: Why do Perl programmers make more money than Python <visphatesjava@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 May 2013 03:36:48 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Efficiency of s///e?
Message-Id: <kn48kg$kqb$1@reader1.panix.com>
There's a sub in our code base which has something like
my $prevent_infinite_loop = 0;
while ($prevent_infinite_loop++ < 1000 && $text =~ /(complicated) (regular) (expression)/) {
... various calculations on $1, $2, $3, ... resulting in $replacement;
$text =~ s/(complicated) (regular) (expression)/$replacement/;
# that's exactly the same regular expression as above
}
(though I think that, with the particular pattern, an infinite loop is
impossible.) To add new features and for maintainability,
I've developed
$text =~ s{(simpler)}{
my $found = $1;
... various calculations involving split on $found, unshift, ...
$replacement;
}eg;
I'm wondering about the efficiency of this approach, partincularly
s{}{}e. For instance, is the right-hand side code compiled at run
time, or at compile time? Any other major concerns? We still use
Perl 5.8.8 for now, alas.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 16 May 2013 22:15:03 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: Efficiency of s///e?
Message-Id: <kn4eda$f99$1@speranza.aioe.org>
On 5/16/2013 8:36 PM, Tim McDaniel wrote:
> There's a sub in our code base which has something like
>
> my $prevent_infinite_loop = 0;
> while ($prevent_infinite_loop++ < 1000 && $text =~ /(complicated) (regular) (expression)/) {
> ... various calculations on $1, $2, $3, ... resulting in $replacement;
> $text =~ s/(complicated) (regular) (expression)/$replacement/;
> # that's exactly the same regular expression as above
> }
>
> (though I think that, with the particular pattern, an infinite loop is
> impossible.) To add new features and for maintainability,
> I've developed
>
> $text =~ s{(simpler)}{
> my $found = $1;
> ... various calculations involving split on $found, unshift, ...
> $replacement;
> }eg;
>
> I'm wondering about the efficiency of this approach, partincularly
> s{}{}e. For instance, is the right-hand side code compiled at run
> time, or at compile time? Any other major concerns? We still use
> Perl 5.8.8 for now, alas.
>
It's syntax checked and compiled at compile time along with the rest of
your program.
The only gotcha IMO is the replacement morphing into a
long,hard-to-unravel mess that's hard-on-the-eyes and tough to debug.
Even commented, a big multi-line s/pattern/replacement/ becomes vertigo
inducing.
s{ ... }
{ $1 ... # blah
.... # more blah...
...
....
}gex;
At some point, a plain old "if" block seems better.
--
Charles DeRykus
------------------------------
Date: Fri, 17 May 2013 09:58:17 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Efficiency of s///e?
Message-Id: <928h6a-c8i.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 5/16/2013 8:36 PM, Tim McDaniel wrote:
> > There's a sub in our code base which has something like
> >
> > my $prevent_infinite_loop = 0;
> > while ($prevent_infinite_loop++ < 1000 && $text =~ /(complicated)
> (regular) (expression)/) {
> > ... various calculations on $1, $2, $3, ... resulting in
> $replacement;
> > $text =~ s/(complicated) (regular) (expression)/$replacement/;
> > # that's exactly the same regular expression as above
> > }
> >
> > (though I think that, with the particular pattern, an infinite loop is
> > impossible.) To add new features and for maintainability,
> > I've developed
> >
> > $text =~ s{(simpler)}{
> > my $found = $1;
> > ... various calculations involving split on $found, unshift, ...
> > $replacement;
> > }eg;
You can also use @+ and substr, as was discussed here a little while
ago:
while (... and $text =~ /.../) {
my ($start, $length) = ($-[0], $+[0] - $-[0]);
# calculate $replacement
substr $text, $start, $length, $replacement;
}
> > I'm wondering about the efficiency of this approach, partincularly
> > s{}{}e. For instance, is the right-hand side code compiled at run
> > time, or at compile time? Any other major concerns? We still use
> > Perl 5.8.8 for now, alas.
> >
>
> It's syntax checked and compiled at compile time along with the rest of
> your program.
>
> The only gotcha IMO is the replacement morphing into a
> long,hard-to-unravel mess that's hard-on-the-eyes and tough to debug.
> Even commented, a big multi-line s/pattern/replacement/ becomes vertigo
> inducing.
>
> s{ ... }
> { $1 ... # blah
> .... # more blah...
> ...
> ....
> }gex;
>
> At some point, a plain old "if" block seems better.
A block like
s{...}{
# code
}gex;
isn't entirely different from an if: to some extent it's just a
brace-delimited block like any other. However, given that it does
actually have slightly strange parsing rules, I'd probably prefer to
move large amounts of code into a sub, either named or anonymous:
my $dorepl = sub { ... };
s/$pattern/$dorepl->()/ge;
Ben
------------------------------
Date: Thu, 16 May 2013 13:23:20 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: is there a really simple cgi chat anywhere?
Message-Id: <0eca6bf2-89ad-40ef-a3b1-932cc861ddb5@googlegroups.com>
something that has like 1 file
adds what i chat to file
returns to broswser a box with top 30 lines of file
each line having time name and text fo chat
a input form for new chat text
and a submit button
thats it
nothign more
no login etc
anyone hit page can input and its aded to bottom fo file
name maybe is just chatter 1 .. N
and maybe 1 comamdn to change chatter 5 to joe or whatever
rest just chater name time and chat text
thats it
------------------------------
Date: Thu, 16 May 2013 13:23:56 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: is there a really simple cgi chat anywhere?
Message-Id: <28d5fdc1-243f-4983-830a-7a1aeb1c62e8@googlegroups.com>
or even btter when first chat it asks you name
then that name used
------------------------------
Date: Thu, 16 May 2013 13:11:48 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: oh perlbal you!!! you got what i need....but you dotn work with 5 16
Message-Id: <2a0627c3-c447-4607-81ba-da89ff6c9e64@googlegroups.com>
perlbal is only million times easier than apache :)
I bet we could replace out f5 load balancers with it too!!
------------------------------
Date: Thu, 16 May 2013 20:46:00 -0700 (PDT)
From: cibalo <cibalo@gmx.co.uk>
Subject: Perl regex - How to make my greedy quantifier greedier?
Message-Id: <cdcaf60d-5bb6-4472-b4ba-626b86632b99@ua8g2000pbb.googlegroups.com>
Hello,
I would like to try some string matching in perl as is in the title.
Let's create some testfiles for testing as follows.
$ mkdir -vp testing/dir.a/dir_b/dir-c; cd testing/dir.a/dir_b/dir-c; \
touch This_is_testing1_org.txt This-is-testing2_org.txt \
this_is_testing3_org.txt this-is-testing4_org.txt; cd
What I am looking for is the result similar to:
$ find testing -type f -name "[a-z]*\.txt"
testing/dir.a/dir_b/dir-c/this-is-testing4_org.txt
testing/dir.a/dir_b/dir-c/this_is_testing3_org.txt
I know it is more easier to find the result this way.
Now I try with perl regex as:
$ ls testing/dir.a/dir_b/dir-c/* | perl -ne '/^(.*\/)([a-z].*)$/;
print $1, " - ", $2, "\n";'
testing/dir.a/dir_b/ - dir-c/This_is_testing1_org.txt
testing/dir.a/dir_b/ - dir-c/This-is-testing2_org.txt
testing/dir.a/dir_b/dir-c/ - this_is_testing3_org.txt
testing/dir.a/dir_b/dir-c/ - this-is-testing4_org.txt
Actually, I want my leftmost greedy quantifier, (.*\/), to be so
greedier that it can prevent the first two output items from listing.
What interests me most is this:
$ ls testing/dir.a/dir_b/dir-c/* | perl -ne '/^(.*\/)([A-Z].*)$/;
print $1, " - ", $2, "\n";'
testing/dir.a/dir_b/dir-c/ - This_is_testing1_org.txt
testing/dir.a/dir_b/dir-c/ - This-is-testing2_org.txt
testing/dir.a/dir_b/dir-c/ - This-is-testing2_org.txt
testing/dir.a/dir_b/dir-c/ - This-is-testing2_org.txt
"This-is-testing2_org.txt" is repeated three times.
Can you please let me know what I'm missing?
Thank you very much in advance!!!
Best Regards,
cibalo
------------------------------
Date: Fri, 17 May 2013 10:14:47 +0200
From: Damien Wyart <damien.wyart@free.fr>
Subject: Re: Perl regex - How to make my greedy quantifier greedier?
Message-Id: <5195e706$0$2279$426a74cc@news.free.fr>
* cibalo <cibalo@gmx.co.uk> in comp.lang.perl.misc:
> [...]
> Now I try with perl regex as:
> $ ls testing/dir.a/dir_b/dir-c/* | perl -ne '/^(.*\/)([a-z].*)$/;
> print $1, " - ", $2, "\n";'
> testing/dir.a/dir_b/ - dir-c/This_is_testing1_org.txt
> testing/dir.a/dir_b/ - dir-c/This-is-testing2_org.txt
> testing/dir.a/dir_b/dir-c/ - this_is_testing3_org.txt
> testing/dir.a/dir_b/dir-c/ - this-is-testing4_org.txt
> Actually, I want my leftmost greedy quantifier, (.*\/), to be so
> greedier that it can prevent the first two output items from listing.
> [...]
To answer strictly to your question, what you were looking for is '*+' ;
but this will not work in your regex: you need to exclude '/' in the
second group to match only on the filename.
You can read more on the topic (using regexes with paths and filenames)
here: http://stackoverflow.com/questions/169008/regex-for-parsing-directory-and-filename
--
DW
------------------------------
Date: Fri, 17 May 2013 10:35:50 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Perl regex - How to make my greedy quantifier greedier?
Message-Id: <5195ebe6$0$6630$9b4e6d93@newsspool2.arcor-online.net>
Am 17.05.2013 05:46, schrieb cibalo:
> What I am looking for is the result similar to:
> $ find testing -type f -name "[a-z]*\.txt"
> testing/dir.a/dir_b/dir-c/this-is-testing4_org.txt
> testing/dir.a/dir_b/dir-c/this_is_testing3_org.txt
> I know it is more easier to find the result this way.
> Now I try with perl regex as:
> $ ls testing/dir.a/dir_b/dir-c/* | perl -ne '/^(.*\/)([a-z].*)$/;
> print $1, " - ", $2, "\n";'
> testing/dir.a/dir_b/ - dir-c/This_is_testing1_org.txt
> testing/dir.a/dir_b/ - dir-c/This-is-testing2_org.txt
> testing/dir.a/dir_b/dir-c/ - this_is_testing3_org.txt
> testing/dir.a/dir_b/dir-c/ - this-is-testing4_org.txt
> Actually, I want my leftmost greedy quantifier, (.*\/), to be so
> greedier that it can prevent the first two output items from listing.
Two approaches instantly come to my mind:
1. Modifying the pattern for the filename so it looses
its greediness, which unfortunately isn't solved by
adding the non-greedy modifier. A simple solution is
looking for anything but a slash:
/^ (.*\/) ([^\/]+) $/x;
2. Use a negative look-ahead assertion after the first
pattern to invalidate a match if there's still a slash
further ahead:
/^ (.*\/) (?!.*\/) ([a-z].*) $/x;
This one has the added benefit that the capture for $2
is applied to the filename only.
-Chris
------------------------------
Date: Thu, 16 May 2013 17:01:40 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: utf8
Message-Id: <87wqqylxqz.fsf@sapphire.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Wed, 15 May 2013, Rainer Weikusat wrote:
>
>> Helmut Richter <hhr-m@web.de> writes:
>
>> > The idea is to separate things that belong to the interface from those
>> > that do not. The latter things may change at any time or from one
>> > implementation to another without doing any harm to people who have only
>> > used the documented interface and not arbitrary implementation decisions
>> > of one particular implementation. This is a wise way to proceed.
>
>> That's a completely general statement about "good programming
>> practices".
>
> Indeed. And it is meant as such.
Doesn't this 'delete content and reply to a more convenient
fabrication' trick become boring over time?
,----
| The sole purpose it is supposed to fulfil here is to
| suggest that an opinion about something which happens to conflict with
| some other opinion would somehow conflict with the mentioned 'good
| programming practice' without detailing how exactly.
`----
What you should realize here that this is not a dogma, ie, a statement
detailing an unquestionable truth made by a (by definition) infallible
entity, but a generalized guideline supposed to be of _demonstable_
practical usefulness in 'certain situations'. Consequently, quoting it
as if it was akin to "Thou shalt not bear false witness against thy
neighbour" is not sufficient as argument in favor of or against
anything, even more so when actual existance of a 'violation of the
principle' is just implied but not described. Yet more so, when the
statement is demonstrably wrong: The Perl programming language is only
a part of the 'interface' to perl, the other is the extension
facilitiy which has direct access to everything inside the Perl core,
including the mechanics of character handling.
> Implementing something in a way that the arbirtrary choice of implementation
> details becomes part of the interface and thus can never again be changed
> would be a major blunder,
'The interface' itself is nothing but the cumulative effect of a set
of perfectly arbitrary implementation choices: Every perl operator
could have been implemented in a different way or not implemented at
all.
I'm going to ignore the rest of this text because you aren't telling
the truth, you know that, I know that, and you know that I know that.
------------------------------
Date: Thu, 16 May 2013 17:05:16 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: utf8
Message-Id: <87sj1mlxkz.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> I'm going to ignore the rest of this text because you aren't telling
> the truth, you know that, I know that, and you know that I know that.
Addition: A discussion of the relative merits of either approach for
handling 'extended characters' could be interesting. However, I'm not
interested in trying to argue for both sides, ie, against my own
standpoint, and these "the Gods have chosen wisely and now it is for
the mortals to obey" declarations of faith (or fandom) are pointless.
------------------------------
Date: Thu, 16 May 2013 18:26:37 +0200
From: Manfred Lotz <manfred.lotz@arcor.de>
Subject: Re: utf8
Message-Id: <20130516182637.446c16b0@arcor.com>
On Thu, 16 May 2013 11:34:15 +0200
"Dr.Ruud" <rvtol+usenet@xs4all.nl> wrote:
> On 15/05/2013 17:48, Manfred Lotz wrote:
>
> > In my opinion it makes no sense to leave out 'use:utf8;' if I have
> > utf8 stuff in my script which is outside of ASCII.
>
> Sure, if your source file is "in 'utf8' format" (and of course a
> fully ASCII file is 'utf8' (and 'UTF-8') as well), then it shouldn't
> harm.
>
> But still be aware of the consequences. If you save the file as
> latin1 at some point, you break it, exactly because of the "use
> utf8;".
>
Yep, this is true. However, Emacs wouldn't do this. :-)
>
> I prefer my source files to be ASCII, so I use code like "\x{1234}".
>
>
> Now read what the module's documentation states:
>
> utf8 - Perl pragma to enable/disable UTF-8 (or UTF-EBCDIC) in source
> code [...]
>
> The "use utf8" pragma tells the Perl parser to allow UTF-8 in the
> program text in the current lexical scope [...]
>
> Do not use this pragma for anything else than telling Perl that your
> script is written in UTF-8.
>
I anyway would use the utf8 pragma only if I really need it.
--
Manfred
------------------------------
Date: Thu, 16 May 2013 18:32:27 +0200
From: Helmut Richter <hhr-m@web.de>
Subject: Re: utf8
Message-Id: <alpine.LNX.2.00.1305161830310.5412@badwlrz-clhri01.ws.lrz.de>
On Thu, 16 May 2013, Rainer Weikusat wrote:
> Helmut Richter <hhr-m@web.de> writes:
> > On Wed, 15 May 2013, Rainer Weikusat wrote:
> >
> >> Helmut Richter <hhr-m@web.de> writes:
> >
> >> > The idea is to separate things that belong to the interface from those
> >> > that do not. The latter things may change at any time or from one
> >> > implementation to another without doing any harm to people who have only
> >> > used the documented interface and not arbitrary implementation decisions
> >> > of one particular implementation. This is a wise way to proceed.
> >
> >> That's a completely general statement about "good programming
> >> practices".
> >
> > Indeed. And it is meant as such.
>
> Doesn't this 'delete content and reply to a more convenient
> fabrication' trick become boring over time?
>
> ,----
> | The sole purpose it is supposed to fulfil here is to
> | suggest that an opinion about something which happens to conflict with
> | some other opinion would somehow conflict with the mentioned 'good
> | programming practice' without detailing how exactly.
> `----
I did not like to answer your allegation of motives which are not mine.
> I'm going to ignore the rest of this text because you aren't telling
> the truth, you know that, I know that, and you know that I know that.
Interesting twist.
--
Helmut Richter
------------------------------
Date: Thu, 16 May 2013 18:39:05 +0200
From: Helmut Richter <hhr-m@web.de>
Subject: Re: utf8
Message-Id: <alpine.LNX.2.00.1305161833120.5412@badwlrz-clhri01.ws.lrz.de>
On Thu, 16 May 2013, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
> > I'm going to ignore the rest of this text because you aren't telling
> > the truth, you know that, I know that, and you know that I know that.
>
> Addition: A discussion of the relative merits of either approach for
> handling 'extended characters' could be interesting. However, I'm not
> interested in trying to argue for both sides, ie, against my own
> standpoint, and these "the Gods have chosen wisely and now it is for
> the mortals to obey" declarations of faith (or fandom) are pointless.
My wording of "the Gods have chosen wisely and now it is for the mortals
to obey" was "I, too, have doubts that they chose the best solution."
I have only much more serious doubts that your idea to publish
implementation details as interface would have been better.
Another example: I am mostly using Emacs as text editor. I do know that
when I type the character "ä" or "§" when entering text, exactly this
character will appear in the file in the encoding I choose when saving the
file. I have no idea how this character is stored internally while emacs
is underway. And that's absolutely fine with me. Why should perl not do
likewise?
--
Helmut Richter
------------------------------
Date: Thu, 16 May 2013 18:21:08 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: utf8
Message-Id: <87obcalu2j.fsf@sapphire.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Thu, 16 May 2013, Rainer Weikusat wrote:
>
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>
>> [...]
>>
>> > I'm going to ignore the rest of this text because you aren't telling
>> > the truth, you know that, I know that, and you know that I know that.
>>
>> Addition: A discussion of the relative merits of either approach for
>> handling 'extended characters' could be interesting. However, I'm not
>> interested in trying to argue for both sides, ie, against my own
>> standpoint, and these "the Gods have chosen wisely and now it is for
>> the mortals to obey" declarations of faith (or fandom) are pointless.
>
> My wording of "the Gods have chosen wisely and now it is for the mortals
> to obey" was "I, too, have doubts that they chose the best solution."
>
> I have only much more serious doubts that your idea to publish
> implementation details as interface would have been better.
But this isn't my idea, that's just a totally generic label you have
chosen to attach to a certain standpoint regarding how 'unicode
strings' should be handled. It is also wrong to refer to this as 'my
idea' since it isn't may idea and to refer to it has not published
because it *is* part of the published documentation of perl. For
instance, to this day, the perlguts manpage contains the following
text:
To fix this, some people formed Unicode, Inc. and produced a
new character set containing all the characters you can
possibly think of and more. There are several ways of
representing these characters, and the one Perl uses is called
UTF-8. UTF-8 uses a variable number of bytes to represent a
character.
http://perldoc.perl.org/perlguts.html#Unicode-Support
> Another example: I am mostly using Emacs as text editor. I do know that
> when I type the character "ä" or "§" when entering text, exactly this
> character will appear in the file in the encoding I choose when saving the
> file. I have no idea how this character is stored internally while emacs
> is underway. And that's absolutely fine with me. Why should perl not do
> likewise?
Because Perl is a programming language and not a text editor and
depending on the kind of program, different strategies for UTF-8
decoding might make sense. A nice discussion of this is available in
the 'Converting the tools' section of this paper:
http://plan9.bell-labs.com/sys/doc/utf.html
------------------------------
Date: Thu, 16 May 2013 13:08:09 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: Why do Perl programmers make more money than Python programmers
Message-Id: <8017d8a5-1db3-40b2-b97b-18ceaacbc8f7@googlegroups.com>
I say simply end all welfare and let unregulated free market make everyoine rich by mas production of commodofied cheap big concrete hsoues adn atomic pwoer and private owned trains union free endign all pensions and lal public school.
------------------------------
Date: Thu, 16 May 2013 13:09:35 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: Why do Perl programmers make more money than Python programmers
Message-Id: <d8b2a5b6-768a-401b-995a-1ce5dd5c106e@googlegroups.com>
better question: which god?
poseidon?
hastur?
godogma?
tak?
pazuzu?
lord arykyn?
khorne?
set?
------------------------------
Date: Thu, 16 May 2013 13:11:00 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: Why do Perl programmers make more money than Python programmers
Message-Id: <3b5da7c4-24d7-4ac4-afd1-4256b7d2cbd7@googlegroups.com>
perl programmers are older and tend to have experience and know c n shit
this is the end arguement
also perl programmers get that object progrmaming is bullshit
procedural is all u need
data structures not algorithms are central to prgraming!!
YEAH!!
all we need isa non oo www.prevayler.org ram databse with update logging and perl can get back in front of java!!
------------------------------
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 3950
***************************************
