[GRASS-dev] Handling of Python scripts on MS Windows
Hamish
hamish_b at yahoo.com
Wed Apr 23 19:34:09 PDT 2014
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.
More information about the grass-dev
mailing list