[31834] in Perl-Users-Digest
Perl-Users Digest, Issue: 3097 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 25 03:09:25 2010
Date: Wed, 25 Aug 2010 00:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 25 Aug 2010 Volume: 11 Number: 3097
Today's topics:
Re: Fast iterative reads <xhoster@gmail.com>
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <ralph@happydays.com>
Re: Simple script execution problems (newbie) <hjp-usenet2@hjp.at>
Re: Simple script execution problems (newbie) <derykus@gmail.com>
Re: Simple script execution problems (newbie) <hjp-usenet2@hjp.at>
Re: Simple script execution problems (newbie) <hjp-usenet2@hjp.at>
Re: Simple script execution problems (newbie) <stevem_@nogood.com>
Re: Simple script execution problems (newbie) <hslee911@yahoo.com>
Re: Simple script execution problems (newbie) <paul@pstech-inc.com>
Re: split on a string that should be interpreted as a r <ben@morrow.me.uk>
Re: split on a string that should be interpreted as a r <xhoster@gmail.com>
Re: split on a string that should be interpreted as a r <ben@morrow.me.uk>
Re: split on a string that should be interpreted as a r (Alan Curry)
Re: split on a string that should be interpreted as a r <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 23 Aug 2010 18:49:33 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Fast iterative reads
Message-Id: <4c745b59$0$15340$ed362ca5@nr5-q3a.newsreader.com>
Paul Branon wrote:
> I like all these ideas.
What ideas? You haven't quoted any context.
> It's a shame the sort and discard idea won't
> work in this instance because the long list comes from the same
> database as the short list! (Why couldn't the original query contain
> all the relevant data? In theory it could. In practice they don't do
> it that way.)
>
> As for storing the data from the long list in a hash, isn't it the
> case that I'd need an array of hashes? Otherwise each iterative read
> of the longlist would overwrite the entries from the previous list.
Why would you read the long list repeatedly? The whole point of storing
it is that you only need to read it once.
<Unreadable code snipped>
Xho
------------------------------
Date: Tue, 24 Aug 2010 12:04:36 -0400
From: Ralph Malph <ralph@happydays.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <6460d$4c73ed94$40779ac3$29049@news.eurofeeds.com>
[asperger's fueled screed snipped]
tl, dnr
------------------------------
Date: Tue, 24 Aug 2010 20:37:01 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <slrni784ae.o8h.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-24 08:49, Paul E. Schoen <paul@pstech-inc.com> wrote:
> There is another form emailer that can be called from the dreamhost server
> http://formmail.dreamhost.com/cgi-bin/formmail.cgi and it uses what I set as
> "email" in the form data.
Ouch. That looks a lot like Matt Wright's infamous formmail script
(especially the "send to any email address the user cares to enter"
feature/bug). Don't use this and tell dreamhost to get rid of it. Once
upon a time this was a major spam vector (by now most spammers have
probably forgotten that it ever existed).
hp
------------------------------
Date: Tue, 24 Aug 2010 12:01:39 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <bff9154c-5787-4a71-bce7-a17ef4866241@n19g2000prf.googlegroups.com>
On Aug 24, 8:05=A0am, Tad McClellan <ta...@seesig.invalid> wrote:
> Scott Bryce <sbr...@scottbryce.com> wrote:
> > Paul E. Schoen wrote:
> >> Actually, running it in Telnet produces both headers and text, and
> >> the "output.txt" file is updated. I wanted the browser to show
> >> "Starting" and then "Finished" after the file had been written. It
> >> does the same thing as edited above, without the second header. I
> >> thought it should show both lines in the browser. So, how does the
> >> browser know that the text it is reading on stdout has "finished"?
> >> Would it work if it actually generated HTML?
>
> > Well, you are sending headers to the browser telling the browser that i=
t
> > is being sent HTML, but what you are sending is not HTML. What the
> > browser does with the text you send it is not predictable.
>
> > BTW, you will want to include a line in your script, somewhere before
> > the first print statement, that reads:
>
> > $|=3D1;
>
> > Perl buffers output. Your browser is likely to get the "Starting" and
> > "Finished" at the same time after the file write on the server. The lin=
e
> > above will tell Perl to flush the buffer after every print statement, s=
o
> > that the "Starting" will get to the browser
> > before the file write.
>
> It might and it might not.
>
> A CGI program's output goes to the *web server*. The server may
> decide to pass output through right away, or it may decide to wait
> until all of the output is available anyway.
> ...
IIRC, a no-parsed header (NPH) script bypasses the server's
header parsing/insertions as well as its buffering. One of
the key NPH script advantages is a scenario in which backend
processing is slow and you want to display unbuffered results
to the client more quickly. The server has to be configured
for NPH scripts though.
--
Charles DeRykus
------------------------------
Date: Tue, 24 Aug 2010 20:56:46 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <slrni785ff.o8h.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-24 14:15, Scott Bryce <sbryce@scottbryce.com> wrote:
> Paul E. Schoen wrote:
>> Actually, running it in Telnet produces both headers and text, and
>> the "output.txt" file is updated. I wanted the browser to show
>> "Starting" and then "Finished" after the file had been written. It
>> does the same thing as edited above, without the second header. I
>> thought it should show both lines in the browser.
As others already suggested, your script probably dies after the failed
open. You should see the error message in the error log. It is possible
(even likely) that the script doesn't have permission to write to the
current directory when it is started by the webserver.
>> So, how does the browser know that the text it is reading on stdout
>> has "finished"?
The browser knows that the text has finished when the web server closes
the connection or when it has read as many bytes as the server indicated
(via a content-length header or chunked encoding).
>> Would it work if it actually generated HTML?
No.
> Well, you are sending headers to the browser telling the browser that it
> is being sent HTML, but what you are sending is not HTML.
This is true only in a very strict sense. Many tags in HTML are
optional, so
---%<------%<------%<------%<------%<------%<------%<------%<---
Starting ...
Finished
---%<------%<------%<------%<------%<------%<------%<------%<---
is exactly equivalent to
---%<------%<------%<------%<------%<------%<------%<------%<---
<html>
<head>
</head>
<body>
Starting ...
Finished
</body>
</html>
---%<------%<------%<------%<------%<------%<------%<------%<---
which still is not conforming because the title element is missing
(which strangely is the only element in HTML which is not optional and
not implied, but afaik there isn't any browser which will complain about
a missing title element) and also because of the missing doctype (but
that only means the the browser doesn't know the exact HTML version).
> What the browser does with the text you send it is not predictable.
For a standards-conforming browser it is predictable: It will display a
single paragraph with the text "Starting ... Finished". Of course IE may
do something different :-).
hp
------------------------------
Date: Tue, 24 Aug 2010 20:59:49 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <slrni785l5.o8h.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-24 15:05, Tad McClellan <tadmc@seesig.invalid> wrote:
> Scott Bryce <sbryce@scottbryce.com> wrote:
>> BTW, you will want to include a line in your script, somewhere before
>> the first print statement, that reads:
>>
>> $|=1;
>>
>> Perl buffers output. Your browser is likely to get the "Starting" and
>> "Finished" at the same time after the file write on the server. The line
>> above will tell Perl to flush the buffer after every print statement, so
>> that the "Starting" will get to the browser
>> before the file write.
>
>
> It might and it might not.
>
> A CGI program's output goes to the *web server*. The server may
> decide to pass output through right away, or it may decide to wait
> until all of the output is available anyway.
True. But without the $| = 1; the first line won't even get to the web
server before the script finishes, so the web server doesn't get a
chance to pass it on.
hp
------------------------------
Date: Tue, 24 Aug 2010 12:26:58 -0500
From: Steve <stevem_@nogood.com>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <F3Vco.28068$EF1.27609@newsfe14.iad>
On 08/24/2010 03:49 AM, Paul E. Schoen wrote:
>
> "Steve" <stevem_@nogood.com> wrote in message
> news:4C72E0A5.7050603@nogood.com...
>> On 08/23/2010 03:34 PM, Paul E. Schoen wrote:
>> <snip>
>>
>>> I rewrote the second.pl script as follows:
>>>
>>> #!/usr/bin/perl
>>> use strict;
>>> use warnings;
>>> use CGI;
>>> my $query= new CGI;
>>> print $query->header;
>>> print "\nStarting\n\n";
>>> open my $out, '>', "output.txt" or die "File error: $!";
>>> print $out $query->header;
>>> print $out "\nHello, World.\n";
>>> close $out;
>>> # print $query->header;
>>> print "\nFinished!\n";
>>>
>>> Running it on Telnet shows both headers and their text. But if run on
>>> the browser it only shows "Starting". Probably just shows how much I
>>> need to learn!
>>>
>>
>> Probably because of an error trying to open that file.
>
> Actually, running it in Telnet produces both headers and text, and the
> "output.txt" file is updated. I wanted the browser to show "Starting"
> and then "Finished" after the file had been written. It does the same
> thing as edited above, without the second header. I thought it should
> show both lines in the browser. So, how does the browser know that the
> text it is reading on stdout has "finished"? Would it work if it
> actually generated HTML?
>
>
This is starting to sound like Apache running SUEXEC where there is a
permissions/ownership conflict somewhere.
You might look at:
http://httpd.apache.org/docs/2.0/suexec.html
which will outline how SUEXEC works.
I'm wondering if cgi-bin is owned by someone else.
Oh.
It is almost always a bad idea to write a file to cgi-bin or any
directory your server considers a script enabled directory.
hth,
\s
------------------------------
Date: Tue, 24 Aug 2010 15:51:07 -0700 (PDT)
From: James <hslee911@yahoo.com>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <6367bd2d-37e0-4c96-830a-9845aee61a55@x18g2000pro.googlegroups.com>
On Aug 22, 2:37=A0pm, "Paul E. Schoen" <p...@pstech-inc.com> wrote:
> I am trying to set up a webspace so I can use CGI, and I'm getting errors
> and/or it is not behaving as it should using IE8 or Firefox. I read the F=
AQ
Modify conf/httpd.conf as
DocumentRoot "whatever"
Options FollowSymLinks
Options All
and restart apache.
JL
------------------------------
Date: Tue, 24 Aug 2010 20:54:10 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Re: Simple script execution problems (newbie)
Message-Id: <6RZco.3871$8A2.623@newsfe22.iad>
"James" <hslee911@yahoo.com> wrote in message
news:6367bd2d-37e0-4c96-830a-9845aee61a55@x18g2000pro.googlegroups.com...
On Aug 22, 2:37 pm, "Paul E. Schoen" <p...@pstech-inc.com> wrote:
> I am trying to set up a webspace so I can use CGI, and I'm getting errors
> and/or it is not behaving as it should using IE8 or Firefox. I read the
> FAQ
Modify conf/httpd.conf as
DocumentRoot "whatever"
Options FollowSymLinks
Options All
and restart apache.
-----------------------------------------------
I think that's what the administrator at Smart.net did at my request. I also
had to change the way I refer to files in cgi-bin. The main home page is
www.smart.net/~pstech, and for subdomains I simply added directories with
/subdir. But for the CGI scripts I have to use www.smart.net/pstech-cgi-bin
even though the actual directory is /cgi-bin.
Thanks for the information, but I have things under control, at least until
I start writing some non-trivial code where I'll have the opportunity of
making non-trivial mistakes :)
Paul (the 61 year old perl virgin)
------------------------------
Date: Tue, 24 Aug 2010 17:06:23 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <v87dk7-8np1.ln1@osiris.mauzo.dyndns.org>
Quoth Sherm Pendley <sherm.pendley@gmail.com>:
> Klaus <klaus03@gmail.com> writes:
>
> > I was thinking that perl (at least perl 5.8) interprets the first
> > parameter of the split function always as a regular expression, even
> > if it is a simple string, i.e. if I say:
> >
> > split(":\s*", $_, 2)
> >
> > then perl interprets this automatically and without warning into
> >
> > split(/:\s*/, $_, 2)
> >
> > Is my thinking correct ?
>
> Nope, sorry. In most cases, if the first argument is a string, it's
> not interpreted as a regex. The exception is " ", which is interpreted
> as /s+/.
No. " " is an exception, other strings are treated as a regex. See
xthread.
Ben
------------------------------
Date: Tue, 24 Aug 2010 18:47:33 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <4c747f29$0$15377$ed362ca5@nr5-q3a.newsreader.com>
Klaus wrote:
> Hello everybody,
>
> I need the wisdom of the perl community.
>
> I have a perl program that uses the split function as follows:
>
> my ($tag, $value) = split(":\s*", $_, 2);
>
> I want to split on ':', followed by optional whitespaces.
>
> When I run the program, I get a warning
>
> Unrecognized escape \s passed through at test.pl line 228.
That warning seems bizarre to me. It is the literal s, and not the
escape, that got "passed through".
Xho
------------------------------
Date: Wed, 25 Aug 2010 04:09:58 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <65eek7-v512.ln1@osiris.mauzo.dyndns.org>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> Klaus wrote:
> > Hello everybody,
> >
> > I need the wisdom of the perl community.
> >
> > I have a perl program that uses the split function as follows:
> >
> > my ($tag, $value) = split(":\s*", $_, 2);
> >
> > I want to split on ':', followed by optional whitespaces.
> >
> > When I run the program, I get a warning
> >
> > Unrecognized escape \s passed through at test.pl line 228.
>
> That warning seems bizarre to me. It is the literal s, and not the
> escape, that got "passed through".
No it's not. First the string undergoes qq expansion: this sees "\s",
doesn't recognize it, and passes it through unchanged (with a warning).
The result, ':\s*', is then passed to the regex compiler by split, which
quite happily interprets \s as 'space'.
The fact this is so confusing is a very good reason to avoid
double-quoting the split pattern in the first place :).
Ben
------------------------------
Date: Wed, 25 Aug 2010 03:49:28 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <i523s8$esf$1@speranza.aioe.org>
In article <65eek7-v512.ln1@osiris.mauzo.dyndns.org>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
>> Klaus wrote:
>> > Hello everybody,
>> > Unrecognized escape \s passed through at test.pl line 228.
>>
>> That warning seems bizarre to me. It is the literal s, and not the
>> escape, that got "passed through".
>
>No it's not. First the string undergoes qq expansion: this sees "\s",
>doesn't recognize it, and passes it through unchanged (with a warning).
>The result, ':\s*', is then passed to the regex compiler by split, which
>quite happily interprets \s as 'space'.
Really? Not for me:
$ perl -wle 'print length "\s"'
Unrecognized escape \s passed through at -e line 1.
1
$ perl -wle 'print for split "\s", "Mississippi"'
Unrecognized escape \s passed through at -e line 1.
Mi
i
ippi
$
>
>The fact this is so confusing is a very good reason to avoid
>double-quoting the split pattern in the first place :).
That part is true.
--
Alan Curry
------------------------------
Date: Wed, 25 Aug 2010 05:30:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: split on a string that should be interpreted as a regex
Message-Id: <briek7-e822.ln1@osiris.mauzo.dyndns.org>
Quoth pacman@kosh.dhis.org (Alan Curry):
> In article <65eek7-v512.ln1@osiris.mauzo.dyndns.org>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> >> Klaus wrote:
> >> > Hello everybody,
> >> > Unrecognized escape \s passed through at test.pl line 228.
> >>
> >> That warning seems bizarre to me. It is the literal s, and not the
> >> escape, that got "passed through".
> >
> >No it's not. First the string undergoes qq expansion: this sees "\s",
> >doesn't recognize it, and passes it through unchanged (with a warning).
> >The result, ':\s*', is then passed to the regex compiler by split, which
> >quite happily interprets \s as 'space'.
>
> Really? Not for me:
>
> $ perl -wle 'print length "\s"'
> Unrecognized escape \s passed through at -e line 1.
> 1
> $ perl -wle 'print for split "\s", "Mississippi"'
> Unrecognized escape \s passed through at -e line 1.
> Mi
>
> i
>
> ippi
> $
Oh God, you're right... I think this probably counts as a bug, not that
I care. split "\\s" behaves as I described (straighforward
double-un-escaping), and except for the warning that string should be
exactly equivalent to "\s".
Perl's string parsing is *scary*. For instance, compare "$x[1+1]" with
/$x[1+1]/ with /$x[0]/.
Ben
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3097
***************************************
