Found another minor item that a small change could improve.
g.gisenv does not behave like other GRASS commands in that you cannot launch the autogenerated gui by typing ‘g.gisenv’ from the command line. Instead, you get the current environment settings. You can only get the gui if you run it through some special processing in the GUI. Likewise, you can’t get it to print out current environment settings from the gui unless you do some tricks with its execution.
To behave more ‘normally’ it needs a –p flag. Then…
g.gisenv → autogenerated gui
g.gisenv –p → print current settings.
I suppose that this would break a bunch of scripts, but it would be nice if it could work consistently with other commands.
Michael
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Found another minor item that a small change could improve.
g.gisenv does not behave like other GRASS commands in that you cannot
launch the autogenerated gui by typing Œg.gisenv¹ from the command
line. Instead, you get the current environment settings. You can only
get the gui if you run it through some special processing in the GUI.
for a GUI just launch with:
g.gisenv --ui
use that as the menu command.
A number of modules work like this without command line args.
Likewise, you can¹t get it to print out current environment settings
from the gui unless you do some tricks with its execution.
g.gisenv store="" --ui
[Run]
Probably a nice GUI frontend should be used for that, vs exposing the
user to the raw g.gisenv GUI.
On 6/7/07 11:34 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
for a GUI just launch with:
g.gisenv --ui
This does work to get the gui from the command line
use that as the menu command.
A number of modules work like this without command line args.
Likewise, you can¹t get it to print out current environment settings
from the gui unless you do some tricks with its execution.
g.gisenv store="" --ui
[Run]
This doesn't work to get the settings printed to stdout. It just launches
the gui.
Michael
Probably a nice GUI frontend should be used for that, vs exposing the
user to the raw g.gisenv GUI.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
> Found another minor item that a small change could improve.
>
> g.gisenv does not behave like other GRASS commands in that you cannot
> launch the autogenerated gui by typing Œg.gisenv¹ from the command
> line. Instead, you get the current environment settings. You can only
> get the gui if you run it through some special processing in the GUI.
for a GUI just launch with:
g.gisenv --ui
use that as the menu command.
A number of modules work like this without command line args.
In general, modules where all options have a reasonable default value
work this way. E.g. "d.erase" is equivalent to "d.erase color=white"
rather than to "d.erase --ui".
Found another minor item that a small change could improve.
g.gisenv does not behave like other GRASS commands in that you cannot launch
the autogenerated gui by typing Œg.gisenv¹ from the command line. Instead,
you get the current environment settings. You can only get the gui if you
run it through some special processing in the GUI.
See Hamish's reply.
Likewise, you can¹t get
it to print out current environment settings from the gui unless you do some
tricks with its execution.
AFAICT, the problem with g.gisenv is that it checks for argc==1 before
calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to
fail.
What it should probably do is to call G_parser() unconditionally, then
check for:
if (!get->answer && !set->answer && !store_opt->answer)
To behave more Œnormally¹ it needs a p flag. Then...
g.gisenv -> autogenerated gui
g.gisenv p -> print current settings.
I suppose that this would break a bunch of scripts, but it would be nice if
it could work consistently with other commands.
I suspect that this is unnecessary if the no-arguments check is fixed.
I don't quite follow the proposed changes below, but I trust you that this
will probably fix things.
Michael
On 6/8/07 6:30 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Found another minor item that a small change could improve.
g.gisenv does not behave like other GRASS commands in that you cannot launch
the autogenerated gui by typing �g.gisenv� from the command line. Instead,
you get the current environment settings. You can only get the gui if you
run it through some special processing in the GUI.
See Hamish's reply.
Likewise, you can�t get
it to print out current environment settings from the gui unless you do some
tricks with its execution.
AFAICT, the problem with g.gisenv is that it checks for argc==1 before
calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to
fail.
What it should probably do is to call G_parser() unconditionally, then
check for:
if (!get->answer && !set->answer && !store_opt->answer)
To behave more �normally� it needs a �p flag. Then...
g.gisenv -> autogenerated gui
g.gisenv �p -> print current settings.
I suppose that this would break a bunch of scripts, but it would be nice if
it could work consistently with other commands.
I suspect that this is unnecessary if the no-arguments check is fixed.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
> Likewise, you can¹t get it to print out current environment settings
> from the gui unless you do some tricks with its execution.
Glynn:
AFAICT, the problem with g.gisenv is that it checks for argc==1 before
calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to
fail.
g.gisenv just outputs to stdout. There's no G_message() or G_percent()
or anything that would use --quiet. Just treat g.gisenv like it were
"ls" and send the output to a buffer or a temp file.
for example:
import os
prog = os.popen("g.gisenv")
print prog.read()
Michael:
> > Likewise, you can¹t get it to print out current environment settings
> > from the gui unless you do some tricks with its execution.
Glynn:
> AFAICT, the problem with g.gisenv is that it checks for argc==1 before
> calling G_parser(), so e.g. "g.gisenv --quiet" causes that check to
> fail.
g.gisenv just outputs to stdout. There's no G_message() or G_percent()
or anything that would use --quiet. Just treat g.gisenv like it were
"ls" and send the output to a buffer or a temp file.
The point is that *any* options (even ones which have no effect, e.g.
--quiet or --verbose) caused the argc==1 check to fail.
I've now changed it so that if you specify neither get= nor set=, it
will print the current settings.
Apart from not being confused by --quiet etc, you should now be able
to use "g.gisenv store=mapset" to list the VAR file.