В арсенале каждого, кто работает с командной строкой Linux, есть набор инструментов, без которых жизнь становится заметно сложнее. Утилита xargs пусть и не на слуху у новичков, но среди опытных пользователей пользуется заслуженным уважением. Её главная задача звучит обманчиво просто - превращать поток данных со стандартного входа в аргументы для других команд. На практике это открывает такие возможности, что после знакомства с xargs многие повседневные сценарии выглядят совершенно иначе.
Часто задачи требуют связки нескольких утилит, где результат одной команды должен превратиться в параметры для другой. Простой пайп через | передаёт данные на стандартный вход, но что делать, если получатель ожидает их именно как аргументы командной строки? Например, команда rm не читает имена файлов из stdin - ей нужны параметры. Тут на сцену и выходит xargs, выступая переводчиком между двумя мирами.
Все примеры ниже проверены на Ubuntu 22.04 LTS с оболочкой Bash. Принципы работы одинаковы на любых современных дистрибутивах Linux, а также на BSD-системах, разве что некоторые редкие опции могут отличаться по синтаксису.
Принцип работы команды xargs и базовое поведение при чтении данных со стандартного входа
Прежде чем погружаться в практические сценарии, имеет смысл разобраться, что именно делает xargs под капотом. Если описать максимально простыми словами, утилита читает данные со стандартного входа (stdin) и выполняет указанную ей команду, передавая прочитанные данные как аргументы. Пробелы и табуляции в потоке считаются разделителями, пустые строки игнорируются.
Любопытная деталь - если xargs запустить вообще без указания команды для выполнения, по умолчанию используется echo. То есть утилита просто выведет на экран всё, что прочитала. Этот режим полезен для отладки, когда нужно посмотреть, во что именно преобразуется поток данных перед передачей в реальную команду.
Простейший эксперимент проводится так. Запускаем xargs без параметров, набираем строку Hello World, нажимаем Enter, потом Ctrl+D для сигнала об окончании ввода. На экран выводится Hello World - это сработала встроенная echo, получившая на вход то, что мы напечатали.
Эта простая модель скрывает тонкости, на которых основано всё дальнейшее. xargs не просто пробрасывает данные - он группирует их в аргументы по определённым правилам, может разбивать на части, обрабатывать кавычки и обратные слеши. Именно богатство этих правил и делает утилиту такой полезной.
Связка xargs с командой find для поиска файлов по различным шаблонам через стандартный вход
Самый частый сценарий применения xargs - связка с командой find. Сама по себе find умеет искать файлы по миллиону критериев, и часто результаты её работы нужно передать какой-то другой команде в качестве аргументов. Тут и происходит главная магия.
Простейший пример - попросить пользователя ввести шаблон поиска и выполнить find с этим шаблоном:
xargs find -name
Запускаем команду, вводим в stdin строку "*.txt" и нажимаем Ctrl+D. Утилита xargs передаёт введённое значение как аргумент к find -name, и в результате выполняется поиск всех файлов с расширением txt в текущем каталоге и его подкаталогах.
Логика тут такая. xargs прочитал из stdin строку ".txt", скомпоновал из неё команду find -name ".txt" и запустил её на выполнение. На первый взгляд кажется, что то же самое можно было сделать гораздо проще через прямой вызов find. И это правда - в данном конкретном случае xargs избыточен. Но как только появляется необходимость передавать несколько разных шаблонов или интегрировать поиск в более сложный конвейер обработки, без xargs становится не обойтись.
Запуск команды несколько раз для каждого аргумента отдельно через ключи L и n
В предыдущем примере был один шаблон поиска. А что если их несколько и нужно искать сразу .txt, .log и .tmp файлы? Если попробовать ввести в stdin сразу несколько шаблонов, разделённых пробелами или переносами строки, получится не то, что ожидается.
Дело в том, что xargs по умолчанию пытается передать все прочитанные элементы как набор аргументов в одну команду. То есть find получит на вход что-то вроде:
find -name "*.txt" "*.log"
А такая запись для find некорректна - утилита ждёт после -name только один шаблон. В результате выскакивает ошибка, и поиск не выполняется.
Правильное поведение - запускать find отдельно для каждого шаблона. Для этого у xargs есть опция -L, которая принимает число и указывает, сколько строк ввода передавать в команду за один раз:
xargs -L 1 find -name
Теперь xargs прочитает первую строку, запустит find -name с её содержимым, потом прочитает вторую строку, запустит find ещё раз с новым шаблоном, и так далее. Каждый шаблон обрабатывается своим запуском find.
У -L есть особенность. Параметр считает именно строки, а не отдельные элементы внутри строки. Если ввести в одну строку ".txt" ".log", опция -L 1 всё равно передаст оба шаблона как один пакет аргументов в один запуск find, и снова получится та же ошибка.
Для подобных случаев есть опция -n, которая считает уже не строки, а отдельные аргументы:
xargs -n 1 find -name
Теперь xargs разбирает входной поток на отдельные элементы и для каждого запускает свою команду. Получается аналог цикла for, где итерация идёт по каждому слову во входе.
Разница между -L и -n становится особенно важна, когда формат входных данных может варьироваться. Если поток гарантированно идёт построчно (например, из find -print или из ls -1), -L 1 работает прекрасно. Если же данные могут быть в одной строке через пробелы, надёжнее использовать -n 1.
Корректная обработка имён файлов с пробелами через смену разделителя по умолчанию
В самом начале упоминалось, что xargs воспринимает пробелы как разделители аргументов. Это удобно для большинства сценариев, но порождает классическую проблему - имена файлов с пробелами. Современные операционные системы давно разрешают пробелы в именах, и это норма для документов и медиафайлов.
Допустим, в каталоге лежит файл с названием new music.mp3, и его нужно открыть в плеере. Простая попытка передать имя через xargs закончится плачевно. Утилита разобьёт имя на два аргумента - new и music.mp3, и плеер пожалуется на отсутствие обоих файлов по отдельности.
Один способ обойти проблему - экранировать пробел обратным слешем при ручном вводе:
new\ music.mp3
Но это работает только для интерактивного режима, и совершенно непригодно при автоматической обработке. Если имена приходят из find или другого источника, экранирование на лету становится головной болью.
Гораздо элегантнее сменить разделитель через опцию -d. Указав в качестве разделителя только символ перевода строки, мы заставим xargs игнорировать пробелы внутри строк и считать аргументом всю строку целиком:
xargs -d '\n' mplayer
Теперь xargs считывает входной поток построчно, и каждая строка - один аргумент, независимо от того, сколько пробелов внутри. Файл new music.mp3 передаётся в плеер как единое целое, и воспроизведение запускается без проблем.
Опция -d принимает любой символ как разделитель. Можно использовать запятую, точку с запятой или даже специальные значения. Это даёт огромную гибкость при работе с CSV-подобными форматами данных или экзотическими источниками вроде логов с нестандартной структурой.
Работа с именами файлов содержащими символы перевода строки через связку print0 и опции 0
Пробелы в именах - это ещё цветочки. Linux разрешает в именах файлов почти любые символы, включая собственно перевод строки. Файл с именем foo[перевод строки]file.txt в терминале выглядит как foo?file.txt, и при попытке его обработать через стандартные пайпы начинаются настоящие приключения.
Допустим, нужно найти все файлы с именами, начинающимися на foo, и открыть их в редакторе:
find . -name "foo*" | xargs gedit
Команда отрабатывает, но открывается совсем не то. Поскольку перевод строки в имени файла xargs воспринимает как разделитель аргументов, он разбивает имя пополам и пытается открыть несуществующие файлы по фрагментам.
Решение элегантно и опирается на координированную работу find и xargs. У find есть опция -print0, которая выводит результаты не через переводы строк, а через нулевой байт. У xargs есть зеркальная опция -0, которая ожидает входной поток, разделённый именно нулевыми байтами:
find . -name "foo*" -print0 | xargs -0 gedit
Нулевой байт - это единственный символ, который точно не может встретиться в имени файла на любой Unix-подобной системе (он зарезервирован как маркер конца строки в C-строках, на которых построена вся файловая система). Поэтому использование нулевого байта как разделителя гарантирует корректную передачу любых имён без двусмысленностей.
Связка -print0 и -0 - это золотой стандарт для надёжной обработки имён файлов в скриптах. Если код обрабатывает результаты find через пайп, опытные администраторы автоматически добавляют этот тандем, не задумываясь, есть ли в реальной выборке проблемные имена. Привычка прививается через пару неприятных инцидентов, когда отлаженный скрипт спотыкается о файл с экзотическим именем.
Поиск файлов содержащих определённый текст через комбинацию find и grep
Один из самых полезных классических сценариев применения xargs - поиск файлов, содержащих определённую строку. На первый взгляд кажется, что эту задачу прекрасно решает grep с рекурсивным поиском (grep -r "abc" .). И в простых случаях так и есть. Но связка через xargs даёт больше гибкости, когда нужно фильтровать файлы перед поиском по содержимому.
Допустим, нужно найти все .txt файлы, в которых встречается строка abc:
find -name "*.txt" | xargs grep "abc"
Здесь происходит изящная двухступенчатая обработка. Сначала find отбирает только текстовые файлы по расширению, потом xargs передаёт их имена в grep, который ищет нужный текст уже только в отобранных. Получается фильтр по двум критериям - имени файла и содержимому, причём каждый шаг можно настроить независимо.
Преимущество такой схемы перед прямым grep -r --include="*.txt" в том, что find намного гибче в плане условий отбора. Можно добавить поиск только файлов, изменённых за последнюю неделю, или только тех, размер которых меньше определённого порога, или принадлежащих конкретному пользователю. Любой из десятков критериев find становится фильтром для последующего поиска по содержимому.
Стоит отметить нюанс - если grep находит совпадения, по умолчанию он показывает каждое в формате имя_файла:строка. Когда xargs передаёт grep сразу несколько файлов, такой формат сохраняется автоматически. Если же нужно выводить только имена файлов, в которых есть совпадения, помогает флаг -l (от lower-case L). А вот флаг -h убирает имена файлов из вывода, оставляя только сами совпавшие строки - удобно при подготовке отчётов.
Чтение входных данных из файла через опцию a вместо стандартного ввода
До этого момента xargs получал данные либо из stdin при ручном вводе, либо через пайп от другой команды. Но утилита умеет и третий вариант - читать список аргументов прямо из файла. Это бывает полезно, когда входные данные подготовлены заранее и хранятся как обычный текстовый файл.
Опция -a принимает имя файла, из которого xargs будет считывать входной поток вместо stdin:
xargs -a input.txt ls -lart
Допустим, в input.txt лежит две строки - testfile1.txt и testfile2.txt. После запуска команды xargs прочитает их из файла и передаст как аргументы в ls -lart, которая выведет подробную информацию о каждом из этих файлов в порядке времени изменения.
Такой подход удобен в нескольких ситуациях. Во-первых, когда список объектов генерируется заранее каким-то отдельным процессом и используется многократно. Во-вторых, когда хочется иметь возможность визуально проверить и при необходимости отредактировать список перед обработкой - открыть файл в редакторе всегда проще, чем модифицировать промежуточный пайп. В-третьих, при работе со списками, которые слишком велики для удобной передачи через командную строку, но укладываются в файл.
Альтернативный способ добиться того же результата - использовать перенаправление: xargs ls -lart < input.txt. Разница в том, что при -a сохраняется возможность одновременно использовать stdin для чего-то ещё, что иногда бывает критично в сложных конвейерах.
Интерактивное подтверждение каждого вызова через опцию p для безопасного выполнения
При работе с потенциально опасными операциями (массовое удаление, изменение прав, перемещение файлов) хочется иметь возможность контролировать каждое действие лично. xargs предоставляет такую возможность через опцию -p.
С этим флагом утилита перед каждым запуском команды показывает, что именно собирается выполнить, и ждёт подтверждения от пользователя. Ответ y разрешает выполнение, любой другой ответ или просто Enter - пропуск.
Получается интерактивный режим, в котором оператор может пробежаться по списку и решить судьбу каждого элемента. Особенно ценно это при отладке скриптов или при работе с непривычными наборами данных, где можно случайно зацепить лишнее.
Сочетание -p с -n 1 даёт максимально безопасный режим - команда запускается отдельно для каждого аргумента, и каждый запуск требует явного разрешения. Медленно, зато надёжно. После пары случаев, когда автоматический скрипт удалял что-то не то, привычка использовать -p при первых тестах новых конструкций приходит сама собой.
Дополнительные сценарии и практические наблюдения из реальной работы с xargs
В копилку наблюдений из практики стоит добавить несколько полезных трюков, которые редко упоминаются в базовых руководствах, но регулярно выручают в реальных задачах.
Первый трюк - параллельное выполнение через опцию -P. Современные процессоры имеют десятки ядер, и последовательный запуск команд по одной выглядит расточительно. Опция -P указывает максимальное число параллельных процессов:
find . -name "*.jpg" | xargs -P 4 -n 1 jpegoptim
Эта команда запустит до четырёх процессов оптимизации картинок одновременно, что ускоряет обработку каталога с тысячами файлов в разы. Подобный приём прекрасно работает для конвертации видео, сжатия архивов, обработки логов и многих других ресурсоёмких задач.
Второй полезный момент - подстановка аргументов в произвольное место команды через опцию -I. По умолчанию xargs приклеивает аргументы в конец команды, но иногда нужно вставить их в середину. Опция -I задаёт строку-заполнитель, которая будет заменена на каждый аргумент:
ls *.txt | xargs -I {} cp {} /backup/{}.bak
Здесь {} - это плейсхолдер для имени файла, и xargs подставляет его в трёх местах команды cp, превращая каждый текстовый файл в его резервную копию с расширением .bak.
Третий момент касается ограничений на длину командной строки. У ядра Linux есть лимит на размер аргументов одного вызова - обычно несколько мегабайт, но точное значение зависит от настроек. Если файлов очень много и их имена длинные, xargs автоматически разобьёт вызов на несколько порций, не превышающих этот лимит. Это поведение защищает от ошибки Argument list too long, которая случалась бы при попытке передать всё одним вызовом.
Где xargs незаменим в реальной работе? Сценариев масса. Массовое удаление старых логов, отобранных по дате модификации. Конвертация всех изображений в каталоге с определёнными параметрами. Изменение владельца или прав на большом наборе файлов после переноса проекта. Поиск конкретного текста в коде по выборке только нужных типов файлов. Запуск тестов параллельно для каждого модуля. Очистка временных файлов по сложным критериям. Архивирование баз данных по списку из конфига.
Освоение xargs даёт инженеру нечто большее, чем знание одной утилиты. Это тренировка мышления в категориях потоков данных и преобразований, которые лежат в основе философии Unix. Каждая команда делает одно дело, но хорошо. Соединяя их через пайпы и xargs, можно собирать сложные конвейеры обработки прямо в терминале, не написав ни строчки кода. Этот подход переносим - те же концепции встречаются в современных инструментах оркестрации, в системах потоковой обработки данных вроде Kafka и Spark, в облачных функциях и serverless-архитектурах. Тот, кто проникся идеями xargs и find на уровне привычки, легко осваивает любую современную систему обработки потоков, поскольку видит за модной обёрткой ту же базовую логику, отточенную ещё в семидесятых годах прошлого века.
Канал сайта в Telegram
Канал сайта на YouTube