Comments 83
Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.
авто-исправление ошибок
Если вы отправляете на выполнение команду с опечаткой, у меня для вас плохие новости.
Хорошая подборка! Узнал новое для себя.
https://github.com/ibraheemdev/modern-unix ещё полезный список
Еще gdu
Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.
а если свой bashrc + скриптом подтянуть все проги?
Напоминает мне одного коллегу из 2000х, который на каждом компьютере менял как минимум раскладку клавиатуры, которая была удобна ему, не заботясь о пользователях.
Это можно для себя так делать. А если в команде несколько людей и они предпочитают разные утилиты. И у тебя тысячи серверов. На них, например, разные варианты linux развернутые разными людьми из разных шаблонов, на протяжении нескольких лет. Не очень реально.
Как минимум отказ от grep в пользу rg имеет шансы уменьшить боль в таком зоопарке, хотя бы просто потому что оно кратно быстрее.
У меня как раз тысячи серверов на работе. Открою тайну: в скорость grep никогда ещё не упирались настолько, чтобы сей греп имело смысл менять на всех серверах, включая клиентские. Его не настолько часто используют на действительно больших данных.
Знаю что найдутся люди которые частенько делают какой-нибудь jq|grep на относительно жирных массивах. Если там хотя бы мегабайт данных набирается, то это уже +секунда жизни с одного запуска если пользоваться rg вместо него.
а) это не делается на каждом сервере, можно выделить группу специализированных, на которых и надо что-то нестандартное.
б) если дошло до обработки json - дешевле сразу взять какой-нибудь python или сразу go и писать скрипты на нём.
Пример в целом нерелевантен - основные тормоза тут всё же в разборе json, а не в грепе. Ну или запускаете на хреновой флешке.
jq|grep - это просто показательный пример. Грепают естественно не только джсон и не только с пайплайнов, так что "разбор джсона" такая себе отговорка.
Эксперимента ради предлагаю всё же попробовать на какой-нибудь средненькой репе (100k sloc) эксперимента ради погрепать и тем и другим через time. Будете неприятно удивлены насколько grep все же тормозной, особенно если будете проверять на яблочных устройствах. Но да, на все машины в сети столько грепать почти наверняка не нужно, тут вы правы. И нет, обрабатывать питоном будет даже медленее, чем просто grep, насколько мне известно, по крайней мере без дополнительныой магии.
А смысл? Это не является узким местом в моей работе. Тормозят чаще диски и сеть, а не средства обработки. Понадобится постоянно грепать что-то в куче мелких файлов - перетащу их в базу кликхауса и буду делать селекты, что точно будет быстрее и эффективней.
Искать же слово в репозитории имеет смысл либо в IDE, либо в вебморде гитлаба.
В любом случае - утилита для localhost, а не тысяч серверов.
Плюс, есть опция -F
Это не зоопарк - это жизнь :) Когда источников правды много, лучшее что можно сделать не генерить лишней кастомизации.
Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия.
Да не такая это и проблема. Я на своём компьютере использую ripgrep и fd, но на чужих у меня нет никаких проблем с тем, чтобы на автомате запустить grep и find.
А на сервер зачем заходить?
Если речь о том, что при централизованном управлении конфигурацией, логгировании и мониторингом заходить на сервера нет необходимости, то это не так.
* Всегда найдутся сервера, о которых узнаешь только когда они поломались и всего выше перечисленного там нет.
* Почти всегда, кроме случая когда много однотипных серверов, зайти во время сбоя и исправить что-то на сервере руками быстрее чем писать плейбук.
* Логов и метрик может быть недостаточно для траблшутинга. Для сложных проблем их всегда будет недостаточно.
и тд.
Не соглашусь. Даже версии стандартных утилит отличаются от дистрибутива к дистрибутиву (а так же у линукса и мака, например). Поэтому, на мой взгляд привычка использовать только стандартные - вещь тут лишняя. Но знание стандартных обязательно.
А я вот на серверах, подконтрольных мне, позволяю себе и пару новых команд установить и алиасы, удобные лично мне, настроить. Linux, к счастью, многопользовательский. Не всё подряд конечно ставлю.
ПС: у меня порядка десятка долгоживущих серверов. Понятно что у настоящего админа их гораздо больше и они поднимаются и уничтожаются десятками. Заниматься каждым в отдельности смысл теряется, но ведь есть .ssh_config, ansible и прочее.
В общем не вижу смысла слишком уж ограничивать себя и не пользоваться удобными утилитами и алиасами, только потому что маинтайнеры ещё не включили их по-умолчанию в используемый на сервере дистрибутив.
Когда прихожу на новую работу, всегда спрашиваю — будет ли кто-то еще работать за моим компом? Если нет — подгружаю свои шорткаты, экшены, плагины и скрипты для Adobe. Если да — то все оставляю стандартным.
Потому что если вдруг, кому-то придется сесть за мой комп и что-то резко переделать, мало ли — то меня на след день четвертуют ))
Обычно, никто за мой комп не садится, но были разные случаи и теперь заранее выясняю такие возможности
Хорошая практика, надо будет запомнить.
А еще вопросик: у вас нет рабочих профилей (аккаунтов) в системе?
Все рабочие файлы лежали локально, передавались заказчикам или в производство — на болванках и, если кто-то отсутствовал, а надо срочно поправить какой-то его макет, то чел ничего никуда не копировал — просто садился за комп, где был сделан файл и переделывал его прямо там
Ессно, кастомные шорткаты были просто невозможны
Для этого придуманы отдельные профили (пользователи). Пусть садится кто угодно и делает что угодно. Не могу придумать ситуации, что кому-то нужен доступ к моему профилю.
Согласен, но не могу обходиться без этого:)
(echo '"\e[A": history-search-backward'; echo '"\e[B": history-search-forward') >> /etc/inputrc
fdupes — поиск дубликатов
Я предпочитаю rmlint — для моих сценариев больше подходит.
Я тоже сначала использовал fdupes, пока не понадобился поиск уникальных файлов... Тогда я узнал о jdupes --isolate --print-unique --recurse. Когда и в нём сломалась эта фича, я перешёл на rmlint и пользовался им до тех пор, пока не обнаружил, что он непредсказуемо сбоит на специфической fuse файловой системе под одним конкретным устройством (что чуть не стоило мне потери данных)
В общем, есть основания относиться с максимальным подозрением к таким инструментам и не полагаться на них, а использовать вместо этого самописную портянку с применением find/sha512sum/sort/join, которые пока ещё, к счастью, не провинились передо мной
Свои 5 копеек
delta (CLI diff) https://github.com/dandavison/delta
И tig (git наоборот) -- консольный просмотрщик git, пользуюсь часто, имхо удобен
Тогда не tig, а gitui. Tig на больших репах может тормозить, а то и покрашиться вовсе.
Отличная подборка! Нашел много интересного для себя.
P.S. Пункт rsync (номер 21) здесь лишний. Ему уже 26 лет, его можно смело отнести к основам. Ну и ссылка у него не на github, а на rsync.samba.org.
смотришь на очередную "современную" утилиту - а она весит пару мегабайт вместо пары сотен килобайт, и в качестве "современных" фич предлагает какой-нибудь цветной вывод текста (который в стандартной утилите тоже в общем-то можно настроить, но не из коробки) с нескучными эмодзи.
Из реально нового и полезного тут разве что fzf, но и для него есть написанные на Си легковесные аналоги. А для всего остального есть zsh и fish.
Весят они по 2M+ потому что статически скомпилированы (как правило), т.е. никакой зависимости от системных библиотек, которые в разных дистрибутивах (и даже их версиях) настолько разные что бинарник из одного в другой не перенести простым копированием, а компилировать под себя на каждой системе - то ещё удовольствие, да и не всегда возможно.
Это вообще большая проблема в линухе - дистров куча, все как бы линух, но и как бы нет - разные места для конфирурации, разные библиотеки, разные имена пакетов (и принцип именования), разные оболочки по умолчанию, разные версии приложений, разное поведение этих приложений по умолчанию - это просто зоопарк.
На этом фоне приложение или утилита которую можно просто скачать (в виде бинарника) и запустить почти где угодно без бубна - очень удобно, и пофиг что оно весит чуть больше, это может быть проблемой только в системах где дисковое пространство реально на вес золота (IoT & co).
Весят они по 2M+ потому что статически скомпилированы (как правило), т.е. никакой зависимости от системных библиотек
это вы взяли откуда-то из параллельной реальности. Берем первую попавшуюся из списка и смотрим:
$ ldd (which exa)
linux-vdso.so.1 (0x00007ffd6b9c1000)
libgit2.so.1.5 => /usr/lib/libgit2.so.1.5 (0x00007f733fed9000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f733feb9000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f733fdd1000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f733fbea000)
libssl.so.3 => /usr/lib/libssl.so.3 (0x00007f733fb4a000)
libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007f733f600000)
libhttp_parser.so.2.9 => /usr/lib/libhttp_parser.so.2.9 (0x00007f733fb3c000)
libpcre2-8.so.0 => /usr/lib/libpcre2-8.so.0 (0x00007f733faa1000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007f733fa5f000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f733f5e6000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f7340108000)
хотя сама она тоже под мегабайт весит, т.е. туда напихали незнамо что и так и эдак. Это, на минуту, замена ls, про которую пишут в официальном readme
it’s small, fast, and just one single binary
Не знаю, кому как, но лично мне такие "современные" утилиты - не нужны. Дело даже не в дисковом пространстве самом по себе, а в том что от этого вранья и пиара откровенно несет.
Ладно, токсиком который выскажет это буду я.
CLI инструменты, без которых нельзя жить
Какой же голимый кликбейт, буквально без любой утилиты из этого списка прекрасно живётся. Самый незаменимый пожалуй rsync, но он как бы и так в стандартном комплекте.
Отдельно стоит отметить "кстати, это написано на Rust" в качестве киллер-фичи/преимущества у какой-то тулзы. I use Arch, btw.
Блин, это ж надо так органично назвать утилиту fuck! Именно это же и есть в голове, когда в команде делаешь типичную ошибку или опечатку. Я просто в восторге от задумки.
(но ставить себе, наверное, не буду)
раз уж сказали про rsync, надо бы добавить еще rclone для работы с облаками. И еще Lazygit
Ничего системного или кроссплатформенного (Linux / Unix, macOS) не включено
Кхм... А для какой ОС тогда это всё?
Хочется еще упомянуть ncdu, альтернативу du с более понятным интерактивным интерфейсом для определения, что в текущей папке все место съело.
gdu на больших объёмах заметно быстрее работает, но не во всех дистрибутивах есть в репозиториях
Мне dua больше нравится, ещё и на винде работает.
Товарищи!
Много читаю про Разбивку диска для установки Linux. Но как правило люди делают это или через графические утилиты типа gnome-disk-utility или через консольные интерактивные. Только недавно я увидел язык описания разметки диска genimage Вопрос: это единственный такой проект?
Обычно используют что-то вроде sfdisk для разбивки. Ну или parted. А всякие описания разделов делают в ansible, как универсальном средстве конфигурации всей системы.
Все зависит от того где ставить. Образ для VM - задача полегче, чем для железа. Там не только разметка (как parted), но еще нужно устанавливать загрузчики, в том числе для UEFI.
Для железа очень классно FAI, но это при большом количестве. При малом наверное стоит покапаться в kickstart файлах, у каждого дистрибутива свой. В дебиан/убунту по-моему вообще документации не было, нужно смотреть debconf для debian installer.
А для образов VMок популярен packer, но я лично не люблю его за сложность и неинтуитивность. Больше понравился disk image builder. Но я до этого этот genimage проект не видел, звучит интересно.
Но времена меняются, в развитых странах админы потихоньку переходят в devops в облаке и уже эти установки железа остаются далеко позади. А с kubernetes практически уходит удаленный доступ через ssh (ну если не считать exec в контейнер).
"А с kubernetes практически уходит удаленный доступ через ssh"
А как же тогда подключаться к типичному консольному линуксу, если не по ssh?
Имеется ввиду, что в среде, где это запускается, не нужно логиниться на серверы. Программист не оперирует понятием "сервер". Он закачивает image и свой helm chart, например. Там он указывает какой адрес будет у его приложения. Никаких ssh.
Если админу нужно именно на сервер зайти, то конечно ssh подойдет. Но таких админов несколько человек на десятки тысяч программистов может быть. И заходить нужно только чтобы расследовать проблему, а не каждый день :)
Я бы добавил screen, а все остальное - убрал.
ripэто безопасный, эргономичный и производительный инструмент для удаления файлов.
От авторов "проактивный и быстрообучаемый". Ну серьезно, какая эргономика и производительность по отношению к замене rm?
Есть прога, похожая на zoxide, которой я часто пользуюсь - Warp Directory.
Пользуясь случаем представляю свой скрипт "безопасный dd" для записи образа на флешку.
Стараюсь не пользоваться такими штуками, чтоб, как тут уже упомянули, не теряться на серверах где всего этого добра нет. Но пользую https://github.com/ellie/atuin
Оно хранит историю команд и предлагает удобный поиск по ней. И по желанию может хранить все в облаке.
Настроил так, чтобы по ctrl+r был atuin, а по стрелке вверх - стандартный переход на предыдущую команду. Теперь на любой вкладке терминала у меня есть вся история. Ну и поиск тоже выручает.
Если будете ставить, рекомендую не ограничиваться readme, но и по всей документации пройтись. Там не очень очевидно что большая ее часть спрятана, вот тут ссылки: https://github.com/ellie/atuin#documentation
А я юзаю https://github.com/dvorka/hstr
"исправление минорных ошибок."
Грустно-то как прозвучало... Автор, по-русски: "исправление мелких ошибок" или лучше: "небольшие исправления". Спасибо заранее.
exa умеет имитировать treeexa --tree
Зашел из-за тега DevOps, а тут про "вкусовщину" уровня пользователя.
Ну раз так, то мой личный единственный грешок, который я устанавливаю почти в любой *nix системе с которой приходится по долгу работать -- Midnight Commander, который наверное с половину функционала перечисленных утилит покрывает.
Все остальное, как отметил @mirwide, -- зло! Лушче уметь быстро ориентироваться в любой (даже новой, незнакомой) среде и знать не только про набор стандартных утилит (и их версии в разных дистро), а про например всякие там псевдофайловые системы типа /proc и прочие особенности, а не тащить вот это все в попытке сделать из шелла швейцарский нож.
Про образы/контейнеры, которые мы все пытаемся сделать наиболее легковесными и быстрыми я вообще молчу.
P.S. Вообще этот пост напомнил мне эдакого сферического около-IT-шника из 90ых/нулевых (мы все знаем хотя бы одного такого), когда траффик был еще дорогой, а CD/DVD были в полном расцвете сил, который при всякой встрече задавал один стандартный вопрос: "есть какой-нибудь новый софт?" Вот напоминает *nix-версию такого "IT-Плюшкина" :-)
Все остальное, как отметил mirwide, — зло!
ну тут в список попали и вполне себе распространённые rsync и jq
diff-so-fancy - сравнение содержания двух файлов (аналог diff)
есть куда более интересная difftastic которая понимает структурные изменения файлах типа java, js и т.д.
CLI инструменты, которые облегчат времяпровождение в терминале и сделают его приятнее