我有很多用groovyc编译成Java类文件的groovy文件（因为启动Java比启动groovy更快，只是为了运行一个简短的脚本。）所有脚本都在默认程序包中，但它们共享一些“ .support”包中定义的常见功能。
当我使用它时，我只是在重新加工它，发现一个令人惊讶的奇怪问题：
cd /D c:\scripts
groovyc -d c:\destPath *.groovy
cd support
groovyc -d c:\destPath *.groovy
一切正常。
但是，当我按照期望的方式进行编译时：
groovyc -d c:\destPath c:\scripts\*.groovy
它只会编译其中一个脚本（我相信这是按字母顺序的最后一个）。
有人对此行为有解释吗？
这似乎是由于执行groovyc可执行程序的包装批处理脚本所致。
在Windows上，该groovyc命令将启动一个名为的批处理脚本startGroovy.bat：
"%DIRNAME%\startGroovy.bat" "%DIRNAME%" org.codehaus.groovy.tools.FileSystemCompiler %*
我不是批处理文件的专家，但是如果您仔细看一看startGroovy.bat，您会很容易注意到，*通配符上存在某种黑客行为，该黑客作为参数传递给脚本（例如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%
如果通过set DEBUG=on在命令行中执行打开回显，然后groovyc再次执行命令，则将获得批处理脚本的输出，您可以在其中查看如何处理通配符。下面是一个方案中的样本数，我们有3个文件命名File1.groovy，File2.groovy和File3.groovy。
groovyc -d c:\destPath c:\scripts\*.groovy
样本输出：
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=
似乎脚本忽略了前两个文件，最终只有最后一个文件传递给了org.codehaus.groovy.tools.FileSystemCompiler类（实际的编译器）。当*通配符是源文件路径中的第一个字符时，则不存在此行为。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句