Re: OT perl question
Nicholas Clark wrote: Does a CGI always run with a socket as STDOUT? (in that running with a CGI-faked ENV as part of a pipe in a cron job is going to look awfuly like being run from a web server) Or will there be servers that run the CGI with the output to a pipe and in turn pump that to the client? I doubt the specification makes any mention of this. FYI, the Xitami web server (at least on Win32 systems) doesn't output any of the CGI's output to the client until the CGI is done, so perhaps it implements CGI with STDOUT directed to a file, which it then reads -- in which case you couldn't even rely on dev ino fields of stat(STDIN). Cheers, Philip -- Philip Newton [EMAIL PROTECTED] All opinions are my own, not my employer's. If you're not part of the solution, you're part of the precipitate.
Re: OT perl question
On Wed, 16 Jan 2002 09:20:49 +0100 Newton, Philip [EMAIL PROTECTED] wrote: FYI, the Xitami web server (at least on Win32 systems) doesn't output any of the CGI's output to the client until the CGI is done, so perhaps it implements CGI with STDOUT directed to a file, which it then reads -- in which case you couldn't even rely on dev ino fields of stat(STDIN). I thought that was just how pipes work in DOS. Sam.
RE: Threads availability and support
Nicholas Clark [mailto:[EMAIL PROTECTED]] wrote on 15 January 2002 21:42: I believe that ithreads were experimental in 5.6 (in that there was no perl level interface to make a thread, but the underlying ithreads mechanism is what is used to fake fork() on Windows) Fake fork() sounds useful for getting round the nasty NT nested scripts problem (which a couple of years ago stopped me installing Perl directly on an NT box - I used a Win95 workstation to do the install, putting the files on a shared drive). Does this enable perl system() and backticks to work properly on NT? Ivor. --- The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this email may be unlawful. If you have received this email in error, please notify the sender immediately and delete it from your system. The views expressed in this message do not necessarily reflect those of LIFFE (Holdings) Plc or any of its subsidiary companies. ---
RE: Threads availability and support
Ivor Williams writes:
Nicholas Clark [mailto:[EMAIL PROTECTED]] wrote on 15 January 2002 21:42:
I believe that ithreads were experimental in 5.6
(in that there was no perl level interface to make a thread, but the
underlying ithreads mechanism is what is used to fake fork() on Windows)
Fake fork() sounds useful for getting round the nasty NT nested scripts
problem (which a couple of years ago stopped me installing Perl directly on
an NT box - I used a Win95 workstation to do the install, putting the files
on a shared drive).
Does this enable perl system() and backticks to work properly on NT?
I don't think it has any relation, as they have always worked fine for
me, as far as I can remember, and I have been using Perl on NT since
all you could get was a DOS version of Perl 4. I remember hearing of
some people having problems but I thought they were usually due to NT
config issues.
[P.S. Wave when you read this, you are probably only about 20 feet away
:-)]
--
Brian Raven
switch (ref $@) {
OverflowError =
warn Dam needs to be drained;
DomainError =
Re: OT perl question
Sam Vilain wrote: On Wed, 16 Jan 2002 09:20:49 +0100 Newton, Philip [EMAIL PROTECTED] wrote: FYI, the Xitami web server (at least on Win32 systems) doesn't output any of the CGI's output to the client until the CGI is done, so perhaps it implements CGI with STDOUT directed to a file I thought that was just how pipes work in DOS. DOS, yes, but AFAIK Win32 has proper pipes. And this isn't something written using a DOS extender, I'm assuming, but rather with the Win32 API. AFAIK, Apache manages to pass content along to the client as soon as it receives it from the CGI program, even on Win32. Cheers, Philip -- Philip Newton [EMAIL PROTECTED] All opinions are my own, not my employer's. If you're not part of the solution, you're part of the precipitate.
Re: OT perl question
On Wed, 2002-01-16 at 07:03, Newton, Philip wrote: AFAIK, Apache manages to pass content along to the client as soon as it receives it from the CGI program, even on Win32. Nope, at least not yet. It's been going to be fixed in the next release for quite a while. 2.0 though. Yep, it'll be fixed then, -- mike
Of meetings technical and social
I know a few people have been muttering about technical meetings, and I did say it was 'provisionally' on the 17th. However, due to me being rubbish at this leadership lark, the meeting's only just getting finalised. So, barring any last minute problems (sorry, Dave [0], I couldn't bring myself to use your phrase), details of the tech meet are: At: Codix.net (where we held the last one) On: Thursday 24th January, probably at 7pm (will confirm) So far we have three speakers; more would be appreciated, or I'll force a talk on some IRC idiocy on you all. We don't have a projector, so anyone who can offer would win kudos (and probably be bought a pint or two, at least). The next social meeting is on the usual date (7th February) at the Cittie of Yorke, where the first London.pm meeting was held. Kate has already booked a room, so there should be plenty of space. Phew. [0] Hodgkinson, if you're not sure which Dave -- :: paul :: husk
issues with WWW::Search::Scraper
i was just fooling about with WWW::Search::Scraper::Google, and come
across odd problems. am i just having late-night code blindness, and does
anyone here know that source tree well? i've spent a lot of the last
couple of hours trailing through WWW::Search* trying to see what's going
wrong.
(incidentally, google blocks the WWW::Search::Scraper default user
agent string now, which may have caused issues with dipsy?)
this should be, is, a very simple script to google search on a gang of
integers and return the url of the 'i feel lucky' result. i don't know
why. it's going to be art, okay?
#!/usr/bin/perl
use strict;
use WWW::Search::Scraper;
foreach my $q (1 .. 20) {
my $search = new WWW::Search::Scraper('Google');
$search-native_query(WWW::Search::escape_query($q));
my $r = $search-next_result;
print $q: . $r-title . . $r-url . \n;
}
that's it. but when i run it, each time the $r object, (which is in the
WWW::Search::Scraper::Response class, a subclass of WWW::SearchResult)
returns the right title, but *always returns the url of the first
search result*, and i just can't see why.
(btw the first four results this script returns are actually the same,
but i get the same behaviour if i start at 5, where they're all
different)
i Dumped the little buggers, $r-{url} and $r-{urls} are both undef, and
the $r object after the 5th iteration doesnt have any knowledge of the
original url inside it. in the end, i got the data i wanted out by peeking
inside the hash returned by $r-results and parsing the cache url , but
that was probably an unfriendly and short-term thing to do.
i tried requiring WWW::Search::Scraper in an eval each time through the
loop, and that didnt make any difference, though i probably shouldnt
expect it to. i tried dumb things like changing the variable names in case
it was some trivial exporting thing. (i turned off warnings cos
WWW::Search::Scraper spews out a bunch of 'uninitialised values' under
5.6, but they didnt seem crucial...) i had a good rattle through the code
but got a bit lost - it's late, and i'm quite rusty perlwise.
can anyone illuminate this? i assume this is the root of dipsy's googling
problems as well, and would help fix...
jo
