On Sat, 14 Jan 2006, Tim Rightnour wrote:
> 
> On 13-Jan-2006 Alan Barrett wrote:
> > Well, I think that stderr would be the right default, and I can't easily
> > think of a case where I'd want progress(1) to write to stdout.  I can
> > easily think of cases where I'd want output to /dev/tty (so stdout and
> > stderr can be reserved for use by the command spawned by progress).
> 
> If people think this is a reasonable thing to do, I can back out the change,
> and set the default output to stderr.  However we need to know 2 things:
> 
> 1) Will this affect any current uses of progress, such as sysinst?  The -e
> change was relatively safe because it didn't modify the default behavior,
> however if people have written scripts or whatnot around the current behavior
> of progress, we may break them unexpectedly.  I don't take that as lightly.

sysinst runs commands inside a pty, with stdin/stdout/stderr all
connected to the pty.  See the call to login_tty() in launch_subwin()
in distrib/utils/sysinst/run.c.  So there's no problem with sysinst if
progress() suddenly starts writing to stderr instead of stdout.

Nothing else in-tree uses progress(1).

The only users who will be affected, AFAICT, are those who run progress
with stdout and stderr going to different places.  The most likely way
of doing that, "progress somecommand | pipeline", previously didn't work
because the progress messages would go to the pipeline instead of being
visible, so people would not have done it.  Complicated workarounds like

        progress sh -c 'somecommand >&2' 2>&1 >/dev/tty | pipeline

would previously have worked but will break if progress(1)
starts writing to stderr instead of stdout; they will have to be
rewritten as

        progress somecommand | pipeline

> 2) You propose wanting to output to /dev/tty.  How do you propose we
> allow that from an option standpoint?  A -d <device> option?

Or -o outputfile, possibly with magic special treatment for
"/dev/stdout" and "/dev/stderr" (so that they DTRT even if the device
nodes do not exist in /dev).  Or just forget this, and decide that
writing to stderr is good enough.

--apb (Alan Barrett)