[GRASS5] Inconsistencies among modules

[Glynn Clements]

Frank Warmerdam wrote:

> As someone (email already deleted!) pointed out, G_parser() actually 
> does this
> sort of existance test if it prompts for the raster name, but not if 
> supplied on
> the command line.  Should we look at fixing G_parser() to check for command
> line arguments too instead of trying to build alot of logic into each 
> program?

Yes.

> If so, should we leave this for post 5.0? I hate to make dramatic system 
> wide changes shortly before a release.

Definitely.

For a start, to solve this particular issue correctly would require
the "force overwrite" flag to be understood by G_parser() itself.

And this is only the tip of the iceberg in terms of potentially
worthwhile changes to application startup. I think that we need to
undertake a comprehensive survey of the way that programs are handling
their command line, so that G_parser() itself can provide features
such as:

+ Common flags, e.g. -q (quiet), -v (verbose), -f (force overwrite).

+ Option combinations; i.e. being able to tell G_parser() that one of
a set of alternatives is required, rather than telling it that none
are required followed by the application itself checking that at least
one was provided.

+ More specific types, e.g. colour, coordinate, datum, projection,
etc, rather than just specifying TYPE_STRING and having the
application decode it. Merge the "type" field with the first two parts
of the "gisprompt" field, so that names of
{old,new,any}-{raster,vector,sites} layers are each a specific type.

+ Dynamic defaults, e.g. where the default value depends upon the
current location/mapset or on settings obtained from the current
monitor.

+ Probably many more features, which would be made clear by a survey
of the code which existing applications have surrounding the call to
G_parser().

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