<p>Hi Hamish,</p>
<p>No, I just run it from within GRASS.  But let's see if it works with the latest version (I'LLC try tomorrow).</p>
<p>Thanks!</p>
<p>Paulo</p>
<div class="gmail_quote">On Jan 28, 2013 10:14 PM, "Hamish" <<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Margherita wrote:<br>
> Hamish,<br>
> KUDOS! It works like a charm, tested with addons in C, in<br>
> python and in bash.<br>
> Thanks A LOT!<br>
<br>
glad to hear it. It's just the first step though, making sure it<br>
also still works from the various packages (esp. Mac) is needed.<br>
<br>
Paulo, re.:<br>
> ERROR: G_getenv(): Variable LOCATION_NAME not set<br>
<br>
I'd again ask Markus's question- are you trying to run the script<br>
from outside of GRASS? The help pages get their usage info auto-<br>
matically from a modified version of 'g.module --help', so if<br>
you try to run it from outside of GRASS the module fails to run<br>
and that's the error you are seeing. During the main build we<br>
don't have a grass session to use for that so we employ a trick<br>
that creates a fake grass session (called "demolocation", perhaps<br>
a poor choice of words) and runs it there. The bootstrapping from<br>
that to the installed stripped down build system for g.extension<br>
and self compiled addon modules or self-supplied scripts  is in large part the cause of all the trouble we've had with this, it's a multicontext situation. But solvable, and hopefully that part of it is all ok now.<br>

<br>
<br>
regards,<br>
Hamish<br>
</blockquote></div>