Hi all,
AFAR there was already discussion related to g.remove/g.copy/g.rename
modules. Before we start releasing GRASS7 tech-preview I would prefer
to change the current behaviour.
g.remove x
Removing raster <x>
WARNING: Raster map <x> not found
WARNING: <x> nothing removed
to
g.remove x
ERROR: Invalid data element (valid options: rast,vect..)
->
g.remove rast=x
What do you think? Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi Martin,
On Sunday 11 Aug 2013 11:05:44 Martin Landa wrote:
Hi all,
AFAR there was already discussion related to g.remove/g.copy/g.rename
modules. Before we start releasing GRASS7 tech-preview I would prefer
to change the current behaviour.g.remove x
Removing raster <x>
WARNING: Raster map <x> not found
WARNING: <x> nothing removedto
g.remove x
ERROR: Invalid data element (valid options: rast,vect..)->
g.remove rast=x
What do you think?
+1
I like the idea!
Pietro
On Sunday 11 of August 2013 11:50:26 Pietro Zambelli wrote:
Hi Martin,
On Sunday 11 Aug 2013 11:05:44 Martin Landa wrote:
Hi all,
AFAR there was already discussion related to g.remove/g.copy/g.rename
modules. Before we start releasing GRASS7 tech-preview I would prefer
to change the current behaviour.
g.remove x
Removing raster
WARNING: Raster map not found
WARNING: nothing removed
to
g.remove x
ERROR: Invalid data element (valid options: rast,vect…)
→
g.remove rast=x
What do you think?
+1
Same here (being a messy user this is an extra “safety” feature).
Thanks, Nikos
Martin wrote:
AFAR there was already discussion related to g.remove/g.copy/g.rename
modules. Before we start releasing GRASS7 tech-preview I would prefer
to change the current behaviour.g.remove x
Removing raster <x>
WARNING: Raster map <x> not found
WARNING: <x> nothing removedto
g.remove x
ERROR: Invalid data element (valid options: rast,vect..)->
g.remove rast=x
What do you think?
I'd personally prefer to have it stay as-was, but whatever. (Extra keystrokes just slow me down.)
I wonder though, as long as rast= stays as the first option will your
example of "g.remove rast=x" still just work as "g.remove x" anyway since the parser assumes the first option as the default? (this is what currently happens)
And so does the change need some deeper parser override? If so I'd be very hesitant about touching that in libgis as it breaks predictability of parser usage. that consistency is a very strong selling point &/or any inconsistency makes the learning curve that much harder and messier. To me that consistency is more important than the pain of the lesson of how the parser works.
how would it be implemented?
regards,
Hamish
ps- my big question prior to g7 preview: to reorganize raster elements into $MAPSET/raster/mapname/elements dir structure for g7 or not? if so as per Glynn's plan we need to clean-room/from scratch(spec) write a MIT/X licensed G6 raster map driver for gdal ASAP.
Hi,
2013/8/13 Hamish <hamish_b@yahoo.com>:
Martin wrote:
AFAR there was already discussion related to g.remove/g.copy/g.rename
modules. Before we start releasing GRASS7 tech-preview I would prefer
to change the current behaviour.g.remove x
Removing raster <x>
WARNING: Raster map <x> not found
WARNING: <x> nothing removedto
g.remove x
ERROR: Invalid data element (valid options: rast,vect..)->
g.remove rast=x
What do you think?
IMHO it should stay as it is, since the first option is used as
default, as Hamish said.
I'd personally prefer to have it stay as-was, but whatever. (Extra keystrokes just slow me down.)
I wonder though, as long as rast= stays as the first option will your
example of "g.remove rast=x" still just work as "g.remove x" anyway since the parser assumes the first option as the default? (this is what currently happens)And so does the change need some deeper parser override? If so I'd be very hesitant about touching that in libgis as it breaks predictability of parser usage. that consistency is a very strong selling point &/or any inconsistency makes the learning curve that much harder and messier. To me that consistency is more important than the pain of the lesson of how the parser works.
how would it be implemented?
Good question. 
Best regards
Soeren
regards,
Hamishps- my big question prior to g7 preview: to reorganize raster elements into $MAPSET/raster/mapname/elements dir structure for g7 or not? if so as per Glynn's plan we need to clean-room/from scratch(spec) write a MIT/X licensed G6 raster map driver for gdal ASAP.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev