incorrect errno/perror with IO::socket->new

[brandon]

I have been having fits getting meaningful errno/perror values out of
Perl from Socket->new() and I am hoping someone here might know what
is going on. The errno/perror values seem to work fine on my Linux
servers but AIX, HP, and Sun are not giving me a correct failure
value. I have remote servers set up so that I can get various types of
failures (no daemon, firewall blocking, no route, etc.) and I can test
all these conditions with telnet to see what the perror string should
be, and my Linux servers match that.

It should be just a matter of getting extern int errno in the
interpreter when I ask for it with $!, no?

Here is my sample code :

------------------------------------------------

#!/usr/bin/perl

use IO::Socket;
use strict;

my($server_ip, $server_port) = ("172.16.18.96", "10");
my($timeout) = 5;
my($firsterr) = "";
my($socket);

print "\$! = $!\n";
$! = 0;
print "\$! = $!\n";

$socket = IO::Socket::INET->new(
Proto => "tcp",
PeerAddr => $server_ip,
PeerPort => $server_port,
Timeout => $timeout
);

if ( $firsterr eq "" ) { $firsterr = $!; }
print "\$! = $!\n";

if ( $socket ) {
close $socket;
print " OK : Port $server_port is OPEN\n";

else {
# Other error detected
print " Use OS problem determination procedures to determine
the \n";
print " source of the perror (errno) string : \n";
print " \t $firsterr\n";
}

exit 0;


----------------------

In this particular case (IP/port) on my subnet, this server exists
and has no process listening on the port so I fully expect to get
(some OS specific form of) a perror string : "connection refused".
This is what I get on all the OS's when I telnet to this server and
port, and is also what I get from this script on Linux. For the other
OS's I am getting errno/perror values that apparently do not have
anything to do with the fact there is no listening process :

OS / Ver perl -v result

RH WS2u1 v5.6.1 "Connection refused"
RH WS3u5 v5.8.0 "Connection refused"
RH AS4u3 v5.8.5 "Connection refused"
AIX 5.3 v5.8.0 "A system call received a parameter that is
not valid."
AIX 5.3 v5.8.2 "A system call received a parameter that is not
valid."
AIX 5.1 v5.6.0 "A system call received aparameter that is not
valid."
AIX 5.2 v5.8.0 "A system call received aparameter that is not
valid."
AIX 4.3 v5.005_03 "A file descriptor does not refer to
an open file."
AIX 4.3 v5.005_03 "A file descriptor does not refer to
an open file."
HP 11.11 v5.8.0 "Invalid argument"
HP 11.00 v4.0 <problem w/ use>
HP 10.20 v4.0 <problem w/ use>
Sun 5.7 v5.8.5 "Connection refused"
Sun 5.8 v5.005_03 "Bad file number"
Sun 5.9 v5.6.1 "Connection refused"
Sun 5.10 v5.8.4 "Connection refused"

If I change nothing other than the IP and port values in the script
(to something that will allow a connection), I get a successful socket
creation. This is just an example of the script I am developing, the
original also writes to and reads from the socket, and that is working
splendidly on all the test boxes. I need to use the errorno/perror to
point the user towards what needs to be checked on the host, client,
or network if there is a failure however.

Also, I have also noticed similar behavior opening ports sucessfully.
The above server had telnet running and I can open port 23
successfully but I get various inexplicable $! errors after the
new().

Thanks, Brandon

 

[xhoster]

I have been having fits getting meaningful errno/perror values out of
Perl from Socket->new() and I am hoping someone here might know what
is going on. The errno/perror values seem to work fine on my Linux
servers but AIX, HP, and Sun are not giving me a correct failure
value. I have remote servers set up so that I can get various types of
failures (no daemon, firewall blocking, no route, etc.) and I can test
all these conditions with telnet to see what the perror string should
be, and my Linux servers match that.

After the "primary" error, IO::Socket might make more system calls
before it returns to your code. Those other system calls might set errno,
thus overwriting the previous value of $! set by the "primary" error.
Because of this, IO::Socket tries to set $@ to be the most meaningful error
message it can manage, considering the mishmash of system calls that are
going on behind the scenes. You should look in $@ instead of or in
addition to $!. (I'm saying this will solve the problem, only that it is
the first thing I'd try.)


....

Also, I have also noticed similar behavior opening ports sucessfully.
The above server had telnet running and I can open port 23
successfully but I get various inexplicable $! errors after the
new().

After a successful system call, $! contains whatever it contained
*before* that system call. Looking in $! is meaningful only after
an unsuccessful system call.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[brandon]

After the "primary" error, IO::Socket might make more system calls
before it returns to your code.  Those other system calls might set errno,
thus overwriting the previous value of $! set by the "primary" error.
Because of this, IO::Socket tries to set $@ to be the most meaningful error
message it can manage, considering the mishmash of system calls that are
going on behind the scenes.  You should look in $@ instead of or in
addition to $!.  (I'm saying this will solve the problem, only that it is
the first thing I'd try.)

...

Thanks - I will definately try that.

After a successful system call, $! contains whatever it contained
*before* that system call.  Looking in $! is meaningful only after
an unsuccessful system call.

Yes, and note from the code I did test it before and set it to '0'.

 

[brandon]

After the "primary" error, IO::Socket might make more system calls
before it returns to your code.  Those other system calls might set errno,
thus overwriting the previous value of $! set by the "primary" error.
Because of this, IO::Socket tries to set $@ to be the most meaningful error
message it can manage, considering the mishmash of system calls that are
going on behind the scenes.  You should look in $@ instead of or in
addition to $!.  (I'm saying this will solve the problem, only that it is
the first thing I'd try.)

That results in :

# ./simple.pl
$! =
$! =
$! = A system call received a parameter that is not valid.
$@ = IO::Socket::INET: connect: A system call received a parameter
that is not valid.
Use OS problem determination procedures to determine the
source of the perror (errno) string :
A system call received a parameter that is not valid.
#

 

[Uri Guttman]

b> Yes, and note from the code I did test it before and set it to '0'.

but you are missing the point. if the call to IO::Socket->new doesn't
return undef, there is NO point in checking out $! or $@. they will be
meaningless and may be set to some irrelevant value. i have never had to
clear those before making any lib or system calls. i only check them if
there is an indicator of an error. checking them directly is wrong in
almost every case. they could be changed due to some internal call that
is redone or worked around and yet your call will still have succeeded.

uri

 

[brandon]

  >> After a successful system call, $! contains whatever it contained
  >> *before* that system call.  Looking in $! is meaningful only after
  >> an unsuccessful system call.
  >>

  b>  Yes, and note from the code I did test it before and set it to '0'.

but you are missing the point. if the call to IO::Socket->new doesn't
return undef, there is NO point in checking out $! or $@. they will be
meaningless and may be set to some irrelevant value. i have never had to
clear those before making any lib or system calls. i only check them if
there is an indicator of an error. checking them directly is wrong in
almost every case. they could be changed due to some internal call that
is redone or worked around and yet your call will still have succeeded.

But I do understand. The call is failing on port 10, I am not getting
a socket because there is no listening process on port 10. Some of the
platforms are working (Linux and Sun) and some are not (AIX and HP).
My code does check to see if the call to new() failed, I just threw in
the print's to see what it is set to in all cases as some additional
debug. I did not put those print's in until after I noticed that I was
getting strange perrors went the call failed as I expected it to.

 

[brandon]

I'll make the example even simpler The only reason I'm printing
$! and $@ before the call is even made is to prove that errno IS
getting
set.

----------------------------------------------------------
#!/usr/bin/perl

use IO::Socket;
use strict;

my($server_ip, $server_port) = ("172.16.18.96", "10");
my($timeout) = 5;
my($socket);

print "\$! = $!\n";
print "\$@ = $@\n";

$socket = IO::Socket::INET->new(
Proto => "tcp",
PeerAddr => $server_ip,
PeerPort => $server_port,
Timeout => $timeout
);

if ( $socket ) {
close $socket;
print " OK : Port $server_port is OPEN\n";
exit 1;
}

# else
# Other error detected
print "\$! = $!\n";
print "\$@ = $@\n";
exit 0;
-------------------------------------------------------------

# uname -rvs
AIX 3 5
# perl -v

This is perl, v5.8.2 built for aix-thread-multi
(with 2 registered patches, see perl -V for more detail)

Copyright 1987-2003, Larry Wall

Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source
kit.

Complete documentation for Perl, including FAQ lists, should be found
on
this system using `man perl' or `perldoc perl'. If you have access to
the
Internet, point your browser at http://www.perl.com/, the Perl Home
Page.

# ./simple.pl
$! =
$@ =
$! = A system call received a parameter that is not valid.
$@ = IO::Socket::INET: connect: A system call received a parameter
that is not valid.
#

I should have gotten : "A remote host refused an attempted connect
operation."

# telnet 172.16.18.96 10
Trying...
telnet: connect: A remote host refused an attempted connect operation.
#

 

[Uri Guttman]

b> But I do understand. The call is failing on port 10, I am not getting
b> a socket because there is no listening process on port 10. Some of the
b> platforms are working (Linux and Sun) and some are not (AIX and HP).
b> My code does check to see if the call to new() failed, I just threw in
b> the print's to see what it is set to in all cases as some additional
b> debug. I did not put those print's in until after I noticed that I was
b> getting strange perrors went the call failed as I expected it to.

but you still don't get it. clearing error variables before the call or
printing them in all cases is useless. i repeat useless. it is not extra
debugging info but random noise. only if the new call FAILS do some of
the error vars have meaning. and $! will still be meaningless as you
don't know what internal system calls were made and if their failures
mean anything. so printing them at any time unless you make a direct
system call is useless. i repeat useless. just noise.

only print error values when you actually have an error. you detect
errors from io::socket::new by its return value. period. all preprinting
is useless. all error postprinting without an actuall error is useless.

do you understand me now??

uri

 

[Uri Guttman]

b> I'll make the example even simpler The only reason I'm printing
b> $! and $@ before the call is even made is to prove that errno IS
b> getting
b> set.

useless as you don't know what system calls were made and which ones may
have failed.

b> ----------------------------------------------------------
b> #!/usr/bin/perl

b> use IO::Socket;
b> use strict;

b> my($server_ip, $server_port) = ("172.16.18.96", "10");
b> my($timeout) = 5;
b> my($socket);

declare variables when first used. no need for the () in the scalar cases

b> print "\$! = $!\n";
b> print "\$@ = $@\n";

useless noise. no information

b> $socket = IO::Socket::INET->new(

my $socket = ....

b> Proto => "tcp",
b> PeerAddr => $server_ip,
b> PeerPort => $server_port,
b> Timeout => $timeout
b> );

b> if ( $socket ) {
b> close $socket;
b> print " OK : Port $server_port is OPEN\n";
b> exit 1;
b> }

b> # else
b> # Other error detected
b> print "\$! = $!\n";

useless as the module makes MANY system calls and you may not know which
one failed. $! is only useful on YOUR DIRECT system call.

b> print "\$@ = $@\n";
b> $! =
b> $@ =

see, useless noise.

b> $! = A system call received a parameter that is not valid.

useless error message.
b> $@ = IO::Socket::INET: connect: A system call received a parameter
b> that is not valid.
b> #

b> I should have gotten : "A remote host refused an attempted connect
b> operation."

perl -MIO::Socket -e '$s = IO::Socket::INET->new( "127.0.0.1:1234"); print "$@\n" unless $s'
IO::Socket::INET: connect: Connection refused

perl -MIO::Socket -e '$s = IO::Socket::INET->new( "172.16.18.96:1234"); print "$@\n" unless $s'
IO::Socket::INET: connect: Connection timed out


neither of those is what you expected so your expectations were
wrong. the telnet program is not IO::Socket.

uri

 

[brandon]

Just for grins I just now built perl 5.8.8 on an AIX 5.3 box :

# uname -svr
AIX 3 5
# /home/brandonm/perl-5.8.8/perl -v

This is perl, v5.8.8 built for aix

Copyright 1987-2006, Larry Wall

Perl may be copied only under the terms of either the Artistic License
or the
GNU General Public License, which may be found in the Perl 5 source
kit.

Complete documentation for Perl, including FAQ lists, should be found
on
this system using "man perl" or "perldoc perl". If you have access to
the
Internet, point your browser at http://www.perl.org/, the Perl Home
Page.

# /home/brandonm/perl-5.8.8/perl -e 'print "@INC\n";'
/opt/lib/perl5/5.8.8/aix /opt/lib/perl5/5.8.8 /opt/lib/perl5/site_perl/
5.8.8/aix /opt/lib/perl5/site_perl/5.8.8 /opt/lib/perl5/site_perl .
# for i in `/home/brandonm/perl-5.8.8/perl -e 'print "@INC\n";'` ; do
find $i -name Socket.pm ; done
/opt/lib/perl5/5.8.8/aix/Socket.pm
/opt/lib/perl5/5.8.8/aix/IO/Socket.pm
/opt/lib/perl5/5.8.8/aix/Socket.pm
/opt/lib/perl5/5.8.8/aix/IO/Socket.pm
# /home/brandonm/perl-5.8.8/perl ./simple.pl
$! =
$@ =
$! = A system call received a parameter that is not valid.
$@ = IO::Socket::INET: connect: A system call received a parameter
that is not valid.
#

I removed the shebang line from the sample code so I would be sure to
get the new perl interpreter and modules.

 

[brandon]

  b> I'll make the example even simpler The only reason I'm printing
  b> $! and $@ before the call is even made is to prove that errno IS
  b> getting
  b> set.

useless as you don't know what system calls were made and which ones may
have failed.

  b> ----------------------------------------------------------
  b> #!/usr/bin/perl

  b> use IO::Socket;
  b> use strict;

  b> my($server_ip, $server_port) = ("172.16.18.96", "10");
  b> my($timeout) = 5;
  b> my($socket);

declare variables when first used. no need for the () in the scalar cases

  b> print "\$! = $!\n";
  b> print "\$@ = $@\n";

useless noise. no information

  b> $socket = IO::Socket::INET->new(

my $socket = ....

  b>         Proto    => "tcp",
  b>         PeerAddr => $server_ip,
  b>         PeerPort => $server_port,
  b>         Timeout  => $timeout
  b> );

  b> if ( $socket ) {
  b>         close $socket;
  b>         print " OK : Port $server_port is OPEN\n";
  b>         exit 1;
  b> }

  b> # else
  b> #     Other error detected
  b> print "\$! = $!\n";

useless as the module makes MANY system calls and you may not know which
one failed. $! is only useful on YOUR DIRECT system call.

  b> print "\$@ = $@\n";
  b> $! =
  b> $@ =

see, useless noise.

  b> $! = A system call received a parameter that is not valid.

useless error message.
  b> $@ = IO::Socket::INET: connect: A system call received a parameter
  b> that is not valid.
  b> #

  b> I should have gotten : "A remote host refused an attempted connect
  b> operation."

perl -MIO::Socket -e '$s = IO::Socket::INET->new( "127.0.0.1:1234"); print "$@\n" unless $s'
IO::Socket::INET: connect: Connection refused

 perl -MIO::Socket -e '$s = IO::Socket::INET->new( "172.16.18.96:1234"); print "$@\n" unless $s'
IO::Socket::INET: connect: Connection timed out

neither of those is what you expected so your expectations were
wrong. the telnet program is not IO::Socket.

uri

--
Uri Guttman  ------  (e-mail address removed)  --------  http://www.sysarch.com--
-----  Perl Architecture, Development, Training, Support, Code Review  ------
-----------  Search or Offer Perl Jobs  -----http://jobs.perl.org ---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com---------

Hi Uri,

That's very interesting - if I leave off the Timeout hash member,
then on AIX and HP I get the return values that I was expecting
depending for each particular failure I have set up on my test IP and
port numbers.

Does that mean that Timeout is not valid for AIX and HP or only works
properly under certain conditions? It seems to me extremely strange
because if I try to open a port on a server that does not respond
(packets being dropped without any response from the network) then it
does seem to wait for "Timeout" seconds before returning a "timed out"
perror.

And also the fact that the same script does return the expected
perror on Sun and Linux whether I use Timeout or not.

I guess I get to hack a little more tomorrow, and you've helped me a
bunch but it still seems like something is inconsistent here.

 

[Uri Guttman]

b> Does that mean that Timeout is not valid for AIX and HP or only works
b> properly under certain conditions? It seems to me extremely strange
b> because if I try to open a port on a server that does not respond
b> (packets being dropped without any response from the network) then it
b> does seem to wait for "Timeout" seconds before returning a "timed out"
b> perror.

the timeout i got was a real failure of the connect and reported as
such. the timeout in io::socket timeout arg is NOT a part of any system
call and is controlled by some perl time thing like an alrm signal
breaking out of an eval block. you may be seeing the error from that
which is not important

b> And also the fact that the same script does return the expected
b> perror on Sun and Linux whether I use Timeout or not.

the perror IS USELESS. i keep telling you that. there is so much code
executing in io::socket that you can't tell what error was generated by
what call. why do you keep caring about $!?????

b> I guess I get to hack a little more tomorrow, and you've helped me a
b> bunch but it still seems like something is inconsistent here.

no, your brane is inconsistant. $! has nothing to do with io::socket. do
you see any docs that say otherwise?? only check $@ if you get an error
and not a socket. ignore $!. period. that is all. you are wasting your
and our time with this. it is so simple and you think it is
complex. change your brane as the perl modules won't change for you.

uri

 

[brandon]

  >>
  >>   >> After a successful system call, $! contains whatever it contained
  >>   >> *before* that system call.  Looking in $! is meaningful only after
  >>   >> an unsuccessful system call.
  >>   >>
  >>
  >>   b>  Yes, and note from the code I did test it before and set it to '0'.
  >>
  >> but you are missing the point. if the call to IO::Socket->new doesn't
  >> return undef, there is NO point in checking out $! or $@. they willbe
  >> meaningless and may be set to some irrelevant value. i have never had to
  >> clear those before making any lib or system calls. i only check them if
  >> there is an indicator of an error. checking them directly is wrong in
  >> almost every case. they could be changed due to some internal call that
  >> is redone or worked around and yet your call will still have succeeded.
  >>

  b>  But I do understand. The call is failing on port 10, I am not getting
  b> a socket because there is no listening process on port 10. Some of the
  b> platforms are working (Linux and Sun) and some are not (AIX and HP)..
  b> My code does check to see if the call to new() failed, I just threwin
  b> the print's to see what it is set to in all cases as some additional
  b> debug. I did not put those print's in until after I noticed that I was
  b> getting strange perrors went the call failed as I expected it to.

but you still don't get it. clearing error variables before the call or
printing them in all cases is useless. i repeat useless. it is not extra
debugging info but random noise. only if the new call FAILS do some of
the error vars have meaning. and $! will still be meaningless as you
don't know what internal system calls were made and if their failures
mean anything. so printing them at any time unless you make a direct
system call is useless. i repeat useless. just noise.

only print error values when you actually have an error. you detect
errors from io::socket::new by its return value. period. all preprinting
is useless. all error postprinting without an actuall error is useless.

do you understand me now??

uri

--
Uri Guttman  ------  (e-mail address removed)  --------  http://www.sysarch.com--
-----  Perl Architecture, Development, Training, Support, Code Review  ------
-----------  Search or Offer Perl Jobs  -----http://jobs.perl.org ---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com---------

I really did get you the first time I was thinking that perhaps
the errno was NOT getting set in Socket->new() from it's system calls
(I am kinda just assuming that $! returns the current value of errno
or perror depending on the context), and I wanted to see if $! was
different before and after the call.

If it was not changed from before the call it might mean nothing set
an error code during the call or it might mean there is a bug
somewhere if Perl (read IO::Socket::INET) is saving errno off
temporarily while it does some other system calls after the first
failure (for instance maybe it needs to make other system calls to
clean up).

Or if was changed from before the call then at least I know something
in the call really did change it and it was not just that value to
begin with. This is the case I had, it was I guess 'undef' before the
call and something else after, turns out it may be valid (though if it
is it doesn't seem consistent across platforms) after all.

That wasn't really what I was having trouble with, it was the $!
after the Socket->new(). Based on your next post I did find out some
more, so thanks very much for all your comments.

 

[Uri Guttman]

b> I really did get you the first time I was thinking that perhaps
b> the errno was NOT getting set in Socket->new() from it's system calls
b> (I am kinda just assuming that $! returns the current value of errno
b> or perror depending on the context), and I wanted to see if $! was
b> different before and after the call.

but where did you get the totally misguided idea that $! has anything to
do with the results of the io::socket call? where in the docs is that?
what source led you to think that? $! is defined for system calls. you
don't care about individual system calls in a module as it may call MANY
system calls and even handle those errors. modules will not clear or
reset $! so you get bogus info.

b> If it was not changed from before the call it might mean nothing set
b> an error code during the call or it might mean there is a bug
b> somewhere if Perl (read IO::Socket::INET) is saving errno off
b> temporarily while it does some other system calls after the first
b> failure (for instance maybe it needs to make other system calls to
b> clean up).

who cares if it was changed? it has no relationship to the io::socket
call. why do you keep checking it?

b> Or if was changed from before the call then at least I know something
b> in the call really did change it and it was not just that value to
b> begin with. This is the case I had, it was I guess 'undef' before the
b> call and something else after, turns out it may be valid (though if it
b> is it doesn't seem consistent across platforms) after all.

no, it could be random noise from a cosmic ray changing it. there is no
informational value in $! after an io::socket call. stop even thinking
the name of $!.

b> That wasn't really what I was having trouble with, it was the $!
b> after the Socket->new(). Based on your next post I did find out some
b> more, so thanks very much for all your comments.

i tell you to not look at $! and you keep saying you have trouble with
it. i give up.

uri

 

[brandon]

  >>
  >> perl -MIO::Socket -e '$s = IO::Socket::INET->new( "127.0.0.1:1234"); print "$@\n" unless $s'
  >> IO::Socket::INET: connect: Connection refused
  >>
  >>  perl -MIO::Socket -e '$s = IO::Socket::INET->new( "172.16.18.96:1234"); print "$@\n" unless $s'
  >> IO::Socket::INET: connect: Connection timed out

  b>  Does that mean that Timeout is not valid for AIX and HP or only works
  b> properly under certain conditions? It seems to me extremely strange
  b> because if I try to open a port on a server that does not respond
  b> (packets being dropped without any response from the network) then it
  b> does seem to wait for "Timeout" seconds before returning a "timed out"
  b> perror.

the timeout i got was a real failure of the connect and reported as
such.

Right, there is no timout value in :

perl -MIO::Socket -e '$s = IO::Socket::INET->new( "127.0.0.1:1234");
print "$@\n" unless $s'

only an IP address and a port.

the timeout in io::socket timeout arg is NOT a part of any system
call and is controlled by some perl time thing like an alrm signal
breaking out of an eval block. you may be seeing the error from that
which is not important

yes you might be right. strange it does not behave this way on sun
and linux.

  b>  And also the fact that the same script does return the expected
  b> perror on Sun and Linux whether I use Timeout or not.

the perror IS USELESS. i keep telling you that. there is so much code
executing in io::socket that you can't tell what error was generated by
what call. why do you keep caring about $!?????

I guess I would expect that the Socket code would save the first
meaningful errno (that would be from the first failed system call) so
that the caller could tell exactly why the call failed. There is no
other mechanisim to determine why the call failed otherwise. It
appears that they are and that my use of Timeout is related to what
error is set.

  b>  I guess I get to hack a little more tomorrow, and you've helped me a
  b> bunch but it still seems like something is inconsistent here.

no, your brane is inconsistant. $! has nothing to do with io::socket. do
you see any docs that say otherwise?? only check $@ if you get an error
and not a socket. ignore $!. period. that is all. you are wasting your
and our time with this. it is so simple and you think it is
complex. change your brane as the perl modules won't change for you.

Please don't get testy - why shouldn't I think something is
inconsistant if the same code produces different results on 4 differnt
OS's? I am currently printing out both $@ and $! and they are always
the same - I have not seen a difference yet under any of the test
conditions I have set up, on 6 different versions of perl.

And yes, I do see documentation about how $! is supposed to work,
perlvar indicates I should be able to use $! to return the errno /
perror from the last failed system call, which should be exactly what
I want, given that the writer(s) of Socket were careful enough to save
the one from the first failed system call to restore for me before
returning if other system calls have to be made in the iterim. $@ is
supposed to return the last failure from an eval, which I am not using
so I am not sure why you think that is more applicable.

 

[Uri Guttman]

b> Right, there is no timout value in :

b> perl -MIO::Socket -e '$s = IO::Socket::INET->new( "127.0.0.1:1234");
b> print "$@\n" unless $s'

b> only an IP address and a port.

how observant of you.

b> yes you might be right. strange it does not behave this way on sun
b> and linux.

hmm. maybe i AM right? i have done way more complex socket stuff than
io::socket for decades in perl and c. not an exaggeration.

b> I guess I would expect that the Socket code would save the first
b> meaningful errno (that would be from the first failed system call) so
b> that the caller could tell exactly why the call failed. There is no
b> other mechanisim to determine why the call failed otherwise. It
b> appears that they are and that my use of Timeout is related to what
b> error is set.

why do you assume stupid ideas like that? do you know how many modules
there are on cpan? how many system calls most of them make? tracking
each one and reporting each possible error is insane. why don't you
check the fucking source code instead of living your fantasy of how you
think system call errors should be handled?

b> Please don't get testy - why shouldn't I think something is
b> inconsistant if the same code produces different results on 4 differnt
b> OS's? I am currently printing out both $@ and $! and they are always
b> the same - I have not seen a difference yet under any of the test
b> conditions I have set up, on 6 different versions of perl.

if the value of $! is not related to the module's error, why do you
think it will be the same on different systems? that makes absolutely no
sense.

b> And yes, I do see documentation about how $! is supposed to work,
b> perlvar indicates I should be able to use $! to return the errno /
b> perror from the last failed system call, which should be exactly what
b> I want, given that the writer(s) of Socket were careful enough to save
b> the one from the first failed system call to restore for me before
b> returning if other system calls have to be made in the iterim. $@ is
b> supposed to return the last failure from an eval, which I am not using
b> so I am not sure why you think that is more applicable.

i give up. you won't listen. read the code. send in large patches. you
are blocked in your brane and won't ever get over this obsession with $!
when it is meaningless here.

uri

 

[brandon]

  b>  I really did get you the first time I was thinking that perhaps
  b> the errno was NOT getting set in Socket->new() from it's system calls
  b> (I am kinda just assuming that $! returns the current value of errno
  b> or perror depending on the context), and I wanted to see if $! was
  b> different before and after the call.

but where did you get the totally misguided idea that $! has anything to
do with the results of the io::socket call? where in the docs is that?
what source led you to think that? $! is defined for system calls. you
don't care about individual system calls in a module as it may call MANY
system calls and even handle those errors. modules will not clear or
reset $! so you get bogus info.

No I am expecting that Socket->new() is making system calls and if
they fail I can retrieve the error with $!. If not, then there is not
a way for me to tell exactly why the call failed.
I am left only with an undef $socket.

The writers of Socket should be (and apparently are) either returning
immediately on a filed system call, or if others need to be made to
clean up then saving it and restoring it after all clean up system
calls are finished. That does seem to be what they are doing an it is
not unreasonable to expect.

  b>  If it was not changed from before the call it might mean nothingset
  b> an error code during the call or it might mean there is a bug
  b> somewhere if Perl (read IO::Socket::INET) is saving errno off
  b> temporarily while it does some other system calls after the first
  b> failure (for instance maybe it needs to make other system calls to
  b> clean up).

who cares if it was changed? it has no relationship to the io::socket
call. why do you keep checking it?

I have to disagree with that. It is set, and correctly apparently.

 

[Uri Guttman]

b> No I am expecting that Socket->new() is making system calls and if
b> they fail I can retrieve the error with $!. If not, then there is not
b> a way for me to tell exactly why the call failed.
b> I am left only with an undef $socket.

b> The writers of Socket should be (and apparently are) either returning
b> immediately on a filed system call, or if others need to be made to
b> clean up then saving it and restoring it after all clean up system
b> calls are finished. That does seem to be what they are doing an it is
b> not unreasonable to expect.

then write your own module. i did. otherwise expect nothing more than
what the docs offer. your expectations are wrong, useless and leading
you into a brick wall. enjoy.

b> I have to disagree with that. It is set, and correctly apparently.

but who cares?? your connection failed. $@ tells you why. why the hell
check $!??? it could be anything inside the module and it could be
something that does not matter. yet you give it credence. this is on
your head and not the module. bang your head away. enjoy.

uri

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Uri Guttman

do you understand me now??

a) there is no reason to yell;

b) your arguments are, IMO, wrong.

In a perfect world, your argument that `$@ should contain all the
information one needs' would be right. In a perfect world, presetting
these variables to FALSE would not be needed. In a perfect world,
one would not need to check $!.

However, as the OP had shown, the world he lives in is not perfect.
Somethign fishy is happening. So it is very logical, very polite, and
very helpful (*) that he is setting $!, $@ to FALSE, and is the value
of reporting $! to us.

(*) Well, not helpful enough for me to solve his problem (sorry!),
but helpful in avoiding unneeded assumptions and questions.

Hope this helps,
Ilya

 

[Uri Guttman]

IZ> [A complimentary Cc of this posting was sent to
IZ> Uri Guttman

IZ> a) there is no reason to yell;

there is a reason when the OP keeps banging his head on the wall and
won't listen.

IZ> b) your arguments are, IMO, wrong.

and i disagree. but you are always right so i won't argue with you. it
is a waste of time.

IZ> In a perfect world, your argument that `$@ should contain all the
IZ> information one needs' would be right. In a perfect world, presetting
IZ> these variables to FALSE would not be needed. In a perfect world,
IZ> one would not need to check $!.

and the module code can be patched in the imperfect world. or you can
write your own which i did. no problems with any error handling then.

IZ> However, as the OP had shown, the world he lives in is not perfect.
IZ> Somethign fishy is happening. So it is very logical, very polite, and
IZ> very helpful (*) that he is setting $!, $@ to FALSE, and is the value
IZ> of reporting $! to us.

nope, i did the same things and got a clean error message from $@. $! is
useless as it could be from some system call that failed but was handled
by the module. LWP does retries and such so $! may get set along the way
to a perfectly fine page fetch. if the module doesn't specify it will
use $! then looking at it is dumb.

IZ> (*) Well, not helpful enough for me to solve his problem (sorry!),
IZ> but helpful in avoiding unneeded assumptions and questions.

well, you didn't help either. so why argue about it. io::socket works
fine for everyone but the OP. i lay the blame on the obvious location.

uri