A short comment about GRASS as a monolithic application or not: On every OS where I tested various GRASS versions (I tested on various Linux distros, on various FreeBSD versions, on various NetBSD versions, on 2 Solaris versions and helped give IBM AIX a try) and on all these OS's I started GRASS with the grassxy command, usually not bothering about a GUI but using the command line exclusively. All I propose is that GRASS on Windows behaves the same, and that all GRASS commands work, no matter if they are real executables or some scripts.
I hope we can agree on that. I think this discussion has gone astray. This is about how GRASS scripts are executed on Windows, not whether GRASS on WIndows should behave any different than on other OS's. There seems to be agreement that changing an existing Python file association is not a good idea. An existing Python file association on MS Windows can change or disappear any time, and a GRASS installation will not be notified about this change. Therefore it is IMHO not a good idea to rely on a system-wide Python file association on MS Windows, and therefore I propose to use the embedded Python version already coming for some years with the WinGRASS installer. With .bat file wrappers, you would not even need to set a particular python environment, it would just work. Just as on any other OS, all GRASS commands would be available after running the grassxy command. If, as Glynn suggests, running grassxy should not be required, instead the GRASS environment is set permanently at login time, there would be no difference, except that you don't need to bother about funny (non-)existing Python file associations on MS Windows. I suspect the whole discussion boils down to the question whether we can rely on GRASS-compatible Python file associations on MS Windows or not. I say, we can not. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
