Введение
Многие из вас каждый день работают в терминале, так давайте улучшим это времяпровождение вместе. Существует множество полезных инструментов CLI, которые могут сделать вашу жизнь в командной строке проще, быстрее и в целом веселее.
В этом посте описан мой топ-25 обязательных инструментов CLI, на которые я привыкла полагаться. Если тут нет вашего любимого - дайте мне знать в комментариях :)
1. thefuck - авто-исправление ошибок
Проект на GitHub
thefuck- это одна из тех утилит, без которых вы не сможете жить, как только попробуете ее. Всякий раз, когда вы неправильно вводите команду и получаете сообщение об ошибке, просто запустите ее, и она автоматически исправит ее. Используйте up / down, чтобы выбрать исправление, или просто пропишитеfuck -yeah, чтобы она автоматические исправила ошибку на своё усмотрение.
2. zoxide - легкая навигация по папкам (аналог cd)
Проект на GitHub
zпозволяет вам перейти в любую папку без необходимости запоминать или указывать полный путь до неё. Он запоминает, какие папки вы посетили, так что вы можете быстро перемещаться - вам даже не нужно вводить полное название папки. Он также имеет опцию интерактивного выбора, используяfzf, чтобы вы могли фильтровать результаты каталога в реальном времени.
3. tldr - поддерживаемая сообществом документация (аналог man)
Проект на GitHub
tldr- это огромная коллекция справочных страниц, поддерживаемых сообществом. В отличие от традиционных документаций, она обобщена, содержит полезные примеры использования и красиво оформлена для удобства чтения.
4. scc - подсчитает кол-во строк кода (аналог cloc)
Проект на GitHub
sccдает вам информацию по количеству строк кода, написанных на каждом языке для конкретного каталога. Он также показывает некоторые забавные статистические данные, такие как ориентировочная стоимость разработки и информация о сложности. Он невероятно быстр, очень точен и поддерживает широкий спектр языков.
5. exa - список файлов (аналог ls)
Проект на GitHub
exa- это современная замена команды ls на основе Rust. Он может отображать типы файлов в виде значков, цветовую палитру, информацию о файле / папке и имеет несколько выходных форматов - дерево, сетку или список.
6. duf - использование диска (аналог df)
Проект на GitHub
dufотлично подходит для отображения информации о дисках и проверки свободного места. Он выдает четкие и красочные данные и включает в себя опции для сортировки и настройки результатов.
7. aria2 - скачивание файлов (аналог wget)
Проект на GitHub
aria2- это легкая утилита, которая поддерживает HTTP / HTTPS, FTP, SFTP, BitTorrent и Metalink с поддержкой управления через интерфейс RPC. Он невероятно богат функциями и имеет массу опций. Есть также ziahamza/webui-aria2 - приятный компаньон веб-интерфейса.
8. bat - открытие файлов (аналог cat)
Проект на GitHub
bat- это клонcatс подсветкой синтаксиса и интеграцией сgit. Написанный на Rust, он очень производителен и имеет несколько вариантов настройки вывода и цветовых тем. Существует поддержка автоматической конвейеризации и объединения файлов.
9. diff-so-fancy - сравнение содержания двух файлов (аналог diff)
Проект на GitHub
diff-so-fancyдает вам более привлекательные различия для сравнения строк, файлов, каталогов и измененийgit. Подсветка изменений значительно упрощает обнаружение изменений, и вы можете настроить макет вывода и цвета
10. entr - следит за изменениями (стандартный watcher)
Проект на GitHub
entrпозволяет запускать произвольную команду при каждом изменении файла. Вы можете передать файл, каталог, символическую ссылку или регулярное выражение, чтобы указать, какие файлы он должен просматривать.
11. exiftool - чтение и запись метаданных
Проект на GitHub
ExifTool- это удобная утилита для чтения, записи, удаления и создания метаданных для широкого спектра типов файлов. Никогда больше случайно не сообщайте о своем местоположении, когда делитесь фотографией!
12. jdupes - поиск дубликатов
Проект на GitHub
jdupesиспользуется для поиска и/или удаления дубликатов файлов в указанных каталогах. Это полезно для освобождения места на диске.
13. fzf - поиск файлов (аналог find)
Проект на GitHub
fzf- это чрезвычайно мощный и простой в использовании инструмент поиска и фильтрации файлов. Это позволяет вам искать строку или шаблон по файлам. У fzf также есть плагины, доступные для большинства сред разработки (IDE), для отображения мгновенных результатов во время поиска. В этом посте Алексея Самошкина освещаются некоторые из его вариантов использования.
14. hyperfine - консольный benchmarking
Проект на GitHub
hyperfineпозволяет легко проводить точный бенчмарк и сравнивать произвольные команды или скрипты. Он заботится о прогреве, очищает кэш для получения точных результатов и предотвращает вмешательство других программ. Он также может экспортировать результаты в виде необработанных данных и генерировать диаграммы.
15. just - создание скриптов для выполнения команд (аналог make)
Проект на GitHub
justпохож наmake, но с некоторыми приятными дополнениями. Это позволяет вам группировать команды ваших проектов в повторные копии, которые можно легко перечислить и запустить. Поддерживает псевдонимы, позиционные аргументы, различные оболочки, интеграциюdotenv, взаимозаменяемость строк и практически все остальное, что вам может понадобиться.
16. jq - работа с JSON
Проект на GitHub
jqпохож наsed, но для JSON - вы можете использовать его для нарезки, фильтрации, сопоставления и преобразования структурированных данных с легкостью. Его можно использовать для написания сложных запросов для извлечения данных JSON или манипулирования ими. Существует также игровая площадка jq, которую вы можете использовать, чтобы опробовать ее или сформулировать запросы с живой обратной связью.
17. most - многооконный пейджер (аналог less)
most- это пейджер для чтения длинных файлов или вывода команд.mostподдерживает несколько окон и имеет возможность не переносить текст.
18. procs - диспетчер задач (аналог ps)
Проект на GitHub
process- это простой в навигации диспетчер задач, он имеет цветную подсветку, упрощает сортировку и поиск процессов, имеет древовидный вид и обновления в режиме реального времени.
19. rip - удаление файлов (аналог rm)
Проект на GitHub
ripэто безопасный, эргономичный и производительный инструмент для удаления файлов. Это позволяет вам интуитивно удалять файлы и каталоги, а также легко восстанавливать удаленные файлы.
20. ripgrep - поиск в файлах (аналог grep)
Проект на GitHub
ripgrep- это инструмент поиска, ориентированный на строку, который рекурсивно выполняет поиск шаблона регулярного выражения в текущем каталоге. Он может игнорировать содержимое.gitignoreи пропускать двоичные файлы. Он способен выполнять поиск в сжатых архивах или выполнять поиск только по определенному расширению и понимает файлы, использующие различные методы кодирования.
21. rsync - быстрая инкрементная передача файлов
Проект на GitHub
rsyncпозволяет копировать большие файлы локально, на удаленные хосты или внешние диски и наоборот. Он может использоваться для синхронизации файлов в нескольких местах и идеально подходит для создания, обновления и восстановления резервных копий.
22. sd - поиск и замена (аналог sed)
Проект на GitHub
sd - это простой, быстрый и интуитивно понятный инструмент поиска и замены, основанный на строковых литералах. Он может быть выполнен для файла, всего каталога или любого передаваемого текста.
23. tre - иерархия каталогов (аналог tree)
Проект на GitHub
treвыводит древовидный список файлов для вашего текущего или указанного каталога с цветами. При запуске с параметром-eон нумерует каждый элемент и создает временный псевдоним, который вы можете использовать для быстрого перехода к этому местоположению.
24. xsel - доступ к буферу обмена
Проект на GitHub
xselпозволяет вам читать и записывать в буфер обменаX Selectionс помощью командной строки. Это полезно для передачи вывода команды в буфер обмена или скопированных данных в команду
25. bandwhich - мониторинг сети
Проект на GitHub
Отображение использования пропускной способности, информации о соединении, исходящих хостах и DNS-запросах в режиме реального времени
Дополнительная информация
Что не было включено в статью:
Этот список не включает основы, такие как Vim, Tmux, Ranger, ZSH, Git и т.д., Которые вы, вероятно, уже используете.
Я также не включила ничего слишком нишевого или специфичного только для небольшого числа пользователей.
Не включила инструменты, которые поддерживаются только одной системой и являются специфичными именно для неё (MacOS, Linux etc).
Не включила приложения, которые относятся к терминалу, но не являются приложениями CLI (например, эмуляторами терминалов).
Для большинства перечисленных проектов существует множество альтернатив, которые достигают аналогичных результатов, для краткости они также не были включены.
Заключение
В скором времени будет готов еще один перевод такого же плана.
Как обычно, буду рад любому фидбеку относительно представленных утилит в комментариях.
Только добра.
upd 22.01.23 18:00: добавил заключение.
upd 22.01.23 19:35: исправление мелких ошибок.
Комментарии (72)
Mirzapch
22.01.2023 16:43+9авто-исправление ошибок
Если вы отправляете на выполнение команду с опечаткой, у меня для вас плохие новости.
domix32
23.01.2023 11:48Самое печальное, что оно работает исключительно медленно, по крайней мере в настолько же неторопливо терминале Mac OS. Это не считая того что логика на питоне писана.
411
22.01.2023 16:55+3https://github.com/ibraheemdev/modern-unix ещё полезный список
scoffs Автор
22.01.2023 17:54Приму к сведению. Хоть я и не сисадмин, но, возможно, сделаю еще или переведу другую подборку такого же плана.
bkstan
23.01.2023 08:20войти на Хабр, чтоб увидеть в комментариях в десять раз больше нагрузки, чем в статье. Так-то статей хороших много....
mirwide
22.01.2023 17:34+100Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.
yurikk
22.01.2023 17:53а если свой bashrc + скриптом подтянуть все проги?
mc2
22.01.2023 18:08+5Напоминает мне одного коллегу из 2000х, который на каждом компьютере менял как минимум раскладку клавиатуры, которая была удобна ему, не заботясь о пользователях.
Mirzapch
24.01.2023 11:06У меня как рефлекс - нажимать ctrl+shift и следом сразу alt+shift. Да, у меня тоже был такой коллега.
DistortNeo
24.01.2023 16:56У меня сейчас Alt+Shift меняет язык (EN/RU), а Ctrl+Shift — раскладку (EN/TR). Не поможет такой совет.
mirwide
22.01.2023 18:11+1Это можно для себя так делать. А если в команде несколько людей и они предпочитают разные утилиты. И у тебя тысячи серверов. На них, например, разные варианты linux развернутые разными людьми из разных шаблонов, на протяжении нескольких лет. Не очень реально.
domix32
23.01.2023 11:53Как минимум отказ от grep в пользу rg имеет шансы уменьшить боль в таком зоопарке, хотя бы просто потому что оно кратно быстрее.
Stanislavvv
23.01.2023 12:13+1У меня как раз тысячи серверов на работе. Открою тайну: в скорость grep никогда ещё не упирались настолько, чтобы сей греп имело смысл менять на всех серверах, включая клиентские. Его не настолько часто используют на действительно больших данных.
domix32
23.01.2023 21:05Знаю что найдутся люди которые частенько делают какой-нибудь jq|grep на относительно жирных массивах. Если там хотя бы мегабайт данных набирается, то это уже +секунда жизни с одного запуска если пользоваться rg вместо него.
Stanislavvv
23.01.2023 21:43а) это не делается на каждом сервере, можно выделить группу специализированных, на которых и надо что-то нестандартное.
б) если дошло до обработки json - дешевле сразу взять какой-нибудь python или сразу go и писать скрипты на нём.
Пример в целом нерелевантен - основные тормоза тут всё же в разборе json, а не в грепе. Ну или запускаете на хреновой флешке.domix32
23.01.2023 22:11jq|grep - это просто показательный пример. Грепают естественно не только джсон и не только с пайплайнов, так что "разбор джсона" такая себе отговорка.
Эксперимента ради предлагаю всё же попробовать на какой-нибудь средненькой репе (100k sloc) эксперимента ради погрепать и тем и другим через time. Будете неприятно удивлены насколько grep все же тормозной, особенно если будете проверять на яблочных устройствах. Но да, на все машины в сети столько грепать почти наверняка не нужно, тут вы правы. И нет, обрабатывать питоном будет даже медленее, чем просто grep, насколько мне известно, по крайней мере без дополнительныой магии.
mirwide
23.01.2023 12:16Это не зоопарк - это жизнь :) Когда источников правды много, лучшее что можно сделать не генерить лишней кастомизации.
invasy
22.01.2023 20:48Бывают серверы с ограниченным или полностью закрытым доступом к интернетам или репозиториям. Можно, конечно, обходными путями попытаться протащить нужные утилиты, но это усложняет процесс и безопасники могут не понять. Поэтому и полезно работать с тем, что доступно по-умолчанию.
masai
22.01.2023 18:21+2Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия.
Да не такая это и проблема. Я на своём компьютере использую ripgrep и fd, но на чужих у меня нет никаких проблем с тем, чтобы на автомате запустить grep и find.
leotsarev
22.01.2023 20:45А на сервер зачем заходить?
mirwide
22.01.2023 21:56+6Если речь о том, что при централизованном управлении конфигурацией, логгировании и мониторингом заходить на сервера нет необходимости, то это не так.
* Всегда найдутся сервера, о которых узнаешь только когда они поломались и всего выше перечисленного там нет.
* Почти всегда, кроме случая когда много однотипных серверов, зайти во время сбоя и исправить что-то на сервере руками быстрее чем писать плейбук.
* Логов и метрик может быть недостаточно для траблшутинга. Для сложных проблем их всегда будет недостаточно.
и тд.
411
23.01.2023 02:34+2Не соглашусь. Даже версии стандартных утилит отличаются от дистрибутива к дистрибутиву (а так же у линукса и мака, например). Поэтому, на мой взгляд привычка использовать только стандартные - вещь тут лишняя. Но знание стандартных обязательно.
Pavel1114
23.01.2023 04:51А я вот на серверах, подконтрольных мне, позволяю себе и пару новых команд установить и алиасы, удобные лично мне, настроить. Linux, к счастью, многопользовательский. Не всё подряд конечно ставлю.
ПС: у меня порядка десятка долгоживущих серверов. Понятно что у настоящего админа их гораздо больше и они поднимаются и уничтожаются десятками. Заниматься каждым в отдельности смысл теряется, но ведь есть .ssh_config, ansible и прочее.
В общем не вижу смысла слишком уж ограничивать себя и не пользоваться удобными утилитами и алиасами, только потому что маинтайнеры ещё не включили их по-умолчанию в используемый на сервере дистрибутив.
vconst
23.01.2023 12:44+1Не сисадмин, но соглашусь
Когда прихожу на новую работу, всегда спрашиваю — будет ли кто-то еще работать за моим компом? Если нет — подгружаю свои шорткаты, экшены, плагины и скрипты для Adobe. Если да — то все оставляю стандартным.
Потому что если вдруг, кому-то придется сесть за мой комп и что-то резко переделать, мало ли — то меня на след день четвертуют ))
Обычно, никто за мой комп не садится, но были разные случаи и теперь заранее выясняю такие возможностиscoffs Автор
23.01.2023 12:56+1Хорошая практика, надо будет запомнить.
А еще вопросик: у вас нет рабочих профилей (аккаунтов) в системе?vconst
23.01.2023 13:16В некоторых фирмах, во времена поголовной XP, были просто — «рабочие компы». Админил все это дело какойнить «приходящий» студент, никаких «энтерпрайзов с доменами», а в макинтошы вообще никто не лез, кроме самих дизайнеров и верстальщиков — ибо «ниасиливали»
Все рабочие файлы лежали локально, передавались заказчикам или в производство — на болванках и, если кто-то отсутствовал, а надо срочно поправить какой-то его макет, то чел ничего никуда не копировал — просто садился за комп, где был сделан файл и переделывал его прямо там
Ессно, кастомные шорткаты были просто невозможны
valvalva
23.01.2023 19:47+2Согласен, но не могу обходиться без этого:)
(echo '"\e[A": history-search-backward'; echo '"\e[B": history-search-forward') >> /etc/inputrc
DistortNeo
22.01.2023 17:35+1fdupes — поиск дубликатов
Я предпочитаю rmlint — для моих сценариев больше подходит.
oficsu
23.01.2023 06:15Я тоже сначала использовал fdupes, пока не понадобился поиск уникальных файлов... Тогда я узнал о jdupes --isolate --print-unique --recurse. Когда и в нём сломалась эта фича, я перешёл на rmlint и пользовался им до тех пор, пока не обнаружил, что он непредсказуемо сбоит на специфической fuse файловой системе под одним конкретным устройством (что чуть не стоило мне потери данных)
В общем, есть основания относиться с максимальным подозрением к таким инструментам и не полагаться на них, а использовать вместо этого самописную портянку с применением find/sha512sum/sort/join, которые пока ещё, к счастью, не провинились передо мной
thegriglat
22.01.2023 17:58+3Свои 5 копеек
delta (CLI diff) https://github.com/dandavison/delta
И tig (git наоборот) -- консольный просмотрщик git, пользуюсь часто, имхо удобен
lexore
22.01.2023 18:35+6Отличная подборка! Нашел много интересного для себя.
P.S. Пункт rsync (номер 21) здесь лишний. Ему уже 26 лет, его можно смело отнести к основам. Ну и ссылка у него не на github, а на rsync.samba.org.
scoffs Автор
22.01.2023 18:52Исправлю ошибку в ссылке, но всё же не буду удалять из подборки. Спасибо!
lrrr11
22.01.2023 19:37+5смотришь на очередную "современную" утилиту - а она весит пару мегабайт вместо пары сотен килобайт, и в качестве "современных" фич предлагает какой-нибудь цветной вывод текста (который в стандартной утилите тоже в общем-то можно настроить, но не из коробки) с нескучными эмодзи.
Из реально нового и полезного тут разве что fzf, но и для него есть написанные на Си легковесные аналоги. А для всего остального есть zsh и fish.
Tangeman
23.01.2023 13:59+2Весят они по 2M+ потому что статически скомпилированы (как правило), т.е. никакой зависимости от системных библиотек, которые в разных дистрибутивах (и даже их версиях) настолько разные что бинарник из одного в другой не перенести простым копированием, а компилировать под себя на каждой системе - то ещё удовольствие, да и не всегда возможно.
Это вообще большая проблема в линухе - дистров куча, все как бы линух, но и как бы нет - разные места для конфирурации, разные библиотеки, разные имена пакетов (и принцип именования), разные оболочки по умолчанию, разные версии приложений, разное поведение этих приложений по умолчанию - это просто зоопарк.
На этом фоне приложение или утилита которую можно просто скачать (в виде бинарника) и запустить почти где угодно без бубна - очень удобно, и пофиг что оно весит чуть больше, это может быть проблемой только в системах где дисковое пространство реально на вес золота (IoT & co).
lrrr11
23.01.2023 14:25Весят они по 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, про которую пишут в официальном readmeit’s small, fast, and just one single binary
Не знаю, кому как, но лично мне такие "современные" утилиты - не нужны. Дело даже не в дисковом пространстве самом по себе, а в том что от этого вранья и пиара откровенно несет.
Flux
22.01.2023 20:28+37Ладно, токсиком который выскажет это буду я.
CLI инструменты, без которых нельзя жить
Какой же голимый кликбейт, буквально без любой утилиты из этого списка прекрасно живётся. Самый незаменимый пожалуй rsync, но он как бы и так в стандартном комплекте.
Отдельно стоит отметить "кстати, это написано на Rust" в качестве киллер-фичи/преимущества у какой-то тулзы. I use Arch, btw.scoffs Автор
23.01.2023 08:23Да, чутка хайпанул. Прислушаюсь и изменю заголовок, спасибо.
Да и я не вижу токсичности в вашем комментарии, ваше замечание вполне себе адекватное и имеет место на существование
QDeathNick
23.01.2023 15:54-1Это же ???????????????????????? хайпанула, а не вы.
scoffs Автор
23.01.2023 15:59Мне стоило здраво оценить содержание статьи и назвать ее должным образом.
Сейчас, вроде как, название соответствует содержанию.
Survtur
22.01.2023 23:56+4Блин, это ж надо так органично назвать утилиту fuck! Именно это же и есть в голове, когда в команде делаешь типичную ошибку или опечатку. Я просто в восторге от задумки.
(но ставить себе, наверное, не буду)
CyberVettGhern
23.01.2023 04:29раз уж сказали про rsync, надо бы добавить еще rclone для работы с облаками. И еще Lazygit
scoffs Автор
23.01.2023 04:30В этой статье только те 25 инструментов, которые были в оригинале. Там еще есть 25 каких-то вещей, но уже для других целей
Elrond16
23.01.2023 11:32+3Хочется еще упомянуть
ncdu, альтернативуduс более понятным интерактивным интерфейсом для определения, что в текущей папке все место съело.
overmind88
23.01.2023 11:54gdu на больших объёмах заметно быстрее работает, но не во всех дистрибутивах есть в репозиториях
DungeonLords
23.01.2023 12:09Товарищи!
Много читаю про Разбивку диска для установки Linux. Но как правило люди делают это или через графические утилиты типа gnome-disk-utility или через консольные интерактивные. Только недавно я увидел язык описания разметки диска genimage Вопрос: это единственный такой проект?
Stanislavvv
23.01.2023 12:27Обычно используют что-то вроде sfdisk для разбивки. Ну или parted. А всякие описания разделов делают в ansible, как универсальном средстве конфигурации всей системы.
mrsantak
23.01.2023 13:21ripэто безопасный, эргономичный и производительный инструмент для удаления файлов.От авторов "проактивный и быстрообучаемый". Ну серьезно, какая эргономика и производительность по отношению к замене rm?
solarplexus
23.01.2023 15:03Есть прога, похожая на zoxide, которой я часто пользуюсь - Warp Directory.
DungeonLords
23.01.2023 17:07Пользуясь случаем представляю свой скрипт "безопасный dd" для записи образа на флешку.
Leksat
24.01.2023 09:48Стараюсь не пользоваться такими штуками, чтоб, как тут уже упомянули, не теряться на серверах где всего этого добра нет. Но пользую https://github.com/ellie/atuin
Оно хранит историю команд и предлагает удобный поиск по ней. И по желанию может хранить все в облаке.
Настроил так, чтобы по ctrl+r был atuin, а по стрелке вверх - стандартный переход на предыдущую команду. Теперь на любой вкладке терминала у меня есть вся история. Ну и поиск тоже выручает.
Если будете ставить, рекомендую не ограничиваться readme, но и по всей документации пройтись. Там не очень очевидно что большая ее часть спрятана, вот тут ссылки: https://github.com/ellie/atuin#documentation
Pogan
24.01.2023 15:11-1"исправление минорных ошибок."
Грустно-то как прозвучало... Автор, по-русски: "исправление мелких ошибок" или лучше: "небольшие исправления". Спасибо заранее.
ComradePashka
25.01.2023 13:51Зашел из-за тега DevOps, а тут про "вкусовщину" уровня пользователя.
Ну раз так, то мой личный единственный грешок, который я устанавливаю почти в любой *nix системе с которой приходится по долгу работать -- Midnight Commander, который наверное с половину функционала перечисленных утилит покрывает.
Все остальное, как отметил @mirwide, -- зло! Лушче уметь быстро ориентироваться в любой (даже новой, незнакомой) среде и знать не только про набор стандартных утилит (и их версии в разных дистро), а про например всякие там псевдофайловые системы типа /proc и прочие особенности, а не тащить вот это все в попытке сделать из шелла швейцарский нож.
Про образы/контейнеры, которые мы все пытаемся сделать наиболее легковесными и быстрыми я вообще молчу.
P.S. Вообще этот пост напомнил мне эдакого сферического около-IT-шника из 90ых/нулевых (мы все знаем хотя бы одного такого), когда траффик был еще дорогой, а CD/DVD были в полном расцвете сил, который при всякой встрече задавал один стандартный вопрос: "есть какой-нибудь новый софт?" Вот напоминает *nix-версию такого "IT-Плюшкина" :-)
mirwide
Для админов(а кто еще живёт в консоли) использование утилит аналогов стандартным - злеейшее зло. Лучше использовать всё стандартное, что бы зайдя на рандомный сервер, можно было всё делать на автомате, а не вспоминать в чём же там отличия. В качестве бонуса, не нужно тратить полдня на настройку нового ноутбука под себя, можно работать с любого.
Про автоисправление уже написали, это крутая фича в IDE, где будет ревью, тесты и тд. Но не в консоли, где может не быть ни каких доп проверок, а ошибка может стоить очень дорого.