fzf: поиск, который работает везде

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

Утилита принимает список строк на вход, а на выходе отдаёт выбранную.

➤ Вариант 1 (Поиск по истории команд): привязка к Ctrl+R превращает поиск в истории из слепого перебора в интерактивную прогулку.

# Добавить в .bashrc или .zshrc
bind '"\C-r": "\C-e \C-u history | fzf --tac --no-sort | xargs -I {} echo {}"'

➤ Вариант 2 (Быстрый переход в папку): больше не нужно помнить, где лежит проект, запущенный месяц назад.

# Переход в любую папку в проектах
cd $(find ~/projects -type d 2>/dev/null | fzf)

# Или с предпросмотром содержимого
cd $(find ~/projects -type d | fzf --preview 'ls -la {}')

➤ Вариант 3 (Поиск и убийство процесса): нашел процесс глазами — убил, не выходя из поиска.

# Выбрали процесс — отправили SIGTERM
kill -15 $(ps aux | fzf | awk '{print $2}')

# С предпросмотром деталей процесса
kill -15 $(ps aux | fzf --preview 'echo {}' | awk '{print $2}')


fzf работает как пайплайн: слева что угодно (файлы, процессы, строки), справа — действие над выбранным. Один раз настроив, вы получаете интерактивность там, где раньше был только слепой grep.

Используете ли вы интерактивный поиск в терминале или предпочитаете старый добрый Ctrl+R?

*P.S. В zsh можно настроить автодополнение команд через fzf — набираем kill **, нажимаем Tab, и выбираем процесс из списка.*

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode (тут выходит более подробный материал)

ripgrep: grep, который не заставляет ждать

grep хорош, но на больших проектах он тормозит. ripgrep (команда rg`) ищет в 10-20 раз быстрее, умеет игнорировать .gitignore` по умолчанию и выводит результат с контекстом.

Фраза «подожди, я сейчас найду где это используется» — это симптом, который лечится заменой инструмента.

➤ Вариант 1 (Поиск по коду проекта): находит все вызовы функции за доли секунды, даже в проекте с 10k файлов.

# Найти все вызовы calculate_price во всём проекте
rg "calculate_price"

# Только в Python-файлах, игнорируя тесты
rg -t py "calculate_price" -g "!tests/**"

# Найти TODO и показать имя файла и номер строки
rg -n "TODO"

➤ Вариант 2 (Поиск с контекстом и подсветкой): видно не только где, но и что было до и после.

# Показать 3 строки до и после найденного
rg -C 3 "error" logs/application.log

# Только имена файлов, где нашлось
rg -l "password" --hidden

# Подсветка совпадений разными цветами
rg --colors 'match:bg:yellow' "TODO"

➤ Вариант 3 (Замена во всех файлах): безопасная замена с предварительным просмотром.

# Сначала посмотреть, что попадёт под замену
rg "old_function" --files-with-matches

# Потом заменить с бекапом
rg "old_function" --files-with-matches | \
  xargs sed -i.bak 's/old_function/new_function/g'


ripgrep использует SIMD-инструкции и умные алгоритмы поиска. На проекте с 10k файлов он находит всё за секунду, пока grep ещё думает. И главное - он "уважает" .gitignore, поэтому случайно не залезет в node_modules.

Пробовали ли вы rg или остались верны классическому grep?

*P.S. rg отлично дружит с fzf: rg --no-heading "TODO" | fzf — интерактивный поиск по всем TODO в проекте.*

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

Короче, веселье. Минцифры решило подключить к блокировке VPN сами сайты и приложения. Не только операторов, а теперь ещё и «Яндекс», VK, Wildberries, Ozon, Сбер, Авито, Wink, ivi и ещё с десяток крупных игроков.

Что от них хотят? Чтобы к 15 апреля они:

- заблокировали доступ пользователям с включенным VPN по спискам РКН
-сами научились выявлять новые способы обхода
- в идеале - вообще отключали весь функционал, если видно VPN

А если не сделают? То лишат IT-льгот, выкинут из «белых списков» и из перечня ПО для предустановки на гаджеты. На мой взгляд - весьма болезненно.

Но есть нюансы, которые мне лично пока непонятны.

Как отличить «плохой» VPN от корпоративного? Технически трудно. То есть человек, который работает из дома через VPN компании, может попасть под блокировку. Просто потому, что система увидит «VPN».

А что с пользователями из Казахстана, Беларуси, Турции? Они без всяких VPN заходят, а алгоритм может решить, что это обход. И все, занавес🤷‍♂️

И главный прикол: требование пока только к крупным. Мелкие сервисы и иностранцы - мимо. То есть аудитория может просто перетечь туда, где не блокируют.

Моё мнение. Я понимаю задачу. Но когда под угрозой оказываются обычные люди с корпоративным VPN или наши же пользователи из-за границы - это уже не про блокировку, а про «лишь бы отчитаться». И пока нет чёткой методики, компании будут откровенно бояться что-то менять.

Что будет с этим каналом в дальнейшем - пока сказать сложно. Доступ в Телеграм и его работа на данный момент весьма затруднительны. Публиковать статьи пока не вижу смысла, так как еще не понимаю, где будет дислоцироваться канал. Вопросов уйма, ответов мало. В любом случае, буду стараться держать Вас в курсе происходящего!

Как только все вопросы устаканятся и появится хоть какая-то ясность - вернемся к активным, разносортным постам и статьям!

P.S. Если Вам нравится мое творчество - буду рад подпискам на иные соцсети😁

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

fd: find, который не требует гуглить синтаксис

find - прекрасный инструмент, но синтаксис у него... мягко говоря специфический. Каждый раз, когда нужно найти что-то сложнее find . -name "*.py", приходится лезть в документацию. fd делает то же самое, но с человеческим интерфейсом.

Запоминать десятки флагов - это когнитивная нагрузка, которая отвлекает от реальной задачи.

➤ Вариант 1 (Поиск файлов по имени): интуитивно понятно даже для тех, кто не помнит синтаксис регулярных выражений.

# Найти все Python-файлы
fd .py

# Найти все файлы readme (регистронезависимо)
fd -i readme

# Найти все файлы с расширением .md или .txt
fd -e md -e txt

➤ Вариант 2 (Поиск с исключениями): игнорировать нужно чаще, чем искать.

# Искать всё, кроме папки tests
fd .py --exclude tests

# Искать, учитывая .gitignore (по умолчанию включено)
fd "config" --hidden  # включает поиск в скрытых папках

➤ Вариант 3 (Выполнить команду над найденным): нашел - сделал, без xargs и экранирования.

# Найти и удалить все .tmp файлы
fd -e tmp -x rm {}

# Найти и показать содержимое каждого найденного файла
fd -e md -x bat {} --style=plain

# Найти и выдать размер каждого файла
fd -e log -x du -h {}


fd по умолчанию игнорирует .gitignore, умеет цветной вывод и поддерживает регулярные выражения. Имена файлов, которые часто ищут (`*.py`, *.md, `*.json`), можно не экранировать. А цветная подсветка помогает сразу отличить файлы от папок.

*P.S. fd отлично работает в паре с fzf: fd | fzf - интерактивный выбор файла из всего проекта.*

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

bat: cat, который показывает код, а не просто текст

cat выводит файл. Всё. Ни подсветки, ни номеров строк, ни навигации. bat делает то же самое, но превращает вывод в читаемый документ с синтаксисом, разметкой и возможностью скроллить.

➤ Вариант 1 (Просмотр кода с подсветкой): синтаксис определяется автоматически под сотню языков.

# Вместо cat app.py
bat app.py

# Принудительно указать язык
bat --language=json config.json

# С нумерацией строк
bat --number app.py

➤ Вариант 2 (Просмотр с Git-аннотацией): видно, кто и когда менял каждую строку.

# Показать изменения относительно последнего коммита
bat --diff app.py

# С Git-блэйд (автор каждой строки)
bat --paging=always --line-range :50 app.py  # первые 50 строк

➤ Вариант 3 (В пайплайнах и скриптах): умное поведение — если вывод не в терминал, bat ведет себя как обычный cat.

# В пайпе не ломает скрипты
rg "error" | bat --language=log

# Сохранить подсвеченный вывод в файл
bat --plain app.py > app.txt  # --plain отключает подсветку


bat поддерживает более 300 языков, автоматически определяет синтаксис и показывает Git-изменения на полях. При этом если вывести bat в пайп или запустить не в терминале, он ведёт себя как обычный cat, не ломая скрипты и автоматизацию.

Сколько раз вы использовали cat и жалели, что нет подсветки синтаксиса?

*P.S. Можно сделать алиас alias cat='bat', но осторожно — в скриптах это может сломаться. Лучше оставить cat для скриптов, а в интерактиве использовать bat.*

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

socat - nc для сетей, который вы заслужили

netcat (nc) знают многие. Но когда задачи становятся сложнее - нужен SSL, нужен форк на несколько соединений, нужна привязка к конкретному интерфейсу - nc пасует. Здесь на сцену выходит socat.

Это как прокаченный nc. Он умеет соединять что угодно с чем угодно: файл с сокетом, TCP с SSL, Unix-сокет с UDP, и даже выполнять команду при подключении.

➤ Вариант 1 (Проброс трафика с одного порта на другой): классический use case для обхода фаерволов.

# Слушаем на 8080, пересылаем на внутренний сервер 3000
socat TCP-LISTEN:8080,fork TCP:localhost:3000

# fork — позволяет обрабатывать несколько соединений

➤ Вариант 2 (Туннель с SSL-терминацией): нужен HTTPS-сервер, а поднимать nginx ради одного эндпоинта — жирно.

# Принимаем HTTPS на 443, внутри отдаём на HTTP 8080
socat OPENSSL-LISTEN:443,cert=server.pem,verify=0,fork TCP:localhost:8080

➤ Вариант 3 (Работа с Unix-сокетами): контейнеры и демоны часто общаются через сокеты, отлаживать их неудобно.

# Подключиться к сокету Docker и отправить запрос
echo 'GET /info HTTP/1.0' | socat - UNIX-CONNECT:/var/run/docker.sock

# Проксировать Unix-сокет в TCP для внешнего доступа
socat TCP-LISTEN:9999,fork UNIX-CONNECT:/var/run/docker.sock

➤ Вариант 4 (Перенаправление ввода-вывода в сеть): передать вывод команды или файл по сети без ssh.

# На стороне получателя: слушаем, сохраняем в файл
socat TCP-LISTEN:1234,fork OPEN:backup.tar.gz,create,append

# На стороне отправителя: читаем файл, шлём
socat OPEN:backup.tar.gz TCP:192.168.1.100:1234

➤ Вариант 5 (Отладка и перехват трафика): посмотреть, что реально передаётся между клиентом и сервером.

# Эхо-сервер для отладки (возвращает то же, что получил)
socat -v TCP-LISTEN:1234,fork STDOUT

# -v выводит весь трафик в stderr
# Можно записывать в файл: 2>traffic.log

➤ Вариант 6 (Выполнение команд по сети): организовать примитивное удалённое управление.

# На сервере: при подключении выполняем скрипт
socat TCP-LISTEN:1234,fork EXEC:/bin/script.sh

# На клиенте: подключаемся, получаем результат
socat - TCP:server:1234

Главный минус socat - синтаксис. Он страшный. Но если освоить базовые паттерны (`TCP-LISTEN`, OPENSSL, `EXEC`), он закрывает сценарии, для которых иначе пришлось бы писать отдельный сервис.

P.S. Самый недооценённый режим: socat -T 60 - таймаут для безответных соединений. Спасает от подвисших сессий.

👉🏻 Я в Telegram - t.me/helcode
👉🏻 Я в VK - vk.com/helcode
👉🏻 Я на Boosty - boosty.to/helcode (тут посты более подробные)

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` — даёт чистый ответ, но флаги всё равно приходится вспоминать.