testing 6.5svn nightly wingrass installer r55947-561 (-562 is the broken
one).
if you start the GRASS Command line (cmd.exe) and try to bring up a module
GUI or the wxGUI with g.gui you get an error that it can't find
grass.script and friends.
{{{
g.version --ui
...
import grass.script as grass
ImportError: No module named grass.script
}}}
`g.gui tcltk` is working from in the dos box, as is starting the wxGUI
with and without MSYS.
After setting 'g.gui -u tcltk' to set `GRASS_GUI: tcltk` in g.gisenv, the
per-module auto-gen GUIs still try to find the python grass.script and
fails as well. :-/
... %PYTHONHOME% is set but %PYTHONPATH% is empty.
Slightly unrelated, but I'd also note that running 'python' from the
GRASS+MSYS prompt just freezes the window, you need to click the window's
"X" and abandon the session. I notice that grass65svn.sh contains several
path variables (incl. $PYTHONHOME) which are using C:\... paths instead of
g.dirsep'd /c/... versions.
Replying to [comment:2 hamish]:
> ... %PYTHONHOME% is set but %PYTHONPATH% is empty.
try for a fix for PYTHONPATH in devbr6 r55955. please test.
> Slightly unrelated, but I'd also note that running 'python' from the
GRASS+MSYS
> prompt just freezes the window, you need to click the window's "X" and
abandon
> the session. I notice that grass65svn.sh contains several path variables
(incl.
> $PYTHONHOME) which are using C:\... paths instead of g.dirsep'd /c/...
versions.
if it helps, small path fixer function added to init.sh, copied here:
{{{
dos2unix_path()
{
echo "$1" | sed -e 's|^\([A-Za-z]\):|/\1|' -e 's|\\|/|g'
}
}}}
ok, seems fixed in devbr6 with r55960. a couple outstanding issues-
- init.bat adds %GISBASE%/etc/wpython to %PYTHONPATH%, but nothing else
seems to, and a g.gui wxGUI started from the cmd.exe Command Line seems to
work fine with wxNviz, wxVdigit, etc.. Going to the python console tab in
the layer manager and doing
{{{
import os
print os.getenv('PYTHONPATH')
}}}
shows that the GUI itself isn't adding the wxpython dir to $PYTHONPATH (at
least the one that python console sees; not sure if it is shared with the
gui process). so is having etc/wxpython in PYTHONPATH not needed at all?
- even with 'g.gisenv set="GRASS_GUI=tcltk"' the module GUIs started from
the cmd.exe get wxpython GUIs. When running from the msys terminal those
get tcltk ones. not a big problem, but why?
- ok, I see now, there's an enviro var %GRASS_GUI%=text also set, and
parser.c looks for an enviro var setting before the g.gisenv GRASS_GUI
setting. "text" is ignored, so the fallback is to wxpython. Perhaps
GRASS_GUI=text should call the old text "GRASS_UI_TERM" based parser
instead?
- after setting the %GRASS_GUI% enviro var to tcltk, I get an error in
the cmd.exe window:
{{{
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
}}}
perhaps this line in parser.c's G_gui_tcltk() needs extra quoting around
$env(GISBASE)?
{{{
fprintf(fp, "source $env(GISBASE)/etc/gui.tcl\n");
}}}
Replying to [comment:4 hamish]:
> perhaps this line in parser.c's G_gui_tcltk() needs extra quoting around
$env(GISBASE)?
> {{{
> fprintf(fp, "source $env(GISBASE)/etc/gui.tcl\n");
> }}}
I don't think so. Unlike bash, Tcl doesn't re-parse the result of
substitutions.
Also the "... is not recognized as an internal or external command,
operable program or batch file." error is generated by Windows in response
to an attempt to execute a command; it wouldn't be generated by Tcl in
response to a "source" command.
It could be generated by the popen() call in G_gui_tcltk() (although the
quoting looks okay), or by a Tcl "exec" command.
Replying to [comment:5 glynn]:
> I don't think so. Unlike bash, Tcl doesn't re-parse the result of
substitutions.
ok
> Also the "... is not recognized as an internal or external command,
> operable program or batch file." error is generated by Windows in
response
> to an attempt to execute a command; it wouldn't be generated by Tcl in
response
> to a "source" command.
>
> It could be generated by the popen() call in G_gui_tcltk() (although the
quoting
> looks okay), or by a Tcl "exec" command.
I tried on linux with putting a space in $GISBASE, but it worked fine
there. G_gui_tcltk() has a different #ifdef path for WIN32; I'm not sure
if the tcltk code does too; I didn't see anything obvious.
If I "`set GRASS_DEBUG_GUI=true`" to get the different tee+pipe behaviour
from G_gui_tcltk(), it works and the module gui opens.