在java类路径中转义通配符处理 [英] escape wildcard processing in java classpath

查看:422
本文介绍了在java类路径中转义通配符处理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

由于通配符处理,下一个代码打印当前目录中每个文件的属性。

  c:\work> attrib * 

我需要在我的脚本中禁用通配符处理。换码符号不工作:

  c:\work> attrib*
c:\work> attrib ^ *

两者都给你一样。



我需要禁用通配符处理才能启动我接受通配符作为参数的应用程序。



A.java

  import java.util.Arrays; 

public class A {

public static void main(String [] args){
System.out.println(Arrays.deepToString(args));
}
}

CMD

  C:\work\temp> start.bat 

C:\work\temp> java -cp playground.jar A *
[activation.jar,file.txt,playground.jar,playground.jar.bak,start.bat,test.bat]

C:\work\temp> start .bat

C:\work\temp> java -cp playground.jar*
[activation.jar,file.txt,playground.jar,playground.jar。 bak,start.bat,test.bat]

C:\work\temp> start.bat

C:\work\temp> java -cp playground.jar* foo?* bar *
[* foo? * bar *]






找到解决方法。 *; - 不是falid文件夹名称,但有效的类路径:

  java -cp*; A 

感谢。

解决方案

正如Ignacio Vazquez-Abrams已经指出的,在Windows上,shell 不执行通配符扩展。这取决于应用程序。所以没有什么你可以做的shell来阻止它做的事情,它不做的第一个地方。

 > echoargs.exe * 
arg 1:*

因此,如果应用程序中的参数已损坏

显然,Java帮助复制了Unix行为并为你展开了所有的通配符。以上 echoargs 是用C#编写的,这就是为什么问题没有显示。



2004年的此错误报告。这是因为Java与不同的版本 setargv ,如这里在MSDN上,因此在命令行参数中扩展通配符。这发生在Java甚至看到参数,因为这是C运行时启动代码。



此外,这是没有记录在任何地方,只要我能找到,bug 5036373 linked above甚至注意到应该记录。没有修复,显然。即使它不可能传递一个字面通配符到Java程序。显然Windows确实只是Java的二等目标,他们不在乎(或者它会打破太多的程序,但我不知道有很多明确依赖这种行为)。


Next code prints attributes of each file in current directory because of wildcard processing.

c:\work>attrib *

I need to disable wildcard processing in my script. Escape symbols dont work:

c:\work>attrib "*"
c:\work>attrib ^*

Both give you the same.

I need to disable wildcard processing to start my application that accept wildcard as an argument.

A.java

import java.util.Arrays;

public class A {

    public static void main(String[] args) {
        System.out.println(Arrays.deepToString(args));
    }
}

CMD

C:\work\temp>start.bat

C:\work\temp>java -cp playground.jar A *
[activation.jar, file.txt, playground.jar, playground.jar.bak, start.bat, test.bat]

C:\work\temp>start.bat

C:\work\temp>java -cp playground.jar A "*"
[activation.jar, file.txt, playground.jar, playground.jar.bak, start.bat, test.bat]

C:\work\temp>start.bat

C:\work\temp>java -cp playground.jar A "* foo? *bar*"
[* foo? *bar*]


Found workaround. "*;" - not falid folder name, but valid classpath:

java -cp "*;" A

Thanks.

解决方案

As Ignacio Vazquez-Abrams already notes, on Windows the shell does not do wildcard expansion. That's up to the application. So there is nothing you can do to the shell to stop it from doing something that it doesn't do in the first place.

> echoargs.exe *
arg 1: *

So if the arguments in your application are corrupted somehow, then it's definitely not the shell's fault.

EDIT: Apparently Java "helpfully" copies the Unix behaviour and expands all wildcards for you. Above echoargs was written in C#, which is why the problem didn't show.

Ok, further digging reveals this bug report from 2004. This is because Java was linked with a different version of setargv, as described here on MSDN and thus expands wildcards in command-line arguments. This happens before Java even sees the arguments because this is the C runtime startup code.

Furthermore, this is not documented anywhere as far as I could find, bug 5036373 linked above even notes that it should be documented. No fix for that, apparently. Even though it makes it impossible to pass a literal wildcard to Java programs. Apparently Windows is indeed just a second-class target for Java and they don't care (or it would break too many programs, but I'm not sure there are that many that explicitly rely on this behaviour).

这篇关于在java类路径中转义通配符处理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆