[GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well

[Maciej Sieczka]

Paul Kelly wrote:
> On Thu, 8 Feb 2007, Hamish wrote:
> 
>> Markus:
>>>> up to now interactive input in tcl based dialogs is not possible.
>>>> Using the -f flag (force removal) you can delete also in gis.m.
>>>>
>>>> Probably we need to enforce -f somehow in gis.m - how to do that?
>>
>> Glynn:
>>> I've committed a fix which removes the prompting code. The -f flag
>>> remains for compatibility but is ignored.
>>
>> I understand the push to remove interactive, but this one is a fairly
>> important failsafe and I wouldn't mind it staying. With the -f flag a
> 
> I agree this seems a bit of a dangerous change, especially since an easy
> workaround was available... hope it doesn't catch anybody out who is
> just experimenting with a wildcard pattern but not sure if it's the one
> they want! I know I have used it like that in the past anyway.

I'm uneasy about this change too. Users who knew how g.mremove worked
in past will be surprised the safety question has been removed. Some of
them will be surprised badly, learning it when a precious map is
removed with the rest of the crowd on a sudden, while the user expected
y/n prompt.

I was never really carefull when giving the wildcard to g.mremove.
Propably nobody was, since we knew g.mremove will let us me verify the
wildcard's result before deleting data. Now the wildcard has to be
perfect at a first attempt, which is a unrealistic requirement when you
have dozens of maps in the mapset.

I agree that the interactivity has to be removed when possible, but in
this case it is too radical change I guess. It would be all OK if
g.mremove never asked for confirmation. But since it used to, it's
behaviour as users knew it for years is changed, and this change will
lead to data loss and user frustration. I don't think such radical
changes, even as fixes, should be allowed during GRASS 6.

What do you think about this: if g.mremove cannot remain
half-interactive, I'd suggest getting rid of it alltogether, and
replacing it's manual page with an instruction how to use "g.mlist
sep=," and feed it's output to g.remove by hand (I can write it).
Although removing a module during GRASS 6 should be avoided too, I
think that this would do less harm than letting g.mremove delete user's
data without control.

Or maybe revert the changes in g.mremove as it was, for GRASS 6, and
postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on
removing it completely, as described above, instead of removing it's
interactiveness, for the sake of user's data.

Maciek