[GRASS-dev] Incorrect stuff coming through stderr?

[Michael Barton]

We are linking GRASS modules with a Java agent-based modeling environment.
The lack of consistency in GRASS output is an issue here, as it is with
trying to link GRASS with an interface building platform.

Because GRASS is a suite of command-line tools, it is an ideal platform to
be used by other platform for sophisticated modeling (Python, Java, etc) as
well as be wrapped in an interface platform to serve as a full-featured GIS.

However, GRASS was originally designed to be used by a person sitting at a
terminal, typing commands, and reading the output off the screen. That's why
there is output of the type produced by r.info and r.report. It's also why
it didn't matter about inconsistencies between the information provided by
r.display in different kinds of maps or between g.region -p and g.region -g

However, these become issues that range from annoyances (parsing r.info) to
impossibilities (parsing r.describe) when you try to use GRASS from another
environment than a user at a terminal.

There is nothing wrong with nicely formatted output (though it usually
depends on fixed-width fonts, and looks ugly otherwise). However, it would
be very useful (maybe even increasingly essential) that we also have a
standard, easy to parse output format that is consistent across all modules.
Standardized input is equally important, but we are in much better shape
there.

We already have a good start one kind of standardized output format, usually
called "shell-script style", but sometimes also called "terse" or other
things. This takes the format of "key=value" followed by a new line. It
would also be very helpful, however, to simply have commands return a list
of values in an order given in the command docs. So I'd like to propose the
following as a goal in future version of GRASS.

All commands that return values of some kind (i.e, that do not create or
modify maps) have the option to return ALL of their values (not just a
subset as is the case with g.region) in "shell-script" or "terse" format of
"key=value".

This option should be controlled by a standard flag for all modules for
consistency.

All commands that return values should also be able to return values as a
list of values "value value value...".

Again, this should be controlled by a standard flag for all modules.

... Snip snip ...
>> 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?

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).

I'm open to suggestion for how to modify this proposal. The objective is to
offer standardized output that would make it easier to use GRASS in
non-interactive environments.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton