[GRASS-dev] r.in.* modules and verbosity

[Hamish]

Jachym Cepicky wrote:
> I tryed to rewrite r.in.* (and some others) modules to stop to use
> fprintf and use G_message and G_warning instead. Plese test latest cvs
> version for your data type - I do not have access to most of this
> formats.

Module output which can be parsed should be sent to stdout. Module
output that just says "step 2: scanning data... " shoud use G_message().

Modules can print data to stdout, but should generally use G_* library
functions if they want to print to stderr.

> If I understand it well, r.in.xyz prints some informations to stdout.
> IMHO import (and export) modules should print nothing (except G_*) ,
> unless they are explicitly  asked for it.
> 
> So I suggest to add 
>     
>     -r  print range information
> 
> and
> 
> +   if (range) 
>        if (!shell_style) {
> -           fprintf(stderr,_("Range:     min         max\n"));
> +           fprintf(stdout,_("Range:     min         max\n"));
> 
> to r.in.xyz/main.c
> 
> What do you think?


No thank you, for both the flag and the change in output location.
This module was written with above stdout/stderr rules in mind.

Please leave "connected" output together. Even if that header line
doesn't contain parsable data, it is part of a table that does.
If the redirected data is sent to a file, in future you have no idea
what those numbers mean.

Also, if you redirect stdout to something, you still see
"Range:     min         max"  by itself at the terminal, which looks
weird.

Also, things like the GUI output can stall all messages to stderr until
after the module has completed. Then the "Range" line comes after the
data, which looks weird.  (at least the GUI used to act this way)

The -r flag is added complexity with no gain and redundant to the
function of the existing -s flag.


Hamish