Changeset 32969

Timestamp:

2019-04-02T17:24:42+13:00 (5 years 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.

File:

• main/trunk/greenstone3/gs3-setup.bat (modified) (1 diff)

main/trunk/greenstone3/gs3-setup.bat

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