[GRASS-dev] [GRASS GIS] #1491: python libs shouldn't parse freeform text fields with parse_key_val()

[GRASS GIS]

#1491: python libs shouldn't parse freeform text fields with parse_key_val()
---------------------+------------------------------------------------------
 Reporter:  hamish   |       Owner:  grass-dev@…              
     Type:  defect   |      Status:  new                      
 Priority:  normal   |   Milestone:  7.0.0                    
Component:  Python   |     Version:  svn-trunk                
 Keywords:  parsing  |    Platform:  All                      
      Cpu:  All      |  
---------------------+------------------------------------------------------
 Hi,

 raster.py and vector.py use core.py's parse_key_val() to evaluate the
 results of r.info and v.info, and report the result of `kv[1]` using `=`
 as the field separator.

 r.info's title, vdatum, and units results, and most of v.info's extended
 metadata results can contain free-from text, which can contain `=` chars.
 And so text containing that will get cut off and only give the result up
 to the first `=`.

 vector_info_topo(v.info -t) looks safe to use it.

 db.py contains one too, using `:` as the fs, it is easy to imagine this
 failing if the database: string is on MS Windows and contains `C:\`, only
 the initial drive letter would get through.

 raster3d.py's one should be ok, I don't spot any free-form text options in
 `r3.info`.

 `g.region -g` in core.py should be safe too.

 `g.findfile` in core.py won't be safe if the file= path contains a `=`.  I
 suspect that's safe on MS Windows but not in UNIX?


 thanks,
 Hamish

 ps- r.info and v.info's -g flags restored to their original "show region"
 meanings in trunk. maybe `r.info -s` (show res) should get merged into -g,
 a bunch of the others could not be eval'd and had to be moved back out.
 after doing that it became obvious that leaving the rest was inconsistent
 and breaking the meaning of what -g has historically been for, so backed
 out as well.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1491>
GRASS GIS <http://grass.osgeo.org>