[GRASS-dev] Incorrect stuff coming through stderr?

[Hamish]

Michael Barton wrote:
> 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.

Implement Java bindings for the SWIG interface?
See QGIS<->GRASS module glue?

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

With r.info you have a point (although extending the -g flag as
suggested by Martin could help that). For me r.info has all the flags I
need (because we've added them as needed...), but v.info could use a
parsable version of lines= boundaries= etc.

What's so hard about parsing "r.describe -q1"?


> It seems odd to me that progress messages are written to stderr.

If you redirect stderr with "2> /dev/null" all that should be left is
parsable output from stdout.

> We also need a "quiet" option for all commands to suppress all stdout
> except the actual output values.

or otherwise stated, only parsable output should be sent to stdout.


I agree with your basic tenet that as much functionalily as possible
should be able to be dealt with by scripts or wrapper functions (i.e.
generalized interoperability). I think we are well on our way to this
already, certainly more so than the competition.



Hamish