Build of 7.0.SVN dont work

[jeleniste]

i try install build of 7.0.SVN grass and this don't work on my PC

Starting GRASS GIS...
python: can't open file '\c\OSGeo4W\apps\grass\grass-7.0.svn\etc\gui\wxpython\gi
s_set.py': [Errno 2] No such file or directory
Received EXIT message from GUI.
GRASS is not started. Bye.

[martinl]

How did you compiled GRASS?

See CompileOnWindows

[martinl]

Replying to jeleniste:

i try install build of 7.0.SVN grass and this don't work on my PC

ops, sorry I read compile instead of install ;-) Currently the machine where daily builds are creating is not accessible. WinGRASS 7.0 needs some fixes. I will take a look at this issue ASAP.

[hellik]

Replying to martinl:

Replying to jeleniste:

i try install build of 7.0.SVN grass and this don't work on my PC

ops, sorry I read compile instead of install ;-) Currently the machine where daily builds are creating is not accessible. WinGRASS 7.0 needs some fixes. I will take a look at this issue ASAP.

tested with the latest accessible WinGrass7-nightly build (WinGRASS-7.0.SVN-r42077-1-Setup.exe).

in grass70.py there is the wrong paths

gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.svn"
cmd_name = "grass70"
grass_version = "7.0.svn"
ld_library_path_var = 'PATH'
config_projshare = "/c/OSGeo4W/share/proj"
grass_config_dirname = ".grass7"

gisbase should be "C:\Program Files\GRASS-70-SVN"

and

config_projshare should be "C:\Program Files\GRASS-70-SVN\proj"

best regards Helmut

[hellik]

Replying to hellik:

gisbase should be "C:\Program Files\GRASS-70-SVN"

and

config_projshare should be "C:\Program Files\GRASS-70-SVN\proj"

tested by manually changing to above, WinGrass7 is starting normally.

best regards Helmut

[hellik]

Replying to hellik:

Replying to hellik:

gisbase should be "C:\Program Files\GRASS-70-SVN"

and

config_projshare should be "C:\Program Files\GRASS-70-SVN\proj"

this should be fixed in the next nightly WinGrass7-build (r42332, r42334). please test.

Helmut

[martinl]

Replying to hellik:

this should be fixed in the next nightly WinGrass7-build (r42332, r42334). please test.

just note that "start with msys" option is still broken.

[martinl]

Replying to martinl:

Replying to hellik:

this should be fixed in the next nightly WinGrass7-build (r42332, r42334). please test.

just note that "start with msys" option is still broken.

...the remaining issue is how to launch correctly the shell, see grass/trunk/lib/init/grass.py@42357#L774​. Any hits welcomed...

[glynn]

Replying to martinl:

...the remaining issue is how to launch correctly the shell, see grass/trunk/lib/init/grass.py@42357#L774​. Any hits welcomed...

subprocess.call() is fine, but SHELL isn't normally going to be set on Windows, so it will need to be set in a batch file prior to running the grass70.py script (or the script needs -cmd and -sh options to choose the shell).

[martinl]

Replying to glynn:

Replying to martinl:

...the remaining issue is how to launch correctly the shell, see grass/trunk/lib/init/grass.py@42357#L774​. Any hits welcomed...

subprocess.call() is fine, but SHELL isn't normally going to be set on Windows, so it will need to be set in a batch file prior to running the grass70.py script (or the script needs -cmd and -sh options to choose the shell).

what about GRASS_SH - grass/trunk/lib/init/grass.py@42357#L864​ ?

[glynn]

Replying to martinl:

subprocess.call() is fine, but SHELL isn't normally going to be set on Windows, so it will need to be set in a batch file prior to running the grass70.py script (or the script needs -cmd and -sh options to choose the shell).

what about GRASS_SH

GRASS_SH specifies the program used to run Bourne shell scripts. I don't know if it's still needed in 7.0, but if it is, it must refer to a compatible shell regardless of whether you want to use sh.exe or cmd.exe for the interactive command line.

On Unix, SHELL specifies the user's preferred shell (from the last field in /etc/passwd). It's meant for use by programs which provide an option to spawn an interactive shell (e.g. "M-x shell" in Emacs). It will always be set for an interactive login unless the user explicitly unsets it.

On Windows, the shortcuts need to refer to batch files which set it explicitly before invoking grass70.py, i.e. "set SHELL=...\bin\sh.exe" for "start with MSys" and "set SHELL=%COMSPEC%" for "start with Windows command prompt". Alternatively, extending the grass70.py script with e.g. -sh and -cmd switches would eliminate the need for batch files and allow the shortcut to refer to the script directly (AFAIK, a shortcut can specify arguments but not environment variables).

[hellik]

Replying to glynn:

Replying to martinl:

subprocess.call() is fine, but SHELL isn't normally going to be set on Windows, so it will need to be set in a batch file prior to running the grass70.py script (or the script needs -cmd and -sh options to choose the shell).

what about GRASS_SH

GRASS_SH specifies the program used to run Bourne shell scripts. I don't know if it's still needed in 7.0, but if it is, it must refer to a compatible shell regardless of whether you want to use sh.exe or cmd.exe for the interactive command line.

On Unix, SHELL specifies the user's preferred shell (from the last field in /etc/passwd). It's meant for use by programs which provide an option to spawn an interactive shell (e.g. "M-x shell" in Emacs). It will always be set for an interactive login unless the user explicitly unsets it.

On Windows, the shortcuts need to refer to batch files which set it explicitly before invoking grass70.py, i.e. "set SHELL=...\bin\sh.exe" for "start with MSys" and "set SHELL=%COMSPEC%" for "start with Windows command prompt". Alternatively, extending the grass70.py script with e.g. -sh and -cmd switches would eliminate the need for batch files and allow the shortcut to refer to the script directly (AFAIK, a shortcut can specify arguments but not environment variables).

at the moment, with the desktop-shortcut "GRASS 7.0.SVN" and the "GRASS Command Line"-shortcut in the program menue

(seehttp://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi#L621)

you get in both cases a windows-commandline with the following information:

This version running through:   shell (C:\Program Files\GRASS-70-SVN\msys\bin\sh.exe)

In this windows-commandline a shell is running and you have access to the shell-utilities:

i.e.

GRASS 7.0.svn> gawk --help
Usage: gawk [POSIX or GNU style options] -f progfile [--] file ...
Usage: gawk [POSIX or GNU style options] [--] 'program' file ...
POSIX options:          GNU long options:
        -f progfile             --file=progfile
        -F fs                   --field-separator=fs
        -v var=val              --assign=var=val
[...]

And also the windows-commandline commands are working.

So you have both a working shell and a working windows command line.

The only thing is, that you have only access to the following folders in the moment:

GRASS 7.0.svn> ls
bin  doc  etc  home  info  lib  m.ico  man  msys.bat  msys.bat.tmpl  msys.ico

So maybe, we should remove "GRASS 7.0.SVN with MSYS", because there is already a shell and a windows-commandline accessible.

Helmut

[martinl]

Replying to hellik:

at the moment, with the desktop-shortcut "GRASS 7.0.SVN" and the "GRASS Command Line"-shortcut in the program menue

(seehttp://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi#L621)

you get in both cases a windows-commandline with the following information:

This version running through:   shell (C:\Program Files\GRASS-70-SVN\msys\bin\sh.exe)

"GRASS 7.0.svn" (cmd) is working OK. "GRASS 7.0.svn with MSYS" just flash and nothing happens.

From running MSYS

landa@GEO1 /osgeo4w/usr/src/grass_trunk
$ ./bin.i686-pc-mingw32/grass70 -wx

landa@GEO1 /osgeo4w/usr/src/grass_trunk
$ Cleaning up temporary files...
Starting GRASS GIS...
UPOZORNÌNÍ: Attention!
UPOZORNÌNÍ: Locking is not supported on Windows!

          __________  ___   __________    _______________
         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/
        / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \ 
       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ / 
       \____/_/ |_/_/  |_/____/____/   \____/___//____/  

Welcome to GRASS 7.0.svn (2010) 

GRASS homepage:                          http://grass.osgeo.org
This version running through:            shell (C:\OSGeo4W\apps\msys\bin\sh.exe)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
If required, restart the GUI with:       g.gui wxpython
When ready to quit enter:                exit

Cleaning up temporary files...
Done.

Goodbye from GRASS GIS

Traceback (most recent call last):
  File "c:\osgeo4w\usr\src\grass_trunk\dist.i686-pc-mingw32\etc\gui\wxpython\wxg                                ui.py", line 73, in <module>
    import gui_modules.preferences as preferences
  File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/etc/gui/wxpython/gui                                _modules/preferences.py", line 857, in <module>
    globalSettings = Settings()
  File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/etc/gui/wxpython/gui                                _modules/preferences.py", line 545, in __init__
    self.ReadSettingsFile()
  File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-mingw32/etc/gui/wxpython/gui                                _modules/preferences.py", line 610, in ReadSettingsFile
    gisdbase = gisenv['GISDBASE']

[glynn]

Replying to martinl:

"GRASS 7.0.svn" (cmd) is working OK. "GRASS 7.0.svn with MSYS" just flash and nothing happens.

From running MSYS

    gisdbase = gisenv['GISDBASE']

This may be related to MSys imposing its own $HOME directory. If you start GRASS manually from within an existing MSys shell, it should probably use MSys' definition of $HOME. If you start the shell from a shortcut or from the wxGUI, it's debatable whether it should use MSys' $HOME or Windows' %HOMEDRIVE%%HOMEPATH% or Windows' %USERPROFILE%; it all depends upon how "Unix-like" the user wants their shell to be.

Actually, I don't think that we've explicitly discussed the correct location for the saved $GISRC file on Windows; arguably, it should go into e.g. "%USERPROFILE%\Application Data\GRASS7".

[martinl]

Replying to glynn:

Actually, I don't think that we've explicitly discussed the correct location for the saved $GISRC file on Windows; arguably, it should go into e.g. "%USERPROFILE%\Application Data\GRASS7".

Right, currently there are two location which is quite messy approach

• CMD - grass/trunk/mswindows/GRASS-Installer.nsi@42334#L680​

FileWrite $0 'rem Directory where your .grass7/rc file will be stored$\r$\n
FileWrite $0 'set HOME=%USERPROFILE%$\r$\n'

• SH - grass/trunk/mswindows/GRASS-Installer.nsi@42334#L826​

CreateDirectory $INSTALL_DIR\msys\home\$USERNAME\.grass7

Unique location for config dir would nice idea.

%USERPROFILE%\Application Data\GRASS

seems to be OK.

[martinl]

Replying to martinl:

> %USERPROFILE%\Application Data\GRASS

or better {{{ %APPDATA%\GRASS }}}