this bug's URL: http://intevation.de/rt/webrt?serial_num=820
-------------------------------------------------------------------------
Subject: Idea: links for g.remove, g.list, g.rename maybe others
Platform: Linux/Intel
Linux distro: RedHat
linux cpu: AMD (K6, ...)
Xwindows version: Xfree 3.3.6
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.2
grass downloaded at: Hannover site
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, pre-2
c compiler name: gcc
Regarding the commands for general cover management i.e g.copy, g.rename, g.remove, g.list (maybe also others) could it be possible (at least in unix..) to make links to the same command for each data type?
In stead of writing g.list rast, I could write r.list and have a list of raster files, in stead of writing g.copy vect=vector1,vector2, I could write v.copy vector1 vector2 etc. For systems that do not support multiple links to a file, different versions of the commands could of cource be used.
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....
-------------------------------------------- Managed by Request Tracker
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....
Hi,
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?
Markus
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.
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?
--
Glynn Clements <glynn.clements@virgin.net>
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.
Markus