Changeset 32969 for main

Show
Ignore:
Timestamp:
02.04.2019 17:24:42 (8 months ago)
Author:
ak19
Message:

Fix to a bug discovered and investigated by Kathy: on Win, when there are spaces in the filepath to the GS3 installation, gs3-setup fails to properly detect the bitness of the GS3 installation to determine what bitness of Java to use. (In her case this may have further caused the subsequent problem of no JAVA_HOME and JRE_HOME being found because the bundled JRE gets discounted due to the unknown bitness. In my case, it finds a system JDK to fall back on, but with this fix finds and uses the bundled JRE as it's of the correct bitness.) The quick solution is to use relative filepaths.

Files:
1 modified

Legend:

Unmodified
Added
Removed
  • main/trunk/greenstone3/gs3-setup.bat

    r31473 r32969  
    173173:: Could use shortfilenames, see http://stackoverflow.com/questions/10227144/convert-long-filename-to-short-filename-8-3-using-cmd-exe 
    174174if not exist "!GSDL3SRCHOME!\lib\jni\gdbmjava.dll" set bitness=UNKNOWN& goto setupjavahome 
    175 for /f "usebackq tokens=2 delims= " %%G IN (`call "!GSDLHOME!\bin\windows\GNUfile\bin\file.exe" "!GSDL3SRCHOME!\lib\jni\gdbmjava.dll"`) do set bitness=%%G 
     175rem The following breaks when GS3 is installed in a path containing spaces 
     176rem for /f "usebackq tokens=2 delims= " %%G IN (`call "!GSDLHOME!\bin\windows\GNUfile\bin\file.exe" "!GSDL3SRCHOME!\lib\jni\gdbmjava.dll"`) do set bitness=%%G 
     177rem So run with relative filepaths: 
     178for /f "usebackq tokens=2 delims= " %%G IN (`cd gs2build ^&^& call "bin\windows\GNUfile\bin\file.exe" "..\lib\jni\gdbmjava.dll"`) do set bitness=%%G 
    176179 
    177180if "%bitness%" == "PE32+" (