[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 cmbarton):

 Replying to [comment:11 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).

 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? Or does g.parser still need to be changed as you
 mention below?

 >
 > 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.

 This is a fairly large hassle. However, I think that we really need to do
 this if it makes scripts runable in WinGRASS.

 >
 > 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?

 Michael

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/553#comment:12>
GRASS GIS <http://grass.osgeo.org>