[GRASS-dev] Exit code for Tk GUI

[Glynn Clements]

Maris Nartiss wrote:

> > An alternative is to make the initial command return wish's exit code
> > (which is returned from pclose()), i.e.:
> 
> This was also my first idea, but, as I noted, it would break all
> existing modules.
> When module gets launched from console, it will create GUI via
> G_parser and then use G_parser return code to exit or continue running
> (assuming all required options are set, what isn't true if G_parser
> was using GUI), thus getting back module fail/sucess to first running
> module instance via G_parser is impossible (w/o fixing all modules).
> Example from r.info:
> if (G_parser(argc, argv))
> 	exit(EXIT_FAILURE);
> 
> Thus only way how to get back module exit code to console is by
> replacing already running module with it's GUI via exec().

G_gui() can call exit() with the value returned from pclose(); it
doesn't have to return to the caller. See my patch.

> > However, that's only part of the solution, as you note in point #2
> > below.
> >
> > > Currently such approach has some problems:
> > > 1) if user hits RUN button in GUI w/o any param's, it starts another
> > > module window (hint - need to look how parser determines that GUI is
> > > already running);
> >
> > It doesn't.
> 
> It does. I have to look more closely to G_parser how to distinguish
> when module is launched from GUI and then not exec() new wish
> instance.

Maybe my reply wasn't clear; I should probably have snipped the text
more aggressively to:

> > > (hint - need to look how parser determines that GUI is
> > > already running);
> >
> > It doesn't.

IOW, the parser makes no attempt to determine whether the GUI is
running; it behaves the same regardless.

When a module requires one or more arguments and is run with none,
G_parser() either calls interactive() (if GRASS_UI_TERM is set) or
G_gui() (if GRASS_UI_TERM isn't set.

If the --ui switch is used, G_gui() is always called, even if other
arguments are given or if GRASS_UI_TERM is set.

If you want to prevent the GUI from invoking a command which simply
creates another GUI, change the GUI code so that it never runs a
command without arguments. The GUI will never be displayed
automatically (without --ui) if any arguments are given.

Alternatively, we could change G_parser() to only go interactive if no
arguments are given *and* there is at least one "required" option. 
Typically, modules with no required options (i.e. where all options
have a default value) skip calling G_parser() altogether if no
arguments are given (argc <= 1); e.g. d.erase:

	if (argc > 1 && G_parser(argc, argv))
		exit(1);

> > To generate the dialogs, gis.m invokes the command with the --tcltk
> > switch. This causes the command to write the generated code to stdout,
> > rather than spawning a wish process. gis.m reads the Tcl/Tk and
> > executes it locally, having previously overriden some of the
> > procedures in gui.tcl (specifically, run_cmd and
> > make_{buttons,output,progress}).
> 
> Original bugreport was referring to running module from CLI (bash) and
> checking exit code via echo $?.

Yes, the (implied) --ui case.

> > > 2) still way how to get module exit code from gronsole is required.
> >
> > Getting the actual exit code isn't possible, AFAICT. The problem is
> > that Tcl's "open |..." syntax can create a pipeline consisiting of
> > multiple commands. In fact, the gronsole code always spawns two
> > commands (the second is the grocat program, used to merge stdout and
> > stderr).
> 
> This is biggest bummer :(
> If somebody doesn't come up with some solution to this problem, then
> we have to just document permanent GRASS bug - module with GUI allways
> exits with error.

If you're running the command manually from the command line, you
probably aren't paying any attention to exit codes. If you're running
it from a script, you're likely to be providing arguments.

-- 
Glynn Clements <glynn at gclements.plus.com>