Как запускать программы Windows из WSL

Как работает командная интеграция

Microsoft называет этот механизм command-line interop: Linux shell может запускать Windows executable, а Windows shell — Linux-команды через `wsl.exe`. Из WSL доступен Windows PATH, поэтому многие системные программы находятся без полного пути. Расширение `.exe` важно: `notepad.exe` однозначно указывает на Windows-приложение, а `notepad` Bash будет искать как Linux-команду. Аргументы передаются дальше Windows-процессу, однако сначала строку разбирает Bash. Отсюда типичная проблема с кавычками, долларами и обратными слэшами в сложной команде PowerShell. Чем длиннее команда, тем выгоднее вынести её в `.ps1` или `.cmd` и передать только параметры.

Совет: Если три уровня кавычек уже трудно читать, сохраните Windows-команду в отдельный скрипт. Это упрощает отладку и снижает риск неправильного экранирования.

Полезные сценарии WSL interop

1. Открыть текущий Linux-каталог в Проводнике: `explorer.exe .`. Windows получает корректный доступ к текущей папке через WSL.
2. Запустить PowerShell: `powershell.exe -Command "Get-Date"`. Для PowerShell 7 при установленном `pwsh.exe` можно вызывать его аналогично.
3. Скопировать Linux-вывод в буфер Windows: `printf "hello" | clip.exe`. Это удобно для путей, ключей и результатов фильтрации.
4. Передать путь Windows-программе. Если она не понимает `/home/user/file`, преобразуйте его командой `wslpath -w /home/user/file`.
5. Работать с диском C: из Linux через `/mnt/c/..`. Это другой случай: файл физически находится в Windows-файловой системе и уже имеет естественный Windows-аналог.
6. Комбинировать конвейеры только при понятном формате данных. При записи текста в файл проверяйте кодировку и окончания строк, особенно если данные потом читает Windows-программа.

Важно: Для Linux-файлов не стройте путь через AppData вручную. Используйте `explorer.exe .`, `wslpath` или `\wsl$`.

Команда и результат

• `explorer.exe .`. Открывает текущую WSL-папку в Проводнике
• `powershell.exe -Command "Get-Date"`. Выполняет PowerShell-команду
• `cat file.txt | clip.exe`. Копирует текст в буфер Windows
• `wslpath -w /home/user/file`. Преобразует Linux-путь в Windows-формат
• `cmd.exe /c echo %USERNAME%`. Запускает команду через Windows CMD

Предупреждение: Не все Windows GUI-программы понимают Linux-путь `/home/..` как аргумент. При сомнении сначала преобразуйте путь.

Пути /mnt/c, \wsl$ и wslpath

Windows-диски обычно смонтированы в WSL под `/mnt`, поэтому `C:\Users\Name\Documents` соответствует `/mnt/c/Users/Name/Documents`. В обратном направлении Windows получает доступ к Linux-файлам через `\wsl$\<дистрибутив>\..` или `\wsl.localhost\..`. Не следует вручную открывать служебный ext4.vhdx и редактировать его содержимое: Microsoft предупреждает, что прямое изменение внутренних файлов дистрибутива Windows-инструментами может привести к повреждению. Для передачи пути в Windows executable используйте `wslpath -w`; для обратного преобразования пригодится `wslpath -u`. Такой подход делает скрипт понятнее и уменьшает количество хрупких ручных замен слэшей.

Если .exe не запускается

• В имени есть расширение `.exe`.
• Программа доступна в Windows PATH или указан полный путь.
• Кавычки не были неправильно обработаны Bash.
• Файловый путь преобразован в понятный Windows-формат.
• Interop и добавление Windows PATH не отключены пользовательской конфигурацией.

Где interop полезен, а где лучше разделить среды

Interop особенно удобен для коротких мостов: открыть папку, скопировать текст, вызвать Windows-only утилиту или отдать результат Linux-фильтру. Но для массовых операций по тысячам файлов лучше выбрать одну файловую систему и один набор инструментов, чтобы не тратить время на постоянные переходы и преобразования путей. В переносимых скриптах зависимость от `powershell.exe` стоит изолировать: на обычном Linux-сервере её не будет. Хорошая архитектура — явно разделить границу: Linux-часть готовит данные и путь, Windows-команда выполняет одну конкретную операцию и возвращает простой результат.

Кавычки, коды возврата и переменные среды при WSL interop

Сложность WSL interop чаще возникает не в самом запуске `.exe`, а на границе двух оболочек. Bash сначала разбирает `$VAR`, кавычки, обратные слэши, пайпы и перенаправления, поэтому строка, которую вы хотели отдать PowerShell или CMD, может измениться ещё до старта Windows-процесса. Для коротких команд используйте явные одинарные или двойные кавычки осознанно, а длинные сценарии лучше вынести в `.ps1` или `.cmd` и передавать только простые аргументы. После запуска проверяйте код возврата через `$?` или сохраняйте его сразу, если последующая Linux-команда может перезаписать статус. Помните и о переменных среды: WSL добавляет Windows PATH по стандартной конфигурации, но пользовательские изменения `.wslconfig` или `wsl.conf` могут изменить это поведение, поэтому «команда не найдена» не всегда означает отсутствие программы в Windows. При конвейерах тестируйте кодировку и окончания строк на небольшом образце, особенно если Windows-утилита создаёт текстовый файл, который затем читает Linux-скрипт. Для файлов используйте `wslpath`, а не ручную замену пути `/mnt/c` на Windows-путь, потому что пробелы и файлы внутри Linux быстро ломают самодельную логику. Чем меньше неявных преобразований вы оставляете на границе Windows/Linux, тем устойчивее такой сценарий в автоматизации.

Практическая проверка результата

Для автоматизации полезно явно нормализовать входы и выходы на границе сред. Если Linux-скрипт вызывает Windows-утилиту, заранее сформируйте Windows-путь, передайте его как один аргумент и сохраните stdout/stderr отдельно. Не рассчитывайте, что строка с пробелами и обратными слэшами переживёт несколько оболочек без кавычек. Аналогично, если результат Windows-команды будет анализировать `grep`, `awk` или Python в WSL, сначала посмотрите сырой вывод и убедитесь, что кодировка и переносы строк ожидаемые. Это устраняет большую часть «мистических» ошибок interop.

Как писать скрипты, которые не ломаются на границе Windows и Linux

Для одноразовой команды достаточно помнить про `.exe`, но в повторяемом скрипте лучше явно оформить границу между средами. Не склеивайте Windows-путь строками вида `C:\..` внутри Bash, если тот же путь можно получить через `wslpath`; это уменьшает ошибки с пробелами, обратными слешами и изменённой точкой монтирования дисков. Значения с пробелами передавайте отдельными аргументами и заключайте переменные Bash в кавычки. Если Windows-программа возвращает текст, проверьте кодировку и окончания строк до того, как результат попадёт в `grep`, `awk` или файл Linux. Для проекта также выберите «главную» файловую систему: если сборку запускают Linux-инструменты, репозиторий лучше держать внутри WSL и обращаться к нему из Windows лишь эпизодически. Если основная программа Windows постоянно работает с тысячами файлов, логичнее хранить их на NTFS. Interop удобен как мост, но постоянная работа через границу файловых систем может стать узким местом и сделать скрипт сложнее для переноса на обычный Linux.

Как упростить отладку

Сначала воспроизведите сбой одной короткой командой без конвейера, затем добавляйте преобразование пути, кавычки и pipe по одному. Так сразу видно, на какой границе меняются аргументы или формат вывода, и рабочий вариант легче перенести в скрипт.

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-20; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. WSL interop — Windows and Linux integration). Пример и формулировки — редакция N1RO на 2026-09-20.

• WSL interop — Windows and Linux integration
• How to manage WSL disk space