Вышла версия 1.8 построчного текстового редактора ed

Мощный changelog, ничего не скажешь.

ну, существенный, это точно.

Починили баг, когда он знак вопроса выдавал в ответ на любую введенную последовательность символов?

Починили баг, когда он знак вопроса выдавал в ответ на любую введенную последовательность символов?

Как повторить?

А вообще ed не нужен, есть sed.

А вообще ed не нужен, есть sam.

Fixed.

Ну, теперь венда обречена.

ох, его еще и разрабатывают. я-то думал, что туда лет 10 никто не смотрел.

Ну кагбэ

some@test ~> ed
a
hello wor^Wlinux.org.ru
.

?
w test.txt
24
q
some@test ~> cat test.txt 
hello wor^Wlinux.org.ru

Как повторить?

Вводишь любую последовательность символов.

К.О.

Я джва года этого ждал! Лучший редактор на свете стал ещё лучше!

А вообще ed не нужен, есть perl.

Fixed.

ещё раз починил

Зачем нужен такой редактор до сих пор? Даже на допотопный системах на КР580ВМ80 с 16КБ памяти были более человеческие редакторы. Кроме скриптов, для которых тоже есть инструменты получше.

А вообще, perl не нужен, есть python.

А вообще, компьютеры не нужны.

Ну, вдруг у кого-то есть машина послабее, чем КР580ВМ80. Им-то и пригодится.

Рядом с новостью о Left 4 Dead смотрится весьма гармонично...

Вот ты смеёшся, а я им иногда пользуюсь. ☺

Даже на допотопный системах на КР580ВМ80 с 16КБ памяти были более человеческие редакторы.

Какие это?

Зачем нужен такой редактор

Мелкие правки вносить удобно — если точно знаешь что где надо поправить, например раскомментировать 16ю строку:

% ed /etc/somefile.conf
16s/^#//p
wq

И скрипты правки писать. (пример)

% ed /etc/somefile.conf
16s/^#//p
wq

Чем это лучше

sed -i '16s/^#//'

Зачем нужен такой редактор до сих пор?

Он нужен svu, чтобы его не забанили наверное.

Cool story, bro.

А если ввести q?

Вводишь любую последовательность символов.

Не повторяется.

У меня повторяется.

да, какой-то такой батхерт у меня был при crontab -e в солярке

Тем лучше, что sed создаёт временный файл, а ed редактирует на месте. В случае очень больших файлов получается значительная разница в производительности.

Мелкие правки вносить удобно — если точно знаешь что где надо поправить, например раскомментировать 16ю строку:

А можно узнать, когда возникает такие ситуации, когда знаешь, где и что нужно поправить, но это почему-то раньше не было поправлено?

sed создаёт временный файл, а ed редактирует на месте

Да, так и есть. Благодарю, буду иметь в виду.

// Пока проверял, вспомнил про ex(1) и про способность vim работать как ex

Тем лучше, что sed создаёт временный файл, а ed редактирует на месте. В случае очень больших файлов получается значительная разница в производительности.

Это чисто теоретическая ситуация, или приходится работать с очень большими текстовыми файлами, где точно знаешь, что и где нужно поправить?

Тем лучше, что sed создаёт временный файл, а ed редактирует на месте. В случае очень больших файлов получается значительная разница в производительности.

Про ключ -i для sed не слышали?

Чем оно лучше vim'а?

Про ключ -i для sed не слышали?

А про inotifywait слышали, чтобы проверить?

pwd
/home/user/tempdir
echo "blah" > text.txt

В соседней вкладке терминала

inotifywait -m -r tempdir/

sed -i "s/bla/xxx/g" text.txt

И читаем вывод inotifywait

Watches established.
tempdir/ OPEN text.txt
tempdir/ CREATE sedU4SuRI
tempdir/ OPEN sedU4SuRI
tempdir/ ACCESS text.txt
tempdir/ MODIFY sedU4SuRI
tempdir/ ATTRIB sedU4SuRI
tempdir/ ATTRIB sedU4SuRI
tempdir/ CLOSE_NOWRITE,CLOSE text.txt
tempdir/ CLOSE_WRITE,CLOSE sedU4SuRI
tempdir/ MOVED_FROM sedU4SuRI
tempdir/ MOVED_TO text.txt

Обратите внимание на CREATE sedU4SuRI.
Создаётся временный файл sedU4SuRI.

Можно проще сделать — ls -i показывает inode, при редактировании через sed он меняется.

Он.

ed редактирует на месте.

А как в файл вставить в POSIX один байт за o(1)?

А как в файл вставить в POSIX один байт за o(1)?

Если байт в конце — просто дописать, если ближе к середине — уже сложнее.

А можно узнать, когда возникает такие ситуации, когда знаешь, где и что нужно поправить, но это почему-то раньше не было поправлено?

Достаточно часто, к тому же можно номер строки и не знать. В ed можно как в полноценном редакторе писать, просто не всегда удобно.

У меня по двойному ^D выходит.

У меня постоянно такое.

Оно не пикает.

Он вообще для чего-нибудь полезного используется?

Тем лучше, что sed создаёт временный файл, а ed редактирует на месте. В случае очень больших файлов получается значительная разница в производительности.

Гигабайтными текстовыми файлами ворочаешь? :)

А если серьёзно, то как раз подход с временным файлом лучше, так как обеспечивает транзакционность редактирования — в случае преждевременного завершения работы (падение, ^C или ещё чего) sed оставит оригинальный файл нетронутым, а ed превратит его в недоотредактированный мусор.

Миллионы внимательных глаз... Каждая программа делать одну задачу и делает это ХОРОШО ... ага сейчааззз

Теперь осталось дождаться пока wc починят.

в случае преждевременного завершения работы (падение, ^C или ещё чего) sed оставит оригинальный файл нетронутым, а ed превратит его в недоотредактированный мусор.

Вообще-то в ed изменения применяются только по команде w

а ed редактирует на месте

Что за ed? Гнутый таки создает:

$ readlink /proc/`pidof ed`/fd/3                                                                                                                                                 
/tmp/tmpfgFzySg (deleted)

Размер чуть меньше исходного, без \n (видимо строит внутренний индекс адресов перевода строк).

Из plan9 создает какой-то индексированный файл (~2.5 толще). Sam в 4 раза больше (может, о юникоде беспокоится сильно).

Тут скорее: sed - не подходит для интерактивного использования, а vi - не всегда для больших файлов. Хотя интересно было посмотреть: ed vs «vi -u /dev/null --noplugin» на ваших use case.

в случае преждевременного завершения работы (падение, ^C или ещё чего) sed оставит оригинальный файл нетронутым, а ed превратит его в недоотредактированный мусор.

Вообще-то в ed изменения применяются только по команде w

Ну и что?

Возьмём твой пример с раскомментрированием строки. Сказал ты ed-у, из какой строки надо удалить символ, дал ему команду сохранить изменения. ed нашёл нужную строку, начал двигать оставшуюся часть файла на один символ влево. И где-то посреди этого процесса завершился из-за ошибки/^C/etc.. Результат — в файле «дыра» в виде лишнего символа, т.к. часть символов уже на новых (правильных) местах, а часть осталась на старых.

В случае с sed-ом при преждевременном закрытии просто останется неудалённый временный файл. Неприятно, но по сравнению с испорченным исходным файлом это ерунда.

Сказал ты ed-у, из какой строки надо удалить символ, дал ему команду сохранить изменения. ed нашёл нужную строку, начал двигать оставшуюся часть файла на один символ влево. И где-то посреди этого процесса завершился из-за ошибки/^C/etc.. Результат — в файле «дыра» в виде лишнего символа, т.к. часть символов уже на новых (правильных) местах, а часть осталась на старых.

Довольно маловероятная история. А вообще, кому что.

А вообще-то у меня нет гигабайтных файлов, а ed я больше использую потому что он как-то проще чем всякие там vi, кроме того для тормозящего подключения (когда-нибудь пользовались ssh через GPRS?) он по идее должен быть куда быстрее других редакторов.

Да есть временные файлы, так что плюс ed-а может быть только в интерактивности; xenuis-у еще sv75 выше мягко намекнул, что, «на месте» - прохладная история.

Ну, вдруг у кого-то есть машина послабее, чем КР580ВМ80. Им-то и пригодится.

Для начала им там придется запустить что-то *nix-like.