On Wed, Apr 9, 2014 at 2:16 AM, Markus Metz <[email protected]>wrote:
> On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements <[email protected]> > 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
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
