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

[Maciej_Sieczka2]

Mon, 10 Jul 2006 08:44:30 +0200 (CEST)
Hamish via RT <grass-bugs@intevation.de> wrote:

Maciek Sieczka wrote:

> > still an issue? the fprintf's have been changed in v.patch.
>
> Yes.
>
> v.patch still prints to terminal instead of /dev/null. There is no
> difference to before the change you mention, ie.:
>
> $ v.patch input=map1,map2 output=map3 >/dev/null
> Patching file map1
> Patching file map2
> Patch complete. 2 files patched.
> 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.
>
> 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.

to redirect stderr to /dev/null do:

G61> v.patch input=map1,map2 output=map3 2> /dev/null

note this will send errors and warnings to /dev/null too, which may
not be what you want.

You are right, that is not a solution. We want errors and warnings be
let through.

most modules should be quiet by default (I think ESR asks for "only
display output if something surprising happens"), but include a -v
verbose flag if verbose output could be interesting (e.g. long running
modules). Really long running modules may want to send some heartbeat
or status messages.

> G> v.patch input=map1,map2 output=map3 >/dev/null
> Patching file map1
> Patching file map2

These look like they might be put behind a -v verbose flag or
G_debug(1,"");

> Patch complete. 2 files patched.
> 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 look like they should remain with G_message().

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.

Maciek

[H_B]

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