[22915] in Perl-Users-Digest
Perl-Users Digest, Issue: 5135 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 25 14:05:51 2003
Date: Wed, 25 Jun 2003 11:05:08 -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 Wed, 25 Jun 2003 Volume: 10 Number: 5135
Today's topics:
Re: Accessing constants from another package/file. <coo_t2-NO-LIKE-SPAM@yahoo.com>
Async Message Passing Mechanism Wanted (John Ramsden)
Re: Database Connection Pooling in Perl CGI Script WITH <GPatnude@HotMail.com>
DB_File, large hash, memory. <a24061@void.yahoo.void.com>
Re: DB_File, large hash, memory. <paul.marquess@btinternet.com>
how to convert all invalid UTF-8 sequences to numeric e (Shambo)
Looking for inspiration: cascading CGI <g4rry_short@zw4llet.com>
Re: Looking for inspiration: cascading CGI <bdonlan@bd-home-comp.no-ip.org>
Re: Looking for inspiration: cascading CGI <GPatnude@HotMail.com>
Re: Oracle CLOB using DBI (Ken Chesak)
Perl & HTTP <ed.murray@attbi.com>
Re: Perl & HTTP <mbudash@sonic.net>
Re: Perl & HTTP <bdonlan@bd-home-comp.no-ip.org>
Re: Perl & HTTP <john.thetenant-s@moving-picture.com>
Re: perl compression <minceme@start.no>
Quick Q about $| <rajkothary@hotmail.com>
Re: Quick Q about $| <bdonlan@bd-home-comp.no-ip.org>
Re: Quick Q about $| <matthew@weierophinney.net>
Re: Quick Q about $| <tzz@lifelogs.com>
Re: Surprised by read() (Mark Wirdnam)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 25 Jun 2003 17:13:26 GMT
From: ed <coo_t2-NO-LIKE-SPAM@yahoo.com>
Subject: Re: Accessing constants from another package/file.
Message-Id: <vhljfvods579f2kme3q0e1ouebbd5kuo1d@4ax.com>
Thanks guys!(and gurls).
It makes more sense to me now.
I guess I have to read about, and play around with "use" vs "require" to
get a good understanding of the differences and the whole
"compile time" vs "runtime" thing.
I changed the name of 'DE_Constants.pl' to 'DE_Constants.pm' and put
use DE_Constants;
where "require DE_Constants.pl" used to be.
I have a feeling now that using "use" instead of "require" is
probably always the safer way to do it when "including" a file that uses a module(and obviously
also when using a module directly).
Thanks again.
--ed
------------------------------
Date: 25 Jun 2003 07:59:54 -0700
From: john_ramsden@sagitta-ps.com (John Ramsden)
Subject: Async Message Passing Mechanism Wanted
Message-Id: <d27434e.0306250659.57289803@posting.google.com>
Is there a Perl module that implements a low-overhead FIFO
(order-preserving) async message passing mechanism and works
on Windows and Unix?
It only needs to run locally, but it must allow message queuing,
with no practical limit on the buffer size (which rules out pipes),
in case the receiver can't keep up with the sender.
Better still would be an async message passing layer above TCP
that could be used the same way remotely.
I don't want all the setup and data-formatting complications and
overheads of email, just something like a socket connection for
which I need not worry about buffer overflows.
(My app involves several clients each periodically sending bursts
of data to a central server. I currently use TCP socket links,
and am starting to suffer data loss when several agents are
active.)
I've been looking at a package called Spread (www.spread.org),
which is highly-regarded and has been developed over several
years. But this seems more geared up for one-to-many sessions
and doesn't appear to emphasise the buffering aspect which I
need.
Any suggestions gratefully received...
Cheers
John Ramsden (john_ramsden@sagitta-ps.com)
------------------------------
Date: Wed, 25 Jun 2003 17:00:57 GMT
From: "codeWarrior" <GPatnude@HotMail.com>
Subject: Re: Database Connection Pooling in Perl CGI Script WITHOUT mod_perl
Message-Id: <dzkKa.17483$Jw6.7222101@news1.news.adelphia.net>
"Pete Butler" <pmbutler@attbi.com> wrote in message
news:9b766f0.0306241308.4155a65b@posting.google.com...
> Juha Laiho <Juha.Laiho@iki.fi> wrote in message
news:<bda3vm$ibe$1@ichaos.ichaos-int>...
>
> > With these, I find it very hard to see where you could store your
> > open database connections. Or, ok, you could have a separate standalone
> > process having the DB connections open, and then connecting to that
> > process form your CGI, but I think that wouldn't be that much faster.
>
> Drat.
>
> > As for performance; I think the cost of setting up a MySQL connection
> > can't be even 1/10 of the cost of firing up a CGI process, so your
> > bottleneck won't be the database connection set-up time.
>
> I didn't realize the DB connection was chump change compared to the
> CGI itself, so thanks for that tip. Even so, I think I can help my
> performance if I trim down the number of connections I make; I have it
> set up so that each SQL query opens and closes its own connection.
> That's going to be a minimum of two connections per page load (one to
> grab user session data, at least one to populate the page). Maybe if
> I do a little refactoring, I can get my code to open and pass around a
> single connection. Or something.
>
> But regardless, thanks for letting me know I'm pretty much chasing a
> dead end.
>
> -- Pete Butler
Pete -- Now you're beginning to think like I do ..In my perl scripts -- I
use ONE connection defined in ONE subroutuine and pass it / use it
everywhere in the running CGI... Kind of like this:
if ($DBH = pm_dbConnect()) { # CALL THE GLOBAL DATABASE CONNECTION...
$SQLSTMT = "SELECT id, concat_ws(' ', f_name, l_name) AS person_name
FROM people where active_flag = 'Y'";
$SQL = $DBH->prepare($SQLSTMT);
$result = $SQL->execute();
if ($SQL->rows()) {
while (my $REF = $SQL->fetchrow_hashref()) {
$ID = $REF->{id};
$PERSON_NAME = $REF->{person_name};
}
}
} else {
die "Unable to connect to the system database...";
}
# * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB *
SUB * SUB * SUB *
# * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB * SUB *
SUB * SUB * SUB *
sub pm_dbConnect() {
# print "Using database: $DBNAME";
if (defined($DBH)) {
return $DBH;
} else {
# TRY TO CONNECT... IF IT WORKS -- RETURN -- THE DATABASE HANDLE IS A
GLOBAL --> $DBH...
if (eval {$DBH = DBI->connect($DBNAME, $DBUSER, $DBPSWD,
{RaiseError => 1, AutoCommit => 1}) }) {
return $DBH;
} else {
# CONNECTING FAILED...
die "$@";
return undef;
}
}
}
------------------------------
Date: Wed, 25 Jun 2003 14:35:01 GMT
From: Adam <a24061@void.yahoo.void.com>
Subject: DB_File, large hash, memory.
Message-Id: <pqiKa.5920$CD4.41592947@news-text.cableinet.net>
I think that using DB_File causes the whole database/hash to be loaded
into memory from dbmopen to dbmclose. Is that correct?
Is there any way to connect a file to a hash so that this is not the case?
I'd like to work with a very large hash without using much memory.
(Obviously it will be slower.)
Thanks.
------------------------------
Date: Wed, 25 Jun 2003 15:52:26 +0100
From: "Paul Marquess" <paul.marquess@btinternet.com>
Subject: Re: DB_File, large hash, memory.
Message-Id: <3ef9b72c$0$10632$ed9e5944@reading.news.pipex.net>
Nope, DB_File will only store everything in memory if you explicitly ask it
to. By default, it only keeps a small amount in memory.
Paul
"Adam" <a24061@void.yahoo.void.com> wrote in message
news:pqiKa.5920$CD4.41592947@news-text.cableinet.net...
> I think that using DB_File causes the whole database/hash to be loaded
> into memory from dbmopen to dbmclose. Is that correct?
>
> Is there any way to connect a file to a hash so that this is not the case?
> I'd like to work with a very large hash without using much memory.
> (Obviously it will be slower.)
>
> Thanks.
>
------------------------------
Date: 25 Jun 2003 08:34:46 -0700
From: shambo_p@yahoo.com (Shambo)
Subject: how to convert all invalid UTF-8 sequences to numeric equivalent?
Message-Id: <72190192.0306250734.6651e586@posting.google.com>
Hey folks,
I've been grappling with this for days, and can see no option but to
use brute force.
We have a ton of text files from all over the world, often times
including invalid UTF-8 characters such as ø or £ (that was an o with
a line thru it, a la Scandanavian letters, and a British pound
sterling symbol). When I convert these text files to XML, the
resulting XML is not valid becuase it contains these characters. I can
map individual charatcers to their numerical equivalent (ø and
£ in this case), but I'm wary about performing such a conversion
for each and every non UTF-8 valid sequence I may find.
So my question is, has someone found a way to automate converion of
these charcters to their numerical equivalent without having to list
every sinlge character? I searched for scripts and modules that might
do this, but didn't see any that jumped out at me.
Secondly, I had been doing brute-force checking for every non-UTF-8
valid sequence, and I might be doing it incorrectly. For example, if I
searched for the hex string \xA3, I was expecting to match on the £
symbol. Not so. I have to explicitly search for the £ symbol, not the
hex equivalent, because that's how it is in the text file.
To re-iterate:
$line =~ s/\xA3/\£\;/g;
does not work when the literal symbol £ is in the text. I thought
forcing Perl to find the hex version of any character would work. I
guess I'm missing something.
Any insight would be mst appreciated.
thanks very much,
Shambo
------------------------------
Date: Wed, 25 Jun 2003 16:45:39 +0000
From: Garry Short <g4rry_short@zw4llet.com>
Subject: Looking for inspiration: cascading CGI
Message-Id: <bdcg7m$mdn$1$8300dec7@news.demon.co.uk>
Hi all,
I'm looking for a little inspiration! I'm working on a site involving a lot
of CGI - each script generates an HTML page that connects to another
script.
I'm currently thinking I need a way of passing variables from one script to
the next. At the moment I can think of two possibilities, and I'm not
convinced by either of them!
1. Write the variables to a logfile somewhere, which each script can read
and then overwrite.
2. Have a "Next >" button, as follows:
<INPUT TYPE="SUBMIT" NAME="cgi_passed_vars" VALUE="$var1##$var2##$var3">
Then, in the new script, this section of code:
use CGI;
my $form_data = new CGI;
my ($var1, $var2, $var3) =
split /##/, $form_data->param( "cgi_passed_vars" );
Which is the better approach? Is there an even better alternative? Which
would be the easiest for someone else to support after I'm gone?
Personally, I'm inclined to go with #2 at the moment. What do you guys
think?
Cheers,
Garry
------------------------------
Date: Wed, 25 Jun 2003 12:43:47 -0400
From: "bd" <bdonlan@bd-home-comp.no-ip.org>
Subject: Re: Looking for inspiration: cascading CGI
Message-Id: <pan.2003.06.25.16.43.45.398810@bd-home-comp.no-ip.org>
On Wed, 25 Jun 2003 16:45:39 +0000, Garry Short wrote:
> Hi all,
>
> I'm looking for a little inspiration! I'm working on a site involving a lot
> of CGI - each script generates an HTML page that connects to another
> script.
>
> I'm currently thinking I need a way of passing variables from one script to
> the next. At the moment I can think of two possibilities, and I'm not
> convinced by either of them!
>
> 1. Write the variables to a logfile somewhere, which each script can read
> and then overwrite.
>
> 2. Have a "Next >" button, as follows:
> <INPUT TYPE="SUBMIT" NAME="cgi_passed_vars" VALUE="$var1##$var2##$var3">
> Then, in the new script, this section of code:
>
> use CGI;
> my $form_data = new CGI;
> my ($var1, $var2, $var3) =
> split /##/, $form_data->param( "cgi_passed_vars" );
>
3. Use a hidden element:
use CGI;
my $form_data = new CGI;
print $form_data->hidden(-name => 'cgi_passed_vars',
-default => [ $var1, $var2, $var3 ]);
And in the next script:
use CGI;
my $form_data = new CGI;
my ($var1, $var2, $var3) = $form_data->param('cgi_passed_vars');
See perldoc CGI for more details on this approach.
> Which is the better approach? Is there an even better alternative? Which
> would be the easiest for someone else to support after I'm gone?
>
> Personally, I'm inclined to go with #2 at the moment. What do you guys
> think?
>
> Cheers,
>
> Garry
--
Freenet distribution not available
Life is a POPULARITY CONTEST! I'm REFRESHINGLY CANDID!!
------------------------------
Date: Wed, 25 Jun 2003 17:25:45 GMT
From: "codeWarrior" <GPatnude@HotMail.com>
Subject: Re: Looking for inspiration: cascading CGI
Message-Id: <tWkKa.17501$Jw6.7227001@news1.news.adelphia.net>
"Garry Short" <g4rry_short@zw4llet.com> wrote in message
news:bdcg7m$mdn$1$8300dec7@news.demon.co.uk...
> Hi all,
>
> I'm looking for a little inspiration! I'm working on a site involving a
lot
> of CGI - each script generates an HTML page that connects to another
> script.
>
> I'm currently thinking I need a way of passing variables from one script
to
> the next. At the moment I can think of two possibilities, and I'm not
> convinced by either of them!
>
> 1. Write the variables to a logfile somewhere, which each script can read
> and then overwrite.
>
> 2. Have a "Next >" button, as follows:
> <INPUT TYPE="SUBMIT" NAME="cgi_passed_vars" VALUE="$var1##$var2##$var3">
> Then, in the new script, this section of code:
>
> use CGI;
> my $form_data = new CGI;
> my ($var1, $var2, $var3) =
> split /##/, $form_data->param( "cgi_passed_vars" );
>
>
> Which is the better approach? Is there an even better alternative? Which
> would be the easiest for someone else to support after I'm gone?
>
> Personally, I'm inclined to go with #2 at the moment. What do you guys
> think?
>
> Cheers,
>
> Garry
>
>
>
I'd recomend #2 before I tried storing stuff in a logfile... you can pass
form data pretty efficiently in hidden fields...
$FORMDATA = getFormData(); # GET THE FORM CONTENTS....
$NAME = $PARAMS{NAME};
$SUBMITBUTTON = $PARAMS{Submit};
$TEXT = $PARAMS{yourhtmlformfieldnamehere};
# THIS PERL SCRIPT RETRIEVES THE CONTENTS OF ANY FORM INTO A DEFINED HASH...
# RETRIEVES THE DATA FROM THE FORM...
sub getFormData() {
use CGI;
$capture = new CGI();
@FORMDATA = $capture->param();
%PARAMS = {};
# POPULATE THE HASH WITH THE FORM DATA...
foreach $line (@FORMDATA) {
chomp ($line);
$V = $capture->param("$line");
$PARAMS{$line} = $V;
$FORMCODES .= "<INPUT TYPE = 'HIDDEN' NAME = '$line' VALUE = '$V'>";
}
# AND RETURN...
return TRUE;
}
------------------------------
Date: 25 Jun 2003 08:46:43 -0700
From: datavector@hotmail.com (Ken Chesak)
Subject: Re: Oracle CLOB using DBI
Message-Id: <3f2f39c4.0306250746.727576bc@posting.google.com>
Would you email my hotmail account again, I delete by mistake since
99% is junk mail.
I get the following error,
DBD::Oracle::db prepare failed: ORA-03115: unsupported network
datatype or repre
sentation (DBD: odescr failed) at clob.pl line 26.
It runs if I use dbms_lob.substr( comments, 30000, 1).
$dbh->{LongReadLen} = 512 * 1024 ;
$dbh->{LongTruncOk} = 1;
$sth1 = $dbh->prepare(q{
SELECT cd_type, comments
FROM comments WHERE id_comment = 53
});
$sth1->execute();
while ( ($name, $data) = $sth1->fetchrow_array ) {
print "row = $name $data \n";
}
------------------------------
Date: Wed, 25 Jun 2003 15:58:26 GMT
From: Ed Murray <ed.murray@attbi.com>
Subject: Perl & HTTP
Message-Id: <1ex5zghzwt2uz.xqk5ll0pio2k.dlg@40tude.net>
I'd like to open a url from a windows script and read through the html file
searching for the info I want. Is there an easy way to do this.
This is my first post to a news group. Please let me know if my question is
not appropriate to this group.
Thanks,
Ed
------------------------------
Date: Wed, 25 Jun 2003 16:40:00 GMT
From: Michael Budash <mbudash@sonic.net>
Subject: Re: Perl & HTTP
Message-Id: <mbudash-CD5B55.09400225062003@typhoon.sonic.net>
In article <1ex5zghzwt2uz.xqk5ll0pio2k.dlg@40tude.net>,
Ed Murray <ed.murray@attbi.com> wrote:
> I'd like to open a url from a windows script and read through the html file
> searching for the info I want. Is there an easy way to do this.
> This is my first post to a news group. Please let me know if my question is
> not appropriate to this group.
>
> Thanks,
> Ed
a short perl script making use of the LWP module should do the trick
just fine... 'course you'll need perl installed on your box, but that's
easy:
http://www.indigostar.com/indigoperl.htm
hth-
--
Michael Budash
------------------------------
Date: Wed, 25 Jun 2003 12:38:41 -0400
From: "bd" <bdonlan@bd-home-comp.no-ip.org>
Subject: Re: Perl & HTTP
Message-Id: <pan.2003.06.25.16.38.41.607965@bd-home-comp.no-ip.org>
On Wed, 25 Jun 2003 15:58:26 +0000, Ed Murray wrote:
> I'd like to open a url from a windows script and read through the html file
> searching for the info I want. Is there an easy way to do this.
> This is my first post to a news group. Please let me know if my question is
> not appropriate to this group.
I assume, from context, that you're talking about a perl script. Use the
LWP module to download the URL. One of the HTML:: modules may help you
parse the data - since you didn't specify what info you want it's
impossible to be more specific.
--
Freenet distribution not available
Generosity and perfection are your everlasting goals.
------------------------------
Date: Wed, 25 Jun 2003 17:55:36 +0100
From: John Strauss <john.thetenant-s@moving-picture.com>
Subject: Re: Perl & HTTP
Message-Id: <20030625175536.25fe0afd.john.thetenant-s@moving-picture.com>
On Wed, 25 Jun 2003 15:58:26 GMT
Ed Murray <ed.murray@attbi.com> wrote:
>
> I'd like to open a url from a windows script and read through the html file
> searching for the info I want. Is there an easy way to do this.
> This is my first post to a news group. Please let me know if my question is
> not appropriate to this group.
>
> Thanks,
> Ed
You'll need to use LWP to get the HTML content.
The rest depends on what you mean by "the info I want".
If part of what you need to do is to strip out
or parse HTML tags, then read this:
perldoc -q "How do I remove HTML"
It'll explain why you will want to use HTML::Parser
or HTML::FormatText (the gist of it being that it
is trickier than it looks at first glance to reliably
parse HTML).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drop the .thetenant to get me via mail
------------------------------
Date: Wed, 25 Jun 2003 16:04:40 +0000 (UTC)
From: Vlad Tepes <minceme@start.no>
Subject: Re: perl compression
Message-Id: <bdch6o$d06$1@troll.powertech.no>
( off-topic, this is about compressing content on webservers: )
Alan J. Flavell <flavell@mail.cern.ch> wrote:
>> If you use Apache, the preferred way is to use mod_gzip to compress
>> ouput streams.
> Considering that compressing a document on-the-fly costs more than
> uncompressing one that has been stored compressed, and that the
> majority of current web browsers accept gzip encoding, and that files
> occupy less space - and take less time and resources to read - when
> they are stored compressed, it would seem to me to be more appropriate
> to keep the documents on the server in compressed form, and only to
> uncompress them on the fly when the client request does _not_ indicate
> gzip amongst its accept-encoding options.
That's a nice idea. I searched and found there is an apache module for
uncompressing data, mod_gunzip.
This method seems like the best way to serve cached or static content.
--
Vlad
------------------------------
Date: Wed, 25 Jun 2003 15:37:49 +0100
From: "Raj" <rajkothary@hotmail.com>
Subject: Quick Q about $|
Message-Id: <bdcc3u$hl3$1$8300dec7@news.demon.co.uk>
Hi,
What does:
$|=1; select(STDOUT);
do? I understand that STDOUT is selected as the default handle, but what
about the bit preceding it?
Thanks,
Raj
------------------------------
Date: Wed, 25 Jun 2003 10:51:33 -0400
From: "bd" <bdonlan@bd-home-comp.no-ip.org>
Subject: Re: Quick Q about $|
Message-Id: <pan.2003.06.25.14.51.33.210547@bd-home-comp.no-ip.org>
On Wed, 25 Jun 2003 15:37:49 +0100, Raj wrote:
> Hi,
>
> What does:
>
> $|=1; select(STDOUT);
>
> do? I understand that STDOUT is selected as the default handle, but what
> about the bit preceding it?
perldoc perlvar:
$| If set to nonzero, forces a flush right away and after every
write or print on the currently selected output channel.
Default is 0 (regardless of whether the channel is really
buffered by the system or not; $| tells you only whether you've
asked Perl explicitly to flush after each write). STDOUT will
typically be line buffered if output is to the terminal and
block buffered otherwise. Setting this variable is useful pri-
marily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see
the output as it's happening. This has no effect on input
buffering. See "getc" in perlfunc for that. (Mnemonic: when
you want your pipes to be piping hot.)
--
Freenet distribution not available
Journalism is literature in a hurry.
-- Matthew Arnold
------------------------------
Date: Wed, 25 Jun 2003 15:00:10 GMT
From: Matthew Weier O'Phinney <matthew@weierophinney.net>
Subject: Re: Quick Q about $|
Message-Id: <_NiKa.111694$zm1.98342@twister.nyroc.rr.com>
* Raj <rajkothary@hotmail.com>:
> What does:
>
> $|=1; select(STDOUT);
>
> do? I understand that STDOUT is selected as the default handle, but what
> about the bit preceding it?
$! = output autoflush. STDOUT is typically line buffered, which means
that there will often be a delay in seeing output if you're piping to
another process (CGI and rsh are two examples). By setting $| to a
non-zero value, you 'turn off' the buffering (actually, it flushes using
fflush(3) after each command that should be piped to STDOUT, usually
print or write).
--
Matthew Weier O'Phinney
http://weierophinney.net/matthew/
------------------------------
Date: Wed, 25 Jun 2003 11:11:46 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Quick Q about $|
Message-Id: <4nbrwmi43x.fsf@lockgroove.bwh.harvard.edu>
On Wed, 25 Jun 2003, rajkothary@hotmail.com wrote:
> Hi,
>
> What does:
>
> $|=1; select(STDOUT);
>
> do? I understand that STDOUT is selected as the default handle, but
> what about the bit preceding it?
Try "perldoc perlvar" to find the answer.
Ted
------------------------------
Date: 25 Jun 2003 09:48:33 -0700
From: mark.wirdnam@stud.unibas.ch (Mark Wirdnam)
Subject: Re: Surprised by read()
Message-Id: <3c6df95c.0306250848.2ba29949@posting.google.com>
mark.wirdnam@stud.unibas.ch (Mark Wirdnam) wrote in message news:<3c6df95c.0306242200.63077dc5@posting.google.com>...
> tiltonj@erols.com (Jay Tilton) wrote in message news:<3ef8da98.255588305@news.erols.com>...
>
> > ....
> > binmode() acquired relevance on unix-like systems in Perl 5.8.
>
> Thanks, I missed this vital information. It sounds like the likely
> source of trouble. As soon as I can try this out, I'll post a short
> feedback.
>
Indeed, that was the source of my problems. I can get my scripts to work now.
Mark
------------------------------
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.
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 5135
***************************************
