[GRASS5] GRASS_STDERR vs. email

[Hamish]

> Hamish,
> 
> Markus thought you (or maybe someone else?) might know:

[Sorry for the delayed reply, just getting through some old emails..]

 
> I'm working on the GRASS build instructions on the GRASS site for Mac 
> 
> OS X.  Something I did a LONG time ago was:
> 
>  > g.gisenv set="GRASS_STDERR=1"
>  > touch ~/GIS_ERROR_LOG


A couple of things:


GRASS_STDERR is supposed to be a shell variable, not a GIS variable 
so to use it you would need to do  `export GRASS_STDERR=1`  if you are 
using bash* as your shell.

[*] OSX user accounts created under 10.1 or so (even if you have since
upgraded the OS) might still default to csh in which case you'd need 
to do something slightly different, see the GRASS variables help page.

GRASS uses both shell (set with `export GRASS_VARIABLE=value`) and GIS
variables (set with `g.gisenv set="VARIABLE=value"`) because GIS 
settings need to be shared between the GUI and the command prompt (for 
example) and the normal parent/child inheritance paradigm doesn't work.


However-- searching through the source code I see no reference to
GRASS_STDERR at all. I've now removed it from the variables help page.

However-- if we look at the CHANGES file that comes with the 6.0 source
code, we see:

"SOME CHANGES IN GRASS 5.7/6.0
[...]
- GISLIB
  - G_warning(), G_fatal_error() - send mail only if eviroment 
    variable GRASS_ERROR_MAIL is set"


So it only sends you mail for if you have the GRASS_ERROR_MAIL shell 
variable set and you are NOT running from a prompt normally (ie only
sends mail if stderr is redirected somewhere other than the tty).
[Added to the variables help page]

e.g. to get mail:
export GRASS_ERROR_MAIL=1
d.rast bad_mapname 2> /dev/null

Note a built in GRASS script may sometimes surpress stuff destined for
stderr from a module in this way.

If the ~/GIS_ERROR_LOG file exists you get errors and warnings logged to
it, independently of the mail settings. Also note there is code in
lib/gis/error.c to write to a GIS_ERROR_LOG file in $GISBASE as well
if it exists (and the program has write permissions there). This is to
collect system wide error messages vs. individual users' ones.

Also note if you are running from the GUI you don't get emails or 
anything logged to GIS_ERROR_LOG. I am not sure if this should be 
considered a bug.


Simple, huh?

Take home point is that now by default you only see errors on the 
screen. If you want to log them you can create ~/GIS_ERROR_LOG and
if you want emails you have to set GRASS_ERROR_MAIL explicitly and 
be redirecting stderr.


> so that the modules that emailed their status when done (ie  
> i.rectify), would instead dump that into the GIS_ERROR_LOG.

i.rectify (and i.photo.rectify) would send you mail regardless.


> I know there has been work on that recently, but I'm not certain if
> all the email bits are gone now or how much in which versions of
> GRASS.  Do you know if all the email stuff is gone?  Particularly,
> in each of GRASS 6.0.0, 6.0 CVS and 6.1 CVS.

6.0.x will send you mail when i.rectify is done
6.1+  will not send you email when i.rectify is done, but you do get a
       percentage complete like all the other modules.

And for warnings and errors, 6.anything will only send you mail if the 
above conditions are true regarding GRASS_ERROR_MAIL and stderr being
redirected. The idea is you'll miss the error if running from a script,
and you might like to have the option of knowing about it.

If the "mail" command in error.c's mail_msg() fails, I think it just 
fails silently. Thus "mail" is not a requirement.


hope that isn't too confusing. The logic behind all of this could be
revisited & improved..



Hamish