From: An Nguyen <an@(email surpressed)>
Subject: rush error messages
   Date: Sun, 20 Apr 2008 20:57:45 -0400

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.

terminal. i've tried cmd  1>blah 2>bob to redirect them into files,
but i still get that message outputted onto the terminal.

rush stats curses script.

--

An D Nguyen

Systems Programmer / Perl Poet
Research & Development
FUEL International Pty Ltd
65 King Street, Newtown, Sydney NSW, 2042
Australia

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.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

Oh thank you, for your detailed response.

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

An Nguyen wrote:
> 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.

	Mmm. correcting myself, the 'rush:' errors go to stderr, but the
	"*** NO RESPONSE FROM" messages go to stdout.

> 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

	Switch the 2>&1 and 1> around; the order is important.
	You should get correct behavior with:

./stats.pl 1>blah 2>&1

	..where both stdout + stderr appear in 'blah'.

	This is not just OSX, but all versions of unix regarding
	the bourne shell. It can be shown with ls(1), which reports
	errors to stderr:

tower:~ root# ls notfound
ls: notfound: No such file or directory

tower:~ root# ls notfound 2>&1 >/dev/null	<-- 2>&1 first is ineffective
ls: notfound: No such file or directory		<-- (error message still shown)

tower:~ root# ls notfound >/dev/null 2>&1	<-- 2>&1 last works normally
tower:~ root#					<-- (error message not shown)

	Hope that helps.

-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

An Nguyen wrote:
> 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.

	Looking back at your first message, 1>blah 2>bob definitely
	should be catching that "No route to host" message.

	So you're saying the 'No route to host' is still getting through
	even if you invoke your ./stats.pl command as:

../stats.pl 2>err.log 1>out.log

	..and for sure that's a bourne compatible shell you're
	invoking that from? (csh/tcsh syntax is different)

	That really should work.. no message should be appearing on
	the tty.

	What perl command is being used to run 'rush -laj' (system(), open("|"), etc)
	and are there any special shell redirection characters as
	part of that command? Is the $ENV{SHELL} set to something other
	than a bourne shell? (Try setting $ENV{SHELL}="/bin/sh"; explicitly)

	Rush doesn't try writing anything to the tty directly,
	so if you're getting problems with messages leaking past
	>1 and 2>, I'm not sure why, and would have to work with you
	interactively to figure that one out.

Hi Greg,
I think i've found out what my issue is.

I'm actually piping the rush output to 'grep' and
redirecting the stderr and stderr of grep instead of
the rush command. e.g.

rush -laj | grep Done 2>/dev/null

Hence rush's stderr messages were echoing
to the terminal.

Sorry about that, i knew it was something really really silly.
Its just that host errors doesn't appear 100% of the time
and I thought to myself, yay it worked etc.

Thanks again for your help.



Greg Ercolano wrote:

[posted to rush.general]

An Nguyen wrote:

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.

	Looking back at your first message, 1>blah 2>bob definitely
	should be catching that "No route to host" message.

So you're saying the 'No route to host' is still getting through

	even if you invoke your ./stats.pl command as:

./stats.pl 2>err.log 1>out.log

	..and for sure that's a bourne compatible shell you're
	invoking that from? (csh/tcsh syntax is different)

	That really should work.. no message should be appearing on
	the tty.

	What perl command is being used to run 'rush -laj' (system(), open("|"), etc)
	 and are there any special shell redirection characters as
	part of that command? Is the $ENV{SHELL} set to something other
	than a bourne shell? (Try setting $ENV{SHELL}="/bin/sh"; explicitly)

	Rush doesn't try writing anything to the tty directly,
	so if you're getting problems with messages leaking past
	>1 and 2>, I'm not sure why, and would have to work with you
	interactively to figure that one out.

--

An D Nguyen

Systems Programmer / Perl Poet
Research & Development
FUEL International Pty Ltd
65 King Street, Newtown, Sydney NSW, 2042
Australia