Ping puzzle

[Kevin D. Clark]

John Chambers <jc at trillian.mit.edu> writes:

> OK; I can see that people totally missed the point.

Hmm.

...
> The point is that this is a subprocess whose output is being piped
> somewhere.  I want the reader to get all of ping's output, no matter
> whether it is stdout or stderr on the current system.  In the normal
> case, ping's success messages get through.  But ping's error
> messages don't get through.  They appear on my screen, but a parent
> process doesn't see them.  These pipe commands demonstrate that it's
> not just my poor programming; a simple pipe also loses the error
> messages.

Sorry, I must politely disagree:  nothing is getting lost.
 
... 
> If you try the above commands with a  responsive  host,  you'll  find
> that they work.  It's only with a non-responsive host that they fail.
> And they only fail on some systems. (As I said, they seem to work for
> all hosts on this FreeBSD system.)

So, FreeBSD's stdio layer is different from Linux's.

> The guess that they're being buffered is likely correct.  

I wasn't really guessing... (-:

> Maybe if I waited long enough, the parent would get those messages.

Yes.

> But the buffer is apparently pretty big, because tests running 10 or
> 20 minutes don't see the messages.

How long does it take for you to see any output when you do this?:

  perl -le 'print(i++), sleep(1) while(1);' | more

When you finally do see some output, try pressing <space> a bunch of
times to see how much stuff "more" has queued up.

> If this is the problem, is there
> any way to persuade ping to not do this (assuming that it's actually
> ping that's doing it)?

Convince ping's stdio that it is connected to a terminal.  IIRC,
there's a program in the expect distribution ("unbuffer"?) that does
exactly this.

> One bizarre thing about this conjecture is that it implies that  ping
> is  using  fflush  on  its  success  messages  but not on its failure
> messages.  This is the opposite of what most programs do.

There might be something bizarre going on here, but unfortunately I
don't have a lot of time to look at this right now.  ping might be
calling fflush() at various points, but somebody would have to UTSL
through the code to find all of the places.
...
> I wonder if there's a perl ping module? ;-)

Yes there is, but the last time I worked with this module, I recall
that it used the TCP echo port to determine "ping" status -- not
ICMP -- although I recall that you could get it to use ICMP if you
leapt through some hoops.


I've written my own version of ping for various projects I've worked
on in the past; I understand your concerns about doing this.  I think
that if you want this functionality, you're going to have to pick your
poison...

Regards,

--kevin
-- 
Kevin D. Clark / Cetacean Networks / Portsmouth, N.H. (USA)
cetaceannetworks.com!kclark (GnuPG ID: B280F24E)
alumni.unh.edu!kdc