1

次のコードは、ワイルドカード処理により、現在のディレクトリ内の各ファイルの属性を出力します。 

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 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*]

回避策が見つかりました。「*;」- 間違ったフォルダ名ではなく、有効なクラスパス:

java -cp "*;" A

ありがとう。

4

1 に答える 1

4

Ignacio Vazquez-Abrams がすでに指摘しているように、Windows では、シェルはワイルドカード展開を行いません。それはアプリケーション次第です。したがって、そもそもシェルが実行しないことを実行するのを止めるために、シェルに対してできることは何もありません。

> echoargs.exe *
arg 1: *

したがって、アプリケーションの引数が何らかの形で破損している場合、それはシェルのせいではありません。

編集:どうやら Java は Unix の動作を「役立つように」コピーし、すべてのワイルドカードを展開します。上記echoargsは C# で記述されているため、問題は発生しませんでした。

OK、さらに掘り下げると、2004 年のこのバグ レポートが明らかになります。これは、MSDNsetargvで説明されているように、 Java が別のバージョンの にリンクされていたため、コマンド ライン引数でワイルドカードが展開されたためです。これは C ランタイムの起動コードであるため、Java が引数を認識する前に発生します。

さらに、これは私が見つけた限りどこにも文書化されていません。上記のバグ 5036373 には、文書化する必要があるとさえ記載されています。どうやらそれに対する修正はありません。リテラル ワイルドカードを Java プログラムに渡すことはできなくなりますが。どうやら Windows は実際には Java の第 2 級のターゲットにすぎず、彼らは気にしません (または、あまりにも多くのプログラムを壊してしまいますが、この動作に明示的に依存しているプログラムがそれほど多くあるかどうかはわかりません)。

于 2012-07-23T07:34:41.843 に答える