grep - возможности, о которых вы могли не знать

Все знают grep "что-то" файл. Но в утилите есть тёмные углы, которые превращают её из поиска строк в настоящий анализатор логов и кода.

➤ Вариант 1 (Поиск по временному диапазону в логах): логи обычно начинаются со времени. Нужно вытащить кусок между двумя метками.

# Логи с 10:00 до 10:15
grep "^2026-04-13 10:[0-1][0-9]" app.log

# С помощью флага -A (after) и -B (before)
grep -B 5 -A 10 "2026-04-13 10:15:00" app.log

➤ Вариант 2 (Поиск по сложным паттернам с переносом строк): когда ошибка размазана на несколько строк, а -A и -B не хватает.

# Использование pcre (Perl-совместимые регексы) через -P
grep -Pzo "(?s)Exception.*?\n\s+at.*?\n" app.log

# -z читает весь файл как одну строку
# -o выводит только совпадения
# -P включает переносы в регексах

➤ Вариант 3 (Работа с бинарными файлами): иногда нужно найти строку в дампе памяти или логе, который grep считает бинарным.

# Принудительно обрабатывать файл как текстовый
grep -a "password" memory.dump

# Или наоборот — исключить бинарники
grep -I "error" ./logs/*

➤ Вариант 4 (Статистика и группировка): не просто найти, а посчитать.

# Сколько раз встретился каждый код ответа в логах nginx
grep -oE '" [0-9]{3} ' access.log | sort | uniq -c | sort -rn

# -o выводит только совпадение (не всю строку)
# -E расширенные регексы

➤ Вариант 5 (Использование как фильтр с сохранением контекста): оставить в выводе только нужные колонки.

# Из строки "time=2026-04-13 level=error msg=crash"
grep -oP 'time=\K[^ ]+' app.log
# \K означает "начать вывод отсюда"

И главное, что забывают: grep можно комбинировать. Цепочка grep | grep -v | grep -o часто делает то, для чего в других языках пишут скрипты на 20 строк.

P.S. grep -c считает количество совпавших строк. grep -m 5 останавливается после пяти совпадений. Мелочи, которые экономят время.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Коллеги, всем доброго времени суток!

Чертовски рад сделать разговорный пост - давно их не было.

Думаю, многие заметили: постов стало меньше. Рассказываю, что произошло и когда снова будет разнообразие.

Помните голосование о миграции канала пару месяцев назад? Был там пункт про собственный сайт - тогда я его не сделал.

Теперь решил исправить.

После блокировок и новостей об импортозамещении (кстати, кого уже затронуло?) я ушёл в тему: можно ли своими силами с нуля запустить сайт?

Почему я этого хочу:
- код не превращается в кашу;
- статьи живут годами, а не тонут в ленте за два дня;
- туда помещается то, что сюда просто не влезает.

Сейчас сделал макет, разобрался с принципами. Основная работа позади - осталась доработка (а точнее - полная переработка макета в готовый продукт) и подготовка материалов.

Отвечая на главный вопрос: очень скоро посты снова выйдут на стабильный ритм.

P.S. В комментариях скриншот макета для тех, кому интересно. Если есть предложения - пишите, с удовольствием послушаю.

И если у вас есть опыт с хостингом, запуском сайтов, разработкой - делитесь. Любая информация пригодится😁

lsof - кто держит порт и открыл тот файл

Ситуация: пытаетесь запустить сервер, а он падает с "Address already in use". Порт занят, но кем? Или пытаетесь удалить файл, а система пишет "file is in use". Кто его держит?

lsof (List Open Files) отвечает на оба вопроса. В Linux «всё есть файл» - сетевые сокеты, пайпы, устройства, обычные файлы. lsof показывает, какие процессы какие «файлы» открыли.

Вариант 1 (Кто занял порт): классический кейс с запуском сервера.

# Кто слушает 3000 порт?
lsof -i :3000

# Вывод: COMMAND PID USER FD NAME
# node    1234 user  23u  IPv4 TCP *:3000 (LISTEN)

Вариант 2 (Какой процесс держит файл): не даёт удалить папку или файл.

# Кто использует файл лога?
lsof /var/log/app.log

# Кто работает в папке /home/user/project?
lsof +D /home/user/project

Вариант 3 (Все открытые файлы процесса): подозреваете конкретный процесс - смотрите, что он делает.

# Все файлы, открытые процессом с PID 1234
lsof -p 1234

# Сеть, которую использует процесс
lsof -p 1234 -i

Вариант 4 (Кто использует удалённый файл): монтирование не отдаёт, а кто мешает?

# Процессы, использующие файлы на смонтированном диске
lsof /mnt/usb

# Обычно это оболочка, которая "стоит" в папке на этом диске

lsof нужен, когда обычные инструменты молчат. Команда не показывает ошибку, но что-то мешает. lsof показывает «что именно» и «кто».

Альтернатива:

# Когда точно знаем, что ищем сетевой порт. Быстрее и чаще установлена по умолчанию.
ss -tlnp | grep 3000 

lsof выручает, когда:
1. Нужно посмотреть не только TCP, но и UDP
2. Проблема не с портом, а с файлом или папкой
3. Хотите увидеть все соединения процесса целиком

P.S. Самый частый сценарий: lsof -i :8080 - видим PID - kill -9 PID. Всё, порт свободен.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

strace - смотрим, что процесс делает на самом деле

Бывает, процесс висит, жрёт CPU, но не падает. Логи молчат. Что делать? Танцы с бубном? Нет. Есть strace - утилита, которая показывает все системные вызовы процесса.

В Linux любая программа постоянно общается с ядром: читает файлы, пишет в сокеты, выделяет память. strace перехватывает этот диалог и показывает его вам.

➤ Вариант 1 (Прицепиться к работающему процессу): процесс завис, но не умирает.

# Прицепиться к PID 1234
strace -p 1234

# Вывод:
# read(3, 0x7f8a2c000000, 4096) = -1 ETIMEDOUT (Connection timed out)
# Наглядно: процесс ждёт ответа от какого-то файлового дескриптора 3

➤ Вариант 2 (Запустить программу под strace): нужно понять, почему падает при запуске.

# Запускаем и смотрим
strace ./my_binary

# Ищем строки с -1 (ошибка)
strace ./my_binary 2>&1 | grep -1

➤ Вариант 3 (Фильтрация по конкретным вызовам): шума много, нужно только чтение файлов.

# Только open, read, write, close
strace -e trace=open,read,write,close ./my_binary

# Только сеть
strace -e trace=network ./my_binary

➤ Вариант 4 (Сохранить вывод в файл): процесс падает редко, нужно записать всё.

strace -o /tmp/strace.log ./my_binary

➤ Вариант 5 (Замерить время каждого вызова): где программа тормозит?

# -T показывает время выполнения каждого вызова
strace -T -e trace=read ./my_binary

# -c — сводная статистика в конце
strace -c ./my_binary

Когда strace бесполезен:
- Процесс тормозит, но не из-за системных вызовов (например, алгоритм O(n²))
- Проблема в самом ядре (туда уже нужен perf или trace-cmd)
- Программа работает с графикой/звуком через прямые вызовы драйверов

P.S. strace может влиять на производительность процесса в 10-100 раз. На проде прицепляйтесь аккуратно и ненадолго.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

ncdu - визуальный анализ того, куда делось место

Ситуация: сервер ругается, что диск заполнен на 95%. Вы запускаете df -h, видите, что корень почти полный. Дальше начинаются танцы с du -sh */ - приходится долбиться в каждую папку, спускаться глубже, терять нить, забываать, где были.

ncdu (NCurses Disk Usage) делает то же самое, но с интерактивным интерфейсом, где можно ходить стрелками и сразу видеть всё дерево папок.

Как это работает:

Запускаем ncdu / - утилита сканирует директорию (от 10 секунд до пары минут, в зависимости от объёма) и показывает список папок и файлов, отсортированный по размеру.

Навигация внутри ncdu:
- Стрелки вверх/вниз - перемещение по списку
- Enter - зайти внутрь папки
- Стрелка влево - вернуться назад
- d - удалить выбранный файл/папку (с подтверждением)
- n - сортировка по имени (по умолчанию — по размеру)
- q - выход

Вариант 1 (Быстрый анализ конкретной папки):

ncdu /var
# Тут же видно, что /var/log весит 40 гигабайт

Вариант 2 (Сканирование в фоне с сохранением результата):

# Сохранить результат сканирования
ncdu -o /tmp/disk_usage.json /home

# Потом посмотреть без повторного сканирования
ncdu -f /tmp/disk_usage.json

Вариант 3 (Исключить определённые папки):

# Не сканировать монтирования и временные папки
ncdu --exclude /mnt --exclude /tmp /

Из личной практики:

Диск забился на сервере с сайтами. df -h показал, что проблема в /var. Запустил ncdu /var - увидел, что /var/log/nginx весит 30 гигабайт. Зашёл туда стрелкой, увидел, что один лог-файл раздулся до нечеловеческих размеров. Нажал d, подтвердил удаление - место освободилось за 30 секунд. Без ncdu я бы тыкался руками ещё полчаса.

Почему лучше, чем `du`: интерактивность, наглядность, возможность удалять прямо из интерфейса. Не нужно запоминать путь, чтобы потом писать rm -rf.

P.S. На больших дисках (несколько терабайт) первое сканирование может занять несколько минут. Запускайте через screen или tmux, чтобы не оборвалось.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Коллеги, всех приветствую!

Помните пост про сайт? Рассказывал о планах, демонстрировал проделанную работу. Обещал делиться. Сделал даже больше, чем планировал.

Коротко: сайт практически готов. Код написан, тесты проходят, большая часть функций уже работает.

Что реализовано: статьи и гайды, регистрация и комментарии с модерацией, категории (Linux, DevOps, Python, Bash, Сети и другие), популярное в сайдбаре, тёмная тема, адаптив под телефоны, красивые ссылки, карта сайта, безопасность (CSRF, защита от частых запросов, санитизация и др.), всё под 152-ФЗ. В общем, полноценный блог.

Работы ещё немало, но основное уже сделано. Просто не так оно работает, как хотелось бы: где-то кнопки съехали, где-то дата не в том формате, где-то мобильное меню живёт своей жизнью.

Визуально сайт выглядит вполне готовым, но за красивой обложкой пока бардак. Работа велась по принципу «накидать и доработать» - сейчас как раз этап доработки.

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

В комментариях накидаю скринов, дабы можно было оценить проделанную работу😁

mtr - диагностика сети, которая показывает правду

Ситуация: сайт не открывается или работает медленно. ping говорит, что хост доступен. traceroute показывает маршрут, но не даёт понять, где именно проблема. Что делать?

mtr (My TraceRoute) объединяет ping и traceroute в одной утилите. Она показывает каждый узел на пути к серверу и статистику по потерям пакетов и задержкам на каждом из них. В реальном времени.

Базовый запуск:

mtr google.com

Запускается интерактивный интерфейс, который обновляется в реальном времени.

Вариант 1 (Запуск в режиме отчёта):

mtr -r -c 100 google.com

-r - режим отчёта (без интерактива), -c 100 - 100 пакетов. На выходе - готовая статистика для анализа или отправки провайдеру.

Вариант 2 (Только потеря пакетов, без графики):

mtr -r -c 50 --report-wide google.com

--report-wide расширяет вывод, чтобы IP-адреса не обрезались.

Вариант 3 (Ограничить количество прыжков):

mtr --max-ttl 10 google.com

Проверить только первые 10 узлов, если проблема явно недалеко от вас.

Вариант 4 (Использовать TCP вместо ICMP):

mtr --tcp --port 443 google.com

Некоторые сети блокируют ICMP (обычные ping-запросы). TCP-мод обходит это ограничение. --port 443 проверяет доступность конкретного порта (например, HTTPS).

Вариант 5 (Сохранить результат в файл и смотреть позже):

mtr --report google.com > report.txt

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

Как читать вывод `mtr`:

- Loss% - процент потерянных пакетов на узле. Если потери начинаются на каком-то узле и продолжаются на всех следующих - проблема именно на этом узле или на пути к нему.
- Snt - количество отправленных пакетов.
- Last / Avg / Best / Worst / Stdev - задержки в миллисекундах. Если на каком-то узле время резко скачет (например, с 20 мс до 200 мс), а на следующих узлах снова падает - это может быть нормальным поведением маршрутизатора (он обрабатывает ICMP в фоне). Но если тряска остаётся - есть проблема.

Важный нюанс: потери на промежуточных узлах не всегда означают проблему. Многие маршрутизаторы имеют низкий приоритет для ICMP-запросов и могут их отбрасывать, но обычный трафик (HTTP, SSH) пропускать без потерь. Ориентируйтесь на финальный узел: если на нём потерь нет - всё в порядке.

Возможные сценарии использования:

- Провайдер говорит «у нас всё работает» - запускаете mtr, видите 50% потерь на его оборудовании, отправляете отчёт. Слова заканчиваются.
- Сайт тормозит, но не падает - mtr показывает высокую задержку на одном из узлов за пределами вашей сети. Проблема не у вас.
- Выбираете хостинг - запускаете mtr до нескольких потенциальных хостов, сравниваете пинг и стабильность маршрута.
- VPN тормозит - mtr до конечного сервера показывает, где именно теряются пакеты (на входе в VPN или на выходе).

Что `mtr` не умеет: показывать проблемы на обратном пути (от сервера к вам). Для этого нужен mtr с той стороны.

P.S. В интерактивном режиме доступны горячие клавиши: r - перезапуск, d - переключить отображение, q - выход.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

screen — терминальный долгожитель, который не бросает дела при отвале SSH

Ситуация: вы зашли на сервер по SSH, запустили миграцию базы данных, которая идёт 40 минут. Закрыли ноутбук, пошли домой. Пришли утром — миграция оборвалась посередине, потому что SSH-сессия разорвалась, когда ноутбук уснул. Знакомо?

screen решает эту проблему. Это терминальный мультиплексор, который держит сессию на сервере независимо от вашего подключения. Потеряли интернет? Закрыли ноутбук? Ребутнули локальную машину? Сессия на сервере продолжает жить.

Базовые команды:

# Создать новую сессию (имя присвоится автоматически)
screen

# Создать сессию с именем (рекомендую)
screen -S deploy

# Отключиться от сессии (процесс продолжается)
# Ctrl+A, D

# Посмотреть список сессий
screen -ls

# Подключиться к последней отключённой сессии
screen -r

# Подключиться к сессии с конкретным именем
screen -r deploy

# Убить сессию (если она зависла)
screen -X -S deploy quit

Вариант 1 (Запуск команды в screen и отключение):

# Создать сессию, выполнить команду и отключиться
screen -d -m -S backup bash -c "rsync -av /data/ /backup/; exec bash"

-d -m — создать сессию в фоне. exec bash — оставить шелл после выполнения команды.

Вариант 2 (Режим только для чтения):

screen -r deploy -X

Подключиться к сессии, но ничего не писать. Удобно, когда коллега уже работает, а вы хотите просто посмотреть.

Вариант 3 (Логирование всего, что происходит в сессии):

Добавьте в ~/.screenrc:

logfile /var/log/screen/screen-%S.log
logfile flush 1
deflog on

Теперь все сессии пишут лог. Если что-то пошло не так — открываете лог и смотрите, что было.

Вариант 4 (Разделение окна на области):

- Ctrl+A, S — разделить окно горизонтально
- Ctrl+A, TAB — переключиться между областями
- Ctrl+A, c — создать новое окно в текущей области
- Ctrl+A, Q — убрать все области, оставить активную

Запустили htop в одной области, tail -f лога в другой — и переключаетесь между ними.

Вариант 5 (Переключение между окнами внутри сессии):

В одной сессии можно открыть несколько окон (как вкладки в браузере):
- Ctrl+A, c — создать новое окно
- Ctrl+A, n — следующее окно
- Ctrl+A, p — предыдущее окно
- Ctrl+A, " — список всех окон (выбрать стрелками)
- Ctrl+A, 0-9 — переключиться на окно по номеру

Вариант 6 (Скроллинг и копирование):

- Ctrl+A, [ — войти в режим копирования
- Стрелки / PageUp / PageDown — перемещаться
- Space — начать выделение, Space — закончить (текст скопирован в буфер)
- Ctrl+A, ] — вставить скопированное

Что выбрать: screen или tmux?

Оба решают одну задачу. У tmux больше возможностей (панели, поддержка мыши из коробки). У screen одно преимущество: он есть почти на всех серверах по умолчанию. Если вы подключаетесь к чужим серверам или работаете в legacy-среде — screen ваш выбор.

Главный совет: привыкните создавать сессию перед любым долгим процессом. Это занимает 2 секунды, а может спасти часы работы.

Используете screen или предпочитаете tmux?

P.S. Самый частый вопрос новичков: «я нажал Ctrl+A, D, а терминал закрылся, куда всё делось?». Сессия не пропала, она ушла в фон. Вернитесь через `screen -ls` и `screen -r`.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

Скрипт, который не ломается на втором запуске

Бывало такое: запускаете скрипт настройки сервера, а он орёт «пакет уже установлен» и падает? Или молча дублирует конфиги, а потом всё едет?

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

➤ Три функции, которые спасут ваши нервы

Кладёте в начало любого скрипта - и спите спокойно:

#!/bin/bash
set -euo pipefail

# Ставим пакет, только если его нет
ensure_pkg() {
    dpkg -s "$1" &>/dev/null && { echo "$1 уже стоит"; return 0; }
    echo "Ставим $1..."
    apt-get install -y "$1"
}

# Добавляем строку в файл, только если её там нет
ensure_line() {
    grep -qxF "$1" "$2" 2>/dev/null && { echo "Строка уже есть в $2"; return 0; }
    echo "$1" | tee -a "$2"
}

# Запускаем сервис, только если он не крутится
ensure_svc() {
    systemctl is-active --quiet "$1" && { echo "$1 уже работает"; return 0; }
    systemctl start "$1" && systemctl enable "$1"
}

Логика простая: сначала проверяем, потом делаем.

➤ Как это выглядит в деле

Вместо простыни из if-else пишете читаемый список желаемого:

echo "Пора наверное навести порядок..."

ensure_pkg "nginx"
ensure_pkg "jq"
ensure_pkg "htop"

ensure_line "vm.swappiness=10" /etc/sysctl.conf
sysctl -p &>/dev/null

ensure_svc "nginx"

echo "Закончили. Хоть десять раз запустите - ни одной ошибки не увидите :D."

По сути, мы только что написали декларативную спецификацию: говорим «что должно быть», а не «как сделать». Это ровно то, за что все любят Ansible и Terraform, только на голом bash.

➤ Где ещё пригодится этот приём

- SQL-миграции: CREATE TABLE IF NOT EXISTS вместо просто CREATE
- Работа с API: метод PUT идемпотентен, POST - нет
- CI/CD: повторный запуск пайплайна не должен создавать дубликаты артефактов
- Форма заказа на сайте: защита от двойного нажатия через идемпотентный ключ

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

zoxide — cd, который запоминает ваши привычки

Ситуация: вы работаете в трёх-четырёх проектах одновременно. Пути к ним выглядят примерно так: /home/user/projects/backend/api/src, /home/user/work/legacy/2024/frontend, /home/user/labs/experiments/rust/cool-tool. Каждый раз вводить полный путь или даже жать Tab несколько раз — утомительно.

zoxide — это cd, который запоминает, куда вы ходили, и позволяет переходить по короткому фрагменту имени. Чем чаще вы посещаете папку и чем недавнее это было, тем выше её рейтинг.

➤ Базовое использование:

Вместо:

cd /home/user/projects/backend/api/src

Пишете:

z api

zoxide сам найдёт папку, содержащую api в имени, и перейдёт туда.

# Создать базу данных посещённых папок (достаточно один раз)
zoxide init bash   # для bash
zoxide init zsh    # для zsh

# Добавить команду в .bashrc/.zshrc
eval "$(zoxide init bash)"

➤ Вариант 1 (Переход по части имени):

# Если есть папки:
# /home/user/projects/old-backend
# /home/user/projects/new-backend

z new     # перейдёт в new-backend (чаще посещалась)
z old     # перейдёт в old-backend

➤ Вариант 2 (Несколько слов и подстановки):

# Перейти в папку, содержащую "rust" и "lab"
z rust lab

# Подстановка звездочки (любое количество символов)
z *server    # найдёт "my_server", "test-server", "server-main"

➤ Вариант 3 (Интерактивный выбор при нескольких совпадениях):

z api
# Если есть api/v1, api/v2, api/v3
# zoxide покажет список, можно выбрать стрелками (требуется fzf)
zi api

Флаг i (interactive) — открывает интерактивный поиск с предпросмотром содержимого папки.

➤ Вариант 4 (Замена `cd` целиком):

Добавьте в .bashrc:

alias cd='z'

Теперь даже если вы по привычке напишете cd, сработает умный переход.

➤ Вариант 5 (Просмотр и редактирование базы данных):

# Показать рейтинг всех папок
zoxide query --list

# Вывести команды для удаления или изменения веса
zoxide edit

➤ Вариант 6 (Игнорирование временных папок и монтирований):

Добавить в .bashrc:

export _ZO_EXCLUDE_DIRS="$HOME/Downloads;$HOME/.cache"

Теперь zoxide не будет запоминать эти папки.

➤ Пример практического использования #1:

Разработчик работает в пяти микросервисах. Ему приходится открытыми пять терминалов, потому что переключаться через cd ../service-1 && cd ../service-2 было муторно. С zoxide он просто пишет z srv-1, z srv-2 из любого места.

➤ Пример практического использования #2:

Путь к папке с конфигами: /etc/nginx/sites-available/my-project/staging/configs. Чтобы попасть туда, нужно каждый раз либо вводить полный путь, либо ходить по Tab-ам. С zoxide: достаточно один раз туда сходить, потом z configs — и готово.

➤ Пример практического использования #3:

В компании переименовали проект с legacy-monolith на new-microservice. Разработчик год привыкает к новому названию. zoxide запомнает оба варианта, но со временем new стал весить больше. Через месяц z leg перестанет находить старую папку — алгоритм автоматически подстроится под новые привычки.

➤ Типичные сложности и их решение:

«`z` не находит мою новую папку». Вам нужно хотя бы один раз в неё перейти (обычным cd или z один раз вручную). zoxide запоминает только посещённые папки.

«`z` путает два похожих названия». Используйте более уникальный фрагмент. Например, вместо z api — z api/v2 или z /v2.

«`z` показывает список, но я хочу выбрать сразу». Поставьте fzf (sudo apt install fzf) и используйте zi вместо z. Откроется интерактивный поиск с предпросмотром.

«Я не хочу, чтобы `z` запоминал монтирования и временные папки». Используйте _ZO_EXCLUDE_DIRS (см. Вариант 6).

Главный совет: потратьте 2 минуты на установку и добавление eval в .bashrc. Ещё один день — чтобы привыкнуть использовать z вместо cd. После этого вы не захотите возвращаться обратно.

Используете zoxide или до сих пор вводите полные пути вручную?

P.S. Если очень хочется, можно сделать alias cd='z' и жить так, будто ничего не изменилось, кроме скорости и удобства.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

tree — показать структуру папок красиво

Ситуация: вы пришли в новый проект. Внутри — 50 папок и 200 файлов. Как понять, что где лежит? ls -la покажет список, но не даст представления о вложенности. find . вывалит простыню.

tree выводит структуру файлов и папок в виде дерева. С первого взгляда видно, какие папки внутри каких лежат, где глубина, где пустота.

Базовое использование:

# Показать дерево текущей папки
tree

# Показать дерево конкретной папки
tree /home/user/project

Пример вывода:

.
├── app.py
├── config
│   ├── settings.py
│   └── logging.conf
├── requirements.txt
├── static
│   ├── css
│   │   └── style.css
│   └── js
│       └── main.js
└── templates
    ├── index.html
    └── article.html

Вариант 1 (Ограничить глубину):

# Только два уровня вложенности
tree -L 2 /home/user/project

Вариант 2 (Показать только папки, без файлов):

tree -d /home/user/project

Вариант 3 (Показать скрытые файлы):

tree -a /home/user/project

Вариант 4 (Подсветка по типам файлов):

tree -C /home/user/project

Исполняемые файлы — зелёным, папки — синим, архивы — красным.

Вариант 5 (Сохранить дерево в файл):

tree /home/user/project > structure.txt

Вариант 6 (Исключить определённые папки):

tree --prune --matchdirs --dirsfirst -I "node_modules|.git|__pycache__"

Не показывать node_modules, .git и pycache.

Вариант 7 (Показать размер файлов):

tree --du -h

--du — показать суммарный размер папки, -h — человеко-читаемый формат.

Вариант 8 (С XML/JSON выводом для скриптов):

tree --xml > structure.xml
tree --json > structure.json

Красивые варианты:

# Ограничить глубину 2, показать папки первыми, исключить мусор
tree -L 2 -d --dirsfirst -I "venv|.idea|.pytest_cache|__pycache__|.git"

# С размерами файлов, глубиной 3, только папки
tree -L 3 -d --du -h

# Цветной вывод с папками первыми, без файлов
tree -C -d --dirsfirst

Совет: добавьте в ~/.bashrc алиас:

alias tree='tree -C --dirsfirst'

Теперь всегда будет цветной вывод и папки сверху.

Используете tree для навигации или предпочитаете ls -R?

P.S. Самый недооценённый флаг — -L. Ограничивает глубину, когда дерево слишком большое и нужно только понять общую структуру.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

entr — запускаем команды при изменении файлов

Ситуация: вы пишете код. Каждые 30 секунд переключаетесь в терминал, нажимаете Ctrl+C, стрелку вверх, Enter, чтобы перезапустить тесты или пересобрать проект. Рутина раздражает.

entr — это утилита, которая следит за файлами и запускает команду при любом изменении. Пересохранили файл — entr сам перезапустил тесты, перекомпилировал проект или перезагрузил сервер.

Базовое использование:

# Перезапускать тесты при изменении любого .py файла
find . -name "*.py" | entr pytest

# Следить за конкретным файлом
echo app.py | entr python app.py

Вариант 1 (Автоматический перезапуск веб-сервера при разработке):

echo app.py | entr -r python app.py

-r — рестарт: убивает предыдущий процесс перед запуском нового. Идеально для серверов.

Вариант 2 (Автоматическая пересборка документации):

find docs/ -name "*.md" | entr -s "make html"

-s — выполнить команду через шелл. Позволяет использовать пайпы и составные команды.

Вариант 3 (Запуск скрипта при изменении конфига и перезагрузка сервиса):

echo /etc/nginx/nginx.conf | entr -p systemctl reload nginx

-p — не перезапускать команду, если она уже выполняется (защита от наложения).

Вариант 4 (Выполнить несколько команд при изменении):

find src/ -name "*.go" | entr -s "go test && go build -o app"

Вариант 5 (Запускать скрипт в фоне и не ждать его завершения):

find *.c | entr -n ./compile.sh

-n — не ждать завершения предыдущей команды (полезно для долгих задач в фоне).

Некоторые трюки с entr:

1. Следить за новыми файлами: по умолчанию entr следит только за файлами, которые были переданы на старте. Чтобы добавить динамически появляющиеся файлы, нужен перезапуск. Но можно использовать find повторно: while true; do find . -name "*.py" | entr -d pytest; done (флаг -d отслеживает изменение директории).

2. Перезапуск при изменении конфигурации: entr умеет получать сигналы. Если нужно перечитать конфиг без остановки, используйте -r.

3. Ограничение частоты запусков: entr запускает команду при каждом изменении. Если файл сохраняется 100 раз в секунду (бывает при автодополнении), entr может заддосить систему. Защиты встроенной нет, но можно использовать внешние утилиты вроде sleep внутри команды.

P.S. В мире Node.js есть `nodemon`, в Python — `watchdog`, в Go — `fresh`. Но `entr` работает с любым языком и не требует установки дополнительных пакетов, кроме самой утилиты.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

duf — анализ дисков, который не напрягает глаза

Вы наверняка знаете df -h. Но давайте честно: его вывод — серое полотно, в котором глаза цепляются за проценты, а колонки разъезжаются, если подключено много устройств.

duf — это df, который сделали нормальные люди. Таблицы, цвета, сортировка, фильтрация и даже JSON для скриптов.

Базовое использование:

duf

Вы увидите:
- все разделы, смонтированные устройства, Docker-тома (если есть)
- колонки: размер, использовано, свободно, процент, точка монтирования
- цветовую индикацию: зелёный — норма, жёлтый — близко к заполнению, красный — опасно

Вариант 1 (Показать только реальные диски, исключить tmpfs, devtmpfs, squashfs):

duf --only ext4,xfs,btrfs,zfs

Вариант 2 (Сортировка по любому столбцу):

duf --sort size    # самые большие сверху
duf --sort used    # больше всех использовано
duf --sort avail   # больше всех свободно

Вариант 3 (Изменить единицы измерения):

duf --bytes      # байты
duf --si         # десятичные приставки (MB, GB)
duf --binary     # двоичные (MiB, GiB)

Вариант 4 (Исключить определённые устройства):

duf --hide-loops       # скрыть loop-устройства (snap/docker)
duf --hide-tmpfs       # скрыть tmpfs
duf --exclude /mnt/*   # скрыть всё, что примонтировано в /mnt

Вариант 5 (Вывод в JSON для автоматизации):

duf --json | jq '.[] | select(.mountpoint == "/") | .size'

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

Вариант 6 (Тема оформления):

duf --theme dark
duf --theme light

Меняет цветовую схему под ваш терминал.

Скачать бинарник с GitHub (если в репах нет):

wget https://github.com/muesli/duf/releases/download/v0.9.1/duf_0.9.1_linux_amd64.deb

Совет: добавьте в ~/.bashrc алиас alias df='duf'. Если привыкли к df, то однажды забудете, что поменяли, и будете просто радоваться красивому выводу.

P.S. Самый недооценённый флаг — `--only`. Часто `df` показывает 15 устройств, а нужны только `ext4`. `duf --only ext4` — и шума меньше, и глаза не разбегаются.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode

dog — DNS-запросы без тонны технического мусора

dig — стандарт для DNS. Но его вывод... Это помесь из служебной информации, в котором утопает главное — ответ на ваш вопрос. dog делает то же самое, но выдаёт результат как нормальную программу: цветной, структурированный, с группировкой и без лишнего шума.

Базовое использование:

dog google.com

Вывод разбит на секции (цветные, с отступами):
- ANSWER — то, что вы искали (IP-адреса)
- AUTHORITY — кто авторитетен для этого домена
- ADDITIONAL — доп. информация (например, IP авторитетных DNS-серверов)

Вариант 1 (Запросить конкретный тип записи):

dog google.com MX      # почтовые серверы
dog google.com NS      # DNS-серверы домена
dog google.com TXT     # текстовые записи (SPF, DKIM, верификация)
dog google.com AAAA    # IPv6-адреса
dog google.com CNAME   # каноническое имя (алиас)

Вариант 2 (Краткий вывод — только IP):

dog google.com --short
# 142.250.185.46
# 142.250.185.78

Вариант 3 (Использовать конкретный DNS-сервер):

dog google.com @8.8.8.8           # Google DNS
dog google.com @1.1.1.1           # Cloudflare DNS
dog google.com @94.140.14.14      # Яндекс DNS (без фильтрации)

Вариант 4 (DNS over TLS / DNS over HTTPS):

# DNS over TLS (шифрованный, порт 853)
dog google.com --tls @1.1.1.1

# DNS over HTTPS (шифрованный через HTTP)
dog google.com --https @https://cloudflare-dns.com/dns-query

Вариант 5 (Показать только определённые поля ответа):

dog google.com --query-type A --output ip
# 142.250.185.46

Вариант 6 (Обратное DNS-резолвинг — IP в домен):

dog @8.8.8.8 -x 8.8.4.4

Главный совет: для повседневных DNS-запросов dog удобнее dig сразу после установки. Для сложных расследований с трассировкой и анализом делегирования dig всё ещё остаётся стандартом (но dog +trace закрывает 80% таких кейсов).

Пользуетесь dog или остались верны dig?

P.S. Если нужен компромисс: `dig +noall +answer example.com` — даёт чистый ответ, но флаги всё равно приходится вспоминать.

hyperfine — бенчмарк команд без боли

Ситуация: вы написали скрипт и хотите понять, быстрее ли он стал после оптимизации. Или выбираете между grep, rg и ack. Запускаете time ./script.sh несколько раз, смотрите на разброс цифр, пытаетесь усреднить в уме. Это неэффективно.

hyperfine — это утилита для бенчмаркинга команд. Она запускает команду много раз (по умолчанию 10), усредняет результат, показывает доверительный интервал и даже умеет сравнивать несколько команд между собой.

Базовое использование:

# Замерить скорость выполнения команды
hyperfine 'sleep 1'

Вывод:

Benchmark #1: sleep 1
  Time (mean ± σ):      1.003 s ±  0.002 s    [User: 0.002 s, System: 0.001 s]
  Range (min … max):    1.000 s …  1.006 s    10 runs

Видно среднее время, стандартное отклонение (чем меньше, тем стабильнее), диапазон и количество запусков.

Вариант 1 (Сравнить две или более команд):

hyperfine 'grep -c "error" app.log' 'rg -c "error" app.log'

Вывод:

Benchmark #1: grep -c "error" app.log
  Time (mean ± σ):      1.523 s ±  0.021 s
  Range (min … max):    1.491 s …  1.562 s

Benchmark #2: rg -c "error" app.log
  Time (mean ± σ):      0.087 s ±  0.004 s
  Range (min … max):    0.081 s …  0.094 s

  'rg -c "error" app.log' ran 17.51 ± 0.98 times faster than 'grep -c "error" app.log'

В конце — наглядное сравнение во сколько раз быстрее.

Вариант 2 (Настроить количество прогонов и подготовку):

# 20 прогонов, перед каждым очистить кэш диска
hyperfine --runs 20 --prepare 'sync; echo 3 | sudo tee /proc/sys/vm/drop_caches' 'cat largefile.txt'

Вариант 3 (Игнорировать первые N прогонов — для прогрева):

hyperfine --warmup 3 'node server.js'

Три первых запуска не учитываются в статистике. Нужно, чтобы кэши заполнились и JIT-компилятор успел разогнаться.

Вариант 4 (Экспорт результатов для графиков):

hyperfine --export-json results.json 'python script.py' 'pypy script.py'

# Потом можно построить график
cat results.json | jq '.results[].times'

Вариант 5 (Показать время в разных единицах):

hyperfine --style basic 'ls -l'
hyperfine --style full 'ls -l'

Вариант 6 (Сравнение с бейслайном — регрессионное тестирование):

# Сохранить результат старой версии
hyperfine --export-json old.json './script_old.py'

# Сравнить с новой
hyperfine --export-json new.json './script_new.py'
hyperfine --parameter-scan delay 1 10 -D 2 './test.sh {delay}'

Главный совет: для серьёзных замеров используйте --warmup (прогрев кэшей) и --runs 30 (много прогонов для точности). А для быстрой прикидки достаточно --runs 5.

Пользуетесь hyperfine или запускаете time десять раз подряд вручную?

P.S. Самый недооценённый режим — сравнение нескольких команд с разными аргументами через `-L`. Позволяет увидеть, как меняется производительность в зависимости от размера входных данных.

P.P.S. Ссылку прилагаю, утилита полезная: https://github.com/sharkdp/hyperfine

history - ваша память, но с фильтром

history - это команда, которую все знают, но почти никто не настраивает. Она хранит всё, что вы вводили. Включая команды с паролями, токенами и секретными ключами.

Одна ошибка - и в .bash_history лежит curl -H "Authorization: Bearer секрет_который_нельзя_показывать". Потом кто-то получает доступ к вашему терминалу или просто заглядывает через плечо.

history можно и нужно настраивать. Вот как сделать её полезной и безопасной.

Базовое использование:

# Показать историю
history

# Показать последние 20 команд
history 20

# Повторить команду номер 123
!123

# Повторить последнюю команду
!!

# Повторить последнюю команду, начинающуюся с "docker"
!docker

Вариант 1 (Не сохранять команды с пробелом в начале):

Добавьте в ~/.bashrc:

export HISTCONTROL=ignorespace

Теперь любая команда, начинающаяся с пробела, не попадёт в историю:

 curl -H "Authorization: Bearer secret" https://api.example.com

Вариант 2 (Не сохранять дубликаты подряд):

export HISTCONTROL=ignoredups

Если вы 10 раз подряд набрали ls, в истории останется только одна запись.

Вариант 3 (Не сохранять определённые команды):

export HISTIGNORE="ls:ll:cd:exit:clear:history"

Команды из списка не попадают в историю вообще.

Вариант 4 (Увеличить размер истории):

По умолчанию хранится 500-1000 команд. Можно больше:

export HISTSIZE=10000       # размер в памяти
export HISTFILESIZE=20000   # размер в файле

Вариант 5 (Добавить временные метки):

export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S  "

Теперь history показывает, когда была выполнена каждая команда:

123  2025-01-15 10:30:45  docker ps
124  2025-01-15 10:31:20  git push

Вариант 6 (Очистить историю от секретов постфактум):

# Удалить конкретную строку из файла истории
history -d 123

# Очистить всю историю
history -c

Почему это важно?

Злоумышленник, получивший доступ к вашему терминалу (или просто подглядевший через плечо), может увидеть:
- пароли в командах mysql -p, psql -U user -W
- токены доступа к облачным API
- ключи шифрования, переданные через аргументы
- внутренние адреса серверов

Настройка history занимает 2 минуты и спасает от последствий на годы.

Дополнительный совет: для действительно критичных секретов используйте переменные окружения или файлы .env, а не передавайте их в аргументах команд.

Добавьте в ~/.bashrc:

export HISTCONTROL=ignorespace
export HISTTIMEFORMAT="%F %T "
export HISTSIZE=10000
shopt -s histappend

Перезапустите терминал - и история станет безопаснее и полезнее.

А вы настраивали history или пользуетесь стандартными настройками?

P.S. Если хотите вообще отказаться от истории: `unset HISTFILE`. Но это радикально. Лучше просто исключать чувствительные команды через пробел.

atool - забудьте про флаги tar, zip и gunzip

Ситуация: вам прислали архив. Какой именно? .tar.gz? .zip? .7z? .bz2? Вы начинаете вспоминать: для tar нужны флаги -xzf, для zip - unzip, для 7z - x. И каждый раз гуглите.

atool - это обёртка над разными архиваторами. Она сама определяет тип архива и вызывает правильную команду с правильными флагами. Вместо запоминания tar -xzf file.tar.gz вы просто пишете aunpack file.tar.gz. Работает для любого формата.

Базовое использование:

# Распаковать любой архив (определяет тип автоматически)
aunpack archive.zip
aunpack archive.tar.gz
aunpack archive.7z
aunpack archive.rar

# Создать архив (сам выбирает формат по расширению)
apack archive.tar.gz file1 file2
apack archive.zip folder/

Вариант 1 (Показать содержимое архива без распаковки):

als archive.zip

Вариант 2 (Распаковать в конкретную папку):

aunpack -d /target/folder archive.tar.gz

Вариант 3 (Список поддерживаемых форматов):

atool --list

Вариант 4 (Распаковать несколько архивов сразу):

aunpack *.zip *.tar.gz *.7z

Вариант 5 (Создать архив с максимальным сжатием):

apack --best archive.7z myfolder/

Вариант 6 (Создать архив с паролем для zip):

apack --password mysecret archive.zip secret_files/

Что стоит знать о atool:

Это обёртка. Она не реализует распаковку сама, а вызывает системные утилиты: tar, unzip, 7z, unrar и другие. Если какого-то архиватора нет в системе, atool подскажет, что нужно установить.

Совет: добавьте в ~/.bashrc алиасы, если часто работаете с архивами:

alias lsar='als'
alias unarc='aunpack'
alias mkarc='apack'

P.S. Если нужно просто распаковать - `aunpack`. Если запаковать - `apack`. Если посмотреть - `als`. Запомнить три команды проще, чем флаги tar и zip.

pkill и pgrep — убиваем и ищем процессы по имени

Ситуация: на сервере завис процесс, и вы не знаете его PID. Вы делаете ps aux | grep nginx, находите PID, потом kill -9 PID. Три действия, которые можно сделать одним.

pgrep находит PID по имени процесса. pkill убивает процесс по имени. Вместо трёх действий - одно.

Базовое использование:

# Найти PID процесса по имени
pgrep nginx

# Убить все процессы с именем nginx
pkill nginx

# Убить только один процесс с точным совпадением имени
pkill -x nginx

Вариант 1 (Убить процесс по полному имени):

# Не убьёт nginx, если его имя "nginx: master process"
pkill -f "nginx: master"

Вариант 2 (Убить процессы от определённого пользователя):

pkill -u user python

Вариант 3 (Убить процесс, но сначала проверить, что будет убито):

pgrep -la python
# Вывод: 1234 python script.py
# 5678 python app.py

# Потом убить
pkill python

Вариант 4 (Принудительное убийство через -9):

pkill -9 python

Вариант 5 (Искать и убивать процессы, работающие больше N часов):

# Найти процессы, работающие больше 4 часов
pgrep -l -o -t 4

# Убить их
pkill -o -t 4

Вариант 6 (Игнорировать регистр):

pkill -i nginx

Установка: pkill и pgrep есть почти везде по умолчанию (в пакете procps).

Главный совет: сначала используйте pgrep -la name, чтобы убедиться, что найдены нужные процессы. Потом pkill. На одну команду больше, но безопаснее.

P.S. Самый полезный флаг - `-f` (полное имя команды). Он находит процесс по всей командной строке, а не только по имени бинарника.

dust - визуальный анализ диска, который работает быстрее ncdu

Ситуация: диск заполнился на 95%. ncdu показывает дерево папок, но сканирует долго. А если диск терабайтный, ждать приходится минуты.

dust (или dua) - это аналог ncdu, но написанный на Rust. Он сканирует диск быстрее, показывает те же деревья, но с более читаемым выводом и цветами.

Базовое использование:

dust

Вывод показывает список папок и файлов, отсортированный по размеру, с цветовой индикацией.

Вариант 1 (Сканировать конкретную папку):

dust /var/log

Вариант 2 (Ограничить глубину):

dust -d 3 /home

Показывает только три уровня вложенности.

Вариант 3 (Исключить определённые папки):

dust -x /home

-x - не выходить за пределы текущей файловой системы.

Вариант 4 (Вывод в процентах вместо байтов):

dust -p /var

Вариант 5 (Только папки, без файлов):

dust -f /home

Вариант 6 (Сравнить несколько папок):

dust /var/log /var/cache

Главный совет: используйте dust для быстрой первичной диагностики, когда нужно понять, какая папка жрёт место за секунды. Для глубокого анализа с удалением - ncdu всё ещё удобнее.

Пользуетесь dust или остались верны ncdu и du?

P.S. Есть ещё `dua` (Disk Usage Analyzer) - аналогичная утилита, тоже на Rust, с интерактивным режимом.

glances - мониторинг системы в реальном времени

Ситуация: на сервере что-то тормозит. Вы открываете htop - видите CPU и память. Открываете iotop - видите диск. Открываете iftop - видите сеть. Три терминала, три утилиты, глаза бегают.

glances - это единая панель, которая показывает всё сразу: CPU, память, диск, сеть, температуру, процессы, даже docker-контейнеры. И делает это в красивом интерфейсе.

Базовое использование:

glances

Вывод - экран с множеством разделов: загрузка каждого ядра CPU, использование памяти и swap, средняя нагрузка за 1, 5, 15 минут, чтение и запись на диск, входящий и исходящий сетевой трафик, топ процессов с сортировкой по любому столбцу и список Docker-контейнеров если они есть.

Вариант 1 (Включить веб-интерфейс):

glances -w

Открываете браузер, вводите http://localhost:61208 - и видите панель на удалённом сервере через браузер.

Вариант 2 (Удалённый мониторинг):

На сервере:

glances -s

На клиенте:

glances -c server_ip

Вариант 3 (Экспорт в JSON для автоматизации):

glances --export-json

Вариант 4 (Вывод только определённых данных - например, CPU и памяти):

glances --stdout cpu,mem

Вариант 5 (Мониторинг с порогами и уведомлениями):

glances --alerts

Если CPU выше 90%, память выше 80% или диск заполнен - появляется предупреждение красным цветом.

Навигация в glances:

- h — справка со всеми горячими клавишами
- q — выход
- 1 — переключить отображение CPU (все ядра или суммарно)
- 2 — переключить отображение дисков (все или только активные)
- b — переключить сортировку процессов (по CPU, памяти или I/O)
- f — показать встроенную справку по процессам

Сравнение с аналогами вкратце:

top показывает только CPU, память и процессы в базовом текстовом виде. htop делает то же самое, но цветным и интерактивным. iotop специализируется только на дисковом I/O. А glances объединяет всё это в одном экране - и CPU, и память, и диск, и сеть, и Docker, и температуру.

Главный совет: запомните флаг -w - веб-интерфейс. Один раз запустили на сервере и забыли. Мониторинг всегда доступен.

Пользуетесь glances или предпочитаете собирать информацию по частям из разных утилит?

P.S. `glances` можно запустить как демон (`glances -d`) и настроить отправку метрик в InfluxDB или другие системы мониторинга.