[GRASS5] Re: General and gis.m module running (stdout,stderr,exit status) issues

Michael Barton michael.barton at asu.edu
Tue Apr 4 00:57:08 EDT 2006

On 4/3/06 4:38 PM, "Cedric Shock" <cedricgrass at shockfamily.net> wrote:

> execute runs the program with the --tcltk switch and sources the response, so
> it will always get a user interface. The syntax to put into the menu item
> depends on how we sort out the need for xmons and xterms (see below). Adding
> xmon and xterm flags to execute might be a neat syntax like in these
> examples:
> execute g.region
> execute v.digit xmon
> execute v.query xmon xterm
> execute g.setproj xterm

I like this idea. It's clean and doesn't require anything of the C modules.

>> For v.digit, I thought it might be how I tried to work it through gis.m, so
>> I tried running it from the command line and was still having problems.
>> Several programs (e.g., v.digit, d.profile) won't run unless there is an
>> open xmon. The old gis.m tried to help by opening an xmon before starting
>> one of those programs. People can simply do the whole thing manually, but
>> this can be complicated for newish users.
> I actually like having gis.m try to open a monitor for them. It just needs to
> work, and probably be independent of the method used to run the program. I
> think the appropriate logic for opening one would be something like this:
> If there's a running selected x display do nothing.
> Otherwise start and select the last (or first) not started x display.
> If there's no available (not running or running and selected) x display then
> do nothing and let the module report an error.

This is pretty much what my xmon procedure is (or was) doing. So maybe we
just fix this and do what you suggest above?


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

WWW - http://www.public.asu.edu/~cmbarton
Phone: 480-965-6262
Fax: 480-965-7671

More information about the grass-dev mailing list