[GRASS-dev] r44766: v.what: cosmetics in output (empty lines)

GRASS GRASS developer
1

Hi,

sorry but r44766: "v.what: cosmetics in output (empty lines)"
will have to be reverted.

anything written to stdout is fair game for people to parse with
scripts, and rightly or wrongly people will be parsing using
the default output instead of -g, and using brittle ways like
`head` and `tail` instead of grep, and these cosmetic changes
will definitely will break their personal scripts.

the same goes for r.info, v.info form output, etc.
(in GRASS 6.x only of course).

thanks,
Hamish

ps- fair warning that after 6.4.1 I'm going to be even more stubborn about 6.4.x being for bug fixes only..

2

Hamish wrote:

ps- fair warning that after 6.4.1 I'm going to be even more
stubborn about 6.4.x being for bug fixes only..

(ie command modules used by scripts, the GUI is more flexible as
long as it doesn't ruin existing documentation too badly)

3

Hi,

2010/12/29 Hamish <hamish_b@yahoo.com>:

sorry but r44766: "v.what: cosmetics in output (empty lines)"
will have to be reverted.

well, this commit just plays with empty lines in logical manner

$ v.what map=archsites east_north=595743,4925281 dist=250 --q -a

before
"""

East: 595743
North: 4925281

Map: archsites
Mapset: PERMANENT
Type: Point
Id: 8
Layer: 1
Category: 8

Driver: dbf
Database: /home/martin/grassdata/spearfish60/PERMANENT/dbf/
Table: archsites
Key column: cat
cat : 8
str1 : No Name
"""

after

"""
East: 595743
North: 4925281

Map: archsites
Mapset: PERMANENT
Type: Point
Id: 8
Layer: 1
Category: 8

Driver: dbf
Database: /home/martin/grassdata/spearfish60/PERMANENT/dbf/
Table: archsites
Key column: cat
cat : 8
str1 : No Name
"""

$ v.what map=archsites east_north=595743,4925281 dist=250 --q -ag

before

"""
East=595743
North=4925281
Map=archsites
Mapset=PERMANENT
Type=Point

Id=8
Layer=1
Category=8
Driver=dbf
Database=/home/martin/grassdata/spearfish60/PERMANENT/dbf/
Table=archsites
Key_column=cat
cat=8
str1=No_Name
"""

after

"""
East=595743
North=4925281

Map=archsites
Mapset=PERMANENT
Type=Point
Id=8
Layer=1
Category=8
Driver=dbf
Database=/home/martin/grassdata/spearfish60/PERMANENT/dbf/
Table=archsites
Key_column=cat
cat=8
str1=No_Name
"""

If you really thinking that it can break existing scripts, I have
problem to revert it. Anyway I can hardly imagine that it can break
goodly written script;-)

Martin

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

4

Hamish wrote:

anything written to stdout is fair game for people to parse with
scripts, and rightly or wrongly people will be parsing using
the default output instead of -g, and using brittle ways like
`head` and `tail` instead of grep, and these cosmetic changes
will definitely will break their personal scripts.

I disagree. If a module has a -g flag, scripts which parse the
"human readable" format are already broken. E.g. much of the output
from v.what (without the -g flag) is localised, so simply changing
the message catalogues (or LC_MESSAGES) will break the script.

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

5

Martin:

well, this commit just plays with empty lines in logical manner

$ v.what map=archsites east_north=595743,4925281 dist=250 --q -a

before
"""

East: 595743
North: 4925281

...

oh ok, I read the diff as removing all of the section separating
newlines; off by one is easier to handle.

I wonder if that leading newline is there in case multipile input= maps or
multiple east_north= coords are given in the single command?

for -g flag extra newlines probably shouldn't be there at all.

If you really thinking that it can break existing scripts, I have
problem to revert it. Anyway I can hardly imagine that it can break
goodly written script;-)

probably I'm just overreacting. My way of thinking like a new user is
to apply the mistakes I used to make.. head | tail to chop out line number
$x was one of those scripting mistakes... unindented consequences
of seemingly harmless changes was another..

Glynn:

I disagree. If a module has a -g flag, scripts which parse the
"human readable" format are already broken.

BUT the -g flag will be new for the 6.4.1 release, so people running
current/earlier versions didn't have the choice.

E.g. much of the output from v.what (without the -g flag) is localised,
so simply changing the message catalogues (or LC_MESSAGES) will break
the script.

I hadn't considered that, but you are absolutely correct.

anyway no big deal, I drop my objection to the commit, but the two
multiple=yes options should be tested if the new version is kept, maybe
it needs to write the newline at the start of the loop only for
any >first iteration.

Hamish

6

Hamish wrote:

I wonder if that leading newline is there in case multipile input= maps or
multiple east_north= coords are given in the single command?

No. The code just switches from having a newline at the end of each
string to having one at the beginning for no apparent reason. It's in
entirely the wrong place to have been there for a reason (i.e. it's in
the middle of a "block" of related lines).

Glynn:
> I disagree. If a module has a -g flag, scripts which parse the
> "human readable" format are already broken.

BUT the -g flag will be new for the 6.4.1 release, so people running
current/earlier versions didn't have the choice.

Ah; I didn't realise that it was a new addition.

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