Issues with the Windows startup batch files

• Patch Submitted:

  Yes

I spend a lot more time as initially intended on the Windows batch files used to start Groovy. I found several issues already mentioned here as well as some new one. Here the summary of what I found so far:

1. Spaces, quotes (") and asterisks in the argument list of startGroovy.bat may cause the script to fail (see #GROOVY-1525). Also spaces in groovy home path will case problems. I did already suggest a fix for this in #GROOVY-3043.

2. The exit code from the Groovy script is not returned to the calling environment (see #GROOVY-1034).

3. The FOR loop used to search java.exe on the PATH will fail if PATH contains spaces. It will even cause an error if PATH contains a ")" (closing bracket). This may get more important in future, as Vista64 likes to used directories names like "C:\Program Files (x86)\". The reason for this is to set JAVA_HOME if not present (see #GROOVY-1924).

4. The script uses a CMD /C DIR together with a FIND command to check existence of the JAVA_HOME directory. The location of the executables is done hard coded depending on %SystemRoot%. No checks are done if the executables have been found. (Please note that at least the command processor could absolute safely be found using the ComSpec variable.)

5. The property "program.name" is set to the value of %PROGNAME%. This variable is not set inside the groovy scripts, so usually on Windows systems it will be empty. Only if it was defined before the script started, the predefined value will be used.

6. The property "script.name" is set to the first parameter following any classpath argument assuming this is the name of the groovy script to execute. This will obviously fail if an option like "-l" is present.

7. Generally the handling of "script.name" is different in Windows and Unix (see #GROOVY-2648). Unix will set it to the name of the calling script and Windows will (try to) set it to the name of the groovy script to execute. #GROOVY-1642 is indicating that Unix is doing wrong here and the name of the groovy script should be used.

8. If GROOVY_HOME is not set the batch tries to resolve GROOVY_HOME depending on the first parameter passed to the script (DIRNAME). This is the directory, where the calling batch (i.e. groovy.bat) was located. In some rare cases this may fail, so if startGroovy.bat is called directly from a script that is not located in GROOVY_HOME\bin.

9. The initial startup files like groovy.bat will generally fail on Window systems before NT. These versions do not support the ~-operator and so will try to execute "~dp0\startGroovy.bat".

10. The initial startup files like groovy.bat expect to find startGroovy.bat in the same directory where the script itself is located. No check is done if this is true.

To solve all this issues I have added a lot of changes to the existing code. Naturally this does include the risk of causing new issues. But as some of the current issues are quite serious I think it is worth the risk. Here a short overview about the main changes:

ad. 1: Spaces, quotes (") and asterisks in the argument list are not a problem when using the Windows_NT features instead of the FOR loop. Keeping out pre-Windows NT versions shouldn't cause any problems as the scripts currently will not even start here. The new version will at least show a message giving the user a hint that Groovy may be started by building a command line manually.

ad. 2: To return the exit code from the Groovy script to the calling program is quite easy. It just needs to save the return code from Java (set RC=%ERRORLEVEL%) and use the "EXIT /B %RC%" command at the end of the script.
Here a simple test to show how it works:
c:\> groovy -e "System.exit(42)"
c:\> echo %errorlevel%
c:\> 42
Also the extended version shown in #GROOVY-1034 in will now work as expected:
c:\> groovy -e "p='groovy.bat -e \"System.exit(10)\"'.execute();p.waitFor();println p.exitValue()"
c:\>10

ad. 3: Searching java.exe using the FOR statement will fail if the PATH contains " " or ")". Well, this topic may need some more discussions. The only reason for this is to set JAVA_HOME by finding "bin\java.exe" in the PATH. And the only reason to set JAVA_HOME is to be able to set the "tools.jar" property on startup. Just searching "java.exe" would return the one usually installed in the "system32" directory, which will not help. This is also the reason why the simple (and save) search using the "%~$PATH:I" construct can not be used as this does not work for relative filenames.
I decided to remove the search completely which will let the script behave as follows:
If started without having JAVA_HOME set it will let Windows choose the java.exe to start. Other than now, not try is made to locate JAVA_HOME and thus the "tools.jar" property is never set.
If started having JAVA_HOME set the JAVA_HOME\bin\java.exe will be used and the tools.jar property will be set to JAVA_HOME\lib\tools.jar if it is present (same as now)
If you think the current behavior (i.e. have the "tools.jar" property set when "the first bin\java.exe found on the PATH is found in a directory that also contains a lib\tools.jar file") should be kept: It is possible to realize this by enhancing the FOR statement, but this will blow up the script by additional 70 lines of code.)

ad. 4: The use of CMD /C DIR and FIND seem only be done to check if JAVA_HOME is set to a valid directory. I think this can be removed completely. Checking if the directory "JAVA_HOME\bin\java.exe" exists will implicit make sure that JAVA_HOME is a valid too.

ad. 5,6,7: Setting the properties program.name and script.name.
The script.name property will now be set to the groovy script to execute. In detail it will be set to the first argument following all options including their arguments. If no script is present (i.e. when using the -e option), it will be empty.
The program.name property will also be set now. It will do the same as Unix does now, i.e. when calling groovy.bat it will be set to "groovy", if calling groovysh.bat it will be set to "groovysh" etc.

ad. 8: If GROOVY_HOME is missing it will now be set depending on the directory where startGroovy.bat itself is located. Usually this should not make any difference, as groovy.bat and startGroovy.bat will stay in the same directory. But the old version would fail if startGroovy.bat would be called directly from some local script.

ad. 9, 10: I have change the initial start up files like groovy.bat as follows:
A messages will be shown if called on pre-Windows NT systems as well as if startGroovy.bat is not found in the same directory as the script itself.
I thought about trying to locate startGrovvy.bat if not found. It could easily be done by testing GROOY_HOME or searching the PATH. But finally I don't see any reason to do this as all Groovy batch files will ever be installed together in one directory (GROOVY_HOME\bin).

General notes:
The environment variable DIRNAME is not present any more. This could be a problem if any of the local initialization scripts relay on this. If you think this is an important issue DIRNAME should be set again in the initial startup scripts.

The attached startGroovy.bat script was taken from Groovy version 1.6.0. If you want to test it with other versions make sure to adjust the following line according to your version:
set STARTER_CLASSPATH=%GROOVY_HOME%\lib\groovy-1.6.0.jar

The initial startup files only differ in the name of the class passed to startGroovy.bat. I only have added groovy.bat here. You can easily build the other files from this by simply changing the class parameter in the call of startGroovy.bat.

I have removed the special handling for 4NT systems as I assume the now installed handling of the command line arguments will work for these systems too. Please note that the special handling did not even work up to now (see 'GROOVY-1925).