[GRASS5] GRASS_STDERR vs. email

[William Kyngesburye]

er, wow, that IS quite a delayed reply. ^_^

I've long since removed that from the build instructions, and from my  
setup.  Since I left the GIS_ERROR_LOG, I still get errors logged  
there, of course.

I'm pretty sure that was a GRASS variable at one time - I was  
confused about shell vs. GRASS vars at one time so I made sure I got  
it right.  And when then email thing was the way it used to be, I did  
it this way and it worked.

On Sep 22, 2005, at 11:46 PM, Hamish wrote:

>> 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
>

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy