[GRASS5] Darwin Pre1 gtty stty errors

[Glynn Clements]

Eric G. Miller wrote:

> > > The dtd is not copied to "etc" though it should be (or share/xml ??).
> > > I was just playing with this the other day to parse the output from
> > > hitting each command with the "--interface-description" flag.
> > > Unfortunately, some modules (and shell scripts), do things before
> > > calling G_parser() that muck this up.
> > 
> > Do you have any specific cases? That sort of thing should probably be
> > fixed for 5.0.0.
> 
> You asked for it (note, I don't have any of src.garden compiled...)

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

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.

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.

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.

-- 
Glynn Clements <glynn.clements at virgin.net>