python libs shouldn't parse freeform text fields with parse_key_val()
|Reported by:||hamish||Owned by:|
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
= 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
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?
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.