Opened 7 years ago

Last modified 4 years ago

#1945 new defect

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

Reported by: hamish Owned by: grass-dev@…
Priority: normal Milestone: 6.4.6
Component: Python Version: svn-develbranch6
Keywords: wingrass Cc:
CPU: x86-32 Platform: MSWindows XP

Description

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

Change History (8)

comment:1 Changed 7 years ago by 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

comment:2 Changed 7 years ago by 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

comment:3 in reply to:  2 Changed 7 years ago by 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

comment:4 Changed 7 years ago by 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

comment:5 in reply to:  4 ; Changed 7 years ago by 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.

comment:6 in reply to:  5 Changed 7 years ago by 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

comment:7 Changed 7 years ago by hamish

Milestone: 6.4.36.4.4
Priority: criticalnormal

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

comment:8 Changed 4 years ago by neteler

Milestone: 6.4.46.4.6
Note: See TracTickets for help on using tickets.