sed как текстовый редактор (отрезано от Что мешает переходу на Linux)

[diesel]

жду как минимум генерации на основе входного текста команды sed'а которая будет немедленно исполнена текущим экземпляром sed'а

ну вы поподробнее обрисуйте?
нужна команда самой sed?? вроде sed 'p'? или команда shell? я просто не очень понимаю, что вы хотите.

нужен sed, который формирует команду sed, которая тем же самым экземпляром sed'а исполняется Это единственный очевидный вариант, который будет делать "не просто запуск внешней команды, с текстом в качестве параметра". Если же единственное что имелось ввиду это формирование и исполнение внешней команды, то исполнением внешних команд никого не удивишь Хотя, для sed/awk я обычно это делаю без помощи sed/awk, а в perl/ruby/etc стараюсь обходится без вызова внешних команд.

Ленивая Бестолочь все правильно понял по поводу аналогии с LISP'ом

где же ходят фанатичные лисперы в такие минуты? :-)

да... LISP это сила. Однако, на практике, для написания простеньких одностроков он ИМХО не слишком удобен. На LISP надо писать такое, что не в код, а под стекло и в рамочку (:

а sed типа вашего листинга директорий - супер удобная штука если предполагается что написанное придется читать самому, или показывать другим - а это почти всегда - то sed за пределами //d; //s/// стараюсь не использовать(равно как и тарабарщину на perl) - сам же потом не разберусь.

[drBatty]

нужен sed, который формирует команду sed, которая тем же самым экземпляром sed'а исполняется

sed 's/^/sed /e' конечно же будет вызывать другую команду.

внешних команд никого не удивишь

согласен. для perl или там PHP это - норма. Как и для всех скриптовых языков. Однако, не думаю, что для тех, кто считает sed - тупым фильтром, это тоже норма.

а sed типа вашего листинга директорий - супер удобная штука

не думаю. ИМХО LISP это куда-то где нужна рекурсия, а вот тут-то её и нет. Точнее есть, но не в sed, она где-то в ls -R. sed получает уже линейный список, который и обрабатывает, ей в принципе всё равно, будет ли это
/
/ggg
/ggg/hh/h
/hh/j
/ddddd/dd/dd/f/
/f/

Либо просто список inode. Для sed удобнее строки, но если-бы то-же реализовалось на C, то я бы лучше взял список inode. Потому ут не надо не только рекурсии, но и вообще никаких функций, просто обработка списка(линейного, без вставок, замен и пр.).

sed за пределами //d; //s/// стараюсь не использовать(равно как и тарабарщину на perl) - сам же потом не разберусь.

спорно. в некоторых случаях sed - самое простое, а сл-но самое понятное. ИМХО.

ЗЫЖ Я пытался реализовать в sed рекурсию... Частично получилось. Я пришёл к выводу, что хотя это и возможно, но настолько жутко и уродливо, что совершенно не применимо на практике.

[diesel]

внешних команд никого не удивишь

согласен. для perl или там PHP это - норма. Как и для всех скриптовых языков. Однако, не думаю, что для тех, кто считает sed - тупым фильтром, это тоже норма.

про тупой или умный я не говорил, а так да - sed - может использоваться как фильтр, более того - очень часто он именно как фильтр и используется. Что кстати в духе того самого unix-way. В отличии от "все делаем sed'ом".

sed за пределами //d; //s/// стараюсь не использовать(равно как и тарабарщину на perl) - сам же потом не разберусь.

спорно. в некоторых случаях sed - самое простое, а сл-но самое понятное. ИМХО.

ЗЫЖ Я пытался реализовать в sed рекурсию... Частично получилось. Я пришёл к выводу, что хотя это и возможно, но настолько жутко и уродливо, что совершенно не применимо на практике.

угу, как я уже сказал - на практике sed за пределами d и s - сомнительной полезности штука

[drBatty]

про тупой или умный я не говорил, а так да - sed - может использоваться как фильтр, более того - очень часто он именно как фильтр и используется. Что кстати в духе того самого unix-way. В отличии от "все делаем sed'ом".

ну я изначально не предполагал "всё делать sed'ом"
то, что удобнее sed'ом - им, остальное - чем-то другим.

ЗЫЖ Я пытался реализовать в sed рекурсию... Частично получилось. Я пришёл к выводу, что хотя это и возможно, но настолько жутко и уродливо, что совершенно не применимо на практике.

угу, как я уже сказал - на практике sed за пределами d и s - сомнительной полезности штука

это почему это?!
то, что есть некоторые задачи для которых sed не предназначена, вовсе не ограничивает возможности теми 2м командами, которые вы освоили
вот пример: Как создать html страницу shell скриптом?
там чуть выше есть пример на bash, кривой только. кривой он вовсе не потому, что автор криворукий, просто сама задача(преобразовать текст) не предназначенна для bash, а вот sed неплохо сработала. Не думаю, что что-то может быть лучше. Например на C++ это тоже было-бы криво(отдельная утилита для такой простой задачи). может быть разве что на перле получилось-бы что-то подобное...
sed - это вовсе не фильтр, это язык программирования, для обработки текстов. Он идеально подходит для не слишком сложной обработки, в случае если задача уже достаточно сложная для применения стандартных фильтров(вроде grep или tail), но ещё недостаточно сложна, что-бы для решения писать специальную утилиту(например на том-же C++).

что касается UnixWay... что-то все утилиты принимают текст, и отдают текст, и практически все не понимают того, что отдают они сами. Например:
дана задача Z, которую можно разбить на 3 подзадачи Z1, Z2, Z3, причём у нас есть утилитки для решения этих подзадач A, B, C
Логично написать

Код: Выделить всё

A | B | C

что-бы каждая утилита выполнила свою подзадачу, вот только B требует данные от A вовсе не в том формате, который даёт A. И что делать? писать свою программу, которая заменяет A, B, C? очередной велосипед... проще написать

Код: Выделить всё

A|sed|B|sed|C

А может и

Код: Выделить всё

A|sed 's/.*/B &/e'|C

Вам так не кажется?

[minoru-kun]

что касается UnixWay... что-то все утилиты принимают текст, и отдают текст, и практически все не понимают того, что отдают они сами. Например:
дана задача Z, которую можно разбить на 3 подзадачи Z1, Z2, Z3, причём у нас есть утилитки для решения этих подзадач A, B, C
Логично написать

Код: Выделить всё

A | B | C

что-бы каждая утилита выполнила свою подзадачу, вот только B требует данные от A вовсе не в том формате, который даёт A. И что делать? писать свою программу, которая заменяет A, B, C? очередной велосипед... проще написать

Код: Выделить всё

A|sed|B|sed|C

А может и

Код: Выделить всё

A|sed 's/.*/B &/e'|C

Вам так не кажется?

Для начала, наверное, надо бы почитать маны постарательнее и убедиться, что утилиты действительно не обладают достаточными возможностями форматирования.

[drBatty]

Для начала, наверное, надо бы почитать маны постарательнее и убедиться, что утилиты действительно не обладают достаточными возможностями форматирования.

да?
в большинстве случаев и ман читать не обязательно, для того что-бы понять, что это невозможно. например
Нужна прога - если зашли как root, отсылает мне сообщение
ну и каким ключём мне заставить ps выполнять xmessage?
а ман читать конечно придётся. и не один а четыре(к A, B, C и к самой sed), т.ч. чтение манов я вовсе и не отменяю.

[ChAnton]

Для начала, наверное, надо бы почитать маны постарательнее и убедиться, что утилиты действительно не обладают достаточными возможностями форматирования.

да?
в большинстве случаев и ман читать не обязательно, для того что-бы понять, что это невозможно. например
Нужна прога - если зашли как root, отсылает мне сообщение
ну и каким ключём мне заставить ps выполнять xmessage?
а ман читать конечно придётся. и не один а четыре(к A, B, C и к самой sed), т.ч. чтение манов я вовсе и не отменяю.

Когда в свое время я пришел работать в РосНИИРос, в самом начале моей там работы, первое что заставили меня сделать, это выполнять ЛЮБУЮ задачу на sed)))) И потом я не пожалел.

[/dev/random]

в большинстве случаев и ман читать не обязательно, для того что-бы понять, что это невозможно. например
Нужна прога - если зашли как root, отсылает мне сообщение
ну и каким ключём мне заставить ps выполнять xmessage?

ps <...> | grep -q <...> && xmessage <...>

[drBatty]

Когда в свое время я пришел работать в РосНИИРос, в самом начале моей там работы, первое что заставили меня сделать, это выполнять ЛЮБУЮ задачу на sed)))) И потом я не пожалел.

жёстко. но полезно ИМХО.

ps <...> | grep -q <...> && xmessage <...>

можно весь код полностью? у меня не так всё просто

[/dev/random]

можно весь код полностью? у меня не так всё просто

while sleep 5; do ps aux | grep -q '^root .* [-/]\?\(bash\|sh\|su\)' && xmessage '--> ALERT <--'; done
Пойдёт?

ЗЫ я правильно понял, что оно должно быть неубиваемым?

[drBatty]

Пойдёт?

я то-же написал, потом замучился окошки закрывать, проще оказалось CTRL+ALT+BS
у меня ещё и проверяет есть-ли такое окошко. впрочем верю, можно и с grep. но... как я уже неоднократно говорил - можно, но только в простых случаях... в более сложных устанешь мануал читать, проще на sed пару букв добавить. и строчки более жуткие получаются. впрочем - дело вкуса.
в моём понимании - много мелких утилиток - это правильно, и очень удобно. особенно учитывая, что все они принимают текст и отдают текст. потому их можно связывать друг с другом в любых порядках и сочетаниях. только приходится текст между командами отфильтровывать. в grep только 1 вариант фильтра - регулярное выражение. sed даёт больше свободы:

• /RE/команда
• s/RE/.../
  T
  Команда
• s/RE/.../модификатор

т.о. мы можем использовать 3 варианта условий

[diesel]

в grep только 1 вариант фильтра - регулярное выражение. sed даёт больше свободы:

в grep как миниму 3 возможных варианта самих регулярных выражений: обычные, extended, и в некоторых сборках - перловые. к тому же grep можно использовать не только для поиска в конкретном файле, но и для рекурсивного поиска, при этом регулирование того что надо показывать: только файл в котором найдено; файл и совпадающую строчку; файл и то что найдено; только то что найдено и так далее. То есть это утилита специально созданная для поиска чего-то в файле(ах), которая это умеет делать хорошо и по всякому-разному. Вы, конечно, можете тут щас начать травить байки по поводу того что sed'ом это тоже все можно, и даже приводить какие-то скрипты на sed'е которые это все делают, заточенные под конкретную странную задачу.

Проблема в том что: для того чтобы заточить под другую задачу, скрипт на sed'е вам прийдется полностью или сильно переделать, чтобы соответствовать новым условиям, там где в grep'е мы просто поменяем один из аргументов.

[diesel]

то, что есть некоторые задачи для которых sed не предназначена, вовсе не ограничивает возможности теми 2м командами, которые вы освоили
вот пример: Как создать html страницу shell скриптом?
там чуть выше есть пример на bash, кривой только. кривой он вовсе не потому, что автор криворукий, просто сама задача(преобразовать текст) не предназначенна для bash, а вот sed неплохо сработала.

не-а скрипт на bash'е там в принципе нормальный, и нормальность здесь оценивается по одному единственному критерию: он работает и делает то что нужно было его автору. Более того: скрипт на bash'е гораздо более читаемый чем ваша строчка на sed'е, и человек, который с bash'ем на Вы, увидев его смог осознать как оно работает, и как ему переделать это для своих собственных нужд. В этот же самый скрипт на bash'е будет гораздо легче чего-нить добавить: например вывод еще какой-нить команды, чем в скрипт на sed'е.

Не думаю, что что-то может быть лучше. Например на C++ это тоже было-бы криво(отдельная утилита для такой простой задачи). может быть разве что на перле получилось-бы что-то подобное...

если оставь sed'у то чем он должен заниматься - замену - а работу с полями перенести в программу которая более умела в этом получится даже читаемее:

Код: Выделить всё

/sbin/ifconfig  | sed -e 's!^  *!\t!; s!    *!\t!' |
         awk 'BEGIN{print "<html><head><title>ifconfig</title></head><body>"; t=0; FS="\t"}
                 !/./{t=1}
                  /./{ if(t==1){print "</table><table>"; t = 0}; print "<td><tr>"$1"</tr><tr>"$2"</td></tr>" }
                 END{ print "</table></body></html>"}'

sed - это вовсе не фильтр, это язык программирования, для обработки текстов. Он идеально подходит для не слишком сложной обработки, в случае если задача уже достаточно сложная для применения стандартных фильтров(вроде grep или tail), но ещё недостаточно сложна, что-бы для решения писать специальную утилиту(например на том-же C++)..

фильтр - это ммм свойство программы, а sed - это не ЯП - это "Stream Editor" - так в man'е написано. Причем в самом понятии "Stream Editor" заложены "фильтрующие свойства" (:

что-бы каждая утилита выполнила свою подзадачу, вот только B требует данные от A вовсе не в том формате, который даёт A. И что делать? писать свою программу, которая заменяет A, B, C? очередной велосипед... проще написать

Код: Выделить всё

A|sed|B|sed|C

А может и

Код: Выделить всё

A|sed 's/.*/B &/e'|C

Вам так не кажется?

ну вот как раз здесь в первом случае sed будет заниматься вполне себе своим делом(и как раз таки в рамках s и d :-D), второй случай - лучше так не делать, если речь идет всего лишь о преобразовании формата входных данных. Просто потому что входные данные могут измениться, а искать B внутри sed'а и удалять лишнее, дольше, чем просто удалить sed из pipe'а.

[drBatty]

в grep как миниму 3 возможных варианта самих регулярных выражений: обычные, extended, и в некоторых сборках - перловые.

в sed 2: RE и ERE. про перловые сборки sed не слышал, впрочем это ИМХО лишнее, и для grep и для sed.

То есть это утилита специально созданная для поиска чего-то в файле(ах), которая это умеет делать хорошо и по всякому-разному. Вы, конечно, можете тут щас начать травить байки по поводу того что sed'ом это тоже все можно, и даже приводить какие-то скрипты на sed'е которые это все делают, заточенные под конкретную странную задачу.

могу конечно и примеры привести.
вот только не буду. Я прекрасно понимаю, что Вам быстрее набрать segrep с десятком ключей, но..
мне проще и быстрее это сделать на sed, просто я выучил(не такую уж и сложную) систему команд, а выучить все типы, виды, ключи, и сборки вашей grep мне всей жизни не хватит
проще набрать 10 символов, а если это кого-то напугает, то это уж не моя проблема

Проблема в том что: для того чтобы заточить под другую задачу, скрипт на sed'е вам прийдется полностью или сильно переделать, чтобы соответствовать новым условиям, там где в grep'е мы просто поменяем один из аргументов.

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

[drBatty]

Более того: скрипт на bash'е гораздо более читаемый чем ваша строчка на sed'е, и человек, который с bash'ем на Вы, увидев его смог осознать как оно работает, и как ему переделать это для своих собственных нужд. В этот же самый скрипт на bash'е будет гораздо легче чего-нить добавить: например вывод еще какой-нить команды, чем в скрипт на sed'е.

ну это говорит только о незнании и непривычности sed. так можно доказать и то, что BASIC лучше С++, или виндовс лучше Linux.

а работу с полями перенести в программу которая более умела в этом получится даже читаемее:

для вас...
для меня - не очень. не вижу особого смысла мешать sed и awk.

фильтр - это ммм свойство программы, а sed - это не ЯП - это "Stream Editor" - так в man'е написано. Причем в самом понятии "Stream Editor" заложены "фильтрующие свойства" (:

ну мало-ли...
sed это действительно потоковый редактор, который редактирует поток по заданным правилам. Фактически - ЯП. правила надо ведь как-то задавать? вы пытаетесь доказать мне то, что нет смысла в правилах сложнее примитивной замены. Это бесполезно, мне это нравится, и я вижу в этом смысл

ну вот как раз здесь в первом случае sed будет заниматься вполне себе своим делом(и как раз таки в рамках s и d :-D), второй случай - лучше так не делать, если речь идет всего лишь о преобразовании формата входных данных. Просто потому что входные данные могут измениться, а искать B внутри sed'а и удалять лишнее, дольше, чем просто удалить sed из pipe'а.

в первом случае не обязательно должно быть примитивное sed 's/ / /' постоянно этого не достаточно.
а во втором... если данные изменятся, то B внутри sed не выполнится, я не знаю, хорошо это или плохо, зависит от данных, и от того, как они меняются. часто это как раз то, что надо. С конвейером сложнее - тут B выполняется по любому, без условий. Это не всегда хорошо. Даже больше того - почти всегда плохо.
например:
есть текст, нужно провести операцию над числом оттуда
s/.*([0-9]+).*/B \1/e
найдёт число, и отдаст его B. Если числа нет - B не выполнится.
а вот s/.*[0-9]+.*/\1/, а потом уже B - приведёт к тому, что B получит кучу мусора. придётся добавлять всякие grep -q и прочее, для проверки этого... Это конечно для вас проще, но на самом деле - много букв, и всё равно всего вы не предусмотрите.

[diesel]

Более того: скрипт на bash'е гораздо более читаемый чем ваша строчка на sed'е, и человек, который с bash'ем на Вы, увидев его смог осознать как оно работает, и как ему переделать это для своих собственных нужд. В этот же самый скрипт на bash'е будет гораздо легче чего-нить добавить: например вывод еще какой-нить команды, чем в скрипт на sed'е.

ну это говорит только о незнании и непривычности sed. так можно доказать и то, что BASIC лучше С++, или виндовс лучше Linux.

да, это говорит о незнании и непривычности sed. но поскольку мы говорим в принципе о реальном мире и реальных задачах, то "незнание и непривычность" решения тоже нужно принимать во внимание, поскольку непонятный скрипт, на понимание которого уйдет много времени, может быть абсолютно бесполезным для тех кто его будет пытаться применить на практике: явно где-то глючит, но пока найдешь где... лучше новый написать

вы пытаетесь доказать мне то, что нет смысла в правилах сложнее примитивной замены.

ну изначально мы говорили о том что sed - это не замена WordPad'у :-D

приведёт к тому, что B получит кучу мусора. придётся добавлять всякие grep -q и прочее, для проверки этого...

это может так же говорить о неверном выборе B, да и о том что sed немного не то делает что надо(:

[drBatty]

да, это говорит о незнании и непривычности sed. но поскольку мы говорим в принципе о реальном мире и реальных задачах, то "незнание и непривычность" решения тоже нужно принимать во внимание, поскольку непонятный скрипт, на понимание которого уйдет много времени, может быть абсолютно бесполезным для тех кто его будет пытаться применить на практике: явно где-то глючит, но пока найдешь где... лучше новый написать

да. я с вами согласен.
просто обращу ваше внимание, что sed частенько встречается в других скриптах, в которых разбираться необходимо. причём часто там не только s/ / / , часто и другие команды проскальзывают...

ну изначально мы говорили о том что sed - это не замена WordPad'у :-D

смотря для чего применяется wordpad, если для того, что-бы каждый понедельник, в 7 утра поменять в каком-то файле строчки 23-45, так что-бы в них не было слов из строчки 713 - то sed мне кажется единственно верным решением

это может так же говорить о неверном выборе B, да и о том что sed немного не то делает что надо(:

конечно.