Нерабочее расширение подстановочного знака для командной строки Java7 в Windows (7?) - PullRequest
Новая
       42

Нерабочее расширение подстановочного знака для командной строки Java7 в Windows (7?)

16 голосов
/ 08 февраля 2012

Я наблюдаю странное поведение поведения расширения с подстановочными знаками для Java7 в Windows.

Веками существовала четкая разница между "*" и *.
Кажется, это больше не так для Java7 (по крайней мере, для Windows7).

Я заметил проблему при использовании подстановочного знака класса .
Несмотря на цитирование подстановочного пути, он расширяется.
Таким образом, кажется, что больше невозможно передать шаблон для Java-приложения.

Таким образом, использование java -cp "somewhere/*" не удастся (как и "somewhere\*").

Обходной путь кажетсяbe: java -cp "somewhere/*;", который запрещает расширение.

Чтобы проверить поведение, я написал небольшой класс Echo.java.

Я обнаружил, что с помощью Java 1.6.0 цитируется "*" и обычный *работает как ожидалось, тогда как на Java7 я всегда получал расширенный шаблон.До сих пор это наблюдалось в Windows7, не знаю, что происходит в XP.

Проблема возникает, поскольку подстановочные знаки в Windows никогда не расширяются темным возрастом CMD.EXE (как любая оболочка в UNIX).Вместо этого каждый исполняемый файл должен выполнить это явно, используя setargv.obj .

Я обнаружил две связанные проблемы, которые, кажется, описывают похожую проблему:

Наблюдал ли это кто-то еще?
Или есть какие-то неясные настройки Windows или пакетного файла для управления этим?

Дитер.

Ответы [ 2 ]

7 голосов
/ 29 августа 2012

Да, я заметил ту же проблему.

  • Это объясняется как «известная проблема» в примечаниях к выпуску обновления Java7 4 .

  • Вот отчет об ошибке .Исправление будет доставлено в Java7, обновление 8 (текущий выпуск - обновление 6).

  • Обратите внимание, что обходного пути для параметров оболочки не существует, поскольку в Windows оболочка необрабатывать расширение по шаблону.(В то время как в Unixes оболочка выполняет расширение).

0 голосов
/ 27 июня 2016

Непосредственное решение проблемы / *, но я надеюсь, что вы могли бы использовать следующий сценарий для облегчения вашей ситуации. 

 libDir2Scan4jars="../test";cp=""; for j in `ls ${libDir2Scan4jars}/*.jar`; do if [ "$j" != "" ]; then cp=$cp:$j; fi; done; echo $cp| cut -c2-${#cp} > .tmpCP.tmp; export tmpCLASSPATH=`cat .tmpCP.tmp`; if [ "$tmpCLASSPATH" != "" ]; then echo .; echo "classpath set, you can now use  ~>         java -cp \$tmpCLASSPATH"; echo .; else echo .; echo "Error please check libDir2Scan4jars path"; echo .; fi;

Сценарий для Linux, может быть аналогичным и для Windows. Если в качестве входных данных для "libDir2Scan4jars" указан правильный каталог; скрипт отсканирует все файлы jar, создаст строку classpath и экспортирует ее в переменную env "tmpCLASSPATH".

...