Hello developers
I was just wondering about the appropriateness of writing different types of module output to stderr or stdout, as I notice there has been some activity in 5.7 in this area recently. I am wondering if perhaps I have been wrong about how this should be used before:
When writing new code and fixing bugs I have tended to ensure that only output which is the actual result of a GIS processing operation that needs to be displayed to the user (rather than written to a file in the GRASS database) should be written to stdout. All other errors, warnings, informative progress messages and copyright notices etc. are written to stderr.
I'll use the example of re-directing output to a file to show why this makes logical sense to me.
g.proj -wf proj4=+init=epsg:29900 > irishgrid.prj
The point of this command is to convert the projection description described by '+init=epsg:29900' in PROJ.4 format into WKT format and store it in a .prj file. The WKT output is printed to stdout and stdout re-directed to a file, which accomplishes this nicely. But on running the above command, it is determined that +init=epsg:29900 does not contain enough information on datum parameters, so the user is prompted for more information. These prompts are written to stderr, so the user can still see them even though stdout is re-directed. The user can interactively choose the datum paramters and then the final version of the WKT output is written to the file. If the prompts also went to stdout then the user wouldn't see them and the program would just hang waiting for input from the user.
I suppose that for modules that only write output to another file in the GIS database, having information messages printed to stdout wouldn't result in mixing up, but still I was under the (possibly mistaken) impression that writing to stderr ensured the messages would always appear where the user could see them and act on them, regardless of where stdout was appearing (e.g. in a future GUI perhaps the stdout would be placed in a pretty 'results' window to be stored while stderr could be kept out of the way).
I was just wondering about the appropriateness of writing different
types of module output to stderr or stdout,
I'm totally not sure; the reason for splitting off the progress info from
the copyright information in v.surf.rst was to [at some point in the
future] make it possible to clean up the term output in the r.fillnulls
script without hiding the G_percent() progress. As this is usually just
filling a few cells here and there I didn't think it would be too
abusive of the authors' wish for some credit for their hard work when
the module is used extensively. There isn't anything in that module
which might be redirected to a file or piped to another program.
d.where and r.univar2 are good examples of where there is output which
could be redirected to a file or piped to another program, and there you
get a mix of stdout and stderr.
Another thing to consider is the tcl menus: stderr is written
immediately while stdout gets buffered and displayed after the module
finishes. So progress messages should always be sent to stderr to cover
that.
Also, I see that d.info uses a plain printf(), for whatever that's
worth.
Hello developers
I was just wondering about the appropriateness of writing different types of module output to stderr or stdout, as I notice there has been some activity in 5.7 in this area recently. I am wondering if perhaps I have been wrong about how this should be used before:
When writing new code and fixing bugs I have tended to ensure that only output which is the actual result of a GIS processing operation that needs to be displayed to the user (rather than written to a file in the GRASS database) should be written to stdout. All other errors, warnings, informative progress messages and copyright notices etc. are written to stderr.
I'll use the example of re-directing output to a file to show why this makes logical sense to me.
g.proj -wf proj4=+init=epsg:29900 > irishgrid.prj
The point of this command is to convert the projection description described by '+init=epsg:29900' in PROJ.4 format into WKT format and store it in a .prj file. The WKT output is printed to stdout and stdout re-directed to a file, which accomplishes this nicely. But on running the above command, it is determined that +init=epsg:29900 does not contain enough information on datum parameters, so the user is prompted for more information. These prompts are written to stderr, so the user can still see them even though stdout is re-directed. The user can interactively choose the datum paramters and then the final version of the WKT output is written to the file. If the prompts also went to stdout then the user wouldn't see them and the program would just hang waiting for input from the user.
I suppose that for modules that only write output to another file in the GIS database, having information messages printed to stdout wouldn't result in mixing up, but still I was under the (possibly mistaken) impression that writing to stderr ensured the messages would always appear where the user could see them and act on them, regardless of where stdout was appearing (e.g. in a future GUI perhaps the stdout would be placed in a pretty 'results' window to be stored while stderr could be kept out of the way).
On Sunday 17 October 2004 15:04, Paul Kelly wrote:
Hello developers
I was just wondering about the appropriateness of writing different types
of module output to stderr or stdout, as I notice there has been some
activity in 5.7 in this area recently. I am wondering if perhaps I have
been wrong about how this should be used before:
When writing new code and fixing bugs I have tended to ensure that only
output which is the actual result of a GIS processing operation that needs
to be displayed to the user (rather than written to a file in the GRASS
database) should be written to stdout. All other errors, warnings,
informative progress messages and copyright notices etc. are written to
stderr.
I am not sure. If info (no error/progress) is printed to stdout
it cannot be separated from data.
I suppose that for modules that only write output to another file in the
GIS database, having information messages printed to stdout wouldn't
result in mixing up, but still I was under the (possibly mistaken)
impression that writing to stderr ensured the messages would always appear
where the user could see them and act on them, regardless of where stdout
was appearing (e.g. in a future GUI perhaps the stdout would be placed in
a pretty 'results' window to be stored while stderr could be kept out of
the way).
My suggestion for discussion:
data -> stdout
messages -> stderr
and it should be consisten for all modules even if data are not printed.
Only stderr could be translated.
Examples for data:
- v.out.ascii without output
- v.category option=print
- v.to.db -p
- g.region -g
Messages:
- g.region -p
- r.info
For GUI, I suggest (as posted previously) some standard format,
i.e. add more prefixes like WARNING and ERROR, e.g. PERCENT.
We should also add the G_message, maybe with type ?
void G_message ( int type, const char *msg );
I suppose that for modules that only write output to another file in the
GIS database, having information messages printed to stdout wouldn't
result in mixing up, but still I was under the (possibly mistaken)
impression that writing to stderr ensured the messages would always appear
where the user could see them and act on them, regardless of where stdout
was appearing (e.g. in a future GUI perhaps the stdout would be placed in
a pretty 'results' window to be stored while stderr could be kept out of
the way).
Any thoughts?
Any output which you might want to save to a file or pipe to another
program should go to stdout. Anything which should go to the terminal
even when stdout is redirected should go to stderr.
Prompts, progress indicators etc should always go to stderr.
Meaningful data (e.g. r.info, g.region -p, etc) should always go to
stdout. For anything else, consider the stdout-to-file/stderr-to-terminal
scenario and try to decide whether stdout or stderr is more appropriate.
In any case, many GRASS programs are far more "talkative" than they
should be, IMHO. We should probably have an environment variable to
determine whether "progress" messages (i.e. G_percent(), messages
indicating the processing "phase" etc) should be generated. With a
"quiet" setting, most programs would generate no output whatsoever
unless there's an error.