OS X имеет свой собственный формат строки?

В Вашем сценарии существует две ошибки. Прежде всего, Вам нужно пространство между ! и $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
7
09.11.2011, 00:45
2 ответа

На это нужно указать тот Mac OS X использование \n иначе перевод строки (0x0A) теперь, точно так же, как все другой *отклоняют системы. Только версии Mac OS 9 и более старый используемый \r (CR).

Ссылка: Википедия на новых строках.

14
27.01.2020, 20:14

jw013 указывает в другом ответе, что Mac теперь переключился на *, отклоняют стандарт \n.

Ранее, Mac OS был \r (возврат каретки, 13/0x0D); Windows \r\n, и *отклоняют, \n (перевод строки, 10/0x0A). Я не уверен для более неясных систем, но я предположил бы, что почти все остальное также \n. Различие прибывает со дней телетайпа когда \n переместился бы в следующую строку, и \r положил бы обратно голову к запуску (левая сторона) страницы, весьма схожей с тем, что нужно было сделать (вручную) с печатающим устройством назад в день. Обратите внимание на это в терминале на Linux, \r все еще перемещает курсор в начало текущей строки вместо того, чтобы спуститься к следующей строке, согласовывающейся с ее использованием телетайпа. Я видел более подробные истории на том, почему каждая система выбрала их собственные типы строки, таким образом, я уверен, что можно искать больше деталей.

Так или иначе, в практических вопросах, большинство редакторов (кроме блокнота) может иметь дело с любым из трех типов, и существуют многочисленные способы преобразовать между ними. Некоторые удаленные инструменты копии (ftp, например, и вероятно другие подобные программы) даже преобразовывают прозрачно в корректные типы строки для места назначения при переносе файлов в текстовом режиме. И я читал сегодня на ТАК post1, что gcc на самом деле преобразовывает \n к соответствующей строке, заканчивающейся для системы, это компилирует на.


¹ Кавычка:

Переменные конечные символы строки не имеют значения, предполагая, что файл открыт в текстовом режиме, который является тем, что Вы получаете, если Вы не просите двоичный файл. Скомпилированная программа выпишет корректную вещь для системы, скомпилированной для.

4
27.01.2020, 20:14
  • 1
    +1. можно ли совместно использовать ТАК ссылка Сообщения? –  Prince John Wesley 08.11.2011, 06:27
  • 2
    Вы имеете, это немного перепутало. В то время как Вы корректны, что Старый Mac использует '\r', Windows использует '\r\n', и Unix использует '\n' - описания и шестнадцатеричные коды, которые Вы дали, являются неправильными. '\r' является возвратом каретки 0x0d / 13, и '\n' является переводом строки 0x0a / 10. Ссылка: en.wikipedia.org/wiki/ASCII#ASCII_control_characters –  teambob 08.11.2011, 06:39
  • 3
    @Kevin, ничто, что Вы сказали в своем ответе, не было ложью, но это ни в коем случае не отвечало на вопрос, который был о OS X. –  Jeremy Visser 08.11.2011, 10:08
  • 4
    Вы все еще не полностью зафиксировали ошибку teambob, указал: 0x0A = 10 не то же как 0x10 = 16. То же с 0x13 не совпадение с 0x0D. –  jw013 08.11.2011, 21:14
  • 5
    я не соглашаюсь - Ваш ответ вводил в заблуждение. O.P. ясно спрашивал о "Mac" в контексте современных основанных на OS X машин. Для утверждения окончаний строки Mac \r, не разъясняясь, поскольку "Mac OS 9 и ранее" вводит в заблуждение. –  Jeremy Visser 12.11.2011, 17:15

Теги

Похожие вопросы