[32801] in Perl-Users-Digest
Perl-Users Digest, Issue: 4065 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 27 18:09:33 2013
Date: Sun, 27 Oct 2013 15:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 27 Oct 2013 Volume: 11 Number: 4065
Today's topics:
Ping was SIgnal help <dave@invalid.invalid>
Re: READFILE sorting coding problem <gravitalsun@hotmail.foo>
Re: Replacement for CGI.pm <ben@morrow.me.uk>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <ben@morrow.me.uk>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: Replacement for CGI.pm <rweikusat@mobileactivedefense.com>
Re: SIgnal help <ben@morrow.me.uk>
Re: SIgnal help <dave@invalid.invalid>
Re: SIgnal help <dave@invalid.invalid>
Re: SIgnal help <ben@morrow.me.uk>
Re: SIgnal help <dave@invalid.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 27 Oct 2013 14:22:05 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Ping was SIgnal help
Message-Id: <fV45K0OBJxbE-pn2-QL3geqdb2XhP@paddington.bear.den>
On Sun, 27 Oct 2013 12:47:53 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
<snip>
> I get the same results, so there's something different about your
> program which is causing the hang and the failed unpack_sockaddr_in. You
> will need to start cutting it down until you get something small enough
> to post.
As I said in another reply it would seem to the difference between
5.8.2 and 5.16.0
>
> > And another thing :-)
> >
> > A "real" ping seems to be about once a second here. If I start a ping
> > to a host, let it return a few times and pull the ethernet cable it
> > obviously stops printing returns.If I then put the cable back it
> > starts again. CTRL-C and I get a summary of pings sent, received and
> > lost.
> >
> > Trying to do the same thing with Net::Ping and it stops printing
> > returns and starts again when I replace the cable - but it sees *no*
> > dropped packets. It would appear that it blocks until it gets a
> > return. I just tried your program doing the same thing and it hangs at
> > SENDING PING... until I plug it in again when it takes almost 20
> > seconds before it prints ALIVE.
>
> ping(1) sends ICMP pings by default, which (at least on Unix) require
> privilege. In order to avoid making you run your script as root,
> Net::Ping uses TCP 'pings' by default, which actually just attempt a TCP
> connection to the echo port (port 4) and return 'reachable' if either
> the connection succeeds or we get a definite ECONNREFUSED. This will
> lead to different behaviour on failure: in particular, a TCP connection
> attempt can take several minutes to time out, so if you pull the cable
> it will take that long before the host is reported dead. The delay when
> the cable is plugged back in is likely due to the kernel's exponential
> backoff of connection retries.
>
> I don't know what OS/2's security model is like.
Hasn't got one :-)
I *am* using ICMP. My point is "real" ping gets a reject or something
when the cable is pulled but keeps trying as when it is plugged in
again it not only starts printing status lines immediately but also
knows how many failed. I know it is still pinging because the lights
on the switch blink.
PC <cable> switch <cable> router ie I pull the second cable.
I slowly modifed your code to match mine and it behaves as "real" ping
all the time. Just tried mine again and it worked. Hmmm.
I<snip>
> You could also try Net::Ping::External, though again you will need to
> patch it for OS/2. (Or, you know, you could just run 'ping -c1' or
> whatever the equivalent is and check the exit status.)
LOL that was my first thought. The actual problem I am trying to solve
is a drop out on VOIP. It has been suggested to run a ping during the
call to see if packets are dropping or getting long response times.
Ping on its own only gives the packet loss at program end. I wanted it
continuous and thought running a completely fresh copy of ping every
second was a bit much. :-)
--
Regards
Dave Saville
------------------------------
Date: Sun, 27 Oct 2013 22:54:32 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: READFILE sorting coding problem
Message-Id: <l4jui9$19jd$1@news.ntua.gr>
#!/usr/bin/perl
use strict;
use warnings;
use feature 'say';
#open DATA, '<:utf8', 'somefile.csv' or die "Could not read fiel because
\"$^E\"\n";
my $column_to_sort = 1;
my @data;
while (<DATA>) {
/^\s*(\S*)[,\s]*(\S*?)[,\s]*(\d{3}\.\d{3}\.\d{4})[,\s]*(\S*?)\s*$/ or next;
push @data, [$1,$2,$3,$4];
}
foreach (sort {$a->[0] cmp $b->[0] || $a->[3] cmp $b->[3]} @data) {
say "@{$_}"
}
__DATA__
name2 , colum1, 444.444.4444, info4
name1 , colum3, 111.111.1111, info2
name1 , colum2, 222.222.2222, info1
name3 , colum4, 333.333.3333, info3
------------------------------
Date: Sat, 26 Oct 2013 21:05:03 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Replacement for CGI.pm
Message-Id: <fsjtja-hoq2.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> ["Followup-To:" header set to comp.lang.perl.misc.]
> On 2013-10-24 23:39, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth Joachim Pense <snob@pense-mainz.eu>:
> >>
> >> I wonder if an "HTML disassembler" is available - a program that takes
> >> HTML code as input and produces CGI.pm output.
> >
> > Given a single input, Peter's answer is actually the only correct one.
>
> I don't think so. CGI.pm provides a function for every HTML element, so
> it should be possible to parse an HTML input into a DOM tree and then
> serialize that as nested calls to CGI functions.
>
> So, this small HTML file:
>
> <html>
> <head>
[...]
>
> could be converted into:
>
> html(
> head(
[...]
>
> I think this is what Joachim meant.
Good point.
> I just don't think that would be terribly useful. But then I think the
> html-generating functions in CGI.pm aren't very useful in general, so
> that't not a big surprise ;-).
Well, if one is using the HTML-generating functions, it might be useful.
One of the reasons I don't use them is because of the work involved in
translating a static HTML page into an equivalent list of function
calls.
Maybe CGI.pm should provide a function which takes HTML as input, parses
it, and calls the corresponding HTML-generating functions for you... :)
Ben
------------------------------
Date: Sun, 27 Oct 2013 12:41:32 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <8738nmansz.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
[...]
>> So, this small HTML file:
>>
>> <html>
>> <head>
> [...]
>>
>> could be converted into:
>>
>> html(
>> head(
> [...]
[...]
>> I just don't think that would be terribly useful. But then I think the
>> html-generating functions in CGI.pm aren't very useful in general, so
>> that't not a big surprise ;-).
>
> Well, if one is using the HTML-generating functions, it might be
> useful.
NB: The text below is firmly based on ignoring the somewhat persistent
failures of the W3C to prevent HTML from being useful as general way to
describe graphical user interfaces in favour of producing a myriad of
mutually incompatible 'standards' to accomplish the same thing in as
many different way, all of which are either deprecated, incomplete or
without sufficient support across a range of common browsers to be
useful. Considering that Microsoft is a major sponsor of this
organization, this might as well just be an implementation the
'original' Microsoft-vs-Netscape strategy [If you're blind, GUIs are
obviously not for you and that's that].
It is possible to define a general 'tag function' which behaves as
follows: The first argument can be a hash reference. In this case, the
hash contains tag attributes. An arbitrary number of other arguments can
follow. The tag function returns a string describing the 'open' tag with
added attributes as required, following by all of its 'list arguments',
followed by the a string representing the closing tag. If no special
processing is required, tag-functions are generated via AUTOLOAD. It
might make sense to use a single subroutine created in a suitable
lexical environment instead of creating a large number of different
subroutines with almost identical code. A toy example of that coud look
like this (toy example because it doesn't deal with encoding 'special
characters'):
------------
package Tag;
sub AUTOLOAD {
our $AUTOLOAD;
my $tag;
$AUTOLOAD =~ /^.*::([^:]+)/ and $tag = $1;
*$AUTOLOAD = sub {
my @attrs;
if (ref($_[0]) eq 'HASH') {
@attrs = map { $_.'="'.$_[0]->{$_}.'"' } keys(%{$_[0]});
shift;
}
return ("<$tag ".join(' ', @attrs).'>',
@_,
"</$tag>");
};
goto &$AUTOLOAD;
}
package main;
print(join("\n", Tag::body({bgcolor => 'white', color=> 'blue'}, 'Text')), "\n");
------------
Something mildy more interesting can be done with an additional function
merging two hashes:
sub merge_attrs
{
my %attrs;
%attrs = %{$_[0]};
$attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
return \%attrs;
}
because this enables defining tag functions supplying some set of
overridable/ expandle default attributes:
-----------
package Std;
sub merge_attrs
{
my %attrs;
%attrs = %{$_[0]};
$attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
return \%attrs;
}
sub table
{
my $attrs = {cellspacing => 0, cellpadding => 0};
$attrs = merge_attrs($attrs, shift) if ref($_[0]) eq 'HASH';
return Tag::table($attrs, @_);
}
package main;
print(join("\n",
Tag::body({bgcolor => 'white', color=> 'blue'},
Std::table({border => 1},
Tag::tr(
Tag::td('Blah'))))));
-----------
These 'default-attribute-supplying tag functions' could also be
auto-generated:
------------
package Std;
sub merge_attrs
{
my %attrs;
%attrs = %{$_[0]};
$attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
return \%attrs;
}
sub make_def_tag
{
my $def_attrs = $_[0];
my $tagf = $_[1];
return sub {
my $attrs = $def_attrs;
$attrs = merge_attrs($attrs, shift) if ref($_[0]) eq 'HASH';
$tagf->($attrs, @_);
};
}
*table = make_def_tag({cellspacing => 0, cellpadding => 0}, \&Tag::table);
package main;
*btable = Std::make_def_tag({border => 1}, \&Std::table);
print(join("\n",
Tag::body({bgcolor => 'white', color=> 'blue'},
btable({cellpadding => 5},
Tag::tr(
Tag::td('Blah'))))));
------------
NB: This is a (n executable) sketch showing how to build higher-level
abstractions closer to the problem domain from the ground
up. Necessarily, since this is a made-up example, it remains pretty
low-level.
> One of the reasons I don't use them is because of the work involved in
> translating a static HTML page into an equivalent list of function
> calls.
Where did the static HTML-page come from? A stranger slipped it through
below you door in 1823 and you've been using it ever since? It was
hammered in stone based on direct instruction from above given atop of a
mountain the middle-east in ancient times? Or could it be that you wrote
it prior to implementing the 'active' parts of your wepplication?
------------------------------
Date: Sun, 27 Oct 2013 13:17:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Replacement for CGI.pm
Message-Id: <ibgvja-ro5.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > Well, if one is using the HTML-generating functions, it might be
> > useful.
>
[...]
> It is possible to define a general 'tag function' which behaves as
> follows: The first argument can be a hash reference. In this case, the
> hash contains tag attributes.
[...]
>
> Something mildy more interesting can be done with an additional function
> merging two hashes:
[...]
> because this enables defining tag functions supplying some set of
> overridable/ expandle default attributes:
Yes, that's all true, and when we were generating HTML 3.2, with its
horribly limited attribute-based formatting, that sort of thing would
have been very useful. (Presumably that's why CGI.pm acquired these
functions in the first place.) However, these days we're generating HTML
5 with CSS, which already includes the ability to make that sort of
high-level change to formatting in a clean and consistent manner, so
there's no need to do it in Perl.
> > One of the reasons I don't use them is because of the work involved in
> > translating a static HTML page into an equivalent list of function
> > calls.
>
> Where did the static HTML-page come from? A stranger slipped it through
> below you door in 1823 and you've been using it ever since? It was
> hammered in stone based on direct instruction from above given atop of a
> mountain the middle-east in ancient times? Or could it be that you wrote
> it prior to implementing the 'active' parts of your wepplication?
Perhaps it was supplied by someone else in the organisation, who knows
about how to beat browsers into submission but doesn't know Perl. In my
case, even when designing the HTML myself, I find it much easier to
start by getting a complex layout right in a static file, without
involving Perl. Once I've done that it's trivial to cut it up into bits
and turn it into a template. Even then, if I have major changes to make
to the design, or if some part of the layout is misbehaving, I will
sometimes save a static copy of the page, debug that against the
browser, and then merge the changes back into the templates.
Ben
------------------------------
Date: Sun, 27 Oct 2013 15:54:30 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87iowilnex.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > Well, if one is using the HTML-generating functions, it might be
>> > useful.
>>
> [...]
>> It is possible to define a general 'tag function' which behaves as
>> follows: The first argument can be a hash reference. In this case, the
>> hash contains tag attributes.
> [...]
>>
>> Something mildy more interesting can be done with an additional function
>> merging two hashes:
> [...]
>> because this enables defining tag functions supplying some set of
>> overridable/ expandle default attributes:
>
> Yes, that's all true, and when we were generating HTML 3.2, with its
> horribly limited attribute-based formatting, that sort of thing would
> have been very useful. (Presumably that's why CGI.pm acquired these
> functions in the first place.)
'Presumably', CGI.pm 'acquired these functions in the first place' (and
I wasn't writing about the CGI.pm functions) because a CGI-program will
usually involve dynamically generated HTML in order to interact with a
user and one way to do this easily is to use a the facilities of a
programming language in order to generate it.
It is no small wonder that people who feel very much out home inside
their WYSIWYG HTML-editors and seriously uncomfortable with
non-interactive, higher-level abstracting programmable ways to
accomplish the same task don't understand why this would be useful and
this is no different today than it was in 1995. But (imagine this) not
everybody on this planet is 'a reluctant programmer' forced to write
code because there's really no other way.
------------------------------
Date: Sun, 27 Oct 2013 15:58:31 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <87d2mqln88.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > Well, if one is using the HTML-generating functions, it might be
>> > useful.
>>
> [...]
>> It is possible to define a general 'tag function' which behaves as
>> follows: The first argument can be a hash reference. In this case, the
>> hash contains tag attributes.
> [...]
>>
>> Something mildy more interesting can be done with an additional function
>> merging two hashes:
> [...]
>> because this enables defining tag functions supplying some set of
>> overridable/ expandle default attributes:
>
> Yes, that's all true, and when we were
[...]
IMHO, this is a flamebait I'm going to ignore because of that.
------------------------------
Date: Sun, 27 Oct 2013 17:36:41 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Replacement for CGI.pm
Message-Id: <874n82liom.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
>> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>> Ben Morrow <ben@morrow.me.uk> writes:
>>> >
>>> > Well, if one is using the HTML-generating functions, it might be
>>> > useful.
>>>
>> [...]
>>> It is possible to define a general 'tag function' which behaves as
>>> follows: The first argument can be a hash reference. In this case, the
>>> hash contains tag attributes.
>> [...]
>>>
>>> Something mildy more interesting can be done with an additional function
>>> merging two hashes:
>> [...]
>>> because this enables defining tag functions supplying some set of
>>> overridable/ expandle default attributes:
>>
>> Yes, that's all true, and when we were
>
> [...]
>
> IMHO, this is a flamebait I'm going to ignore because of that.
Except this: Considering what I know about (X)HTML generated by JSF and
RichFaces (both 'state of the art, enterprise-grade HTML generation
toolkits/ frameworks'), the statement that 'nowadays, we use
attribute-free hand-written HTML5 formatted only via CSS' must have been
made by some guy living on a different planet: Maybe, some people do
that, but it certainly isn't the norm for web GUIs, which are rather
centered around "use bits and pieces of everything" (favoring more
conservative approaches over more modern ones where possible) _provided
the result works_.
------------------------------
Date: Sat, 26 Oct 2013 21:01:15 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: SIgnal help
Message-Id: <bljtja-hoq2.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> I am developing a script that uses Net::Ping
>
> I need to be able to CTRL-C it and have my END block run.
>
> I have $SIG{INT} = \&catch; at the top of the script;
>
> sub catch
> {
> $int++;
> $SIG{INT} = 'DEFAULT' if $int > 3;
> }
>
>
> In the main program I check for $int being no-zero and exit.
> The actual ping is issued from a subroutine.
>
> If the other end is responding then a CTRL-C will stop it and run my
> END block. However if the other end is *not* responding then I get
> this:
>
> .........
>
> CTRL-C Nothing happens, if I leave it it stays that way and no more
> output appears.
>
> CTRL-C
> Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
> 16 at D:/u
> sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.
>
> Followed by the print from my END block.
>
> What's going on and what have I missed? I am guessing that the
> Net::Ping code has installed another handler?
Net::Ping does not install a SIGINT handler. You may be falling foul of
'safe signals', or this may be an inconsistency in the way OS/2 handles
signals. I can't reproduce this with this program:
use 5.012;
use Net::Ping;
my $int = 0;
$SIG{INT} = sub {
warn "SIGINT ($int)";
if (++$int > 3) {
warn "CLEARING SIGINT";
$SIG{INT} = "DEFAULT";
}
};
$| = 1;
my $P = Net::Ping->new;
while (1) {
print "SENDING PING...";
my $p = $P->ping($ARGV[0]);
say $p ? "ALIVE" : "DEAD";
sleep 5;
}
even if I time the ^C so it comes while a ping is in progress, which
suggests the latter; can you post a minimal program which exhibits the
problem to confirm whether this is OS-dependent?
Ben
------------------------------
Date: Sun, 27 Oct 2013 10:49:12 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: SIgnal help
Message-Id: <fV45K0OBJxbE-pn2-0hcSyxuJHYOF@paddington.bear.den>
On Sat, 26 Oct 2013 20:01:15 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > I am developing a script that uses Net::Ping
> >
> > I need to be able to CTRL-C it and have my END block run.
> >
> > I have $SIG{INT} = \&catch; at the top of the script;
> >
> > sub catch
> > {
> > $int++;
> > $SIG{INT} = 'DEFAULT' if $int > 3;
> > }
> >
> >
> > In the main program I check for $int being no-zero and exit.
> > The actual ping is issued from a subroutine.
> >
> > If the other end is responding then a CTRL-C will stop it and run my
> > END block. However if the other end is *not* responding then I get
> > this:
> >
> > .........
> >
> > CTRL-C Nothing happens, if I leave it it stays that way and no more
> > output appears.
> >
> > CTRL-C
> > Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
> > 16 at D:/u
> > sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.
> >
> > Followed by the print from my END block.
> >
> > What's going on and what have I missed? I am guessing that the
> > Net::Ping code has installed another handler?
>
> Net::Ping does not install a SIGINT handler. You may be falling foul of
> 'safe signals', or this may be an inconsistency in the way OS/2 handles
> signals. I can't reproduce this with this program:
>
> use 5.012;
> use Net::Ping;
>
> my $int = 0;
> $SIG{INT} = sub {
> warn "SIGINT ($int)";
> if (++$int > 3) {
> warn "CLEARING SIGINT";
> $SIG{INT} = "DEFAULT";
> }
> };
>
> $| = 1;
> my $P = Net::Ping->new;
> while (1) {
> print "SENDING PING...";
> my $p = $P->ping($ARGV[0]);
> say $p ? "ALIVE" : "DEAD";
> sleep 5;
> }
>
> even if I time the ^C so it comes while a ping is in progress, which
> suggests the latter; can you post a minimal program which exhibits the
> problem to confirm whether this is OS-dependent?
Running the above on 5.16.0
[T:\tmp]try.pl 192.168.0.2
SENDING PING...ALIVE
SIGINT (0) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (1) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (2) at try.pl line 6.
SENDING PING...ALIVE
SIGINT (3) at try.pl line 6.
CLEARING SIGINT at try.pl line 8.
SENDING PING...ALIVE
[T:\tmp]try.pl 192.168.0.5
SENDING PING...DEAD
SENDING PING...SIGINT (0) at try.pl line 6.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD
SENDING PING...SIGINT (1) at try.pl line 6.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD
SIGINT (2) at try.pl line 6.
SENDING PING...SIGINT (3) at try.pl line 6.
CLEARING SIGINT at try.pl line 8.
select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
line 633.
DEAD
And another thing :-)
A "real" ping seems to be about once a second here. If I start a ping
to a host, let it return a few times and pull the ethernet cable it
obviously stops printing returns.If I then put the cable back it
starts again. CTRL-C and I get a summary of pings sent, received and
lost.
Trying to do the same thing with Net::Ping and it stops printing
returns and starts again when I replace the cable - but it sees *no*
dropped packets. It would appear that it blocks until it gets a
return. I just tried your program doing the same thing and it hangs at
SENDING PING... until I plug it in again when it takes almost 20
seconds before it prints ALIVE.
--
Regards
Dave Saville
------------------------------
Date: Sun, 27 Oct 2013 11:51:14 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: SIgnal help
Message-Id: <fV45K0OBJxbE-pn2-h08zvTNZRXMd@paddington.bear.den>
I just tried my script again under 5.16.0 and it is OK with CTRL-C
when pinging a non exisitant IP. So it is something in my "normal use"
5.8.2 perl Net::Ping or the underlying socket code.
5.8.2 Net::Ping is version 2.31 and 5.16.0 is 2.38 - Diff shows a lot
of changes.
However, the "pulling the plug hang" remains under 5.16.0.
--
Regards
Dave Saville
------------------------------
Date: Sun, 27 Oct 2013 12:47:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: SIgnal help
Message-Id: <pkevja-ch5.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Sat, 26 Oct 2013 20:01:15 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> > >
> > > I am developing a script that uses Net::Ping
[...]
> > > I need to be able to CTRL-C it and have my END block run.
[...]
> > > CTRL-C
> > > Bad arg length for Socket::unpack_sockaddr_in, length is 0, should be
> > > 16 at D:/u
> > > sr/lib/perl/lib/5.8.2/os2/Socket.pm line 370.
[...]
> >
> > Net::Ping does not install a SIGINT handler. You may be falling foul of
> > 'safe signals', or this may be an inconsistency in the way OS/2 handles
> > signals. I can't reproduce this with this program:
[...]
>
> Running the above on 5.16.0
>
> [T:\tmp]try.pl 192.168.0.2
> SENDING PING...ALIVE
> SIGINT (0) at try.pl line 6.
> SENDING PING...ALIVE
> SIGINT (1) at try.pl line 6.
> SENDING PING...ALIVE
> SIGINT (2) at try.pl line 6.
> SENDING PING...ALIVE
> SIGINT (3) at try.pl line 6.
> CLEARING SIGINT at try.pl line 8.
> SENDING PING...ALIVE
>
> [T:\tmp]try.pl 192.168.0.5
> SENDING PING...DEAD
> SENDING PING...SIGINT (0) at try.pl line 6.
> select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
> line 633.
> DEAD
> SENDING PING...SIGINT (1) at try.pl line 6.
> select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
> line 633.
> DEAD
> SIGINT (2) at try.pl line 6.
> SENDING PING...SIGINT (3) at try.pl line 6.
> CLEARING SIGINT at try.pl line 8.
> select: Interrupted system call at u:/perl5/lib/5.16.0/Net/Ping.pm
> line 633.
> DEAD
I get the same results, so there's something different about your
program which is causing the hang and the failed unpack_sockaddr_in. You
will need to start cutting it down until you get something small enough
to post.
> And another thing :-)
>
> A "real" ping seems to be about once a second here. If I start a ping
> to a host, let it return a few times and pull the ethernet cable it
> obviously stops printing returns.If I then put the cable back it
> starts again. CTRL-C and I get a summary of pings sent, received and
> lost.
>
> Trying to do the same thing with Net::Ping and it stops printing
> returns and starts again when I replace the cable - but it sees *no*
> dropped packets. It would appear that it blocks until it gets a
> return. I just tried your program doing the same thing and it hangs at
> SENDING PING... until I plug it in again when it takes almost 20
> seconds before it prints ALIVE.
ping(1) sends ICMP pings by default, which (at least on Unix) require
privilege. In order to avoid making you run your script as root,
Net::Ping uses TCP 'pings' by default, which actually just attempt a TCP
connection to the echo port (port 4) and return 'reachable' if either
the connection succeeds or we get a definite ECONNREFUSED. This will
lead to different behaviour on failure: in particular, a TCP connection
attempt can take several minutes to time out, so if you pull the cable
it will take that long before the host is reported dead. The delay when
the cable is plugged back in is likely due to the kernel's exponential
backoff of connection retries.
I don't know what OS/2's security model is like. If you can create
SOCK_RAW sockets without privilege, or you can reasonably give your
script the right privileges, you could try using the 'icmp' ping method.
You may need to patch the 'croak("icmp ping requires root privilege")'
line in Net::Ping to include OS/2; properly speaking, Net::Ping
shouldn't be making assumptions, it should just try to create the socket
and see if it succeeds.
You could also try Net::Ping::External, though again you will need to
patch it for OS/2. (Or, you know, you could just run 'ping -c1' or
whatever the equivalent is and check the exit status.)
Ben
------------------------------
Date: Sun, 27 Oct 2013 15:46:08 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: SIgnal help
Message-Id: <fV45K0OBJxbE-pn2-dZV8s2TQgn5T@paddington.bear.den>
Hi Ben
It would seem to be a timing issue. Using your code from previous post
I can reprduce the error.
SENDING PING... <timeout delay> DEAD
<sleep delay>
SENDING PING...
If you CTRL-C during the sleep delay it works as expected but if you
do it during the timeout delay you get the error. As I was running
with a sleep of 1 it was always in the timeout delay. Works OK on
5.16.0. You can CTLR-C any time and no error
--
Regards
Dave Saville
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 4065
***************************************
