[GRASS-dev] g.region print flags combination

Glynn Clements glynn at gclements.plus.com
Fri Jan 5 07:55:02 EST 2007


Martin Landa wrote:

> > "g.region -g" works OK now, but it prints a WARNING message on the top.
> > It also prints few extra lines, compared to before, namely:
> >
> > projection=1
> > zone=34
> > datum=wgs84
> > ellipsoid=wgs84
> >
> > Your WARNING message is correct and desired, as well as the extra info
> >  is usefull, but those several additional lines might brake some user's
> > scripts.
> 
> So should I disable this warning, right?

Maybe.

If the intention is that use of -g alone will cease to work at some
point, the warning should be kept.

If it is kept, gis.m should be modified to handle it; has that been
done already? Even if this specific warning is removed, gis.m should
always allow for warnings simply for robustness.

Personally, I don't see a problem with having -g alone remaining
equivalent to -pg permanently, i.e. if -g is used with no other
"print" switches, then -p is enabled automatically.

> I think the additional lines would not break any scripts, which parse
> `g.region -g` output in a reasonable way (eval, awk) (?).

Agreed, but that doesn't help scripts which parse the output in an
*unreasonable* way ;)

Where the g.region documentation specifies the output produced by a
switch or combination of switches, it should explicitly state that the
output will include specific fields, but that the order is unspecified
and that other fields may also be present.

IOW, anything which parses the output of g.region should, regardless
of which output format is used:

1. identify fields by their "keys" rather than by their relative
position (i.e. line number) in the output, and

2. silently ignore any unrecognised fields.

IMHO, scripts which don't comply with the above should be considered
"already broken"; changes to g.region need not accomodate them.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list