Maciej:
> 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).
No, just remove it from the GUI if the possibility of interactivity is
an issue, or create a wrapper script for the GUI which does not include
the offending flag. I don't think it is so bad to have command-line-only
power-tools, and to leave g.mremove out of the GUI if that's what is
required.
> 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.
Removing a module during GRASS 6 should not be allowed at all.
That will break scripts and render documentation+books out of date.
> 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.
Glynn:
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.
Personally I'd prefer #2 or removing g.mremove from the GUI menu vs.
adding yet another duplicate module.
but wait --
** A compromise idea: make g.mremove without "-f" exit (0 or 1?) after
listing the files the regex would match; have it only delete something
if "-f" is used. The extra tick of brain activity to type the extra 3
chars should be enough to invoke the do-I-really-want-to-do-this 2nd
thought, if not, well that's not our problem, we tried. That way we only
"break" interactive mode, and the new solution is in a way interactive
(they have to retype the command).
-- patch attached.
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;
Point taken.
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.
It's a worthy goal, and something we should do for GRASS 7, but we can't
go around breaking people's scripts in order to make their scripts
easier to write! [Glynn's patch in CVS does not do that; some of the
proposed solutions might] As far as g.mremove goes, I imagine scripters
figured out they needed to use "-f" when they wrote it.
So how do folks feel about the compromise solution? Without -f it skips
the y/n prompt, forcing "no", and a functional g.remove command line is
sent to stdout for perusal[, piping, logging, whatever], along with a
message to stderr that you need to use -f if you actually want to remove
files.
Hamish
(attachments)
mremove_force.diff (964 Bytes)