[GRASS5] Re: [bug #3009] (grass) g.remove - accidental removing possible!

[Maciek Sieczka]

Hi

I'm fowarding here in case anybody's interested.

From: "Harmish Bowman via RT" <grass-bugs at intevation.de>
To: "Maciek Sieczka" <werchowyna at pf.pl>
 Subject: [bug #3009] (grass) g.remove - accidental removing possible!

Maciek >>>>
Hamish >>>
Maciek >>
Hamish >

>>>>If the user doesn't specify the 'type' in g.remove then raster is taken
>>>>as a default, which may lead to accidental removing what you not
>>>>intended to. Seems scarry.

>>> I think the benefits of not having to enter the default option= part for
>>> every command outweighs the harm of the occasional deleted map.

>> And I don't :). Safety, reliability and idiot-proofness (to the possible
>> extent) first.

> In general I agree with that fully; in this case it happens to screw up
> pretty much every GRASS script ever written so I am hesitant to change
> it. e.g. you'd have to then do "d.mon start=x0" not just "d.mon x0" etc.

This is unrelated - d.mon is not a file-management command and it cannot do 
any harm to you whatever you use it.

> In addition to breaking a lot of scripts anything that requires extra
> keystrokes slows down power users and is to be avoided if possible

Power users first? Hmm, doesn't sound inviting to Grass adepts.

>> Besides - since uniform, predictable behaviour is possible to achieve,
>> why not implement it? By now g.remove, g.mremove,  g.rename and g.copy do
>> not treat raster files and all the other types equally. And why to assume
>> that Grass users will be working more with raster data than with vector,
>> rast3d, asciivect,  sites etc., especially now when Grass' new vector
>> engine attracts more vector-oriented GIS users?

> It is this way for historical reasons of course. GRASS -was- a raster
> based GIS for the most part, so default actions acted on raster files. So
> until there is a major re-write, the entire architecture is biased
> towards rasters for good or ill.

I understand but I hope it doesn't mean this won't be changed at all.

>>> Perhaps there could be a test for a g.gisenv variable like the OVERWRITE
>>> one to ask "Are you sure"? This could be disabled by power users; needs
>>> a Yes/No GUI [see g.message emails on grass5 list]

>> I don't find it more practical than removing the default target
>> permanently. I'm *guessing* it might be the same amount of work to code
>> it, but the resulting solution wouldn't be any better.

> Removing the default target incurs problems as stated above.
> Amount of coding is not really the issue.

I see your points but in my opinion they should not be taken into account in 
a further perspective of Grass development in respect to g.remove, 
g.mremove, g.rename and g.copy.

Maciek