[30793] in Perl-Users-Digest
Perl-Users Digest, Issue: 2038 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Dec 6 21:10:05 2008
Date: Sat, 6 Dec 2008 18:09:26 -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 Sat, 6 Dec 2008 Volume: 11 Number: 2038
Today's topics:
Re: a simple control in an nntp client sln@netherlands.com
Re: Array initialization and @ARGV <rvtol+news@isolution.nl>
Re: Array initialization and @ARGV <tadmc@seesig.invalid>
Re: Array initialization and @ARGV <vt@vt.com>
Re: FAQ 8.44 How do I tell the difference between error <hjp-usenet2@hjp.at>
Re: how detect english subject and predicate in a sente <hjp-usenet2@hjp.at>
Re: how detect english subject and predicate in a sente <hjp-usenet2@hjp.at>
Re: how detect english subject and predicate in a sente <cwilbur@chromatico.net>
Re: Noob trying to understand simple Perl grep statemen <walterbyrd@iname.com>
Re: Noob trying to understand simple Perl grep statemen sln@netherlands.com
Re: perl segfault - how to troubleshoot sln@netherlands.com
Re: sysread and syswrite analogy <hjp-usenet2@hjp.at>
Re: sysread and syswrite analogy sln@netherlands.com
Re: sysread and syswrite analogy xhoster@gmail.com
Re: Why would it appear to my scripts that a server the <bill@ts1000.us>
Re: Why would it appear to my scripts that a server the <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 07 Dec 2008 00:45:19 GMT
From: sln@netherlands.com
Subject: Re: a simple control in an nntp client
Message-Id: <427mj4d9eql4v99988li1liu4uhtk0vatq@4ax.com>
On Fri, 5 Dec 2008 01:33:47 -0700, George <george@example.invalid> wrote:
>On Fri, 05 Dec 2008 03:57:42 GMT, sln@netherlands.com wrote:
>
>> On Thu, 4 Dec 2008 14:13:27 -0700, George <george@example.invalid> wrote:
>>
>>>
>>>I would like to extend the following script:
>>>
>> Have you thought of 'extension' courses?
>>
>> sln
>
>No, but your response makes me recall fondly the moments when I used to
>throw eurotrash around. Typ.
>--
>George
>
>I believe that God has planted in every heart the desire to live in
>freedom.
>George W. Bush
>
>Picture of the Day http://apod.nasa.gov/apod/
Typical George W. Bush fan.
sln
------------------------------
Date: Sat, 6 Dec 2008 13:26:22 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Array initialization and @ARGV
Message-Id: <ghdulc.1mg.1@news.isolution.nl>
vt schreef:
> Is it possible to initialize an array with numeric values
> specified as command line parameters that utilize the range
> operator?
There are several modules for that, see CPAN.
> C:\perl test_script.pl 1..5,30
Alternative syntax:
test_script.pl 1-5,30
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Sat, 6 Dec 2008 07:24:01 -0600
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Array initialization and @ARGV
Message-Id: <slrngjkv7h.ig0.tadmc@tadmc30.sbcglobal.net>
vt <vt@vt.com> wrote:
> Is it possible to initialize an array with numeric values specified as
> command line parameters that utilize the range operator?
>
> C:\perl test_script.pl 1..5,30
>
> with test_script.pl containing
>
> #!c:\perl\bin\perl
Insert this line here:
$ARGV[0] =~ s/(\d+)\.\.(\d+)/ join ',', $1 .. $2 /ge;
> @array1 = split ',', $ARGV[0];
>
> exit;
Errr, a program that makes no output is not very useful...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Sat, 06 Dec 2008 10:03:58 -0600
From: vt <vt@vt.com>
Subject: Re: Array initialization and @ARGV
Message-Id: <Xns9B6C6659DD752vtvtcom@127.0.0.1>
Thanks to all for the feedback.....
vt.
------------------------------
Date: Sat, 6 Dec 2008 13:08:12 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 8.44 How do I tell the difference between errors from the shell and perl?
Message-Id: <slrngjkqpd.23b.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-02 23:27, Eric Pozharski <whynot@pozharski.name> wrote:
> On 2008-12-02, Josef Moellers <josef.moellers@fujitsu-siemens.com> wrote:
>> Bill H wrote:
>>> On Dec 1, 9:03 pm, PerlFAQ Server <br...@stonehenge.com> wrote:
>>>
>>>> Consider this script, which has an error you may not notice immediately.
>>>>
>>>> #!/usr/locl/bin/perl
>>>>
>>>> print "Hello World\n";
>>>>
>>>> I get an error when I run this from my shell (which happens to be bash).
>>>> That may look like perl forgot it has a print() function, but my shebang
>>>> line is not the path to perl, so the shell runs the script, and I get
>>>> the error.
>>>
>>> Ok maybe I need another cup of coffee, but what is the error?
>>
>> IIUC:
>>
>> -bash: print: command not found
No.
./test: line 3: print: command not found
(its just below the quoted paragraph - Bill would just have read 2 more
lines to see it)
>> -bash: ./hello.pl: /usr/local/bin/perl: bad interpreter: No such file or
>> directory
>>
>> which is not what the FAQ says. So this does not apply to all shells.
>
> What even worst it doesn't apply to some environments:
>
> Warning: unknown mime-type for "Hello World\n" -- using
> "application/octet-stream"
That's just another symptom of the same problem: The script is not
interpreted by the perl interpreter, so the error message doesn't come
from perl itself, but the environment. It depends on the environment
whether this error message can be clearly attributed to the environment
("-bash: ./hello.pl: /usr/local/bin/perl: bad interpreter: No such file
or directory" is clearly a message from bash, not from perl, but for
"print: command not found" or "Warning: unknown mime-type ..." this is
much less clear). So this FAQ demonstrates a way to make perl messages
easily recognizable.
The whole point of that FAQ is that different environments behave
differently. So it's not "worse" that you get a different error message
than Josef, it proves the point.
On a related note, I have a minor peeve with "die": The normal
convention of error messages in unix is to print the name of the program
first:
-bash: ./hello.pl: /usr/local/bin/perl: bad interpreter: No such file or directory
chmod: cannot access `foo': No such file or directory
...
But die writes the name at the end:
cannot open bla: No such file or directory at ./foo line 2.
which makes it hard to see at first glance.
./foo: line 2: cannot open bla: No such file or directory
would be much more unixy.
hp
------------------------------
Date: Sat, 6 Dec 2008 22:13:44 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how detect english subject and predicate in a sentence
Message-Id: <slrngjlqoa.7qf.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-04 22:10, Charlton Wilbur <cwilbur@chromatico.net> wrote:
>>>>>> "SB" == Scott Bryce <sbryce@scottbryce.com> writes:
>
> SB> Jack wrote:
>
> >> I want to know the topical NOUN of the sentence. Not nouns that
> >> happen to supplement elsewhere in the sentence. In "fruit flies
> >> like a banana" - the key or topical noun is 'fruit' NOT banana
> >> yet both are nouns...just 1 example.
>
> SB> This is an example which points out how difficult the task
> SB> is. "Fruit" is NOT the topic of the sentence. "flies"
> SB> is. "Fruit" tells us what type of flies like bananas.
>
> Actually, the sentence can be read *correctly* in two incompatible ways.
> You can read "Fruit flies" as the subject, and "like a banana" as the
> predicate, or "Fruit" as the subject, and "flies like a banana" as the
> predicate. Both readings are correct.
Only syntactically. I am not an expert in the aerodynamic properties of
fruit, but I would imagine that a banana with its elongated, curved form
flies rather differently than an apple or a coconut. So the
generalization is false or at least questionable. And if it was intended
as a generalization it would probably have been worded "*all* fruit
flies like a banana." On the other hand, it is common knowledge that
fruit flies do like bananas. So the interpretation ((fruit) (flies) (like
a banana)) is rather unlikely (and I'm rather astonished that Jack made
that mistake, especially given the context).
> Structurally, it's identical to the former sentence in the statement:
> "Time flies like an arrow." But because there is no such thing as a
> "time fly," there's only one reading that makes sense.
Well, there could be. It doesn't even have to be an insect. Maybe
there's a rock band "The Time Flies". And maybe they like Italian
motorcycle parts ...
> In other words, you can't determine what the subject of the sentence is
> without knowledge of the semantic content.
Right. It's knowledge about the real world (including common figures of
speech) which makes the ((fruit flies) (like) (a banana)) a much more
likely interpretation than ((fruit) (flies) (like a banana)), and which
makes ((time) (flies) (like an arrow)) much more likely than ((time
flies) (like) (an arrow)).
hp
------------------------------
Date: Sat, 6 Dec 2008 22:20:10 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how detect english subject and predicate in a sentence
Message-Id: <slrngjlr4b.7qf.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-05 02:09, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>Charlton> Consider: "Time flies like an arrow. Fruit flies like a banana."
[...]
>
> Keep in mind, the second sentence has *three* interesting interpretations:
[...]
> (3) You are instructed to attack some flies by throwing fruit at them.
> Do this as a banana might do it.
Merriam Webster's doesn't know about this meaning of the verb "fruit".
Instead is lists "to bear fruit". And as anyone who has left an overripe
banana lying around, it does seem to "fruit flies" (people used to
believe that low life like insects can develop directly from inanimate
matter). So "fruit flies like a banana!" might be some especially nasty
curse. Eew!
hp
------------------------------
Date: Sat, 06 Dec 2008 17:25:09 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: how detect english subject and predicate in a sentence
Message-Id: <86r64lq6uy.fsf@mithril.chromatico.net>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>> Actually, the sentence can be read *correctly* in two
>> incompatible ways. You can read "Fruit flies" as the subject,
>> and "like a banana" as the predicate, or "Fruit" as the subject,
>> and "flies like a banana" as the predicate. Both readings are
>> correct.
PJH> Only syntactically.
You're trying to make a distinction between the reading of the sentence
conveying information (in which sense both readings are correct) and the
reading of the sentence conveying factually true information.
This is a level removed from correctly parsing the sentence.
For instance, given the sentence "Tokyo is the capital of
Massachusetts," the correct reading of the sentence is factually wrong.
This does not make it grammatically incorrect or even grammatically
ambiguous.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sat, 6 Dec 2008 09:07:27 -0800 (PST)
From: walterbyrd <walterbyrd@iname.com>
Subject: Re: Noob trying to understand simple Perl grep statement
Message-Id: <4ca4e8c7-db3c-4dee-adb8-aa858856de61@d42g2000prb.googlegroups.com>
On Dec 3, 3:05=A0pm, s...@netherlands.com wrote:
> I don't know what book that is but it looks like you are trying
The book is called: "Learning Perl Objects, References, and Modules."
The book is supposed to pick up where "Learning Perl" left off. I read
"Learning Perl" and consider it to be a great book.
I found out the book has been updated, the new book is called
"Intermediate Perl" so I got the new book.
I am presently trying to read, and understand, the stuff about
referencing, and de-referencing, arrays. And it is giving me a serious
headache.
------------------------------
Date: Sun, 07 Dec 2008 01:28:12 GMT
From: sln@netherlands.com
Subject: Re: Noob trying to understand simple Perl grep statement
Message-Id: <3k8mj4l2be0vedpsd1mhbklqbmucg11ir6@4ax.com>
On Sat, 6 Dec 2008 09:07:27 -0800 (PST), walterbyrd <walterbyrd@iname.com> wrote:
>On Dec 3, 3:05 pm, s...@netherlands.com wrote:
>
>> I don't know what book that is but it looks like you are trying
>
>The book is called: "Learning Perl Objects, References, and Modules."
>The book is supposed to pick up where "Learning Perl" left off. I read
>"Learning Perl" and consider it to be a great book.
>
>I found out the book has been updated, the new book is called
>"Intermediate Perl" so I got the new book.
>
>I am presently trying to read, and understand, the stuff about
>referencing, and de-referencing, arrays. And it is giving me a serious
>headache.
I wouldn't think too hard on references. Its actually the 'syntax' for
de-referencing in the doc's that makes most readers candidates for thorozine.
The Perl universe is so cluttered with 'meta' it makes deciphering code almost
impossible. The reason boils down to one thing: "One-liners". Yep, the little thing
penchant Perl fanatics drivel over and one-up each other with.
In reality, it is so busy because some dope decided to let people think short
contractions with 'meta' will give some other dope the illusion his/her code
is not only spiffy and unintelligable, but (this is the worst) will somehow
magically run faster. Emacs on steriods, but let's let it be syntactically
part of the language.
Hey well, give enough rope, get a good hanging.
References are very easy if you don't read too much into it.
Keep at it and good luck!
sln
------------------------------
Date: Sun, 07 Dec 2008 01:56:03 GMT
From: sln@netherlands.com
Subject: Re: perl segfault - how to troubleshoot
Message-Id: <3tamj49n93gefbrrh33ou62knis17i7nqp@4ax.com>
On Thu, 04 Dec 2008 16:49:01 GMT, sln@netherlands.com wrote:
>On Wed, 3 Dec 2008 13:44:00 -0800 (PST), James Harris <james.harris.1@googlemail.com> wrote:
>
>>On 3 Dec, 17:06, xhos...@gmail.com wrote:
>>...
>>> > Does this mean that the segfault occurred as a result of the close(8)
>>> > call - or at least that close() was the last system call prior to the
>>> > fault?
>>>
>>> No to the first--close(8) completed successfully before the segfault.
>>> Yes to the second, close(8) was the last system call prior to the fault.
>>> So the fault probably occurred in "user space".
>>
>>To follow up on this, I shut the machine down and ran memtest86+ to
>>check the ram. That checked out OK for all tests.
>>
>>On restart, however, problems with at disk partitions were found. The
>>problems reported included
>>
>>* Block bitmap differences
>>* Free inode counts wrong
>>* (Most alarming) Buffer I/O errors from which one can only a) ignore
>>and b) force rewrite
>>* (Most relevant, perhaps, as it relates to Perl's Socket.so though
>>not directly):
>>
>>/usr/lib/perl/5.8.8/auto/Socket/Socket.so.dpkg-tmp mod time Nov 27,
>>2007
>> has 2 multiply-claimed blocks shared with 0 files
>>
>>I spent a while running through the reported problems and then let (e2)
>>fsck do the rest. It took some time but on subsequent reboot the Perl
>>problem had gone away. I expected to have to reinstall Socket.so at
>>least but so far it seems to be OK now. As scripts run I'll keep an
>>eye on them. Hopefully they will all work now.
>>
>>I've added a Linux group because this has led to other queries:
>>
>>1. Is there a way to tell what file systems are corrupt while the
>>machine is running normally? - I.e. was Linux (Ubuntu) telling me of
>>the faults somewhere?
>>2. If it was where does it report this?
>>3. If it wasn't why not??? Fsck knew of faults on some of the file
>>systems on bootup without having to scan the disks for them. If it
>>knows there why not report it sooner?
>>
>>Thanks to all in the Perl group for the education in debugging tools.
>>I'll find other uses for them.
>>
>>James
>
>I take it you hardly ever shut down/reboot. Every OS seems to do at
>least a checksum on the file structure tables (without doing a file
>scan) on boot-up.
>
>If all you do is run a particular software all the time, odds are
>disk/memory problems manifest in those areas of the disk producing
>wild crazy cascading errors .. A typical indication of hardware fatigue.
>
>Replace the whole machine if it is old.
>Otherwise, some things to try:
>
>* Run memtest for 24 straight hours, all tests.
>* Stress test the cpu/ram, monitoring temperature.
> Windows has ORTHOS and Core Temp 94.
>* Stress test the disks. Windows has Everest Ultimate.
>* Do a full scan on the IDE drives checking for bad physical
> sectors.
>* Repartition/format and move the software used most frequently
> to a new area on the disk. This includes temporary files it
> might create, to a new area.
>
>
I just want to add. Between software installs, defragment the disk
so that they are are on continuous sectors. Delete temporary files
after they are no longer needed. Defragment before and after upgrades,
etc. This will lengthen the life of your drive(s) as its arm will not
have to be subject to excessive physical 'jerk' when seeking data in
excessively scatterred patterns.
Good luck!
sln
------------------------------
Date: Sat, 6 Dec 2008 12:31:54 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: sysread and syswrite analogy
Message-Id: <slrngjkola.23b.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-04 19:58, xhoster@gmail.com <xhoster@gmail.com> wrote:
> For file handles that don't have O_NONBLOCK turned on, I see this
> behavior:
>
> sysread will return partial reads (fewer bytes than were requested), rather
> than blocking, provided that the partial read is at least one byte.
>
> syswrite will not perform partial writes, but rather it will block waiting
> for the entire write to be accepted.
>
> Based on sysread's behavior, I would have expected syswrite to return
> immediately with a partial write, provided that at least one character was
> written. Why the lack of analogy between the two?
I can see two reasons:
For a read operation, you typically cannot know how many bytes you need
to read (when Unix was developed, non-file input was from line oriented
terminals. Many network protocols are also line oriented). Blocking
until a fixed number of bytes are read is just impossible. (Imagine a
shell where you always need to type exactly 80 bytes for each command).
Reading single characters was considered too CPU intensive. Hence
read(2) returns as soon as possible. For write otoh, you always know
exactly, how many bytes need to be written. The program typically cannot
do anything else until that operation is finished (and it won't block
anyway because the write just copies the data into an OS buffer). So a
partial write wasn't considered desirable.
Both read and write are supposed to be atomic (they often aren't in
reality, but that's what the Unix programmer expects). For read a
partial read *helps* maintaining atomicity. If your read buffer is
larger than the largest write request, each read will normally return a
single (or an integral number) of records. And even if your buffer is
smaller, you can usually safely read the rest. But for write, it destroys
atomicity: You have just written a partial record, now you need to write
the rest and in the meantime somebody else could write another (partial)
record into the middle of your record. So partial writes are more
problematic than partial reads.
Of course some assumptions from the 1970's don't hold any more, and some
system calls which were added later don't fit nicely into this model.
Especially select(2) is problematic, because it just tells you that you
can write without blocking, but not how much you can write without
blocking. So either you need to write in 1-byte chunks or you need to
use a non-blocking file descriptor.
hp
------------------------------
Date: Sat, 06 Dec 2008 23:37:34 GMT
From: sln@netherlands.com
Subject: Re: sysread and syswrite analogy
Message-Id: <cn2mj41an7afg0qp9rnegfffhts7uo25p2@4ax.com>
On 05 Dec 2008 17:05:59 GMT, xhoster@gmail.com wrote:
>sln@netherlands.com wrote:
>
>> Am I missing something here? Level I and level II with regard to i/o?
>> I thought syswrite/sysread were Level I i/o.
>
>What are "Level I" and "Level II" I/O? AFAICT, these terms are not used
>in the Perl docs, or the Linux man pages. They seem to be part of your own
>private language.
>
>
>Xho
You must be too young and inexperienced to know what Level I/II I/O is.
It was later changed to unbuffered/buffered I/O. The 'I' Roman Numberal being
'Lower' than the 'II' Roman Numeral. Hence 'Low-Level' I/O, conversely what,
'High-Level' I/O ??
What, there is no 'High-Level' I/O ?? Where did 'Low-Level' I/O come from ??
What the hell does 'Level' mean to you ??
And are you saying Perl does its own I/O ?? Well, I'm not suprised since I found
out Perl does its own floating point conversions.
Sounds like Perl justs RE-INVENTS the wheel all the time partner.
Grow up sonny !
sln
------------------------------
Date: 06 Dec 2008 23:57:24 GMT
From: xhoster@gmail.com
Subject: Re: sysread and syswrite analogy
Message-Id: <20081206185620.764$mE@newsreader.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
...
> Of course some assumptions from the 1970's don't hold any more, and some
> system calls which were added later don't fit nicely into this model.
> Especially select(2) is problematic, because it just tells you that you
> can write without blocking, but not how much you can write without
> blocking. So either you need to write in 1-byte chunks or you need to
> use a non-blocking file descriptor.
Thanks for the useful discussion. I'm used to Perl protecting me from
such underlying system anachronisms. But in this case I guess I don't see
how it could unless it were to automatically set O_NONBLOCK for me, which
would probably be going a bit too far.
Thankfully IO::Handle->blocking() makes it almost unnecessary to manually
use the nightmare which is fcntl.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Sat, 6 Dec 2008 14:57:09 -0800 (PST)
From: Bill H <bill@ts1000.us>
Subject: Re: Why would it appear to my scripts that a server they're connecting to has gone away (using Net::FTP and LWP)
Message-Id: <a779c0df-7030-445d-8fb1-9ec09e8f4db3@k36g2000yqe.googlegroups.com>
On Dec 5, 1:23=A0am, Ted Byers <r.ted.by...@gmail.com> wrote:
> Here is the interesting part of the log for my script that uses
> NET::FTP:
>
> Copying 44 files
> Net::FTP=3DGLOB(0x3e18a04)>>> TYPE I
> Net::FTP=3DGLOB(0x3e18a04)<<< 200 Type set to I
> Status: 2
>
> C_MerchantData_ALT_Work.2008-11-12.zip
> Net::FTP=3DGLOB(0x3e18a04)>>> ALLO 5062889
> Net::FTP=3DGLOB(0x3e18a04)<<< 202 No storage allocation neccessary.
> Net::FTP=3DGLOB(0x3e18a04)>>> PORT 10,1,10,124,7,5
> Net::FTP=3DGLOB(0x3e18a04)<<< 200 Port command successful
> Net::FTP=3DGLOB(0x3e18a04)>>> STOR C_MerchantData_ALT_Work.
> 2008-11-12.zip
> Net::FTP=3DGLOB(0x3e18a04)<<< 150 Opening data channel for file
> transfer.
> Net::FTP=3DGLOB(0x3e18a04): Timeout at C:/Perl/site/lib/Net/FTP/
> dataconn.pm line 7
> 4
> Status: 1
>
> C_MerchantData_ALT_Work.2008-11-13.zip
> Net::FTP=3DGLOB(0x3e18a04)>>> ALLO 5299854
> Net::FTP: Unexpected EOF on command channel at C:\backup
> \copy.backups.to.T.O.pl
> line 48
> Status: 5
>
> Qualitatively, it looks like only one zip archive is tranfered (and my
> colleagues in TO can open them and verify the contents), and then the
> ftp session seems to go away and there is no more interaction with the
> ftp server.
>
> Here is the interesting part of a log created (LWP::DebugFile):
>
> Here is the last bit pertaining to the download that occured just
> before the failed dowwnload:
> LWP::Protocol::http::request: ()
> # Time now: {1228452248} =3D Thu Dec =A04 23:44:08 2008
> LWP::UserAgent::request: Simple response: OK
>
> # LWP::DebugFile logging to lwp.log
> # Time now: {1228452249} =3D Thu Dec =A04 23:44:09 2008
> LWP::UserAgent::new: ()
> LWP::UserAgent::request: ()
>
> ignoring the URL requested (it doesn't matter because if I select a
> temporal interval involving a few kbytes of data, all works fine),
> here is what follows:
>
> .LWP::Protocol::http::request: ()
> # Time now: {1228452869} =3D Thu Dec =A04 23:54:29 2008
> LWP::UserAgent::request: Simple response: Internal Server Error
>
> # LWP::DebugFile logging to lwp.log
> # Time now: {1228452870} =3D Thu Dec =A04 23:54:30 2008
> LWP::UserAgent::new: ()
> LWP::UserAgent::request: ()
>
> I find it interesting to observe that simply including use of
> LWP::DebugFile is sufficient to prevent the script from freezing or
> locking up. =A0Instead, an error like this is logged and the script
> proceeds to the next request. =A0The error shown above happens in the
> middle of the download, and in this run, this is the only download
> that failed.
>
> Questions:
>
> 1) How do I get more information from LWP::DebugFile? =A0Or is there any
> more information to be had?
> 2) I'd also included the following statements:
>
> use Log::Trace;
> use Log::Trace 'print';
> use Log::Trace log =3D> 'master.generic.download.trace.log';
> use Log::Trace warn =3D> { Deep =3D> 1, Everywhere =3D> 1, Verbose =3D> 2=
};
>
> But I did not get any log from Log::Trace. =A0i must have missed
> something, but what?
>
> 3) The information I'm getting from Net::FTP seems fine, except I have
> yet to find the documentation for what the status codes (returned by
> the status function) mean. =A0(I found curl, but haven't had time to
> compile and run it on the same files). =A0Where will I find a more
> complete description of these status codes?
>
> 4) Most importantly of all, why do these transfers fail and what can
> be done about them?
>
> Thanks
>
> Ted
Ted, not sure if this may be your problem but I had an issue with
NET::Ftp earlier this year. I have a script that runs as a cron job
and uses ftp to transfer files from a clients web server to their
interanl server. It had always worked great, then we upgraded the
server and it would never connect and just get timeout warnings, even
though I could connect from my own machine perfectly fine. It took me
a day or so to determine that the upgraded server was not allowing the
outgoing ftp connection because the destination server was an IP
address. After I setup a DNS for it and used a domain name in the
connection, it started working just fine again.
Bill H
------------------------------
Date: Sat, 6 Dec 2008 22:33:06 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why would it appear to my scripts that a server they're connecting to has gone away (using Net::FTP and LWP)
Message-Id: <slrngjlrsj.7qf.hjp-usenet2@hrunkner.hjp.at>
On 2008-12-05 22:47, Ted Byers <r.ted.byers@gmail.com> wrote:
> Thanks Tim. I appreciate this. As I am working on this with a
> colleague who has physical access to the nearest machine, we'll be
> able to check the logs Monday when he's back in the office. Like I
> said, these machines are behind strict firewalls, so there is limited
> connectivity to the outside world. For example, the ftp server is
> configured to accept connections only from with the LAN behind the
> firewall and from the machine running my script. Otherwise, this
> machine has no contact to the outside world at all. I wonder if the
> firewall or router may be an issue?
FTP is nasty for firewalls. It opens a seperate connection for each file
transfer, from and to essentially random ports, and in different
directions (in "active mode" the server connects back to the client, in
"passive mode" the server expects a connection from the client). Your
log file snippet suggests that you are using active mode and that the
server isn't able to connect back to your client. Try passive mode
instead. Are these transfers already done manually? If so, check the
settings and behaviour of the ftp client. And ask the firewall admin
about the details for ftp access.
hp
------------------------------
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 2038
***************************************
