Перейти к содержимому

Почему Windows преобразует оператор "= <" в "= 0 <"?

1

У меня есть следующий пакетный файл:

SET /P FOO=<"foo.txt" 

Это попытка прочитать содержимое foo.txtв переменную FOO, как предложено в разделе Как прочитать содержимое файла в переменную в пакетном файле? , Этот метод ранее работал хорошо для меня.

Когда я выполняю скрипт, я получаю следующий вывод:

SET /P FOO= 0<"foo.txt" 

Это не только ошибка отображения, значение не считывается в переменную. Почему это происходит? Как мне решить это?

Я вижу это на нескольких машинах, кажется, EOL или проблемы с кодировкой не являются источником.

145 просмотров
Der Hochstapler спросил 8 лет назад
D 66 934

2 ответа

3

Вы уверены, что это не работает? Я попытался повторить проблему, и вот что я получаю:

D:\>notepad test.bat //i've put SET /P FOO=<"foo.txt" inside it D:\>echo asdf > foo.txt D:\>test.bat D:\>SET /P FOO= 0<"foo.txt" D:\>echo %FOO% asdf D:\> 

Таким образом, он добавляет, 0<но все равно применяет данные из файла к переменной.

Да. Я уверен, что это не работает. «Не работающая» часть привела меня к этому расследованию.

Der Hochstapler · 8 лет назад · 0

Это означает, что, скорее всего, «неработающая» часть полностью откуда-то еще (например, кодировка файла foo.txt).

grawity · 8 лет назад · 0

Вы правы, по крайней мере, для Windows 7. (В настоящее время я не могу запустить этот тест на Windows 10).

Kamil Maciorowski · 8 лет назад · 0

@ Grawity Нет. Я могу воспроизвести это по желанию с любым файлом. Первоначальная проблема заключалась в том, что переменная не установлена. Если я копирую точную команду в CMD, тогда переменная * установлена ​​*. Хватит сомневаться во мне; P

Der Hochstapler · 8 лет назад · 0

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

Der Hochstapler · 8 лет назад · 0
darthzejdr ответил 8 лет назад
D 46
2

Ответ на первоначальный вопрос, как указал @grawity, =<- это всего лишь короткая форма = <0, которая отлично подходит для синтаксиса и фактически работает, как и ожидалось (после того, как вы проверите ее правильно ).

Так что в выводе нет ничего плохого, и это была просто красная сельдь, когда я исследовал другую проблему.

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

@ECHO OFF SETLOCAL SET TEST=Fail ECHO Pass>foo.txt  IF ERRORLEVEL 0 ( SET /P TEST=<foo.txt ECHO %TEST% ) 

Когда я запустил это, я ожидал, что вывод будет таким Pass, каким он должен был быть прочитан из foo.txt, но вывод есть Fail. Я подозревал, что это связано с «искаженным» синтаксисом.

Однако, как отметил @Joey, такое поведение связано с отложенным расширением .

Чтобы приведенный выше код работал, его нужно переписать так:

@ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION SET TEST=Fail ECHO Pass>foo.txt  IF ERRORLEVEL 0 ( SET /P TEST=<foo.txt ECHO !TEST! ) 

Читайте о отложенном расширении (help set), и вы поймете, почему ваш код не работает. Это никак не связано с оператором перенаправления. Добавьте еще один echo% TEST% после вашего оператора if, и вы получите Pass.

Joey · 8 лет назад · 0

@ Джои Я подозревал, что это связано с задержкой расширения. Однако, добавляя ECHO ** после **,` IF 'вроде бы сводит на нет то, что я хотел сделать со сценарием, не так ли?

Der Hochstapler · 8 лет назад · 0

Это показывает, что set / p работает правильно; Ваше предположение неверно.

Joey · 8 лет назад · 0

@ Джои Спасибо. Я поправил свой ответ. Я надеюсь, что получил это прямо сейчас: P

Der Hochstapler · 8 лет назад · 0
Der Hochstapler ответил 8 лет назад
D 66 934