[GRASS-dev] Re: [GRASS-user] r.reclass not spawning xterm on Mac OS X

Michael Barton michael.barton at asu.edu
Mon Nov 13 17:01:55 EST 2006


Am I understanding the proposed changes correctly? They will make no
difference for how the current wrapper scripts operate with r.reclass (and
related files), but will will make them functional--albeit in the old xterm
interface--when run from the command line without arguments. This will serve
as an interim solution for keeping these modules functional while the old
interactive xterm modules are being phased out.

Is this the gist or did I miss an important point?

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

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


> From: Hamish <hamish_nospam at yahoo.com>
> Date: Fri, 10 Nov 2006 17:36:02 +1300
> To: <michael.barton at asu.edu>, <glynn at gclements.plus.com>,
> <dechant at nature.berkeley.edu>
> Cc: grass5 <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-user] r.reclass not spawning xterm on Mac OS X
> 
>> Michael Barton wrote:
>>> You have to run r.reclass with arguments to get to the xterm
>>> interface. From the GIS Manager, there is a script that does this.
>>> 
>>> Running r.reclass without arguments will open a GUI that is pretty
>>> useless.
> 
> I have modified r.reclass and r.recode in 6.3-CVS to force interactive
> term mode if they are run without arguements. The GUI wrapper scripts
> should not be affected. Let me know if they don't.
> 
> 
>> A couple of potentially useful enhancements:
>> 
>> 1. Add a rules= option to r.reclass which accepts the name of a file
>> containing reclass rules.
>> 
>> 2. Add a button to the standard dialogs which allows stdin to be
>> redirected from a user-specified file.
>> 
>> Either of those would allow r.reclass to be usable without a terminal.
> 
> this is exactly what Michael's two wrapper scripts provide.
> 
>  
>> There's still the general issue of what we do about
>> terminal-interactive modules. So long as at least one such module
>> exists, the issue remains.
>> 
>> Either we decide to "kill them all",
> 
> not until functionality is ported to something newer, or analysis method
> is conisdered obsolete. (does anyone use the i.class stuff?)
> 
>> and declare all use of stdin to be a bug,
> 
> stdin is very useful for scripting use. the problem is exclusive input
> via stdin (or interactive term) and no option to take from a file. you
> can have input from a file as the primary method and still allow the
> module to take data from stdin.
> 
>> or we need some way for a module to indicate that it needs (or may
>> need) a terminal. The latter is complicated by the fact that a module
>> may only require a terminal in certain circumstances.
> 
> It's not a full solution at all, but see above r.reclass commit.
> 
> 
>> Comments? Please. I'd *really* like to get this issue dealt with; it's
>> been coming up since the days of d.m (maybe even since tcltkgrass).
> 
> trying to get a list of remaining modules:
> 
> r.le - in the process of being replaced by r.li
> r.digit - just a frontend to r.in.poly, easily replaced by a wxPython
>   utility (integrate with wxPython version of v.digit as g.digitize?)
> r.watershed - all sorts of interactive menus in shed/ which I'm not sure
>   how to access.
> r.support - being worked on by Brad
> 
> i.* are the main apps without a solution in progress.
> 
> 
> 
> $ grep -rI G_ask * | cut -f1 -d: | uniq
> 
> general/g.setproj/get_datum.c
> general/g.setproj/main.c
> general/manage/lib/ask.c
> general/g.ask/main.c
> include/P_site.h
> include/gisdefs.h
> lib/gis/ask_vctrs.c
> lib/gis/ask_cell.c
> lib/gis/nme_in_mps.c
> lib/gis/ask.c
> lib/gis/get_ell_name.c
> lib/gis/gislib.dox
> lib/gis/get_projname.c
> lib/gis/gisvectorlib.dox
> lib/gis/get_datum_name.c
> lib/gis/parser.c
> lib/gis/gisrasterlib.dox
> lib/imagery/sigfile.c
> lib/imagery/sigsetfile.c
> lib/sites/sites.c
> raster/r.le
> raster/r.watershed
> raster/r.support
> raster/r.coin/inter.c
> raster3d/r3.showdspf/r3_find.c
> raster3d/r3.mkdspf/r3_find.c
> 
> $ grep -rI '$(VASKLIB)' * | grep Makefile | cut -f1 -d:
> general/g.mapsets/Makefile
> general/g.access/Makefile
> imagery/i.cca/Makefile
> imagery/i.ifft/Makefile
> imagery/i.gensig/Makefile
> imagery/i.group/Makefile
> imagery/i.his.rgb/Makefile
> imagery/i.zc/Makefile
> imagery/i.rgb.his/Makefile
> imagery/i.rectify/Makefile
> imagery/i.target/Makefile
> imagery/i.smap/shapiro/Makefile
> imagery/i.gensigset/Makefile
> imagery/i.cluster/Makefile
> imagery/i.vpoints/Makefile
> imagery/i.fft/Makefile
> imagery/i.maxlik/Makefile
> imagery/i.class/Makefile
> imagery/i.points/Makefile
> imagery/i.ortho.photo
> imagery/i.pca/Makefile
> lib/init/Makefile
> lib/edit/Makefile
> lib/imagery/Makefile
> ps/ps.map/Makefile
> raster/r.le
> raster/r.support
> raster/r.digit/Makefile
> vector/v.transform/Makefile
> 
> 
> Hamish




More information about the grass-dev mailing list