[24142] in Perl-Users-Digest
Perl-Users Digest, Issue: 6336 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 30 00:15:32 2004
Date: Mon, 29 Mar 2004 21:15: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 Mon, 29 Mar 2004 Volume: 10 Number: 6336
Today's topics:
Re: cpu use in threads <angshu31@hotmail.com>
Re: data types <jwkenne@attglobal.net>
exit status of first program in pipe (Palaniappan)
Re: how to capture multiple lines? <geoffacox@dontspamblueyonder.co.uk>
Re: Lost data on socket - Can we start over politely? (Vorxion)
Re: LWP cookies <rbell01824@earthlink.net>
Re: Performance issues with LWP? (off-topic?) <mahesha-at-mahesha-dot-net>
Re: Performance issues with LWP? (off-topic?) (Myron Turner)
Re: Perl Serial io on linux <wherrera@lynxview.com>
Re: Perl Serial io on linux <jhsterling@earthlink.net>
Perl-5.8.2 NDBM_File appears to insert POD into DB file <leftfoot@siu.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Mar 2004 19:13:22 -0500
From: "Angshuman Guin" <angshu31@hotmail.com>
Subject: Re: cpu use in threads
Message-Id: <c4ae3e$i39$1@news-int2.gatech.edu>
Yes I think you are right. The CPU was still showing nearly 99.9% usage.
However the cpu time was jumping at double the pace of the refresh rate. I
think it was really using two CPUs. I'll increase the threads and see if the
thing scales up.
Thanks!
"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:c49p87$8e3$1@canopus.cc.umanitoba.ca...
> In article <c45vcg$4js$1@nets3.rz.RWTH-Aachen.DE>,
> Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote:
> :I am not an expert for Perl's threading capabilities. However, the POSIX
> :thread library it uses (where available) isn't quite yet ready for SMP
> :and wont distribute the threads over the processors (AFAIK).
>
> I haven't looked at the standards in this regards, but on at least
> one variety of "real" SMP (SGI Challenge XL), what happens is that
> each of the threads may run on a different CPU but the time is
> added into a single accounting structure -- resulting in oddities
> like having a single process that is taking 700% of a CPU.
> --
> Warning: potentially contains traces of nuts.
------------------------------
Date: Tue, 30 Mar 2004 04:46:46 GMT
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: data types
Message-Id: <WY6ac.153082$LX.19415962@news4.srv.hcvlny.cv.net>
Anno Siegel wrote:
> <anuradha.k.r@sify.com> wrote in comp.lang.perl.misc:
>
> [please don't top-post]
>
>
>>Hi,
>>Well let me be little more clear.The format of the file which I am
>>readiing is what I am actually looking for.In pl/1 irrespective of
>>what the data format is ie say integer/character/bits when read into a
>>bit(16) say
>>READ FILE INTO(X) where X is X(128) BIT(16),X will always give a
>>binary value ie the character/integer represented as 16 bit values.So
>>you need not know whether the data in file is fixed binary or varying
>>binary.However when I am porting this to perl ,I need to worry about
>>the exact data format in the file.
>>Thatz the reason why I asked that it would be necessary that my data
>>in file is in directly binary format(made of 1s and 0s) let it be
>>representing a character or a decimal value?
>>In my pl/1 program I am manipulating the bitstrings only to compute
>>some values.
>>Only if I am sure of the data format in the file in perl can I go for
>>options to manipulate them in my program,and see whether I need
>>pack/unpack etc.
>>I hope now its more clear?
>
>
> Not really.
>
> I guess what you're saying is:
>
> I have this file, and this is how I read it in PL/1. How can I read
> it in Perl, or, if I can't, how should I re-format it so that I can.
>
> The problem is that you have described your problem in terms of PL/1
> which few people here speak fluently. Neither the specification
> "...where X is X(128) BIT(16)", nor the terms "fixed binary" and
> "varying binary" have specific meaning outside PL/1 terminology.
As it happens, I haven't had to use pack and unpack much, but:
DECLARE X(128) BIT(16); /* In PL/I */
would be:
unsigned short x[128]; /* In C, assuming "short" is 16 bits */
-- more or less.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
------------------------------
Date: 29 Mar 2004 20:41:01 -0800
From: palam_analog@yahoo.co.in (Palaniappan)
Subject: exit status of first program in pipe
Message-Id: <a7b604a1.0403292041.719e9f3b@posting.google.com>
Hi all,
consider the following code
-----
$exit_status = system( "program1 | program2" );
-----
can anyone explain, what exit_status system() will return?
is it from program1 or program2 ?
or is it depends on whether piping is done successfully or not ?
how to get program1 exit status alone ?
(without using temporary files to dump the intermediate output).
-palam
------------------------------
Date: Tue, 30 Mar 2004 00:22:51 GMT
From: Geoff Cox <geoffacox@dontspamblueyonder.co.uk>
Subject: Re: how to capture multiple lines?
Message-Id: <freh60tlq4t87ovs1sibh9414cit7k3a9m@4ax.com>
On Mon, 29 Mar 2004 11:27:56 -0600, Tad McClellan
<tadmc@augustmail.com> wrote:
Tad,
>> I know it has little elegance
>
>It is downright horrid style.
I know. but it is all working except for the reading of the <p> ..
</p>
>> Perhaps you can see
>> why the $/ is not working correctly?
>Because you set it *after* you have already read from the file.
>
>It affects input, you much change it before you do the input
>that you want to affect.
Have only now realised what you mean by this. had missed the point re
the sub data coming from an earlier event, ie the reading in of the
file. This makes me think that using the $/ change just will not work
as I only wish to apply it to the text between <p> and </p> on
different lines. Changing the $/ for the whole file will break the
rest of the code...so is it back to sluping in the whole file? I do
not see how this can deal with the parts of the file in the order in
which they appear in the file? The HTML::Parser is perhaps the best
way but that will take me a little while to get to grips with!
>
>> use File::Find;
>> my $dir = 'd:/a-keep9/prog-nondb/old-prog';
>>
>> find sub {
>> my $name = $_;
>There is no need to copy it from one scalar to another.
OK.
>> if ($name =~ /.htm/) {
>That will match if $name = 'nightmare'.
>
>Is that what you want?
>
>Probably not, so:
>
> if ( /\.htm$/ ) {
OK
>
>
>> open (IN, "$name");
>Lose the useless use of quotes.
OK
>You should always, yes *always*, check the return value from open():
>
> open IN, $_ or die "could not open '$_' $!";
>or
> open IN, $name or die "could not open '$name' $!";
> hanging it there will not affect the contents of $line.
OK.
>> print OUT ("<\/table>\n<\/body>\n<\/html>");
>
>Slashes are not special in strings, no backslashing needed.
>
> print OUT ("</table>\n</body>\n</html>");
OK
>
>
>
>> sub choice {
>> my ($path) = @_;
>> if ($path =~/btec-first/) {
>> &intro($path);
>> &applefirst($path);
>> } elsif ($path =~ /classroom-notes/) {
>> &intro($path);
>> &clasroomnotes($path);
>> }elsif ($path =~/pears\/assignments/) {
>> &intro($path);
>> &pearsassignments($path);
>> } else {
>> &intro($path);
>> &other($path);
>> }
>> }
>
>
>You call intro($path) for every alternative!
>
>You should just call it once at the top of the sub instead.
OK
Thanks for your suggestions.
Geoff
>
> http://web.presby.edu/~nnqadmin/nnq/nquote.html
------------------------------
Date: 29 Mar 2004 23:00:21 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: Lost data on socket - Can we start over politely?
Message-Id: <4068f0d5_1@news.iglou.com>
In article <c4a82k$1p1$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>Also sprach Vorxion:
>
>> In article <c49ous$hif$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>>>Also sprach Vorxion:
>
>>>If I am not completely mistaken, perl internally uses recvfrom(2) when
>>>reading from a socket. AFAIK, a socket's send and receive buffer is each
>>>around 64kB. You try to read significantly more than that. What happens
>>>when you read in smaller chunks?
>>
>> Same results. It drops out in the 1150-2200 line range and tosses the
>> rest of the data. Actually, since I'm not storing it anywhere in this, I
>> couldn't even tell you if those are 100% contiguous lines from start to
>> middle, or if it's dropping out intermittantly as well.
>>
>> I tried 1024, 8192, 16384, and 65536, all with the same net effect.
>
>In this case I'd see whether there is any read() that returns undef.
>Check $! in this case.
read() or sysread()? You did have me switch back, remember?
>Here is what 'perldoc -f select' says:
>
> WARNING: One should not attempt to mix buffered I/O (like "read" or
> <FH>) with "select", except as permitted by POSIX, and even then
> only on POSIX systems. You have to use "sysread" instead.
Yeah, which I discovered after posting the first reply, and since posted
that I'd seen. This is apparently why I was using sysread() in the first
place.
>You have to keep in mind that Perl's read() is _not_ read(2). The naming
>is a bit misleading there. A true read(2) is done through sysread(). So
>use this and suspiciously watch its return value for undefs.
No undefs are issued. Just checked with sysread(). Always returns a
defined value. Usually 8192, the sysread value. However, at one point it
returned 5344, then another 8192, and then another whopping 43 bytes.
On this system, it seems to like to die out almost precisely at 70923
bytes. I have seen it go up to 96000+, but that's been a rarity.
Is this providing any more insight?
>Maybe we are also talking about different buffers here. When talking
>about buffering and Perl, one usually means the buffer you have when
>using C's FILE and fread/fwrite etc. That's a high-level buffer used to
>increase the performance. A socket's buffer however is something else.
>When you receive network data, this data has to be stored somewhere
>before it even reaches user-space programs. The maximum size of a TCP
>packet is 64kB so there are facilities to store at least that much on
>the lower levels of the ISO/OSI layers. These buffers have nothing to do
>with the buffer in a FILE structure. When using select, you are working
>with file-descriptors, and those don't have buffers in Perl's meaning
>of the word.
Well apparently I'm talking about socket-level buffering not working then?
Because the rest of the data just plain goes AWOL. It vanishes. The
program will accept new input, it just loses the last 2/3 of the stream it
was just fed at any given time.
God, any clues at all as to how to keep this from happening would help. My
book should be here tomorrow morning, thankfully. Maybe that will have
some insight for me. Not that you didn't just clarify things a bit. I
wasn't aware that we were talking about two different buffering layers, for
instance.
I just find it incredulous that the data would simply disappear in
mid-stream. If that were the case, how would something like ftp work?
Obviously it doesn't die off after 70K of data. :)
So far, I've stripped out -all- my protocol stuff and am simply reading
based on newline-terminated lines, which is a lot less to consider. Once I
get this working right, THEN I can toss the other stuff back into the mix.
Thanks for your help so far!
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: Mon, 29 Mar 2004 23:33:28 GMT
From: Richard Bell <rbell01824@earthlink.net>
Subject: Re: LWP cookies
Message-Id: <2vbh605hefcab23s9d810k8055sjrobb9m@4ax.com>
On Mon, 29 Mar 2004 17:34:27 GMT, peter@PSDT.com (Peter Scott) wrote:
>In article <8AW9c.42530$QO2.39890@pd7tw1no>, I wrote:
>>In fairness to the OP he probably meant JavaScript - that has caused
>>me problems on mechanizing some sites and I can easily imagine it
>>being too difficult to figure out what it's doing. Until we get a JS
>>engine for Perl there's no way to avoid manual inspection.
>
>Hmm, no sooner do I say that than this shows up:
>
>===================
>http://search.cpan.org/~abeltje/Win32-IE-Mechanize-0.004/
>
>This module is mostly a port of the very popular WWW::Mechanize
>module but uses InternetExplorer as the user-agent. This makes it
>possible to also test JavaScript dependant webpages.
>===================
>
>Haven't tried it, don't have enough time + inclination, and it's brand new
>(first version posted within last 24 hours). Still, interesting...
And no sooner than I note ...
Interestingly, I've done a fair bit of work with automation of IE in a
separate XP process. As an engine, there is much to recommend it.
Unfortunately, there are also some very nasty bits (as in, for
example, when is a page really truly loaded - seems like it ought to
be a simple enough question but turns out to be much trickier than
most think). I'm also fairly sure IE leaks memory (I've a process
running for 33 days driving IE at about a 50% traffic rate that needs
periodic rebooting or the system dies - it might also be .net
leaking). Access to the DOM is also a bit contorted in my view.
Wouldn't it be nice if there was a Mozilla based version for Linux!
R
------------------------------
Date: Mon, 29 Mar 2004 15:48:29 -0800
From: Mahesha <mahesha-at-mahesha-dot-net>
Subject: Re: Performance issues with LWP? (off-topic?)
Message-Id: <106hdeepge8ned8@corp.supernews.com>
Prabh wrote:
> Hello all,
> In my task I need to check if the web server at a known URL is up and
> available. If its not, I need to send a mail to the system admins that
> the server is down and if its available then get the URL's contents.
> The simplest way I could think of doing this was with LWP.
>
>
> use LWP::Simple ;
> my $chkUrl = get("http://abc.xyz.com");
> if ( ! $chkUrl )
> {
> &mail_the_Admins_the_server_is_down() ;
> die "Cant connect: Check the URL or the Server is down\n" ;
------------------------^^^^^^^^^^^^^
In this example, the URL is hard-coded. I am assuming it is a valid URL
in the actual application, in which case 'Check the URL' will not apply.
If, however, the URL comes as an argument from a user, admins will get
an email every time a user mis-types the URL. That could be an annoyance
to the admins. No?
--
M
------------------------------
Date: Tue, 30 Mar 2004 01:00:08 GMT
From: turnermm@shaw.ca (Myron Turner)
Subject: Re: Performance issues with LWP? (off-topic?)
Message-Id: <4068c054.2236775252@news.wp.shawcable.net>
On Mon, 29 Mar 2004 15:48:29 -0800, Mahesha
<mahesha-at-mahesha-dot-net> wrote:
>Prabh wrote:
>
>> Hello all,
>> In my task I need to check if the web server at a known URL is up and
>> available. If its not, I need to send a mail to the system admins that
>> the server is down and if its available then get the URL's contents.
>> The simplest way I could think of doing this was with LWP.
>>
>>
>> use LWP::Simple ;
>> my $chkUrl = get("http://abc.xyz.com");
>> if ( ! $chkUrl )
>> {
>> &mail_the_Admins_the_server_is_down() ;
>> die "Cant connect: Check the URL or the Server is down\n" ;
>------------------------^^^^^^^^^^^^^
>
>In this example, the URL is hard-coded. I am assuming it is a valid URL
>in the actual application, in which case 'Check the URL' will not apply.
>
>If, however, the URL comes as an argument from a user, admins will get
>an email every time a user mis-types the URL. That could be an annoyance
>to the admins. No?
>--
>M
You'' have to use LWP::UserAgent and HTTP::Response, where you can
check the response message and response code. It's not as complicated
as it first appears. There's a simple example in the Synopsis to
LWP::UserAgent that works fine.
Try this:
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->timeout(10);
my $response = $ua->get('http://bad.url.org/');
if ($response->is_success) {
print $response->content; # or whatever
}
else {
die $response->status_line;
}
The error message will read:
500 Can't connect to bad.url.org:80 (Bad hostname 'bad.url.org') at
script.pl line n.
Myron Turner
www.room535.org
------------------------------
Date: Mon, 29 Mar 2004 18:32:10 -0700
From: Bill <wherrera@lynxview.com>
Subject: Re: Perl Serial io on linux
Message-Id: <zMmdnUFEpvqHU_Xd4p2dnA@adelphia.com>
T.Paakki wrote:
> So far, expect is not an option. I'm not sure why.
There is an Expect.pm module for Perl that works with serial ports. Too
bad if it won't compile on Zaurus.
------------------------------
Date: Tue, 30 Mar 2004 02:11:42 GMT
From: John Sterling <jhsterling@earthlink.net>
Subject: Re: Perl Serial io on linux
Message-Id: <yH4ac.7689$lt2.5721@newsread1.news.pas.earthlink.net>
Bill wrote:
> T.Paakki wrote:
>
>> So far, expect is not an option. I'm not sure why.
>
>
> There is an Expect.pm module for Perl that works with serial ports. Too
> bad if it won't compile on Zaurus.
>
You don't really need Expect.pm to do this. One of the techs at work
asked me how to drive the serial port with Perl the other day. I came
up with this pretty quickly. I am logging into an HPUX system from a
Linux system then running the ioscan command. You should be able to do
something similar for your display. You just have to understand it's
protocol.
#!/usr/local/bin/perl
use strict;
use warnings;
sub readUntil {
my $port = shift;
my $pat = shift;
my $data = "";
my $buf = "";
my $br;
my $timeout = 10000;
do {
$br = sysread($port, $buf, 256);
$data .= $buf if $br > 0;
} while ($data !~ /$pat/i && $timeout--);
return $data;
}
my $port;
open ($port, "+</dev/ttyS0") || die "cannot open port S0: $!\n";
# you will have to tweak this depending on your comm protocol
# my guess is that raw might do what you want
system("stty 9600 raw < /dev/ttyS0");
syswrite($port, "\r");
readUntil($port,"login:");
syswrite($port, "$user\r");
readUntil($port,"assword");
syswrite($port,"$password\r");
readUntil($port,"Terminal Type?");
syswrite($port,"vt100\r");
readUntil($port,"#");
syswrite($port, "ioscan\r");
# I am just dumping the output of the ioscan command to a file
# you probably want to do something else
my $output = readUntil($port,"#");
my $outfile;
open ($outfile,">data.txt");
print $outfile $output;
close $outfile;
syswrite($port, "exit\r");
close $port;
-John
It isn't pretty but it works.
------------------------------
Date: Mon, 29 Mar 2004 17:49:29 -0600
From: "N.A." <leftfoot@siu.edu>
Subject: Perl-5.8.2 NDBM_File appears to insert POD into DB file?
Message-Id: <pan.2004.03.29.23.49.26.873471@siu.edu>
Using Perl-5.8.2 and the following (INN) script to insert values into a
new DB file, it appears that Perl/NDBM_File is grabbing some POD
documentation from somewhere and inserting it into the DB file?! This does
NOT happen with Perl-5.6.1.
#!/usr/bin/perl
use Fcntl;
use NDBM_File;
tie (%db, 'NDBM_File', 'newsusers', O_RDWR | O_CREAT, 0640)
or die "Cannot open newsusers: $!\n";
$| = 1;
print "Username: ";
my $user = <STDIN>;
chomp $user;
print "Password: ";
my $passwd = <STDIN>;
chomp $passwd;
my @alphabet = ('.', '/', 0..9, 'A'..'Z', 'a'..'z');
my $salt = join '', @alphabet[rand 64, rand 64];
$db{$user} = crypt ($passwd, $salt);
untie %db;
exit;
====== sample "POD garbage" plus script data in DB file ==================
strings newsusers.db
orage = bless [{}, @_], $class;
warn "New ReportHash created, stored in $storage.\n";
$storage;
sub STORE {
warn "Storing data with key $_[1] at $_[0].\n";
$_[0][0]{$_[1]} = $_[2]
The default C<TIEHASH> method stores "extra" arguments to tie() starting
from offset 1 in the array referenced by C<tied(%tiedhash)>; this is the
same storage algorithm as in TIEHASH subroutine above. Hence, a typical
package inheriting from B<Tie::ExtraHash> does not need to overwrite this
method.
=head1 C<UNTIE> and C<DESTROY>
The methods C<UNTIE> and C<DESTROY> are not defined in B<Tie::Hash>,
B<Tie::StdHash>, or B<Tie::ExtraHash>. Tied hashes do not require
presense of these methods, but if defined, the methods will be called in
proper time, see L<perltie>.
If needed, these methods should be defined by the package inheriting from
B<Tie::Hash>, B<Tie::StdHash>, or B<Tie::ExtraHash>.
=head1 MORE INFORMATION
The packages relating to various DBM-related implementations (F<DB_File>,
F<NDBM_File>, etc.) show examples of general tied hashes, as does the
L<Config> module. While these do not utilize B<Tie::Hash>, they serve as
good working examples.
=cut
use Carp;
use warnings::register;
sub new {
my $pkg = shift;
$pkg->TIEHASH(@_);
# Grandfather "new"
sub TIEHASH {
my $pkg = shift;
if (defined &{"${pkg}::new"}) {
warnings::warnif("WARNING: calling ${pkg}->new since ${pkg}->TIEHASH is missing");
$pkg->new(@_);
}
else {
croak "$pkg doesn't define a TIEHASH method";
}
sub EXISTS {
my $pkg = ref $_[0];
croak "$pkg doesn't define an EXISTS method";
sub CLEAR {
my $self = shift;
my $key = $self->FIRSTKEY(@_);
my @keys;
while (defined $key) {
push @keys, $key;
$key = $self->NEXTKEY(@_, $key);
}
foreach $key (@keys) {
$self->DELETE(@_, $key);
}
# The Tie::StdHash package implements standard perl hash behaviour.
# It exists to act as a base class for classes which only wish to
# alter some parts of their behaviour.
package Tie::StdHash;
# @ISA = qw(Tie::Hash); # would inherit new() only
sub TIEHASH { bless {}, $_[0] }
sub STORE { $_[0]->{$_[1]} = $_[2] }
sub FETCH { $_[0]->{$_[1]} }
sub FIRSTKEY { my $a = scalar keys %{$_[0]}; each %{$_[0]} }
sub NEXTKEY { each %{$_[0]} }
sub EXISTS { exists $_[0]->{$_[1]} }
sub DELETE { delete $_[0]->{$_[1]} }
sub CLEAR { %{$_[0]} = () }
package Tie::ExtraHash;
sub TIEHASH { my $p = shift; bless [{}, @_], $p }
sub STORE { $_[0][0]{$_[1]} = $_[2] }
sub FETCH { $_[0][0]{$_[1]} }
sub FIRSTKEY { my $a = scalar keys %{$_[0][0]}; each %{$_[0][0]} }
sub NEXTKEY { each %{$_[0][0]} }
sub EXISTS { exists $_[0][0]->{$_[1]} }
sub DELETE { delete $_[0][0]->{$_[1]} }
sub CLEAR { %{$_[0][0]} = () }
Note that you cannot use tags in @EXPORT or @EXPORT_OK.
Names in EXPORT_TAGS must also appear in @EXPORT or @EXPORT_OK.
An application using Module can say something like:
use Module qw(:DEFAULT :T2 !B3 A3);
Other examples include:
use Socket qw(!/^[AP]F_/ !SOMAXCONN !SOL_SOCKET);
use POSIX qw(:errno_h :termios_h !TCSADRAIN !/^EXIT/);
Remember that most patterns (using //) will need to be anchored
with a leading ^, e.g., C</^EXIT/> rather than C</EXIT/>.
You can say C<BEGIN { $Exporter::Verbose=1 }> to see how the
specifications are being processed and what is actually being imported
into modules.
=head2 Exporting without using Exporter's import method
Exporter has a special method, 'export_to_level' which is used in situations
where you can't directly call Exporter's import method. The export_to_level
method looks like:
MyPackage->export_to_level($where_to_export, $package, @what_to_export);
where $where_to_export is an integer telling how far up the calling stack
to export your symbols, and @what_to_export is an array telling what
symbols *to* export (usually this is @_). The $package argument is
currently unused.
For example, suppose that you have a module, A, which already has an
import function:
package A[gen.passwd script data]
------------------------------
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 V10 Issue 6336
***************************************
