On Wed, Feb 19, 2014 at 3:56 PM, Glynn Clements <[email protected]> wrote: > > 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).
Typing "exit" invokes some clean up which I do not want to miss. We are using something similar to your suggested new mechanism on a high performance cluster, but struggle with the cleaning up. "We" means long-term GRASS users and developers. Leaving the cleaning up of any temp files to the user is IMHO very user-unfriendly. > .py is supposed to be associated with a Python interpreter, and > the stock Python installer will do that. .py is not supposed to be associated with a Python interpreter that is installed system-wide because this assumes some kind of package manager as available on Linux/BSD/Unix. MS Windows does not have a package manager. Any software installed on Windows must include any script interpreters and enforce the use of these for the respective scripts. The fundamental assumption of MS Windows software installers is that no other software installer will interfere with its installation. This assumption is violated as soon as a software installer invokes another software installer. This means that the WinGRASS software installer should not invoke or require a Python installation on MS Windows. Instead of battling the MS Windows software management system, I would rather follow the approach of other projects that have been running successfully on MS Windows with their embedded python interpreter for a couple of years. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
