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

[Hamish]

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