[GRASS5] Darwin Pre1 gtty stty errors

[Eric G. Miller]

On Thu, Jun 07, 2001 at 09:01:49AM +0100, Glynn Clements wrote:
> These programs fall into five basic categories:
> 
> 1. False positives (apparently). Most of the listed d.* programs seem
> to handle the --interface-description flag fine.
> 
> 	d.colortable
> 	d.db
> 	d.geodesic
> 	d.icons
> 	d.label
> 	d.legend
> 	d.leg.thin
> 	d.measure
> 	d.menu
> 	d.points
> 	d.scale
> 	d.sites
> 	d.sites.qual
> 	d.text
> 	d.title

NOTE: Each one of these produces a Segmentation fault after outputting
the description on the command line.  Since I generated the list from a
little script, presumably the segmentation fault was generated before
the interface description had been output to stderr.  Possibly still 
a problem if another program tries to popen() these programs...

> 2. A number of d.* programs obtain defaults for certain options from
> the monitor:
> 
> 	d.colors	- D_get_cell_name
> 	d.pan		- D_get_cell_list, D_get_dig_list, D_get_site_list
> 	d.save		- R_screen_{top,bot,left,rite}, R_pad_list, R_pad_select
> 	d.what.rast	- D_get_cell_list
> 	d.what.sites	- D_get_site_list
> 	d.what.vect	- D_get_dig_list
> 	d.zoom		- D_get_cell_list, D_get_dig_list, D_get_site_list
> 
> There are two main options for fixing these:
> 
> a) Disable the determination of defaults. This is simpler, but removes
> potentially useful functionality.
> 
> b) Initialise the defaults to a "magic" string, e.g. "<default>" (or
> "<default_cell>") etc, then determine the actual values after calling
> G_parser.

Yea, this is a tough nut, since G_parser might go interactive before the
real defaults could be generated. This was part of the thing I was
trying to get across with the idea of a "spec", or more appropriately
"interface" file.  That is, main() could be generated from the interface
file, and other programs could utilize this "interface" file to generate
gui dialogs and such.  That'd be a big change though...

> 3. A few programs could use G_parser but don't.
> 
> 	g.version
> 	m.in.stf1.tape
> 	p.chart
> 	p.labels
> 	r.agnps50.run
> 	r.agnps50.view
> 	v.in.tig.lndmk
> 
> 4. Most of the remaining programs are strictly interactive. These
> basically just won't play nice with any kind of global framework. The
> only fix is to extract any useful functionality and incorporate it
> into either:
> 
> a) one or more command-line utilities (where the program's interactive
> nature is gratuitous), or
> 
> b) a properly-designed application (where the user interaction is
> necessary).
> 
> 	d.display
> 	d.labels
> 	d.rast.edit
> 	g.access
> 	g.help
> 	g.setproj
> 	i.class
> 	i.colors
> 	i.composite
> 	i.group
> 	i.ortho.photo
> 	i.points
> 	i.points3
> 	i.quantize
> 	i.rectify
> 	i.tape.mss
> 	i.tape.other
> 	i.tape.spot
> 	i.tape.tm
> 	i.target
> 	i.vpoints
> 	m.examine.tape
> 	m.futil
> 	m.lulc.USGS
> 	m.proj
> 	p.colors
> 	p.icons
> 	r.digit
> 	r.mask
> 	r.reclass.scs
> 	r.water.fea
> 	r.weight
> 	tcltkgrass
> 	v.digit
> 	v.export
> 	v.import
> 	v.out.mapinfo
> 	v.out.moss
> 	v.patch.scs
> 	v.sdts.meta
> 
> NB: some of these are simply interactive front-ends to command-line
> programs (e.g. r.reclass.scs and v.patch.scs).
> 
> 5. Miscellaneous cases.
> 
> 	v.in.tig.basic
> 	r.mapcalc
> 
> v.in.tig.basic is almost in the OK category. It calls G_projection to
> check that the projection is LL or UTM; this could be done after
> G_parser is called.
> 
> r.mapcalc could be made to use G_parser (e.g. "expr=..."). Whether to
> do so comes down to whether the advantage of consistency outweighs the
> disadvantage of changing its syntax.
> 
> There's something of a chicken-and-egg situation here. The consistency
> doesn't provide any benefit if nothing takes advantage of it, but the
> usefulness of a generic front end is reduced if important programs
> won't work with it.
> 
> Summary: Programs in category 1 don't need changing. I'll look into
> fixing those in categories 2 and 3, using option b) for category 2.

Maybe we could track down the reason for the Segmentation fault's in
category 1, as the interface description output seems to fail when
called from a script.

> Most of category 4 is going to have to stay as-is for 5.0.0, although
> some of them might be amenable to "rehabilitation" as command-line
> programs without too much work.

I guess a program that would use this mechanism could blacklist
"category 4" programs...

-- 
Eric G. Miller <egm2 at jps.net>