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

[Patton, Eric]

I like this solution, Hamish. I always rely on g.mremove to produce a
listing prior to deletion, and your patch seems to preserve this
behavior. 

--
Eric Patton 
email: epatton at nrcan.gc.ca

> -----Original Message-----
> From: grass-dev-bounces at grass.itc.it 
> [mailto:grass-dev-bounces at grass.itc.it] On Behalf Of Hamish
> Sent: Monday, February 12, 2007 5:24 AM
> To: Glynn Clements
> Cc: grass-bugs at intevation.de; paul-grass at stjohnspoint.co.uk; 
> grass-dev at grass.itc.it
> Subject: Re: [GRASS-dev] [bug #5483] (grass) g.mremove 
> through gis managerGUI seems not to work well
> 
> 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
>