[31152] in Perl-Users-Digest
Perl-Users Digest, Issue: 2397 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 6 16:09:41 2009
Date: Wed, 6 May 2009 13:09: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, 6 May 2009 Volume: 11 Number: 2397
Today's topics:
Re: Help with Net::ftp not downloading <edMbj@aes-intl.com>
Re: Help with Net::ftp not downloading <edMbj@aes-intl.com>
Re: Help with Net::ftp not downloading <edMbj@aes-intl.com>
Re: Help with Net::ftp not downloading <RedGrittyBrick@spamweary.invalid>
Re: Perl command call check <n@solenttechnology.co.uk>
Re: Perl command call check <1usa@llenroc.ude.invalid>
Re: Perl is too slow - A statement <nat.k@gm.ml>
searching directory based on csv file <Stephen.Schoenberger@gmail.com>
Re: searching directory based on csv file <1usa@llenroc.ude.invalid>
Re: searching directory based on csv file <tadmc@seesig.invalid>
Re: searching directory based on csv file <someone@example.com>
Re: searching directory based on csv file <jurgenex@hotmail.com>
Re: stackoverflow.com (was: "Perl has been pretty much <spamtrap@dot-app.org>
Re: stackoverflow.com (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 06 May 2009 07:38:06 -0700
From: Ed Jay <edMbj@aes-intl.com>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <t38305pb3u23utuu9826ep4dlkovm7v903@4ax.com>
RedGrittyBrick wrote:
>
>Ed Jay wrote:
>
>>
>> What was confusing to me was that my file manager wasn't refreshing its
>> cache, so I never saw that the file was actually being sent to the
>> script's folder.
>>
>
>It is usually a bad thing (tm) to allow the public to upload files to
>your web-servers folders in which scripts reside.
>
>There's enough ambiguity in your sentence that this may not be what is
>actually happening, but I thought it worth mentioning.
These guys aren't the public. They're subscribed clients.
Thanks for your help.
--
Ed Jay (remove 'M' to reply by email)
Win the War Against Breast Cancer.
Knowing the facts could save your life.
http://www.breastthermography.info
------------------------------
Date: Wed, 06 May 2009 07:38:57 -0700
From: Ed Jay <edMbj@aes-intl.com>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <l68305t6hhl0drn4ih9vfjb9j1ulmvdc7k@4ax.com>
A. Sinan Unur wrote:
>Ben Morrow <ben@morrow.me.uk> wrote in
>news:fh28d6-r94.ln1@osiris.mauzo.dyndns.org:
>>
>> Quoth Ed Jay <edMbj@aes-intl.com>:
>
>>> My purpose: A customer uploads 3 - 5 images to a specific folder on
>>> the server.
>>
>> 'The' server. *Which* server? (Machines have names for a reason.) In
>> particular, is this the same machine as is running the CGI, or not? If
>> it is, then Net::FTP is not going to help you one bit.
>
>Let's assume for the moment that the customer uploads the photos to the
>web server via another CGI script. Let's also assume that the images are
>stored in a directory that is not publically accessible. Finally, let's
>assume that the CGI script Ed Jay wants to write will also reside on
>this particular server and has read access to the images.
>
>>> We know how many images, their (sequentially numbered) filenames,
>>> and where they are located on the server. With a click of the mouse
>>> on my desktop machine, I want to download the images to a specific
>>> folder on my desktop,
>
>Write a script which, when invoked, will ZIP up all the image files and
>stream back that archive to the client. The user can then save the ZIP
>file containing the images in any folder on his computer.
>
>>> and when the last image has successfully finished downloading, I want
>>> to launch a specific application to view the images.
>
>Not possible. However, you can extract the images from the ZIP file.
>
>On the other hand, if the directory containing the images is publically
>accessible and you use automatic index generation by the web server
>software, you can write a batch file (to be run on the client computer)
>to download all the images to a specific folder and then invoke whatever
>image editor you want.
>
>>> Similarly, I want my customers to capture the images to a specific
>>> folder on their machine, and with a single click, upload all the
>>> images to the specific folder on the server along with data
>>> pertaining to image filenames and quantity.
>>
>> OK. Unless there is something going on you haven't told us about, you
>> *simply* *cannot* do this with a CGI script. If you want to write to
>> files and run programs on the local machine, your program needs to be
>> running on the local machine.
>
>Ditto. That just is not possible with CGI. If it were, surely online
>photo sites would have already started it. There is a reason you must
>either select each image to be uploaded individually or use a helper
>application with those sites.
>
>> It may be possible to do something involving JavaScript and lowering
>> your browser's security settings to dangerous levels. I don't know
>> anything about that, and it certainly has nothing to do with Perl.
>>
>>> >Is there some terribly good reason you can't run this program on the
>>> >machine the file is going to? It would make things much easier.
>>>
>>> Yes, there is an important reason.
>
>See, important and good are not the same things.
>
>>> If you'd care to direct me to a different, more appropriate group,
>>> please do. I thought that NET::ftp was a Perl module I'm having
>>> difficulty with, and therefore on-topic.
>
>No, you are not having difficulty with Net::FTP. You simply do not
>understand how things work. Your problem is not about, say, fixing a
>couple of bugs in the guidance system of a rocket you are building. No,
>it is about why it is hard and not a good idea to launch the rocket in
>your living room.
>
>There is a reason you are in my killfile. You are clueless when it comes
>to the basic concepts involving computers and you are resistant to
>learning.
>
My heart is broken.
--
Ed Jay (remove 'M' to reply by email)
Win the War Against Breast Cancer.
Knowing the facts could save your life.
http://www.breastthermography.info
------------------------------
Date: Wed, 06 May 2009 07:50:24 -0700
From: Ed Jay <edMbj@aes-intl.com>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <n88305p2vjnp4gvmhp7763mp2fapv102io@4ax.com>
Ben Morrow wrote:
>
>Quoth Ed Jay <edMbj@aes-intl.com>:
>> Ben Morrow wrote:
>> >Quoth Ed Jay <edMbj@aes-intl.com>:
>> >>
>> >> Yes, you are correct, and that also crossed my mind, so I created two
>> >> directories named C, one above cgi-bin and one a subdirectory of cgi-bin.
>> >> No go...same error.
>> >
>> >I'm struggling to understand here: what thought process made you think
>> >that might help? I'm not (just) being sarcastic: you clearly have some
>> >fundamental misunderstanding here, and until you resolve it there's no
>> >way you're going to make this work.
>>
>> The thought process was that if the script is looking for a C folder on
>> the server, I'd provide it.
>
>Yes, but...
>
>Even setting aside the fact the script was looking for a directory
>called "C:", not "C", *how* *exactly* did you think the files were going
>to get from the "C" directory on the server into the "C:\" directory on
>your local machine? Magic?
>
>> >> Perhaps you'd care to make another wild guess at the answer to my dilemma.
>> >> I cannot find the answer elsewhere, and I have done my due diligence.
>> >
>> >Sure... you don't understand the difference between running a program
>> >locally and requesting a webpage that happens to run a CGI the results
>> >of which happen to be displayed on your machine.
>>
>> Actually, I do understand that, but I've become so accustomed to running a
>> web app from my browser that I didn't stop to think of the consequences
>> when I decided to try NET::ftp.
>
>(It's called Net::FTP. Case is important in Perl.)
>
>You posted to Usenet before stopping to think? Around here that's
>considered rather rude.
It slipped my mind. If I wanted to be rude, some of the people who
responded to my question presented plenty of opportunity for retaliatory
abuse.
>
>Now you have stopped to think, what have you thunk? Can you see yet that
>Net::FTP can't possibly help you here?
Yes. I had a complete misunderstanding of its purpose.
>
>> >There is *no* *way* a CGI program can access the filesystem on the
>> >machine the browser is running on (in the general case). Otherwise any
>> >random website could trash all your files. If you have provided some way
>> >we don't know about, you need to say so.
>>
>> Of course, but my situation is not the general case.
>
>In what way is your situation different from the general case? Be
>specific. That is, what means have you provided, that you haven't told
>us about yet, for a process running on the webserver to get at your
>local filesystem?
It's different, because the customers are not Joe-on-the-street come and
go types. They are professionals (radiologists) who have subscribed to a
service. I provide a custom browser, image analysis software and any small
utilities needed to perform the attendant tasks, e.g., batch files, etc.
Installing Perl on the guys machine is asking for (support) trouble, as is
installing anything that needs to be configured at the local level. These
guys are adept at reading images, but never instruction manuals.
>
>> >> Should this be done under the scenario of transferring files from one
>> >> remote to another remote with no local client?
>> >
>> >No. That would require you to be running an FTP server on your local
>> >machine, and for that FTP server to be accessible to the machine running
>> >the CGI. I seriously doubt this is the case.
>> >
>> >As I asked upthread: please explain what you are trying to achieve.
>> >Which machine is running the CGI? Which machine is the file coming from?
>> >Which machine is the file going to? What channels of communication exist
>> >between these machines?
>> >
>> My purpose: A customer uploads 3 - 5 images to a specific folder on the
>> server.
>
>'The' server. *Which* server? (Machines have names for a reason.) In
>particular, is this the same machine as is running the CGI, or not? If
>it is, then Net::FTP is not going to help you one bit.
I've come to realize this is the case.
>
>> We know how many images, their (sequentially numbered) filenames,
>> and where they are located on the server. With a click of the mouse on my
>> desktop machine, I want to download the images to a specific folder on my
>> desktop, and when the last image has successfully finished downloading, I
>> want to launch a specific application to view the images.
>>
>> Similarly, I want my customers to capture the images to a specific folder
>> on their machine, and with a single click, upload all the images to the
>> specific folder on the server along with data pertaining to image
>> filenames and quantity.
>
>OK. Unless there is something going on you haven't told us about, you
>*simply* *cannot* do this with a CGI script. If you want to write to
>files and run programs on the local machine, your program needs to be
>running on the local machine.
Understood.
>
>It may be possible to do something involving JavaScript and lowering
>your browser's security settings to dangerous levels. I don't know
>anything about that, and it certainly has nothing to do with Perl.
>
>> >Is there some terribly good reason you can't run this program on the
>> >machine the file is going to? It would make things much easier.
>>
>> Yes, there is an important reason. Too lengthy to get in to.
>
>Well, you're going to have to rethink something, since under the
>constraints you've set no solution is possible.
>
>> >Note that none of this (yet) has anything to do with Perl. The answers
>> >would be the same if your CGI was written in any other language.
>> >
>> If you'd care to direct me to a different, more appropriate group, please
>> do. I thought that NET::ftp was a Perl module I'm having difficulty with,
>> and therefore on-topic.
>
>If it was Net::FTP you were having difficulty with, that would indeed be
>on-topic here. However, your problems started long before you tried to
>use Net::FTP: they started when you said to yourself 'I want to go to a
>web page and have it write random files on my local filesystem', which
>has nothing to do with Perl (or Net::FTP, or ftp in general).
>
Understood. Thanks for your help.
--
Ed Jay (remove 'M' to reply by email)
Win the War Against Breast Cancer.
Knowing the facts could save your life.
http://www.breastthermography.info
------------------------------
Date: Wed, 06 May 2009 18:40:31 +0100
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: Help with Net::ftp not downloading
Message-Id: <4a01cb90$0$2482$db0fefd9@news.zen.co.uk>
Ed Jay wrote:
> RedGrittyBrick wrote:
>
>> Ed Jay wrote:
>>
>>> What was confusing to me was that my file manager wasn't refreshing its
>>> cache, so I never saw that the file was actually being sent to the
>>> script's folder.
>>>
>> It is usually a bad thing (tm) to allow the public to upload files to
>> your web-servers folders in which scripts reside.
>>
>> There's enough ambiguity in your sentence that this may not be what is
>> actually happening, but I thought it worth mentioning.
>
> These guys aren't the public. They're subscribed clients.
>
Let's hope none of them are unethical and ever become disgruntled or
curious to see what other subscribed clients you have or forget to log
out at night. ;-)
--
RGB
------------------------------
Date: Wed, 6 May 2009 09:38:57 -0700 (PDT)
From: neilsolent <n@solenttechnology.co.uk>
Subject: Re: Perl command call check
Message-Id: <d5509dd5-9abf-416c-8c67-01d556df1c7c@z19g2000vbz.googlegroups.com>
> > I will just submit the commands and work out what happened
> > after.
>
> Well with system() or backticks, how do know if it's telling you that
> the command doesn't exist vs. exit failure?
I find $? (within the Perl process) gets set to -1, and $! is set to
something like "file not found".
Does your platform do something different ?
------------------------------
Date: Wed, 06 May 2009 18:45:38 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl command call check
Message-Id: <Xns9C0396260F27Casu1cornelledu@127.0.0.1>
neilsolent <n@solenttechnology.co.uk> wrote in news:d5509dd5-9abf-416c-
8c67-01d556df1c7c@z19g2000vbz.googlegroups.com:
>> > I will just submit the commands and work out what happened
>> > after.
>>
>> Well with system() or backticks, how do know if it's telling you that
>> the command doesn't exist vs. exit failure?
>
> I find $? (within the Perl process) gets set to -1, and $! is set to
> something like "file not found".
> Does your platform do something different ?
The documentation for the system function explains:
You can check all the failure possibilities by inspecting $?
like this:
if ($? == -1) {
print "failed to execute: $!\n";
}
elsif ($? & 127) {
printf "child died with signal %d, %s coredump\n",
($? & 127), ($? & 128) ? 'with' : 'without';
}
else {
printf "child exited with value %d\n", $? >> 8;
}
Alternatively you might inspect the value of
"${^CHILD_ERROR_NATIVE}" with the W*() calls of the POSIX
extension.
Read the rest of the documentation for potential pitfalls when the shell
is involved.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Tue, 05 May 2009 23:41:30 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl is too slow - A statement
Message-Id: <IdjMl.101$hX2.54@newsfe19.iad>
David Formosa (aka ? the Platypus) wrote:
> On Mon, 04 May 2009 17:28:11 -0700, Nathan Keel <nat.k@gm.ml> wrote:
>> David Formosa (aka ? the Platypus) wrote:
> [...]
>>> Ok your claim was "What happens when you find that the language
>>> isn't
>>> fast enough?". My responce was that this question didn't make
>>> sence. Because languages are not what is fast or slow, applications
>>> are fast and slow.
>>
>> Certain languages will run faster than others.
>
> Languages are not run, programs are run.
You're really going out of your way to be sarcastic and petty here. The
"program" is build/coded in the particular language, and this some run
faster than others. You know what I meant. It's unfortunate that I
have to spell it out so literally.
>> Precompiled languages, for example, and thus C will run faster than
>> Perl.
>
> Your at the wrong leval of abstraction. Languages are syntax and
> semantics, programs running under language implimentations may run
> faster or slower but that doesn't mean the language is faster or
> slower.
Ugh. See the above, or are you going to base your whole argument on
such a foolish semantic so you can try and appear witty?
>> So, if the slowness
>> of Perl could be remedied and be more efficient if re-worked in
>> quality C code, it could solve the problem.
>
> Most of the time slow code can be remedied by profiling the perl and
> improving the algorithm. You get far larger speed improvements from
> shifting down a class of big-O behavour then any language port.
Of course you can improve different areas of different code in different
languages, but some programs are faster, coded to do the same things in
different languages (choices).
>> Additionally, this is something
>> that can be decided in the pre development stage, is what I was
>> saying.
>
> Optimizing in predevelopement is the very definition of premature.
I didn't ever say "optimizing" in predevelopment. I said that you can
plan what language would be best to create an application in, before
you start. That was speaking directly in response to the mention of
that aspect, so don't make more out of what was said. Also, don't
reach so far to try and make your point. If you comprehend what I
said, then you've got nothing to disagree with, so enough with the
petty remarks.
------------------------------
Date: Wed, 6 May 2009 08:12:41 -0700 (PDT)
From: steve <Stephen.Schoenberger@gmail.com>
Subject: searching directory based on csv file
Message-Id: <849176ec-82cb-4261-aaac-13c8af5d8f26@z19g2000vbz.googlegroups.com>
I am a bit stumped on what should be pretty easy. I have a csv file
with filenames in it. I want to read that csv file into an array and
then parse through that array, one file at a time and search a given
directory for that filename. When (the filename will be in the
directory) that file is found it is copied from that location to
another given location.
Thanks for any help!
------------------------------
Date: Wed, 06 May 2009 15:26:26 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: searching directory based on csv file
Message-Id: <Xns9C0374604DE6Easu1cornelledu@127.0.0.1>
steve <Stephen.Schoenberger@gmail.com> wrote in news:849176ec-82cb-4261-
aaac-13c8af5d8f26@z19g2000vbz.googlegroups.com:
> I am a bit stumped on what should be pretty easy. I have a csv file
> with filenames in it. I want to read that csv file into an array and
> then parse through that array, one file at a time and search a given
> directory for that filename. When (the filename will be in the
> directory) that file is found it is copied from that location to
> another given location.
perldoc -f -X
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: Wed, 6 May 2009 11:54:15 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: searching directory based on csv file
Message-Id: <slrnh03g5n.2do.tadmc@tadmc30.sbcglobal.net>
steve <Stephen.Schoenberger@gmail.com> wrote:
> I am a bit stumped on what should be pretty easy. I have a csv file
> with filenames in it. I want to read that csv file into an array and
perldoc Text::CSV
perldoc Text::CSV_XS
> then parse through that array, one file at a time
See the "Foreach Loops" section in
perldoc perlsyn
> and search a given
> directory for that filename.
perldoc -f glob
perldoc -f opendir
perldoc -f readdir
> When (the filename will be in the
> directory) that file is found it is copied from that location to
> another given location.
perldoc File::Copy
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 06 May 2009 12:21:34 -0700
From: "John W. Krahn" <someone@example.com>
Subject: Re: searching directory based on csv file
Message-Id: <1rlMl.5242$%_2.1886@newsfe04.iad>
steve wrote:
> I am a bit stumped on what should be pretty easy. I have a csv file
> with filenames in it. I want to read that csv file into an array and
> then parse through that array, one file at a time and search a given
> directory for that filename. When (the filename will be in the
> directory) that file is found it is copied from that location to
> another given location.
>
> Thanks for any help!
This is an example of what may work for you but it is UNTESTED:
#!/usr/bin/perl
use warnings;
use strict;
use File::Copy;
my $csv_file = 'file.csv';
my $search_dir = 'some/dir';
my $new_dir = 'some/where/else';
open my $CSV, '<', $csv_file or die "Cannot open '$csv_file' $!";
while ( <$CSV> ) {
chomp;
my $file = ( split /,/ )[ 3 ]; # file name is the fourth field
if ( -e "$search_dir/$file" ) {
copy( "$search_dir/$file", "$new_dir/$file" ) or die "Cannot
copy '$search_dir/$file' $!";
}
}
close $CSV;
__END__
John
--
Those people who think they know everything are a great
annoyance to those of us who do. -- Isaac Asimov
------------------------------
Date: Wed, 06 May 2009 13:06:55 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: searching directory based on csv file
Message-Id: <g7r305p455n8ksf5s38vvv798ch1sc8h5u@4ax.com>
>steve wrote:
>> I am a bit stumped on what should be pretty easy. I have a csv file
>> with filenames in it. I want to read that csv file into an array
There are several modules on CPAN which handle CSV quite nicely,
including all the oddities of CSV like quotes and escapes. No need to
reinvent the wheel.
>>and
>> then parse through that array, one file at a time
perldoc perlsyn, check for the 'for' loop
>>and search a given
>> directory for that filename. When (the filename will be in the
>> directory) that file is found
perldoc -f -X
>>it is copied from that location to
>> another given location.
perldoc File::Copy
Which part do you have trouble with?
jue
------------------------------
Date: Wed, 06 May 2009 09:54:32 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: stackoverflow.com (was: "Perl has been pretty much forgotten" says Spolsky)
Message-Id: <m1ocu68hgn.fsf@dot-app.org>
Ben Bullock <benkasminbullock@gmail.com> writes:
> [This is a repost since I believe the previous post of this failed.
> Please excuse me if you have seen this before.]
>
> On Tue, 05 May 2009 04:22:43 -0500, brian d foy wrote:
>
>> A lot of answers are less than thoughtful and lacking in experience,
>> but the Perl section has been doing very nicely. There are some very
>> clueful Perl people who answer most of the questions, but once in a
>> while there's a lull where a newbie will pop his head up before one of
>> those people can get there.
>
> Let's be clear what stackoverflow.com is. The site is set up as a
> programming question "video game" where you're awarded "reputation"
> points for answering questions.
Precisely! I spent maybe two months on that site. That was long enough
to see many patently incorrect "answers" get voted up and even "accepted,"
and to realize that the site is just a popularity contest. As a technical
resource, it's as useless as slashdot.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Wed, 06 May 2009 07:25:52 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: stackoverflow.com
Message-Id: <86ws8ujojz.fsf@blue.stonehenge.com>
>>>>> "Sherm" == Sherm Pendley <spamtrap@dot-app.org> writes:
>> Let's be clear what stackoverflow.com is. The site is set up as a
>> programming question "video game" where you're awarded "reputation"
>> points for answering questions.
Sherm> Precisely! I spent maybe two months on that site. That was long enough
Sherm> to see many patently incorrect "answers" get voted up and even
Sherm> "accepted," and to realize that the site is just a popularity
Sherm> contest. As a technical resource, it's as useless as slashdot.
It's like a really poor imitation of perlmonks.org, which has taken *years* of
tuning to get the right mix of points, editors, questions, answers,
troll-response, searching, sorting and so on. Why people think they can start
over without the benefit of a decade of experience on that, not sure.
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/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
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 2397
***************************************
