#693: wxGUI menus: i.ortho.photo locks up GUI
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords: i.ortho.photo
Platform: All | Cpu: x86-64
---------------------+------------------------------------------------------
Comment (by glynn):
Replying to [comment:7 cmbarton]:
> But it might be better if there is an environmental variable GRASS_XTERM
that is set to a platform specific value than a script that tries to
figure it out.
There is such a variable; that's the whole point of grass-xterm-wrapper.
It is essentially just:
{{{
exec "$GRASS_XTERM" "$@"
}}}
except that it also tries to autodetect a suitable program if GRASS_XTERM
isn't set.
However, wxGUI's GMFrame.OnXTerm() method involves rather more than simply
running a command in a terminal.
First, it invokes the command via grass-run.{sh,bat}. The primary
rationale for that script is to restore LD_LIBRARY_PATH in case the loader
resets it due to xterm being setuid/setgid. But in typical form, the
grass-run.sh script has been "enhanced" with other functionality. The
grass-run.src file '''should''' be nothing more than:
{{{
LD_LIBRARY_PATH_VAR=$GRASS_LD_LIBRARY_PATH
export LD_LIBRARY_PATH_VAR
exec "$@"
}}}
Everything else is gratuitous, and possibly harmful.
Second, GMFrame.OnXTerm() starts (and selects) another XDRIVER monitor (I
don't see where (or even if) it stops this monitor, and I'm fairly sure
that it doesn't re-select the previous monitor).
Ah. This is where it goes beserk. It constructs the command as:
{{{
command = shlex.split(str(command))
...
cmdlist = [xtermwrapper, '-e "%s"' % grassrun, command]
}}}
which will result in cmdlist looking something like:
{{{
['/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/etc/grass-xterm-
wrapper',
'-e "/usr/local/src/grass/svn/dist.i686-pc-linux-gnu/etc/grass-
run.sh"',['i.ortho.photo']]
}}}
How many things are wrong with this? Apart from the last argument being a
Python list (which gcmd.Command() '''might''' handle), the -e switch is
merged into the same argument as its value. And its value is quoted,
whereas xterm's -e switch signifies that all remaining arguments are to be
treated as the command and its arguments (unlike e.g. /bin/sh's -c switch,
which expects a single argument).
Does GMFrame.OnXTerm() work at all for anything on any platform? I'm hard
pressed to see how it can, unless gcmd.Command() is doing a '''lot''' of
scary magic on the mess it gets passed.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/693#comment:11>
GRASS GIS <http://grass.osgeo.org>