[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter:  hamish        |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  blocker       |   Milestone:  6.4.0                    
 Component:  wxGUI         |     Version:  6.4.0 RCs                
Resolution:                |    Keywords:  wingrass                 
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------
Comment (by hamish):

 Replying to [comment:4 hamish]:
 > > Running a python script from the DOS prompt it fails though
 > > because it doesn't know what program to associate .PY with.
 > >
 > > what is apparently missing is:
  {{{
   set .py="%GISBASE%/extrabin\python.exe"
  }}}

 Replying to [comment:5 glynn]:
 > I've never seen this syntax.

 Nevermind, further down in the thread that suggested that is the small
 caveat that belongs to some NT4 3rd party replacement for cmd.exe (gee,
 thanks for the tip then).


 > The normal way to associate applications with extensions is via
 > assoc and ftype (but AFAICT, those change the system-wide
 > settings, which may have be overriden by per-user settings).
 ...
 > Note that this will change the registry keys, which will
 > permanently affect the handling of all .py files on the system,
 > not just those which are part of GRASS, and not just for the
 > lifetime of the command prompt.

 ... leading to more like bug #570


 So lacking a way to locally set the extension association, our only choice
 is to ditch PATHEXT and use wrapper scripts which ensure that the
 GRASS_PYTHON enviro var. is respected. Workable from the GUI, but running
 GRASS python modules from the command line will be at the mercy of
 whatever version of python the user has installed. (a python wrapper
 script which launched another (but this time known) version of python to
 run a script is probably asking for trouble)


 > Bundling a "local" copy of Python (with a matching copy of
 > wxPython) may be a reasonable approach for getting the wxGUI
 > working,

 (and even with doing that we still aren't close to mastering it)

 > but any standalone scripts will use the system Python
 > installation, and GRASS shouldn't be interfering with that

 is there anything left which won't use the python set by the GRASS_PYTHON
 enviro variable? (from #570 apparently the answer is yes)

 > (applications which automatically "steal" file associations are
 > generally considered to be malware).

 ... Windows would seem to have a lot of malware then ... at least the DLL
 version clobbering in favour of the last-to-run installer is less
 prevalent these days.


 Hamish

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