[GRASS-dev] Re: r49205 - in grass/trunk: lib/python raster/r.info

[Michael Barton]

Does this mean that we are abandoning the idea to have -g determine *how* out put is printed (i.e., shell-script style) and use other flags to determine *what* is printed? 

Michael 
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu


On Nov 27, 2011, at 10:00 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Sat, 26 Nov 2011 17:50:39 -0800 (PST)
> From: Hamish <hamish_b at yahoo.com>
> Subject: [GRASS-dev] Re: r49205 - in grass/trunk: lib/python
>        raster/r.info
> To: Martin Landa <landa.martin at gmail.com>
> Cc: GRASS developers list <grass-dev at lists.osgeo.org>
> Message-ID:
>        <1322358639.73854.YahooMailClassic at web110016.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Martin:
>> current situation is
>> 
>> r.info
>> ? -g???Print raster array information only
> 
> [in shell script style!]
> 
>> ? -e???Print extended metadata information only
> 
> [also in shell script style!]
> 
>> v.info
>> ? -g???Print region info in shell script style
>> ? -e???Print extended metadata info in shell
>> script style
>> 
>> which forces to open discussion again.
> 
> ..did it ever close? :-)
> 
> what is new since last we discussed this is r.info's
> many shell script style flags are now grouped* so
> it is not as messy in the module GUI.  IMHO it is a
> good compromise, and consistent design among modules
> is still respected.
> 
> [*] https://trac.osgeo.org/grass/changeset/49293
> 
> so -rgstmpud becomes -ger instead of just one huge
> -g.  Non shell-script safe foo=(bar) things are kept
> in -e, so you can still `eval` -g.  Instances of
> '(none)' have been changed to '"none"' to become
> more shell friendly as well.
> 
> 
>> I would still incline to use `-g` for shell
>> script output as used in others modules.
>> I have counted more than 45 modules in trunk
>> which use `-g` for shell script style output.
> 
> huh? I don't understand what you are talking about.
> 
> ** r.info -g, v.info -g, and g.region -g  DO all
> print eval-safe shell script style ** same as ever,
> still shell script style, still similar to -g in
> other modules...
> 
> Keep in mind that r.info and v.info's default
> "pretty" output mode is a tractor-fed dot-matrix
> printer style report, not a "foo: bar" listing. [and
> fwiw there is no point for "min: 1.2345" instead of
> "min=1.2345" style, since min= is perfectly human
> friendly to read]
> 
> 
> What they are not is a full --parsable-debug-data-
> dump which may save a gui programmer 5 keystrokes
> in a python library which is revisited once every
> 3 years, but make things totally annoying for a
> command line user who uses that same flag 20 times
> a day, not to mention making them eval-unsafe.
> 
> If you need a --dump-everything-parsable flag some-
> where then fine add that (better yet just make a
> wrapper --script instead of messing up the code),
> but don't remove the fine grained eval-safe shell
> script style options in the process. These things
> do not have to be mutually exclusive. But -g does
> have to stay shell-script (ie eval) safe.
> 
> 
>> I don't see any reason why `r.info` or `v.info`
>> should be exceptions.
> 
> ?! they aren't !?
> 
> 
> If you want to see an exception, look at d.what.rast
> -t "terse" output flag.
> 
> 
> Hamish