Pull to refresh

Comments 34

В следующий раз поговорим о языке обработки данных awk
А какое отношение sed и awk имеют к bash? То ли автор оригинального текста просто напихал все в одну кучу для создания объема, то ли назвал статью неправильно.
UFO just landed and posted this here
для баш-скриптов на любую тему
Так и при чем тут bash? Написал бы — для шелл-скриптов. awk и sed безусловно — супер инструменты. Но это отдельные темы для отдельных статей. Привязывать их теме bash — только путать новичков. Иногда правильнее вовремя остановиться. imho.

Если в статьях про баш-скрипты писать только про bash builtins и ничего более, то они будут очень скудными и далёкими от реальности. Например, cat, ls и find — тоже внешние программы.

А вы замените слово bash в названии этой статьи на sh|ash|dash|zsh|ksh|csh|tcsh… на выбор. Ничего в самой статье не изменится, верно?

По поводу скудности — это зависит от подхода… К примеру. Автор этого цикла статей (как верно заметил ghostinushanka ) ничего не написал про globbing вообще и extended globbing в bash в частности. Вот уж совсем не скудная и близкая к реальности тема.

Так "bash scripting" — это название всего цикла. Это стандартная практика пихать в книги/циклы статей сопутствующий материал, только косвенно относящийся к тематике, просто указывая во введении что-то типа: "Если вы, в bash-скриптах, каким-то образом обрабатываете данные, вам не помешает знакомство с инструментами sed и gawk".

Sed и Awk безусловно супер инструменты, но только к башу они отношения не имеют никакого.
Оба являются язык программирования и посему не имеет значения из какого шелла они вызывается, ровно как и скрипты на python/perl/ruby/[insert your preferred language].
С таким же успехом эту статью можно было назвать «часть 7: perl и обработка текстов» и точно так же скармливать ему текст.

Когда мы говорим о bash программировании и обработке текстов, мы говорим в первую очередь о parameter expansion. И во многих случаях не надо ничего «извне».

Посему согласен с redfs

Edit:
Чесслово не подглядывал когда писал фразу «Sed и Awk безусловно супер инструменты»

Вообще, скорее, потоковые редакторы. sed, например, — Stream EDitor. Но они на столько мощные, что уже можно и программировать. Вот, например, Тетрис.
К bash, конечно, же они прямого отношения не имеют.

Спасибо за ссылку на прекрасную статью про parameter expansion и супер сайт

По теме же поста — я бы еще флаг -i упомянул: открыть файл, провести редактирование, результат записать в тот же файл.

Как он с симлинками работает знаете? Я б не рекомендовал его использовать в общем случае без осознания связанных проблем.

sed -i.bak '/text/s/patern1/patern2/' file
Найти в файле строку с text, произвести замену по шаблону, сохранить старый файл как file.bak

По-моему, почти никто не использует sed и awk вне контекста bash (или другого shell). Так что я особого противоречия не вижу. Bash без утилит типа grep/sed/awk получается довольно ограниченным инструментом, ценность которого невелика.

Я вот ImageMagick тоже из под bash запускаю. И gcc. И ssh… :)
И при этом не понимаете разницы между bash и bash-скриптом. :)
Даже так?

find -iname \*.bmp|xargs -l1 -i% convert "%" "%.png"


Это был bash или bash-скрипт? :)
:)

Вот, Вы уже, как писали выше, запускаете ImageMagick из под bash. И gcc. И ssh. А, судя по вопросу, «плывёте» в элементарных вещах. Но не беда, я с удовольствием помогу Вам найти ответ на поставленный вопрос.

То, с чем Вы хотите разобраться — это команда для командной оболочки Unix Shell, такой как, например, bash (но не обязательно только для неё), которую (команду) она (оболочка) интерпретирует. Оболочка может делать это (интерпретировать команду) непосредственно из командной строки или (внимание!) из файла, представляющего собой скрипт командной оболочки.

Ответ на вопрос о том, сможет ли командная оболочка правильно интерпретировать указанную Вами команду, зависит от настройки Вашей системы и окружения. У Вас, например, может быть не установлен ImageMagick, или он установлен, но окружение, в контексте которого команда будет интерпретироваться, может ничего не знать о ImageMagick (по разным причинам).

Думаю, теперь Вы сами легко сможете ответить на поставленный Вами вопрос. Надеюсь, я смог Вам помочь.

;)
Не каждый может коротко и ясно ответить на простой и понятный вопрос. Вернее, может, но не каждый. :)
Все же, та конструкция выше — это, по вашему, bash или bash-скрипт?
:)

Не каждый может в дискуссии услышать ясный ответ собеседника на простой и понятный вопрос. Вернее, может, но не каждый. :)

(Подсказка: второй абзац текста моего ответа.)

;)
Есть такая DoS атака, dns amplification. Когда на короткий вопрос приходит длииинныый ответ. ;)
Есть такая логическая ошибка, называется «Мнимая логическая связь». Это когда ЖЕЛАЕМАЯ логическая связь выдаётся за истинную. Например, на КОРОТКИЙ вопрос должен быть только КОРОТКИЙ ответ. ;)
Хорошие ответы, как правило, короче вопросов. 42 например :)
Оболочка может делать это (интерпретировать команду) непосредственно из командной строки или (внимание!) из файла, представляющего собой скрипт командной оболочки.

Вообще говоря, вы сами или путаетесь или не до конца понимаете, о чём пишете.

Начать с того, что в unix — всё файлы. Даже «командная строка» (как вы говорите).
Поэтому нет никакой принципиальной разницы, откуда шелл получает команды — из командной строки или из файла — для него это одно и то же.

С этой точки зрения пример выше — обычный скрипт использующий фильтр к потоку вывода.
Вообще говоря, вы сами или путаетесь или не до конца понимаете, о чём пишете.

Судя по тому, что для доказательства своего утверждения (Ваше цитата выше), Вы привели следующую мою цитату:
Оболочка может делать это (интерпретировать команду) непосредственно из командной строки или (внимание!) из файла, представляющего собой скрипт командной оболочки.

правильно ли я понимаю, что Вы с этим моим утверждением не согласны и считаете его неправильным? Ну, тогда расскажите, пожалуйста, что неправильного в приведённом Вами моём утверждении, с которым Вы не согласны.

Я, в свою очередь, в приведённой Вами моей цитате не вижу утверждения о том, что для шелла есть принципиальная разница откуда получать команды. Наоборот, там как раз и говорится, что ему без разницы, откуда команды принимать: может от сюда, а может от туда — для него это одно и тоже.

Но, как и из моей приведённой Вами цитаты, так и из уже Вашей следующей цитаты:
Поэтому нет никакой принципиальной разницы, откуда шелл получает команды — из командной строки или из файла — для него это одно и то же.

мы можем сделать вывод, что шелл может получать команды из множества РАЗНЫХ мест. ("… нет никакой принципиальной разницы, откуда шелл получает команды...").

Так вот, bash-скрипт — это ВСЕГО ЛИШЬ одно из множество мест, ОТКУДА шелл получает команды. Причём место конкретное — КОМАНДНЫЙ файл.

Да, в unix всё — суть файлы. Но согласитесь, файлы-то могут быть разными. Например, есть бинарные, есть текстовые. Не из всех unix-файлов шелл может команды получить. Иначе мы можем прийти к выводу, что все в unix — суть скрипты шелла.

Не кажется ли Вам, что всё-таки это Вы:
… или путаетесь или не до конца понимаете, о чём пишете.
Как Вы думаете:
— bash и bash-скрипт — суть одно и тоже или нет?
— используется ли в bash-скриптах sed и awk?
— если в bash-скрипте используется sed и/или awk, остаётся ли он bash-скриптом или нет?
— bash и bash-скрипт — суть одно и тоже или нет?
Нет.
— используется ли в bash-скриптах sed и awk?
Может использоваться. Может не использоваться.
— если в bash-скрипте используется sed и/или awk, остаётся ли он bash-скриптом или нет?
Хм. В скрипте bash могут использоваться вызовы практически любых команд и программ, включая sed и awk. Если это скрипт bash, то он останется скриптом bash, перловкой он точно не станет.

Задавайте основной вопрос, можно без вступительной риторики :)
Основной вопрос — первый. :)
При необходимости вывод sed можно перенаправить в файл, возможно — перезаписать старый файл


Хм. Я бы такого не советовал.

В данном случае в качестве разделителя использован восклицательный знак


В зависимости от того, в каких кавычках будет команда для sed (одинарные/двойные) — оно сработает по разному. Символы, которые bash интерпретирует по своему, лучше так не использовать.

Видимо, у ruvds дела идут столь хорошо, что промокод стал появляться в статье по два раза. И основная задача этого набора статей — публикация этого промокода и ссылки на свой сервис, а не публикация полезного материала, что, конечно, ожидаемо, но несколько печально.

В нашем случае применена команда вида s/pattern1/pattern2/. Буква «s» — это сокращение слова «substitute», то есть — перед нами команда замены. Sed, выполняя эту команду, просмотрит переданный текст и заменит найденные в нём фрагменты (о том — какие именно, поговорим ниже), соответствующие pattern1, на pattern2.

Вводит читателя в заблуждение. Если посмотреть sed(1), то там эта операция описана так: s/regexp/replacement/, что соответствует реальности. Таки s/// заменяет не на другой pattern/regexp, а на replacement string, в котором могут использоваться подстановки на основе capture group.


Но какое отношение имеет sed к bash мне тоже не очень понятно. Так можно в статьях про баш и perl/ruby/python обсуждать.

Для оформления правила обработки текста, заключённого в кавычки, используются прямые слэши

в качестве разделителя необязательно использовать слеши
$ echo 1214 | sed -e 's[1[5[g'
5254

К счастью, sed позволяет нам самостоятельно задавать символы-разделители для использования их в команде замены. Разделителем считается первый символ, который будет встречен после s:
$ sed 's!/bin/bash!/bin/csh!' /etc/passwd

При необходимости вывод sed можно перенаправить в файл, возможно — перезаписать старый файл.

wc -l .xsession-errors.old
#9165 .xsession-errors.old
sed 's/Indirect/REDIRECT/g' .xsession-errors.old > .xsession-errors.old
#
cat .xsession-errors.old
#
wc -l .xsession-errors.old
#0 .xsession-errors.old

А если бы я был новичком, а это был боевой конфиг?) Опять учите плохому.

Ваш пример к сожалению не обьясняет сути граблей (а это на мой взгляд самое важное).
Кому интересно — я уже писал почему это произойдёт вот тут.
Sign up to leave a comment.