我使用groovyc将满手groovy文件编译成java类文件(因为启动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它只会编译其中一个脚本(我相信这是最后一个字母)。
有人能解释一下这种行为吗?
发布于 2014-10-02 21:08:42
这似乎是由于执行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类(实际的编译器)。如果*通配符是源文件路径中的第一个字符,则不存在此行为。
https://stackoverflow.com/questions/26168696
复制相似问题