Hi, sometimes it is a good idea to rethink existing design decisions and re-implement it in a better way. As you stated the shell style output was added to the modules successively without having a specific design rule, but imitating g.region. Maybe its a good time to change this, at least in GRASS 7.
As an example the Vask lib and therefor interactive behavior of modules was removed too, to implement it in a better, more modular way ... . IMHO the point is that GRASS 7 is designed to use Python as scripting language. So the working environment wont mess up, if a dictionary is used to manage the modules output. Best regards Soeren 2011/11/14 Hamish <[email protected]>: > Martin wrote: >> shrug, `-g` is mainly used for shell script output, >> I think it would be better update `r.info` and `v.info` to >> follow this logic, g.region is an exception. You are going to >> the opposite direction! > > AFAIR g.region was the original, using -g to display region > bounds in shell script style. later "-g" was added to r.info > and v.info to do the same, and later again "-g" was added to > other modules like r.univar as generic shell script style > alias -- not the other way around! These were mostly added by > MarkusN and myself over the years, although I am very sure > there were others involved too. > > r.info -g, v.info -g, g.region -g all show the region in shell > script style and all act the same. it's a good thing and makes > learning the tools easier. IMO it would be a disservice to morph > -g into a shell style dump of all internal variables. it clutters > your working environment. > > > 2c from fuzzy memories of years ago, > Hamish > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
