[GRASS-dev] Re: [GRASS GIS] #553: wx and tcltk GUI: changing default GUI returns error

[GRASS GIS]

#553: wx and tcltk GUI: changing default GUI returns error
---------------------------+------------------------------------------------
  Reporter:  hamish        |       Owner:  grass-dev at 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>