[GRASS-dev] Handling of Python scripts on MS Windows
Vaclav Petras
wenzeslaus at gmail.com
Wed Apr 9 06:25:04 PDT 2014
On Wed, Apr 9, 2014 at 2:16 AM, Markus Metz
<markus.metz.giswork at gmail.com>wrote:
> On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements <glynn at gclements.plus.com>
> wrote:
> >
> > Markus Metz wrote:
> >
> >> > All of this goes out the window if you want to provide a command-line
> >> > environment, whether an interactive shell or the ability to execute
> >> > commands via system() or CreateProcess().
> >>
> >> It works in GRASS 6 with shell scripts. I am sure the same mechanism
> >> will work just as well with python scripts.
> >
> > GRASS 6 creates a .bat file for each shell script.
>
> And this .bat file specifies the script interpreter. Looks like a good
> solution to also select the correct Python version.
I'm afraid how will work for user scripts. Typical case will be that user
has some Python, so he or she will try to run from outside if he or she
sets the environment correctly, running of modules (exe or bat) will be OK,
but grass.pygrass and grass.lib might not be OK.
The other typical case (hopefully more common) is when a user writes his or
her own GRASS Python module/script. This does not contain any environment
settings (same as .py in scripts/ and temporal/) because it is intended to
be run inside of GRASS session. However, it will not run because there is
no .bat. Should user create one? Should GUI do some workaround for that
case? But what about Python command line, wxGUI command console and
standard Windows command line?
My point is that nobody was writing shell scripts on Windows but people are
writing Python scripts/modules. So, this new problem to solve.
Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140409/79217525/attachment-0001.html>
More information about the grass-dev
mailing list