Hi
I'm fowarding here in case anybody's interested.
From: "Harmish Bowman via RT" <grass-bugs@intevation.de>
To: "Maciek Sieczka" <werchowyna@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