Комментарии 110
главная особенность у mosh в том что он работает поверх UDP о чём в статье забыли упомянуть. Т.е. с менее стабильным интренетом будет работать проще чем с обычным ssh поверх tcp который будет отваливаться и тебе прийдётся переподключаться. ssh + screen насколько помню решает только проблему с тем что сессия не потеряется
Добавил больше информации про mosh.
Вот удобная альтернатива mosh: https://eternalterminal.dev/
Из-за того, что mosh не сохраняет локальную историю, по факту даже с mosh пригождается tmux или screen. Как уже упомянули выше, главные преимущества mosh это предиктивное эхо (по сути практически до 0 устраняет задержку при вводе текста) и возможность переключать сеть и прочее не теряя сессию.
Если серверов большое корреспондент, то установить все это будет не возможно по разным причинам. По этому намного полезнее уметь и знать дефольные утилиты
Вот этот https://ru.wikipedia.org/wiki/GNU_parallel ?
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
«Интуитивно понятные» названия, если выражаться слогом статьи.
Как можно догадаться что они делают?
Как можно догадаться какую надо использовать, если надо что-то сделать?
Почему программисты не следуют советам, которые сами же дают другим программистам по наименованию?
Или пользователи это другое?
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)
Посмею добавить свое смешное мнение.
exa (examine) — скорее экспрессивное "че за...?!"
ls (list) — скорее нейтральное "а хто тута?"
Имел случай, когда по какой-то причине в некотором каталоге накопилось более 40К файлов. ls — падал, даже ls -Uне помог, только find -type f. Интересно, в таком разрезе, как некоторые из предлагаемых, несомненно прекрасных, утилит справляются с такими проблемами?
Скорее всего, в программе на C используется статический буфер, размера которого должно хватить всем. Если так не делать (на любом языке) — не будет этой проблемы.
Только что для примера нагенерил миллион файлов со средней длинной имени >100 символов — всё ок.
ls без маски использовался? Обычная ситуация, когда маска раскрывается в слишком длинный список и шелл не может запустить команду, но это не проблема ls.
$ ls *
bash: /bin/ls: Argument list too long
Есть история про это
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 минут я нашёл только поверхностные сравнения:
Хорошие названия консольных утилит краткие и уникальные
Командная строка не предоставляет средств для легкого изучения новых команд, к сожалению. Их прежде всего должно быть легко и быстро печатать, а сами команды и их свойства можно нагуглить при желании :).
Как можно догадаться что они делают?Как будто стандартные команды имеют очевидные названия… Почему cat, если должен быть concat, при чём здесь котики? Почему вывод строк в обратном порядке — tac, а не reversecat? ls??? ps??? Не зная истории, как догадаться, что grep — это поиск регулярными выражениями? Может, [ — хорошее название?
Почему бы им не последовать?
Я бы сказал, что конкретно [ — не такое уж и плохое название — при написании конструкций вроде [ -lt $a $b ] выглядит вполне прилично, маскируясь под синтаксис языка (и в итоге породив [[ ]], которое уже настоящий синтаксис). А если не устраивает такая форма, можно использовать test, менее "магическое" название той же утилиты.
Вот-вот, у меня ощущение, что я наткнулся на сундук с бриллиантами, но не могу их взять — из рук выскальзывают (( как всё это запомнить?? И если потом привыкну к ним, как работать с системой, где это все не установлено? (
Мне кажется, что удобнее будет сделать автозамену и не париться с запоминанем. Как с классическим ls:
alias ls='ls --color=auto'
Надо просто по одному добавлять инструменты. А ещё, запомнить помогают такие штуки как Anki — можно туда набить карточек с вопросами "Если я хочу получить список файлов, какая команда в терминале мне нужна?" на разные лады и с перечислением всяких полезных опций, то благодаря тому, что это активное вспоминание и идёт по правильному расписанию, содержимое вбивается в мозги просто замечательно.
Ну мне больше нравится mindforger, так что если я что-то забываю, потому что редко пользуюсь, я заглядываю в свои блокнотики и всё становится хорошо! Главное не забывать записывать и правильно расставлять хэштеги!
И если потом привыкну к ним, как работать с системой, где это все не установлено?написать маленький плейбук на ансибле, который их доустановит. Или собирать пакером образ сразу с ними всеми. Или страдать :)
Отнюдь не претендую на истину в последней инстанции, но я бы предложил строку вызова давать в виде текста. Тогда ее всегда можно скопировать в консоль и тут же поиграться с параметрами. А результат работы уже можно представить по разному:
- если это просто текст — то пусть и будет текст
- если важно показать цветовое оформление — то можно и графический скриншот
- если вывод достаточно длинный — то результат спрятать под кат, чтобы не раздувать статью
Кажется, что Rust (и, в меньшей степени, Go) очень хорошо подходит для написания небольших и очень производительных консольных утилит, так что ИМХО выбор языка вполне оправдан в 2021 году-то :).
Недавно тут статья про exa была, и выяснилось, что в отличие от ls эта самая exa в размере в 10 раз больше чем ls, и при этом тянет кучу системных библиотек, в отличие от ls, которая только libc тянет. Так что нет — ни разу не 'небольших'.
А какой примерно размер у ls и у exa? Если, допустим, ls весит 500 Кб, а exa 5 Мб, то ИМХО всё равно можно считать бинарник небольшим, поскольку функциональность не сравнить, стартует он всё равно мгновенно, даже если «на холодную», и т.д. Если это 5 Мб против 50, то тут уже наверное можно о чём-то поспорить, но я лично не верю, что там бинари настолько большие получаются.
Что-то мне подсказывает что есть связь с https://zaiste.net/posts/shell-commands-rust/ :-)
Потому что на расте быстрее и проще написать подобные утилиты
Подробнее на русском myroad.club/kak-ispolzovat-komandu-fd-v-linuxТочно на русском? Слова-то вроде все русские, а вот текст в целом выглядит странно, и не во всех предложениях вообще есть смысл:
Он имеет упрощенный синтаксис, использует разумные значения по умолчанию и обладает встроенным поведением здравого смысла. Давайте пройдем его темпами.
fd команда не предназначена для замены традиционный find команда, которая имеет был на линуксе, ну вечно
Красиво, но пёстровато. У всех этих утилит есть несомненно большой недостаток — они написаны на достаточно экзотическом языке и требуют отдельной установки, которого по умолчанию в системе нет. Мне встречались системы без perl, хотя, к счастью, там были команды из "великой тройки", то есть grep/sed/awk.
У всех этих утилит есть несомненно большой недостаток — они написаны на достаточно экзотическом языке и требуют отдельной установки, которого по умолчанию в системе нет.
Rust — компилируемый язык. Если вы ставите эти утилиты из репы вашего дистрибутива, то никакого Rust-специфичного рантайма в системе не будет.
Я умею это и понимаю, что есть ситуации когда оно нужно.
Но по моему это скорее исключение.
А реально что то делаешь или в графической среде или, если совсем беда, в MC и ему подобном.
По крайней мере я использую все утилиты командной строки только в скриптах. А там мне без разницы насколько оно красивее и изящнее. Важно лишь что бы данная утилита имелась в наличии.
А многие ли работают в командной строке?
Ну допустим я.
Вообще, это удобно, если уметь.
К примеру, как бы вы решали задачу взять json(массив записей), вытащить из него авторов каждой записи(они там прописаны), посчитать число записей на автора и отсортировать их по убыванию? Можно конечно написать скрипт на Python, а можно воспользоваться утилитками командной строки, включая приведенный тут jq.
Аналогичная задачка — быстро найти закоммиченные в VCS симлинки. Здесь нет на самом деле привязки к VCS, просто поиск симлинков в директории был интересен именно для этого.
А после какого-то количества лет работы с linux большинство вещей быстрее сделать через консольные команды.
К тому же, написанный однострочник командами можно потом запихнуть в скрипт, а вот список действий из MC — врятли.
Хотя, возможно, стандарты и пора расширить и углУбить.
Спасибо. Я часть добавил и наткнулся на пост https://xakinfo.ru/network_administration/sysadmin-tools/
Если я не успею и не добавлю остальные, вы пожалуйста напишите комментарий.
Добавил sponge. Спасибо.
Как вы бы описали утилиту sponge?
Sponge легко эмулируется с помощью awk, также perl, который есть почти всегда, и python и другими, которые иногда уже установлены по умолчанию.
Например, https://github.com/ildar-shaimordanov/perl-utils#sponge
Если внимательно подумать, то и редирект в какой-нить
dd bs=$(cat /proc/meminfo|head -n2|sed '1d;s/^MemFree\:\s*//;s/ kB$//') of=/dev/stdoutсойдёт. ;-) Ну это если памяти не жалко. Зато засосёт что твой Спанчбоб, и есть везде.
Есть ещё bottom, — конфигурируемый аналог htop на Rust.
Но единственный минус привыкания к новым утилитам в замен старым — их нужно ставить
Когда у тебя 10+ серверов в разных инфраструктурах и ты привыкаешь к таким вариантам — эффективность использования консоли может резко упасть на нет
Пока писал комментарий, понял — нужно написать утилиту «установщик», которая умеет смотреть в репозиторий для подтягивания конфига.
Выложить эту утилиту в самые распространённые дистрибутивы, научить её подтягивать конфиг со своего репо с настройкой (так можно под рукой держать несколько репозиториев с разными пресетами) и одной командой устанавливать на сервер то, что описано в пресете.
А ещё уметь обновляться нужно. Например — обновляешь свой пресет, логинишься в консоли и утилита автоматически посмотрит в использованный ранее пресет и увидит, что что-то изменилось и предложит доустановить.
Если есть такое — дайте ссылку, буду очень благодарен.
Пока писал комментарий, понял — нужно написать утилиту «установщик»
Это называется Ansible/Chef/etc
На самом деле была утилита, которая скачивала и устанавливала подобные утилиты. Но я не помню.
А зачем велосипед то изобретать? Пишешь playbook со всеми нужными утилитами, кладёшь их в локальную репу, раскатываешь на все сервера. При изменении — повторяешь. Profit.
Нашел. https://github.com/devops-works/binenv
Попозже добавлю в пост.
Баловство, но зато интерактивное: up — the Ultimate Plumber.
ncdu — простой и удобный инструмент для просмотра размера каталогов и освобождения места на диске
htop — не понимаю, как его можно не упомянуть
А может кто посоветует… наверняка же есть утилита, чтобы в неё вбить десяток частых команд типа "systemctl restart httpd" и вызвать их через (псевдо)графическое меню или номер, вроде "shortcut 1"..?
Автокомплит по Ctrl+R?
Еще можно насоздавать скриптов в ~/.local/bin
В zsh просто великолепнейший автокомплит (включая ключи и параметры), подсветка синтаксиса и вот это всё. Разумеется с плагинами, куда-ж без них. Ну а так, через fzf можно что-то такое организовать. А ещё есть всякие странные менеджеры всего подряд...
По нарастанию гибкости использования: алиасы, шелл-функции, шелл-скрипты.
в .basrc алиасы и функции
alias sreht='systemctrl restart httpd'
но надоедает, а вот функции уже имеют смысл
sreht () {
nginx -t || echo "товарищь, смотри воба " && return 13
systecmctl restart httpd
moncho.github.io/dry
gh — утилита для работы с GitHub из консоли, например можно создать Pull Request
github.com/cli/cli
gitlab — аналогичная утилита для работы с GitLab (неофициальная)
github.com/NARKOZ/gitlab
watch — запуск любой команды каждые N секунд, позволяет на раз-два сделать реалтайм мониторинг в консоли
runnel — автоматический запуск туннелей SSH с переподключением при обрыве соединения
Для редких случаев работы с kernel ещё можно добавить kmon. Его уже упоминали в схожей публикации https://habr.com/ru/post/495882/
Полезные консольные Linux утилиты