windows - escape wildcard processing in java classpath

Question

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:workemp>start.bat

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

C:workemp>start.bat

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

C:workemp>start.bat

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

---

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

java -cp "*;" A

Thanks.

Answer 1

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).