- BASH и поведение возврата каретки
- Удалить возврат каретки в Unix
- Удаление \r в любой системе UNIX®:
- С sed :
- Разница между sed и tr :
- Тестирование:
- Как n и r обрабатываются по-разному в Linux и Windows?
- 3 ответов
- CR и LF
- зависимость от платформы
- \n и \r
- Программирование
- действовать до его закрытия в Unix
- текстовые файлы
- принтеры
- Разница между типами разрыва линии CR LF, LF и CR?
- 9 ответов
BASH и поведение возврата каретки
У меня есть один быстрый вопрос.
Это нормально, что bash (я использую 4.4.11) не отображает строки / текст, который отделен / заканчивается простым \r ?
Я был немного удивлен, увидев такое поведение:
Но текст «Привет снова» все еще там, как-то «спрятан»:
И как только мы просто поиграем с bash, это нормально . Но разве это потенциальный риск для безопасности? Что если содержимое переменной «а» пришло из внешнего мира и содержит «плохие команды», а не просто привет?
Еще один тест, немного ненадежный на этот раз:
Вообразите скрытое rm вместо скрытого ls .
То же поведение при использовании echo -e:
Это я что-то не так делаю .
Вы echo «$a» печатаете «привет», затем возвращаетесь к началу строки (что и \r делает), печатаете «снова», возвращаетесь снова, печатаете «джордж», снова возвращаетесь и переходите к следующей строке ( \n ). Это все совершенно нормально, но, как указывает Чепнер , это не имеет ничего общего с Bash: \r и \n интерпретируется терминалом, а не Bash (именно поэтому вы получаете полный вывод, когда отправляете команду od ).
Вы можете увидеть это лучше с
так как это оставит конец перезаписанного текста:
Вы не можете использовать это, чтобы скрыть команды, только, только их вывод (и только если вы можете быть уверены, что перезаписываете с достаточным количеством символов), если не используете, eval как вы показываете (но использование, eval как правило, не рекомендуется). Более опасным трюком является использование CSS для маскировки команд, предназначенных для копирования и вставки с веб-сайтов.
В мире Unix возврат каретки (обычно кодируемый как \r в языках программирования) является ничем не примечательным управляющим символом. Вы можете иметь возврат каретки внутри строки текста, как и любой другой символ, кроме перевода строки (также называемого переводом строки ), который отмечает конец строки.
В частности, в скрипте bash возврат каретки является обычным символом, составляющим слово, таким как буквы и цифры. Любой специальный эффект возврата каретки происходит из терминала, а не из оболочки.
Возврат каретки является управляющим символом . Когда вы печатаете его в терминал, вместо отображения глифа , терминал выполняет какой-то специальный эффект. Для возврата каретки специальный эффект заключается в перемещении курсора в начало текущей строки. Таким образом, если вы печатаете строку, которая содержит возврат каретки в середине, то эффект состоит в том, что вторая половина записывается поверх первой половины.
Некоторые другие управляющие символы имеют специальные эффекты: символ возврата на одну позицию перемещает курсор влево. Символ колокольчика заставляет терминал издавать звук или иным образом привлекать внимание пользователя. Экранирующий символ запускает экранирующую последовательность, которая может иметь все виды специальных эффектов.
Если вы выводите ненадежный вывод, вам нужно удалить или удалить управляющие символы. Не только возврат кареты, но и некоторые другие, в частности, спасательный персонаж, который может вызывать всевозможные негативные последствия. См. Может ли «кошение» файла представлять потенциальную угрозу безопасности? и как избежать атак escape-последовательности в терминалах? больше по теме.
Источник
Удалить возврат каретки в Unix
Какой самый простой способ удалить все возвраты каретки \r из файла в Unix?
Я буду считать , что вы имеете в виду возврат каретки ( CR , «\r» , 0x0d ) в концах строк , а не просто слепо в файле (вы можете иметь их в середине строки для всех я знаю). Используя этот тестовый файл только CR в конце первой строки:
dos2unix это путь, если он установлен в вашей системе:
Если по какой-то причине вам dos2unix это не доступно, то sed сделаем это:
Если по какой-то причине вам sed это недоступно, то ed сделаем это сложным образом:
Если на вашем компьютере не установлено ни одного из этих инструментов, у вас есть большие проблемы, чем при попытке конвертировать файлы 🙂
Самый простой способ для Linux, по моему скромному мнению,
В сильных кавычках вокруг оператора подстановок ‘s/\r//’ являются существенными . Без них оболочка будет интерпретироваться \r как escape + r, уменьшать ее до простого r и удалять все строчные буквы r . Вот почему ответ, данный Робом в 2009 году , не работает.
А добавление /g модификатора гарантирует, что \r будет удалено даже многократное число , а не только первое.
Существует утилита dos2unix, которая существует во многих системах и может быть легко установлена в большинстве систем.
sed -i s/\r// или что-то подобное; увидеть man sed или множество информации, доступной в Интернете, относительно использования sed .
Следует отметить одно точное значение слова «возврат каретки» в приведенном выше; если вы действительно имеете в виду один управляющий символ «возврат каретки», то приведенная выше схема верна. Если вы имели в виду, в более общем смысле, CRLF (возврат каретки и перевод строки, то есть, как переводы строк реализованы в Windows), то вы, вероятно, хотите заменить \r\n вместо этого. Голые строки (новая строка) в Linux / Unix есть \n .
Если вы являетесь пользователем Vi, вы можете открыть файл и удалить возврат каретки с помощью:
Обратите внимание, что вы должны набрать ^ M, нажав Ctrl-V, а затем Ctrl-M.
Еще раз решение . Потому что всегда есть еще один:
Это приятно, потому что он работает и работает в каждом варианте Unix / Linux, с которым я работал.
Кто-то еще рекомендует, dos2unix и я настоятельно рекомендую это также. Я просто предоставляю больше деталей.
Если установлено, перейдите к следующему шагу. Если он еще не установлен, я бы рекомендовал установить его через yum :
Тогда вы можете использовать его как:
Если вы используете ОС (например, OS X), у которой нет dos2unix команды, но есть интерпретатор Python (версия 2.5+), эта команда эквивалентна dos2unix команде:
Это обрабатывает как именованные файлы в командной строке, так и каналы и перенаправления, как dos2unix . Если вы добавите эту строку в файл
/ .bashrc (или эквивалентный файл профиля для других оболочек):
. при следующем входе в систему (или запуске source
/.bashrc в текущем сеансе) вы сможете использовать dos2unix имя в командной строке так же, как и в других примерах.
%0d символ возврата каретки Сделать его совместимым с Unix. Нам нужно использовать приведенную ниже команду.
dos2unix fileName.extension fileName.extension
Попробуйте это преобразовать файл DOS в файл Unix:
Для UNIX . Я заметил, что dos2unix удалил заголовки Unicode из моего файла UTF-8. В git bash (Windows) следующий скрипт, похоже, работает хорошо. Он использует sed. Обратите внимание, что он удаляет только возврат каретки на концах строк и сохраняет заголовки Unicode.
Если вы работаете в среде X и имеете соответствующий редактор (код Visual Studio), я бы следовал рекомендациям:
Просто перейдите в правый нижний угол экрана, код Visual Studio покажет вам как кодировку файла, так и соглашение об окончании строки, за которым следует файл, простым щелчком мыши вы можете переключить его.
Просто используйте визуальный код в качестве замены для notepad ++ в среде Linux, и все готово.
Удаление \r в любой системе UNIX®:
Большинство существующих решений в этом вопросе специфичны для GNU и не будут работать на OS X или BSD; приведенное ниже решение должно работать на многих других системах UNIX, и в любой оболочке, от tcsh до sh , но по- прежнему работать даже на GNU / Linux, тоже.
Протестировано на OS X, OpenBSD и NetBSD в tcsh и на Debian GNU / Linux в bash .
С sed :
В tcsh на OS X, следующий sed фрагмент кода может быть использована вместе с printf , так как ни , sed ни echo ручки \r особым способом , как ГНУ делает:
Разница между sed и tr :
Казалось бы, что tr сохраняет отсутствие завершающей новой строки из входного файла, тогда как sed в OS X и NetBSD (но не в OpenBSD или GNU / Linux) вставляет завершающую новую строку в самом конце файла, даже если во входных данных отсутствует какой-либо в конце \r или \n в самом конце файла.
Тестирование:
Вот несколько примеров тестирования, которые можно использовать, чтобы убедиться, что это работает в вашей системе, используя printf и hexdump -C ; в качестве альтернативы, od -c может также использоваться, если ваша система отсутствует hexdump :
Я использовал Python для этого, здесь мой код;
Хотя это старый пост, недавно я столкнулся с той же проблемой. Поскольку у меня были все файлы для переименования внутри / tmp / blah_dir /, так как каждый файл в этом каталоге имел символ «/ r» (в конце файла был символ «?»), Так что делать это способом сценария было только для меня.
Я хотел сохранить окончательный файл с тем же именем (без конечного символа). С sed проблема была в имени выходного файла, которое мне было необходимо, чтобы упомянуть что-то еще (чего я не хотел).
Я пробовал другие варианты, как предложено здесь (не считал dos2unix из-за некоторых ограничений), но не работал.
Наконец, я попытался с «awk», который работал, где я использовал «\ r» в качестве разделителя и взял первую часть :
Хитрость заключается в следующем:
Ниже приведен фрагмент сценария, который я использовал (где у меня все файлы имели «\ r» в качестве завершающего символа в пути / tmp / blah_dir /), чтобы исправить мою проблему:
Примечание: этот пример не очень точен, хотя и близок к тому, что я работал (упомяну здесь, чтобы дать лучшее представление о том, что я сделал)
Источник
Как n и r обрабатываются по-разному в Linux и Windows?
Я думаю n двигает иглу вниз, и r перемещение стрелки в начало строки (выравнивание по левому краю)? Я не уверен, однако. Так что, если я ошибаюсь, пожалуйста, поправьте меня.
во всяком случае, мне сказали, что Windows и Linux обрабатывают newlines и carriage returns по-разному. Я хотел бы знать, как они справляются с ними по-разному и в некоторых местах, где важно помнить. Спасибо за ответ.
3 ответов
Я думаю, что \ n перемещает иглу вниз, а \ r перемещает иглу в начало строки (выравнивание по левому краю)? Я не уверен, хотя
Это правда, более или менее, но в основном исторический курьез. Первоначально, перевод строки (LF) был использован для того чтобы выдвинуть бумагу одной линией на принтерах и стержнях печатной копии (телетайпов); возврат каретки (CR) возвратил печатающую головку в начало строки.
Это, вероятно, все еще работает на современных принтерах при использовании в «текстовом режиме», но в остальном не имеет большого значения сегодня.
во всяком случае, мне сказали, что Windows и Linux обрабатывают новые строки и каретку возвращается по-другому.
разница Просто: разработчики ОС должны были выбрать, как представить начало новой строки в тексте в компьютерных файлах. По различным историческим причинам в мире Unix/Linux в качестве маркера перевода строки был выбран один символ LF; MS-DOS выбрала CR+LF, а Windows унаследовала этот. Таким образом, разные платформы используют разные соглашения.
на практике, это становится все меньше и меньше проблем. Маркер новой строки действительно актуален только для погромов, которые обрабатывают «обычный текст», и их не так много — он в основном влияет только на исходный код программы, файлы конфигурации и некоторые простые текстовые файлы с документацией. В настоящее время большинство программ обработки этих видов файлов (Редакторы, компиляторы и т. д.) может обрабатывать оба соглашения о новой строке, поэтому это не имеет значения какой из них вы выберете.
есть некоторые случаи, когда инструменты настаивают на «своем» соглашении о новой строке (например, сценарии оболочки Unix не должны использовать CR+LF), и в этом случае вы должны использовать правильный.
CR и LF
американский стандартный код для обмена информацией (ASCII) определил управляющие символы, включая возврат каретки (CR) и перевод строки (LF), которые использовались (и все еще используются) для управления положением печати на принтерах способом, аналогичным механическим пишущим машинам, которые предшествовали ранним компьютерным принтерам.
зависимость от платформы
в Windows традиционную линию-разделитель в текстовых файлах следует КЛ ЛН
In старые (до OSX) системы Apple Macintosh традиционным разделителем строк в текстовых файлах был CR
в Unix и Linux традиционным разделителем строк в текстовых файлах является LF.
\n и \r
во многих языках программирования и сценариев \n означает «новая линия». Иногда (но не всегда) это означает символ перевода строки ASCII (LF), который, как вы говорите, перемещает курсор (или позицию печати) вниз на одну строку. В принтере или на пишущей машинке, можно бумага поднялась на одну строчку.
всегда \r означает символ возврата каретки ASCII (CR), название которого на самом деле происходит от механических пишущих машинок, где был ключ возврата каретки, из-за которого ролик («каретка»), который нес бумагу, чтобы двигаться вправо, питание от пружины, насколько это будет идти. Таким образом, устанавливаем текущую позицию набора текста на левое поле.
Программирование
в некоторых языках программирования \n может означать a зависящая от платформы последовательность символов, заканчивающихся или разделяющих строки в текстовом файле. Например в Perl, print «\n» создает другую последовательность символов в Linux, чем в Windows.
в Java, лучшая практика, если вы хотите использовать собственные окончания строк для платформы выполнения, не использовать \n или \r на всех. Вы должны использовать System.getProperty(«line.separator») . Вы должны использовать \n и \r где вы хотите LF и CR независимо от платформы (например, как используется в HTTP, FTP и других интернет коммуникационный протокол.)
действовать до его закрытия в Unix
в оболочке Unix stty команда может использоваться, чтобы заставить оболочку переводить между этими различными соглашениями. Например stty -onlcr заставит оболочку впоследствии перевести все исходящие LFs в CR LF.
Linux и OSX следуют соглашениям Unix
текстовые файлы
текстовые файлы по-прежнему чрезвычайно важны и широко используются. Например, HTML и XML примеры текстовый файл. Большинство важных интернет-протоколов, таких как HTTP, следуют соглашениям о текстовых файлах и содержат спецификации для окончаний строк.
принтеры
большинств принтеры за исключением очень самого дешевого, все еще уважают CR и LF. На самом деле они являются фундаментальными для наиболее широко используемых языков описания страниц — PCL и Postscript.
Источник
Разница между типами разрыва линии CR LF, LF и CR?
Я хотел бы знать разницу (с примерами, если это возможно) между типами разрыва строки CR LF (Windows), LF (Unix) и CR (Macintosh).
9 ответов
Это действительно только о том, какие байты хранятся в файле. CR — это байт-код для возврата каретки (со времен пишущих машинок) и LF аналогично, для линии подачи. Это просто относится к байтам, которые размещаются как маркеры конца строки.
больше информации, как всегда, на Википедия.
CR и LF являются управляющими символами, соответственно закодированными 0x0D (13 десятичных знаков) и 0x0A (10 десятичное).
Они используются для обозначения разрыва строки в текстовом файле. Как вы указали, Windows использует два символа последовательности CR LF; Unix использует только LF, а старый MacOS (pre-OSX MacIntosh) использовал CR.
апокрифическая историческая перспектива:
как отметил Петр, CR = Возврат Каретки и LF = Строки, два выражения имеют свои корни в старых пишущих машинках / TTY. LF переместил бумагу вверх (но сохранил горизонтальное положение идентичным), а CR вернул «каретку» так, чтобы следующий введенный символ был в крайнем левом положении на бумаге (но на той же строке). CR+LF делал и то, и другое, то есть готовился ввести новую строку. С течением времени физическая семантика кодов была неприменима, а поскольку память и дискетное пространство были в цене, некоторые ОС дизайнеры решили использовать только одного из персонажей, они просто не очень хорошо общались друг с другом 😉
большинство современных текстовых редакторов и текстовых приложений предлагают опции / настройки и т. д. это позволяет автоматически обнаруживать соглашение о конце строки файла и отображать его соответствующим образом.
это хорошее резюме, которое я нашел:
символ возврата каретки (CR) ( 0x0D , \r ) перемещает курсор в начало строки, не перейти к следующей строке. Этот символ используется в качестве нового символа строки в Commodore и ранних операционных системах Macintosh (OS-9 и более ранних).
символ подачи строки (LF) ( 0x0A , \n ) перемещает курсор к следующей строке, не возвращаясь к началу линии. Этот символ используется как новый символ строки в системах на базе UNIX (Linux, Mac OSX и т. д.)
конец строки (EOL) последовательности ( 0x0D 0x0A , \r\n ) на самом деле два символа ASCII, комбинация символов CR и LF. Он перемещает курсор как вниз к следующей строке, так и к началу этой строки. Этот символ используется в качестве нового символа строки в большинстве других операционных систем, отличных от Unix, включая Microsoft Windows, Symbian OS и другие.
поскольку нет ответа, заявляющего только это, кратко резюмировал:
Возврат Каретки (Mac pre-OSX)
Строки (Linux, MAC OSX)
возврат каретки и подача линии (Windows)
- CRLF
- \r\n
- ASCII код 13, а затем ASCII код 10
Если вы видите код ASCII в странном формате, это просто число 13 и 10 в другом радиксе/базе, обычно база 8 (восьмеричная) или база 16 (шестнадцатеричная).
у Джеффа Этвуда есть недавнее сообщение в блоге об этом:Великий Раскол Новой Линии
последовательность CR+LF была в общем использовании на многих ранних компьютерных системах приняла телетайпная машин, обычно ASR33, как консоль устройства, потому что эта последовательность была требуется разместить эти принтеры на начало новой линии. На этом системы, текст часто регулярно состоящий быть совместимым с этими принтеры, начиная с концепции устройства драйверы, скрывающие такие детали оборудования из приложения еще не было хорошо разработано; приложения должны были говорить прямо на телетайп и следовать конвенциям. разделение из двух функций скрыты факт, что печатающая головка не могла возвращение из крайнего правого начало следующей строки время одного персонажа. Вот почему последовательность всегда отправлялась с CR первый. На самом деле, это часто необходимо чтобы отправить лишние символы (лишние CRs или NULs, которые игнорируются) для дайте печатающей головке время перейти к левое поле. даже после телетайпов были заменены компьютерные терминалы с более высокими скоростями передачи данных, много работая системы по-прежнему поддерживаются автоматически отправка этих символов заполнения, для совместимость с более дешевыми терминалами это потребовало несколько раз символов для прокрутки экрана.
LF — ASCII код 10.
теоретически CR возвращает курсор в первую позицию (слева). LF подает одну строку, перемещая курсор на одну строку вниз. Вот как в старые времена вы управляли принтерами и текстовыми мониторами. Эти символы обычно используются для обозначения конца строк в текстовых файлах. В разных операционных системах используются разные соглашения. Как вы указали, Windows использует комбинацию CR/LF, а pre-OSX Mac использует только CR и так далее.
системы на основе ASCII или a совместимый набор символов, использовать если (Линия подачи, 0x0A, 10 в десятичном) или CR (возврат каретки, 0x0D, 13 в десятичном) индивидуально, или CR следовать LF (CR+LF, 0x0D 0x0A); Эти символы основаны на командах принтера: подача строки указано, что одна строка бумага должна подаваться из принтера, а каретка-возвращаться указано, что принтер перевозка должна возвратиться к началу течения линия.
печальное состояние «разделителей записей» или «линейных Терминаторов» является наследием темных веков вычислений.
теперь мы считаем само собой разумеющимся, что все, что мы хотим представить, является каким-то образом структурированными данными и соответствует различным абстракциям, которые определяют строки, файлы, протоколы, сообщения, разметку, что угодно.
но когда-то это было не совсем так. Применения встроенные характеры управления и прибор-специфическая обработка. Мозг-мертвые системы, которые требовали и CR, и LF просто не имели абстракции для разделителей записей или линейных Терминаторов. CR был необходим для того, чтобы заставить телетайп или видеодисплей вернуться в столбец один, а LF (сегодня, NL, тот же код) был необходим, чтобы заставить его перейти к следующей строке. Я думаю, идея сделать что-то другое, кроме сброса необработанных данных на устройство, была слишком сложной.
Unix и Mac фактически указали абстрагирование для конца линии, представьте себе это. К сожалению, они уточнили разные. (Unix, кхм, пришел первым.) И, естественно, они использовали код управления, который уже был «близок» к S. O. P.
поскольку почти все наше операционное программное обеспечение сегодня является потомком Unix, Mac или MS operating SW, мы застряли с линией, заканчивающейся путаницей.
NL, полученный из EBCDIC NL = x ’15’, который логически сравнивался бы с CRLF x’odoa ascii. это становится очевидным, когда physcally перемещение данных с мейнфреймов на сч. Coloquially (как только тайные люди используют ebcdic) NL был приравнен к CR или LF или CRLF
Источник