[27478] in Perl-Users-Digest
Perl-Users Digest, Issue: 9086 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 24 21:05:44 2006
Date: Fri, 24 Mar 2006 18:05:06 -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 Fri, 24 Mar 2006 Volume: 10 Number: 9086
Today's topics:
Re: 533: error: syntax error before "void" <sisyphus1@nomail.afraid.org>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <uri@stemsystems.com>
Re: Great JAPH (was Re: Creating Graphs Dynamically wit <abigail@abigail.nl>
Re: More help requested on permutation code. <jack@abc.net>
Re: Security implications of taking a stylesheet URL fr <bumens@dingens.org>
Re: sockaddr_in() timeout or asynchone call ? <jgibson@mail.arc.nasa.gov>
Re: sockaddr_in() timeout or asynchone call ? <uri@stemsystems.com>
Re: sockaddr_in() timeout or asynchone call ? <no@thanks.com>
Re: sockaddr_in() timeout or asynchone call ? <no@thanks.com>
Re: sockaddr_in() timeout or asynchone call ? <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 25 Mar 2006 08:58:42 +1100
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: 533: error: syntax error before "void"
Message-Id: <44246c47$0$10674$afc38c87@news.optusnet.com.au>
"Ken Rich" <kenr@troi.cc.rochester.edu> wrote in message
.
.
> GD.c
>
> GD.c:533: error: syntax error before "void"
> GD.xs: In function `XS_GD__Image_trueColor':
> GD.xs:545: error: `dMY_CXT' undeclared (first use in this function)
> GD.xs:545: error: (Each undeclared identifier is reported only once
> GD.xs:545: error: for each function it appears in.)
> GD.xs:549: error: `MY_CXT' undeclared (first use in this function)
> GD.xs: In function `XS_GD__Image__new':
> GD.xs:564: error: `dMY_CXT' undeclared (first use in this function)
> GD.xs:565: error: `MY_CXT' undeclared (first use in this function)
> ...and a bunch more like that...
>
>
> Set-up:
>
> Sun V880
> solaris 8
> perl v5.6.1
> GD-2.32
> GD-2.31 tried too.
>
> No Sun compiler, but I am considering installing one and
> going back and compiling perl and libs and EVERYthing using Sun C.
>
Try GD-2.30. It doesn't use those (perl) macros - which are defined in
perl.h on perl 5.8, but apparently missing in perl 5.6.
I'm not sure when they first appeared - probably with 5.8.0. Imho if the
author wants to write code that works only on perl 5.8, he should make that
fact clear - eg by placing code in the Makefile.PL that dies with an
appropriate error message if 5.6 or earlier is used.
Or update to perl 5.8 :-)
Cheers,
Rob
------------------------------
Date: Fri, 24 Mar 2006 18:49:42 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <12294qo14rgk813@corp.supernews.com>
Eric Schwartz wrote:
> Mark Manning <markem@airmail.net> writes:
>
>>Yes, but you are forgetting that people do not update their
>>installation of Perl every time a single change is made to the
>>documentation. Thus, the ones that are on-line would (in most cases)
>>be more up-to-date than the ones on your system. That is just common
>>sense.
>
>
> It is also wrong. The documentation is released at the same time new
> versions of Perl are released; if you use more recent documentation
> than the version of Perl you have, it may well reference syntax,
> modules or functions that don't exist in your version, which is not
> only frustrating, but wrong. You seem to be confusing "up-to-date"
> with "applicable to the version I'm using". That is not sense of any
> kind, common or un-. :)
>
> -=Eric
No. The conversation is not "which version of perl do you have" - it is "where
is the most up-to-date version of the documentation". The most up-to-date
version will be on-line. True, the documentation might refer to a different
version of Perl but it would still be more current than whatever documentation I
might have on my system.
------------------------------
Date: Fri, 24 Mar 2006 18:57:51 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <12295a1kgpeg612@corp.supernews.com>
Abigail wrote:
> Mark Manning (markem@airmail.net) wrote on MMMMDLXXXVI September MCMXCIII
> in <URL:news:12232gsgtrhhq7d@corp.supernews.com>:
> @@
> @@
> @@ Yes, but you are forgetting that people do not update their installation of
> @@ every time a single change is made to the documentation. Thus, the ones tha
> @@ are on-line would (in most cases) be more up-to-date than the ones on your
> @@ system. That is just common sense.
>
>
> Ah, you prefer to use documentation of that doesn't match the version
> of the product you are using. Very useful. I do that all the time.
> I remember the fun we had when the documentation said my TV, which always
> showed pictures in B&W, was able to show colour images.
>
>
>
> Abigail
Ah Abigail, you disappoint me. Not all changes to documentation are so radical
that they totally invalidate all of the prior documentation. For instance, if
the ** function were incorrectly documented as doing E to some power and then
was corrected to be what it is - that does not mean the entire rest of the Perl
documentation has suddenly become invalid.
Further, there are updates and corrections (such as spelling) which are also
corrected without meaning that someone has to totally download and re-install
Perl just to be up-to-date on those either.
------------------------------
Date: Fri, 24 Mar 2006 20:05:14 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: A Problem With GD
Message-Id: <x7d5gbl4fp.fsf@mail.sysarch.com>
>>>>> "MM" == Mark Manning <markem@airmail.net> writes:
MM> No. The conversation is not "which version of perl do you have" -
MM> it is "where is the most up-to-date version of the documentation".
MM> The most up-to-date version will be on-line. True, the
MM> documentation might refer to a different version of Perl but it
MM> would still be more current than whatever documentation I might
MM> have on my system.
where can you find the most up to date documentation for your brain?
the most recent docs on perl are NOT USEFUL for older perls. perl
doesn't change the docs separately from the source tree. the new docs
will cover changes, bug fixes, additions, etc that ARE NOT in your older
perl. it will NOT just be a 'better' or more useful set of docs. being
current is not the issue, being accurate it. very few doc changes go in
that are just pure doc edits as they have been reviewed and edited over
a long period of time by many (hundreds of thousands?) of
readers/users.
just trying to explain why your expectations of newer docs being better
for older perls is a way off target. you can continue to think you are
correct but you are wrong. changing your views about perl's docs and
perl's released code is the correct answer.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 24 Mar 2006 21:20:49 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Great JAPH (was Re: Creating Graphs Dynamically with Perl)
Message-Id: <slrne28olg.c1.abigail@alexandra.abigail.nl>
jussi.mononen-asdf@asdf-comptel.com (jussi.mononen-asdf@asdf-comptel.com)
wrote on MMMMDLXXXVIII September MCMXCIII in <URL:news:e00sip$65r$1@phys-news4.kolumbus.fi>:
-- >> // > Abigail <abigail@abigail.nl> wrote in
-- >> // > news:slrne1eb9n.1v0.abigail@alexandra.abigail.nl:
-- >> // >
-- >> // > > #!/opt/perl/bin/perl -- # No trailing newline after the last line!
-- >> // > > BEGIN{$|=$SIG{__WARN__}=sub{$_=$_[0];y-_--;print/(.)"$/;seek _,-open(_
-- >> // > > ,"+<$0"),2;truncate _,tell _;close _;exec$0}}//rekcaH_lreP_rehtona_tsuJ
-- >> // >
-- >> // > This is an amazing JAPH. Very instructive.
-- >> //
-- >> // Seconded!
-- >>
-- >> The fun is executing the file *twice*.
-- >
-- > That was the original reason I thought this one was extremely impressive.
-- >
-- > It sure is hard to read ;-)
--
-- Thank god for Deparse, we mere mortals would be lost without it.
--
-- [tarzan ~]$ perl -MO=Deparse japh.pl
-- sub BEGIN {
-- $| = $SIG{'__WARN__'} = sub {
-- $_ = $_[0];
-- tr/_/ /;
-- print /(.)"$/;
-- seek _, -open(_, "+<$0"), 2;
-- truncate _, tell _;
-- close _;
-- exec $0;
-- }
-- ;
-- }
-- //;
-- japh.pl syntax OK
--
-- That makes much more sense :-)
But that's the output *after* you ran it.
Try deparsing the program before running it.
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'
------------------------------
Date: Fri, 24 Mar 2006 23:17:10 GMT
From: Michael Press <jack@abc.net>
Subject: Re: More help requested on permutation code.
Message-Id: <jack-1613B5.15171024032006@newsclstr02.news.prodigy.com>
In article <48igj9Fkdg2tU1@news.dfncis.de>,
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote:
> Michael Press <jack@abc.net> wrote in comp.lang.perl.misc:
[...]
> > my $alpha = "(99)(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22)";
> > my $beta = "(99)(0)(3 6 12 1 2 4 8 16 9 18 13)(15 7 14 5 10 20 17 11 22
> > 21 19)";
> > my $gamma = "(99 0)(1 22)(2 11)(3 15)(4 17)(5 9)(6 19)(7 13)(8 20)(10
> > 16)(12 21)(14 18)";
> > my $delta = "(99)(0)(3)(15)(1 18 4 2 6)(5 21 20 10 7)(8 16 13 9 12)(11
> > 19 22 14 17)";
> > my $x;
>
> What are all the single-element cycles for? They map to the unit
> permutation and have no effect.
These are (redundant) generators of a real world group. As
you see in the next bit of code, if the singletons were
not present in $beta, then the result of
permutation_multiply $beta and
permutation_multiply ($alpha x 2 ...
would not be the same.
But more importantly these are generators of
PSL_2 (GF_23), the group of automorphisms over the
projective line in GF_23. GF_23 has 23 elements:
{0, 1, ... 23}. The projective line has 24 elements:
{infinity, 0, 1, ... 23}. (I use 99 for infinity).
Since the permutation beta is an automorphism, we must
define its behavior on every point. The fixed points of
group elements are important in the analysis, so it is
better when reading to see the singletons explicitly,
rather than trying to infer them. For instance
(alpha delta)^3 = (0) (1) (5) (6) (18) (20) (22) (99)
(2 3) (4 15) (7 8) (9 11) (10 19) (12 16) (13 21) (14 17)
The group is the Mathieu group M_24.
It is generated by alpha and (gamma delta^2).
The automorphisms have algebraic expressions:
z alpha = z + 1
z beta = 2z
z gamma = -1/z
delta is a bit more complicated.
Here are more relations:
print "beta = alpha^5 gamma alpha^5 gamma alpha^14 gamma
alpha^18 \n";
print "(alpha^13 gamma delta^2)^3 has shape 4^6\n";
print "delta alpha^2 is 1^3 7^3 \n";
print "(alpha delta)^3 has shape 1^8 2^8\n";
print "gamma delta^2 \n";
print "(gamma delta^2)^5 = gamma \n";
print "(gamma delta^2)^8 = delta \n";
print "beta gamma delta^2 = gamma delta^2 beta^2 \n";
print "alpha^5 delta has shape 1^2 2^1 4^1 8^2\n";
print "delta alpha^11 has shape 1^1 3^1 5^1 15^1\n";
print "(delta alpha^11)^5 has shape 1^6 3^6\n";
> > print "beta = alpha^5 gamma alpha^5 gamma alpha^14 gamma alpha^18 \n";
> > $x = ($alpha x 5 . $gamma) x 2 . $alpha x 14 . $gamma . $alpha x 18;
> > permutation_multiply $x;
> > $x = $beta;
> > permutation_multiply $x;
> > print "\n";
> >
> > print "(alpha^13 gamma delta^2)^3 has shape 4^6\n";
> > $x = (($alpha x 13) . $gamma . ($delta x 2)) x 3;
> > permutation_multiply $x;
> > print "\n";
> >
> > ________________END________________
>
> One of my projects in the almost-done limbo is a permutation class. It
> overloads permutation objects so that multiplication (x) and exponentiation
> (**) can be applied directly. I had an hour of fun adapting it to the
> problem at hand. The adaption is mainly in the stringification of
> permutations and in the addition of a special creator (new_from_cyc_str)
> to deal with the given formats.
>
> The code (incompletely tested) is appended below. The printed results
> are equivalent to those of the original code.
Well, it will take me a bit of study. :)
--
Michael Press
------------------------------
Date: 24 Mar 2006 22:50:32 +0100
From: Volker Birk <bumens@dingens.org>
Subject: Re: Security implications of taking a stylesheet URL from a CGI parameter
Message-Id: <442469a8@news.uni-ulm.de>
In comp.security.misc Scott W Gifford <gifford@umich.edu> wrote:
> The goal is to limit the possibility of doing something like:
> http://10.0.0.5:445/
> to cause the client machine to connect to a fileserver in their
> internal network.
Then you'd better remove access of this machine to your internal network
for such purposes completely. Additionally, you could filter out URLs
which are resulting in internal network addresses.
You're wrong to have constraints for the port number then.
> >> and
> >> require the filename to end with ".css" (to make it more difficult to
> >> cause a script to run).
> > This is unneccessary.
> The goal here is to reduce the possibility of doing something like:
> http://www.somesite.com/runsomething.cgi
Why? I cannot see any security drawback from this.
> >> Something like this:
> >> /^https?:\/\/[\w.-]+\/[\w\/:.-]+\.css$/
> > Why not implementing RFC1738, 3.3 exactly?
> I explicity don't want to allow some of the reserved characters
> mentioned in section 2.2 of that RFC, to make it impossible to send
> queries. Like the above restriction, I expect this to reduce the risk
> of running executable content.
Hm...
Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain
------------------------------
Date: Fri, 24 Mar 2006 11:23:22 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: sockaddr_in() timeout or asynchone call ?
Message-Id: <240320061123222856%jgibson@mail.arc.nasa.gov>
In article <MPG.1e8e18b63959a2469897a0@news.tiscali.fr>, Asterbing
<no@thanks.com> wrote:
> Hello,
>
> Is it possible to do that a code like the one described on the chapter
> 42.6.2 called "WebGet Client" on the Perl manual, be not a locking point
> for the rest of the script ?
Which Perl manual? I have several. None of them come close to having 42
Chapters. Does your Perl manual have a title? An author? A publisher?
An edition number? Maybe it would be easier if you just posted the
code.
>
> Effectively, the sockaddr_in() freeze the script if the remote host is
> not available.
Curious. The sockaddr_in function (of the Socket module) packs and
unpacks interaddress protocol addresses. It does no input or output. It
is hard to see how it could possibly "freeze". Maybe it is something
else in your program that is blocking. Of course, it is hard to tell
without seeing your program.
>
> Is there a way to reduce the timeout or, better, to do that this call be
> asynchroneous (don't taliking about waiting of the response since in the
> first case I've to treat, this GET response isn't necessary for the rest
> of the script - the matter is just to launch a remote cgi which will
> live its life by itself).
The choice to prevent a program blocking on I/O usually involves either
non-blocking I/O (polling) or asynchronous I/O (e.g, the select
statement or forking/threading). Both have their complications.
See 'perldoc -f select' or 'perldoc IO::Select' (your platform may
affect your results.)
--
Jim Gibson
------------------------------
Date: Fri, 24 Mar 2006 16:57:40 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: sockaddr_in() timeout or asynchone call ?
Message-Id: <x7hd5nmror.fsf@mail.sysarch.com>
>>>>> "JG" == Jim Gibson <jgibson@mail.arc.nasa.gov> writes:
JG> The choice to prevent a program blocking on I/O usually involves
JG> either non-blocking I/O (polling) or asynchronous I/O (e.g, the
JG> select statement or forking/threading). Both have their
JG> complications.
you are conflating several things there. the blocking nature of the
socket has nothing to do with whether you use select on it. and select
has nothing to do with forking/threads. and async i/o can means using
the OS's async i/o ops or an event loops that supports it or even using
threads. so you can pretty much mix and match all of those things and
you don't have an either/or situation.
but i agree with your main assessment, sockaddr_in just does some simple
IP address munging and should never block. the OP is confused or
misunderstood something.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sat, 25 Mar 2006 00:33:58 +0100
From: Asterbing <no@thanks.com>
Subject: Re: sockaddr_in() timeout or asynchone call ?
Message-Id: <MPG.1e8ea03d16538dd09897a1@news.tiscali.fr>
In article <240320061123222856%jgibson@mail.arc.nasa.gov>,
jgibson@mail.arc.nasa.gov says...
> Which Perl manual? I have several. None of them come close to having 42
> Chapters. Does your Perl manual have a title? An author? A publisher?
> An edition number? Maybe it would be easier if you just posted the
> code.
Of course. Here is the doc : <http://perl.enstimac.fr/perl-all-fr-
pdf.pdf> and here is the code I'm using in a sub :
StatsRelay()
{
use IO::Socket;
my $host = "www.domain.com";
my $path = "/cgi-bin/stats.cgi?a=2&t=12&z=27&rz=102";
my $port = 8080;
if ($host eq "" or $path eq ""){ return(0);}
my $iadr = inet_aton($host) || return(0);
my $padr = sockaddr_in($port, $iadr);
my $proto = getprotobyname('tcp');
socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0);
if(!connect(hpSOCK, $padr)){return(0);}
hpSOCK->autoflush();
print hpSOCK "GET $path HTTP/1.1\015\012";
print hpSOCK "Host: $host\015\012\015\012";
...
close(hpSOCK);
return(1);
}
> Curious. The sockaddr_in function (of the Socket module) packs and
> unpacks interaddress protocol addresses. It does no input or output. It
> is hard to see how it could possibly "freeze". Maybe it is something
> else in your program that is blocking. Of course, it is hard to tell
> without seeing your program.
I'm calling the sub above like this :
$rc= StatsRelay();
Maybe I could remove the $rc analysis since this call is done sevral
times a hour and just some are useful per day (security). Don't know if
it would change something.
However to point the sockaddr_in() fct, I've commented out the rest
below it and deconnected the LAN from Internet.
> The choice to prevent a program blocking on I/O usually involves either
> non-blocking I/O (polling) or asynchronous I/O (e.g, the select
> statement or forking/threading). Both have their complications.
>
> See 'perldoc -f select' or 'perldoc IO::Select' (your platform may
> affect your results.)
OK, thanks Jim, a little bit afraid of your "both have complications"
but I'll take a look to these parts of perldoc.
------------------------------
Date: Sat, 25 Mar 2006 00:43:53 +0100
From: Asterbing <no@thanks.com>
Subject: Re: sockaddr_in() timeout or asynchone call ?
Message-Id: <MPG.1e8ea2a96da4d99a9897a2@news.tiscali.fr>
In article <x7hd5nmror.fsf@mail.sysarch.com>, uri@stemsystems.com
says...
> you are conflating several things there. the blocking nature of the
> socket has nothing to do with whether you use select on it. and select
> has nothing to do with forking/threads. and async i/o can means using
> the OS's async i/o ops or an event loops that supports it or even using
> threads. so you can pretty much mix and match all of those things and
> you don't have an either/or situation.
>
However I've to do that the code below work both under Win32 and FreeBSD
and be not a hanging point (remembering I don't have to wait for get
response for the rest of the script : maybe an important point !!!) :
StatsRelay()
{
use IO::Socket;
my $host = "www.domain.com";
my $path = "/cgi-bin/stats.cgi?a=2&t=12&z=27&rz=102";
my $port = 8080;
if ($host eq "" or $path eq ""){ return(0);}
my $iadr = inet_aton($host) || return(0);
my $padr = sockaddr_in($port, $iadr);
my $proto = getprotobyname('tcp');
socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0);
if(!connect(hpSOCK, $padr)){return(0);}
hpSOCK->autoflush();
print hpSOCK "GET $path HTTP/1.1\015\012";
print hpSOCK "Host: $host\015\012\015\012";
...
close(hpSOCK);
return(1);
}
> but i agree with your main assessment, sockaddr_in just does some simple
> IP address munging and should never block. the OP is confused or
> misunderstood something.
>
Hum, with Jim, you're starting to do I'm wondering if I've well pointing
the responsible line... Maybe a wrong debug, maybe too tired... Well,
imagine it's not sockaddr_in, but something later (socket(), connect
())... The objectif remains the same : do this StatsRelay be not a
blocking point even if the target host or uri (not you, Uri ;-)) is not
available :(
Thanks for your help, Uri and Jim.
------------------------------
Date: Fri, 24 Mar 2006 19:48:26 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: sockaddr_in() timeout or asynchone call ?
Message-Id: <x7odzvl57p.fsf@mail.sysarch.com>
>>>>> "A" == Asterbing <no@thanks.com> writes:
A> In article <x7hd5nmror.fsf@mail.sysarch.com>, uri@stemsystems.com
A> says...
>> you are conflating several things there. the blocking nature of the
>> socket has nothing to do with whether you use select on it. and select
>> has nothing to do with forking/threads. and async i/o can means using
>> the OS's async i/o ops or an event loops that supports it or even using
>> threads. so you can pretty much mix and match all of those things and
>> you don't have an either/or situation.
>>
A> However I've to do that the code below work both under Win32 and FreeBSD
A> and be not a hanging point (remembering I don't have to wait for get
A> response for the rest of the script : maybe an important point !!!) :
A> StatsRelay()
A> {
A> use IO::Socket;
why are you using that module but not even using it to connect? or why
aren't you using LWP for the web page fetch? the number of possible
problems you avoid will amaze you.
A> my $host = "www.domain.com";
A> my $path = "/cgi-bin/stats.cgi?a=2&t=12&z=27&rz=102";
A> my $port = 8080;
A> if ($host eq "" or $path eq ""){ return(0);}
A> my $iadr = inet_aton($host) || return(0);
A> my $padr = sockaddr_in($port, $iadr);
A> my $proto = getprotobyname('tcp');
A> socket(hpSOCK, PF_INET, SOCK_STREAM, $proto) || return(0);
A> if(!connect(hpSOCK, $padr)){return(0);}
my $sock = IO::Socket::INET->new( "$host:$port" ) ;
isn't that much nicer?
A> print hpSOCK "GET $path HTTP/1.1\015\012";
A> print hpSOCK "Host: $host\015\012\015\012";
more code you shouldn't be writing.
A> Hum, with Jim, you're starting to do I'm wondering if I've well pointing
A> the responsible line... Maybe a wrong debug, maybe too tired... Well,
A> imagine it's not sockaddr_in, but something later (socket(), connect
A> ())... The objectif remains the same : do this StatsRelay be not a
A> blocking point even if the target host or uri (not you, Uri ;-)) is not
A> available :(
if you would read the docs on those calls you can see what they do and
if they would block. but why you are writing it at such a low level is
beyond me. just use LWP::Simple and it is one call. something like this
(untested) :
use LWP::Simple ;
my $page = get( "http://$host:$port$path" );
even nicer than before!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
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 9086
***************************************
