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

[Glynn Clements]

Hamish wrote:

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

That's a good idea.

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

Note that my patch retained the -f flag, although the script doesn't
pay any attention to it. Any scripts using "g.mremove -f ..." would
work as before.

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

Seems okay to me.

1. -f works as before.

2. Omitting -f won't unconditionally delete files which wouldn't have
been unconditionally deleted before.

3. The changed behaviour when -f is omitted isn't really a problem as
that case always required user interaction.

4. It still "works" (i.e. doesn't hang) if a terminal isn't available.

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