wx and tcltk GUI: changing default GUI returns error

[hamish]

Hi,

working with latest 6.4.0svn WinGrass from the osgeo4w installer.

1. Start up the wxGui in spearfish/user1.

In the Layer Manager GUI: Config -> GRASS Working Environment -> Change default GUI

nothing happens, only this appears in the output window:

Traceback (most recent call last):
  File "C:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wx
gui.py", line 515, in OnMenuCmd

menuform.GUI().ParseCommand(cmd, parentframe=self)
  File "C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1716, in ParseCommand

xml.sax.parseString( getInterfaceDescription(cmd[0]),
handler )
  File "C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py", line 1657, in
getInterfaceDescription

raise IOError, _("Unable to fetch interface description for
command '%s'.") % cmd
IOError
:
Unable to fetch interface description for command
'g.change.gui.py'.

2. startup the tcltk gui with "grass64 -tcltk" from the OSGeo4W shell prompt.

In the GIS manager do

Config -> GRASS Working Environment -> Change default GUI

a tcltk popup Error window comes up which says:

couldn't execute "C:\OSFeo4W\apps\grass\grass-6.4.0svn\etc\gui\scripts\g.change.gui.sh":
 no such file or directory  [OK]

after you press OK an empty wish gui is there titled "dialog0".

the file is in fact there. (it's a bash script)

??, Hamish

[hamish]

see also wish #500

[hamish]

I guess all the scripts in $GISBASE/etc/gui/scripts/ need batch files like are used for the scripts in $GISBASE/bin/: e.g. the file "C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\v.in.garmin.bat" contains the single line:

@"%GRASS_SH%" -c '"%GISBASE%/scripts/v.in.garmin" %*'

Hamish

[hamish]

same thing happens with 6.4.0rc4 native wingrass install.

the release notes say that the tcltk gui is unavailable, but I *can* start it if I start in the msys mode, close the wxGUI and type "gis.m" on the command line. weirdly to access maps in spearfish PERMANENT from user1 I have to type in the map name manually with @PERMANENT, in the avail map listing the PERMANENT mapset is closed.

some space could be saved by not shipping d.m with native wingrass (it also starts, but without xmons it is useless)

strangely "g.gui tcltk" from the msys command line does not work. (and the GRASS> prompt is still ridiculously long for an 80 col terminal)

Hamish

[hamish]

see also bug #580, and ​http://trac.osgeo.org/osgeo4w/ticket/81#comment:7 and ​http://trac.osgeo.org/grass/changeset/37075

[hamish]

I may have solved the problem of g.change.gui[.sh|.py] not running on WinGRASS with r37085, 86, 87. The scripts in gui/scripts/ were missing .bat wrappers. leaving bug open as I haven't properly tested it.

Hamish

[cmbarton]

Is this now fixed for Windows or is it still broken?

Michael

[hamish]

still broken, same as v.type wrapper. see #580, report:13.

Hamish

[neteler]

See also #639

[cmbarton]

Does anyone know how to solve this scripts issue for Windows? I'm happy to implement something but don't understand how to fix this. It seems to me that it is something that needs to be done somewhere outside the GUI. If so, we should probably change the "component" to whatever component is the right place to fix Windows ability to read these scripts.

Michael

[glynn]

Replying to cmbarton:

Does anyone know how to solve this scripts issue for Windows? I'm happy to implement something but don't understand how to fix this. It seems to me that it is something that needs to be done somewhere outside the GUI. If so, we should probably change the "component" to whatever component is the right place to fix Windows ability to read these scripts.

The core issue is that Windows decides how to "run" scripts via the extension, not the shebang. If you want to support the most general case, all scripts must have an appropriate extension, e.g. .sh for Bourne shell scripts. Even then, we're dependent upon the file associations being set correctly (on Unix, we're dependent upon /bin/sh being a Bourne shell, but that's a much safer assumption).

We can get more limited support either by relying upon MSys or by implementing similar emulation ourselves (i.e. writing a utility to identify whether a command is an exe or a script and invoking the appropriate interpreter).

Either way, g.parser needs to be changed to match.

One option is to back-port the -s switch used by Python scripts, and to add similar functionality for Bourne-shell scripts (i.e. write out environment settings in a form that can be "eval"d). But that would require changing the g.parser boilerplate in existing shell scripts.

Aside from that, when invoking commands via subprocess.Popen, ensure that you use shell=True on Windows. Without that, it will only work for binaries (.exe and .com), not for scripts (which includes .bat files).

[cmbarton]

Replying to glynn:

Replying to cmbarton:

Does anyone know how to solve this scripts issue for Windows? I'm happy to implement something but don't understand how to fix this. It seems to me that it is something that needs to be done somewhere outside the GUI. If so, we should probably change the "component" to whatever component is the right place to fix Windows ability to read these scripts.

The core issue is that Windows decides how to "run" scripts via the extension, not the shebang. If you want to support the most general case, all scripts must have an appropriate extension, e.g. .sh for Bourne shell scripts. Even then, we're dependent upon the file associations being set correctly (on Unix, we're dependent upon /bin/sh being a Bourne shell, but that's a much safer assumption).

Thanks Glynn,

So does this mean that if the extension *.py is set to a python.exe (such as the one in $GISBASE/extrabin), a python script will actually run from the GRASS command line? Or does g.parser still need to be changed as you mention below?

We can get more limited support either by relying upon MSys or by implementing similar emulation ourselves (i.e. writing a utility to identify whether a command is an exe or a script and invoking the appropriate interpreter).

Either way, g.parser needs to be changed to match.

One option is to back-port the -s switch used by Python scripts, and to add similar functionality for Bourne-shell scripts (i.e. write out environment settings in a form that can be "eval"d). But that would require changing the g.parser boilerplate in existing shell scripts.

This is a fairly large hassle. However, I think that we really need to do this if it makes scripts runable in WinGRASS.

Aside from that, when invoking commands via subprocess.Popen, ensure that you use shell=True on Windows. Without that, it will only work for binaries (.exe and .com), not for scripts (which includes .bat files).

But this only applies to scripts called from the GUI, right?

Michael

[glynn]

Replying to cmbarton:

The core issue is that Windows decides how to "run" scripts via the extension, not the shebang. If you want to support the most general case, all scripts must have an appropriate extension, e.g. .sh for Bourne shell scripts. Even then, we're dependent upon the file associations being set correctly (on Unix, we're dependent upon /bin/sh being a Bourne shell, but that's a much safer assumption).

Thanks Glynn,

So does this mean that if the extension *.py is set to a python.exe (such as the one in $GISBASE/extrabin), a python script will actually run from the GRASS command line?

You would be able to run it from the Windows command prompt, or via system(), or via subprocess.call(..., shell=True). MSys might have its own ideas about running it based upon the shebang.

Or does g.parser still need to be changed as you mention below?

g.parser needs to be changed to work with non-Bourne-shell scripts on Windows. Right now, it always re-invokes the script using $GRASS_SH, which won't work for anything other than shell scripts. Either:

1. g.parser can be made to execute the script via some mechanism which pays attention to the type of the script (e.g. "sh -c ..." or "cmd /c ..."), or

2. both g.parser and the scripts can be re-written to avoid the need for re-invocation, as is done for Python scripts in 7.0.

#2 is more work, but is less susceptible to problems (incorrect file associations, g.parser not finding the script, MSys getting in the way).

One option is to back-port the -s switch used by Python scripts, and to add similar functionality for Bourne-shell scripts (i.e. write out environment settings in a form that can be "eval"d). But that would require changing the g.parser boilerplate in existing shell scripts.

This is a fairly large hassle. However, I think that we really need to do this if it makes scripts runable in WinGRASS.

It isn't strictly necessary. It is possible to make g.parser behave like it does on Unix, but it means relying upon either Windows or MSys execution semantics.

Relying upon Windows execution semantics means that scripts must have the correct extensions, the file associations must be set correctly (and GRASS can't have the final say in this), and how MSys deals with this is MSys' problem.

Relying upon MSys' execution semantics means that other parts of the system (e.g. wxGUI, g.parser, G_parser()) will have to explicitly cater to MSys (e.g. invoking commands via "$GRASS_SH -c ..." to ensure that MSys gets involved), and making scripts work transparently from the Windows command prompt would require .bat wrappers.

Bottom line: do you want "GRASS for Windows" or "GRASS for MSys"? There's a degree of mutual exclusion here.

Aside from that, when invoking commands via subprocess.Popen, ensure that you use shell=True on Windows. Without that, it will only work for binaries (.exe and .com), not for scripts (which includes .bat files).

But this only applies to scripts called from the GUI, right?

This applies to running scripts from within Python, although this is one instance of a wider principle.

On Unix, script execution is supported by the execve() system call, which is the only way to execute a program; all higher-level functions (the other exec* functions plus system(), popen() etc) go through here.

On Windows, the low-level functions (CreateProcess() and the _spawn* family) only work with executables (.exe, .com); running anything else (i.e. scripts, including .bat files) requires that the command is passed via ShellExecute() or "cmd /c <command>" (I have no idea how these two approaches relate to each other, beyond the fact that both are affected by the file associations).

IOW, in order for scripts to be treated on a par with binary executables, the shell must be involved. If some lower-level interface is used, commands which refer to executables will work on all platforms, scripts will work on Unix, but scripts won't work on Windows.

[cmbarton]

My inclination is that we would be better served in the long run with a GRASS for Windows rather than a GRASS for MSys. However, I don't know if the project has the expertise to support this or not. Also, I don't have the C skills to implement it either way. So I have to remain neutral and leave it to you and others to decide. I am happy to help with changes to the GUI and/or scripts as needed whichever way we decide to go.

IMHO, the important thing is that we make a decision one way or the other and implement it so that the Windows version of GRASS does not remain crippled (this coming from a Mac guy!).

Michael

[hamish]

calling the main gist of this bug has been fixed.

however, on wingrass the "start GRASS with wxPython gui" icon launches 'grass64 -wxpython', which has the effect of resetting the default GUI away from what you set, but there's a "start GRASS with tcltk gui" button as well so I guess you can get the one you want pretty easily. not sure the best way to fix that.

Hamish