#553: wx and tcltk GUI: changing default GUI returns error
---------------------------+------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wxgui gis.m
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by glynn):
Replying to [comment:10 cmbarton]:
> Does anyone know how to solve this scripts issue for Windows? I'm happy
to implement something but don't understand how to fix this. It seems to
me that it is something that needs to be done somewhere outside the GUI.
If so, we should probably change the "component" to whatever component is
the right place to fix Windows ability to read these scripts.
The core issue is that Windows decides how to "run" scripts via the
extension, not the shebang. If you want to support the most general case,
all scripts must have an appropriate extension, e.g. .sh for Bourne shell
scripts. Even then, we're dependent upon the file associations being set
correctly (on Unix, we're dependent upon /bin/sh being a Bourne shell, but
that's a much safer assumption).
We can get more limited support either by relying upon MSys or by
implementing similar emulation ourselves (i.e. writing a utility to
identify whether a command is an exe or a script and invoking the
appropriate interpreter).
Either way, g.parser needs to be changed to match.
One option is to back-port the -s switch used by Python scripts, and to
add similar functionality for Bourne-shell scripts (i.e. write out
environment settings in a form that can be "eval"d). But that would
require changing the g.parser boilerplate in existing shell scripts.
Aside from that, when invoking commands via subprocess.Popen, ensure that
you use shell=True on Windows. Without that, it will only work for
binaries (.exe and .com), not for scripts (which includes .bat files).
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/553#comment:11>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
