[GRASS-dev] Re: [bug #4524] (grass) v.clean, v.patch (else?):

Hamish hamish_nospam at yahoo.com
Mon Jul 10 05:23:57 EDT 2006


Maciej Sieczka wrote:
..
> > > The above 6 lines should all go to /dev/null, too. v.clean is even
> > > worse - *not a single line* is redirected to /dev/null, so each
> > > v.clean run results in about 40 lines printed to the terminal.
> > 
> > GRASS sends general messages to stderr and parsable output to
> > stdout.
..
> What for? >/dev/null should result in filtering out all standard
> information. Only information in case of unexpected module behaviour
> should be let through. This will make user's scripts output cleaner.
> The above info is usefull for a single v.patch run, to give guiding to
> the user on how to proceed. But when v.patch is called from a script
> it is script's author responsibility to be aware of such caveats and
> use v.patch properly. IOW, when v.patch is called from a script the
> standard message above is not improving anything but decreases the
> output clarity.
> 
> Same for v.clean or any other module.


fyi, v.clean and any module that builds topology with Vect_build() sends
as its second argument the destination of messages. for v.clean this is:

Vect_build (pErr, stderr);

distribution is as follows:
$ cd vector/
$ grep -rI Vect_build * | grep stdout | wc -l
31
$ grep -rI Vect_build * | grep stderr | wc -l
41

clearly not standardized; this should be fixed to either one or the
other for most modules.

It is indeed arguable (as you suggest) that modules which will not
produce parsable output should have status messages sent to stdout. IMO
this would lead to a mess- GUIs, etc, couldn't redirect std* en masse
and presume that all modules will work as expected. Scripts would have
to be crafted for each module's needs individually.

The correct solution IMO is to relegate overly verbose messages to
G_debug(1,) or a -v verbose flag, and continue to send warnings and
errors to stderr.

> >  Patch complete. 2 files patched.

in effect G_done_msg().

> >  Intersections at borders will have to be snapped.
> >  Lines common between files will have to be edited.
> >  The header information also may have to be edited.

These 3 are somewhere between needing Warnings and boldface type in the
help page. (hence G_message())


The question might be reduced to "where to send G_message()?" ?


Hamish




More information about the grass-dev mailing list