Re: [Monotone-devel] question regarding stdio and streams

[Nathaniel J. Smith]

On Sat, Dec 23, 2006 at 08:52:26AM -0500, Ethan Blanton wrote:
> Nathaniel J. Smith spake unto us the following wisdom:
> > However, this would break piping, which is a rather more important
> > part of the Unix Way :-).  In particular: diff, log, status, annotate,
> > cat, all automate commands (and _especially_ automate stdio), ... all
> > expect their stdout stream to pristine of random chatter.
> 
> Normally this is handled by:
> 
> if (!isatty(1))
>     do_not_print_random_junk()

Bit klugy, though, don't you think?

> The fact that ticker junk is leftover when piping is one very
> important example of where I have found this irritating.

The only command I can think of that uses tickers and that you might
want to pipe is 'annotate', and there, the fact that tickers go to
stderr actually makes 'mtn annotate foo | less' work out quite nicely,
you see the ticker counting for a while, and then eventually when it
finishes you see the clean output.  If you dislike this, it seems like
you must actually dislike the ticker itself, and the stderr thing is
irrelevant?

> Optionally,
> tickers could be turned off without --verbose, instead.  On a whole,
> monotone is *extremely* verbose, which, again, is not part of the Unix
> Way -- I find myself ignoring monotone's output, because it always
> prints junk and the junk is never relevant.  This is bad, because at
> some point that junk will contain an error or a warning that I'll
> really wish I'd seen.  The boy who cried wolf effect is going on,
> here.

It's entirely possible that mtn is too chatty, but I don't think it's
something that has just never occurred to us, and now that you mention
it we all slap our foreheads and say "of course!  let's go strip out
90% of the print statements!".  Unfortunately, without examples, I
think our only possible actions are to either slap our foreheads or do
nothing at all, so some examples would be useful :-).

> > If you want to include the information into automate stdio's stdout
> > stream, you need to multiplex it in somehow, and I don't have any
> > particular opinion on what the best way would be to write such code.
> > I'm sort of surprised you even want it :-).
> 
> Well, that must be directed at the thread in general, and not me,
> because I'm not using automate stdio.  ;-)

Indeed.

-- Nathaniel