Oh thank you, for your detailed response.
I guess I try to use your technique of parsing the out error message
(somehow from stdout).
However, maybe its OS X or something silly. But, trying to redirect
stdout and stderr to a file (i.e. cmd 1>blah 2>bob) - Shouldn't the
rush: error message appear in the stdout file "blah" and not to echoed
to the terminal? This is the result
i receive.
Hence my confusion with what fd you were using, hence my question.
If that doesn't make sense, an example of what is occuring is:
xxxx:~/curses adnguyen$ ./stats.pl 2>&1 1>blah
xxxx:~/curses adnguyen$ ./stats.pl 2>&1 1>blah
xxxx:~/curses adnguyen$ ./stats.pl 2>&1 1>blah
rush: 'rush -laj': sendto(angel:696): No route to host
xxxx:~/curses adnguyen$
It also doesn't happen 100% of the time either.
Greg Ercolano wrote:
[posted to rush.general]
An Nguyen wrote:
Hi Greg,
I was wondering what file descriptor you use to output your
rush: 'rush -laj': sendto(angel:696): No route to host
messages to the terminal.
I've been trying redirect 2>/dev/null but the message still gets echoed
into the
terminal. i've tried cmd 1>blah 2>bob to redirect them into files,
but i still get that message outputted onto the terminal.
Just trying to remove these messages from the pipe input i'm trying to
use for my rush stats curses script.
Yes, some error messages, such as those, are sent to stdout
along with the normal output.
The rule is any lines that start with "rush:" or "***"
should be considered error messages.
Though undocumented, this is actually dependable output
you can parse for and rely on. I've made sure all error
messages reported this way follow that specific format,
and tools like irush and rushtop parse for this. For instance,
this is how irush knows to print rush: errors and *** NO RESPONSE FROM
errors in red, and knows not to split those lines into columns.
The reason its in the stdout stream (and not stderr)
is that with 'rush -lac/-laj/-status', the error messages
must remain synchronized with the output so that eg. when
the -c <repcount> and -s <secs> flags are used, you can
determine which iteration the error output is associated with.
Using stderr would have worked if rush was only unix, but I
found early on when doing the windows port that windows is
very unreliable about keeping stdout/stderr synchronized
in pipes, and has KB articles that indicate this is a
"problem" with no known resolutions.
--
An D Nguyen
Systems Programmer / Perl Poet
Research & Development
FUEL International Pty Ltd
65 King Street, Newtown, Sydney NSW, 2042
Australia
|