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

Glynn Clements glynn at gclements.plus.com
Wed Oct 11 00:35:51 EDT 2006


Maciej Sieczka wrote:

> >> i just tested g.remove (lates grass cvs version).
> >>
> >> If i try to remove a non existent map i get this warning:
> >>
> >> GRASS 6.3.cvs > g.remove rast=huch
> >> WARNING: <huch> nothing removed
> >>
> >> I think this is a wrong warning, because map "huch" does not exist.
> >> Maybe i'm doing something wrong?
> > 
> > So far as g.remove is concerned, maps don't "exist" (or not) as
> > monolithic entities. A map (or any other entity type, e.g. stored
> > regions) can have multiple elements; e.g. a raster map can have any or
> > all of the elements:
> > 
> > 	cell cellhd cats colr hist cell_misc fcell g3dcell
> > 
> > Previously, g.remove would simply tell you whether the element was
> > removed, missing, or removal failed. If a map didn't exist at all, it
> > would just print "MISSING" for every element.
> > 
> > Now, it prints nothing if one or more elements exist, and the above
> > warning if no elements exist.
> > 
> > The basic behaviour is correct, but we might want to think about the
> > exact message. The above might be interpreted as meaning that
> > something which exists wasn't removed, when it actually signifies that
> > nothing was removed, either because there wasn't anything to remove or
> > because removal failed.
> > 
> > Note that if an element exists but removal fails, you get a separate
> > warning for each failed removal.
> 
> Still g.remove doesn't output an information like it should,
> considering it's function, for either the success or failure case.
> Here's why I think so:
> 
> There is a thing called raster map in GRASS, so the 'g.remove rast=map'
> should be concerned with this thing as a whole. Same for g.copy/rename,
>  It's not the point whether a raster map is consisted of one or more
> and what kind of files actually. There is no need to pull the user into
> the details of the GRASS raster format in any of these modules at a
> default DEBUG level. So the message should just be "WARNING: raster map
> <huch> not found" for failure and "raster map <huch> removed" for
> successs.

"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.
2. Some files found, none removed.
3. Some files found, some removed.
4. Some files found, all 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. When the
command completes, the map doesn't exist, so it was "successfully
removed" in that sense.

> It should not refer to particular components *directly*, like
> it used to until recently, or *indirectly*, like it does now in
> "WARNING: <huch> nothing removed". For the latter I mean that the
> "nothing" implies that "something" would be removed under some
> circumstances, and "something" would not - like if a raster map was not
> an integral unity (again, it doesn't matter raster im GRASS is made of
> a few files; they are only a form for the content that the raster is).
> A module to remove a map is not supposed to be concerned with the
> internals of the given map. It is just supposed to try to remove the
> map, return a failure or success and issue appropriate information if
> failed or succeeded.

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.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list