[GRASS-dev] 'g.gui wxpython' won't work in wingrass as wxgui is a shell script

Glynn Clements glynn at gclements.plus.com
Thu Feb 28 12:33:44 EST 2008


Glynn Clements wrote:

> > >  > as wxgui is a shell script, g.gui wxpython (which does:
> > >  >
> > >  >  else if (strcmp(type->answer, "wxpython") == 0) {
> > >  >         sprintf (progname, "%s/etc/wxpython/scripts/wxgui", G_gisbase());
> > >  >         if (rc_file->answer) {
> > >  >             G_spawn(progname, "wxgui", rc_file->answer, NULL);
> > >  > )
> > >  >
> > >  > will not work.
> > 
> > since gis.m and d.m are also shell scripts, g.gui tcltk|oldtcktk will
> > not work too(?)
> 
> The batch file may work, but I would suggest invoking gm.tcl directly,
> similar to the above.

I have committed changes to g.gui to invoke gm.tcl and d.m.tcl
directly, rather than via the shell scripts.

One consequence of this is that all three GUIs currently run in the
foreground, so you need to run g.gui itself in the background (i.e. 
"g.gui &") to avoid locking up the terminal (or you can use Ctrl-Z
then "bg" after starting g.gui).

> > There is one problem, when you run `g.gui wxpython`, the program is
> > waiting for thread termination. So you cannot use xterm when wxGUI is
> > running. I am not sure how to fix it since I am not so familiar with
> > G_spawn*.
> 
> G_spawn() behaves like system() in that it waits for termination.
> 
> You could use G_spawn_ex() with the SF_BACKGROUND flag (although we're
> still waiting for a Windows implementation of G_spawn_ex()), or you
> could fork() before calling G_spawn() (but fork() doesn't exist on
> windows).
> 
> So far as a Windows implementation of G_spawn_ex() is concerned, a
> partial implementation using spawnvp() or spawnvpe() should be
> relatively straightforward, and better than nothing.

I have also committed a minimal Windows implementation of
G_[v]spawn_ex(), as outlined below. It hasn't been tested yet, though.

> That wouldn't support redirection, current directory, or signal
> handling (I don't think that signal handling can be implemented on
> Windows in any case). But implementing SF_BACKGROUND is
> straightforward (don't use P_WAIT), and implementing environment
> bindings isn't particularly problematic (the existing environment is
> in the global variable "_environ").
> 
> AFAICT, a version based upon CreateProcess() would also allow the
> redirection and current directory flags to be implemented.
> 
> FWIW, the primary function which needs to be re-implemented is
> do_spawn(), in lib/gis/spawn.c.
> 
> Off the top of my head, the following seems about right:
> 
> static int do_spawn(const char *command)
> {
> 	char **env;
> 	int status;
> #if 0
> 	/* these also need implementing, eventually */
> 	do_redirects(redirects, num_redirects);
> 	env = do_bindings(_environ, bindings, num_bindings);
> #else
> 	env = _environ;
> #endif
> 
> 	status = spawnvpe(background ? _P_NOWAIT : _P_WAIT, command, (char **) args, env);
> 
> 	if (!background && status < 0)
> 		G_warning(_("Unable to execute command"));
> 
> 	return status;
> }

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


More information about the grass-dev mailing list