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

Hi,

I get this error when launching d.rast3d from layer manager toolbar on Windows.
I fixed it in r57218 [1] but it I was wondering if there is some better solution?

Thanks, Anna

Traceback (most recent call last):
File “C:\OSGeo4W_dev\apps\grass\grass-7.0.svn\etc\gui\wxpy
thon\lmgr\frame.py”, line 1805, in OnAddRaster3D

self.GetLayerTree().AddLayer(‘3d-raster’)
File “C:\OSGeo4W_dev\apps\grass\grass-7.0.svn\etc\gui\wxpy
thon\lmgr\layertree.py”, line 1018, in AddLayer

self.PropertiesDialog(layer, show = True)
File “C:\OSGeo4W_dev\apps\grass\grass-7.0.svn\etc\gui\wxpy
thon\lmgr\layertree.py”, line 1092, in PropertiesDialog

completed = (self.GetOptData,layer,params))
File “C:\OSGeo4W_dev\apps\grass\grass-7.0.svn\etc\gui\wxpy
thon\gui_core\forms.py”, line 2208, in ParseCommand

raise gcmd.GException(e.value)
core.gcmd
.
GException
:
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

Anna wrote:

I get this error when launching d.rast3d from layer manager
toolbar on Windows.
I fixed it in r57218 [1] but it I was wondering if there is
some better solution?

...

Traceback (most recent call last):

...

Unable to fetch interface description for command 'd.rast3d.py'.

...

[1] http://trac.osgeo.org/grass/changeset/57218

...

os.chdir(...)

Hi,

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.

On linux the script is installed as "d.rast3d" without the .py, I guess
it keeps the .py extension on Windows? perhaps check how the script is called: is e.g. 'd.rast3d.py' requested but 'd.rast3d' found?

Maybe etc/gui/scripts/ needs to be added to PYTHONPATH with

wxscripts = os.path.join(os.getenv('GISBASE'), 'etc', 'gui', 'scripts')
if wxbase not in sys.path:
sys.path.append(wxbase)

?
(probably won't help, but worth a try)

Hamish

Hi,

···

On Thu, Jul 18, 2013 at 11:30 PM, Hamish <hamish_b@yahoo.com> wrote:

Anna wrote:

I get this error when launching d.rast3d from layer manager
toolbar on Windows.
I fixed it in r57218 [1] but it I was wondering if there is
some better solution?

Traceback (most recent call last):

Unable to fetch interface description for command ‘d.rast3d.py’.

[1] http://trac.osgeo.org/grass/changeset/57218

os.chdir(…)

Hi,

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.

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.

On linux the script is installed as “d.rast3d” without the .py, I guess
it keeps the .py extension on Windows? perhaps check how the script is called: is e.g. ‘d.rast3d.py’ requested but ‘d.rast3d’ found?

there should be d.rast3d.py which is really there so that’s not the problem.

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

Thanks,
Anna

Maybe etc/gui/scripts/ needs to be added to PYTHONPATH with

wxscripts = os.path.join(os.getenv(‘GISBASE’), ‘etc’, ‘gui’, ‘scripts’)
if wxbase not in sys.path:
sys.path.append(wxbase)

?
(probably won’t help, but worth a try)

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