Vim: \ n против \ r
Я давно не использовал vim в системе Unix, но, насколько я помню, не было \ r, всегда было \ n.
Я использую gVim под окнами, и когда я использую поиск для символов новой строки, я использую \ n. Поиск \ r ничего не возвращает. Но когда я заменять символы, я должен использовать \ r. \ n дай мне ^ @
Кто-нибудь может объяснить, что здесь происходит?
Ответы 8
В unix, внутри vim, ^V + <enter> дает мне ^M, который является символом \r.
Кроме того, вы не можете найти \r внутри vim, если вы не укажете ему редактировать файл в двоичном режиме, то есть не использовать автоматический режим по умолчанию, в котором он автоматически определяет окончание строки. (он должен печатать [dos] в статусе.)
FWIW, если в вашем файле есть несколько строк, заканчивающихся на \ n, но других строк, заканчивающихся на \ r \ n, вы увидите символы ^ M. Вы можете получить микс, если кто-то отредактировал текстовый файл с помощью Windows.
Да, конечно, vim выберет то окончание строки, которое имеет смысл.
Я думаю, что проблема может заключаться в способе перевода строки в Windows и Unix. Формат для Unix - \ n (перевод строки), но для Windows - \ r \ n (возврат каретки, перевод строки).
У вас есть это в обратном направлении, UNIX делает \ n (что означает перевод строки), Windows выполняет \ r \ n (возврат каретки, перевод строки),
В Windows, если вы открываете файл в текстовом режиме, \ n интерпретируется как символы новой строки и перевода строки. Обычно это не относится к системам * nix.
vim немного возится с возвратом каретки (\ r) и новой строкой (\ n). Например, если вы работаете в Unix и vi показывает вам строки, заканчивающиеся на '^ M', потому что это текстовые файлы Windows, простой способ избавиться от них - ввести команду
:%s/^V^M/^V^M/g
Не похоже, что он должен что-то делать, но это так.
Поиск:
:set fileformat=unix
:set fileformat=dos
Это можно использовать на любой платформе для переключения на другую кодировку.
Я не понимаю, какое отношение формат EOL файла имеет к тому, как vim выполняет поиск / замену символов новой строки / возврата каретки.
Обычно вы устанавливаете формат файла соответствующим образом, и тогда вам не нужно беспокоиться о том, нужны ли символы возврата каретки, и, следовательно, не нужно их искать.
Я бы сказал, что это самое простое решение! Я отлично работаю для своего дела.
Похоже, вы спрашиваете о двух вещах. Одна проблема - это \r против \n, о которой уже говорили другие.
Другая проблема - это \n справа от замены. Если вы посмотрите на :h s/\n, там написано, что \n в заменяющей части замены вставляет <NUL> / <NL>, а НЕ новую строку.
Если вы выполните :%s/\n/\n/ и сохраните и откроете файл в шестнадцатеричном редакторе, все символы ^@ будут ASCII 0 (символы NUL). Почему разработчики Vim используют \n слева для конца строки и \n справа для NUL, мне непонятно. Но это конкретное поведение не имеет ничего общего с Windows и Unix.
Этот всегда меня поражает - я никогда не могу вспомнить, означает ли это \ r или \ n разные вещи при поиске и замене. Недавно (после того, как я действительно прочитал документацию и обнаружил, в чем разница), мне было полезно вспомнить, что NUL начинается с 'n'.
Несомненно, в выборе, который сделали дизайнеры, есть логика, но она тоже каждый раз сбивает меня с толку. Для меня было бы гораздо разумнее использовать \r(или \ n по вашему выбору) как при поиске, так и при замене. Использование s/\r/\r/n должно возвращать 1 вместо Pattern not found, а использование s/\n/\n ничего не меняет.
:%s/^V^M/^V^M/g
Точно так же следующее делает то же самое (я думаю), и его легче печатать.
:%s/\r/\r/g
За кулисами Vim использует \ r (возврат каретки) для сохранения конца строки (независимо от формата файла, который имеет значение только при чтении или записи файла). Vim использует \ n для представления NUL. Однако вы ищите EOL как \ n, но в замене \ n означает NUL. Это объясняется в: h sub-replace-sepcial. При поиске \ r будут найдены символы возврата каретки, которые не были частью EOL формата файла. Есть подробное объяснение в: h форматы файлов.
Вы должны изменить принятый ответ; Ответ Джонатана Леффера правильный, но не имеет отношения к вопросу.