Glynn Clements wrote > Markus Metz wrote: > >> >> Other projects such as gimp or libreoffice are AFAICT reasonably >> >> bundled with Python, without a Python installer. >> > >> > They aren't attempting to support Python scripts as stand-alone >> > programs (i.e. something which can be run from the command prompt, >> > batch files, etc). >> >> GRASS scripts, just like GRASS C modules, only run as stand-alone >> programs if the GRASS environment is set properly and if a valid GRASS >> session has been established. > > This is a matter of creating a file and setting some environment > variables. > > It's also not that specific to GRASS. As the Windows filesystem layout > groups files by origin (i.e. .../Program Files/ > <vendor> > / > <package> > ) > rather than by function (.../bin, .../lib, etc), it's fairly typical > to have to at least modify PATH for anything which is meant to be used > from the command line. > > But you can't configure interpreters on a per-process basis on Windows. > You can only do it on Unix because we use the "#!/usr/bin/env python" > hack (which was originally invented to deal with Python being either > in /usr/bin or /usr/local/bin). > >> Thus, GRASS modules do not run from any >> command prompt, neither from the native Windows command prompt nor >> from a *NIX shell, without setting the GRASS environment first. Real >> stand-alone programs are for example the GDAL utilities, but not GRASS >> modules. > > It's fairly trivial to set a valid GRASS environment globally, so that > commands are usable in any shell. That's how I've had it on Linux > since roughly forever; I don't run the grass70 script unless I'm > testing it. > > FWIW, I want to make that the default mode of operation. > > I.e. on Unix, set the environment variables in /etc/profile.d/grass7 > or whatever a given distribution uses, so that you only need to > explicitly start GRASS sessions if you want multiple, independent > sessions. > > On Windows, GISBASE should be set from the registry (with the > environment variables allowing this to be overriden, mainly as a > developer feature). > >> > A compiled program which "embeds" Python (links against the Python >> > DSO/DLL) to use Python for "internal" scripting is a much simpler >> > case. And much less useful. >> >> Why much less useful? As far as GRASS modules are concerned, users >> should not be bothered and should not care if a GRASS module is a C >> module or a shell script or a python script. First of all, a GRASS >> module must behave like a GRASS module, independent of the language in >> which it is written. > > This is my entire point. But that cannot be achieved if you're relying > upon hard-coded special treatment for Python scripts. If Python > scripts cannot simply be executed (via system() or subprocess.Popen() > or whatever) in the same manner as executables or other scripts, the > user will have to be bothered with whether something is an executable > or a Python script. > > Attempting to side-step the system's execution mechanism will *always* > be an incomplete solution. > > -- > Glynn Clements
please keep in mind that we are providing WinGRASS in different ways (most used as WinGRASS-standalone and OSGeo4W-WinGRASS; others are QGIS, gvSIGce, etc) for our users aka community. IMHO it would be really a pity to lo lose any of those for our community. thanks ----- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5102228.html Sent from the Grass - Dev mailing list archive at Nabble.com. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev