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

[Martin Landa]

Hi all,

trying to reconcile your notes I prepared the new patch for g.remove,
I will commit it (or prepare a new one) after your full feedback...

export GRASS_VERBOSE=2

Raster map:

g.remove rast=t;echo $?
Remove <t>
WARNING: Raster map <t> not found
WARNING: <t> nothing removed
0

r.mapcalc t=1 2>/dev/null;g.remove rast=t;echo $?
Remove <t>
0

3D raster map:

g.remove rast3d=t;echo $?
Remove <t>
WARNING: Raster 3d map <t> not found
WARNING: <t> nothing removed
0

r3.mapcalc t=1 2>/dev/null;g.remove rast3d=t;echo $?
Remove <t>
0

Vector map:

g.remove vect=t;echo $?
Remove <t>
WARNING: Vector map <t> not found
WARNING: <t> nothing removed
0

v.random out=t n=1 2>/dev/null;g.remove vect=t;echo $?
Remove <t>
0

Region:

g.remove region=t;echo $?
Remove <t>
WARNING: <t> nothing removed
0

g.region save=t;g.remove region=t;echo $?
Remove <t>
0

Best, Martin

2006/10/11, Maciej Sieczka <tutey at o2.pl>:
> 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
>


-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_remove3.diff.gz
Type: application/x-gzip
Size: 1058 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061011/1e582bdb/g_remove3.diff.gz