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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev