Разработчики и системные администраторы, которые имеют дело и с Windows, и с Linux, давно привыкли к одной проблеме: скрипты и команды нормально функционируют на сервере, но не пойдут без адаптации на локальном компьютере. Для запуска привычных утилит вроде ls, cp, grep или find обычно приходилось использовать WSL, Git Bash или другие слои совместимости.
Microsoft решила упростить этот сценарий и выпустила пакет Coreutils для Windows, добавляющий популярные Unix-команды прямо в их систему. Решение ориентировано прежде всего на разработчиков, DevOps-инженеров и администраторов, которым приходится регулярно переключаться между разными платформами. Давайте разберемся, что это за пакет и как он устроен.
Как это устроено технически
В Microsoft взяли за основу проект uutils/coreutils — кроссплатформенную реализацию GNU Coreutils на языке Rust. Вместо коллекции десятков отдельных исполняемых файлов — один многофункциональный бинарник coreutils.exe.
При установке через winget в системе создаются жесткие ссылки (NTFS hard links) на ls.exe, cp.exe, rm.exe и другие утилиты. Все они ведут напрямую на coreutils.exe. Когда вызывается конкретная команда, запускается общий бинарник, который по аргументу argv[0] определяет, какую именно функцию нужно выполнить. Такой подход с множественными вызовами значительно упрощает обновления и уменьшает размер дистрибутива.
Пакет включает не только базовый набор uutils/coreutils, но и компоненты uutils/findutils, — такие как find, xargs, — а также GNU-совместимый grep. При этом разработчики Microsoft сохранили оригинальное поведение некоторых штатных команд Windows. Например, sort и find продолжают поддерживать синтаксис /O и другие DOS-ключами, чтобы не ломались существующие CMD-скрипты.
Такая гибкость достигается за счет особой логики внутри бинарника, которая проверяет контекст вызова и запущенную оболочку. В рамках одного сеанса можно использовать как Unix-флаги (--help, -la), так и традиционные параметры — все работают без конфликтов.
Установка предельно простая:
winget install Microsoft.CoreutilsИсполняемые файлы попадают в папку Program Files, а пути к жестким ссылкам — в переменную окружения PATH. Команды становятся доступны в CMD, PowerShell 7.4+ и Windows Terminal.
Важно учитывать порядок записей в PATH: если штатная команда Windows стоит в перечне раньше, именно она перехватит вызов. Для корректной работы PowerShell рекомендуется настроить алиасы или явно указывать полный путь к исполняемому файлу.
Каждая утилита поддерживает стандартный флаг --help с подробным описанием опций, что соответствует поведению в Linux. Стоит учитывать, что проект пока находится в статусе preview, поэтому в некоторых редких сценариях могут проявляться различия в обработке путей или кодировок.
Почему именно сейчас
Создание ПО все заметнее смещается в кроссплатформенные технологии: контейнеры, CI/CD, облачные сервисы. При этом многие скрипты и пайплайны изначально пишутся под Linux, тогда как сами разработчики предпочитают Windows-машины с привычными инструментами.
Раньше приходилось либо адаптировать код под PowerShell, либо разворачивать WSL с неизбежными накладными расходами на ресурсы — память и файловую систему. Теперь же нативные утилиты на Rust позволяют запускать знакомые конструкции ls -la | grep или cp -r почти без изменений.
Rust в качестве основы дает сразу несколько преимуществ. Во‑первых, безопасная работа с памятью обеспечивается по умолчанию, что снижает риски уязвимостей по сравнению с классическими C‑реализациями. Во‑вторых, один и тот же код хорошо компилируется под Windows, Linux и macOS.
В Microsoft не стали писать все с нуля, а взяли зрелый open-source проект uutils, который уже используется в некоторых дистрибутивах. Такое решение позволило разработчикам сосредоточиться на аспектах, специфичных для Windows: интеграции с файловой системой NTFS, корректного распознавания длинных путей, поддержке кодировки UTF-16 и списками контроля доступа ACL.
Отдельный момент — совместимость с существующими скриптами. Многие корпоративные окружения накопили огромный объем bat- и cmd-файлов. Полная подмена привычных инструментов неизбежно привела бы к хаосу, поэтому разработчики пакета предусмотрели параллельное сосуществование обеих версий.
Утилиты Unix логично задействовать в новых сценариях, где критично одинаковое поведение команд на локальных машинах и серверах. Подобная гибкость особенно полезна для DevOps-инженеров, которые работают с гибридной инфраструктурой.
Реакция сообщества и возможные подводные камни
IT‑сообщество в целом положительно отреагировало на появление пакета. Многие отметили удобство при написании кроссплатформенных скриптов: теперь можно делиться однофайловыми решениями без постоянных оговорок про «на Windows нужно переписать». Нововведение особенно оценить должны те, кто работает с Git, Docker и облачными SDK, где командная строка задействуется максимально интенсивно.
Однако остаются и непреодолимые технические ограничения.
Поскольку Windows использует списки контроля доступа ACL вместо классических прав POSIX (permission bits), в пакет ожидаемо не вошли утилиты chmod, chown, chgrp и chcon. Их логику невозможно адекватно воспроизвести на файловой системе NTFS без внедрения дополнительных метаданных.
Аналогичная ситуация и с POSIX‑сигналами: из‑за отсутствия их полноценной поддержки из набора исключены kill и timeout. По схожим архитектурным причинам пришлось отложить реализацию таких специфичных для Unix инструментов, как mkfifo, mknod и chroot.
Ещё один нюанс связан с особенностями файловых систем. NTFS обрабатывает символические ссылки через точки повторной обработки (reparse points). Linux опирается на индексные дескрипторы (inode). Из‑за такого фундаментального отличия простой вызов ln -s срабатывает, но поведение при рекурсивном копировании или удалении — например, cp -r или rm -rf, — оказывается неожиданным, если приходится обрабатывать вложенные ссылки.
Кроме того, разница в обозначении концов строк — CR, LF в Windows и LF в Linux — иногда влияет на работу текстовых утилит вроде cat, grep или sort. Чтобы избежать непредвиденных результатов при чтении файлов из разных источников, разработчики пакета рекомендуют явно указывать флаг --binary или учитывать кодировку.
Производительность пакета в целом выше, чем у слоев совместимости, поскольку он работает напрямую с WinAPI. Однако в сценариях с очень большим количеством файлов (особенно, когда счет идет на миллионы) могут проявляться особенности NTFS на фоне ext4.
Сообщество уже начало тестировать пакет в реальных задачах, и первые отчеты показывают стабильность для большинства повседневных операций. Репозиторий открыт, так что можно вносить правки или предлагать новые функции.
Что в итоге
Появление Coreutils — заметный шаг в сторону уменьшения трения между платформами. В будущем стоит ожидать расширения списка поддерживаемых команд и более тонкой настройки их поведения под специфику Windows.
Уже сейчас пакет закрывает потребности в основных операциях с файлами и текстом. Доступны ls, cp, mv, rm, cat, grep, find, xargs и другие популярные инструменты. Однако в сложных сценариях, когда требуется вся функциональность POSIX, WSL по‑прежнему остается безальтернативным вариантом.