1

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.

Mike
  • 20,010
  • 25
  • 97
  • 140

1 Answers1

4

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

Joey
  • 344,408
  • 85
  • 689
  • 683
  • It works for you because "* foo? \*bar\*" is not valid folder name, plese try single * – Mike Jul 23 '12 at 07:53
  • See edit. The shell isn't a fault, neither is Windows. It's Java. (And those are three arguments, the first of which is an asterisk.) – Joey Jul 23 '12 at 07:56
  • could you show autput of your app with single \* as an argument pls – Mike Jul 23 '12 at 07:59
  • It's as if you'd expect it. I told you, the shell does not to wildcard expansion and neither does any other part of Windows by default, excepting those functions who do so by design (e.g. `FindFirstFile`). – Joey Jul 23 '12 at 08:00
  • it is not Java neither, because wildcard in classpath is signifficant, well cocumented feature, and it works correctly in unix. Users face issues in windows http://stackoverflow.com/questions/7441112/java-command-line-arguments-using-as-an-argument-for-multiplication – Mike Jul 23 '12 at 08:09
  • Windows 7, Java 1.7u3 64-bit. And you need to quote the classpath if you include an `*`. Otherwise on Unix the shell *would* expand it. – Joey Jul 23 '12 at 08:15
  • Huh? You were looking for a *classpath*? I was under the impression that normal arguments gave you headaches. – Joey Jul 23 '12 at 08:26
  • classpath was original problem, then I've figured out that it is cmd processing, thus I've done simplest program that reveal that processing and started to play with it. – Mike Jul 23 '12 at 08:40