[17889] in Perl-Users-Digest
Perl-Users Digest, Issue: 49 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 12 14:06:34 2001
Date: Fri, 12 Jan 2001 11:05:14 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <979326313-v10-i49@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 12 Jan 2001 Volume: 10 Number: 49
Today's topics:
Re: Ada feature borrowed for Perl?? (Mark Jason Dominus)
Re: Ada feature borrowed for Perl?? <iltzu@sci.invalid>
Re: Ada feature borrowed for Perl?? (Mark Jason Dominus)
Re: Archive::Zip - any user comments? <comdog@panix.com>
Re: can I chdir(DIRHANDLE)? nobull@mail.com
Finding memory leaks in a Perl program <nagle@animats.com>
Getting files off remote servers <scarroll@sci-design.com>
Re: Getting files off remote servers (Mark Jason Dominus)
Re: Getting files off remote servers (Reto Hersiczky)
Re: Getting files off remote servers <mischief@velma.motion.net>
Re: HTTP::Request encoding query nobull@mail.com
Re: HTTP::Request encoding query <flavell@mail.cern.ch>
Re: Jobs: Senior Software Engineer (Randal L. Schwartz)
Re: Jobs: Senior Software Engineer (Randal L. Schwartz)
Re: Jobs: Senior Software Engineer <mischief@velma.motion.net>
Re: Jobs: Senior Software Engineer <juex@deja.com>
Re: Jobs: Senior Software Engineer <elijah@workspot.net>
Re: Jobs: Senior Software Engineer <comdog@panix.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 12 Jan 2001 16:14:12 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <3a5f2d53.4e2e$30a@news.op.net>
In article <978374927.4396@itz.pp.sci.fi>,
Ilmari Karonen <usenet11323@itz.pp.sci.fi> wrote:
>In article <3a50aee2.3873$2eb@news.op.net>, Mark Jason Dominus wrote:
>>
>>With 'elsif' being the 'one you use every day'.
>
>Hey, you're right! Though that's just because the only script that
>"grep -l elsif perl/*" turned up is the one I use to post to Usenet.
>
>I understand the point of having "elsif", but in my experience it's a
>particularly rarely needed feature, unless you're fond of spaghetti
>code.
Interesting. I wonder how you manage to avoid it?
Here are some elsifs I wrote in recent programs:
A.
if (param('age') eq "") {
push @ERRORS, "You omitted your age!";
} elsif (param('age') =~ /\D/) {
push @ERRORS, "Your age should be a number!";
}
I think this is the prototypical example. You cannot use a dispatch
table here.
B.
if ($STATE eq 'show_first_page') {
...
} elsif ($STATE eq 'check_page_1') {
...
} elsif ($STATE eq 'check_page_2') {
...
}
This example would have been well-served by a dispatch table. (The
word 'STATE' is a dead giveaway.) If I had been writing the code for
production, instead of as an example for a CGI class, I would probably
have used a dispatch table here.
C.
if (param()) {
# (update database)
} elsif (defined(my $pid = get_person())) {
# (display information about database record #$pid)
} else {
# (display form)
}
D.
sub get_person {
if (my $pi = path_info()) {
$pi =~ tr{/}{}d;
return $pi eq '' ? undef : $pi;
} elsif (defined(my $p = param('person'))) {
return $p;
} else {
return;
}
}
Here I might have used something more like
return path_info() || param('person')
except that the logic is just a little too complicated---there is no
way to get the defined() test or the tr///d into the right place if
you do that. However, I could have replaced the elsif:
sub get_person {
if (my $pi = path_info()) {
$pi =~ tr{/}{}d;
return $pi eq '' ? undef : $pi;
} else
return param('person');
}
}
This shortens the code, which is good, but it is no longer clear that
the possibly undefined return value is not an oversight. I think the
original code makes the intention clearer.
E.
my $resp = $ua->request($req);
if (! $resp->is_success) {
push @bad_urls, $url;
} elsif ($resp->content_type eq 'text/html') {
push @QUEUE, links($url, $resp->content);
++$HTML;
}
This is another typical example. How do you write this sort of logic
without 'elsif'? It seems perfectly natural to me, and it even reads
the way I would explain the logic in English: "If the request is
unsuccessful, put the url into the list of bad urls; or else if the
request yielded HTML, get the links from it and put them in the
queue."
F.
if ($MODE eq 'show') {
...
} elsif ($MODE eq 'set') {
...
} elsif ($MODE eq 'check') {
...
}
This one clearly could have been a dispatch table.
G.
while (<>) {
if (/^begin (\d\d\d) (.*)/) {
...
open F, ...;
$open = 1;
} elsif (/^end/) {
close F;
$open = 0;
} elsif ($open) {
print F ...;
}
}
H.
if (defined $opt_A) {
$ua->agent($opt_A);
} elsif ($opt_m) {
$ua->agent('Mozilla/3.04 (X11; I; Linux 2.2.12 i586)');
} else {
$ua->agent("Site Copier ($ADDRESS)" . $ua->agent);
}
I.
if ($main::opt_C) {
# (get credentials from $opt_C)
} elsif (-t) {
# (get credentials from STDIN)
} else {
return (undef, undef)
}
J.
if (/^-{12}/) {
# (emit the recently-seen section of the document)
undef $title;
...
} elsif (! $title && /\S/) {
$title = $_;
}
Looking these over, I don't draw any especially enlightening
conclusions about my usage patterns for 'elsif'. But I find myself
more rurpsied than ever that you don't use it. How would you have
written (E) or (I) for example?
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f|ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 12 Jan 2001 17:52:02 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <979318857.3741@itz.pp.sci.fi>
In article <3a5f2d53.4e2e$30a@news.op.net>, Mark Jason Dominus wrote:
>In article <978374927.4396@itz.pp.sci.fi>,
>Ilmari Karonen <usenet11323@itz.pp.sci.fi> wrote:
>>
>>I understand the point of having "elsif", but in my experience it's a
>>particularly rarely needed feature, unless you're fond of spaghetti
>>code.
>
>Interesting. I wonder how you manage to avoid it?
Probably by thinking differently. I suppose I tend to break up
problems in ways which usually result in either nested if blocks, or
short-circuit failure handling using die, return or next.
If you tend to break up problems into a parallel set of possibilities,
I suppose you'd tend to use elsif more often. Neither approach is
inherently better in all cases -- I just recently posted example code
using elsif, which I'd first written using nested ifs and then cleaned
up to use elsif since it looked better in that particular case.
The above is completely unrelated to the fact that I also tend to
avoid elsif in cases where the code in the blocks might end up longer
than half a dozen lines. In those cases nested ifs, with the extra
indentation they cause, IMHO help readability. A single elsif line
gets easily lost in the noise.
(Below, I've snipped all examples where you've mentioned a dispatch
table yourself, since I agree with you on all of those.)
>A.
> if (param('age') eq "") {
> push @ERRORS, "You omitted your age!";
> } elsif (param('age') =~ /\D/) {
> push @ERRORS, "Your age should be a number!";
> }
>
>I think this is the prototypical example. You cannot use a dispatch
>table here.
I might write that, but more likely I'd short-circuit:
push(@ERRORS, "You omitted your age!"), last
if param('age') eq "";
push(@ERRORS, "Your age should be a number!"), last
if param('age') =~ /\D/;
>C.
> if (param()) {
> # (update database)
> } elsif (defined(my $pid = get_person())) {
> # (display information about database record #$pid)
> } else {
> # (display form)
> }
That's a funny one. I'd really have to see more context to say what
I'd do. If I had those program paths to choose from, I would probably
write something like you did. But somehow I tend to do my high level
program design so that I rarely end up with such a three-way choice,
and I can't entirely consciously describe how I do it.
>D.
[snip]
> sub get_person {
> if (my $pi = path_info()) {
> $pi =~ tr{/}{}d;
> return $pi eq '' ? undef : $pi;
> } else
> return param('person');
> }
> }
>
>This shortens the code, which is good, but it is no longer clear that
>the possibly undefined return value is not an oversight. I think the
>original code makes the intention clearer.
I'd have written:
return param('person') # might be undef
>E.
>
> my $resp = $ua->request($req);
> if (! $resp->is_success) {
> push @bad_urls, $url;
> } elsif ($resp->content_type eq 'text/html') {
> push @QUEUE, links($url, $resp->content);
> ++$HTML;
> }
>
>This is another typical example. How do you write this sort of logic
>without 'elsif'? It seems perfectly natural to me, and it even reads
>the way I would explain the logic in English: "If the request is
>unsuccessful, put the url into the list of bad urls; or else if the
>request yielded HTML, get the links from it and put them in the
>queue."
This is a good one. I wouldn't have written it like that, but I'm not
entirely sure how, then. Two possibilities that occur to me:
# 1. short-cicuit (assuming a loop around this)
my $resp = $ua->request($req);
push(@bad_urls, $url), next URL unless $resp->is_success;
push(@QUEUE, links($url, $resp->content)), ++$HTML
if $resp->content_type eq 'text/html';
# 2. nested ifs
my $resp = $ua->request($req);
if ($resp->is_success) {
push(@QUEUE, links($url, $resp->content)), ++$HTML
if $resp->content_type eq 'text/html';
} else {
push @bad_urls, $url;
}
>G.
>
> while (<>) {
> if (/^begin (\d\d\d) (.*)/) {
> ...
> open F, ...;
> $open = 1;
> } elsif (/^end/) {
> close F;
> $open = 0;
> } elsif ($open) {
> print F ...;
> }
> }
Yes, I think I'd use elsif there. It's the cleanest solution.
>H.
>
> if (defined $opt_A) {
> $ua->agent($opt_A);
> } elsif ($opt_m) {
> $ua->agent('Mozilla/3.04 (X11; I; Linux 2.2.12 i586)');
> } else {
> $ua->agent("Site Copier ($ADDRESS)" . $ua->agent);
> }
$ua->agent( defined $opt_A ? $opt_A
: $opt_m ? 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)'
: "Site Copier ($ADDRESS)" . $ua->agent );
But maybe that's just my fascination with ?: -- let's try without:
my $agent = "Site Copier ($ADDRESS)" . $ua->agent;
$agent = 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)' if $opt_m;
$agent = $opt_A if defined $opt_A;
$ua->agent($agent);
Okay, it's not as nice -- but that's why I would normally use ?:.
>I.
>
> if ($main::opt_C) {
> # (get credentials from $opt_C)
> } elsif (-t) {
> # (get credentials from STDIN)
> } else {
> return (undef, undef)
> }
if ($main::opt_C) {
# (get credentials from $opt_C)
return($user, $pass);
}
if (-t) {
# (get credentials from STDIN)
return($user, $pass);
}
return(undef, undef);
I might also use a nested if, but this looks like a perfect case for
short-circuiting.
>J.
>
> if (/^-{12}/) {
> # (emit the recently-seen section of the document)
> undef $title;
> ...
> } elsif (! $title && /\S/) {
> $title = $_;
> }
$title = $_, next LINE if !$title and /\S/;
if (/^-{12}/) {
# (emit the recently-seen section of the document)
undef $title;
}
>Looking these over, I don't draw any especially enlightening
>conclusions about my usage patterns for 'elsif'. But I find myself
You don't use 'next' as much as I do? Nor statement modifiers?
>more rurpsied than ever that you don't use it. How would you have
Is that an interesting typo for 'surprised'? It looks almost like
something that might eventually end up in the Jargon File..
>written (E) or (I) for example?
Short circuit with next/return/die.
HTH. I don't consider this a particularly important issue, but IMO
it's interesting to compare personal coding styles in the process.
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"no one could take it seriously, though lots of people have."
-- Ian A. York in rec.arts.sf.composition
------------------------------
Date: Fri, 12 Jan 2001 18:47:31 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <3a5f5142.51f6$200@news.op.net>
Keywords: Somerville, ppm, prostheses, vague
In article <979318857.3741@itz.pp.sci.fi>,
Ilmari Karonen <usenet11334@itz.pp.sci.fi> wrote:
> push(@ERRORS, "You omitted your age!"), last
> if param('age') eq "";
> push(@ERRORS, "Your age should be a number!"), last
> if param('age') =~ /\D/;
Very interesting. I would have considered that 'spaghetti code', and
I would have been embarrassed to write it. (That is not intended as a
criticism of any kind.)
> $ua->agent( defined $opt_A ? $opt_A
> : $opt_m ? 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)'
> : "Site Copier ($ADDRESS)" . $ua->agent );
>
>But maybe that's just my fascination with ?: -- let's try without:
I was wondering if you were going to say that. Of course, ?:?: is
just an abbreviated form of if-elsif.
> if ($main::opt_C) {
> # (get credentials from $opt_C)
> return($user, $pass);
> }
>
> if (-t) {
> # (get credentials from STDIN)
> return($user, $pass);
> }
>
> return(undef, undef);
>
>I might also use a nested if, but this looks like a perfect case for
>short-circuiting.
Yes. This is the only one of your examples where I also felt I might
have written it your way.
>>
>> if (/^-{12}/) {
>> # (emit the recently-seen section of the document)
>> undef $title;
>> ...
>> } elsif (! $title && /\S/) {
>> $title = $_;
>> }
>
> $title = $_, next LINE if !$title and /\S/;
>
> if (/^-{12}/) {
> # (emit the recently-seen section of the document)
> undef $title;
> }
Here you changed the semantics, because you will now accept
"------------------" as a title; in this program that behavior is
incorrect.
>>Looking these over, I don't draw any especially enlightening
>>conclusions about my usage patterns for 'elsif'. But I find myself
>
>You don't use 'next' as much as I do? Nor statement modifiers?
I use them frequently, but not nearly as much as you do.
For example, here's (E) again:
>>
>> my $resp = $ua->request($req);
>> if (! $resp->is_success) {
>> push @bad_urls, $url;
>> } elsif ($resp->content_type eq 'text/html') {
>> push @QUEUE, links($url, $resp->content);
>> ++$HTML;
>> }
Here's the surrounding code:
while (@QUEUE) {
my $url = shift @QUEUE;
next if $visited{$url};
next if host_of($url) ne $mainhost;
my $req = HTTP::Request->new('GET' => $url);
my $resp = $ua->request($req);
if (! $resp->is_success) {
push @bad_urls, $url;
} elsif ($resp->content_type eq 'text/html') {
push @QUEUE, links($url, $resp->content);
++$HTML;
}
$visited{$url} = 1;
}
Following your style, this might become:
while (@QUEUE) {
my $url = shift @QUEUE;
next if $visited{$url};
next if host_of($url) ne $mainhost;
my $req = HTTP::Request->new('GET' => $url);
my $resp = $ua->request($req);
push(@bad_urls, $url), next URL unless $resp->is_success;
push(@QUEUE, links($url, $resp->content)), ++$HTML
if $resp->content_type eq 'text/html';
$visited{$url} = 1;
}
I think the difference in our styles might be summarized: I like
"a if c" and "next if c"; I dislike "a,b if c" and "a, next if c".
Taking it in the other direction, we might get something more like this:
while (@QUEUE) {
my $url = shift @QUEUE;
if ($visited{$url} || host_of($url) ne $mainhost) {
# ignore it
} else {
my $req = HTTP::Request->new('GET' => $url);
my $resp = $ua->request($req);
if (! $resp->is_success) {
push @bad_urls, $url;
} elsif ($resp->content_type eq 'text/html') {
push @QUEUE, links($url, $resp->content);
++$HTML;
}
$visited{$url} = 1;
}
}
Here I think the 'next' is an obvious improvement over '# ignore it'.
It gets even worse the farther you push it:
while (@QUEUE) {
my $url = shift @QUEUE;
if ($visited{$url} || host_of($url) ne $mainhost) {
# ignore it
} elsif (!(my $resp = $ua->request(HTTP::Request
->new('GET'=>$url)))
->is_success)) {
push @bad_urls, $url;
$visited{$url} = 1;
} elsif ($resp->content_type eq 'text/html') {
push @QUEUE, links($url, $resp->content);
++$HTML;
$visited{$url} = 1;
}
}
Here you have to duplicate the assignment to %visited, and the second
condition is skanky.
>I don't consider this a particularly important issue, but IMO
>it's interesting to compare personal coding styles in the process.
I agree.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f|ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Fri, 12 Jan 2001 12:37:01 -0500
From: brian d foy <comdog@panix.com>
Subject: Re: Archive::Zip - any user comments?
Message-Id: <comdog-C5A4CC.12370112012001@news.panix.com>
In article <93mklr$sj8$1@soap.pipex.net>, "Geoff Winkless"
<geoff-at-farmline-dot-com@127.0.0.1> wrote:
> "brian d foy" <comdog@panix.com> wrote in message
> news:comdog-F506A4.13011111012001@news.panix.com...
> : i always had problems with it creating "inconsistent headers" or
> : some such. i ended up using an external zip program to do that
> : work. otherwise, i liked the module.
> So no problems with decompression? I only want to use it to extract files,
> not create archives.
i never tried it for that. i was always going the other way. YMMV.
--
brian d foy - mod_perl hacker for hire <comdog@panix.com>
------------------------------
Date: 12 Jan 2001 18:05:44 +0000
From: nobull@mail.com
Subject: Re: can I chdir(DIRHANDLE)?
Message-Id: <u9itnkir2f.fsf@wcl-l.bham.ac.uk>
"Antoine Beaupre (LMC)" <lmcabea@lmc.ericsson.se> writes:
> opendir(FROM, ".");
> # do something
> chdir(FROM);
>
> that would be less error-prone and more portable.
Hardly! This would require Perl to call fchdir() in the underlying
OS. fchdir() is much less portable than chdir().
> Any idea on that?
I'd expect there'd be a module on CPAN that provides a Perl interface
to fchdir (on systems that support it). I'll just go look... looks
like I'm wrong search.cpan.org gives no hits for fchdir.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Fri, 12 Jan 2001 10:18:57 -0800
From: John Nagle <nagle@animats.com>
Subject: Finding memory leaks in a Perl program
Message-Id: <3A5F4A91.D49DB2D4@animats.com>
I have a Perl program with a sizable memory leak, and I can't
find the leak. The program grows from 13MB to 100MB while running.
The program uses HTML::TreeBuilder, which can
create circular references, but I call $tree->delete() when done
with the tree.
The program uses LWP, makes about 5000 queries, and
uses a new LWP object every time. The LWP object is local
and should be destroyed at block exit.
Any known leaks in that area?
Are there any tools for analyzing memory leaks? The debugger
doesn't seem to offer anything in this area.
Thanks.
Perl 5.6.0 (Win32, ActiveState)
All CPAN packages are up to date.
John Nagle
Downside.com
------------------------------
Date: Fri, 12 Jan 2001 16:30:09 -0000
From: Stuart Carroll <scarroll@sci-design.com>
Subject: Getting files off remote servers
Message-Id: <t5uc8hap9olp53@corp.supernews.com>
Is it possible to get a Perl cgi script to open up a file that's located on
a different server? Say I want my script to fetch a html page located on a
different site, and skim through it to get some information, or check to
see the last time it was updated - is this possible?
And is it possible to do this if the other page is dynamically generated
rather than hard-coded? I want my script to call a cgi program on someone
else site and treat the resulting response the same way I would a file
opened on my own server - can I do this?
(Just as an aside, this isn't intended for any nefarious pupose, like
stealing someone's pages, or gathering email addresses for spam)
Thanks
Stuart Carroll
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Fri, 12 Jan 2001 16:49:08 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Getting files off remote servers
Message-Id: <3a5f3584.4f18$217@news.op.net>
Keywords: continue, inquisitor, insecticide, neutral
In article <t5uc8hap9olp53@corp.supernews.com>,
Stuart Carroll <scarroll@sci-design.com> wrote:
>Is it possible to get a Perl cgi script to open up a file that's located on
>a different server? Say I want my script to fetch a html page located on a
>different site, and skim through it to get some information, or check to
>see the last time it was updated - is this possible?
use LWP::Simple;
my $html = get('http://perl.plover.com/perl.html');
>And is it possible to do this if the other page is dynamically generated
>rather than hard-coded?
Not only is it possible, but there is no way for your program to tell
the difference.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f|ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 12 Jan 2001 17:06:09 GMT
From: fight_against_spam_cut_here_retoh@dplanet.ch (Reto Hersiczky)
Subject: Re: Getting files off remote servers
Message-Id: <Xns9027BEB6Cfightagainstspamcuth@195.141.200.222>
Remember, in Perl, easy things are easy, and hard things are possible
(mostly ;) --from the Perl Cook Book
The easiest way is to use LWP, as far as your requested file
is accessible from a web server's document path:
use LWP::UserAgent;
my $ua = LWP::UserAgent->new(agent => "$ENV{'SCRIPT_NAME'} V$VERSION");
my $request = HTTP::Request->new('GET', 'http://localhost');
my $response = $ua->request($request);
print "Content-type: text/plain\n\n";
unless ($response->is_success) {
print $response->error_as_HTML . "\n";
print "Could not connect to server\n";
exit(1);
}
my $Result = $response->content(); # content without HTTP header
print $Result;
If your need is to fetch a file beyond the web servers document
root, you have to hack one more CGI script on the remote machine
which slurps the requested file and prints its content to STDOUT.
Check out also from CPAN:
Net::FTP
State-of-the-art would be to install rsync (http://www.rsync.org),
which would be the most performant and secure solution anyway....
--Reto
Stuart Carroll <scarroll@sci-design.com> wrote in
<t5uc8hap9olp53@corp.supernews.com>:
>Is it possible to get a Perl cgi script to open up a file that's located
>on a different server? Say I want my script to fetch a html page
>located on a different site, and skim through it to get some
>information, or check to see the last time it was updated - is this
>possible?
>
>And is it possible to do this if the other page is dynamically generated
>rather than hard-coded? I want my script to call a cgi program on
>someone else site and treat the resulting response the same way I would
>a file opened on my own server - can I do this?
>
>(Just as an aside, this isn't intended for any nefarious pupose, like
>stealing someone's pages, or gathering email addresses for spam)
>
>Thanks
>
>Stuart Carroll
------------------------------
Date: Fri, 12 Jan 2001 18:17:31 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Getting files off remote servers
Message-Id: <t5uihrb1ojca30@corp.supernews.com>
Stuart Carroll <scarroll@sci-design.com> wrote:
> Is it possible to get a Perl cgi script to open up a file that's located on
> a different server? Say I want my script to fetch a html page located on a
> different site, and skim through it to get some information, or check to
> see the last time it was updated - is this possible?
Using many different methods, yes, this is possible.
> And is it possible to do this if the other page is dynamically generated
> rather than hard-coded? I want my script to call a cgi program on someone
> else site and treat the resulting response the same way I would a file
> opened on my own server - can I do this?
The method to use here is LWP. Check Cpan. When you see a question
about getting a Web page from a Web server, think, "LWP".
> (Just as an aside, this isn't intended for any nefarious pupose, like
> stealing someone's pages, or gathering email addresses for spam)
I hope not. However, let me tell you my feelings on that.
Programming is a lot like fire, talk radio, guns, or what the
occultists say about magic. It is not the tool that is good or evil,
only the person using it. That is to say, you can use a tool towards
benevolent ends or towards malevolent ends, and can use it in
benevolent ways or malevolent ways to reach those ends, but the tools
themselves are blameless.
Chris
--
Christopher E. Stith
Parking for people we like only. All other vehicles will be vandalized.
------------------------------
Date: 12 Jan 2001 18:07:03 +0000
From: nobull@mail.com
Subject: Re: HTTP::Request encoding query
Message-Id: <u9g0ioir08.fsf@wcl-l.bham.ac.uk>
iain_hogg@my-deja.com writes:
> Take the following HTTP::Request :
>
> $tgt = 'http://www.acme.com/cgi/test.cgi?val=bar|';
> $req = new HTTP::Request('GET' => $tgt);
>
> Now, when this request is made at some point it is encoded (in iso latin 1 I
> think) into a HTTP request that looks like
>
> GET http://www.acme.com/cgi/test.cgi?val=bar%7C
>
> where '|' has become '%7C'
>
> So what I'd like to know is if there is any way to prevent this encoding
> taking place?
Wouldn't it make more sense to fix the bug in test.cgi?
> I don't mind changing perl source and recompiling if someone
> can point me in the right direction, though obviously I'd prefer not to :)
ISTR that the URI::Escape module actually keeps the characters to be
substuted in a package variable so you can tweak that varaible
directly after loading URI::Escape. For details see source.
BTW: Why do you want to make your LWP not conform to RFC2396?
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Fri, 12 Jan 2001 19:41:34 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: HTTP::Request encoding query
Message-Id: <Pine.LNX.4.30.0101121932210.13422-100000@lxplus003.cern.ch>
On Fri, 12 Jan 2001 iain_hogg@my-deja.com wrote:
(excess quotage now removed)
> The cgi-bin script I'm trying to work with (which I can't change) does not
> unencode its input i.e. change '%7C' back to '|',
Then that's your real problem, but it has nothing to do with
programming in Perl. It would be more on-topic for a group with CGI
in its name.
> so I need to send the cgi-bin arguments un-encoded.
No, you don't. You need a working script, and on the basis of your
postings, it's clear that you haven't got one.
You seem blithely unaware that there is a published interworking
specification, and that you are using a script that doesn't follow
that specification. On that basis, there could well be a lot of other
things wrong with the script, including security exposures.
You'd be well advised to carefully study the relevant FAQs.
(I'm thinking it's time I added my-deja to at least the scorefile, if
not the killfile.)
------------------------------
Date: 12 Jan 2001 07:58:16 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <m1d7dsu5if.fsf@halfdome.holdit.com>
>>>>> "Terrence" == Terrence Brannon <brannon@lnc.usc.edu> writes:
Terrence> can we make a move to have comp.lang.perl.jobs created? I think this
Terrence> would be a great thing.
Yes, there are procedures for that. It'll take a lot of will, and
about 90 days minimum, and probably get "boo-hooed" by the news.admin
cartel since there are already job areas under misc.jobs.
If anything, you'll be told "it should be misc.jobs.offered.perl", and
then they'll wonder why Perl is so special that people can't simply
grep for "perl" in misc.jobs.offered. No other language has a
subcategory there. :)
A much richer source of job postings is the "perl jobs" mailing lists.
Go there if you are offering or wanting a job.
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: 12 Jan 2001 08:00:09 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <m18zogu5fa.fsf@halfdome.holdit.com>
>>>>> "Terrence" == Terrence Brannon <brannon@lnc.usc.edu> writes:
>> A Perl job is certainly a miscelaneous topic regarding Perl.
Terrence> AMEN!!!!!
Terrence> You speak my thoughts better than me Jerome.
But the "misc" here means "things that belong under comp.lang.perl.*
that do not have a more specific group". "jobs" don't belong under
comp.lang.perl in the first place.
So if those are your thoughts, you are less educated than you need to
be. :) Get wise.
print "Just another Perl hacker," # and former news admin, and usenet reader since 1980...
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Fri, 12 Jan 2001 17:19:29 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <t5uf51mvut2i71@corp.supernews.com>
Richard Zilavec <rzilavec@tcn.net> wrote:
> On Thu, 11 Jan 2001 22:58:07 GMT, Terrence Brannon
> <brannon@lnc.usc.edu> wrote:
>>
>>He posted a Perl job posting in a Perl newsgroup. Because this is
>>where Perl programmers are. I don't mind that.
> I think this NG gets enough traffic already, I can't imagine resumes
> and job postings here too.
If I were a recruiter wanting to make use of this newsgroup, I'd
use the group itself AS a resume. Even if I knew nothing of Perl,
I could go through and count how many answers a poster gave that
went uncorrected, and could, from the context of the posts around
a certain person's posts, figure out approximately how much experience
they have.
I'd then check to see if any of those people have actual resumes or
curricula vitae on the net, such as at the web pages listed on
signatures or on monster.com, techies.com, dice.com, or some other
job site. I know that myself, personally, don't have a resume on the
net today, but I do from time to time. Some people here might not
even mind being emailed job offers directly to them, although I'm
sure some would.
Chris
--
Christopher E. Stith
For the pleasure of others, please adhere to the following
rules when visiting your park:
No swimming. No fishing. No flying kites. No frisbees.
No audio equipment. Stay off grass. No pets. No running.
------------------------------
Date: Fri, 12 Jan 2001 10:08:35 -0800
From: "Jürgen Exner" <juex@deja.com>
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <3a5f4823$1@news.microsoft.com>
"Jerome O'Neil" <jerome@activeindexing.com> wrote in message
news:nDr76.2204$dy.423040@news.uswest.net...
> Uri Guttman <uri@sysarch.com> elucidates:
>
> > TB> He posted a Perl job posting in a Perl newsgroup. Because this is
> > TB> where Perl programmers are. I don't mind that.
> >
> > <flame war starting>
> >
> > well, then post anything about any job that is for a company that may
> > have heard about perl in here. there are jobs groups just for that
> > purpose. this group is to discuss perl, not perl jobs.
>
> <dons asbestos pants>
>
> A Perl job is certainly a miscelaneous topic regarding Perl.
You may want to brush-up on the Nettiquette.
Job posting DO NOT, I repeat DO NOT belong in technical NGs.
Or what do you thing the *.job.offered NGs are for?
jue
------------------------------
Date: 12 Jan 2001 18:14:03 GMT
From: Eli the Bearded <elijah@workspot.net>
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <eli$0101121303@qz.little-neck.ny.us>
In comp.lang.perl.misc, Chris Stith <mischief@velma.motion.net> wrote:
> If I were a recruiter wanting to make use of this newsgroup, I'd
> use the group itself AS a resume. Even if I knew nothing of Perl,
> I could go through and count how many answers a poster gave that
> went uncorrected, and could, from the context of the posts around
> a certain person's posts, figure out approximately how much experience
> they have.
That is *way* to much work for a pimp^H^H^H^Hrecruiter. I read this
group in bits regularlly (most topics not selected by my 'killfiles'
don't get read, so maybe I see 5-10% of the traffic here) and I'd
find that a lot of work.
> I'd then check to see if any of those people have actual resumes or
> curricula vitae on the net, such as at the web pages listed on
> signatures or on monster.com, techies.com, dice.com, or some other
> job site.
That's also a lot of work, unless the .sig explicitly mentions
that there is a CV there to read.
> I know that myself, personally, don't have a resume on the
> net today, but I do from time to time. Some people here might not
> even mind being emailed job offers directly to them, although I'm
> sure some would.
I would mind. (I was flattered when I first got them, back in
1995 or 1996, now it is just spam.) If I saw someone here posting
a CV and knew that they had some skill from their posts, I'd
certainly look at it. I'm not hiring anyone and I am not a
recruiter, but my company does have positions open and that filling
some of them (at least) means an easier day for me.
I know brian d foy mentions that he is 'for hire' in his .sig, but
I also know that he would not fit any positions here. (Partially
due to his location, partially because he is a bit too web oriented.)
I don't see others representing themselves as available.
Elijah
------
has always seen 'location' as a big obstacle for Usenet job postings
------------------------------
Date: Fri, 12 Jan 2001 13:48:35 -0500
From: brian d foy <comdog@panix.com>
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <comdog-B8FEB6.13483512012001@news.panix.com>
In article <eli$0101121303@qz.little-neck.ny.us>, Eli the Bearded
<elijah@workspot.net> wrote:
> I know brian d foy mentions that he is 'for hire' in his .sig, but
oh - forgot about that. i'm no longer for hire. maybe that's
why i was still getting offers.
> I also know that he would not fit any positions here. (Partially
> due to his location, partially because he is a bit too web oriented.)
now let's play nice - the web makes me a lot of money and i'm not
ashamed of it :). however, the new job is something other than
the web. indeed, the webmaster here is in corporate communications,
not tech.
> I don't see others representing themselves as available.
i found it hard to stay unemployed, which made it difficult to
collect unemployment checks (which i wanted to at least try once),
and i've had to make almost all of my new hires by luring people
away from other companies.
> Elijah
> ------
> has always seen 'location' as a big obstacle for Usenet job postings
i just convinced the company to open a new york office. that solved
the location problem. someday new york will not only be the Center
of the Universe but the Center of the Perl Universe as well ;)
--
brian d foy - mod_perl hacker for hire <comdog@panix.com>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 49
*************************************
