Startup runs as in Cygwin when CYGWIN is set although running as native application

[wenzeslaus]

Reported on mailing list, I don't know how Cygwin works, so this might be partially problem on user side but startup should be able to handle this.

On ​Tue, Aug 19, 2014 at 2:58 AM, Sindile Bidla wrote:

/usr/bin/bash.exe: Command not found

The problem is that "/usr/bin/bash.exe" is expected but not found. Why it is expected? Because once CYGWIN variable is in environmental variables, GRASS start up script thinks that it runs in the Cygwin mode and for some reasons needs to use full path.

    # cygwin has many problems with the shell setup
    # below, so i hardcoded everything here.
    if os.getenv('CYGWIN'):
        sh = "cygwin"
        shellname = "GNU Bash (Cygwin)"
        os.environ['SHELL'] = "/usr/bin/bash.exe"
        os.environ['OSTYPE'] = "cygwin"

In any case, this is not supposed to work as OSGeo4W and standalone GRASS are not Cygwin applications. They are native MS Windows applications, so this would anyway fail later.

The problem is that you have CYGWIN variable in you environment and GRASS GIS then thinks that it is supposed to run as Cygwin application. This leads to three questions.

1) Do you need CYGWIN variable in you environment for some reason? Are you using some Cygwin applications? (I don't know if the later implies the former but it seems that the Cygwin environment is not correct anyway.) Removing CYGWIN from the environment (at least for GRASS if this is possible on MS Windows) would workaround GRASS imperfect deciding about type of application it is (Cygwin or MS Windows native).

2) For GRASS GIS, is there some better way of getting to know if it is running as Cygwin application?

3) Is this Cygwin part even needed? We are not relying on Cygwin in GRASS GIS 7 anymore and we don't plan to do so, as far as I know. So, a possile solution is just removing this Cygwin-related code.

Note that this is quite high priority because GRASS will not start when CYGWIN is in the enviroment.

[glynn]

Replying to wenzeslaus:

1) Do you need CYGWIN variable in you environment for some reason?

FWIW, the CYGWIN variable isn't even set in my Cygwin64 environment, so checking it may lead to false negatives as well as false positives.

2) For GRASS GIS, is there some better way of getting to know if it is running as Cygwin application?

For a Python script, sys.platform will tell you if you're running a Cygwin version of Python.

Another option would be to check for the presence of the variable SHELL in the environment. If it doesn't exist, GRASS is probably being launched from a desktop icon or start menu entry, in which case the GUI should be started directly. If SHELL is set, GRASS should spawn a session using that shell, in the current console.

Ideally, we shouldn't be trying to distinguish Cygwin from other Unix platforms except where this turns out to be strictly necessary.

3) Is this Cygwin part even needed? We are not relying on Cygwin in GRASS GIS 7 anymore and we don't plan to do so, as far as I know. So, a possile solution is just removing this Cygwin-related code.

This isn't version-specific. For a long time, we have offered GRASS for both (native) Windows and Cygwin. Some Windows users (e.g. those who already use Cygwin for other reasons) may prefer the Cygwin version.

[sindile]

I have replaced etc\grass70.py with the attached grass.py (have renamed it to grass70.py) as per this email ​http://lists.osgeo.org/pipermail/grass-user/2014-August/070728.html

This is the error I get,

firstly I get a libgrass_gis.7.0.0beta3.dll missing error and then the following

Cleaning up temporary files... Starting GRASS GIS... Unable to import pyGRASS: grass_gis.7.0.0beta3 not found. Some functionality will be not accessible

_ _

/ / \/ | / _/ _/ / / _/ _/

/ / / /_/ / /| | \
_ \ / / / / \ \

/ /_/ / _, _/ _ |_/ // / / /_/ / _/ / \/_/ |_/_/ |_/// \/_/

Welcome to GRASS @GRASS_VERSION_NUMBER@ GRASS homepage: ​http://grass.osgeo.org This version running through: Bourne 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

Launching <wxpython> GUI in the background, please wait... GRASS @GRASS_VERSION_NUMBER@> Unable to import pyGRASS: grass_gis.7.0.0beta3 not

found.

Some functionality will be not accessible Traceback (most recent call last):

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\wxgui.py", line 34,

in <module>

from lmgr.frame import GMFrame

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\lmgr\frame.py", line

50, in <module>

from lmgr.layertree import LayerTree, LMIcons

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\lmgr\layertree.py",

line 37, in <module>

from mapdisp.frame import MapFrame

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\mapdisp\frame.py", l

ine 35, in <module>

from vdigit.toolbars import VDigitToolbar

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\vdigit\toolbars.py",

line 30, in <module>

from iclass.digit import IClassVDigit

File "C:\OSGeo4W\apps\grass\grass-7.0.0beta3\gui\wxpython\iclass\digit.py", li

ne 23, in <module>

from vdigit.wxdisplay import DisplayDriver, TYPE_AREA

ImportError: cannot import name TYPE_AREA

Furthermore I do not have a CYGWIN in my environmental variables defined.

[hellik]

Replying to sindile:

I have replaced etc\grass70.py with the attached grass.py (have renamed it to grass70.py) as per this email ​http://lists.osgeo.org/pipermail/grass-user/2014-August/070728.html

in the attached script

# Variables substituted during build process
if 'GISBASE' in os.environ:
    gisbase = os.environ['GISBASE']
else:
    gisbase = "@GISBASE@"
cmd_name = "@START_UP@"
grass_version = "@GRASS_VERSION_NUMBER@"
ld_library_path_var = '@LD_LIBRARY_PATH_VAR@'
if 'GRASS_PROJSHARE' in os.environ:
    config_projshare = os.environ['GRASS_PROJSHARE']
else:
    config_projshare = "@CONFIG_PROJSHARE@"

it should be something (adapted to beta3) like

# Variables substituted during build process
if 'GISBASE' in os.environ:
    gisbase = os.environ['GISBASE']
else:
    gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.0svn"
cmd_name = "grass70"
grass_version = "7.0.0svn"
ld_library_path_var = 'PATH'
if 'GRASS_PROJSHARE' in os.environ:
    config_projshare = os.environ['GRASS_PROJSHARE']
else:
    config_projshare = "/c/OSGeo4W/share/proj"

[hellik]

Replying to hellik:

Replying to sindile:

I have replaced etc\grass70.py with the attached grass.py (have renamed it to grass70.py) as per this email ​http://lists.osgeo.org/pipermail/grass-user/2014-August/070728.html

in the attached script

# Variables substituted during build process
if 'GISBASE' in os.environ:
    gisbase = os.environ['GISBASE']
else:
    gisbase = "@GISBASE@"
cmd_name = "@START_UP@"
grass_version = "@GRASS_VERSION_NUMBER@"
ld_library_path_var = '@LD_LIBRARY_PATH_VAR@'
if 'GRASS_PROJSHARE' in os.environ:
    config_projshare = os.environ['GRASS_PROJSHARE']
else:
    config_projshare = "@CONFIG_PROJSHARE@"

it should be something (adapted to beta3) like

# Variables substituted during build process
if 'GISBASE' in os.environ:
    gisbase = os.environ['GISBASE']
else:
    gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.0svn"
cmd_name = "grass70"
grass_version = "7.0.0svn"
ld_library_path_var = 'PATH'
if 'GRASS_PROJSHARE' in os.environ:
    config_projshare = os.environ['GRASS_PROJSHARE']
else:
    config_projshare = "/c/OSGeo4W/share/proj"

for beta3 in osgeo4w it should be:

# Variables substituted during build process
if 'GISBASE' in os.environ:
    gisbase = os.environ['GISBASE']
else:
    gisbase = "/c/OSGeo4W/apps/grass/grass-7.0.0beta3"
cmd_name = "grass70"
grass_version = "7.0.0beta3"
ld_library_path_var = 'PATH'
if 'GRASS_PROJSHARE' in os.environ:
    config_projshare = os.environ['GRASS_PROJSHARE']
else:
    config_projshare = "/c/OSGeo4W/share/proj"

[hellik]

Replying to sindile:

Furthermore I do not have a CYGWIN in my environmental variables defined.

instead of the CYGWIN issue, could it be some kind of an incomplete installation caused by missing admin rights (right click and install as admin - standalone as well osgeo4w) or by some blocking antivirus software?

[zarch]

Replying to hellik:

it should be something (adapted to beta3) like

[cut]

a cleaned version could be:

# Variables substituted during build process
cmd_name = "grass70"
grass_version = "7.0.0svn"
ld_library_path_var = 'PATH'
gisbase = os.environ.get('GISBASE', "/c/OSGeo4W/apps/grass/grass-7.0.0svn")
config_projshare = os.environ.get('GRASS_PROJSHARE', "/c/OSGeo4W/share/proj")

And I believe that variables: cmd_name and grass_version that at the moment are hard-coded should be defined in some more clever way.

I'm not sure but I think that even the path: /c/OSGeo4W/ could/should be a variable in case that the user change the default installation directory.

[hellik]

Replying to zarch:

I'm not sure but I think that even the path: /c/OSGeo4W/ could/should be a variable in case that the user change the default installation directory.

the path (is?)/should be adapted by the osgeo4w-installation-script.

[sindile]

instead of the CYGWIN issue, could it be some kind of an incomplete installation caused by missing admin rights (right click and install as admin - standalone as well osgeo4w) or by some blocking antivirus software?

I have installed by right click and install as admin on osgeo4w as well as the standalone and Grass 7.0.0 beta3 works. I also did not have to replace /etc/grass70.py

This is strange because with previous version I never needed to right click and install as admin.

[wenzeslaus]

Replying to glynn:

Replying to wenzeslaus:

1) Do you need CYGWIN variable in you environment for some reason?

FWIW, the CYGWIN variable isn't even set in my Cygwin64 environment, so checking it may lead to false negatives as well as false positives.

2) For GRASS GIS, is there some better way of getting to know if it is running as Cygwin application?

For a Python script, sys.platform will tell you if you're running a Cygwin version of Python.

So, I will change this accoring to ​GRASS-user Grass-7.0 beta3 fails to launch:

if sys.platform == 'cygwin':

I'm just not sure from the documentation if "equals", "startswith", or "in" is more appropriate.

Another option would be to check for the presence of the variable SHELL in the environment. If it doesn't exist, GRASS is probably being launched from a desktop icon or start menu entry, in which case the GUI should be started directly. If SHELL is set, GRASS should spawn a session using that shell, in the current console.

According to comment and the source code I think that SHELL variable might be somehow wrong sometimes.

• source:grass/trunk/lib/init/grass.py#L906​

Ideally, we shouldn't be trying to distinguish Cygwin from other Unix platforms except where this turns out to be strictly necessary.

Yes, we would be defeating the purpose of Unix and Cygwin then but I guess this is the exception.

3) Is this Cygwin part even needed? We are not relying on Cygwin in GRASS GIS 7 anymore and we don't plan to do so, as far as I know. So, a possile solution is just removing this Cygwin-related code.

This isn't version-specific. For a long time, we have offered GRASS for both (native) Windows and Cygwin. Some Windows users (e.g. those who already use Cygwin for other reasons) may prefer the Cygwin version.

OK, if we still support Cygwin and it is still possible to install GRASS GIS like this we need to keep the code there.

[hellik]

Replying to sindile:

instead of the CYGWIN issue, could it be some kind of an incomplete installation caused by missing admin rights (right click and install as admin - standalone as well osgeo4w) or by some blocking antivirus software?

I have installed by right click and install as admin on osgeo4w as well as the standalone and Grass 7.0.0 beta3 works. I also did not have to replace /etc/grass70.py

This is strange because with previous version I never needed to right click and install as admin.

installing as admin is default since a few years now (standalone ~3 years, osgeo4w ~1 year).

any change on your system?

[hellik]

Replying to wenzeslaus:

Replying to glynn:

Replying to wenzeslaus:

1) Do you need CYGWIN variable in you environment for some reason?

FWIW, the CYGWIN variable isn't even set in my Cygwin64 environment, so checking it may lead to false negatives as well as false positives.

2) For GRASS GIS, is there some better way of getting to know if it is running as Cygwin application?

For a Python script, sys.platform will tell you if you're running a Cygwin version of Python.

So, I will change this accoring to ​GRASS-user Grass-7.0 beta3 fails to launch:

if sys.platform == 'cygwin':

I'm just not sure from the documentation if "equals", "startswith", or "in" is more appropriate.

Another option would be to check for the presence of the variable SHELL in the environment. If it doesn't exist, GRASS is probably being launched from a desktop icon or start menu entry, in which case the GUI should be started directly. If SHELL is set, GRASS should spawn a session using that shell, in the current console.

According to comment and the source code I think that SHELL variable might be somehow wrong sometimes.

• source:grass/trunk/lib/init/grass.py#L906​

Ideally, we shouldn't be trying to distinguish Cygwin from other Unix platforms except where this turns out to be strictly necessary.

Yes, we would be defeating the purpose of Unix and Cygwin then but I guess this is the exception.

3) Is this Cygwin part even needed? We are not relying on Cygwin in GRASS GIS 7 anymore and we don't plan to do so, as far as I know. So, a possile solution is just removing this Cygwin-related code.

This isn't version-specific. For a long time, we have offered GRASS for both (native) Windows and Cygwin. Some Windows users (e.g. those who already use Cygwin for other reasons) may prefer the Cygwin version.

OK, if we still support Cygwin and it is still possible to install GRASS GIS like this we need to keep the code there.

as the source of original failure report is an incomplete installation, closing ticket?

[wenzeslaus]

Replying to wenzeslaus:

So, I will change this accoring to ​GRASS-user Grass-7.0 beta3 fails to launch.

Committed to trunk and 70 in r61705 and r61706.

Replying to hellik:

as the source of original failure report is an incomplete installation, closing ticket?

Closing. However, shouldn't the installer tell you that it was in fact unsuccessful installation and that nothing will work, or that you are not running it with admin rights (assuming now that admin right are really necessary). I guess that GRASS itself cannot tell much since it is broken.

[hellik]

Replying to wenzeslaus:

Replying to wenzeslaus:

So, I will change this accoring to ​GRASS-user Grass-7.0 beta3 fails to launch.

Committed to trunk and 70 in r61705 and r61706.

Replying to hellik:

as the source of original failure report is an incomplete installation, closing ticket?

Closing. However, shouldn't the installer tell you that it was in fact unsuccessful installation and that nothing will work, or that you are not running it with admin rights (assuming now that admin right are really necessary). I guess that GRASS itself cannot tell much since it is broken.

few years ago I've implemented in the standalone installer to ask/install by admin

​http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L100

100	;Request application privileges for Windows
101	RequestExecutionLevel admin

by simple double clicking (no right click) on the standalone installer, you should be asked to grant admin rights. similar is implemented in the OSGeo4W-setup.

regarding should, as there are so many different flavours of windows with too many different system rights settings out there in the wild, it's hardly possible to catch all possible hurdles.

at least it should be mentioned in the download page.

[hellik]

Replying to hellik:

​http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Installer.nsi.tmpl#L100

100	;Request application privileges for Windows
101	RequestExecutionLevel admin

by simple double clicking (no right click) on the standalone installer, you should be asked to grant admin rights. similar is implemented in the OSGeo4W-setup.

regarding should, as there are so many different flavours of windows with too many different system rights settings out there in the wild, it's hardly possible to catch all possible hurdles.

at least it should be mentioned in the download page.

additional check may be if you run as admin:

​example 1

​example 2

something like:

!include LogicLib.nsh

Function .onInit
UserInfo::GetAccountType
pop $0
${If} $0 != "admin" ;Require admin rights on NT4+
    MessageBox mb_iconstop "Administrator rights required!"
    SetErrorLevel 740 ;ERROR_ELEVATION_REQUIRED
    Quit
${EndIf}
FunctionEnd

Page InstFile

Section
SectionEnd

[wenzeslaus]

Replying to sindile:

I have replaced etc\grass70.py with the attached grass.py (have renamed it to grass70.py) as per this email ​http://lists.osgeo.org/pipermail/grass-user/2014-August/070728.html

This is the error I get,

firstly I get a libgrass_gis.7.0.0beta3.dll missing error and then the following ...

Are you sure that you are not getting the error dialogs with missing MS...DLL files? I have just seen similar/same errors on some MS Windows 7 computer.

The ​GRASS download page for MS Windows says:

Troubleshooting: If the program exits immediately after you start it or it complains about a missing MSVCR71.dll, MSCVP100.dll or similar on startup, you may need to install Microsoft's .NET Framework. See also WinGRASS errors (and their solution).

But .NET Framework was not enough and we had to go to ​linked wiki page and use the last option "mimic what installer is doing".

It is actually the second computer I see where was necessary to do the "mimic what installer is doing" steps. I don't have an idea what does this mean.