[GRASSGUI] Re: grassgui Digest, Vol 4, Issue 6

[Michael Barton]

Thanks again Glynn


On 6/10/07 6:34 AM, "grassgui-request at grass.itc.it"
<grassgui-request at grass.itc.it> wrote:

The file= option would be most useful for users directly accessing the
command. 

> An alternative is to add stdin= and stdout= pseudo-options to the
> module's GUI dialog, so that the user can redirect stdin/stdout of any
> command from/to a file. This can be done in addition to a file= option
> for modules where it would be useful.
> 

Within a GUI environment, I'd like to be able to send these (and some other
commands a set of rules stored in a variable, so that I don't have to save
them to a tmp file and do the equivalent of...

cat [file] | r.recode input=[map] output=[map]

I'd rather do the equivalent of ...

echo $rules > r.recode input=[map] output=[map]

I'm not sure if this is permitted now, nor how to do it in Python if it is.

Nevertheless, if there is a file= option for all these color/reclass/recode
modules it would at least be consistent and I can deal with it.

> However: any module which is run from the GUI must behave in a
> non-interactive manner regardless of which flags/options the user
> selects. Having the module hang because the user chose a combination
> of options which results in the module trying to read from stdin isn't
> acceptable.

At least within a GUI setting this should be preventable.

Michael

> 
> You can probably eliminate hanging by simply closing stdin (or
> redirecting it from /dev/null), although that may just result in a
> different form of misbehaviour.


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

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton