wxGUI doesn't work in Windows
|Reported by:||glynn||Owned by:|
In menuform.py, getInterfaceDescription() attempts to insert the full path to grass-interface.dtd in the --interface-description output, using:
p = re.compile('(grass-interface.dtd)') p.search(cmdout) cmdout = p.sub(globalvar.ETCDIR + r'/grass-interface.dtd', cmdout)
But the first argument to the RegexObject.sub() method is a replacement pattern, not a literal string, meaning that certain backslash sequences have special meaning.
This is problematic if globalvar.ETCDIR contains a recognised backslash sequence, which is quite likely on Windows. In particular, \g is used to insert the contents of a named or numbered group, and ETCDIR will almost certainly contain this sequence as part of "\grass-". This results in the error:
File "C:\msys\1.0\home\glynn\src\grass-7.0\dist.i686-pc-mingw32\etc\gui\wxpython\gui_modules\menuform.py", line 1997, in getInterfaceDescription cmdout = p.sub(globalvar.ETCDIR + r'/grass-interface.dtd', cmdout) File "C:\Program Files\Python26\lib\re.py", line 273, in _subx template = _compile_repl(template, pattern) File "C:\Program Files\Python26\lib\re.py", line 260, in _compile_repl raise error, v # invalid expression sre_constants.error: bad group name
Also, even without the error, the "\1" in "\1.0" would end up being replaced by the first parenthesised group (grass-interface.dtd).
As the pattern is a literal string, I don't see any reason to use regular expression. It may as well just use e.g.:
cmdout.replace('grass-interface.dtd', os.path.join(globalvar.ETCDIR, 'grass-interface.dtd'))
which also fixes the use of the wrong directory separator.
Also, if the DTD is supposed to be specified by a full path, the implementation of --interface-description should be fixed, rather than patching the output afterwards.
Priority set to "blocker" as this can make the wxGUI effectively non-functional. Executing any command will trigger the error if $GISBASE contains the wrong characters (this may be specific to Python 2.6; I can't see any other reason why it wouldn't have been noticed earlier).
Platform set to "MSWindows" (applies to all versions) as backslashes in pathnames are uncommon on other platforms (although technically permitted).
Tested with the latest 7.0, but the code is identical in 6.x.