[GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Metz wrote:

> >> > 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.
> >>
> >> At the very least, GRASS needs to clean up temporary files on exit.
> >
> > Temporary files need to be cleaned up periodically. The term "on exit"
> > doesn't make sense for something which doesn't start or stop.
> 
> I thought that is the way GRASS operates currently: a process is
> started and stopped when the user types "exit". At least I do that on
> Linux when calling grass64 or grass70.

And I'm suggesting eliminating that mechanism because it's
inconvenient and unnecessary (at one point, the only way to change
mapsets was to exit the current session and start a new one, but that
hasn't been the case for a long while).

> >> We use hard-coded special treatment for shell scripts and still they
> >> behave like a GRASS module.
> >
> > Where?
> 
> We create .bat wrappers for shell scripts here:
> https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/include/Make/Script.make#L15

Ah, that.

Shell scripts are somewhat abnormal, largely because MSys (and
similar) try to emulate aspects of Unix beyond the shell itself. But
the main reason we have to do that is that MSys itself doesn't
associate its sh.exe with the .sh extension; it assumes that shell
scripts will always be started from within the shell, which has its
own execution mechanism which recognises scripts and uses the #! line.

> >> I don't see how users are bothered whether
> >> a module is an executable or a shell script. Internally, GRASS can
> >> always use system() or subprocess.Popen() for executables and .bat
> >> files, but not for shell or Python scripts, Therefore we need
> >> hard-coded special treatment for shell and Python scripts in order to
> >> make sure that the correct interpreter is used.
> >
> > IIRC, .bat files were used because there were issues with associating
> > .sh with MSys' shell (one of them being that MSys itself doesn't do
> > that, so we'd effectively be forced to make global changes to
> > something which doesn't "belong" to GRASS).
> 
> Msys is not a Windows shell script interpreter. IIUC, msys provides a
> minimal, isolated system environment which needs to be started
> explicitly.

Not really. Although setting PATH is even more important than with
other command-line programs, because the shell itself doesn't provide
most of the facilities found in other programming languages, relying
upon external commands for all but the most basic operations; e.g. 
"expr" for arithmetic operation ("test" aka "[" is only built-in for
efficiency; historically, it was external command, and coreutils still
provides it).

> Just as there were issues with associating .sh with MSys' shell, there
> are issues when .py files are associated with the system's Python.
> IMHO, any attempt of GRASS to associate .sh files or .py files on
> Windows with a particular interpreter is doomed to fail. WinGRASS
> includes all the needed interpreters and should use them.

WinGRASS can't make the OS use them other than by ensuring that the
extension is registered.

Shell scripts calling shell scripts works (sort of) because the shell
deliberately emulates the Unix #! mechanism. Although it still falls
down in the case of a script calling an EXE which tries to execute a
script directly.

And with .sh, we had no real choice. MSys doesn't even try to
associate it, and GRASS shouldn't be overriding that.

But .py is supposed to be associated with a Python interpreter, and
the stock Python installer will do that.

I don't particularly like working around bugs (which is what
"bundling" Python tries to do), but I'll do it ... except when the
workaround ends up breaking systems which are actually configured
correctly and/or imposing a maintenance burden on the system as a
whole (and "bundling" Python ends up doing both of those).

-- 
Glynn Clements <glynn at gclements.plus.com>