Emacs отображает управляющие символы.

Это и есть нормальный вид. BS - это такой же символ ASCII, как и все остальные. vi, кстати, также отображает.

Это и есть нормальный вид.

Этот нормальный вид не не дружит с конфигами например, есть ли способ передать вывод printf в уже интерпретированном терминалом виде?

BS - это такой же символ ASCII, как и все остальные.

LF ^J тоже символ как и все остальные, однако его не видно в конце каждой строки, в том числе и после printf '%b' 'string\nstring' > filename. В чем парадокс?

Тебе в прошлом топике пояснили, как на самом деле «интерпретируется терминалом» такой символ.

Если ты распечатаешь этот файл в консоль потом, то отобразится именно то, что ты хочешь увидеть. Никакой ошибки здесь нет.

Если ты хочешь видеть это в редакторе «в интерпретированном терминалом виде», то тебе нужен снимок консоли. Здесь поможет, например, screen.

А если ты таким образом пытаешься манипулировать строками (удалить последний символ одной из строк?), то тебе нужен sed.

в уже интерпретированном терминалом виде?

Конкретно ^H можно убрать с помощью `col -b' (только вход должен \n заканчивать, иначе последнюю строку может проглотить).

LF ^J тоже символ как и все остальные, однако его не видно в конце каждой строки

Тебе бы хотелось, чтобы редактируемый файл был одной строкой с внутренними ^J ?

А если ты таким образом пытаешься манипулировать строками (удалить последний символ одной из строк?), то тебе нужен sed.

sed во много раз медленнее встроенной в bash замены, подстановки, printf'а и т.п. потому и решил использовать printf, кстати sed даже медленнее awk в некоторых случаях.

Если ты хочешь видеть это в редакторе «в интерпретированном терминалом виде», то тебе нужен снимок консоли. Здесь поможет, например, screen.

Тот же emacs по умолчанию интерпретирует ^J, неужели нет функции что бы остальные управляющие символы интерпретировать. Прозреваю что с помощью screen будет еще медленнее чем с помощью sed, awk.

Конкретно ^H можно убрать с помощью `col -b' (только вход должен \n заканчивать, иначе последнюю строку может проглотить).

Благодарю.

Тебе бы хотелось, чтобы редактируемый файл был одной строкой с внутренними ^J ?

А тебе бы хотелось видеть через каждое слово ^H?

А тебе бы хотелось видеть через каждое слово ^H?

«Как бы» есть разница: интерпретация \n подразумевается «by-design», а ^H - пережиток прошлого, необходимости в нем нет (ну там в манах еще используется, но это не считается).

Ты не стараешься объяснить, ни где корень проблемы, ни в чем она. Если ты хочешь получить снимок терминала в текстовом файле со всеми последовательностями, то ничо не выйдет — терминал в общем виде может в цвета, жирность, подчеркивание, мигание, а простой текст не может (кроме как будучи выведенным в _этот терминал). Если эти последовательности ты сам генеришь и знаешь, что там может быть, а чего нет, то напиши свой автомат, который интерпретирует этот набор по нужным _тебе правилам, в т.ч. чтобы nul например удалял символ из строки, а не ставил пробел, если за ним идет lf, например. Либо сразу пиши «исходники» в подходящем виде — ed/sed/ex.

Emacs отоброжает filename как string^Hstring, это нормально?

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

sed во много раз медленнее встроенной в bash замены

Это не встоенная в bash замена, это управляющие символы терминала. Они предназначены исключительно для вывода на экран. Символ \b образабывается в драйвере терминала, а не в bash. Можете использовать утилиту вроде empty, чтобы сохранить результат такой обработки в файл.

Как вы измеряли скорость обработки текста на sed и замену в терминале? Вы уверены, что sed медленнее? Вы уверены, что вам важна эта скорость? Использовать терминал для такой задачи - это какое-то непотребство.

Это не встоенная в bash замена, это управляющие символы терминала.

Это я уже понял, просто хотелось обойтись без встроенной в bash замены ${///} и подстановки ${:} поверх printf дабы не плодить сущности, но так не получится.

Как вы измеряли скорость обработки текста на sed и замену в терминале?

В миллисекундах с помощью time, среднее время выполнения из 1000 например.

В миллисекундах с помощью time, среднее время выполнения из 1000 например.

Покажете тесты? Интересно.

Вот например, добавление строки с «string» в файл на 100 000 строк.
Если перед этим еще надо проверить файл на наличие строки, связка bash и grep быстрее чем sed.

{ [[ -s filename ]] && ! tail -c1 filename | read && printf \\n; printf string\\n; } >> filename

2ms

awk '{print}END{printf("string\n");}' filename > filename.$$ && mv filename.$$ filename

63ms

sed -i '$a string' filename

205ms

Спасибо.

Вот например, добавление строки с «string» в файл на 100 000 строк.

Не, я спрашивал про замену спец-символов в терминале vs sed. В приведенных тестах сравнивается, по сути, запись в конец файла vs sed, понятно, что первое быстрее. А какую задачу вы решаете, так что заморачиваетесь с этими миллисекундами?

Если перед этим еще надо проверить файл на наличие строки, связка bash и grep быстрее чем sed.

А на сколько быстрее вариант grep?

Не, я спрашивал про замену спец-символов в терминале vs sed.

Где-то sed наверное быстрее, зависит от конкретной задачи.

А какую задачу вы решаете, так что заморачиваетесь с этими миллисекундами?

Запись отформатированных данных в файл при их отсутствии, если это можно сделать быстрее в 25 раз, то почему нет?

А на сколько быстрее вариант grep?

sed -i '/^string$/ { :l; n; b l }; $a string' filename

Файл на 100 000 строк, без «string».
~257ms
Файл на 100 000 строк, с «string» посередине.
~231ms

grep -q ^string$ filename || { [[ -s filename ]] && ! tail -c1 filename | read && printf \\n; printf string\\n; } >> filename

Файл на 100 000 строк, без «string».
~10ms
Файл на 100 000 строк, с «string» посередине.
~6ms

Где-то sed наверное быстрее, зависит от конкретной задачи.

Так вот я не думаю, что быстрее.

Файл на 100 000 строк, без «string».
[...]

Ого, спасибо.