[24139] in Perl-Users-Digest
Perl-Users Digest, Issue: 6333 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 29 18:05:38 2004
Date: Mon, 29 Mar 2004 15:05:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 29 Mar 2004 Volume: 10 Number: 6333
Today's topics:
Re: [OT] Text editors (religious war awaits) (was Re: (David Combs)
Re: Deleting old files in windows 2000 using Perl (Steve The Geek)
Hashes of arrays <a@b.c>
Re: Hashes of arrays <mothra@nowhereatall.com>
Re: Hashes of arrays <noreply@gunnar.cc>
Re: Hashes of arrays <a@b.c>
Re: Hashes of arrays <noreply@gunnar.cc>
how to pattern match \d in a variable? (nickelstat)
Re: how to pattern match \d in a variable? <noreply@gunnar.cc>
Re: life time of $1? (Myron Turner)
Re: life time of $1? (Myron Turner)
Re: life time of $1? <tadmc@augustmail.com>
Re: Loss of privledges in a perl app <perlcdr@mail.rumania>
Re: Lost data on socket - Can we start over politely? (Vorxion)
Re: Lost data on socket - Can we start over politely? (Vorxion)
Re: Lost data on socket - Can we start over politely? (Vorxion)
Re: Lost data on socket - Can we start over politely? <tassilo.parseval@rwth-aachen.de>
Re: LWP cookies (RJB)
Re: New module: Array::Each <bmb@ginger.libs.uga.edu>
Re: Performance issues with LWP? <postmaster@castleamber.com>
Re: Perl Programmer Wanted for Games Web Site Developme <dha@panix.com>
Re: Regex match for one and only one occurrence of a pa <remorse@partners.org>
Re: Regex match for one and only one occurrence of a pa <ittyspam@yahoo.com>
Re: Regex match for one and only one occurrence of a pa <skuo@mtwhitney.nsc.com>
Re: split string to chars <uri.guttman@fmr.com>
Re: Testing PHP script using Test::Simple perl script (Jimmy Jacobson)
Re: Text editor implemented in Perl (David Combs)
Writing to STDIN (Hobbit HK)
Re: Writing to STDIN (Walter Roberson)
Re: Writing to STDIN <xxala_qumsiehxx@xxyahooxx.com>
Re: Writing to STDIN <ittyspam@yahoo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Mar 2004 22:20:09 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: [OT] Text editors (religious war awaits) (was Re: Text editor implemented in Perl)
Message-Id: <c4a7ep$f83$1@reader1.panix.com>
In article <va49i1-vr7.ln1@espresso.tdegruyl.com>,
Todd de Gruyl <todd@tdegruyl.com> wrote:
>Brad Baxter wrote:
>> On Fri, 12 Mar 2004, J Krugman wrote:
>>
>>>What makes vim so much better than Emacs?
>
>> Ever since IBM destroyed WordStar (for me) by relocating the Ctrl key,
>> I've had an aversion to Ctrl key combinations--it's a carpal tunnel
>> problem. At a key point, I bit the bullet and worked at wrapping my mind
>> and fingers around vi. Now it's second nature, and having to edit text
>> with anything else makes me feel quadriplegic.
>>
>
>Recently, I have been going through a bout of wrist-related RSI's, so I
>had to move from Emacs to an editor that did not need me to contort my
>hand so much.
At least try a "unix style" keyboard -- one that has the
control-key just to the left of "A".
Holding down control when it's located there is *VASTLY* easier,
ZERO contortion required, than down where it's located
on PC-style keyboards, which I find actually *painful*, having
to contort my left-pinky angled south-south-west, which the
pinky-bones are absolutely *not* designed to do.
Where to get such a keyboard? Sun sells both kinds for plugging
into a pc-style socket.
Give it a try.
David
------------------------------
Date: 29 Mar 2004 11:14:17 -0800
From: slkleine@hotmail.com (Steve The Geek)
Subject: Re: Deleting old files in windows 2000 using Perl
Message-Id: <863f122c.0403291114.138a49e7@posting.google.com>
avindia@indiya.com (Avinash) wrote in message news:<fe5e1363.0403290757.650e4d75@posting.google.com>...
> Hi,
> is someone have perl script wrote to delete files older than 30 days
> from diffrent diffretent folders in windows 2000 or similar.
> Or some one can guide any URL which can help me to write one.
Google is your friend, is my advice.
I entered this into google:
perl script delete windows 2000 files older than 30 days
And got dead-on hits.
Steve the Geek
------
If they hear, they do not listen.
If they listen, they do not understand.
If they understand, they do not *Obey*.
------------------------------
Date: Mon, 29 Mar 2004 21:21:28 +0000 (UTC)
From: Me <a@b.c>
Subject: Hashes of arrays
Message-Id: <slrnc6h4qo.vtg.a@haddieweel.inf.ed.ac.uk>
I want to make an associative array containing arrays rather
than scalar values, and I've been trying to do it like this:
@xxx("a") = (4, 3, 6);
@xxx("b") = (7, 6, 8);
@xxx("c") = (1, 4, 3);
@xxx("d") = (0, 5, 2);
However, when I try to get the array back out of the hash, perl
just gives me the first value of the array, e.g. if I do:
while (($key, @values) = each %xxx) {
print ("$key: @values\n");
}
I'd get:
a: 4
b: 7
c: 1
d: 0
How do I get the full array back out?
------------------------------
Date: Mon, 29 Mar 2004 13:46:29 -0800
From: "Mothra" <mothra@nowhereatall.com>
Subject: Re: Hashes of arrays
Message-Id: <4068979b$1@usenet.ugs.com>
Me wrote:
> I want to make an associative array containing arrays rather
> than scalar values, and I've been trying to do it like this:
>
> @xxx("a") = (4, 3, 6);
> @xxx("b") = (7, 6, 8);
> @xxx("c") = (1, 4, 3);
> @xxx("d") = (0, 5, 2);
>
> However, when I try to get the array back out of the hash, perl
> just gives me the first value of the array, e.g. if I do:
>
> while (($key, @values) = each %xxx) {
> print ("$key: @values\n");
> }
>
> I'd get:
> a: 4
> b: 7
> c: 1
> d: 0
>
> How do I get the full array back out?
use strict;
use warnings;
my %xxx =();
$xxx{a} = [4,3,6];
$xxx{b} = [7,6,8];
while (my ($key, $value) = each %xxx) {
print $key;
print map {$_} @$value;
}
hope this helps
Mothra
------------------------------
Date: Mon, 29 Mar 2004 23:42:17 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hashes of arrays
Message-Id: <c4a59d$2g9d51$1@ID-184292.news.uni-berlin.de>
Me wrote:
> I want to make an associative array containing arrays rather
> than scalar values, and I've been trying to do it like this:
>
> @xxx("a") = (4, 3, 6);
> @xxx("b") = (7, 6, 8);
> @xxx("c") = (1, 4, 3);
> @xxx("d") = (0, 5, 2);
Then I suggest that you start learning the basics about data
structures in Perl, for instance by studying
http://www.perldoc.com/perl5.8.0/pod/perldsc.html
After that you may be ready to give it a *serious* try, and if you
would encounter problems when doing so, you are welcome back here.
Also, please work with strictures and warnings enabled.
use strict;
use warnings;
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 29 Mar 2004 21:50:30 +0000 (UTC)
From: Me <a@b.c>
Subject: Re: Hashes of arrays
Message-Id: <slrnc6h6h6.vtg.a@haddieweel.inf.ed.ac.uk>
In article <4068979b$1@usenet.ugs.com>, Mothra wrote:
> use strict;
> use warnings;
>
> my %xxx =();
>
> $xxx{a} = [4,3,6];
>
> $xxx{b} = [7,6,8];
>
> while (my ($key, $value) = each %xxx) {
> print $key;
> print map {$_} @$value;
> }
>
> hope this helps
That works, thanks!!!!!
------------------------------
Date: Tue, 30 Mar 2004 00:01:05 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Hashes of arrays
Message-Id: <c4a6cn$2goria$1@ID-184292.news.uni-berlin.de>
Me wrote:
> In article <4068979b$1@usenet.ugs.com>, Mothra wrote:
<working code>
>>hope this helps
>
> That works, thanks!!!!!
Fine. What have you learned? Or doesn't that matter?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 29 Mar 2004 14:48:01 -0800
From: nickelstat@sbcglobal.net (nickelstat)
Subject: how to pattern match \d in a variable?
Message-Id: <21160ba4.0403291448.5dc409be@posting.google.com>
I'm at a complete loss:
$value = "ITEM_001_in_001.ldg";
$pattern = '_in_\d\d\d.ldg'; # a substring of $value
print "pattern($pattern)
Value($value)\n";
#if ($value !~ /_in_\d\d\d.ldg/) -> this works, but not line below
if ($value !~ /\Q$pattern/) {
print "patern not found\n";
} else { print "OK OK OK\n"; }
I get "pattern not found" instead of OK OK OK.
pattern(_in_\d\d\d.ldg)
Value(ITEM_001_in_001.ldg)
patern not found
------------------------------
Date: Tue, 30 Mar 2004 00:58:46 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: how to pattern match \d in a variable?
Message-Id: <c4a9ou$2fligb$1@ID-184292.news.uni-berlin.de>
nickelstat wrote:
>
> $value = "ITEM_001_in_001.ldg";
> $pattern = '_in_\d\d\d.ldg'; # a substring of $value
Suppose you mean
$pattern = '_in_\d\d\d\.ldg';
--------------------------^
> if ($value !~ /\Q$pattern/) {
-----------------^^
What made you believe you should quote the meta characters? You shouldn't.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 29 Mar 2004 22:14:42 GMT
From: turnermm@shaw.ca (Myron Turner)
Subject: Re: life time of $1?
Message-Id: <40689ffb.2228494816@news.wp.shawcable.net>
On 29 Mar 2004 11:40:53 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
Siegel) wrote:
>Myron Turner <mturner@ms.umanitoba.ca> wrote in comp.lang.perl.misc:
>> On Sat, 27 Mar 2004 14:13:29 -0600, Tad McClellan
>> <tadmc@augustmail.com> wrote:
>>
>> >Geoff Cox <geoffacox@dontspamblueyonder.co.uk> wrote:
>> >
>> >> I am confused re the $1 issue below
>> >
>> > The numbered variables ($1, $2, $3, etc.) and the related punctuation
>> > set ($+, $&, $`, $', and $^N) are all dynamically scoped
>> > until the end of the enclosing block or until the next successful
>> > match, whichever comes first. (See L<perlsyn/"Compound Statements">.)
>> >
>> >
>> >>
>> >> can I use $1 (and $2) again?
>> >
>> >
>> >You should never use the dollar-digit variables unless you
>> >have first ensured that the match _succeeded_. (I have
>> >pointed this out to you before.)
>>
>> In a loop, if your code depends on testing a numbered $ variable, to
>> determine whether something has occurred, you can place the regular
>> expression in an eval:
>>
>> while(<>) {
>> my $num = eval{ /(\d+)/; return $1 if $1; return undef; };
>> check_this_number($num) if $num;
>> }
>>
>> If you don't use the eval, then the next time through the loop, there
>> might not be a number in $_, but $1 would still test true because it
>> would still hold the number from the previous iteration.
>
>Sorry to be blunt, but that's nonsense.
>
>"Eval" is of no use in this situation, and the way you use it is buggy.
>(You throw away legitimate results of "0" and "").
>
>The standard is
>
> if ( /(\d+)/ ) {
> # use $1, whether boolean true or not
> } else {
> # deal with mismatch
> }
>
>If you want the result reflected in $num being defined or not, use
>
> my $num = /(\d+)/ and $1;
>
>The use of "eval" here is abusive and misleading.
>
>Anno
Well, try it and see what happens.
Myron Turner
www.room535.org
------------------------------
Date: Mon, 29 Mar 2004 22:30:38 GMT
From: turnermm@shaw.ca (Myron Turner)
Subject: Re: life time of $1?
Message-Id: <4068a337.2229322696@news.wp.shawcable.net>
On 29 Mar 2004 11:40:53 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
Siegel) wrote:
>Myron Turner <mturner@ms.umanitoba.ca> wrote in comp.lang.perl.misc:
>> On Sat, 27 Mar 2004 14:13:29 -0600, Tad McClellan
>The use of "eval" here is abusive and misleading.
>
>Anno
Well, I just tested it on a lerge database file and I see you're
right. It makes sense, of course. But i have had situations where I
did need the eval, for some reason which is why I started to use it.
Apart from that, however, you mikght want to tone down you're
rhetoric. What is "abusive" supposed to mean here? Save it for wife
beaters and child molesters.
Myron Turner
www.room535.org
------------------------------
Date: Mon, 29 Mar 2004 16:26:07 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: life time of $1?
Message-Id: <slrnc6h8jv.c7a.tadmc@magna.augustmail.com>
Myron Turner <turnermm@shaw.ca> wrote:
> On 29 Mar 2004 11:40:53 GMT, anno4000@lublin.zrz.tu-berlin.de (Anno
> Siegel) wrote:
>
>>Myron Turner <mturner@ms.umanitoba.ca> wrote in comp.lang.perl.misc:
>>> while(<>) {
>>> my $num = eval{ /(\d+)/; return $1 if $1; return undef; };
>>> check_this_number($num) if $num;
>>> }
>>"Eval" is of no use in this situation, and the way you use it is buggy.
>>The use of "eval" here is abusive and misleading.
> Well, try it and see what happens.
I saw that it is abusive and misleading.
What point were you trying to make with that last comment?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 29 Mar 2004 19:52:34 GMT
From: perl coder <perlcdr@mail.rumania>
Subject: Re: Loss of privledges in a perl app
Message-Id: <68%9c.26235$gZ3.21039@bignews3.bellsouth.net>
Michele Dondi said:
>>} I read somewhere that it's also necessary to call fork and exit for the
>>} switch to happen correctly. Why is that?
>
> I think you need to 'fork and exit' to go in the bg. You surely know
> what fork() returns to the parent and to the child respectively, don't
> you?
True, it's necessary to do that to detach daemon programs from any tty.
But the article/message/whetever it was I read (sorry can't remember
where it was) said that "fork and exit" was needed to ensure correct
UID/GID transition, even for non-daemon programs. Which is what doesn't
make sense to me.
--
No crazy stuff in my email. ;-)
------------------------------
Date: 29 Mar 2004 16:42:18 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: Lost data on socket - Can we start over politely?
Message-Id: <4068983a$1_1@news.iglou.com>
In article <c49ous$hif$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>Also sprach Vorxion:
>
>Thank you for the time you invested into readability.
Thanks for replying with pertinent help. :)
>> In short, connect with anything and toss, say... 4000 thousand lines of
>> input at the server. It should give up the ghost far early--somewhere
>> around 1120-2200, depending on the phase of the moon. You'll note that if
>> you're still connected, you can even send more data. It's purely a
>> buffering issue.
>
>It seems to be one:
>
> while ($single_conn->read($line,102400))
>
>If I am not completely mistaken, perl internally uses recvfrom(2) when
>reading from a socket. AFAIK, a socket's send and receive buffer is each
>around 64kB. You try to read significantly more than that. What happens
>when you read in smaller chunks?
Same results. It drops out in the 1150-2200 line range and tosses the
rest of the data. Actually, since I'm not storing it anywhere in this, I
couldn't even tell you if those are 100% contiguous lines from start to
middle, or if it's dropping out intermittantly as well.
I tried 1024, 8192, 16384, and 65536, all with the same net effect.
>Also, I'd return to using sysread() which you initially used. You are
>using select() which doesn't work particularly will with buffered I/O.
I'd have thought it clear that I -need- buffering. The documentation
clearly says don't do that if you need buffering, now that I've reread it a
few hundred times. Why would you suggest I return to something that almost
guarantees failure? Nevertheless, I just tried it with varying read sizes,
and it yields the same type of results.
As for select(), please show me a way to write a multi-connection server
that's efficient, without using select(). :) I think about the only way to
do it would be to use recv() with MSG_PEEK, but I'm pretty much doubting
that would work any better. What makes you say that select() doesn't work
well with buffered I/O? Technically it should be used with non-blocking
I/O, but I've never seen a reference to it nuking buffering. I'll read the
docs on select() again (the low-level one -and- the IO::Select module) just
to check.
Any other ideas? I've looked at several examples online and none seem to
suggest select() is an issue. One I'm specifically looking at at the
moment is at: www.perlfect.com/articles/select.html
I ordered "Advanced Perl Programming" specifically for its chapter on
network programming (amongst other things) and it should be here tomorrow,
so there's something at least. The Camel was less than helpful in this
regard so far, being pretty limited to what's in the perlipc POD and only a
few other things.
The new book may help, but I wouldn't mind further assistance if anything
springs to mind.
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: 29 Mar 2004 16:49:15 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: Lost data on socket - Can we start over politely?
Message-Id: <406899db_1@news.iglou.com>
In article <c49ous$hif$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>Also sprach Vorxion:
>
>Also, I'd return to using sysread() which you initially used. You are
>using select() which doesn't work particularly will with buffered I/O.
Earlier, I'd questioned why you'd advise the former while saying the latter
was an issue. I just re-read (after a long time between) the perldocs for
select() and saw at the very end:
WARNING: One should not attempt to mix buffered I/O
(like "read" or <FH>) with "select", except as
permitted by POSIX, and even then only on POSIX
systems. You have to use "sysread" instead.
Well, that explains -why- I originally used sysread(). I feel less stupid
now, since the docs actually support my having used it in the first place.
When I wrote a client for something, I had used select between STDIN and
the remote socket, and I'd used sysread(). The code I'm working from is
an extension of that work, which explains why I carried over sysread(),
although I'd forgotten the reason for it in the first place. The problem
is that I wasn't realising that it would entirely unbuffer my I/O.
So I guess the question then becomes, "How can you get select-like
functionality without using select(), or how can you use select() and
retain buffering?"
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: 29 Mar 2004 17:27:32 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: Lost data on socket - Can we start over politely?
Message-Id: <4068a2d4$1_1@news.iglou.com>
In article <c49ous$hif$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>Also sprach Vorxion:
>
>Also, I'd return to using sysread() which you initially used. You are
>using select() which doesn't work particularly will with buffered I/O.
And as one further note, I copied this to another test program, commented
out all references to select() (or OO methods dealing with it), and instead
stacked the IO::Socket objects in an array, and simply cycled through them
checking for $client->eof, and using $client->read(). This -should- be
fully buffered. Yes, I know I'd need alternate methods for determining if
connections drop. This was purely a buffering test.
It still bombs out early. And this entirely takes select() out of the
loop, as well as sysread()/syswrite().
Even straight buffered I/O functions...aren't buffering.
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: 29 Mar 2004 22:30:44 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Lost data on socket - Can we start over politely?
Message-Id: <c4a82k$1p1$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Vorxion:
> In article <c49ous$hif$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>>Also sprach Vorxion:
>>> In short, connect with anything and toss, say... 4000 thousand lines of
>>> input at the server. It should give up the ghost far early--somewhere
>>> around 1120-2200, depending on the phase of the moon. You'll note that if
>>> you're still connected, you can even send more data. It's purely a
>>> buffering issue.
>>
>>It seems to be one:
>>
>> while ($single_conn->read($line,102400))
>>
>>If I am not completely mistaken, perl internally uses recvfrom(2) when
>>reading from a socket. AFAIK, a socket's send and receive buffer is each
>>around 64kB. You try to read significantly more than that. What happens
>>when you read in smaller chunks?
>
> Same results. It drops out in the 1150-2200 line range and tosses the
> rest of the data. Actually, since I'm not storing it anywhere in this, I
> couldn't even tell you if those are 100% contiguous lines from start to
> middle, or if it's dropping out intermittantly as well.
>
> I tried 1024, 8192, 16384, and 65536, all with the same net effect.
In this case I'd see whether there is any read() that returns undef.
Check $! in this case.
>>Also, I'd return to using sysread() which you initially used. You are
>>using select() which doesn't work particularly will with buffered I/O.
>
> I'd have thought it clear that I -need- buffering. The documentation
> clearly says don't do that if you need buffering, now that I've reread it a
> few hundred times. Why would you suggest I return to something that almost
> guarantees failure? Nevertheless, I just tried it with varying read sizes,
> and it yields the same type of results.
>
> As for select(), please show me a way to write a multi-connection server
> that's efficient, without using select(). :) I think about the only way to
> do it would be to use recv() with MSG_PEEK, but I'm pretty much doubting
> that would work any better. What makes you say that select() doesn't work
> well with buffered I/O? Technically it should be used with non-blocking
> I/O, but I've never seen a reference to it nuking buffering. I'll read the
> docs on select() again (the low-level one -and- the IO::Select module) just
> to check.
Here is what 'perldoc -f select' says:
WARNING: One should not attempt to mix buffered I/O (like "read" or
<FH>) with "select", except as permitted by POSIX, and even then
only on POSIX systems. You have to use "sysread" instead.
You have to keep in mind that Perl's read() is _not_ read(2). The naming
is a bit misleading there. A true read(2) is done through sysread(). So
use this and suspiciously watch its return value for undefs.
Maybe we are also talking about different buffers here. When talking
about buffering and Perl, one usually means the buffer you have when
using C's FILE and fread/fwrite etc. That's a high-level buffer used to
increase the performance. A socket's buffer however is something else.
When you receive network data, this data has to be stored somewhere
before it even reaches user-space programs. The maximum size of a TCP
packet is 64kB so there are facilities to store at least that much on
the lower levels of the ISO/OSI layers. These buffers have nothing to do
with the buffer in a FILE structure. When using select, you are working
with file-descriptors, and those don't have buffers in Perl's meaning
of the word.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 29 Mar 2004 14:36:39 -0800
From: rbell01824@aol.com (RJB)
Subject: Re: LWP cookies
Message-Id: <f97da4d5.0403291436.3b2cdeb2@posting.google.com>
Peter,
Thanks for your interest.
The session cookie in the hard coded header is in fact expired. An
attempt to use the code snip by itself gets a "page moved" 400 series
error.
What surprised me, as you noted, is that if I first visit the page
that issues (among many other) the session cookies (I now think there
are two, but am still not entirely sure) before running the code snip,
the code snip WORKS even though it forces the header containing the
now expired session cookie!
Does anyone know if this is LWP behavior that I can depend on?
peter@PSDT.com (Peter Scott) wrote in message news:<8AW9c.42530$QO2.39890@pd7tw1no>...
> In article <x7d66wtt96.fsf@mail.sysarch.com>,
> Uri Guttman <uri@stemsystems.com> writes:
> >>>>>> "RB" == Richard Bell <rbell01824@comcast.net> writes:
> >
> > RB> In the course of this dance, I neglected to mention that the 18
> > RB> previous pages use frames and very heavy scripting (some Java, some
> > RB> VB). While I'm new to LWP and don't really know, I'm under the
> > RB> impression that frames and LWP don't get on well, to say nothing of
> > RB> the scripts. That aside, the code to visit all 18 pages would
> > RB> ultimately be IMHO rather worse than the mess with the headers. But
> > RB> that is, of course, just my preference.
> >
> >the backend scripting of java or vb makes NO difference on the client
> >side. only javascript can screw up LWP by making the buttons only
> >javascript and hard/impossible to click.
> >
> >as for your 18 pages, it doesn't matter. www::mechanize can scrape that
> >in 18 calls. and all without ugly manual header code.
> >
> >and www::mechanize handles frames as links so that is not a problem
> >either.
>
> In fairness to the OP he probably meant JavaScript - that has caused
> me problems on mechanizing some sites and I can easily imagine it
> being too difficult to figure out what it's doing. Until we get a JS
> engine for Perl there's no way to avoid manual inspection.
>
It's an interesting proposition. At some level, an even more
interesting would be a way to automate Mozilla from inside perl. My
argument would be that browsers will continue to evolve. Rather than
engage in an endless chase as they do so, why not just use one that is
in the business (more or less) of being a reasonably contemporary
browser to deal with all this nasty scripting etc. Interestingly,
Mozilla provides rather reasonable access to its DOM, including
writing. The fine folks at Mozilla propose it as an application UI
environment based on writing to the DOM. Since we can trigger buttons
etc. by this mechanism automation of even the most perverse page is
possible. It can also clearly be used as a scraper per the DOM
Inspector. I'm surprised that its not been done already. Sigh!
As an asside, of the 4600 or so pages I'm working with now, 15% to 20%
give LWP tools some kind of trouble (also wget and similar things).
For a good time check www.bankofamerica.com (active script drives
navigation via select list, links go to form to select state from
select list that in turn sets state cookie, ...). In the larger web
world, I'm not sure how common this stuff is, but I'm inclined to
think that it will become increasingly common over time, at least in
larger commercial sites.
LWP is great, but as the web continues to evolve, we'll need to come
to grips with this issue.
> But as you say, I would first try using mechanize to visit all 18
> pages. If that didn't work I'd see if the JavaScript was something
> I could figure out easily enough, or use a proxy to see what was
> going over the wire.
>
Tried mechanize. It got to the 2nd page before getting into real
trouble with a bit of Javascript, hiden form with values set by
Javascript, visible form, Javascript buttons, frames, ... . The issue
continues through another 16 or so pages! Since life is finite and
I've got a bunch of gray hair, I opted to bring up wsp -v, catch the
traffic, run template.pl (thanks to a most excellent book), and see
what got sent at the end.
> > RB> To each his own. My real concern, however, remains concerning a
> > RB> cookie value forced in the header v. one in the cookie jar as it
> > RB> concerns the session cookie. It's working, I'm OK with it, but I'd
> > RB> like to be a bit more sure if anyone knows the underlying behavior of
> > RB> LWP in this case.
>
> I wouldn't have thought that hardcoding a session cookie was likely to
> work. It makes no difference how you send it, the problem is that the
> server ought to have forgotten about the original session long ago.
> I would expect you'd have to at least visit the page that generates
> the session cookie before jumping to the stage that you want. This is
> an approach that has usually worked for me with banks in particular;
> do the login and then go directly to the desired end page, regardless
> of any navigation necessary in an interactive session.
Your experience parallels mine entirely. So why does this work even
though I'm forcing an expired cookie in the header? Is this stable
behavior for LWP or am I just getting lucky?
R
------------------------------
Date: Mon, 29 Mar 2004 15:30:22 -0500
From: Brad Baxter <bmb@ginger.libs.uga.edu>
Subject: Re: New module: Array::Each
Message-Id: <Pine.A41.4.58.0403291511340.14164@ginger.libs.uga.edu>
On Mon, 29 Mar 2004, Anno Siegel wrote:
> Brad Baxter <bmb@ginger.libs.uga.edu> wrote in comp.lang.perl.misc:
> > [...]
> > So you see, $undef is really $self->[UNDEF], a user-definable value to be
> > used when the code falls off the end of an array.
>
> Well... the wisdom in the choice of variable name is doubtful, especially
> since a spurious "$" in front of something else is a popular typo.
> "my $self = $shift" anyone?
Point well taken.
> [...]
> You could add a supply of the local undef's past the end of the list:
> (untested)
>
> my @ret = ( @$_, ( $undefined_value ) x $group)[ $i .. $i + $group - 1];
Ah! That's the inspiration I was hoping for. And unless I'm doing
something wrong, it benchmarks nearly twice as fast:
use Benchmark 'cmpthese';
my $count = shift||100000;
my $undef_val = '_';
my $group = 30;
my $set = [['a'..'z'], [1..26]];
my $i = 0;
cmpthese($count, {
'foreach' => sub {
my @ret;
foreach my $aref ( @$set ) {
push @ret, map {$_<@$aref ? $aref->[$_] : $undef_val}
($i..$i+$group-1) }
},
'map_slice' => sub {
my @ret = map { (@$_,($undef_val)x$group)[$i..$i+$group-1] }
@$set;
},
});
__END__
Benchmark: timing 100000 iterations of foreach, map_slice...
foreach: 28 wallclock secs (26.35 usr + 0.00 sys = 26.35 CPU) @
3795.07/s (n=100000)
map_slice: 15 wallclock secs (14.02 usr + 0.00 sys = 14.02 CPU) @
7132.67/s (n=100000)
Rate foreach map_slice
foreach 3795/s -- -47%
map_slice 7133/s 88% --
>
> But let me say that a guts feeling tells me these individual undefs are a
> misfeature. They are presumably there to tell the user that the algorithm
> had to pull elements from past the end of one or more arrays. In many cases
> the user won't care and be quite happy with standard undef's. If they do
> care, they can bloody well fill their own arrays with distinctive values :)
> It could be that the feature encumbers your algorithm more than it's worth.
>
Well, the feature is mostly avoided anyway, and the value *is* undef by
default. I like the idea because it gives an option that doesn't force
anyone to alter (or copy) the arrays they're iterating over.
> > I took another close look at perlvar to see if I missed a special
> > variable. I looked for one that would let me tell perl what to supply in
> > the case of a slice element (or array element autovivification, too?) when
> > it goes past the end. Something along these lines:
>
> No such thing.
As I suspected. :-)
Many thanks, as always.
Brad
------------------------------
Date: Mon, 29 Mar 2004 13:46:05 -0600
From: John Bokma <postmaster@castleamber.com>
Subject: Re: Performance issues with LWP?
Message-Id: <40687d36$0$24356$58c7af7e@news.kabelfoon.nl>
Prabh wrote:
> Hello all,
> In my task I need to check if the web server at a known URL is up and
> available. If its not, I need to send a mail to the system admins that
> the server is down and if its available then get the URL's contents.
> The simplest way I could think of doing this was with LWP.
>
>
> use LWP::Simple ;
> my $chkUrl = get("http://abc.xyz.com");
> if ( ! $chkUrl )
> {
> &mail_the_Admins_the_server_is_down() ;
> die "Cant connect: Check the URL or the Server is down\n" ;
> } else {
> &do_some_prcessing_here() ;
> }
>
>
> I've now been told this strategy might cause "abc.xyz.com" to take a
> performance hit, as every time this check is run, it would be pinging
> the server and will cause performance issues.
not pinging, but it gets the page. Use HEAD.
> Is there any way I could check if the web server is up or not, without
> causing any performances issues?
try to connect to port 80. If you can connect, there is a server running
on that port.
--
John personal page: http://johnbokma.com/
Freelance Perl / Java developer available - http://castleamber.com/
------------------------------
Date: Mon, 29 Mar 2004 20:50:24 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Perl Programmer Wanted for Games Web Site Development
Message-Id: <slrnc6h30g.74v.dha@panix2.panix.com>
In article <b803b120.0403261616.18b70d45@posting.google.com>,
Kerrin wrote:
> I have started a project, and require people to join me.
You have posted a job posting or a resume in a technical group.
Longstanding Usenet tradition dictates that such postings go into
groups with names that contain "jobs", like "misc.jobs.offered", not
technical discussion groups like the ones to which you posted.
Had you read and understood the Usenet user manual posted frequently to
"news.announce.newusers", you might have already known this. :) (If
n.a.n is quieter than it should be, the relevent FAQs are available at
http://www.faqs.org/faqs/by-newsgroup/news/news.announce.newusers.html)
Another good source of information on how Usenet functions is
news.newusers.questions (information from which is also available at
http://www.geocities.com/nnqweb/).
Please do not explain your posting by saying "but I saw other job
postings here". Just because one person jumps off a bridge, doesn't
mean everyone does. Those postings are also in error, and I've
probably already notified them as well.
If you have questions about this policy, take it up with the news
administrators in the newsgroup news.admin.misc.
http://jobs.perl.org may be of more use to you
Yours for a better usenet,
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
"We are the Borg. You will be assimilated! Nah, only kidding. We're
just the Sontarans. Care to take part in some 'medical research'?"
------------------------------
Date: Mon, 29 Mar 2004 14:41:16 -0500
From: Richard Morse <remorse@partners.org>
Subject: Re: Regex match for one and only one occurrence of a pattern
Message-Id: <remorse-192109.14411629032004@plato.harvard.edu>
In article <e33c37bb.0403281853.2e6a0156@posting.google.com>,
chiriones@yahoo.com (Steve Allgood) wrote:
> I'm trying to match one and only one occurrence of a pattern in a string.
>
> For example, for the pattern 'bc' I want a regex to match 'abcd' but not
> 'abcdabcd'.
>
> I have tried /bc(?!(.*bc)+)/ but that doesn't work. It just matches the last
> 'bc'.
Well, you have the negative look-ahead, so maybe you need a negative
look-behind?
You'll have to play around with this a bit, as this is completely
untested...
print "matched" if m/(?<!bc.*)bc(?!.*bc)/;
HTH,
Ricky
------------------------------
Date: Mon, 29 Mar 2004 15:12:30 -0500
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: Regex match for one and only one occurrence of a pattern
Message-Id: <20040329150827.Q25178@dishwasher.cs.rpi.edu>
On Mon, 29 Mar 2004, Richard Morse wrote:
> In article <e33c37bb.0403281853.2e6a0156@posting.google.com>,
> chiriones@yahoo.com (Steve Allgood) wrote:
>
> > I'm trying to match one and only one occurrence of a pattern in a string.
> >
> > For example, for the pattern 'bc' I want a regex to match 'abcd' but not
> > 'abcdabcd'.
> >
> > I have tried /bc(?!(.*bc)+)/ but that doesn't work. It just matches the last
> > 'bc'.
>
> Well, you have the negative look-ahead, so maybe you need a negative
> look-behind?
>
> You'll have to play around with this a bit, as this is completely
> untested...
>
> print "matched" if m/(?<!bc.*)bc(?!.*bc)/;
>
I think that'll cause a regexp error, as lookbehind assertions must be
fixed-width
Move the .* out of the assertion:
print "matched" if m/(?<!bc).*bc.*(?!bc)/;
The .* is allowable in the lookahead, of course. I just moved it out for
symmetry's sake.
Paul Lalli
------------------------------
Date: Mon, 29 Mar 2004 12:28:26 -0800
From: Steven Kuo <skuo@mtwhitney.nsc.com>
Subject: Re: Regex match for one and only one occurrence of a pattern
Message-Id: <Pine.GSO.4.21.0403291225450.5104-100000@mtwhitney.nsc.com>
On 28 Mar 2004, Steve Allgood wrote:
> I'm trying to match one and only one occurrence of a pattern in a
> string.
>
> For example, for the pattern 'bc' I want a regex to match 'abcd'
> but not 'abcdabcd'.
>
> I have tried /bc(?!(.*bc)+)/ but that doesn't work. It just
> matches the last 'bc'.
>
> Any suggestions?
>
> Thanks,
> Steve
One way:
if ( @{[ m/bc/g ]} == 1 ) {
# matched just once
}
--
Hope this helps,
Steven
------------------------------
Date: 29 Mar 2004 14:32:32 -0500
From: Uri Guttman <uri.guttman@fmr.com>
Subject: Re: split string to chars
Message-Id: <siscn05zfnzj.fsf@tripoli.fmr.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> I don't think there is a good use for "%c" in Perl. Where would
AS> "characters as integers" come from? Perl doesn't produce them
AS> (unless on demand), and from a file you could as well read them as
AS> characters.
it can be useful for various binary formats where individual bytes need
to be written or stored in a string. pack C/c or chr() can do the same
thing. (s)printf supports it because c's printf has it. the number may
be generated from an expression and you can't put it into a byte
directly or easily. timtowtdi and all.
uri
------------------------------
Date: 29 Mar 2004 11:33:52 -0800
From: jamesj@jamesj.zyx.net (Jimmy Jacobson)
Subject: Re: Testing PHP script using Test::Simple perl script
Message-Id: <f557d0da.0403291133.13a97063@posting.google.com>
Try using jmeter for testing php applications. It's great stuff.
http://www.phpbuilder.com/columns/bommarito20030610.php3
Jimmy
------------------------------
Date: Mon, 29 Mar 2004 22:12:42 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: Text editor implemented in Perl
Message-Id: <c4a70q$f3k$1@reader1.panix.com>
In article <c2sasr$4u0$1@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote:
>Also sprach J Krugman:
>
>> In <c2qe0q$65f$1@wisteria.csv.warwick.ac.uk> Ben Morrow <usenet@morrow.me.uk> writes:
>>
>>>The main reason I started was because I got really hacked off with
>>>elisp: I just can't make any sense of it... Emacs' Unicode support was
>>>also not how I wanted it to be, so I thought I'd write my own editor in
>>>Perl.
>>
>>>Then I learned to use vim... the project's been on hold ever since :).
>>
>> What makes vim so much better than Emacs?
>People will probably be using one or the other, but not both.
Not that I'm all that good with either, but I
do use both.
Emacs is "up", and I'm "in" it, nearly 100% of the time:
things like *shell* and dired make dealing with the computer
*so much easier* -- and efficient too.
Vi{,m} has one rather unique featured: its "g" (and "v") command,
which work like this:
80,900g/mypat/<some ex-command>
where <some ex-command> can be *any* ex-command -- other than
another v or g command.
like this:
g/myregexp/.-2,.+2s/^/foo/
which works like this, using TWO PASSES:
pass-1: goes through lines 80 through 900, seeing which ones
have a match for myregexp, and for those that do,
turn on a bit (attached to the LINE ITSELF, not the
line-NUMBER).
pass-2 for every line in the file (I guess, so things work
out right), for those that have that bit turned on,
*do that <some ex-command>, in this case,
.-2,.+2s/^/foo/
, where "." is interpreted as the current 2nd-pass line-number.
That is, if in the 2nd pass, we're now at line 458, and
that line does have that bit turned "on", then this
is executed:
456,460s/^/foo/
What's cool is that it still works if the attached-command
changes the number of lines, eg if the command had been:
.-5r myfile.txt
, which of course changes the line-number that of the line
the 2nd-pass is now at.
But that does NOT screw-up everything, because as that line
"moves around (via its linenumber)", that bit MOVES ALONG WITH IT!
Which makes everything work.
Which is pretty darned cool.
And which seems to be fully documented only in the classic
Kernighan book, "Software Tools" (from way back in the mid
70's), and which is *still* very much reading (actually,
studying)
Not so easy to do in emacs, mainly because vi works via an
indexable *array* of lines, where emacs works one single
super=long array *of characters* -- which enables a whole
different kind wonderful magic too.
David
------------------------------
Date: 29 Mar 2004 11:41:49 -0800
From: hobbit_hk@hotmail.com (Hobbit HK)
Subject: Writing to STDIN
Message-Id: <22ee5d47.0403291141.3544e9ee@posting.google.com>
Hi,
I wrote a script that takes user input for confirmation.
Now, I want that the "default" option will be yes, the "y" will
already be ready there, in the STDIN ("Are you sure? y" will be the
output).
I tried something like
print STDIN "y";
but of course that didn't do any good, does anyone know how to do
that?
------------------------------
Date: 29 Mar 2004 19:51:08 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Writing to STDIN
Message-Id: <c49unc$aqs$1@canopus.cc.umanitoba.ca>
In article <22ee5d47.0403291141.3544e9ee@posting.google.com>,
Hobbit HK <hobbit_hk@hotmail.com> wrote:
:I wrote a script that takes user input for confirmation.
:Now, I want that the "default" option will be yes, the "y" will
:already be ready there, in the STDIN ("Are you sure? y" will be the
:output).
:I tried something like
:print STDIN "y";
:but of course that didn't do any good, does anyone know how to do
:that?
Depends on the operating system. On POSIX-based operating systems, you could
use a .xs stub that did an ungetc() of a single character (POSIX
does not promise that more than one will be possible.) Then you'll have
to worry about displaying the character properly and getting it flushed
at just the right point so it appears on the user's output...
If I were you, I simply wouldn't do it that way. I'd look at the
terminal handling modules that have already been developed in CPAN
and pick an appropriate one and go with it.
--
Are we *there* yet??
------------------------------
Date: Mon, 29 Mar 2004 19:59:40 GMT
From: "Ala Qumsieh" <xxala_qumsiehxx@xxyahooxx.com>
Subject: Re: Writing to STDIN
Message-Id: <Me%9c.30318$sb2.1918@newssvr29.news.prodigy.com>
news:22ee5d47.0403291141.3544e9ee@posting.google.com...
> Hi,
> I wrote a script that takes user input for confirmation.
> Now, I want that the "default" option will be yes, the "y" will
> already be ready there, in the STDIN ("Are you sure? y" will be the
> output).
>
> I tried something like
> print STDIN "y";
Why not the standard:
print 'Are you sure? [y] ';
?
That is more convenient since if the user wants to answer no, he/she won't
have to backspace.
--Ala
------------------------------
Date: Mon, 29 Mar 2004 15:06:25 -0500
From: Paul Lalli <ittyspam@yahoo.com>
Subject: Re: Writing to STDIN
Message-Id: <20040329150300.T25178@dishwasher.cs.rpi.edu>
On Mon, 29 Mar 2004, Hobbit HK wrote:
> Hi,
> I wrote a script that takes user input for confirmation.
> Now, I want that the "default" option will be yes, the "y" will
> already be ready there, in the STDIN ("Are you sure? y" will be the
> output).
>
> I tried something like
> print STDIN "y";
>
> but of course that didn't do any good, does anyone know how to do
> that?
You don't want to do this. You want to let the user just hit enter for
the default value, which is fine. But you don't want to make him actually
backspace to change the default value. And you certainly don't want to go
mucking about with the input stream...
print "Are you sure? [y]\n";
chomp(my $resp = <STDIN>);
if ($resp){
#user entered non-default
} else {
#user accepted default.
}
(Granted, that simple case would fail if the user was foolish enough to
enter "0" instead of 'n'. If you want to account for that level of user
stupidity, make your conditional more explicit. )
if ($resp eq '') {
Paul Lalli
------------------------------
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 6333
***************************************
