[GRASS5] [bug #820] (grass) Idea: links for g.remove, g.list,, g.rename maybe others

Markus Neteler neteler at itc.it
Fri Nov 9 07:51:58 EST 2001

On Fri, Nov 09, 2001 at 12:35:13PM +0000, Glynn Clements wrote:
> Markus Neteler wrote:
> > On Thu, Nov 01, 2001 at 08:44:48AM +0100, Request Tracker wrote:
> > > Related to this:
> > > g.remove behaves almost as I would like to... if no data
> > > type specifier is given, it defaults to rast. IMHO that is quite
> > > dangerous. If I want to remove the vector cover my_dear_map and manages to
> > > writes g.remove my_dear_map (because that is more similiar to a typical
> > > unix shell command), it removes quite happily the raster file
> > > my_dear_map....
> > 
> > I agree - at least for g.remove [g.mremove] there should be no default
> > data type to avoid above potential problem.
> > 
> > Any objections to change g.remove?
> No objection; but how do you intend to implement it?
> AFAICT, the behaviour in question is built into G_parser(). An
> argument which neither begins with a dash nor contains an equals sign
> is treated as the value of the first (non-flag) option.

yes, I didn't think of that.
> You could add a dummy option to the beginning of the list, but then
> that would show up in the "help" and "--interface-description" output,
> which isn't ideal. OTOH, it isn't as bad as inadvertently deleting the
> wrong map.
> Is it worth extending G_parser() for this case?

Maybe not. But what about simply changing the order to have
[icon=name[,name,...]] at the beginning? Only a few percent of the users
will use icons, so the probability to delete an icon because of having a
raster map with the same name is pretty low. This would solve the
problem easily.


More information about the grass-dev mailing list