[GRASS5] Inconsistencies among modules

[Glynn Clements]

Rich Shepard wrote:

>   1)  Some modules (e.g., r.in.gdal, r.patch) allow the use of an existing
> output file name with no warning that that file already exists, and asking
> the user if it's OK to overwrite it. Other modules (e.g., r.poly, v.digit)
> tell the user that the output file name exists, does not ask for directions,
> and refuses to let the user overwrite it. Recommendation: always check,
> always ask, follow the user's directions.

There are two distinct issues here. One is the behaviour of
G_parser(), the other is the application.

1. If an option has a "gisprompt" field which starts with "new", and
the program is run without arguments, G_parser() won't let you specify
a layer which already exists. However, if you provide command line
arguments, G_parser() won't complain if the layer exists.

2. An individual applications might implement its own checks; if it
does, it might unconditionally refuse to overwrite or it might prompt. 
Also, it might choose to prompt only if stdin is a terminal; in which
case, there's the issue of whether or not to overwrite in the case
where it doesn't prompt. Or it might provide a flag to inhibit
prompting; or this might get rolled into the behaviour of switches
such as -q (quiet) or -v (verbose).

>   2)  Most modules present a status indication of processing; usually the
> percentage completed. Other modules (today it was r.poly) give no indication
> whether they are slowly working or have silently passed away.
> Recommendation: have a progress indicator for all modules.

This is likely to be a lot easier to actually implement than point 1
above. It doesn't require any significant design; it just needs people
to add calls to G_percent() within programs. However, there may be a
few cases where a percentage indication isn't practical.

It's straightforward in cases where the workload is a pre-determined
number of iterations of a loop with fairly constant overhead per
iteration. It's less straightforward for recursive algorithms, or
where a process is iterated until some test is passed.

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