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 removed > > to > > 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. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
