[GRASS-dev] r49166 consolidating flags from r.info

GRASS GIS GRASS GIS developer
1

Hi,

I am not so sure about r49166. I don't really mind about adding map type
and res to -g to make it more like 'g.region -g', but wonder if things like
vertical datum and data units should only export if they actually exist.

Note -t can't be included, as if the title contains chars like () then
eval `r.info -g` will fail.

(for `r.info -t` I've always had to use `cut -f2- -d=` instead of eval)

also a bunch of scripts and python libs should be updated if the usage
changes.

comments?

thanks,
Hamish

2

Hi,

2011/11/10 Hamish <hamish_b@yahoo.com>:

I am not so sure about r49166. I don't really mind about adding map type
and res to -g to make it more like 'g.region -g', but wonder if things like
vertical datum and data units should only export if they actually exist.

the main question here is to keep behaviour consistent across all
GRASS modules which prints info in shell script style. Basically there
are two options, the items which are not defined

1) will be printed with empty value (`datum=`)
2) will be not printed out

Speaking about Python scripts, this output is processed by
`parse_command()`, for 1) you would need to test if the item is a key
in directory; for 2) you would need to test if the value is non-empty.
Anyway this behaviour should be consistent across the all modules.
Personally I would incline to choose option 1).

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

3

Hamish wrote:

I am not so sure about r49166. I don't really
mind about adding map type and res to -g to make
it more like 'g.region -g', but wonder if things
like vertical datum and data units should only
export if they actually exist.

Note -t can't be included, as if the title contains chars like () then
eval `r.info -g` will fail.

(for `r.info -t` I've always had to use
`cut -f2- -d=` instead of eval)

hmm, vdatum= and units= are also free-form text
fields and so can not be part of 'eval `r.info -g`'
either. (which must be supported for end-users,
even if shell scripts are not used by the official
release)

also, for core.py's parse_key_val(), if a free-
form string is parsed, and the string contains '=',
then "v = kv[1]" will chop it off prematurely.
(this is a bug in all branches)

probably
def parse_key_val(s, sep = '=', dflt = None, val_type = None, vsep = None)

needs to have another argument added like
..., to_eol = False):

to allow an effect like .split('=')[1:end]
instead of just the kv[1] element.

Hamish