Comments 63
Болезнь миллениалов: злоупотребление лишним cat:
cat multiline | awk .... вместо awk ... < multiline
Ну и надо бы знать хотя бы самые основы awk. Например, комбинировать его с grep чаще всего не нужно:
awk /needle/ { print "$12" }
Понимаю, что никто не может знать всего, и утилиты эти используются не так часто. Но в учебном материале стоило бы сразу учить правильно.
а зачем в команде awk ... < multiline перенаправление,
когда вполне себе работает awk ... multiline?
Болезнь миллениалов: злоупотребление лишним cat:
cat multiline | awk… вместо awk… < multiline
Объясню — стремновато выглядит.
Примерно как "> myfile": был myfile — и нет myfile.
Поэтому конструкция "awk… < multiline" выглядит так, как будто сейчас "..." будет прибито.
Нет, ну правда.
А так — цивильный конвейер, слева направо, всё нормуль.
Можно дальше что-нить прицепить без заморочек.
Мне почему-то не кажется. К тому же, в сети можно увидеть и другие примеры, например, cat /var/log/nginx.log | grep Firefox, потому что дурная привычка въедается в пальцы. А новички, например, читают 10-20 подобных статей, и им потом даже в голову не приходит, что правильно (или вообще возможно) писать иначе.
Оукей.
Покажите в правильном виде (с "<"):
sudo cat /var/log/messages | grep systemd | gawk '{print $6}' | lessТолько так, чтобы живому человеку было понятно кто кому Рабинович.
В данном случае — источник | команда | команда | ...
Исключение можно найти для любого правила. Большинство примеров, в т.ч. в этой статье, можно было написать без cat без потери читаемости.
К тому же, здесь опять же зачем-то awk комбинируется с grep — можно было сразу написать gawk '/systemd/ { print $6 }'.
можно было написать без cat
Можно. Пишите без cat, никто ж не запрещает.
Вам кота жалко, что ли? )
cat нужен там, где следующая утилита не работает с именем файла или не умеет несколько файлов (cat используется для конкатенации). Продолжайте пихать везде cat если вас не смущают конструкции вида
cat ... | grep ...
cat ... | awk ...
cat ... | wc
cat ... | cat ...
wtf ... | cat ...С другой стороны, это всё борьба тупоконечников с остроконечниками. Главное — результат.
не умеет несколько файлов (cat используется для конкатенации)
Для нескольких файлов можно использовать такую конструкцию:
command < file1 < file2Хотя команды, не умеющие работать с несколькими файлами, встречаются в повседневном использовании намного реже, чем умеющие.
Простите, но вы какую-то ерунду написали. В какой оболочке одновременное перенаправление двух файлов в stdin приведёт к их конкатенации?
######## bash
$ cat 1.txt
1content
$ cat 2.txt
2content
$ cat 1.txt 2.txt
1content
2content
$ cat < 1.txt
1content
$ cat < 2.txt
2content
$ cat < 1.txt < 2.txt
2contentДа, вы правы, моя ошибка. Где-то видел подобную конструкцию, но видимо неправлильно ее понял.
В какой оболочке одновременное перенаправление двух файлов в stdin приведёт к их конкатенации?
В zsh с включенным multios.
ох ты ж. Век живи, век учись.
Как выглядит исключение из правила "всегда используй cat и пайпай потом его во что нужно для задачи"?
sudo grep systemd /var/log/messages | gawk '{print $6}' | lessЯ терпеть не могу перенаправления, но многое работает и вот так.
Захочется искать не только в messages, но messages.1.gz — тут cat и пригодится.
sudo ( zcat messages.1.gz | cat messages -) | grep ...
А в чем проблема с useless cat? Экономия 2 символов? ;)
Когда надо — тогда надо. Но когда это часть большого скрипта плодить процессы может быть неидеальной идеей.
Вывод адреса IPv4, связанного с сетевым интерфейсом:
ip ad |awk '/inet / {print $2}'
ifconfig — это уже несколько устарело (мало того! встречался с ситуациями, когда ip ad показывал интерфейс/адрсес, а ifconfig — нет, а вот обратного не видел. Но утверждать, что обратного быть не может, я не буду);
/inet / — шаблон строки, которая должна быть обработана, сразу отсекает inet6, т.к. после 't' идёт пробел.
ip добавляет IP на тот же интерфейс, а ipconfig на сабинтерфейс :0. По этому и не видно.
Тема xargs вообще не раскрыта. А между тем:
find <path> -print0|xargs -0 -I {} <command> {}
это наиболее простой способ обработать файлы, в именах которых есть пробелы.
Тема find тоже не раскрыта, но заголовок поста — "… для обработки текста".
Ну расскажите уже, как без find обработать текстовые файлы с пробелами и прочими непотребствами в наименованиях. Я вот сколько не пытался, либо ничего не получается, либо какие-то совершенно монструозные конструкции.
Не очень понятно при чем find к пробелам в имени файла.
Речь о том, что человек обрисовал только примочки для работы с текстом.
Не с файлами как таковыми.
Поэтому нет xargs, find, tee и прочих извращений инструментов.
Иначе проще было бы написать перевод info.
PS. файлы с пробелами в именах обрабатываются как-то так:
ls -1 | while read -r; do echo "$REPLY"; done
ls | while пишут джуны. Сеньоры пишут, как товарищ выше написал.
Тимлиды пишут "Сеньору: вывести список файлов".
Это принципиально кто как пишет?
Главное — результат, в приемлемые сроки и в сопровождаемом виде.
Но вот это не будет работать если в названии файла есть перенос строки же.
Это принципиально кто как пишет?
Нет, просто сеньоры уже успели набить шишек в таких конструкциях.
seq 12|xargs -i sh -c 'LC_ALL=C cal 31 {} $(date +%Y) 2>&1|grep -Eo "\-(2[8|9])|\-30|31"|cut -d "-" -f 2|tr "\n" " "'А вот более жизненная, хоть не сильно быстрая, но на безрыбье и ping nmap. ;-)
seq 1 254|xargs -i sh -c 'ping -c1 -W1 172.19.76.{} >&/dev/null && echo 172.19.76.{} is up'Конкретно в данном случае можно написать проще:
find <path> -print0|xargs -0 <command>
Кстати, у xargs много применений. Например, в Linux посмотреть полную командную строку, использовавшуюся для запуска процесса:
$ xargs -0 echo < /proc/1083/cmdline
containerd --config /var/run/docker/containerd/containerd.toml --log-level info
Конкретно в данном случае можно написать еще проще:
find <path> -exec <command> {} +
$ xargs -0 echo < /proc/1083/cmdline
и чем это лучше чем просто
cat /proc/1083/cmdlineнамного короче получается
Тем, что просто cat /proc/1083/cmdline выведет нечитаемую или трудно читаемую строку, в зависимости от терминала.
Нужно найти способ переименовать bool_from_str повсюду в нашем проекте. Такого можно добиться с помощью команд grep, sed, а также циклов for или с помощью xargs.
И того, кто предложил такую идею — четвертовать, показательно.
Интересно, кто поставил минус? Я обеими руками за grep, sed, xargs, но не для рефакторинга исходников. Поверьте, в реальной кодовой базе такие массовые переименования инструментами, которые не понимают код, привнесут массу больших и маленьких ошибок. И
это не теоретизирование, а знание, основанное на опыте.
sed заменит все вхождения, в т.ч. где подстрока являлась частью большой строки (это, конечно, можно решить при помощи более сложного регекспа), где строка была в кавычках частью строкового литерала, и т.д.
Такие переименования можно делать только лишь в редакторе, в интерактивном режиме, проверяя каждую замену, либо специальным инструментом для рефакторинга, понимающим синтаксис языка.
либо специальным инструментом для рефакторинга, понимающим синтаксис языка
Который обязательно поломается на аспектах, рефлекшене, метапрограммировании и (прости хоспади) эвалах. Ну уж нет, рефакторинг с помощью инструментов — это такая же не работающая лажа, как и grep вслепую в данном случае.
В общем случае — да, в частных — вполне. Если рефакторинга немного, ничего лучше sed+awk, за которыми сразу следует git diff — человечество не придумало.
какой смысл вылезать из уютненькой идешечки? Вот если она не осиливаетИли если она не существует.
Если мы берём не язык из топ-20, такое вполне частое явление. Даже у JS до ~2010 не было иде. А sed/awk тащат любой текстовый язык.
После появления Language Server протокола с кошерными реализациями, я вообще не понимаю, кому нахрен может прийти в голову в нее вообще влезать.
Справедливости ради, в 2009-м году IntelliJ очень хорошо понимала JS, на голову выше любой другой IDE или редактора.
Возможно, и до 2009 года тоже — просто в 2009-м году впервые столкнулся с разработкой большого проекта на JS.
Как раз по тем временам помню, что работа с JS любыми другими средствами была слишком тяжелой, так как язык очень динамичный. И простыми текстовыми инструментами работать с большой кодовой базой было очень неудобно.
Впрочем, уточню мысль: для ещё-вчера-noname языков нет ide, ибо жирно (дай бог чтоб кроме компилятора вообще что-то было), но жизнь заставляет с ними работать и рефакторить.
жизнь заставляет с ними работать и рефакторить
И сколько я ни пробовал рефакторить что-то в IDE, с каждым разом убеждаюсь, что руками это сделать всегда проще и спокойнее. Вообще, я с опытом пришел к мнению, что IDE — хорошее подспорье для новичков, которым и подсказки по методам нужны, и доку прямо тут почитать, и зарефакторить что-то, не особо беря на себя ответственность (пусть железяка сделает).
Профессионалам IDE только мешает своими свистелками и постоянным мерцанием то тут, то там.
Профессионалы обычно могут настроить IDE так, чтобы только нужные им свистелки и мерцания были.
Нужных свистелок не бывает, да и у меня есть, чем заняться в свободное время, помимо настройки IDE. Я люблю, когда оно из коробки не отвлекает, а не после допиливания восемнадцатью напильниками.
Syntax highlighting — единственная причина, почему меня не устраивает Notepad.
А чем вы пользуетесь, что оно вас из коробки не отвлекает?
У меня есть опыт как с редакторами (Vim, Emacs, VS Code), так и с IDE (VS, PHPStorm) — допиливать приходилось и те, и другие.
В этом сезоне модно Go, Node.js, .Net (то есть .NET, прошу прощения).
Многопоточно, асинхронно и с элементами ИИ.
Perl уже моветон.
Сколько лет ими пользуюсь, но без гугла/мана максимум простой grep могу написать и то с дефолтнымитрегэкспами, которых не знаю. У всех так?
Нет
У меня так же. К тому же баш-скрипты с обилием подобного объективно нечитаемые и перегруженные.
Тот же скрипт на руби будет понятным и через год, к тому же чаще всего будет значительно короче.
Более того, он даже понятнее для коллег, которые язык не знают, чем разгадывание ребусов из подобных утилит.
А еще существуют rev и tac, с которыми тоже можно насочинять много интересных дел.
использую вмето него par, очень гибкий инструмент
Причем применение предельно простое, что то вроде такого:
echo "$TableRows" | column -tЕдинственный недостаток — column не умеет адекватно обрабатывать коды управления цветом, текст уезжает. Приходится выбирать между выравниванием и цветным выводом.
grep 'editor =' ~/.gitconfig | cut -d'=' -f2 | sed 's/ //'
grep -oP "(?<=editor\s=\s)(.*)" ~/.gitconfigвозможен пробел в конце строки, или
awk '/editor =/ {print $3}' ~/.gitconfig
13 инструментов для обработки текста в командной оболочке