[GRASS-dev] Re: [GRASS GIS] #544: v.info lacks -g switch

[GRASS GIS]

#544: v.info lacks -g switch
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev at 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.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/544#comment:2>
GRASS GIS <http://grass.osgeo.org>