Hi, 2013/8/13 Hamish <hamis...@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 removed >> >> to >> >> 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, > 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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
