В Вашем сценарии существует две ошибки. Прежде всего, Вам нужно пространство между !
и $flag
, иначе оболочка ищет названную команду !$flag
. Вторая ошибка - это -eq
для целочисленных сравнений, но Вы используете его на строке. В зависимости от Вашей оболочки любой Вы будете видеть сообщение об ошибке, и цикл продолжится навсегда потому что условие [ "$x" -eq "true" ]
не может быть верным, или каждое значение нецелого числа будут рассматривать как 0, и цикл выйдет при вводе какой-либо строки (включая false
) кроме числа, отличающегося от 0.
В то время как ! $flag
корректно, это - плохая идея рассматривать строку как команду. Это работало бы, но это будет очень чувствительно к изменениям в Вашем сценарии, так как необходимо было бы удостовериться это $flag
никогда не может быть совсем не true
или false
. Было бы лучше использовать сравнение строк здесь, как в тесте ниже.
flag=false
while [ "$flag" != "true" ]
do
read x
if [ "$x" = "true" ]
then
flag=true
fi
echo "${x} : ${flag}"
done
Существует, вероятно, лучший способ выразить логику, которая Вы после. Например, Вы могли сделать бесконечный цикл и повредить его при обнаружении условия завершения.
while true; do
read -r x
if [ "$x" = "true" ]; then break; fi
echo "$x: false"
done
На это нужно указать тот Mac OS X использование \n
иначе перевод строки (0x0A
) теперь, точно так же, как все другой *отклоняют системы. Только версии Mac OS 9 и более старый используемый \r
(CR).
Ссылка: Википедия на новых строках.
jw013 указывает в другом ответе, что Mac теперь переключился на *, отклоняют стандарт \n
.
Ранее, Mac OS был \r
(возврат каретки, 13/0x0D); Windows \r\n
, и *отклоняют, \n
(перевод строки, 10/0x0A). Я не уверен для более неясных систем, но я предположил бы, что почти все остальное также \n
. Различие прибывает со дней телетайпа когда \n
переместился бы в следующую строку, и \r
положил бы обратно голову к запуску (левая сторона) страницы, весьма схожей с тем, что нужно было сделать (вручную) с печатающим устройством назад в день. Обратите внимание на это в терминале на Linux, \r
все еще перемещает курсор в начало текущей строки вместо того, чтобы спуститься к следующей строке, согласовывающейся с ее использованием телетайпа. Я видел более подробные истории на том, почему каждая система выбрала их собственные типы строки, таким образом, я уверен, что можно искать больше деталей.
Так или иначе, в практических вопросах, большинство редакторов (кроме блокнота) может иметь дело с любым из трех типов, и существуют многочисленные способы преобразовать между ними. Некоторые удаленные инструменты копии (ftp, например, и вероятно другие подобные программы) даже преобразовывают прозрачно в корректные типы строки для места назначения при переносе файлов в текстовом режиме. И я читал сегодня на ТАК post1, что gcc на самом деле преобразовывает \n
к соответствующей строке, заканчивающейся для системы, это компилирует на.
¹ Кавычка:
Переменные конечные символы строки не имеют значения, предполагая, что файл открыт в текстовом режиме, который является тем, что Вы получаете, если Вы не просите двоичный файл. Скомпилированная программа выпишет корректную вещь для системы, скомпилированной для.
0x0A
= 10
не то же как 0x10
= 16
. То же с 0x13
не совпадение с 0x0D
.
– jw013
08.11.2011, 21:14