wingrass: Command Line can't find grass.python libs

[hamish]

Hi,

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. :-/

thanks, Hamish

[hamish]

also, script-called-from-within-a-script from the cmd.exe Command Line fails. but the interior script can still be called from the command line.

example: v.in.lines which calls v.in.mapgen

C:/.../v.in.lines: line 126: v.in.mapgen: command not found

Hamish

[hamish]

... %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.

Hamish

[hamish]

Replying to 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'
}

Hamish

[hamish]

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");

Hamish

[glynn]

Replying to 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.

[hamish]

Replying to 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.

Hamish

[hamish]

worst of the breakage is fixed; the remaining two issues are not critical; downgrading priority.