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

[Martin Landa]

Hi,

2006/10/23, Hamish <hamish_nospam at yahoo.com>:
> (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. If the "-f"
> force flag is used then it probably should not be an error however.
>
> The choice is then for the user to decide to ignore that error as
> harmless or not. But it is still an error.
>
> 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
>

It is debatable, at least I suggest to print a given warning (in case
of raster/vector map) and exit with EXIT_FAILURE exit status code. The
question is what to do when an user want to remove more data set
elements simultaneously, eg.

g.remove rast=dummy,map

in this case exit status code should be 0 or 1?

rm dummy,test -f
echo $?
0

According to GNU rm, G_fatal_error should be called for non-existing
data set element, G_warning in connection with -f flag. It would be
the best solution(?).

> > 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 agree with you, it should *not* be backported to GRASS 6.2.

> 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.
>
>
> thanks,
> Hamish
>

best, Martin

-- 
Martin Landa <landa.martin at gmail.com> * http://gama.fsv.cvut.cz/~landa *