[GRASS-dev] [GRASS GIS] #2150: Cannot call Python scripts from Python on MS Windows
GRASS GIS
trac at osgeo.org
Sat Oct 25 15:27:24 PDT 2014
#2150: Cannot call Python scripts from Python on MS Windows
-------------------------------------------+--------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Python | Version: svn-releasebranch64
Keywords: packaging, MAXREPEAT, scripts | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------------------------+--------------------------------
Comment(by glynn):
Replying to [comment:26 wenzeslaus]:
> > Why does forms.py need the Python script (rather than the batch file)
in the path?
>
> Without really checking it now, I think it is because of #2133 (g.parser
does call the form.py with full path).
Okay; the actual issue there is that:
1. The parser doesn't include the path. It doesn't actually know the path,
just the name passed to G_set_program_name() (typically by G_gisinit()).
2. It includes the extension, which for a script will be ".py" rather than
".bat".
I note that G_set_program_name() removes any ".exe" suffix. On Windows, it
should probably remove ".py" or also (on Unix, scripts are installed
without the .py suffix). Or perhaps g.parser should do this. Or even
forms.py for that matter.
Actually, this might be a good time to re-consider whether the forms.py
behaviour of re-executing the script with --interface-description is wise,
or whether it should work the same way as the Tcl/Tk version, i.e. have it
fed the description via stdin. OTOH, it's going to have to invoke the
script eventually, so may be this doesn't really matter.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2150#comment:27>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list