Groovyc *.groovy strange behavior

Question

I have a handfull of groovy files that I compile into java class files with groovyc (because it's a good bit quicker to start java than starting up groovy just to run a short script.) All the scripts are in the default package but they share some common functionality defined in a ".support" package.

I was just reworking it and found an amazingly strange problem--when I use:

cd /D c:\scripts
groovyc -d c:\destPath *.groovy
cd support
groovyc -d c:\destPath *.groovy

Everything worked fine.

But when I compile the way I'd expect to:

groovyc -d c:\destPath c:\scripts\*.groovy

It would only compile one of the scripts (I believe it was the last one alphabetically).

Anyone have an explanation for this behavior?

In my ubuntu box it only works if the `-d` param comes last or no script gets compiled — Will, Oct 02 '14 at 20:23
That's interesting, I thought that I saw somewhere that the -d had to come first. — Bill K, Oct 02 '14 at 20:36

M A · Accepted Answer · 2014-10-03T12:21:42.030

This seems due to the wrapper batch script that executes the groovyc executable.

On Windows, the groovyc command will start a batch script called startGroovy.bat:

"%DIRNAME%\startGroovy.bat" "%DIRNAME%" org.codehaus.groovy.tools.FileSystemCompiler %*

I'm no expert in batch files but If you take a close look at startGroovy.bat, you can easily notice that there is some kind of a hack that is being done on the * wildcard that is passed as an argument to the script (e.g. c:\scripts\*.groovy):

rem escape minus (-d), quotes (-q), star (-s).
set _ARGS=%*
if not defined _ARGS goto execute
set _ARGS=%_ARGS:-=-d%
set _ARGS=%_ARGS:"=-q%
rem Windowz will try to match * with files so we escape it here
rem but it is also a meta char for env var string substitution
rem so it can't be first char here, hack just for common cases.
rem If in doubt use a space or bracket before * if using -e.
set _ARGS=%_ARGS: *= -s%
set _ARGS=%_ARGS:)*=)-s%
set _ARGS=%_ARGS:0*=0-s%
set _ARGS=%_ARGS:1*=1-s%
set _ARGS=%_ARGS:2*=2-s%
set _ARGS=%_ARGS:3*=3-s%
set _ARGS=%_ARGS:4*=4-s%
set _ARGS=%_ARGS:5*=5-s%
set _ARGS=%_ARGS:6*=6-s%
set _ARGS=%_ARGS:7*=7-s%
set _ARGS=%_ARGS:8*=8-s%
set _ARGS=%_ARGS:9*=9-s%

If you turn echoing on by executing set DEBUG=on in the command line, and then execute the groovyc command again, you will obtain the output of the batch script where you can see how the wildcard is being processed. Below is a sample log with a scenario where we have 3 files named File1.groovy, File2.groovy and File3.groovy.

groovyc -d c:\destPath c:\scripts\*.groovy

Sample output:

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set _ARG=C:\scripts\File3.groovy 

C:\scripts>set CMD_LINE_ARGS= C:\scripts\File3.groovy 

C:\scripts>set _ARG=

It seems the script is ignoring the first two files and eventually only the last one is passed to the org.codehaus.groovy.tools.FileSystemCompiler class (the actual compiler). This behavior does not exist when the * wildcard is the first character in the path to the source files.

Great answer, thanks. Sounds like a groovy bug with the windows batch integration--I'm surprised I didn't see it reported anywhere. I don't like digging into those groovy batch files they seem complex and fragile--yet I just assumed I was doing something wrong. Should know better than to assume. — Bill K, Oct 09 '14 at 18:18

Groovyc *.groovy strange behavior

1 Answers1