From: brandon on
On Jan 16, 7:53 pm, Uri Guttman <u...(a)stemsystems.com> wrote:
> >>>>> "b" == brandon  <brandon.mayfi...(a)att.net> writes:
>
>   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  ------  u...(a)stemsystems.com  --------  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.
From: Uri Guttman on
>>>>> "b" == brandon <brandon.mayfield(a)att.net> writes:

b> On Jan 16, 7:53�pm, Uri Guttman <u...(a)stemsystems.com> wrote:
>>
>> 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. 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

--
Uri Guttman ------ uri(a)stemsystems.com -------- 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 ---------
From: brandon on
On Jan 16, 7:41 pm, Uri Guttman <u...(a)stemsystems.com> wrote:
> >>>>> "b" == brandon  <brandon.mayfi...(a)att.net> writes:
>
>   b> On Jan 16, 4:22 pm, Uri Guttman <u...(a)stemsystems.com> wrote:
>   >> >>>>> "b" == brandon  <brandon.mayfi...(a)att.net> writes:
>   >>
>   >>   >> 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.
>   >>
>
>   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  ------  u...(a)stemsystems.com  --------  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.
From: Uri Guttman on
>>>>> "b" == brandon <brandon.mayfield(a)att.net> writes:

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

--
Uri Guttman ------ uri(a)stemsystems.com -------- 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 ---------
From: brandon on
On Jan 16, 9:53 pm, Uri Guttman <u...(a)stemsystems.com> wrote:
> >>>>> "b" == brandon  <brandon.mayfi...(a)att.net> writes:
>
>   b> On Jan 16, 7:53 pm, Uri Guttman <u...(a)stemsystems.com> wrote:
>   >>
>   >> 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
>
> --
> Uri Guttman  ------  u...(a)stemsystems.com  --------  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---------