Glynn:
>>> Batch files are a better solution, as they don't affect anything else, >>> and it's a simple matter to either delete them or modify PATH to >>> ignore them, and use the Python scripts directly. MMetz: >> Sounds good. Martin: > I am not sure, what about user scripts? a new g.batwrap helper program (written in C) to create a .bat wrapper and put it in the same dir as the target python script? > It's easier to check if the file is a python script and if so than to > force to use bundled version of Python. This seems to be a better > workarround than using bat files. what would do the checking, g.parser.exe? remember that any solution also needs to work 100% from the command line too, so having the GUI's pseudo-command line taking care of those things is not a real solution. Even if a user never uses the command line on Windows, they will at some point run into the old script-called-from-another-script problem. ? regards, Hamish ps- this part of g.extension.py is fundamentally broken: line = line.replace("%GISBASE%", "%GRASS_ADDON_PATH%") # options['prefix']) It's equivalent to trying to do s+/usr/bin/+$PATH/+ and then run "$PATH/g.module". The approach used in g.extension.sh is to split $GRASS_ADDON_PATH and use the first dir in the list as "$GRASS_ADDON_PATH1", and then use that dir as the first-choice userland exedir destination. _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev