Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No subject



...

Those error messages come out on stderr.  Running under bash, I tried
piping it to a few commands:

$ /bin/ping -n -i 10 64.28.81.46 2>&1 | more

That's all the output I got in over a minute.   The  stderr  messages
didn't appear.  So I tried:

$ /bin/ping -n -i 10 64.28.81.46 2>&1 | tee ping.log

Again, that's all I ever saw, and the ping.log file was empty after a
minute (and after killing the task with ^C).

OK; how about a trivial test:

$ /bin/ping -n -i 10 64.28.81.46 2>&1 | cat

Again, no output appeared.

I also tried running this from a tcl (wish) script, using nonblocking
reads  and  a  fileevent.  The parent process received nothing at all
from the ping process.

For another test, I ran it under tcsh, using |&  rather  than  2>&1|,
and  the  results  were  identical  to  the bash results.  The stderr
messages just disappeared somewhere and were never seen.

What I'm trying to do, of course, is to have a process fire up a ping
subprocess,  and  do  something  sensible with the output.  When ping
returns error messages on stderr, it is especially important that the
parent  know about it in a timely fashion.  But no matter what I try,
ping's stderr never seems to make it through to the parent.

I tried all these on this FreeBSD machine, and they all  worked  just
like  I  expected.   The  more/tee/ping/tcl process sees ping's error
messages as they are produced.  But on the several linux systems that
I have access to, they all fail.

Ahy ideas?  Can someone make them work?






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org