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

[Glynn Clements]

Hamish wrote:

> (sorry, I don't want this thread to go on forever, and didn't follow
> all that was discussed, but the following assertion requires some
> supporting arguments)
> 
> Maciej Sieczka wrote:
> > It is very good that g.remove vect doesn't return 1 exit status
> > anymore if the file doesn't exist.
> 
> why? you told the module to do something specific and it didn't/couldn't
> do that for some reason. This sounds like an error to me.

It did what you told it to, in the sense that the file doesn't exist
when g.remove has finished.

IOW, the map (or other entity) has been deleted. The fact that
deletion involved the removal of zero elements rather than one or more
elements is an "internal" detail.

> If the "-f" force flag is used then it probably should not be an
> error however.

-f has a different purpose. Just because you don't want to forcibly
remove reclass maps, that doesn't mean that you want the operation to
fail unnecessarily.

> The choice is then for the user to decide to ignore that error as
> harmless or not. But it is still an error.

An error is when the entity still exists when you have asked for it to
be deleted.

> at least GNU & co. call it an error, if we can take some guidance from
> them:
> 
> $ rm no_file
> rm: cannot lstat `no_file': No such file or directory
> $ echo $?
> 1
> 
> $ rm -f no_file
> $ echo $?
> 0

Standard utilities have to conform to historical behaviour, even if
such behaviour isn't logical.

> > For this reason I think the patch should be applied ASAP as is, so
> > this important fix makes to GRASS 6.2, if nobody minds.
> 
> I mind:
> 
> Please be very careful with what is applied to the 6.2 branch.
> Especially at this late date we should try for critical fixes only.
> 
> This is especially especially true for "policy" changes such as this
> one. (none of the recent --quiet improvements should be backported to
> 6.2)
> 
> Will a change unintentionally break any scripts which expect the old
> behaviour/return value? That takes a lot of testing (time) to find out.

Actually, I don't think that it requires any testing. If a script
wants to ensure that a map (etc) doesn't exist (which is a safe
assumption, if it's running g.remove), why would it want to fail if
the file never existed in the first place?

To me, it seems more likely that the existing behaviour might result
in bugs due to scripts neglecting to allow for this possibility.

With the existing behaviour, a script which wants to remove a file
which may or may not exist can't easily determine whether the file has
actually been removed without failing due to false positives.

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