[29777] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 1020 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 9 21:09:39 2007

Date: Fri, 9 Nov 2007 18:09:07 -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           Fri, 9 Nov 2007     Volume: 11 Number: 1020

Today's topics:
        $5 reward for this Perl script (regular expression sear <lucavilla@cashette.com>
    Re: $5 reward for this Perl script (regular expression  <1usa@llenroc.ude.invalid>
    Re: $5 reward for this Perl script (regular expression   usenet@DavidFilmer.com
        Announcing Net::Digg - Perl interface to the Digg API <Kwilms@gmail.com>
    Re: File handling and regex <lucavilla@cashette.com>
    Re: File handling and regex <tadmc@seesig.invalid>
    Re: File handling and regex <lucavilla@cashette.com>
    Re: Net::Server + IPC::Shareable == decent performance  xhoster@gmail.com
    Re: Perl + LAMP / PHP JOB <dha@panix.com>
        POE::Component::IRC::State and nick changes <kmw@armory.com>
    Re: thread <dontmewithme@got.it>
    Re: Why can't you slice an array @a[3..-1]? <bik.mido@tiscalinet.it>
    Re: Why can't you slice an array @a[3..-1]? <bik.mido@tiscalinet.it>
    Re: Why can't you slice an array @a[3..-1]? <clint.olsen@gmail.com>
    Re: Why can't you slice an array @a[3..-1]? <tzz@lifelogs.com>
    Re: Why can't you slice an array @a[3..-1]? <tzz@lifelogs.com>
        zipping large file using Archive::Zip <md0710@gmail.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 09 Nov 2007 17:14:53 -0800
From:  Luca Villa <lucavilla@cashette.com>
Subject: $5 reward for this Perl script (regular expression searches through an entire directory of files)
Message-Id: <1194657293.592532.320230@v3g2000hsg.googlegroups.com>

*** I offer $5 via Paypal for the first working complete Perl script
***


I have thousands of files named like these:

c:\input\pumico-home.html
c:\input\ofofo-home.html
c:\input\cimaba-office.html
c:\input\plata-home.html
c:\input\plata-office.html
c:\input\zito-home.html

I need a Perl script that passes through both the categories of these
files (*-home.html and *-office.html) searching for some regular
expressions:

for *-home.html:
 regexAone:   abc\d+def
 regexAtwo:   lmn\d+ofg
 regexAthree: pqr\d+stu

for *-office.html:
 regexBone:   artemis\d+lock
 regexBtwo:   pretamus\d+balim

It must output each regular expression match result to a txt file with
the same name as the input html file plus a suffix corresponding to
the name of the processed regular expression like above defined,
producing an output scenery like this:

c:\output\pumico-home-regexAone.txt
c:\output\pumico-home-regexAtwo.txt
c:\output\pumico-home-regexAthree.txt
c:\output\ofofo-home-regexAone.txt
c:\output\ofofo-home-regexAtwo.txt
c:\output\ofofo-home-regexAthree.txt
c:\output\cimaba-office-regexBone.txt
c:\output\cimaba-office-regexBtwo.txt
c:\output\plata-home-regexAone.txt
c:\output\plata-home-regexAtwo.txt
c:\output\plata-home-regexAthree.txt
c:\output\plata-office-regexBone.txt
c:\output\plata-office-regexBtwo.txt
c:\output\zito-home-regexAone.txt
c:\output\zito-home-regexAtwo.txt
c:\output\zito-home-regexAthree.txt

__________________

For example, supposing that the c:\input\cimaba-office.html file
contains the following 5 lines:
dfgdfsgdf
setertert
artemis123456lock
garumbzeta
pretamus9999balim
popolissss

c:\output\cimaba-office-regexBone.txt will be generated containing:
artemis123456lock

c:\output\cimaba-office-regexBtwo.txt will be generated containing:
pretamus9999balim


Thanks in advance



------------------------------

Date: Sat, 10 Nov 2007 01:32:04 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: $5 reward for this Perl script (regular expression searches through an entire directory of files)
Message-Id: <Xns99E3D0E06CDBBasu1cornelledu@127.0.0.1>

Luca Villa <lucavilla@cashette.com> wrote in news:1194657293.592532.320230
@v3g2000hsg.googlegroups.com:

> *** I offer $5 via Paypal for the first working complete Perl script
> ***

It is much more satisfying to say:

*PLONK*

Sinan

-- 
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.augustmail.com/~tadmc/clpmisc.shtml>



------------------------------

Date: Sat, 10 Nov 2007 02:01:18 -0000
From:  usenet@DavidFilmer.com
Subject: Re: $5 reward for this Perl script (regular expression searches through an entire directory of files)
Message-Id: <1194660078.821221.63240@e34g2000pro.googlegroups.com>

On Nov 9, 5:14 pm, Luca Villa <lucavi...@cashette.com> wrote:
> *** I offer $5 via Paypal for the first working complete Perl script

Make it a $25 contribution to The Perl Foundation (via PayPal to
billing@yapc.org), and send the submitter a copy of the receipt, and
you might get more interest.  I might write it.


--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)



------------------------------

Date: Fri, 9 Nov 2007 21:26:20 GMT
From: kwilms <Kwilms@gmail.com>
Subject: Announcing Net::Digg - Perl interface to the Digg API
Message-Id: <Jr9G75.17BK@zorch.sf-bay.org>

Digg.com is a place for people to discover and share content from
anywhere on the web - go have a look if you're interested, then read
on - or read on if you're impatient.

Net::Digg provides a nice way of accessing the Digg API. It aims to
provide an easy to use middle layer, so you can easily access all the
data that Digg holds and use it in a perl script.

<http://search.cpan.org/~kwilms/Net-Digg-0.1/>

--
Kurt




------------------------------

Date: Fri, 09 Nov 2007 15:31:47 -0800
From:  Luca Villa <lucavilla@cashette.com>
Subject: Re: File handling and regex
Message-Id: <1194651107.497622.27520@v3g2000hsg.googlegroups.com>

Thanks to all and to John in particular.

John's solution perhaps worked but I had difficulty in adapting it for
my needs so I ended using this alternative solution:


use File::Find;

find(\&found, 'c:/dir');


sub found {
      unless(open(IN,"<$File::Find::name")) {
            warn "Could not open $File::Find::name: $! (SKIPPING)\n";
            return;
      }
      local $/;
      my $data=<IN>;
      close(IN);

      my($type, $number);
      if($data =~ /abc([0-9]+)def/) {
            $number=$1;
            $type=1;
      }
      elsif($data =~ /lmn([0-9]+)opq/) {
            $number=$1;
            $type=2;
      }
      elsif($data =~ /rst([0-9]+)uvw/) {
            $number=$1;
            $type=3;
      }
      else {
            warn "File $File::Find::name is unknown type\n";
            return;
      }

      my $outfn="c:/output/$number-type$type.txt";
      if(-e $outfn) {
            warn "File $outfn already exists.\n";
            return;
      }
      unless(open(OUT,">$outfn")) {
            warn "Could not open $outfn: $!\n";
            return;
      }
      print OUT $data;
      close(OUT);
}



------------------------------

Date: Sat, 10 Nov 2007 00:39:18 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: File handling and regex
Message-Id: <slrnfj9uk5.fh4.tadmc@tadmc30.sbcglobal.net>

Luca Villa <lucavilla@cashette.com> wrote:


>       unless(open(IN,"<$File::Find::name")) {
>             warn "Could not open $File::Find::name: $! (SKIPPING)\n";
>             return;
>       }
>       local $/;
>       my $data=<IN>;
>       close(IN);


If you are going to mess with the special variables anyway,
then you could replace all of that with:

   local @ARGV = $_;
   local $/;
   my $data = <>;


-- 
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"


------------------------------

Date: Fri, 09 Nov 2007 17:13:22 -0800
From:  Luca Villa <lucavilla@cashette.com>
Subject: Re: File handling and regex
Message-Id: <1194657202.562017.210850@k79g2000hse.googlegroups.com>

> If you are going to mess with the special variables anyway,
> then you could replace all of that with:
>
>    local @ARGV = $_;
>    local $/;
>    my $data = <>;

I received this error:
"Can't do inplace edit: . is not a regular file at c:\script.src line
12."

inplace edit? What does it want to do?



------------------------------

Date: 09 Nov 2007 20:27:36 GMT
From: xhoster@gmail.com
Subject: Re: Net::Server + IPC::Shareable == decent performance ?
Message-Id: <20071109152739.136$qH@newsreader.com>

David Jacobowitz <david.jacobowitz@gmail.com> wrote:
> Hello, this is a question for all the perl people out there who have
> written internet servers.
>
> I'm currently have a perl-based server that acts as a hub for a simple
> message passing scheme. Clients periodically connect, send a message
> to a user (the server puts the message in an in-memory queue for the
> recipient, and check for their own messages, with the server splatting
> back out the clients message queue and then deleting it.
>
> Each transaction is small and short, and I have everything working
> pretty well with a single instance server of Net::Server. And I'm not
> doing anything funky with select(); I'm just answering and completing
> each transaction in order. This seems to make sense to me, because
> there is really not much work per transaction over and above reading
> and writing data to the socket.
>
> The thing is, I want this server to be able to take hundreds or maybe
> thousands of connections per second.

Do you have simple model code the does just the guts of what you have
described with all auxiliary stuff stripped out?  If you do, please post it
so we can see exactly what you are doing, and try it out for ourselves.  If
not, you should probably make one.

> This will never work with a
> single process (I don't think. My laptop seems to saturate around 600
> xactions/sec, but then the laptop is also running the client processes
> as well)

Is each "transaction" a single TCP connect-send-receive-disconnect
sequence?

At about 600 TCP connections per second on IO::Socket::INET on one of my
machines, the client starts getting refusals with "Cannot assign requested
address".  This seems like a kernel thing, not a Perl thing.

> With Net::Server, turning a server into a pre-forked server is pretty
> easy. But then each process is independent from that point forward,
> and so obviously message queues won't be shared between them. So, I'm
> thinking of using IPC::Shared.
>
> But, with all the overhead of IPC will this be any faster than the
> single process?

I suspect it will be slower.

> Is there an easy way to see where the cycles are
> going?

I'd start (on linux) by running the OS "time" on the server and client
and see how much time is spent in system space rather than user space.
Then just change the server so it throws away the client's message and
just sends back a hard-coded dummy message, rather than doing any real
message-queue work.  If that makes it run faster, then the message queue
is taking a lot of time.  If it doesn't, then it doesn't.

> If most of the cycles are going to data-structure maintenance,
> then I don't see a point in doing this work. If most of them are going
> to handling socket stuff, then it would be a win, assuming it works.

I'm not sure of that.  A lot of the "handling socket stuff" goes on in the
kernel, and I suspect much of it is serialized at that point, even if the
user-level processes think it is happening in parallel.

> As an aside, my application does not require that any user be able to
> leave a message for any other user, so it would be okay to segment the
> message queues into groups.

What is a "user" as distinct from a "client"?

> But for this to work, I'd need a way to
> make sure that each client connection matches up with the same server
> process on sequential accesses.

The easiest way is not to close the connection in the first place.  Keep
using the same one.

> I could do this, of course, by putting
> another server in front of the other servers whose only job in life is
> to track which back-end server the client first connected with and
> then keep sending the client to the same back-end server on subsequent
> connections. But in this case, I'm just creating more or less the same
> bottleneck again.

I think there is a piece missing here.  If the client is long-lived, then
it shouldn't need to told again and again which server it should use--it
should only ask once and then remember which server to use from then on
(or better yet, remember not only the server, but also the connection to
that server.)

On the other hand, if the client is short-lived, then on what basis can it
be considered the "same" as some previous incarnation of itself, in order
for the intermediate server to know what server to route it to?

Whatever it is that defines sameness, perhaps you could compute hash value
on that and use that to compute which server to connect to, omitting the
intermediate server altogether.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.


------------------------------

Date: Fri, 9 Nov 2007 23:51:24 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Perl + LAMP / PHP JOB
Message-Id: <slrnfj9sjs.4c4.dha@panix2.panix.com>

On 2007-11-08, jon.kay@mayfieldcurzon.com <jon.kay@mayfieldcurzon.com> wrote:
> I am a Manchester UK based recruiter.  

You have posted a job posting or a resume in a technical group.

Longstanding Usenet tradition dictates that such postings go into
groups with names that contain "jobs", like "misc.jobs.offered", not
technical discussion groups like the ones to which you posted.

Had you read and understood the Usenet user manual posted frequently to
"news.announce.newusers", you might have already known this. :)  (If
n.a.n is quieter than it should be, the relevent FAQs are available at
http://www.faqs.org/faqs/by-newsgroup/news/news.announce.newusers.html)
Another good source of information on how Usenet functions is
news.newusers.questions (information from which is also available at
http://www.geocities.com/nnqweb/).

Please do not explain your posting by saying "but I saw other job
postings here".  Just because one person jumps off a bridge, doesn't
mean everyone does.  Those postings are also in error, and I've
probably already notified them as well.

If you have questions about this policy, take it up with the news
administrators in the newsgroup news.admin.misc.

http://jobs.perl.org may be of more use to you

Yours for a better usenet,

dha

-- 
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
Looking at the cake is like looking at the future.  Until you taste
it, what do you really know?  And, of course, by then, it's much too
late.    - Merlin, Excalibur


------------------------------

Date: Fri, 09 Nov 2007 17:27:30 -0600
From: "Kurt M. Weber" <kmw@armory.com>
Subject: POE::Component::IRC::State and nick changes
Message-Id: <13j9r78cvn6f6de@corp.supernews.com>

Using POE::Component::IRC::State, I'm trying to access channels in which my
Perl program sees a user has changed his nick.  This is the relevant
subroutine:

sub onnick{
        my ($who,$newnick,$where) = @_[ARG0,ARG1,ARG2];
        my ($nick, $host) = split /!/, $who;
        my $channel = $where->[0];

        my $logline = "---     " . $nick . " is now known as " . $target;

        &writeline($ircserver, $channel, $logline);
}

Now, the documentation indicates that ARG2 will contain an arrayref of all
the channels on which the client saw the user change his nickname.  Now,
for simplicity's sake, I'm just worried about the first one, which should
be in $where->[0].

However, it's not there.

Using Data::Dumper, I discover that ARG2 (and therefore $where) is an
arrayref, but it's empty.

Any clue what I'm missing?  And yes, I am using
POE::Component::IRC::State->spawn rather than just
POE::Component::IRC->spawn.
-- 
Kurt M. Weber
<kmw@armory.com>


------------------------------

Date: Sat, 10 Nov 2007 00:18:58 +0100
From: Larry <dontmewithme@got.it>
Subject: Re: thread
Message-Id: <dontmewithme-71DC1E.00185810112007@news.tin.it>

In article <20071109130443.976$QL@newsreader.com>, xhoster@gmail.com 
wrote:

> I don't know if it can be done, but if you only want to have one thread
> running at a time (well, two, one that is doing stuff and one that is
> killing off the one that is doing stuff), why use threads in the first
> place?

I cannot wait for others threads to finish ... anyway ... I need to get 
control of <STDIN> ...


------------------------------

Date: Fri, 09 Nov 2007 21:16:05 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Why can't you slice an array @a[3..-1]?
Message-Id: <lee9j3lrk66k48omq39f9hainn2ndc8sbc@4ax.com>

On Fri, 9 Nov 2007 18:29:39 +0000 (UTC), Ilya Zakharevich
<nospam-abuse@ilyaz.org> wrote:

>IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
>least, as a pragma), not increasing it.  (Currently, the probability
>of an experienced Perl programmer to predict a result of running
>*simple* Perl code is close to 0 - unless one severely binds oneself
>via coding style discipline.  Too many un-/half-documented special
>cases...)

Well there are two conflicting POVs that should be balanced:

(i) a vector space is a relatively simple algebraic structure. A
programming language with (largely) orthogonal features is nice in
that it makes for the principle of least surprise;

(ii) a manifold (e.g.) is admittedly a richer structure than a vector
space. Perl often deviates from orthogonality for the sake of
dwimmeries. Dwimmeries often have to do with psychological perception
and linguistic issues which in turn often deviate from linearity.

As Perl is now is mostly satisfactory, and indeed I would dread upon
ranges behaving as suggested within subscripts.

The big challenge of Perl 6 is to achieve a high degree of dwimmery
while staying at the same time consistent and orthogonal. It aims, in
other words, at bringing dwimmery into the basic "vector space
structure". Well, sort of.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Fri, 09 Nov 2007 21:17:54 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Why can't you slice an array @a[3..-1]?
Message-Id: <l0g9j3pmnnln9f3k1t2ai9dbtm89feb6u1@4ax.com>

On Fri, 09 Nov 2007 12:40:16 -0600, Clint Olsen
<clint.olsen@gmail.com> wrote:

>> As far as I know, there is no DWIM involved.  There are two operators,
>> both fully-and-simply defined; array offset (which is defined for
>> -$#-1..$#), and range.  You REALLY want the result of an operator be
>> dependent on argument of which operator it is?
>
>In the spirit of Perl and evaluations based on usage context, I don't see
>this as a farfetched thing.  Hey, Perl invented the concept of context, not
>me :)

"Subscript context"? No, kinda too much for me... Even worse,
subscripting strongly reminds me of mathematical usage. A range of
3..-1 returning 3..$#array reminds me of a mathematical nightmare.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Fri, 09 Nov 2007 17:02:12 -0600
From: Clint Olsen <clint.olsen@gmail.com>
Subject: Re: Why can't you slice an array @a[3..-1]?
Message-Id: <slrnfj9pnk.1tf8.clint.olsen@belle.0lsen.net>

On 2007-11-09, Michele Dondi <bik.mido@tiscalinet.it> wrote:
> "Subscript context"? No, kinda too much for me... Even worse,
> subscripting strongly reminds me of mathematical usage. A range of 3..-1
> returning 3..$#array reminds me of a mathematical nightmare.

Well, I was thinking more '..' in an array/list context, but yeah.

-Clint


------------------------------

Date: Fri, 09 Nov 2007 17:09:38 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Why can't you slice an array @a[3..-1]?
Message-Id: <m21wazow25.fsf@lifelogs.com>

On Fri, 09 Nov 2007 21:17:54 +0100 Michele Dondi <bik.mido@tiscalinet.it> wrote: 

MD> "Subscript context"? No, kinda too much for me... Even worse,
MD> subscripting strongly reminds me of mathematical usage. A range of
MD> 3..-1 returning 3..$#array reminds me of a mathematical nightmare.

Well, actually I would argue vehemently that the above should return 3,
2, 1, 0, -1 in regular context.  I think Perl, normally a clever
language, is not clever on this.  Ask any child what 3..-1 should
generate as a sequence, and they won't say "empty list."

If 3..-1 returned a downward range, it would be trivial to look at the
array slice offsets, check if the last number is negative, and do the
right thing for that case.  But instead, we get the empty list because
 .. only counts *up* and that causes the subsequent problems.  But I
realize changing .. is a completely impossible thing, and at least half
the Perl coders will disagree with me, so I'm only suggesting a
subscript context DWIMmery.  That's slightly less anathema I think.

Ted


------------------------------

Date: Fri, 09 Nov 2007 17:13:08 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Why can't you slice an array @a[3..-1]?
Message-Id: <m2wssrnhbv.fsf@lifelogs.com>

On Fri, 9 Nov 2007 18:29:39 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote: 

IZ> [A complimentary Cc of this posting was sent to
IZ> Ted Zlatanov 
IZ> <tzz@lifelogs.com>], who wrote in article <m2640bqv22.fsf@lifelogs.com>:
IZ> Me too.  3..-1 INAMBIGUOUSLY returns an empty list.
>> 
>> Well obviously in a general context, but Perl semantics for array
>> offsets also specifically know about negative numbers, so this is a
>> conflict between two DWIM modes (and I think the array offset DWIM mode
>> should win).

IZ> As far as I know, there is no DWIM involved.  There are two operators,
IZ> both fully-and-simply defined; array offset (which is defined for
IZ> -$#-1..$#), and range.  You REALLY want the result of an operator be
IZ> dependent on argument of which operator it is?

Yes, I think I do.  I could be wrong in wanting it, but it feels right.
It's like a chocolate donut, only much more abstract :)

IZ> IMO, Perl evolution should go in DECREASING number of DWIM stuff (at
IZ> least, as a pragma), not increasing it.  (Currently, the probability
IZ> of an experienced Perl programmer to predict a result of running
IZ> *simple* Perl code is close to 0 - unless one severely binds oneself
IZ> via coding style discipline.  Too many un-/half-documented special
IZ> cases...)

I agree.  And yet, I'm tempted by chocolate.

>> I actually did this just the other day (using $#array as
>> the last offset) and thought "hmm, wouldn't it be nice to use -1" so
>> Clint's question makes sense.

IZ> I do it myself often too.  It does not make it a lesser evil.

No, but it does tell you something about how people think.  Intuition
often contradicts logic and consistency.

Ted


------------------------------

Date: Fri, 09 Nov 2007 11:55:10 -0800
From:  Mark <md0710@gmail.com>
Subject: zipping large file using Archive::Zip
Message-Id: <1194638110.646390.208800@50g2000hsm.googlegroups.com>

I have a 16 GB file that I zipped using perl's Archive::zip module.
When I try to unzip this file using WinZip, it shows the "uncompressed
size" = 4294967295.

Upon trying to extract this file via WinZip, the winzip program
deflates the file correctly to 16 GB, but then before it completes and
yields control to the user,  WinZip does a file size check between
actual decompressed size and the file information (uncompressed size)
stored with the Zip, and, since those don't match, it automatically it
considers the decompressed file as invalid and removes it from the
disk.

This root cause of this problem is due to perl's ZLIB module writing
an incorrect header information on the zip file

Can someone please tell me why Perl's Archive::zip module writes
incorrect information in the zip file header ? Are there any settings
that can override such behaviour?

Thanks



------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 1020
***************************************


home help back first fref pref prev next nref lref last post