Microsoft выпустила Coreutils для Windows: cat, grep и ls без WSL
Microsoft опубликовала Coreutils for Windows — нативный набор UNIX-style утилит для Windows. После установки в PowerShell или CMD появляются привычные команды вроде cat, grep, find, xargs, ls, cp, mv, rm и десятков других. Устанавливается пакет через WinGet:
winget install Microsoft.CoreutilsНа первый взгляд это маленькая новость из мира командной строки. На практике — признание старой проблемы Windows: разработчики, CI-скрипты и теперь AI-агенты живут в мире, где базовый язык автоматизации давно стал POSIX-подобным. Windows всё это время предлагала PowerShell и старые CMD-команды, но универсальным межплатформенным языком они так и не стали.
Что именно выпустила Microsoft
Coreutils for Windows — это Microsoft-maintained сборка на базе проекта uutils/coreutils, Rust-реализации GNU coreutils. В пакет также входят findutils и GNU-compatible grep. Всё упаковано как один multi-call binary: внутри один исполняемый файл, но наружу он раскрывается привычными именами команд — cat.exe, grep.exe, find.exe и так далее.
Проект опубликован как preview. Это важно: речь не о том, что Windows внезапно стала Linux, и не о полной эмуляции POSIX-системы. Это набор практических утилит для ежедневной работы с файлами, текстом, пайпами и скриптами, собранный так, чтобы он запускался нативно в Windows без WSL, MSYS2, Git Bash или Cygwin.
Зачем это Windows-разработчику, если есть PowerShell
PowerShell сильный инструмент, но он решает другую задачу. Он объектный, многословный и хорошо работает внутри Windows-экосистемы. Проблема начинается там, где нужно быстро перенести привычный shell-фрагмент между Linux, macOS, контейнером, WSL и Windows:
grep -R "TODO" src | head -20
find . -name "*.log" -mtime +7 -delete
cat package.json | grep versionДля Unix-подобных систем это повседневная грамматика. Для Windows такая грамматика исторически требовала дополнительной прослойки: Git Bash, WSL, Cygwin, MSYS2 или переписывания под PowerShell. Coreutils for Windows не отменяет PowerShell, но добавляет слой совместимости, который нужен именно в смешанных средах.
И это не только про людей. Всё больше команд в терминале сегодня пишет не человек, а кодинг-агент. Он видел миллионы примеров на Stack Overflow, в README, GitHub Actions, Dockerfile и документации. В этих примерах почти всегда встречаются grep, sed, find, xargs, cat, ls, rm. Когда такой агент попадает в чистую Windows-среду, он часто сначала делает Unix-команду, получает ошибку, тратит контекст на диагностику, потом пытается вспомнить PowerShell-эквивалент и снова рискует ошибиться.
Похоже, Windows адаптируется не только к людям, но и к агентам
Самая интересная часть новости не техническая, а культурная. Десятилетиями Windows говорила разработчикам: у нас есть свои команды, свои правила, свой shell, изучайте их. Но в 2026 году в терминале всё чаще сидит AI-агент, обученный на открытом вебе. А открытый веб для командной строки говорит на Unix.
Можно, конечно, объяснять агенту: если ты на Windows, используй Get-ChildItem вместо ls, Select-String вместо grep, Remove-Item вместо rm. Но это постоянный налог на промпты, токены и ошибки. Проще сделать так, чтобы привычные команды действительно существовали.
В этом смысле Coreutils for Windows выглядит как инфраструктурный ответ на новую реальность: разработческая машина должна быть понятна не только человеку, который помнит синтаксис PowerShell, но и агенту, который действует по статистически наиболее распространённым паттернам из документации и репозиториев.
Но это не магическое превращение Windows в POSIX
У проекта есть честно описанные ограничения. Часть команд конфликтует с встроенными командами CMD и PowerShell. Например, cat, ls, pwd, rm, sleep и tee в PowerShell уже существуют как aliases или команды. Что именно запустится, зависит от shell, порядка в PATH и таблицы aliases. Microsoft отдельно указывает, что нужен PowerShell 7.4 или новее.
| Категория | Что важно помнить |
|---|---|
| Конфликты имён | cat, ls, rm, pwd и другие могут пересекаться с PowerShell aliases |
| Переводы строк | Windows-файлы часто используют CRLF, что влияет на точное сопоставление и byte-level операции |
/dev/null |
В Windows используется NUL, а не POSIX-путь |
| Сигналы | POSIX-сигналов вроде SIGHUP и SIGPIPE нет; Ctrl+C работает как ожидается |
| Права доступа | Windows ACL не равны POSIX permission bits, поэтому часть сценариев с правами работает иначе |
| Симлинки | Чтение работает, создание требует Developer Mode или elevated terminal |
Некоторые upstream-команды сознательно не включены. Среди них chmod, chown, chroot, groups, id, mkfifo, stty, tty, uname, sync, shred и другие утилиты, завязанные на POSIX-концепции или плохо ложащиеся на Windows-модель.
Почему Rust и uutils имеют значение
Microsoft не портировала GNU coreutils напрямую. Под капотом используется uutils — кроссплатформенная Rust-реализация GNU coreutils. Цель uutils — быть drop-in replacement для GNU tools там, где это возможно, и относиться к отличиям поведения как к багам.
Для Windows это практичный выбор. Rust-проект уже изначально думает о нескольких платформах: Linux, macOS, BSD, Windows, WASI. Microsoft добавляет Windows-focused упаковку, installer, интеграцию с WinGet и решения для конфликтов с существующими Windows-командами. Получается не отдельный одноразовый порт, а сборка поверх живого upstream-проекта.
Кому это реально полезно
Первый очевидный сценарий — разработчики, которые постоянно прыгают между Windows, WSL, Linux-серверами и контейнерами. Нативный grep или find в Windows Terminal снижает количество мелких переключений контекста. Не нужно каждый раз думать, в каком shell ты сейчас находишься и почему привычная команда внезапно недоступна.
Второй сценарий — onboarding и dev setup. Если проект в README просит выполнить простые Unix-команды, Windows-пользователь получает меньше специальных инструкций. Не все скрипты начнут работать автоматически, но множество маленьких команд для поиска, фильтрации и обработки текста перестанут быть проблемой.
Третий сценарий — AI-кодинг. Агенту проще работать в окружении, где базовые команды из его обучающего мира действительно существуют. Это не делает агента умнее, но уменьшает количество бессмысленных циклов: попытка выполнить команду, ошибка, диагностика shell, переписывание команды, новая ошибка. Для задач, где агент часто вызывает терминал, это заметная экономия контекста и времени.
Почему это произошло только сейчас
У Windows давно были способы получить Unix-утилиты: Cygwin, MSYS2, Git for Windows, BusyBox, GnuWin32, WSL. Но все они воспринимались как отдельная среда или сторонний слой. Новость в том, что теперь сама Microsoft поддерживает такой пакет и публикует его в обычном Windows-канале установки через WinGet.
Это хорошо совпадает с общим движением Windows последних лет: Windows Terminal, WSL, Dev Drive, sudo for Windows, PowerToys, WinGet. Платформа всё меньше пытается доказать, что у неё должен быть отдельный мир командной строки, и всё больше подстраивается под реальные workflows разработчиков.
AI-агенты только ускоряют этот сдвиг. Человека можно переучить, команду можно отправить на внутренний тренинг, но модель уже несёт в себе статистику публичного кода. Если в этой статистике grep встречается чаще, чем Select-String, платформе дешевле поддержать grep, чем каждый раз компенсировать это инструкциями.
Вывод
Coreutils for Windows — не революция и не конец PowerShell. Это маленькое, прагматичное признание того, что современная разработка стала кроссплатформенной, а язык повседневной автоматизации в ней в основном Unix-подобный. Windows не обязана становиться Linux, чтобы дать разработчикам и агентам привычные инструменты там, где они нужны.
Самое точное описание этой новости: Microsoft уменьшила трение. Меньше специальных Windows-инструкций в README, меньше переключений в WSL ради grep, меньше токенов, сожжённых агентом на понимание того, почему очевидная команда не работает. Для preview-релиза это уже достаточно полезный результат.
Источники: Coreutils for Windows на Microsoft Learn, microsoft/coreutils на GitHub, uutils/coreutils на GitHub.