Глава 9. Максимизируем возможность взаимодействия Windows

wslpath это встроенный в WSL инструмент, который позволяет простое преобразование путей между эквивалентами WSL и Windows и наоборот (Рисунок 9-1):

> wslpath C:\\Users\\Hayden 
/mnt/c/Users/Hayden

> wslpath -w /mnt/c/Users/Hayden 
C:\Users\Hayden
		

wslpath полезен для задач сценариев в Windows из WSL, причём без необходимости синтаксического разбора и повторного выравнивания символов, в особенности всех таких как \ и /s, которые надлежит экранировать в sed и grep. wslpath в особенности мощен при работе на пару с wslenv, подробности по которой приводятся ниже.

wslutilities это набор инструментария Патрика Ву, который был адаптирован некоторыми дистро, публикуемыми в Microsoft Store. По умолчанию Ubuntu и Pengwin содержат wslutilities. wslutilities доступны и для ряда прочих дистро, таких как SUSE, Alpine, Debian, CentOS и openSUSE. wslutilities содержат такие инструменты:

wslusc позволяет вам создавать некий ярлык для приложений Linux на рабочем столе Windows. Например, установим текстовый редактор GNOME gedit (Рисунок 9-2):

> sudo apt -y install gedit
		

Затем подберём подходящую иконку для gedit выполнив поиск в /usr/share/icons иконки, содержащей название gedit (Рисунок 9-3):

> find /usr/share/icons/ -name "*gedit*.svg"
		

После этого выполним wslusc, определяя что gedit это приложение с графическим интерфейсом при помощи флага -g; название закладки gedit через -n 'gedit'; описание иконки мы находим в -i вслед за своей командой gedit (Рисунок 9-4):

> wslusc -g -n 'gedit' -i /usr/share/icons/Humanity/apps/48/gedit-icon.svg gedit
		

И теперь у вас имеется на вашем рабочем столе ярлык для gedit (Рисунок 9-4). Обратите внимание на то, что приложения с графическим интерфейсом всё ещё требуют запущенного в Windows X сервера пока в WSL не будет запущена официальная поддержка прикладных приложений с графическим интерфейсом.

wslsys предоставляет некоторые базовые системные сведения, полезные при заполнении отчётов об ошибках, связанных с WSL (Рисунок 9-5).

Для применения в сценариях вывод wslsys можно обрабатывать grep. Например

> wslsys | grep 'Theme' | sed 's/^.*: //'
		

возвратит просто “light” или “dark” для Темы Windows.

wslfetch это подобный neofetch инструмент, также предоставляющий сведения и о системе хоста Windows, например номер сборки Windows (Рисунок 9-6).

wslvar позволяет вам выполнять выборку переменных окружения Windows, таких как %APPDATA% и %USERPROFILE%. Например, если вы желаете совместно использовать некий сценарий, который выполняет запись в домашнюю папку пользователя Windows, вы не захотите твёрдо кодировать /mnt/c/Users/Hayden, ибо имена пользователей и путей прочих пользователей будут иными.

Вы можете применять сочетание wslpath и $(wslvar USERPROFILE) вместо выборки такого местоположения и последующего преобразования его в путь Linux, который бы понимал WSL, например (Рисунок 9-7):

> touch hello
> cp hello $(wslpath $(wslvar USERPROFILE))
		

wslview регистрирует себя в качестве браузера по умолчанию в WSL, который при запуске откроет соответствующий URL в установленном по умолчанию браузере Windows. Например, приводимое ниже откроет указанный URL в Microsoft Edge, установленном по умолчанию браузере, который настроен в моём Windows 10 (Рисунок 9-8):

> wslview http://boxofcables.dev
		

Тем не менее, wslview не останавливается только на URL. Вы можете применять wslview для открытия любого файла из WSL при помощи установленного по умолчанию для такого типа файлов приложения в Windows. Например, приводимое далее откроет файл в Notepad, установленном по умолчанию в Windows 10 редакторе для файлов .txt (Рисунок 9-9):

> echo 'hello Patrick' > textfile.txt
> wslview textfile.txt
		

Перенаправление это механизм, в котором вы можете получать вывод из исполняемой команды и запитывать его как входные данные для другой команды. Зачастую это носит название “конвейера” (“piping”) и он обычен для применения в командной строке. В оболочке Linux он обычно помечается символом |, который в большинстве раскладок клавиатур доступен через shift+\.

Другой распространённый шаблон состоит в применении содержимого некого файла в качестве входных данных для команды или для записи выходных данных из команды в файл. Это, как правило, обозначается символами << и >>. (Это два символа < и два символа >, а не единственные символы кавычек « и ».)

при использовании механизма конвейера могут создаваться цепочки выполняющие сложные действия команд без требования от вас написания некой программы для выполнения всего процесса. Например, вы можете применять gzip для сжатия файла, преобразовать его в кодировку base64 с тем, чтобы он подходил для отображения или отправки в текстовом формате и направить этот текст base64 в gnupg для его подписи с помощью ключа “PGP” и печати полученного результата в вашем терминале.

Соответствующая команда, описывающая цепочку событий такова (Рисунок 9-10)

> gzip --stdout /etc/hosts | base64 | gpg --clear-sign
		

Если у вас нет ключа GPG, вы можете создать его при помощи

> gpg --full-gen-key
		

Если вы получите сообщение об ошибке “gpg: signing failed: Inappropriate ioctl for device”, тогда установите

> export GPG_TTY=$(tty)
		

Этот пример показывает как мы получаем вывод от стоящей слева от символа | команды и “отправляем конвейером” этот вывод в команду справа. В данном случае мы пользуемся механизмом конвейера дважды, когда в первый раз мы получаем вывод от gzip и передаём его в base64, а второй раз получаем вывод из команды base64 и передаём его в gpg. Мы можем делать это с отдельной программой, которая сохраняет вывод и запитать им входные данные своей следующей команды. Мы могли бы написать такую программу, однако, наш механизм конвейера намного проще для немедленного восприятия и может быть записан быстро и просто.

При помощи WSL в Windows мы можем пользоваться механизмом конвейера для перенаправления ввода и вывода к и из команд между Windows и WSL и наоборот. Это обрастает особой мощью, когда вы осознаете, что способны выполнять скачок между Windows и WSL множество раз в неком едином контейнере.

 

Конвейер от WSL к Windows

В качестве простого примера мы можем воспользоваться clip.exe из Windows в сочетании с конвейером из WSL для быстрого помещения текста в буфер обмена Windows для его использования при помощи функциональной возможности вставки в предпочитаемые вами программы.

> cowsay "Hi readers!" | clip.exe
		

Это снабдит нас следующим в нашем буфере обмена для вставки при помощи Ctrl+V (Рисунок 9-11):

 -------------
> Hi readers! <
 -------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||
		

По умолчанию, значение переменной PATH из Windows передаётся в WSL с тем, чтобы вы могли выполнять программы применяя те же самые ожидания, как если бы вы исполняли их непосредственно из командной строки Windows. Для тех исполняемых файлов, которые не находятся во вложении в PATH вы также можете применять их полное местоположение.

Эквивалентом предыдущего с применением полного местоположения clip.exe было бы

> cowsay "Hi readers!" | /mnt/c/Windows/System32/clip.exe
		

Расширяя это, мы могли бы заменить clip.exe неким коротким сценарием PowerShell, который пользуется API “Component Object Model” (COM) Windows для составления некого нового электронного сообщения в Microsoft Outlook с необходимым текстом из своего конвейера, вставляемым в его тело.

Здесь для создания отличий исходного кода мы воспользуемся git format-patch, подпишем его своим собственным ключом PGPи поместим подписанный результат в тело электронного сообщения в Microsoft Outlook:

> git format-patch --stdout HEAD~1 | \
GPG_TTY=$(tty) gpg --clear-sign | \
powershell.exe '
  $M=(New-Object -ComObject Outlook.Application).CreateItem(0);
  $M.Body=$input | %{$r=""}{$r+="$_`n"}{$r}; $M.BodyFormat=1;
  $M.Display()'
		

Мы можем сохранить этот код PowerShell в некий файл для повторного применения; давайте назовём его sendmail.ps1 и передадим значение пути вместо того чтобы переписывать его дословно всякий раз когда он нам понадобится (Рисунок 9-12).

Для создания нового сообщения Outlook из вывода своей команды мы можем затем выполнить такое (Рисунок 9-13):

> git format-patch --stdout HEAD~1 | GPG_TTY=$(tty) gpg --clear-sign | powershell.exe -File C:/Users/Hayden/sendmail.ps1
		

 

Конвейер от Windows к WSL

Во многом схожим образом с конвейером из WSL в Windows мы можем осуществлять и обратную операцию. Мы можем выполнить команду в Windows и отправить конвейером её вывод в другую команду в WSL. Давайте рассмотрим ситуацию, при которой мы бы желали найти все службы Windows, которые относятся к Xbox. Для достижения этого мы воспользуемся “cmdlet” Get-Service PowerShell и отправим конвейером его вывод в grep из WSL для фильтрации этого вывода только для строк, содержащих слово Xbox (Рисунок 9-14):

PS C:> Get-Service | wsl.exe -d Ubuntu-20.04 grep Xbox
		

Мы также можем получить вывод от своей команды WSL и передать его обратно в другой cmdlet PowerShell. Заменяя grep на аналогичную команду awk, которую мы также можем применять для выделения только второго столбца, мы можем запускать и останавливать все эти службы совместно. Ниже я показываю это для запуска и останова службы ssh-agent с применением фильтрации своего текста на ssh от имени Администратора.

Если вы получите сообщение "Start-Service: Service 'OpenSSH Authentication Agent (ssh-agent)' cannot be started due to the following error: Cannot start service 'ssh-agent' on computer '.'.", тогда вам придётся разрешить запуск вручную ssh-agent (Рисунок 9-15):

PS C:> Set-Service ssh-agent -StartupType Manual
		

Перенаправление файлов позволяет вам сохранять вывод некой команды в файл или применять файл в качестве входных данных для команды. Некий файл для входных данных обозначается в Bash символом <, за которым следует название файла, содержимое которого вы бы хотели применить как ввод для команды, в то время как файл для вывода, наоборот, указывается при помощи символа > с идущим за ним названием файла для того файла, в котором надлежит сохранять вывод этой команды.

В качестве простого примера перенаправления файла мы воспользуемся содержимым /etc/hosts в качестве входных сведений для команды base64; мы записываем это как

> base64 < /etc/hosts
		

При помощи base64 было бы проще записать base64 /etc/hosts без перенаправления соответствующего файла, однако это помогает только командам, которые допускают применение названия файла в качестве параметра. Это к тому же не проиллюстрировало бы перенаправления файла.

Подобным образом, для сохранения вывода команды tar, которая создаёт архивы любого числа файлов, мы записываем это как

> tar c /etc/hosts > hosts.tar
		

И снова, tar обладает встроенным параметром, с которым проще выполнять это действие так:

> tar cf hosts.tar /etc/hosts
		

И командная строка Windows, и PowerShell, оба, также поддерживают понятие перенаправлений файлов, что означает, что мы можем применять его для перенаправления файла в командной строке или окне PowerShell в команду WSL. Ниже мы получаем содержимое файла Windows hosts и копируем его дословно в файл hosts в нашем дистро WSL по умолчанию:

> wsl.exe -u root tee /etc/hosts < C:\Windows\System32\drivers\etc\hosts
		

Помимо перенаправления файлов Bash предоставляет функциональную возможность с названием “heredoc”. Это позволяет вам записывать входные данные из множества строк в команду без необходимости вначале записывать текст в файл. “heredoc” определяется при помощи << с идущим следом любым уникальным словом, которое будет применяться для указания положения конца такого входного текста. heredoc требует своего нахождения в самом конце соответствующей команды или конвейера, для которого он применяется в качестве входных данных. Чтобы указать конец входных данных требуется поместить само такое слово, причём без идущих перед ним пробелов или табуляций и оно может быть любым словом, которое вы пожелаете, только если оно не встречается естественным образом в самом тексте. Распространённым индикатором конца входных данных является EOF.

Например, вот образец простой команды для вывода на печать введённого текста обратно в консоль чтобы показать как это работает:

> cat <<ENDOFINPUTINDICATOR
Hi readers!
The next line indicates the end of this input text
ENDOFINPUTINDICATOR
		

Мы можем воспользоваться этой функциональной возможностью для отправки любого произвольного текста в свои команды, включая команды Windows. Ниже приводится некий пример (Рисунок 9-16), применяющий sendmail.ps1 , которым мы пользовались ранее в разделе Конвейер между Windows и WSL для написания нового электронного сообщения в своём терминале (Рисунок 9-17):

PS C:> powershell.exe -File C:/Users/Hayden/sendmail.ps1 <<EOF
Hi, Readers
This text will be used as the body or a new email message in Microsoft Outlook. Congratulations on learning about Heredocs.
Best regards,
Hayden
EOF
		

Windows и WSL могут совместно применять переменные среды. Это небольшие записи текстовых данных в памяти, которые пересылаются запущенной вами программе. По умолчанию переменные среды Windows и среды в WSL разделены, однако это можно настраивать при помощи особой именованной переменной с названием WSLENV. Эта переменная опрашивается всякий раз когда пересекается граница между Windows и WSL, поэтому вы можете изменять её всякий раз когда она удовлетворяет вашему рабочему процессу.

Например, вы можете определить подобную переменную JAVA_HOME, указывает на местоположение установленной среды времени исполнения Java, при пересечении границы между Windows и WSL производится переход установкой переменной WSLENV в значение JAVA_HOME/p.

ы можете добавить любое число названий переменных среды в своей конфигурации WSLENV, разделяя записи двоеточием. В данном случае у нс имеются описанными JAVA_HOME и OneDrive (Рисунок 9-18).

Значение /p каждой предыдущей настроенной переменной сообщает WSL о трансляции между путями Windows и WSL в значениях каждой из таких переменных. Например, для предыдущей установке WSLENV в Windows, значения переменных в Windows выглядят как:

C:\Program Files\AdoptOpenJDK\jdk-14.0.2.12-hotspot\
C:\Users\Hayden\OneDrive
 	   

В то время как в WSL они выглядят следующим образом по причине трансляции путей, на которую указывает /p:

/mnt/c/Program Files/AdoptOpenJDK/jdk-14.0.2.12-hotspot/
/mnt/c/Users/Hayden/OneDrive
 	   

Дополнительно к /p имеются и прочие суффиксы. Вот все применяемые суффиксы:

Вы также можете комбинировать /u и /w, либо /p или /l. Например, ниже приводятся некоторые варианты, которые вы можете применять, но это не исчерпывающий перечень:

Файловые системы поступают во множестве форм, причём Windows не поддерживает специфичные для Linux. Мы можем применять WSL2 для доступа к таким ранее не доступным местам и выставлять их в приложения Windows через особенный путь \\wsl$ WSL в Windows и узел Linux в Проводнике Windows (Рисунок 9-19).

Совместные файлы Windows поддерживаются через drvfs, которая передаёт известные местоположения Windows в среду WSL. Прежде всего, позвольте нам посмотреть как это делается при помощи соответствия Windows Share для Буквенных устройств в Windows:

В качестве альтернативы установки соответствия Совместного ресурса (Share) Буквенному устройству, мы можем воспользоваться значением пути “UNC” при вызове mount. Основное предостережение состоит в том, что Windows будет применять установленный по умолчанию набор полномочий и они не могут перекрываться при данном методе. Если вам требуется применять другие полномочия, вам следует воспользоваться предыдущим методом соответствия Буквенным устройствам.

Одной из замечательных функциональных возможностей Linux является то, что вы можете применять WSL2 с поддержкой для файловых систем на основе “FUSE”. FUSE это сокращение для “Filesystem in User space”, когда реальный драйвер файловой системы запускается как программа вместо того чтобы выступать частью своего ядра. Это означает, что вы можете применять всякую файловую систему, которая обладает драйвером FUSE не изучая как это сделать и не применяя предварительно собранное индивидуальное ядро. Отличной допускающей FUSE файловой системой выступает “SSHFS”, которая пользуется подключениями Безопасной оболочки (Secure Shell) к удалённому ПК и выставляет такую удалённую файловую систему локально.

Для монтирования некой файловой системы SSHFS мы должны прежде всего изменить файл /etc/fuse.conf чтобы добавить строку, содержащую user_allow_other. Это сделает для нас возможным применять параметр allow_root при монтировании такой файловой системы. Обратите внимание, что это требует установки sshfs и выработки ключей ssh.

Теперь мы можем вызывать sshfs, а потом создание папки, которой владеет той пользователь, который исполняет sshfs:

> sshfs -o idmap=user,uid=1000,gid=1000,allow_root server:/root/test /mnt/test
		

Применяя в WSL файловые системы на основе FUSE с предписанным параметром allow_root в момент монтирования, мы делаем возможным для Проводника Windows видеть файлы с помощью узла Linux в боковой панели. Такая файловая система выставляется через значение \\wsl$\distro\path\to\mountpoint пути UNC (Рисунок 9-20).

Основная магия этого допустима любую файловую систему FUSE, которая изначально не поддерживается естественным путём в Windows, например, SSHFS, можно применять из любого приложения Windows, которое поддерживает открытие пути UNC. Например, мы можем открыть в notepad.exe некий файл в удалённом сервере через WSL2 (Рисунок 9-21).

Это мощная функциональная возможность, поэтому не пользуйтесь ею, если она вам некомфортна.

С учётом сказанного, Linux поддерживает огромный массив файловых систем, причём некоторые из них более узнаваемы чем иные. Обычно предполагаются ext2/3/4, XFS и и btrfs. При наличии WSL2 мы способны смонтировать эти файловые системы в своём дистро и затем выполнять доступ к ним из Windows. Это означает, что через WSL2 Windows теперь поддерживает все натуральные файловые системы Linux.

Какие файловые системы поддерживаются вашим в запущенным настоящее время ядром вы можете обнаружить выполнив внутри WSL2 следующее:

> cat /proc/filesystems
		

 

В разделе

Если у вас имеется жёсткий диск с естественным разделом Linux н нём, тогда вы имеете возможность выставить его в своём дистро WSL2 воспользовавшись параметром --mount из wsl.exe. Это имеет единственное предостережение, что здесь требуется чтобы такой раздел пребывал бы на диске, который в настоящий момент не используется Windows, например, когда этот раздел является вторым разделом в вашем загрузочном диске Windows.

Вам следует знать, значение пути к внутреннему диску Windows при использовании wsl.exe –mount, который вы можете обнаружить выполнив в своём окне PowerShell такую команду:

PS C:> wmic diskdrive list brief
		

Это отобразит вывод подобный такому (Рисунок 9-22).

После того как вы обнаружили свой DeviceID, который выглядит как \\.\PHYSICALDRIVEn, где n это начинающийся с 0 номер, вы можете построить необходимую команду wsl.exe следующим образом:

> wsl.exe --mount \\.\PHYSICALDRIVE1 --partition 2
		

 

В образе диска (файл VHDX)

Вместо применения физического диска или раздела вы можете воспользоваться образом виртуального жёсткого диска, хранимого в виде файла .vhdx. Обычно они создаются системой виртуализации Hyper-V Windows, для которой WSL2 представляет собой очень особый вариант.

Этот метод очень похож на применение физического диска или раздела с той лишь разницей, что вместо физически подключаемого диска вы воспользуетесь PowerShell для монтирования своего файла .vhdx в Windows и затем продолжите аналогично тому, как вы обычно обращаетесь с физическим диском или разделом.

Для монтирования в Windows файла .vhdx выполните приводимое ниже в окне PowerShell после того как вы обеспечили замену <pathToVHDX> на свой файл .vhdx:

PS C:> > Write-Output \\.\PhysicalDrive$((Mount-VHD -Path <pathToVHDX> -PassThru | Get-Disk).Number)
		

Это смонтирует соответствующий файл виртуального диска и затем выведет на печать его название \\.\PhysicalDrive, которое вы можете применять в командах wsl.exe --mount.

 

Параметры монтирования

В качестве необязательных вы также можете добавлять любые из приводимых ниже параметров, которые отражают их двойников из Linux:

Когда вы смонтировали файловую систему в WSL2, применяются обычные методы доступа из Windows, такие как узел Linux в Проводнике и установленные пути \wsl$ UNC.

После того как вы завершите работу со своим диском или дисковым образом, вы можете удалить его из WSL2 при помощи команды --unmount:

wsl.exe --unmount >DiskPath> 
		

Например:

> wsl.exe --unmount \\.\PHYSICALDRIVE1
		

Как альтернатива, вы можете размонтировать все диски и образы, опуская параметр значения пути к диску:

> wsl.exe --unmount