[GRASS-dev] [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

GDAL · May 3, 2009, 9:40am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Keywords: wingrass | Platform: MSWindows XP
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Hi,

None of the GUI wrapper scripts called from the GUI menus work in WinGRASS
due to lack of associated file extensions.

these are the shell and python scripts installed in
$GISBASE/etc/gui/scripts/

explained here:
http://thread.gmane.org/gmane.comp.gis.grass.devel/32133

see also bug #234.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580>
GRASS GIS <http://grass.osgeo.org>

GDAL · May 10, 2009, 8:14am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

I may have solved the problem of the GUI scripts not running on WinGRASS
with r37085, 86, 87. They were missing .bat wrappers. leaving bug open as
I haven't properly tested it.

'''TODO'''
  * grass 7: (gui/scripts/Makefile) fix (wildcard *.*) and then use with
create.bat:
  * wxpython/scripts/Makefile: do p.* need .bat files too?
  * similar thing needed to get g.gui launcher to work on WinGRASS?

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · June 4, 2009, 9:23am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

still doesn't work for v.type_wrapper.py and g.change.gui.py using latest
native wingrass installer (6.4.0.svn 2009-05-02).

in wx it fails looking for the --interface-description.
in tcl it just gives a red "X" in the output window, no error message.

maybe need something like:
{{{
guiscritpspath = os.path.join(globalvar.ETCDIR, 'gui','scripts')
sys.path.append(guiscriptspath)
}}}
??

(still doesn't work, similar error if called with --ui from the msys
terminal prompt)

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · August 9, 2009, 6:44am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

This still doesn't work for v.type_wrapper.py and g.change.gui.py using
latest native WinGrass installer (Colin's 6.4.0.svn r38537 2009-07-29).

wxGUI `Vector -> Develop -> Convert object types` menu item gives a
windows dialog:
{{{
Windows cannot open this file:
File: v.type_wrapper.py
To open this file, Windows needs to know what program created it. ...
[*] Use the web service to find the approp prog
Select the program from a list

[ok] [cancel]
}}}

and if you press cancel the wxGui layer manager output tab comes back with
a Traceback error ending in
{{{
...
IOError
:
Unable to fetch interface description for command
'v.type_wrapper.py'.
}}}

`echo $PATHEXT` in the associated Msys terminal ends in ';.PY',
so at least that part of lib/init/init.bat or init.sh is getting run.

neither $PATH nor $PYTHONPATH includes $GISBASE/etc/gui/scripts/
see this trac ticket log for some sys.path.append(guiscriptspath) ideas.

also I'd note that NVIZ still doesn't start from the wxGUI:
`File -> NVIZ (req tcltk)` brings up the NVIZ launch dialog and lets you
select a map but when you hit [Run] it just returns after 0sec. Same if
you try from the wxGui Cmd> prompt. But if you type 'nviz -q' at the
associated Msys terminal it brings it up ok.

??

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 2, 2009, 3:49am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

(working with Colin's native WinGrass installer r39271)

%PATHEXT% is used to indicate that .py files are executable and usable
without their extension. But this only seems to work from the DOS box
version of WinGrass, not from the MSys xterm (no big surprise there).

Running a python script from the DOS prompt it fails though because it
doesn't know what program to associate .PY with.

what is apparently missing is:
{{{
set .py="%GISBASE%/extrabin\python.exe"
}}}

but setting that in the DOS box doesn't associate it properly.

(aside: strangely `dir "%GISBASE%/extrabin\python.exe"` succeeds while
`dir "%GISBASE%/extrabin/python.exe"` fails at the DOS prompt)

some random google hit shows it might need assoc + ftype as well, so I add
this all together in C:\GRASS-6-SVN\grass64.bat just after the "set
PYTHONHOME":

{{{
set .py="%GRASSDIR%\extrabin\python.exe"
assoc .py=Python.File
ftype Python.File="%GRASSDIR%\extrabin\python.exe" "%1" "%*"
assoc .pyw=Python.NoConFile
ftype Python.NoConFile="%GRASSDIR%\extrabin\pythonw.exe" "%1" "%*"
}}}

and then "cd C:\GRASS-6-SVN\etc\gui\scripts" and v.type_wrapper<enter>
finally launches python, but gives a "unknown option -e" error and shows
the python.exe usage text.

should {{{ set PYTHONPATH="%GRASSDIR%\etc\python" }}} be set in
C:\GRASS-6-SVN\grass64.bat as well?

?,
Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 3, 2009, 4:23am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):

Replying to [comment:4 hamish]:

> %PATHEXT% is used to indicate that .py files are executable and usable
without their extension. But this only seems to work from the DOS box
version of WinGrass, not from the MSys xterm (no big surprise there).

Right. MSys' bash emulates Unix execution semantics.

Ultimately, WinGRASS is supposed to be "GRASS for Windows", not "GRASS for
MSys".

> Running a python script from the DOS prompt it fails though because it
doesn't know what program to associate .PY with.
>
> what is apparently missing is:
{{{
set .py="%GISBASE%/extrabin\python.exe"
}}}

I've never seen this syntax. The normal way to associate applications with
extensions is via assoc and ftype (but AFAICT, those change the system-
wide settings, which may have be overriden by per-user settings).

> some random google hit shows it might need assoc + ftype as well,

It's more likely to be "instead of". "set" sets environment variables,
which have nothing to do with file associations.

> so I add this all together in C:\GRASS-6-SVN\grass64.bat just after the
"set PYTHONHOME":
>
{{{
set .py="%GRASSDIR%\extrabin\python.exe"
assoc .py=Python.File
ftype Python.File="%GRASSDIR%\extrabin\python.exe" "%1" "%*"
assoc .pyw=Python.NoConFile
ftype Python.NoConFile="%GRASSDIR%\extrabin\pythonw.exe" "%1" "%*"
}}}

Note that this will change the registry keys, which will permanently
affect the handling of all .py files on the system, not just those which
are part of GRASS, and not just for the lifetime of the command prompt.

Bundling a "local" copy of Python (with a matching copy of wxPython) may
be a reasonable approach for getting the wxGUI working, but any standalone
scripts will use the system Python installation, and GRASS shouldn't be
interfering with that (applications which automatically "steal" file
associations are generally considered to be malware).

> and then "cd C:\GRASS-6-SVN\etc\gui\scripts" and v.type_wrapper<enter>
finally launches python, but gives a "unknown option -e" error and shows
the python.exe usage text.
>
> should {{{ set PYTHONPATH="%GRASSDIR%\etc\python" }}} be set in
C:\GRASS-6-SVN\grass64.bat as well?

Probably not. This should only be set when invoking a Python script using
the bundled copy of Python. Scripts run from the command prompt will use
the system's Python, so you shouldn't be modifying PYTHONPATH in this
case.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 3, 2009, 5:37am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

Replying to [comment:4 hamish]:
> > Running a python script from the DOS prompt it fails though
> > because it doesn't know what program to associate .PY with.
> >
> > what is apparently missing is:
  {{{
   set .py="%GISBASE%/extrabin\python.exe"
  }}}

Replying to [comment:5 glynn]:
> I've never seen this syntax.

Nevermind, further down in the thread that suggested that is the small
caveat that belongs to some NT4 3rd party replacement for cmd.exe (gee,
thanks for the tip then).

> The normal way to associate applications with extensions is via
> assoc and ftype (but AFAICT, those change the system-wide
> settings, which may have be overriden by per-user settings).
...
> Note that this will change the registry keys, which will
> permanently affect the handling of all .py files on the system,
> not just those which are part of GRASS, and not just for the
> lifetime of the command prompt.

... leading to more like bug #570

So lacking a way to locally set the extension association, our only choice
is to ditch PATHEXT and use wrapper scripts which ensure that the
GRASS_PYTHON enviro var. is respected. Workable from the GUI, but running
GRASS python modules from the command line will be at the mercy of
whatever version of python the user has installed. (a python wrapper
script which launched another (but this time known) version of python to
run a script is probably asking for trouble)

> Bundling a "local" copy of Python (with a matching copy of
> wxPython) may be a reasonable approach for getting the wxGUI
> working,

(and even with doing that we still aren't close to mastering it)

> but any standalone scripts will use the system Python
> installation, and GRASS shouldn't be interfering with that

is there anything left which won't use the python set by the GRASS_PYTHON
enviro variable? (from #570 apparently the answer is yes)

> (applications which automatically "steal" file associations are
> generally considered to be malware).

... Windows would seem to have a lot of malware then ... at least the DLL
version clobbering in favour of the last-to-run installer is less
prevalent these days.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 3, 2009, 7:03am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by cmbarton):

Given all this, is there a way to run a Python script in GRASS for Windows
now (i.e., by including some code in the script or its batch file) or will
it have to wait until the GRASS code is changed?

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 3, 2009, 9:06am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):

Replying to [comment:6 hamish]:

> > The normal way to associate applications with extensions is via
> > assoc and ftype (but AFAICT, those change the system-wide
> > settings, which may have be overriden by per-user settings).
> ...
> > Note that this will change the registry keys, which will
> > permanently affect the handling of all .py files on the system,
> > not just those which are part of GRASS, and not just for the
> > lifetime of the command prompt.
>
> ... leading to more like bug #570

I thought that #570 related specifically to the GUI.

Note that the GUI is a bit more problematic because it requires a version
of Python with wx 2.8, and relying upon the system Python having this is a
bit optimistic (but not entirely unrealistic; wxPython has stock binary
packages to match the stock Python 2.4, 2.5 and 2.6, and supports
concurrent installation of multiple versions of wxPython).

> So lacking a way to locally set the extension association, our only
choice is to ditch PATHEXT and use wrapper scripts which ensure that the
GRASS_PYTHON enviro var. is respected.

The obvious choice is to simply use the system Python, just like we do on
Unix.

It's not as if the user is overwhelmed by a choice of 20 different third-
party Python packages. There are standard Windows (and MacOSX) binary
packages available from the python.org website (without any of the
licensing issues associated with relying upon !ActiveState, like was the
case for Tcl/Tk).

If the user wants to associate the .py extension with something which
isn't compatible[*] with the stock Python, that's their problem. It's not
like we support Unix systems where /bin/sh is csh, either.

[*] It doesn't have to actually '''be''' the stock Python, but it does
need to provide the same language with the same modules. Scripts don't
need binary compatibility.

> > but any standalone scripts will use the system Python
> > installation, and GRASS shouldn't be interfering with that
>
> is there anything left which won't use the python set by the
GRASS_PYTHON enviro variable? (from #570 apparently the answer is yes)

Running a .py script from the command line or via the Windows shell (i.e.
via !ShellExecute, which includes {{{subprocess.Popen(..., shell =
True)}}}) won't use GRASS_PYTHON, nor should it. Even within a GRASS
session, the command line should be able to run non-GRASS commands,
including those written in Python.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 4, 2009, 12:04am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

Replying to [comment:7 cmbarton]:
> Given all this, is there a way to run a Python script in GRASS for
> Windows now (i.e., by including some code in the script or its
> batch file) or will it have to wait until the GRASS code is
> changed?

I think the answer is yes, there is a way. This bug report is mostly
worried about add-on scripts in $GISBASE/etc/gui/scripts being called from
the GUI. You will have to experiment from the command line to test local
g.parser scripts or those in GRASS_ADDON_DIR; please let us know results!

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:9>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 4, 2009, 12:10am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by cmbarton):

So far nothing works. We did up the Python script the way it is suggested
in the WIKI and it works fine on Linux and Mac. It either does nothing or
hangs before launching on Windows. The farthest we've gotten is to get the
error that the script does not generate an XML interface-description. My
interpretation is that python parser work on Linux and Mac but not on
Windows from the command line.

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:10>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 6, 2009, 12:09am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):

Replying to [comment:10 cmbarton]:
> So far nothing works. We did up the Python script the way it is
suggested in the WIKI and it works fine on Linux and Mac. It either does
nothing or hangs before launching on Windows. The farthest we've gotten is
to get the error that the script does not generate an XML interface-
description. My interpretation is that python parser work on Linux and Mac
but not on Windows from the command line.

On Windows, 6.4's g.parser explicitly invokes the script via $GRASS_SH.
Obviously this won't work for Python scripts.

FWIW, Python scripts work in Windows in 7.0, whether the script is in the
path or not (once PYTHONPATH has been set; Init.bat doesn't set this).

The biggest difference between the two is that in 7.0, the
grass.script.parser() Python function uses "g.parser -s", which eliminates
the need to re-execute the script. It may be worth back-porting this
feature to 6.x (the existing behaviour is still available for use by shell
scripts).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:11>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 6, 2009, 6:36am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by cmbarton):

Replying to [comment:11 glynn]:
> Replying to [comment:10 cmbarton]:
> > So far nothing works. We did up the Python script the way it is
suggested in the WIKI and it works fine on Linux and Mac. It either does
nothing or hangs before launching on Windows. The farthest we've gotten is
to get the error that the script does not generate an XML interface-
description. My interpretation is that python parser work on Linux and Mac
but not on Windows from the command line.
>
> On Windows, 6.4's g.parser explicitly invokes the script via $GRASS_SH.
Obviously this won't work for Python scripts.

Does this mean that it is only expecting shell scripts in Windows? What
happens on other platforms (since Python does run without problems in
Linux and on Mac)?

>
> FWIW, Python scripts work in Windows in 7.0, whether the script is in
the path or not (once PYTHONPATH has been set; Init.bat doesn't set this).
>
> The biggest difference between the two is that in 7.0, the
grass.script.parser() Python function uses "g.parser -s", which eliminates
the need to re-execute the script. It may be worth back-porting this
feature to 6.x (the existing behaviour is still available for use by shell
scripts).

Seems like that would be a very good idea, if it means that you can run
something besides shell scripts in a Windows environment.

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:12>
GRASS GIS <http://grass.osgeo.org>

GDAL · October 6, 2009, 8:46am

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by glynn):

Replying to [comment:12 cmbarton]:

> > On Windows, 6.4's g.parser explicitly invokes the script via
$GRASS_SH. Obviously this won't work for Python scripts.
>
> Does this mean that it is only expecting shell scripts in Windows?

Yes. Windows doesn't understand shebang lines, so g.parser can't "run" the
shell scripts as if they were executables; it has to use "$GRASS_SH
<script>".

It might be possible to use "$GRASS_SH -c <script>", as MSys' bash
understands shebang lines. OTOH, for "#!/usr/bin/env python", this will
only work if there is an executable named "python" in the path (if it's
called e.g. "python25" or it isn't in the path, you lose).

Alternatively, the scripts could be installed with a ".sh" extension,
relying upon the file associations to run such scripts via bash.

Or you could make g.parser examine the first line of the script and choose
a suitable interpreter (it isn't as simple as processing a shebang on Unix
as we don't know where MSys' virtual filesystem is located and we can't
assume that the "#!/usr/bin/env" trick will work with "native"
interpreters).

> What happens on other platforms (since Python does run without problems
in Linux and on Mac)?

The code to re-invoke the script is conditionalised upon "#ifdef
!__MINGW32!__". Unix (including MacOSX) simply execl()s the script
directly, while the Windows version invokes it via $GRASS_SH.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:13>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 12:06pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

Hello,

update for this bug report based on the latest native wingrass installer
(r40049) on XP:

works:
  - wxGUI File->"NVIZ (req's tcltk)"
  - "nviz -q" from the wxGUI layer manager 'Cmd> ' prompt
  - wxGUI Vector->Develop->"Digitize (req's tcltk)"

(excellent!)

does not work:
  - wxGUI Config->Working Environ->Change Default GUI
    (Traceback error in command output tab ... Unable to fetch interface
description for command 'g.change.gui.py'.)
  - wxGUI Vector->Develop->Change object types
    (Traceback error in command output tab ... Unable to fetch interface
description for command 'v.type_wrapper.py'.)
  - from the Cmd> prompt:
   * g.change.gui (nothing happens),
   * g.change.gui.py (Unable to fetch interface desc),
   * g.change.gui.py --help (Command finished 0 sec),
   * g.change.gui.py --interface-description (Command finished 0 sec)

any suggestions?

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:14>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 4:44pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by cmbarton):

Why can't windows use g.gui gui=[guiplatform] -nu?

In fact, even though both g.change.gui and v.type_wrapper are in my
source, they are not getting into my OS X binary. Perhaps they are not
getting into the Windows binary either?

There is a problem running python scripts in GRASS for Windows. Ironic in
that one reason for Python is that it is cross-platform. From recent
discussions on this (Glynn, Colin, me, others), it seems like the best
solution will be to NOT package Python with GRASS (wxPython may be a
different issue), but to have an installer that checks for a Python
installation and if not present directs the user to python.org to install
it. A regular Python installation will properly put Python in the registry
so that it can be called to execute scripts.

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:15>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 5:56pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by cnielsen):

Replying to [comment:15 cmbarton]:
> Why can't windows use g.gui gui=[guiplatform] -nu?

This command does work in the msys command prompt (native installer
r40049), with this followed by g.gui &, you can switch back and forth with
no problem.

>
> In fact, even though both g.change.gui and v.type_wrapper are in my
source, they are not getting into my OS X binary. Perhaps they are not
getting into the Windows binary either?

These are present in the windows installations in etc\gui\scripts. Well,
in fact there is
g.change.gui.py
g.change.gui.sh
g.change.gui.sh.bat
but no
g.change.gui

>
> There is a problem running python scripts in GRASS for Windows. Ironic
in that one reason for Python is that it is cross-platform. From recent
discussions on this (Glynn, Colin, me, others), it seems like the best
solution will be to NOT package Python with GRASS (wxPython may be a
different issue), but to have an installer that checks for a Python
installation and if not present directs the user to python.org to install
it. A regular Python installation will properly put Python in the registry
so that it can be called to execute scripts.

I've been working on an update to the NSIS installer that will check to
see if Python is installed via the registry, and if not auto-download and
install the four necessary packages (python, wxpython, pywin32, and
numpy). The installer already does something similar for the sample
datasets.

However, if the gui or other modules needs a build specific version then
this could get complicated... Is there a clear idea of which parts require
build specific and which do not? Where do pywin32 and numpy fit in? Can
build specific parts only be included in the installer and still use an
external Python?

I can make the installer, but I need these details to know how to assemble
it.

-Colin

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:16>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 7:27pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hellik):

Replying to [comment:14 hamish]:

>
> does not work:
> - wxGUI Config->Working Environ->Change Default GUI
> (Traceback error in command output tab ... Unable to fetch interface
description for command 'g.change.gui.py'.)
> - wxGUI Vector->Develop->Change object types
> (Traceback error in command output tab ... Unable to fetch interface
description for command 'v.type_wrapper.py'.)
> - from the Cmd> prompt:
> * g.change.gui (nothing happens),
> * g.change.gui.py (Unable to fetch interface desc),
> * g.change.gui.py --help (Command finished 0 sec),
> * g.change.gui.py --interface-description (Command finished 0 sec)

a quick look at the manual:

http://grass.osgeo.org/grass64/manuals/html64_user/general.html

there seems to be no g.change.gui(.py)

g.gui is working on windows

Helmut

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:17>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 10:27pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

> Replying to [comment:14 hamish]:
> > does not work:
> > - wxGUI Config->Working Environ->Change Default GUI
> > (Traceback error in command output tab ... Unable to fetch
interface description for command 'g.change.gui.py'.)

Replying to [comment:17 hellik]:
> there seems to be no g.change.gui(.py)

sure there is. look at the title of this bug report.

The source is in gui/scripts/, it gets installed to
$GISBASE/etc/gui/scripts/. All the wrapper scripts in there fail on
wingrass. These wrapper scripts are needed to make command line based
modules more GUI dialog friendly, or to extract particular targted
functionality.

https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/gui/scripts/

the above quoted menu path shows where it is in the wx menu.

> g.gui is working on windows

that is something different (a normal C module, not a python wrapper
script).

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:18>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 21, 2009, 11:02pm

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter: hamish | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: blocker | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: | Keywords: wingrass
  Platform: MSWindows XP | Cpu: Unspecified
---------------------------+------------------------------------------------
Comment (by hamish):

> Replying to [comment:15 cmbarton]:
> > Why can't windows use g.gui gui=[guiplatform] -nu?

Replying to [comment:16 cnielsen]:
> This command does work in the msys command prompt (native
> installer r40049), with this followed by g.gui &, you can
> switch back and forth with no problem.

  * this is hardly as user friendly as a GUI which asks: "use Wx", "use
Tcl", or "use text" & restart. these wrapper scripts are not designed for
power users who are comfortable with the command line.
  * the default osgeo4w build does not give the user a msys prompt,
although I guess you could try the Cmd> prompt if you knew the exact magic
incantation.
  * v.type from a GUI is impossible and needs a wrapper.

> > There is a problem running python scripts in GRASS for Windows.

it's just a bug, and not a fundamental problem. mere details can and will
be fixed.

> > A regular Python installation will properly put Python in
> > the registry so that it can be called to execute scripts.

we ''should'' have the equivalent already set up in the msinstaller
startup batch files and scripts to associate .py with a suitable
python.exe. check this bug's previous comments & grep the msinstaller
scripts for more. but that isn't working for some reason.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:19>
GRASS GIS <http://grass.osgeo.org>