Открыть список
Как стать автором
Обновить

Комментарии 108

вместо mosh можно использовать обычную связку ssh+ screen

главная особенность у mosh в том что он работает поверх UDP о чём в статье забыли упомянуть. Т.е. с менее стабильным интренетом будет работать проще чем с обычным ssh поверх tcp который будет отваливаться и тебе прийдётся переподключаться. ssh + screen насколько помню решает только проблему с тем что сессия не потеряется

Добавил больше информации про mosh.

Из-за того, что mosh не сохраняет локальную историю, по факту даже с mosh пригождается tmux или screen. Как уже упомянули выше, главные преимущества mosh это предиктивное эхо (по сути практически до 0 устраняет задержку при вводе текста) и возможность переключать сеть и прочее не теряя сессию.

Сам mosh давно хочу попробовать, но не пробовал.

Пользуюсь связкой autossh+screen, которую обычно называют rscreen.

При этом скроллить в скрине или тмуксе тот еще ад. Поэтому пришлось отказаться от мош и подобного т.к. локальный скролл просто необходим...

mosh + tmux гораздо круче, чем ssh + screen.

Если серверов большое корреспондент, то установить все это будет не возможно по разным причинам. По этому намного полезнее уметь и знать дефольные утилиты

Они не столь опрятны и приятны. К тому же уныло монохромные!

Именно. Шаблоны для командной строки + параллельная обработка файлов + функция обработки файлов на других компьютерах.

Добавил. Спасибо.

Bat
Exa
Fd
Procs
Sd
Dust
Starship
Ripgrep
Ripgrep-all
Grex
Fzf
Jq
Peco
HTTPie
Rebound
HTTP Prompt
shell2http
reachable
Lazydocker
Clog-cli
Gotty
mosh
ngrok
teleconsole
tmate

«Интуитивно понятные» названия, если выражаться слогом статьи.
Как можно догадаться что они делают?
Как можно догадаться какую надо использовать, если надо что-то сделать?
Почему программисты не следуют советам, которые сами же дают другим программистам по наименованию?
Или пользователи это другое?

Тут 2/3 названий это минимальная модификация названия старой программы, которую заменяют. А старое название зародилось ещё когда 640кб хватало всем.

Fd — это простой, быстрый и удобный инструмент, предназначенный для более простой и быстрой работы по сравнению с командой find.

Sd также в 2-11 раз быстрее, чем sed.

Судя по новым названиям, теперь счёт на биты идёт?

Особенно ls (LiSt of files) -> exa (wtf??) интуитивно понятно (coвсем нет).
Также sed (Stream EDitor) — -> sd (sd card?? )
find -> fd (File Descriptor??)

exa — вероятно, examine (files)

А lsattr что за атрибуты показывает? ;)

По первому предположению:


exa -ld@ D[er]*
drwxr-xr-x@ - nez 16 апр 19:37 Desktop
                               └── security.selinux (len 37)
drwx------@ - nez  3 апр 20:12 Dropbox
                               └── user.com.dropbox.foldericon (len 13)

Значит имелись ввиду расширенные атрибуты системной информации, а не файла

Посмею добавить свое смешное мнение.


exa (examine) — скорее экспрессивное "че за...?!"
ls (list) — скорее нейтральное "а хто тута?"


Имел случай, когда по какой-то причине в некотором каталоге накопилось более 40К файлов. ls — падал, даже ls -Uне помог, только find -type f. Интересно, в таком разрезе, как некоторые из предлагаемых, несомненно прекрасных, утилит справляются с такими проблемами?

Скорее всего, в программе на C используется статический буфер, размера которого должно хватить всем. Если так не делать (на любом языке) — не будет этой проблемы.

Это очень странно, 40 тысяч файлов — не так много, у ls не должно возникать таких проблем, тем более у ls -U.
Только что для примера нагенерил миллион файлов со средней длинной имени >100 символов — всё ок.
ls без маски использовался? Обычная ситуация, когда маска раскрывается в слишком длинный список и шелл не может запустить команду, но это не проблема ls.
$ ls *
bash: /bin/ls: Argument list too long


32k мягкий лимит для ls, потом труднее идёт.
Есть история про это
Статья интересная, спасибо. В частности там говорится:
1. ls, find и питоновский os.readdir() используют одну и ту-же функцию glibc readdir для чтения каталога. Поэтому остается непонятным почему у автора коммента выше ls падал а find отрабатывал.
2. 32К это размер буфера с которым readdir вызывает syscall getdents, и это так для любой программы использующей readdir (ls, find, os.readdir(), etc), поэтому слова о том что 32К это «мягкий лимит для ls» — звучат странно.

Да, формулировку "мягкий лимит" подобрал некорректно.
В целом, резюме по статье поясняет, что это особенность реализация на системной функции.
Ради интереса можно поискать результаты замеров по скорости для exa, ls или lsd, на таких специфичных случаях.
За 10 минут я нашёл только поверхностные сравнения:


Мой вопрос был не по поводу быстродействия, а по поводу утверждения, что ls -U не справлся с каталогом с 40к файлов, а find отрабатывал нормально.
По поводу быстродействия exa, которая на порядок медленнее ls — это скорее к авторам статей, которые рекламируют exa как заену ls.

Хорошие названия консольных утилит краткие и уникальные

Уникальные? fd — уникальное название? sd?

Ну у меня таких команд в системе нет

Командная строка не предоставляет средств для легкого изучения новых команд, к сожалению. Их прежде всего должно быть легко и быстро печатать, а сами команды и их свойства можно нагуглить при желании :).

Команды нужны чтобы их набирать, поэтому названия должны быть максимально короткими
Зачем их набирать? Автодополнение уже изобрели.
Как можно догадаться что они делают?
Как будто стандартные команды имеют очевидные названия… Почему cat, если должен быть concat, при чём здесь котики? Почему вывод строк в обратном порядке — tac, а не reversecat? ls??? ps??? Не зная истории, как догадаться, что grep — это поиск регулярными выражениями? Может, [ — хорошее название?
С тех пор написаны книги по лучшим практикам программирования.
Почему бы им не последовать?
Многие вмето использования ip доустанавливают ifconfig потому что «20 лет пользовались и всё нормально было, что переходить-то», а вы названиями недовольны…
Кстати, в PowerShell названия многих команд вполне логичные и осмысленные, но неудобные до жути

Я бы сказал, что конкретно [ — не такое уж и плохое название — при написании конструкций вроде [ -lt $a $b ] выглядит вполне прилично, маскируясь под синтаксис языка (и в итоге породив [[ ]], которое уже настоящий синтаксис). А если не устраивает такая форма, можно использовать test, менее "магическое" название той же утилиты.

Вот-вот, у меня ощущение, что я наткнулся на сундук с бриллиантами, но не могу их взять — из рук выскальзывают (( как всё это запомнить?? И если потом привыкну к ним, как работать с системой, где это все не установлено? (

Переформатировать статью в формат fortunes, добавить в /usr/share/games/fortunes/commands-2021. Юмористические списки из запуска fortune убрать.

Мне кажется, что удобнее будет сделать автозамену и не париться с запоминанем. Как с классическим ls:
alias ls='ls --color=auto'

alias ls='ls --color=auto'
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

в ubuntu по умолчанию

Надо просто по одному добавлять инструменты. А ещё, запомнить помогают такие штуки как Anki — можно туда набить карточек с вопросами "Если я хочу получить список файлов, какая команда в терминале мне нужна?" на разные лады и с перечислением всяких полезных опций, то благодаря тому, что это активное вспоминание и идёт по правильному расписанию, содержимое вбивается в мозги просто замечательно.


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

Надо просто по одному добавлять инструменты. А ещё, запомнить помогают такие штуки как Anki — можно туда набить карточек с вопросами "Если я хочу получить список файлов, какая команда в терминале мне нужна?" на разные лады и с перечислением всяких полезных опций, то благодаря тому, что это активное вспоминание и идёт по правильному расписанию, содержимое вбивается в мозги просто замечательно.

Ну мне больше нравится mindforger, так что если я что-то забываю, потому что редко пользуюсь, я заглядываю в свои блокнотики и всё становится хорошо! Главное не забывать записывать и правильно расставлять хэштеги!

Ух ты, спасибо! А то я уже в Трелло стал запихивать "базу знаний"!

Да тут не принципиально, главное чтобы был механизм для активного вспоминания по расписанию — это даёт 95% эффекта, а конкретная форма — остальные 5%.


Правда навскидку в mindforger'е такого не вижу, больше похоже просто на инструмент для заметок, но может проглядел.

Может быть лучше не приводить демонстрацию работы консольных команд в виде анимации? Не знаю у кого как, но у меня от такой подачи рябит в глазах и я с трудом узнаю вывод даже хорошо знакомых утилит.

Отнюдь не претендую на истину в последней инстанции, но я бы предложил строку вызова давать в виде текста. Тогда ее всегда можно скопировать в консоль и тут же поиграться с параметрами. А результат работы уже можно представить по разному:
  • если это просто текст — то пусть и будет текст
  • если важно показать цветовое оформление — то можно и графический скриншот
  • если вывод достаточно длинный — то результат спрятать под кат, чтобы не раздувать статью
Тогда ссылки на подобные статьи можно было бы коллекционировать как действительно крайне полезный материал.

Добавил. Спасибо.

Больше половины списка написано на Rust. Это тенденция в консольном новострое или автор специально так подбирал?

Кажется, что Rust (и, в меньшей степени, Go) очень хорошо подходит для написания небольших и очень производительных консольных утилит, так что ИМХО выбор языка вполне оправдан в 2021 году-то :).

Недавно тут статья про exa была, и выяснилось, что в отличие от ls эта самая exa в размере в 10 раз больше чем ls, и при этом тянет кучу системных библиотек, в отличие от ls, которая только libc тянет. Так что нет — ни разу не 'небольших'.

А какой примерно размер у ls и у exa? Если, допустим, ls весит 500 Кб, а exa 5 Мб, то ИМХО всё равно можно считать бинарник небольшим, поскольку функциональность не сравнить, стартует он всё равно мгновенно, даже если «на холодную», и т.д. Если это 5 Мб против 50, то тут уже наверное можно о чём-то поспорить, но я лично не верю, что там бинари настолько большие получаются.

Не принципиально много в современном мире.


$ du -h =exa
836K    /usr/bin/exa

Или тенденция или тот факт, что многие пишушие на расте имеют какой-то набор ценностей и навыков, позволяющий (и дающий желание) переписать уже существующие утилиты с нуля из первых принципов с учётом многолетнего накопленного опыта использования этих утилит. Ну, а сам раст даёт возможность получить безбажную и быструю реализацию, что идёт на пользу популярности этих утилиток.

Спасибо за ссылку. Нашел там github.com/imsnif/bandwhich — net monitor с раскладкой по процессам, который работает на FreeBSD. Раньше такого не видел, потому что у FreeBSD нет /proc и стандартные утилиты мира linux вроде NetHogs не умеют per_proccess. Этот bandwhich умеет. BSDшникам рекоммендую.)

Добавил. Спасибо. Есть ли какие-либо еще преимущества, кроме FreeBSD и кроме раскладки по процессам?

Потому что на расте быстрее и проще написать подобные утилиты

Подробнее на русском myroad.club/kak-ispolzovat-komandu-fd-v-linux
Точно на русском? Слова-то вроде все русские, а вот текст в целом выглядит странно, и не во всех предложениях вообще есть смысл:
Он имеет упрощенный синтаксис, использует разумные значения по умолчанию и обладает встроенным поведением здравого смысла. Давайте пройдем его темпами.
fd команда не предназначена для замены традиционный find команда, которая имеет был на линуксе, ну вечно

Красиво, но пёстровато. У всех этих утилит есть несомненно большой недостаток — они написаны на достаточно экзотическом языке и требуют отдельной установки, которого по умолчанию в системе нет. Мне встречались системы без perl, хотя, к счастью, там были команды из "великой тройки", то есть grep/sed/awk.

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

Rust — компилируемый язык. Если вы ставите эти утилиты из репы вашего дистрибутива, то никакого Rust-специфичного рантайма в системе не будет.

jq в репозитории Debian есть абсолютно точно.

Не могу вспомнить ни одной программы из Debian, которой на входе или выходе необходим json. Для всяких web API это почти стандарт, да.

Именно «для всяких web API», если их надо обработать bash-ем: curl выдает на выходе json, а дальше в конвеер ставим jq.
А многие ли работают в командной строке?
Я умею это и понимаю, что есть ситуации когда оно нужно.
Но по моему это скорее исключение.
А реально что то делаешь или в графической среде или, если совсем беда, в MC и ему подобном.

По крайней мере я использую все утилиты командной строки только в скриптах. А там мне без разницы насколько оно красивее и изящнее. Важно лишь что бы данная утилита имелась в наличии.
А многие ли работают в командной строке?

Ну допустим я.
Вообще, это удобно, если уметь.
К примеру, как бы вы решали задачу взять json(массив записей), вытащить из него авторов каждой записи(они там прописаны), посчитать число записей на автора и отсортировать их по убыванию? Можно конечно написать скрипт на Python, а можно воспользоваться утилитками командной строки, включая приведенный тут jq.
Аналогичная задачка — быстро найти закоммиченные в VCS симлинки. Здесь нет на самом деле привязки к VCS, просто поиск симлинков в директории был интересен именно для этого.

mc хорошо, пока вы новичек.
А после какого-то количества лет работы с linux большинство вещей быстрее сделать через консольные команды.
К тому же, написанный однострочник командами можно потом запихнуть в скрипт, а вот список действий из MC — врятли.
Пользуюсь и mc и far2l.
far2l, как более функциональная замена mc.
Стандартные утилиты имеют свои проблемы и порой кажутся неудобными, но их неоспоримое преимущество в том что они вылизаны и стандартизованы, причём уже очень много десятков лет. Они предустановлены в любой ГНУ/Линукс системе и других поддерживающих соответствующие стандарты. Для них вы найдёте тысячи готовых рецептов почти для любой мыслимой задачи.

Хотя, возможно, стандарты и пора расширить и углУбить.

Есть еще отличный набор утилит moreutils:
https://ostechnix.com/moreutils-collection-useful-unix-utilities/


Правда из него чаще всего использую только sponge. Но одна только эта утилита полностью оправдывает установку пакета.


Еще из дополнительных использую delta:
https://dev.to/cloudx/delta-a-new-git-diff-tool-to-rock-your-productivity-2773


Раскрашивает вывод diff, может выводить diff разными способами (например, в две колонки с изменениями).


Что касается некоторых из описанных утилит, то некоторые вообще не зашли. exa, например: от ее вывода в глазах рябило. Раскрашенный ls для меня комфортнее. bat тоже применения не нашёл. Больше похоже на игрушку, нежели на реально полезный инструмент.

Добавил sponge. Спасибо.
Как вы бы описали утилиту sponge?

Если внимательно подумать, то и редирект в какой-нить


dd bs=$(cat /proc/meminfo|head -n2|sed '1d;s/^MemFree\:\s*//;s/ kB$//') of=/dev/stdout

сойдёт. ;-) Ну это если памяти не жалко. Зато засосёт что твой Спанчбоб, и есть везде.

Как Вы сложно выразились в субшелле. Можно ж было проще, например так:


cat /proc/meminfo | awk '/MemFree/ { print $2 }'

И даже cat лишний:


awk '/MemFree/ { print $2 }' /proc/meminfo

Да. Вечно я про возможности awk забываю… :( Использую, в основном, как калькулятор числовых значений из всяких табличек.

Есть ещё bottom, — конфигурируемый аналог htop на Rust.

Добавил. Спасибо. А вы пользуетесь bottom?

Спасибо!
Но единственный минус привыкания к новым утилитам в замен старым — их нужно ставить
Когда у тебя 10+ серверов в разных инфраструктурах и ты привыкаешь к таким вариантам — эффективность использования консоли может резко упасть на нет

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

Если есть такое — дайте ссылку, буду очень благодарен.
Пока писал комментарий, понял — нужно написать утилиту «установщик»

Это называется Ansible/Chef/etc

На самом деле была утилита, которая скачивала и устанавливала подобные утилиты. Но я не помню.

А зачем велосипед то изобретать? Пишешь playbook со всеми нужными утилитами, кладёшь их в локальную репу, раскатываешь на все сервера. При изменении — повторяешь. Profit.

  • mtrMyTraceRoute Великолепная замена traceroute и аналогам
  • gdu — Более шустрый и фичастый аналог ncdu (ncurses du), на Go. Удобнее штатного du, при разборах «куда же делось свободное место».

Добавил. Спасибо.

ncdu — простой и удобный инструмент для просмотра размера каталогов и освобождения места на диске
htop — не понимаю, как его можно не упомянуть

htop, htop их же все знают. Или все таки стоит добавить?

«Плохо кончится...» © А то если в эту хтонь погружаться, пойдут всякие gotop, bashtop, bpytop… Тысячи их! Всё равно пизже связки top / htop / atop, пока ещё ничего не придумали.

bat оказался такой себе заменой
image
Я по-английски читаю более-менее, но когда начинаю писать, то не уверен, что меня поймут.
Написал, как сумел.
Оказывается, с весны прошлого года проблема уже известна, и с зимы ею занимаются.

А может кто посоветует… наверняка же есть утилита, чтобы в неё вбить десяток частых команд типа "systemctl restart httpd" и вызвать их через (псевдо)графическое меню или номер, вроде "shortcut 1"..?

Автокомплит по Ctrl+R?
Еще можно насоздавать скриптов в ~/.local/bin

да, но почему-то представлял себе такую менюшку как в mc по F2, только без mc ))

Поставить fzf, и оно заменит Ctrl-R и там будет список команд с быстрым поиском. Можно заморочиться, добавить туда сортировку по частоте/времени использования (frecency), но готовых таких штук вроде нет. Что-нибудь такое, но отрезать для себя только нужные части

В zsh просто великолепнейший автокомплит (включая ключи и параметры), подсветка синтаксиса и вот это всё. Разумеется с плагинами, куда-ж без них. Ну а так, через fzf можно что-то такое организовать. А ещё есть всякие странные менеджеры всего подряд...

По нарастанию гибкости использования: алиасы, шелл-функции, шелл-скрипты.

в .basrc алиасы и функции
alias sreht='systemctrl restart httpd'
но надоедает, а вот функции уже имеют смысл
sreht () {
nginx -t || echo "товарищь, смотри воба " && return 13
systecmctl restart httpd

dry — менеджер для Docker, по ощущениям гораздо быстрее и отзывчивее чем «LazyDocker»
moncho.github.io/dry

gh — утилита для работы с GitHub из консоли, например можно создать Pull Request
github.com/cli/cli

gitlab — аналогичная утилита для работы с GitLab (неофициальная)
github.com/NARKOZ/gitlab

watch — запуск любой команды каждые N секунд, позволяет на раз-два сделать реалтайм мониторинг в консоли

runnel — автоматический запуск туннелей SSH с переподключением при обрыве соединения
список очень большой, хотелось бы чтобы было какая-то сегментация по области применения и сравнение. а так получается, что вы как гугл поработали :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.