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

[Glynn Clements]

Maciej Sieczka wrote:

> >>>> 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.

Okay, I can see your point here.

> 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.

Alternative possibilities:

1. Rename g.mremove (e.g. to g.remove.multi); if anyone asks where it
went, remind them that the new version doesn't request confirmation.

2. Revert g.mremove, add a version which doesn't prompt, change gis.m
to only refer to the non-prompting version.

Personally, I'd favour #1; option #2 undermines attempts to get
developers to realise that terminal interaction is unacceptable.

In my experience, any rule with an "except in special cases" qualifier
may as well not exist. Everyone thinks that their pet case qualifies,
and you end up with a useless mess.

Either you can rely upon GRASS commands being scriptable, or you
can't. Right now, you can't; if you try to build something on top of
GRASS, sooner or later something is going to try to prompt the
non-existent user for input which will never arrive.

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