[GRASS-dev] d.rast3d not launching on windows

[Hamish]

Anna:
>>> Unable to fetch interface description for command 'd.rast3d.py'.
>>> ...
>>> Details: C:\OSGeo4W_dev\bin\python.exe: can't open file
>>>   'd.rast3d.py': [Errno 2] No such file or directory
>>>
>>> [1] http://trac.osgeo.org/grass/changeset/57218
>>...
>>> os.chdir(...)

Hamish:
>> the "Unable to fetch interface description for command" error is typically
>> because the g.parser script-handling module can not find the script that
>> called it in the system $PATH.
>>
>> (error message happens in lib/python/script/task.py)
>>
>> The os.chdir() solution may work on Windows since "." is usually in
>> %PATH% there, but on Unix "." is typically not in your path.
>>
>> I think it's better remove the os.chdir()s and replace them by adding
>> $GISBASE/etc/gui/scripts/ to the PATH when the wxGUI first starts up.
>>
>> Going into the grass7 wxGUI's Python shell tab, and import os,
>> os.getenv('PATH') shows the last entry as etc/gui/scripts/ already.
>> (tested on linux)    :-/ so that might not be it.

Anna:
> the command is launched with python executable:
>
> .../python.exe d.rast3d.py 
>
> so it seems that it expects the full path to the script and
> therefore chdir before it made it work.
> $GISBASE/etc/gui/scripts/  is already on the PATH.

if etc/gui/scripts/ is already in the PATH why does "cd" make any
difference? perhaps it needs to be in PYTHONPATH instead? as you
describe the reason is the way it is called, using:
  /path/to/python.exe script.py

since script.py is the argument it never goes near $PATH, but maybe
python still checks $PYTHONPATH ?
or if it is just called like:
  /path/to/python.exe /path/to/script.py
then the "cd" wouldn't be needed any more.


note g.parser (at least in 6.x) removes all but the basename from
the original "$0" for the second pass, IIRC.


> So we can keep this solution until someone finds something better.

I'm not really worried about special cases to make d.rast3d work since
it's a private/internal script, but for other regular scripts if a "cd"
is done it's a bug: scripts which write out an output file would no
longer write them to the current directory the script was run from,
the files would either end up in scripts/ or get an error about no
permission to write to scripts/.

In line 540 of trunk/gui/wxpython/core/gcmd.py it seems that bug
exists. (i.e. for: d.polar db.out.ogr i.spectral m.proj r.in.wms
r.out.xyz r.pack v.out.gps v.pack, ...)


thanks,
Hamish