#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:12 cmbarton]:
> > 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).
>
> Thanks Glynn,
>
> So does this mean that if the extension *.py is set to a python.exe
(such as the one in $GISBASE/extrabin), a python script will actually run
from the GRASS command line?
You would be able to run it from the Windows command prompt, or via
system(), or via subprocess.call(..., shell=True). MSys might have its own
ideas about running it based upon the shebang.
> Or does g.parser still need to be changed as you mention below?
g.parser needs to be changed to work with non-Bourne-shell scripts on
Windows. Right now, it always re-invokes the script using $GRASS_SH, which
won't work for anything other than shell scripts. Either:
1. g.parser can be made to execute the script via some mechanism which
pays attention to the type of the script (e.g. "sh -c ..." or "cmd /c
..."), or
2. both g.parser and the scripts can be re-written to avoid the need for
re-invocation, as is done for Python scripts in 7.0.
!#2 is more work, but is less susceptible to problems (incorrect file
associations, g.parser not finding the script, MSys getting in the way).
> > 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.
>
> This is a fairly large hassle. However, I think that we really need to
do this if it makes scripts runable in WinGRASS.
It isn't strictly necessary. It is possible to make g.parser behave like
it does on Unix, but it means relying upon either Windows or MSys
execution semantics.
Relying upon Windows execution semantics means that scripts must have the
correct extensions, the file associations must be set correctly (and GRASS
can't have the final say in this), and how MSys deals with this is MSys'
problem.
Relying upon MSys' execution semantics means that other parts of the
system (e.g. wxGUI, g.parser, G_parser()) will have to explicitly cater to
MSys (e.g. invoking commands via "$GRASS_SH -c ..." to ensure that MSys
gets involved), and making scripts work transparently from the Windows
command prompt would require .bat wrappers.
Bottom line: do you want "GRASS for Windows" or "GRASS for MSys"? There's
a degree of mutual exclusion here.
> > 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).
>
> But this only applies to scripts called from the GUI, right?
This applies to running scripts from within Python, although this is one
instance of a wider principle.
On Unix, script execution is supported by the execve() system call, which
is the only way to execute a program; all higher-level functions (the
other exec* functions plus system(), popen() etc) go through here.
On Windows, the low-level functions (!CreateProcess() and the _spawn*
family) only work with executables (.exe, .com); running anything else
(i.e. scripts, including .bat files) requires that the command is passed
via !ShellExecute() or "cmd /c <command>" (I have no idea how these two
approaches relate to each other, beyond the fact that both are affected by
the file associations).
IOW, in order for scripts to be treated on a par with binary executables,
the shell must be involved. If some lower-level interface is used,
commands which refer to executables will work on all platforms, scripts
will work on Unix, but scripts won't work on Windows.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/553#comment:13>
GRASS GIS <http://grass.osgeo.org>