After some investigation, I have come to the conclusion that this issue is most likely invalid, for the following reasons:
- The "mangling" is not caused by the dot itself, but it is caused by having one or more "non-8.3 compliant" directory names in DERBY_HOME. "8.3" is a common name for the old MS-DOS type of file names with a maximum of 8 character file name plus a 3 character extension (e.g. "PROGRAMS.TXT"). The directory name "10.3RC1" has 4 characters in the extension, so it is treated as a "Long File Name" (LFN), not an 8.3 file name. The "s" in the for loop in the script causes the directory name to be converted from LFN to 8.3 (see below).
- The script does not actually fail, because the "mangled" versions of DERBY_HOME and CLASSPATH are valid file system paths in Windows. E.g. running "java org.apache.derby.tools.sysinfo" after running the script should still work.
DERBY_HOME is modified in the script by the following line:
@FOR %%X in ("%DERBY_HOME%") DO SET DERBY_HOME=%%~sX
Where X is a variable reflecting the value of %DERBY_HOME%, and
~ expands X removing any surrounding quotes (")
s means that the "expanded path contains short names only"
(type FOR /? at a Windows command prompt for details)
Having said that, I don't really understand why the "s" (for converting to 8.3 names) is used, or why the for loop is used at all. All we have to do is to use the value of DERBY_HOME for setting the CLASSPATH variable...
One possible explanation is that this would perhaps make the script work with paths with spaces in them as well, but I have not been able to find the actual reasoning behind this (it has been like this since the scripts were donated to Apache). I'm still a bit confused when it comes to handling spaces in paths in batch files and environment variables on Windows, so I don't have a better suggestion at the moment.