[GRASS-dev] Incorrect stuff coming through stderr?

[Helena Mitasova]

Michael, you may want to put this into wiki for GRASS7, it will get  
lost in the email list.
http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection

Helena

On Sep 2, 2006, at 1:26 PM, 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.
>
> 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
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev