Комментарии 65
а зачем в команде awk ... < multiline перенаправление,
когда вполне себе работает awk ... multiline?
Болезнь миллениалов: злоупотребление лишним cat:
cat multiline | awk… вместо awk… < multiline
Объясню — стремновато выглядит.
Примерно как "> myfile": был myfile — и нет myfile.
Поэтому конструкция "awk… < multiline" выглядит так, как будто сейчас "..." будет прибито.
Нет, ну правда.
А так — цивильный конвейер, слева направо, всё нормуль.
Можно дальше что-нить прицепить без заморочек.
Оукей.
Покажите в правильном виде (с "<"):
sudo cat /var/log/messages | grep systemd | gawk '{print $6}' | lessТолько так, чтобы живому человеку было понятно кто кому Рабинович.
В данном случае — источник | команда | команда | ...
можно было написать без cat
Можно. Пишите без cat, никто ж не запрещает.
Вам кота жалко, что ли? )
cat нужен там, где следующая утилита не работает с именем файла или не умеет несколько файлов (cat используется для конкатенации). Продолжайте пихать везде cat если вас не смущают конструкции вида
cat ... | grep ...
cat ... | awk ...
cat ... | wc
cat ... | cat ...
wtf ... | cat ...С другой стороны, это всё борьба тупоконечников с остроконечниками. Главное — результат.
Простите, но вы какую-то ерунду написали. В какой оболочке одновременное перенаправление двух файлов в 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Я терпеть не могу перенаправления, но многое работает и вот так.
Вывод адреса IPv4, связанного с сетевым интерфейсом:
ip ad |awk '/inet / {print $2}'
ifconfig — это уже несколько устарело (мало того! встречался с ситуациями, когда ip ad показывал интерфейс/адрсес, а ifconfig — нет, а вот обратного не видел. Но утверждать, что обратного быть не может, я не буду);
/inet / — шаблон строки, которая должна быть обработана, сразу отсекает inet6, т.к. после 't' идёт пробел.
Тема 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'
В общем случае — да, в частных — вполне. Если рефакторинга немного, ничего лучше sed+awk, за которыми сразу следует git diff — человечество не придумало.
какой смысл вылезать из уютненькой идешечки? Вот если она не осиливаетИли если она не существует.
Если мы берём не язык из топ-20, такое вполне частое явление. Даже у JS до ~2010 не было иде. А sed/awk тащат любой текстовый язык.
После появления Language Server протокола с кошерными реализациями, я вообще не понимаю, кому нахрен может прийти в голову в нее вообще влезать.
Впрочем, уточню мысль: для ещё-вчера-noname языков нет ide, ибо жирно (дай бог чтоб кроме компилятора вообще что-то было), но жизнь заставляет с ними работать и рефакторить.
жизнь заставляет с ними работать и рефакторить
И сколько я ни пробовал рефакторить что-то в IDE, с каждым разом убеждаюсь, что руками это сделать всегда проще и спокойнее. Вообще, я с опытом пришел к мнению, что IDE — хорошее подспорье для новичков, которым и подсказки по методам нужны, и доку прямо тут почитать, и зарефакторить что-то, не особо беря на себя ответственность (пусть железяка сделает).
Профессионалам IDE только мешает своими свистелками и постоянным мерцанием то тут, то там.
Профессионалы обычно могут настроить IDE так, чтобы только нужные им свистелки и мерцания были.
Сколько лет ими пользуюсь, но без гугла/мана максимум простой 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 инструментов для обработки текста в командной оболочке