[28731] in Perl-Users-Digest
Perl-Users Digest, Issue: 10095 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Dec 25 03:06:03 2006
Date: Mon, 25 Dec 2006 00:05:06 -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, 25 Dec 2006 Volume: 10 Number: 10095
Today's topics:
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <antispam@randometry.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <antispam@randometry.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <jurgenex@hotmail.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <bik.mido@tiscalinet.it>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <bik.mido@tiscalinet.it>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <puckdropper@yahoo.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <john@castleamber.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <john@castleamber.com>
Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX <jwkenne@attglobal.net>
new CPAN modules on Mon Dec 25 2006 (Randal Schwartz)
Re: Replacing expression in a file from mechanize <noreply@gunnar.cc>
Re: Speeding up an application - general rules <phynkel@gmail.com>
Re: Speeding up an application - general rules <phynkel@gmail.com>
Re: Speeding up an application - general rules <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Dec 2006 22:27:07 +0100
From: Ric <antispam@randometry.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <emmrbj$30c$1@online.de>
John Bokma schrieb:
> Ric <antispam@randometry.com> wrote:
>
>> Perhaps some things are done in C++ you can't do at all in Perl, so
>> don't even try.
>
> Ah, the pissing contest! Remember Ric, you are not the language.
>
> Not understanding that a language like Perl has a place makes your
> software engineering skills doubtful, to say the least.
>
If you comment on someones thread then first read the whole discussion,
you obviously didn't read it.
I started with the note, that perl is not designed to be used for large
scale apps. Some folks didn't agree, that's their problem.
Show me a large scale app like apache, mysql, word etc. that is written
in perl and I will shut up:-)
------------------------------
Date: Sun, 24 Dec 2006 22:32:33 +0100
From: Ric <antispam@randometry.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <emmrlo$45p$1@online.de>
Jürgen Exner schrieb:
> Ric wrote:
>> Perhaps some things are done in C++ you can't do at all in Perl,
>
> Hardly. Both languages are Turing complete, therefore there is no difference
> between what you can do in each.
If we talk about functional requirements, then you may be right, but
what about non funtional requirements.
For example a high speed 3d engine or a maintainable gui application
like openoffice
If you can do everything in perl, why does everyone design and write
large apps in C++, C# Java
>
>> so don't even try.
>
> If Perl makes it more difficult to shoot yourself in the foot then I
> actually welcome those limitations.
Yeah right!
I do lots of perl programming and I have done lots of writing in C/C++
and C#, buts that's the silliest argument I've heard so far.
>
> jue
>
>
------------------------------
Date: Sun, 24 Dec 2006 22:16:14 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <O_Cjh.4909$sz5.479@trndny03>
Ric wrote:
> Jürgen Exner schrieb:
>> Ric wrote:
>>> Perhaps some things are done in C++ you can't do at all in Perl,
>>
>> Hardly. Both languages are Turing complete, therefore there is no
>> difference between what you can do in each.
>
> If you can do everything in perl, why does everyone design and write
> large apps in C++, C# Java
I don't know everyone, therefore I don't know if this claim is true.
However many people probably write certain applications in other languages
because they don't know about Perl, because of personal preference, because
of corporate mandates, or even because that other language is better suited
for that application.
Non of this percludes that the application could not be written in Perl if
you would want to.
>> If Perl makes it more difficult to shoot yourself in the foot then I
>> actually welcome those limitations.
>
> Yeah right!
>
> I do lots of perl programming and I have done lots of writing in C/C++
> and C#, buts that's the silliest argument I've heard so far.
If you like convoluted pointer arithmetic, doing garbage collection
manually, and not having any operators on any compound data types, then that
is certainly your choice. I for my part prefer programming languages that
support my way of thinking, not hinder it with technical nonsense.
jue
------------------------------
Date: Sun, 24 Dec 2006 23:26:53 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <ghvto2llc618fk0g3lson4uii97tae4ldv@4ax.com>
On Sun, 24 Dec 2006 22:32:33 +0100, Ric <antispam@randometry.com>
wrote:
>> Hardly. Both languages are Turing complete, therefore there is no difference
>> between what you can do in each.
>
>If we talk about functional requirements, then you may be right, but
>what about non funtional requirements.
>For example a high speed 3d engine or a maintainable gui application
>like openoffice
Which is true and acknowledged and even advocated here constantly, but
has nothing to do with the *scale* of an application: the starting
point in your inflammatory remark.
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: Sun, 24 Dec 2006 23:54:00 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <h21uo2hljrcfifuirhsamgrvg8tvppq8hv@4ax.com>
On Sat, 23 Dec 2006 19:34:10 -0600, Tad McClellan
<tadmc@augustmail.com> wrote:
>> Subject: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
[snip]
>Any of the tutorials mentioned in the Perl FAQ.
>
> perldoc -q book
Also, today I went around by my town and I also enterd the bookstore
which probably has the biggest CS section here. I gave a quick look at
the Perl books, and I noticed a "Minimal Perl" one which should be
aimed precisely at UNIX/Linux sysadmins. I can't comment on the book
proper, but the latter has a foreword by ("that") Conway, and I don't
believe in the principle of authority in general, but a priori that's
a sort of guarantee...
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: 24 Dec 2006 23:48:43 GMT
From: Puckdropper <puckdropper@yahoo.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <458f11db$0$97229$892e7fe2@authen.yellow.readfreenews.net>
Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr> wrote in news:458e7852
$0$27366$ba4acef3@news.orange.fr:
> People still measure application size in terms of lines of code?
>
> Mark
Sure, what other metric is common to programs that's easily measured?
It's bad, but it's the best they've got. I had probably 1000 LOC in a
recent class project and probably wrote only 100 myself. Everything else
was done by a GUI builder or by the UML tool I used. (It was Java, not
Perl, but I constantly wished it was Perl. Does that count as on topic
here? ;-))
Puckdropper
--
Wise is the man who attempts to answer his question before asking it.
To email me directly, send a message to puckdropper (at) fastmail.fm
------------------------------
Date: 25 Dec 2006 00:01:01 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <Xns98A3B7474B2A1castleamber@130.133.1.4>
Ric <antispam@randometry.com> wrote:
> Show me a large scale app like apache, mysql, word etc. that is written
> in perl and I will shut up:-)
Slashdot. But I am sure that you're going to tell "us" that Slashdot is
not an application and more yada yada. Like I already said, pissing
contest.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: 25 Dec 2006 00:03:59 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <Xns98A3B7C7FE498castleamber@130.133.1.4>
Ric <antispam@randometry.com> wrote:
> I do lots of perl programming and I have done lots of writing in C/C++
> and C#, buts that's the silliest argument I've heard so far.
Clueless. Technically it's possible to run (a subset of) Perl on .NET.
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
------------------------------
Date: Sun, 24 Dec 2006 19:20:31 -0500
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: BEST PERL BOOK FOR SYSTEM ADMINISTRATION UNIX
Message-Id: <oPEjh.2393$Bf.2374@newsfe12.lga>
Puckdropper wrote:
> Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr> wrote in news:458e7852
> $0$27366$ba4acef3@news.orange.fr:
>
>
>> People still measure application size in terms of lines of code?
>>
>> Mark
>
> Sure, what other metric is common to programs that's easily measured?
>
> It's bad, but it's the best they've got. I had probably 1000 LOC in a
> recent class project and probably wrote only 100 myself. Everything else
> was done by a GUI builder or by the UML tool I used. (It was Java, not
> Perl, but I constantly wished it was Perl. Does that count as on topic
> here? ;-))
I seem to recall that, back in the 60s or 70s, someone did a study and
discovered that LOCs actually was a pretty decent metric, even
cross-language. From one language to another, one LOC seemed to take up
about the same average amount of planning, debugging, etc.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
------------------------------
Date: Mon, 25 Dec 2006 05:42:12 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Mon Dec 25 2006
Message-Id: <JAtEIC.DGu@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Apache2-AutoIndex-XSLT-0.01
http://search.cpan.org/~nicolaw/Apache2-AutoIndex-XSLT-0.01/
XSLT Based Directory Listings
----
Catalyst-Plugin-Upload-Image-Magick-0.02
http://search.cpan.org/~zigorou/Catalyst-Plugin-Upload-Image-Magick-0.02/
Image information plugin for Catalyst::Request::Upload
----
DBD-mysql-4.00
http://search.cpan.org/~capttofu/DBD-mysql-4.00/
MySQL driver for the Perl5 Database Interface (DBI)
----
LaTeX-TOM-0.3
http://search.cpan.org/~schubiger/LaTeX-TOM-0.3/
(TeX Object Model) v0.3 - A module for parsing, analyzing, and manipulating LaTeX documents.
----
Net-Libdnet6-0.10
http://search.cpan.org/~gomor/Net-Libdnet6-0.10/
adds IPv6 support to Net::Libdnet
----
Path-Class-0.16
http://search.cpan.org/~kwilliams/Path-Class-0.16/
Cross-platform path specification manipulation
----
SVK-1.99_91
http://search.cpan.org/~clkao/SVK-1.99_91/
A Distributed Version Control System
----
String-MFN-1.28
http://search.cpan.org/~mdxi/String-MFN-1.28/
Normalize a string to produce a sane Unix filename
----
TM-1.24
http://search.cpan.org/~drrho/TM-1.24/
Topic Maps, Base Class
----
WebService-Audioscrobbler-0.02
http://search.cpan.org/~nilsonsfj/WebService-Audioscrobbler-0.02/
An object-oriented interface to the Audioscrobbler WebService API
----
WordNet-SenseRelate-TargetWord-0.09
http://search.cpan.org/~sid/WordNet-SenseRelate-TargetWord-0.09/
modules for performing word sense disambiguation.
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Mon, 25 Dec 2006 01:47:11 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Replacing expression in a file from mechanize
Message-Id: <4v8l8lF1b753vU1@mid.individual.net>
Nospam wrote:
> Basically I have a local html file,
The guy is multi-posting.
http://www.thescripts.com/forum/thread580426.html
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 24 Dec 2006 13:54:10 -0800
From: "Petyr David" <phynkel@gmail.com>
Subject: Re: Speeding up an application - general rules
Message-Id: <1166997250.860581.16070@42g2000cwt.googlegroups.com>
You're correct: I use Perl's back tics to take output from a command
that looks similar to this to populate an array:
my @filepatterns=`find $subdir -n $days -type f -exec egrep $pattern {}
\; |sed "s/somepattern/diffpattern"`
I like using the find command because I can also control how many days
to go back in my search. I will also check Devl::DProf
On Dec 22, 12:15 am, Eric Schwartz <emsch...@pobox.com> wrote:
> "Petyr David" <phyn...@gmail.com> writes:
> > Basically: the script uses perl's system command to run a long winded
> > "find" command which is piped to sed to correct patterns that match
> > HTML markers.You are unclear here, which is why we generally ask you to post
> example code. In fact, it's really kinda hard to say anything for
> sure because you didn't. I'm not sure, for instance, if you pipe the
> output of find to sed, or if you iterate over the list of files
> returned by find and run sed on the contents of those files. I'm
> guessing the former, but it's just a guess. If you want people to be
> able to help you the best way possible, you probably don't want to
> make them guess.
>
> > The matching lines are then shoved into an array.Which lines? Are you talking about contents of the files, or names of
> files? Now I think you're talking about contents. It would help if
> you were more clear.
>
> > The elements of the array are moved into a hash for the purpose of
> > sorting the file names.Er, now I think you're talking about file names.
>
> > Then file names and matching lines are printed.Now I have no idea. What are you actually doing? Can you please show
> some code?
>
> > Q: Can I speed things by eliminating the sed command and letting Perl
> > filter and modify the matching patterns? If so, how much of a
> > performance gain?Honestly, rather than asking us, you should ask Perl. The answer to
> "how do I speed things up?" is profile profile profile! Until you
> profile, you don't know what will help.
>
> 'perldoc -q profile' mentions the Devel::DProf module, and you can use
> 'perldoc Devel::DProf' to find out more about it. You'll also want to
> learn about the Benchmark module ('perldoc Benchmark'), which will
> help you compare two different ways of doing the same thing to find
> out which is faster.
>
> > Is using Perl's grep to search through every file for the pattern
> > faster than using the find command?Wait, are you on Windows? It's been a very long time, but I vaguely
> recall that the Windows 'find' command searches in files, whereas the
> Unix one mostly just looks at file names and metadata.
>
> > The find command has the advantage that I can search for files of a
> > certain date rather easily. Again: could that be done more rapidly
> > by Perl's looking at the file's mod time?Those questions really depend on uch a large a number of things,
> including your system's OS, configuration, load for other tasks, etc,
> that it's almost impossible for anyone to tell you for certain.
> Honestly, even if somebody were to give you an answer here, I wouldn't
> believe them-- they may be telling you what worked for them, but it
> might not be the same for you. Profile, then optimize the
> worst-performing part, then profile again, optimize what's left, and
> repeat. Take care that in optimizing one part you don't make another
> slower-- but that's all part of the art, really.s
>
> > Any thoughts or suggestions would be appreciatedEnjoy. But next time, please post some code, so we can actulaly tell
> what you're doing. Making people guess and make stuff up is
> frustrating for us, because we can't tell if we're guessing right, or
> going completely off the deep end. I hope I was helpful anyway.
>
> -=Eric
------------------------------
Date: 24 Dec 2006 13:55:56 -0800
From: "Petyr David" <phynkel@gmail.com>
Subject: Re: Speeding up an application - general rules
Message-Id: <1166997356.811834.20110@42g2000cwt.googlegroups.com>
This litle app is web based and is going against files on a Red Hat
Server's NFS file system. I suppose I could use Samba ...
On Dec 22, 7:56 pm, Ric <antis...@randometry.com> wrote:
> Petyr David schrieb:
>
> > I will also review those URLS. Creating an app that did indexing of the
> > files did not come up as this script came from a far simpler one that
> > merely found files matching the single pattern and printed a link to
> > the file. I also don't have the time to make this a full time job.
> > Something was needed quick and dirty and that's what they got : -)I just took a quick look at your problem description, not sure what your
> needs are, but have you considered using a desktop search engine to do
> the work for you?
>
> http://beagle-project.org/Searching_Data
>
>
>
>
>
> > TX
>
> > On Dec 22, 4:28 am, "Todd W" <t...@sbcglobal.net> wrote:
> >> "Petyr David" <phyn...@gmail.com> wrote in messagenews:1166757223.858558.144370@48g2000cwx.googlegroups.com...
>
> >>> I have a small Perl application that searches through a series of
> >>> directories chosen by the user for files containing a pattern or group
> >>> of patterns. The file names and matching patterns are returned to the
> >>> user sorted by the file's modification time.The user also has the
> >>> choice of how far back in time to search and how many lines of output
> >>> he wants to see for each file.
> >>> With an expected and current increase of files and file sizes, the
> >>> application is bogging down a bit. I didn't design it with performance
> >>> in mind and I will be reviewing what I've done, but are there general
> >>> rules or specific suggestions you could offer to enhance performance?
> >>> Basically: the script uses perl's system command to run a long winded
> >>> "find" command which is piped to sed to correct patterns that match
> >>> HTML markers. The matching lines are then shoved into an array. The
> >>> elements of the array are moved into a hash for the purpose of sorting
> >>> the file names. Then file names and matching lines are printed.
> >>> Q: Can I speed things by eliminating the sed command and letting Perl
> >>> filter and modify the matching patterns? If so, how much of a
> >>> performance gain?
> >>> Is using Perl's grep to search through every file for the pattern
> >>> faster than using the find command? The find command has the advantage
> >>> that I can search for files of a certain date rather easily. Again:
> >>> could that be done more rapidly by Perl's looking at the file's mod
> >>> time?
> >>> Any thoughts or suggestions would be appreciatedThe conventional way of doing what you are proposing is some how building an
> >> index of the files. Your index interface then gives you pointers to results
> >> when a search is performed. If the data changes regularly, you also have to
> >> regularly reindex your files.
>
> >> I've been using htdig in some form or another to accomplish what you
> >> suggest.
>
> >> Your post, though, caused me to take another look on CPAN for relevant
> >> modules as I was sure the state of this technology has improved since I
> >> decided to use htdig (several years ago). The following module looks very
> >> promising:
>
> >>http://search.cpan.org/~dpavlin/Search-Estraier-0.08/
>
> >> I think I'm going to give it a try as my next search engine. Heres another
> >> one that looks interesting:
>
> >>http://search.cpan.org/~snkwatt/Search-FreeText-0.05/
>
> >> I found these modules by going to:
>
> >>http://search.cpan.org/search?query=search&mode=all
>
> >> Enjoy,
>
> >> Todd W.- Hide quoted text -- Show quoted text -
------------------------------
Date: Sun, 24 Dec 2006 23:23:01 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Speeding up an application - general rules
Message-Id: <7uuto2pofqqnufe3kjarbrfin7ffvu632d@4ax.com>
On 24 Dec 2006 13:54:10 -0800, "Petyr David" <phynkel@gmail.com>
wrote:
>You're correct: I use Perl's back tics to take output from a command
>that looks similar to this to populate an array:
>
>my @filepatterns=`find $subdir -n $days -type f -exec egrep $pattern {}
>\; |sed "s/somepattern/diffpattern"`
That can be fine under certain circumstances. Certainly you're using
perl as a shell script. As a general rule, though, a shell is fine for
shell scripts and perl is fine for Perl scripts. In this case what you
are doing can be done perfectly well and easily enough with File::Find
(or one of its cousins) and Perl builtins. Chances are that F::F in
and of itself may be slightly slower than egrep, which is a compiled
and supposedly efficient program. However you will avoid the overhead
of launching a process for every examined file, so things may well
balance out in the end...
>I like using the find command because I can also control how many days
>to go back in my search. I will also check Devl::DProf
You can do that in perl as well. You may want to read
perldoc -f -X
>On Dec 22, 12:15 am, Eric Schwartz <emsch...@pobox.com> wrote:
>> "Petyr David" <phyn...@gmail.com> writes:
[snip full quoted content]
*PLEASE* do not top-post!
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: 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 10095
****************************************
