这似乎是由于执行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%
如果转由executin呼应上g 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
类(实际的编译器)。当*
通配符是源文件路径中的第一个字符时,此行为不存在。
在我的ubuntu盒子里,它只有在'-d'参数最后出现或没有编译脚本时才起作用 – Will 2014-10-02 20:23:29
这很有趣,我以为我看到某个地方-d必须先到达。 – 2014-10-02 20:36:02