[GRASS-dev] r.mapcalc and g.remove --v/q issues

[Maciej Sieczka]

Glynn Clements wrote:

> "not found" is only one failure mode. It's also possible that some or
> all of the files which make up the map exist but couldn't be removed.

> There are essentially 4 cases:
> 
> 1. Nothing found.

"WARNING: Raster map <dummy> not found"

> 2. Some files found, none removed.

"ERROR: Raster map <dummy> found, but none of it's components could be
removed:
(here comes the list)"

> 3. Some files found, some removed.

"ERROR: Raster map <dummy> found, but only the following components
where removed:
(here comes the list)
The following components couldn't be removed:
(here comes the list)"

> 4. Some files found, all removed.

"WARNING: Raster map <dummy> removed"

> #2 and #3 are unarguably failures, while #4 is unarguably success.
> 
> Whether #1 is a failure or success is debatable. It should certainly
> result in notification, probably even at minimum verbosity, but it's
> less clear that it should result in a non-zero exit code.

I agree: exit code 0 and a warning - even at min. verbosity.

> If it fails to remove some components of a map, it's necessary for the
> user to be told the details, IMHO, as the user is going to have to fix
> the problem manually.

I agree. But the situation #2 or #3 is quite unlikely - one would need
to lose his write access for some files that make the given GRASS
raster map, while retaining his write acces to it's other components
(is there a possible scenario for this within GRASS?). Or he would have
to corrupt his raster map by removing some of it's components manually,
outside the GRASS.

And as the prevailing real life situations are #1 and #4, g.remove by
default shouldn't bother the user with the internals of GRASS raster
map format. Like it doesn't in case of vector format, although it also
consists of several files AAMOF.

Maciek