[GRASS-dev] making grass modules less verbose

Jachym Cepicky jachym.cepicky at centrum.cz
Wed Sep 20 07:18:47 EDT 2006


hallo Paul,

On Wed, Sep 20, 2006 at 11:52:13AM +0100, Paul Kelly wrote:
> Hello Jachym
> In order to keep module output as consistent as possible, I feel it might 
> be better to implement this as a "quiet" flag rather than a verbose flag? 
> I.e. by default output continues as normal but if, as you say the modules 
> need to be used in something like an emebedded system with minimal output 
> then the quiet flag could be specified.

http://www.faqs.org/docs/artu/ch11s09.html

I'm not UNIX coder, but I think, I can agree with most of the statemets
listed in this chapter of Art Of Unix Programing:

1) If your CLI program emits status messages to standard output, then
programs that try to interpret that output will be put to the trouble of
interpreting or discarding those messages (even if nothing went wrong!).

*Better to send only real errors to standard error and not to emit
unrequested data at all.*

g.remove (?)

2) The user's vertical screen space is precious. 

v.in.ascii (?)

3) Junk messages are a careless waste of the human user's bandwidth.

g.remove

4) In general, it's bad style to tell the user things he already knows.

5) be chatty only about things that deviate from what's normally
expected. 

G_fatal_error() will always be printed

This was the reasons, i was thinking about, when adding --verbose
and not --quiet flag. Most of the people do not actually care, that
some module is "opening raster files". The work can be done in
background. --verbose could be first step of debuging info. Because of
the user wants to check the progress of the program, i'm suggesting the
idea of log file, which would be removed after grass session is done.

Anyway, if most of the developers would prefere --quite, it is no
problem to implement this and also to change GRASS_VERBOSE to
GRASS_QUITE.

> 
> I was thinking also it would be a good test for which modules write 
> directly to stderr and which should possibly be changed to use 
> G_message(), if you set the quiet flag before running them. Although 
> G_message() doesn't offer as much flexibility as printing to stderr,
> e.g. no backspace or bell.
> 
> Paul
> 

How difficult would it be to make G_message to be able to print
backspaces or bells?

Jachym

> On Wed, 20 Sep 2006, Jachym Cepicky wrote:
> 
> >On Wed, Sep 20, 2006 at 09:37:36AM +0200, Sören Gebbert wrote:
> >>Hi,
> >>i think this is a nice idea.
> >>Some modules are very verbose and with this approach a general
> >>way is provided to handle this verbosity.
> >>
> >>Best regards
> >>Soeren
> >>
> >
> >I prepared new patch (for current cvs version) which makes all modules
> >be able to use --verbose flag or to set GRASS_VERBOSE env. variable.
> >
> >G_message, G_warning and G_percent are now able to handle according to
> >the user needs.
> >
> >Could anybody test this?
> >
> >If this works well and nobody has any objection, I would implement the log 
> >file idea.
> >
> >The hard part will be go throu all modules and replace (f)printf for
> >G_message(), but I could take care on this. Another thing: parts of g.* 
> >and v.* modules do not use G_message at all.
> >
> >Jachym
> >
> >-- 
> >Jachym Cepicky
> >e-mail: jachym.cepicky at centrum.cz
> >URL: http://les-ejk.cz
> >GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> >-----------------------------------------
> >OFFICE:
> >GDF-Hannover
> >Mengendamm 16d
> >30177 Hannover
> >Germany
> >e-mail: cepicky at gdf-hannover.de
> >URL:    http://gdf-hannover.de
> >Tel.:   +49 511-39088507
> >


-- 
Jachym Cepicky
e-mail: jachym.cepicky at centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky at gdf-hannover.de
URL:    http://gdf-hannover.de
Tel.:   +49 511-39088507
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060920/1ed745fa/attachment.bin


More information about the grass-dev mailing list