在旧版本的Groovy中,我可以按照他们自己的指示运行Groovy作为Cygwin下的shell脚本:
$ cat ~/bin/hiworld
#!/usr/bin/env groovy
println("Hello world")
这很有效.但是,在(至少)Groovy 2.3.2和2.3.3下,我看到的是:
$ hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
我在黑暗中最好的刺:"env"通过绝对路径启动脚本(例如"groovy/home/myacct/bin/hiworld"),而新版本的Groovy已被"改进",以便Groovy不再理解如何处理这个.
实际上,我可以通过这样做产生同样的错误:
$ groovy ~/bin/hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
所以我不确定Groovy是如何(a)将其解析为Windows风格的路径,然后(b)无法理解它是一种Windows风格的路径.
我可以"修复"这个,然后通过这样运行它:
$ groovy $(cygpath -w ~/bin/hiworld)
Hello world
...但是,来吧,这是让用户启动实用程序脚本的完全疯狂方式.(或者我可以编写一个"前端"脚本,当然只是用那条线来启动另一个脚本.但是,对于我想要最终实现的目标,我不妨放弃Groovy并分发一个可运行的脚本.带有相关启动脚本的JAR.)
那么Groovy是否只是放弃了对Cygwin的支持？或者它们是否真的有可能至少有两个版本没有测试他们自己推荐的在最流行的环境之一下运行脚本的方式？
如果没有,我错过了什么或做错了什么？
更新:我认为备份我在这里提出的一些建议会有所帮助.
首先,我想要注意Cygwin显然是(或者是)至少得到了一些支持:例如,groovyStart在支持Cygwin平台方面有相当多的代码(看起来和Mac OSX一样多).如前所述,它在以前的版本中显然工作正常.
目前,最后一个示例在groovyStart下解析为:
'/cygdrive/c/Program Files/Java/jdk1.7.0_51/bin/java' -classpath C:/cygwin64/home/myacct/opt/groovy-2.3.3/lib/groovy-2.3.3.jar -Dscript.name=/home/myacct/opt/groovy-2.3.3/bin/groovy -Dprogram.name=groovy -Dgroovy.starter.conf=C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf -Dgroovy.home=C:/cygwin64/home/myacct/opt/groovy-2.3.3 '-Dtools.jar=C:/Program Files/Java/jdk1.7.0_51/lib/tools.jar' org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain --conf C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf --classpath . C:/cygwin64/home/myacct/bin/hiworld
只是为了澄清一下,调用JDK本身没有问题 - 运行命令的那部分运行就好了.被打破的部分是最后一个论点:如果我改变了
C:/cygwin64/home/myacct/bin/hiworld
至
file:///C:/cygwin64/home/myacct/bin/hiworld
......它再次起作用.这与我上面的断言一致,"groovy"(脚本)确实正确地从Cygwin/UNIX样式路径转换为本机Windows路径,但底层进程 - …