[GRASS-dev] Incorrect stuff coming through stderr?

[Glynn Clements]

Michael Barton wrote:

> >> 56%  60%  64%  68%  72%  76%  80%
> >> 84%  88%  92%  96% 100%
> >> CREATING SUPPORT FILES FOR managed.2.6
> >> 
> >> It occurs when I create the new maps using r.in.ascii and is sent via
> >> standard error.
> > 
> > What's the problem? Progress messages are normal, and are supposed to
> > be written to stderr.
> 
> It seems odd to me that progress messages are written to stderr. However, if
> that is the norm across C programs, then I guess that's were they belong.
> But does " CREATING SUPPORT FILES FOR managed.2.6" also go there?

It should.

As a general rule, human-readable output goes to stderr while
machine-readable output goes to stdout. There are two main reasons for
this approach:

1. If you have a pipleine such as:

	foo | bar | baz > out.txt

the data piped between commands and written to the file consists
solely of machine-readable data. Writing diagnostics or status message
to stdout would confuse programs further down the pipeline, or
programs reading the resulting text file.

In the above example, none of the redirections affect stderr, so it
would continue to refer to the terminal.

2. At program startup, stdout is line-buffered if it refers to a
terminal and fully-buffered otherwise (e.g. for files, pipes or
sockets), while stderr is unbuffered.

Writing to a fully-buffered stream won't produce any
externally-visible results until either the buffer is full or an
explicit fflush() is used.

If stdout is a terminal, you will only see complete lines of output,
so output where lines are composed over time (e.g. percentage output,
or "doing something ..... <long delay> ... done") will appear all at
once upon completion.

Worse, if stdout is a pipe (or file being monitored with "tail -f ..." 
from another terminal), you will only see output in complete blocks
(typically 4KiB).

> We also need a "quiet" option for all commands to suppress all stdout except
> the actual output values. There is a lot of verbage produced some GRASS
> commands that might be nice for a user at a terminal to read, but that is
> problematic when GRASS modules are being used in other environments. This is
> available for some modules, but has variable effects (i.e., sometimes it
> only suppresses some of the extraneous verbage).

That isn't hard to implement, although it's a fair amount of (rather
tedious) work.

There are two parts:

1. Change individual modules to use G_message() rather than
[f]printf() for all progress messages.

2. Add a G_INFO_FORMAT_QUIET option to G_info_format() and change
G_message() to take note of it.

-- 
Glynn Clements <glynn at gclements.plus.com>