[GRASS5] Re: 5.1: --html-description to parser added

[Markus Neteler]

On Fri, Feb 07, 2003 at 01:46:55AM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > Is there a better way than faking a GRASS session (hope so!)?
> > > 
> > > Ultimately most of G_gisinit() ought to be moved to G_parser(); but
> > > that would require that everything actually used G_parser(), which
> > > isn't the case at present.
> > 
> > Correct. In general it may be interesting to have 'parser'
> > as program for script usage (so that we don't have to build a
> > parser any more with shell commands) which provides parameters
> > and flags as
> > PARAM1
> > PARAM2 ..
> > FLAG1 ...
> > 
> > for further usage in a script.
> 
> See src/general/g.parser; it really needs some documentation, though.

Oops. I can't believe that I was unaware of this :-)
 
> > > There are some other problems. E.g. some modules call G_get_window(),
> > > R_open_driver() etc and initialise the defaults based upon data from
> > > the current region or the monitor. This is (arguably) OK if the user
> > > is running "g.foo help" interactively, but it means that the defaults
> > > in the HTML file will reflect the session which was used to generate
> > > it.
> > 
> > That's another point against a fake session. If the (updated) parser 
> > got a flag to run without a GRASS session, it could be used in
> > Makefile and above problem should be minimized.
> 
> Yes, but this requires finding and fixing all of the programs which
> call GRASS functions prior to G_parser(). FWIW, I've discussed this
> previously:
> 
> 	From: Glynn Clements <glynn.clements at virgin.net>
> 	Message-ID: <15135.13549.677759.452840 at cerise.nosuchdomain.co.uk>
> 	Date: Thu, 7 Jun 2001 09:01:49 +0100
> 	Subject: Re: [GRASS5] Darwin Pre1 gtty stty errors

http://grass.itc.it/pipermail/grass5/2001-June/000186.html

I remember the problem. As 5.1 is growing slowly, the developers can
easily take care of this problem.

> This mentions the following programs as using raster/display functions
> to initialise defaults (so they fail if no monitor is selected):
> 
> 	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
> 
> Also:
> 
> 	From: Glynn Clements <glynn.clements at virgin.net>
> 	Message-ID: <15163.33358.71553.232455 at cerise.nosuchdomain.co.uk>
> 	Date: Thu, 28 Jun 2001 20:15:26 +0100
> 	Subject: Re: [GRASS5] Interfaces ... (long)

http://grass.itc.it/pipermail/grass5/2001-June/000394.html
 
> This mentions specific classes of problem, but not the individual
> programs:
> 
> 	1. D_get_cell_name (d.colors), D_get_{cell,dig,site}_list (several
> 	programs) and other functions (d.save) to obtain state from the
> 	monitor.
> 	
> 	2. G_gisbase, G_mapset, G_projection, G_zone, G_get_window and
> 	G_get_set_window to obtain information about the current location.
> 	
> 	3. spheroid_list and datum_list. In the case of spheroid_list, many
> 	programs implement this function independently.
> 	
> 	4. G_{lat,lon}_format_string, D_color_list. These functions actually
> 	just return string literals.
> 	
> 	5. read_list (used by g.{copy,list,remove,rename} to parse
> 	etc/element_list).
> 
> 1 and 2 are the real problems here; they won't work without a session,
> 1 won't work without a monitor, and both will produce
> --interface-description (etc) messages which are specific to the
> session in which they are run.
> 
> Some alternative mechanims were proposed in the messages referenced
> above.

So it is unfortunately less easy than expected. I still like the
idea to generate whatever possible automatically to reduce the workload
of the people documenting GRASS.

Markus