[GRASS-dev] Re: [GRASS-SVN] r49204 - grass/trunk/vector/v.info

[Sören Gebbert]

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 <hamish_b at yahoo.com>:
> 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
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>