#544: v.info lacks -g switch
---------------------+------------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Keywords: | Platform: All
Cpu: All |
---------------------+------------------------------------------------------
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:
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:
> 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.
#544: v.info lacks -g switch
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by 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.
#544: v.info lacks -g switch
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: svn-develbranch6
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by glynn):
Replying to [comment:1 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.
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".