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

Question

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

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

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

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

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

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

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

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

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

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

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

Дитер.

16

java command-line windows-7 classpath wildcard

Источник

user371174 08 фев '12 в 14:19

3 ответа

Другие вопросы по тегам java command-line windows-7 classpath wildcard

user303698 29 авг '12 в 00:37 2012-08-29 00:37 · Answer 1 · 2012-08-29 00:37

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

Это объясняется как "известная проблема" в примечаниях к выпуску Java7 update 4.
Вот отчет об ошибке. Исправление будет доставлено в Java7, обновление 8 (текущий выпуск - обновление 6).
Обратите внимание, что не существует обходного пути для параметров оболочки, потому что в Windows оболочка не обрабатывает расширение по шаблону. (В то время как в Unixes оболочка выполняет расширение).

user1729234 27 июн '16 в 12:02 2016-06-27 12:02 · Answer 2 · 2016-06-27 12:02

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

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

user2485870 30 мар '22 в 15:18 2022-03-30 15:18 · Answer 3 · 2022-03-30 15:18

Я нашел общий обходной путь для проблемы Windows-Java-launcher-argument-wildcard-expansion:

Аргументы из @argfile не подвергаются расширению с помощью подстановочных знаков. Например

      java foo.Echo '*.txt'     => 1.txt 2.txt

echo "foo.Echo *.txt" >argfile
java @argfile             => *.txt

Итак, если у вас есть сценарий BASH-оболочки, вы можете сделать:

      argfile=c:/tmp/argfile$$;
echo foo.Echo "$@" >$argfile;
java @$argfile;

, и ваши аргументы командной строки не будут расширены программой запуска с помощью подстановочных знаков.

Протестировано с:

      adopt_openjdk_15+36_swm_cert_v3
adopt_openjdk-11.0.11.9-hotspot
adopt_openjdk-14.0.2_12-hotspot
adopt_openjdk-16.0.1.9-hotspot
jdk-13.0.2+8
jdk-17.0.1+12