[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