v.info lacks -g switch

[neteler]

Problem: the absence of the -g flag breaks some scripts which use v.info in a non-English locale. The -t flag is not sufficient. Details:

 http://lists.osgeo.org/pipermail/grass-user/2009-April/049690.html

On Wed, Apr 1, 2009 at 1:52 PM, Glynn Clements wrote:

The problem is that v.info doesn't have an option to produce machine-readable output. The -t switch doesn't cover all of the information which v.info can output. FWIW, v.report has:

COLNAMES="`v.info -c map=$MAP layer=$LAYER | grep -v '^Displaying column type' | ...

But the 'Displaying column type' message is localised. v.report uses LC_ALL=C, which solves the above issue but is a bug in and of itself. The comment says:

# setting environment, so that sort works properly in all languages
LC_ALL=C         # according to 'man sort'

If it's just for sorting, it should be setting LC_CTYPE (but LC_ALL has to be unset, which means that the other LC_* variables have to be set to $LC_ALL first). But every occurence of "sort" in that script uses -n, which shouldn't be affected by locale.

[hamish]

I'm rather confused by this bug report. v.info already has a -g flag which reports the geographic extent in shell script style.

Other shell script style flags have been added as well, indeed Markus has already used the -t flag to solve the l10n error* reported in the original post.

[*] is the real error that reports should not be translated? ISTR that we had decided not to translate r.info et al.'s reports. (Personally I don't have too strong an opinion about that)

Shell scripts which use awk all unset the locale to ensure that decimal places are "." not ","s and can provide a template if needed if scripts are parsing module report output which do not have a shell script flag equivalent.

So what specifically is this bug report actually asking for? A switch that dumps or converts all output in shell script format? ISTR that was tried for g.region and in practice was/is a complete mess + PITA that we (IMO) shouldn't repeat. Compare that to r.info which has lots of flags for specific shell script formatted params, and seems to work well for all our shell script needs.

I suggest closing this bug as "redundant".

Hamish

[glynn]

Replying to hamish:

I'm rather confused by this bug report. v.info already has a -g flag which reports the geographic extent in shell script style.

Okay; the title is inaccurate. Something like "v.info lacks machine-readable output for some fields" would be more accurate.

[*] is the real error that reports should not be translated? ISTR that we had decided not to translate r.info et al.'s reports. (Personally I don't have too strong an opinion about that)

The real error is that some of the information which can be obtained from v.info is only available as human-readable text. Compare with r.info -rgstmpud which (AFAICT) makes all output available in machine readable formats.

So what specifically is this bug report actually asking for? A switch that dumps or converts all output in shell script format?

Yes.

ISTR that was tried for g.region and in practice was/is a complete mess + PITA that we (IMO) shouldn't repeat.

The problem with g.region was that maintaining "bug compatibility" with all of its existing quirks was a nightmare. Some options simply added information to the output while others replaced other fields or modified their behaviour.

Compare that to r.info which has lots of flags for specific shell script formatted params, and seems to work well for all our shell script needs.

Having many flags would be acceptable, so long as there is no problem which is (sort of) solvable by grepping the human-readable output but which lacks a more robust solution.

More generally, any script which greps human-readable output indicates that the underlying module needs an option for machine-readable output. Forcing LC_MESSAGES=C is a hack, as it will cause any error messages to be displayed to the user in English.

[hamish]

closing this bug, the specific problem that raised it has been AFAIR resolved with some fixes to the shell scripts in question. if anyone has need for a new specific shell script style output option please open a new bug for that. It is unreasonable to act on vague requests to "export everything".

Hamish