On Tue, Feb 11, 2014 at 5:39 PM, Glynn Clements <[email protected]> wrote: > > Markus Metz wrote: > >> This is the fundamental difference and the reason why using a >> system-wide Python can only cause trouble on Windows. On Windows, a >> software package typically includes everything it needs to run, > > On Windows, a software package is typically a monolithic executable > with no ability to be controlled by other programs (including the > command interpreter).
Windows users expect software packages typical for Windows. GRASS is the contrary of a monolithic executable, and should stay so for various reasons. However, on Windows we need to fake a monolithic system, because that is how Windows works, if we like it or not. Having a command interpreter with a GRASS session running on Windows is IMHO something for power users. On Linux/BSD/Unix, a command interpreter is started first, then GRASS. On Windows it is the other way around. The environment established by starting GRASS is (should be) only valid for the current GRASS session. > >> > 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. > >> 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 > >> 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. 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. I don't want to defend the way typical Windows software packages work, but I think it is not worth the trouble to force Unix principles onto Windows. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
