One-liner в Bash — это не «магия ради магии», а способ быстро провернуть разовую операцию без написания отдельного скрипта. В связке bash + jq + curl + xargs можно делать из командной строки почти всё: вытаскивать данные из JSON, массово дергать API, проверять статус HTTP‑эндпоинтов, обрабатывать логи и многое другое.
Дальше — подборка практических шаблонов, которые реально помогают в работе с серверами и веб‑проектами. Акцент на понятности: разберём, что делает каждая часть, чтобы вы могли адаптировать примеры под свои задачи.
Базовые принципы one-liner-подхода
Чтобы one-liner был полезен, он должен быть:
- читаемым — хотя бы для вас самого через неделю;
- безопасным — без лишних потенциально опасных действий на доверии к вводу;
- расширяемым — чтобы по необходимости его можно было раздувать в мини‑скрипт.
Проверенный подход: сначала набросать идею в несколько строк скрипта, а потом уже схлопнуть в one-liner, если вам это действительно нужно и вы понимаете, что происходит на каждом шаге.
Главное: one-liner — это просто «скрипт в одну строку». Все обычные принципы написания shell‑кода к нему по‑прежнему применимы: проверка ошибок, аккуратная работа с вводом, осторожность с удалением и изменением данных.
Минимальный набор приёмов Bash
Чаще всего нам нужны:
$(...)— подстановка результата команды;|— конвейер, передача вывода одной команды на вход другой;set -euo pipefail— уже больше для скриптов, но в сложных one-liner’ах тоже может пригодиться (черезbash -c);- переменные окружения (
API_KEY,HOSTи т.п.) вместо жёстко прошитых значений; - корректные кавычки: одинарные vs двойные, чтобы не словить неожиданные подстановки.
В админской рутине это особенно полезно при проверке доступности сайтов, API‑ендпоинтов, мониторинге фронтендов на виртуальном хостинге или кластера на VDS.
jq: извлечение и трансформация JSON «на лету»
jq — это «grep и awk для JSON». Для one-liner’ов он незаменим, когда нужно:
- вытащить отдельные поля ответа API;
- отфильтровать элементы по условию;
- собрать список идентификаторов для дальнейшей обработки через
xargs; - на лету сформировать конфигурационные строки из структурированных данных.
В отличие от ручного копипаста из браузера, командная строка с jq хорошо сочетается с автоматизацией и CI, где нужно быстро проверить ответы API ваших сервисов на хостинге перед релизом.
Быстрый разбор JSON-ответа API
Классический шаблон: вытащить поле из JSON и дальше использовать его как список.
# Получаем список ID пользователей из JSON-файла users.json
cat users.json | jq -r '.users[].id'Ключевые моменты:
-r— «raw output», печатает строки без кавычек. Почти всегда нужен в one-liner’ах;.users[].id— пройти по массивуusersи вывести полеidкаждого элемента.
Фильтрация по условию
Например, у нас есть список доменов и их статус проверки от внутреннего сервиса:
cat domains.json | jq -r '.domains[] | select(.status == "pending").name'Это выведет только те домены, у которых статус pending. Дальше эти значения можно отправить в xargs, чтобы массово сделать запросы к API, изменить статус и т.д.
Формирование сложных строк
Частый приём: из JSON собрать сразу готовые команды или строки конфигурации.
cat backends.json | jq -r '.backends[] | "server " + .name + " " + .host + ":" + (.port|tostring) + ";"'Так можно из структурированных данных получать, например, строки для конфигов реверс‑проксей, списки бэкендов и т.п. Удобно, когда вы описываете окружения (dev/stage/prod) в одном JSON и разворачиваете конфигом для фронтендов на разных серверах.
curl: oneliners для HTTP и API
curl — основной «нож» для HTTP/HTTPS из командной строки. В связке с jq и xargs он превращается в гибкий инструмент для работы с API и проверки сайтов.
Базовый шаблон запросов к API
curl -sS -H "Authorization: Bearer $API_TOKEN" "$API_URL/resource" | jq -r '.items[].id'Разбор:
-sS— тихий режим, но ошибки показывать;- заголовок авторизации отдаём через переменную окружения, а не прошиваем токен в историю;
- результат сразу фильтруется через
jq.
Такой паттерн хорошо ложится в проверки интеграций: например, вы быстро убеждаетесь, что API биллинга отдаёт корректный список ресурсов для доменов, сайтов или сертификатов.
Проверка HTTP‑статусов пачкой
Обычная задача админа или вебмастера: быстро проверить список URL на предмет 200/301/4xx/5xx.
cat urls.txt | xargs -n1 -P8 -I{} bash -c 'code=$(curl -o /dev/null -sS -w "%{http_code}" "{}" 2>/dev/null); echo "$code {}"'Что тут важно:
-n1— по одному аргументу на вызов;-P8— до 8 параллельных запросов, сильно ускоряет проверку длинных списков;-I{}и"{}"— подставляем URL на место плейсхолдера, аккуратно экранируем;-w "%{http_code}"— выводим только код ответа.
Такой шаблон легко модифицировать: логировать время ответа, редиректы, заголовки и т.п. Вкупе с хорошей конфигурацией кэша (например, с учётом приёмов из статьи про оптимизацию nginx proxy_cache и stale-режим) это помогает оперативно подсветить медленные или битые фронты.
xargs: склеиваем потоки данных и команды
xargs — клей между Unix‑утилитами. Он берёт строки с stdin и подставляет их в вызовы команды. Для one-liner’ов это главный способ «прогнать» список значений через API или обработчик.
Базовый паттерн
echo "one two three" | xargs -n1 -I{} echo "item={}"Вывод:
item=one
item=two
item=threeТо же самое, только полезно: обойти список ID и сделать по ним HTTP‑запросы.
cat ids.txt | xargs -n1 -P4 -I{} curl -sS "$API_URL/resource/{}"-P4 даёт четыре параллельных запроса; значение стоит подбирать под API и свою сеть, чтобы не уткнуться в лимиты.
Когда не использовать xargs
xargs неудобен, когда:
- параметров слишком много и вы упираетесь в ограничение длины командной строки;
- нужно сложное управление ошибками и ретраями — тогда лучше писать скрипт/цикл;
- нужна строгая обработка спецсимволов (новые строки внутри полей и т.д.).
Во всех остальных случаях xargs отлично ложится в one-liner’ы. Альтернатива — while read‑циклы, но они хуже комбинируются с jq и curl в одной строке и чуть тяжелее читаются при беглом просмотре истории.
Типичные рабочие сценарии: Bash + jq + curl + xargs
Перейдём к сценариям, которые встречаются в повседневной админке и DevOps‑задачах: от массового обновления ресурсов до проверки здоровья множества хостов и валидации JSON‑ответов.
1. Массовое обновление ресурсов по списку ID
Допустим, API отдаёт список сущностей в JSON, и нам нужно по каждому ID сделать PATCH/POST/DELETE или какой‑то другой запрос.
# Получаем список ID и по каждому вызываем refresh
curl -sS "$API_URL/resources" | jq -r '.items[].id' | xargs -n1 -P4 -I{} curl -sS -X POST "$API_URL/resources/{}/refresh"Разбор цепочки:
curl -sS "$API_URL/resources"— забрали JSON;jq -r '.items[].id'— из него вытащили ID построчно;xargs -n1 -P4 -I{} ... {}— для каждой строки запускаемcurlв 4 потока.
Практические советы:
- если API ограничивает rate limit, уменьшайте
-Pили добавьте паузу внутри вызова (черезbash -c 'sleep 0.2; curl ...'); - логируйте ответы или хотя бы коды статуса, чтобы видеть, что что‑то пошло не так;
- для критичных операций сначала прогоняйте шаблон в режиме dry-run, печатая команды вместо их выполнения.
2. Быстрый health‑check множества хостов
Предположим, у нас есть список доменов или поддоменов, и надо проверить, что HTTPS‑эндпоинт отвечает 200.
cat hosts.txt | xargs -n1 -P10 -I{} bash -c 'code=$(curl -o /dev/null -sS -w "%{http_code}" "https://{}" 2>/dev/null); echo "$code {}"'Потом можно отфильтровать проблемные:
cat hosts.txt | xargs -n1 -P10 -I{} bash -c 'code=$(curl -o /dev/null -sS -w "%{http_code}" "https://{}" 2>/dev/null); if [ "$code" != "200" ]; then echo "$code {}"; fi'Такой one-liner особенно удобен при миграциях DNS или смене инфраструктуры, когда нужно убедиться, что все фронтенды поднялись и правильно отдают HTTPS. Здесь же полезно держать в голове требования к заголовкам CORS, описанные, например, в материале про настройку CORS в nginx и Apache.
3. Парсинг логов и запросы к API
Классика: вытащить IP‑адреса из access‑лога и прогнать их через некий внешний или внутренний API (например, репутации или аналитики). Сначала аккуратно выделим IP и уберём дубли:
awk '{print $1}' access.log | sort -u | head -100 | xargs -n1 -P5 -I{} bash -c 'curl -sS "$IP_API/{}" | jq -r ".score as $s | \"{} $s\""'Здесь мы:
- берём первые 100 уникальных IP из лога;
- по каждому дергаем API;
jqсразу форматирует вывод: IP + оценка.
Для боевого использования этот шаблон лучше расширить: добавить лимитер запросов, отдельный лог ошибок, фильтрацию только подозрительных URL и т.д. Но как разовый one-liner — вполне рабочий инструмент.
4. Генерация конфигураций из JSON
Если у вас есть некий JSON c описанием бэкендов, виртуальных хостов или настроек, их удобно превращать в «сырой текст» через jq.
cat vhosts.json | jq -r '.vhosts[] | "server_name " + .server_name + "; # " + .env'Вы можете сохранять результат в файл и потом включать его в конфиг веб‑сервера, либо просто использовать для проверки/диагностики. Это сильно упрощает жизнь, когда десятки сайтов разнесены по разным машинам и окружениям.
5. Проверка JSON‑ответов API на корректность
Иногда нужно быстро отловить, где API начал возвращать «ломаный» JSON (например, из‑за лишних логов в выводе). One-liner:
cat urls.txt | xargs -n1 -P4 -I{} bash -c 'echo "{}"; curl -sS "{}" | jq . >/dev/null || echo "BROKEN JSON: {}"'Схема:
- для каждого URL делаем запрос;
- отдаём тело на
jq .— если оно невалидно,jqвозвращает ошибку; - в этом случае печатаем сообщение о проблеме.
Шаблоны, которые стоит знать наизусть
Ниже — набор коротких «кубиков», из которых удобно собирать свои Bash one-liner’ы для curl, jq и xargs.
Вывод HTTP‑кода и времени ответа
curl -o /dev/null -sS -w "%{http_code} %{time_total}\n" "$URL"Это можно завернуть в xargs для списка URL; time_total пригодится при быстрой оценке производительности и отсечении медленных бэкендов.
Безопасное использование переменных окружения
Чтобы не таскать токены и ключи в явном виде в истории shell:
API_TOKEN="..." # экспортируете один раз в сессии
export API_TOKEN
curl -sS -H "Authorization: Bearer $API_TOKEN" "$API_URL"Если нужно передать токен внутрь bash -c '...', избегайте прямой подстановки в одну строку через неэкранированные кавычки. Лучше используйте экспорт и обращайтесь к переменной уже изнутри.
Построчная обработка jq + xargs
Золотой шаблон:
curl -sS "$API_URL/list" | jq -r '.items[].id' | xargs -n1 -P4 -I{} bash -c 'echo "Processing id={}"; curl -sS "$API_URL/item/{}" >/tmp/item_{}.json'Все элементы pipeline работают по строкам; главное — не забывать -r у jq, чтобы не получить кавычки в выводе и не ломать подстановку в URL или имена файлов.
Подход к отладке сложных one-liner’ов
Чем длиннее становится one-liner, тем легче в нём ошибиться. Подход, который работает на практике:
- Разбить конвейер на этапы и проверить каждый отдельно.
- Сначала работать с маленьким подмножеством данных (
head -5), а не со всем массивом. - Добавить временные
echoс отладочной информацией. - Когда всё стабильно — уже сворачивать в аккуратный one-liner.
Пример эволюции:
# 1. Просто получаем JSON
curl -sS "$API_URL/items" > /tmp/items.json
# 2. Смотрим структуру
cat /tmp/items.json | jq '.items | length'
# 3. Проверяем фильтр
cat /tmp/items.json | jq -r '.items[] | select(.enabled == true).id' | head -5
# 4. Подключаем xargs (пока только печать команд)
cat /tmp/items.json | jq -r '.items[] | select(.enabled == true).id' | xargs -n1 -P4 -I{} echo curl -sS "$API_URL/items/{}/refresh"Сначала печатаем команды через echo, убеждаемся, что всё правильно подставляется, и только потом убираем echo для реального запуска.
Безопасность и устойчивость one-liner’ов
При работе с production‑инфраструктурой one-liner’ы могут быть опасными, если:
- входные данные невалидны или содержат неожиданные символы;
- вы выполняете потенциально разрушительные операции без dry-run‑режима;
- не обрабатываете ошибки и ретраи, а API ведёт себя нестабильно;
- нет ограничений на параллелизм и вы легко кладёте соседний сервис или внешний API.
Минимальные меры предосторожности
- по возможности делайте dry-run: сначала печатайте то, что собираетесь выполнить;
- работайте с небольшой выборкой (пара ID, несколько URL) перед запуском по всему списку;
- добавляйте ограничение параллелизма
-P, чтобы не положить API; - в логах сохраняйте хотя бы коды ответов и идентификаторы объектов;
- держите под рукой резервные конфиги и бэкапы, особенно если one-liner меняет настройку веб‑сервера или данные.
Небольшое усложнение делает one-liner более безопасным, но всё ещё достаточно компактным и удобным.
Итог: как собрать свой «набор боевых one-liner’ов»
В реальной жизни вы быстро сформируете свой набор часто используемых шаблонов:
- «получить список ID из JSON»;
- «по каждому ID сделать POST/DELETE»;
- «проверить status code и время отклика URL»;
- «из access.log вытащить IP/URL/код ответа и прогнать через фильтры/API»;
- «превратить JSON‑описание сервисов в конфиг/список».
Хорошая практика — держать такие one-liner’ы в своём dotfiles‑репозитории или просто в текстовом файле с «кулинарной книгой команд». Со временем вы начнёте комбинировать их всё свободнее, и связка bash + jq + curl + xargs станет очень мощным инструментом для ежедневной рутины на серверах и в инфраструктуре ваших проектов.
