Глава 5. Настройка дистрибутивов WSL

Установки для дистрибутива настраиваются в /etc/wsl.conf для каждого соответствующего дистро. Этот файл считывается в “boot” самим WSL. Некоторые издатели дистро публикуют образы для WSL включая некий файл wsl.conf с настройками по умолчанию. Однако если он не присутствует в вашем дистро, тогда вы можете вручную создать или изменить этот файл когда вы желаете перекрыть настройки по умолчанию. Настройки по умолчанию представлены здесь (Рисунок 5-1).

Настройки automount содержат возможность монтирования устройств Windows, например, диска C под /mnt/c для предоставления возможности взаимодействия через файловую систему.

Автоматическое монтирование устанавливается Булевым значением “enabled” равное истине в /etc/wsl.conf:

[automount]
enabled = true
		

Значением по умолчанию является true для автоматического монтирования устройств Windows. Если вы желаете изолировать свой экземпляр WSL от файловой системы Windows, вам следует установить его в значение ложь:

[automount]
enabled = false
		

Папка root для монтирования устройств Windows устанавливается в /etc/wsl.conf при помощи строкового значения “root”:

[automount]
enabled = true
root = /mnt/
		

Значением по умолчанию является true. Если вы желаете смонтировать свои устройства Windows в другой папке, вы можете здесь определить где именно. Например, для монтирования их в /windrives/, установите

[automount]
enabled = true
root = /windrives/
		

Имейте в виду, что такая корневая папка должна существовать; если это не так, вам придётся создать её:

> sudo mkdir /windrives
		

/etc/fstab это традиционный файл настроек файловой системы Linux. Вариант загружать его или нет при запуска WSL может быть установлен в /windrives/ при помощи Булева значения “mountFsTab”:

[automount]
enabled = true
mountFsTab = true
		

Значением по умолчанию является true.

Вы можете настраивать /etc/fstab (Рисунок 5-2) для выполнения более расширенных функций монтирования при запуске WSL. Они могут включать виртуальные диски и совместные сетевые файловые ресурсы.

Если вы не желаете чтобы WSL выполнял синтаксический разбор этого файла, например, с целью большей изоляции вашей среды WSL, вы можете установить это значение ложным:

[automount]
enabled = true
mountFsTab = false
		

Однако, имейте в виду, что ваша корневая файловая система будет автоматически монтироваться при запуске и без синтаксического разбора /etc/fstab она будет монтироваться с установленными по умолчанию настройками WSL. Включение и отключение этого может быть полезным при устранении неисправностей расширенных настроек монтирования.

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

Такие параметры устанавливаются в /etc/wsl.conf при помощи строкового значения “options”, например:

[automount]
enabled = true
mountFsTab = true
options = "metadata,umask=22,fmask=11"
		

Замечание относительно того, как работают в WSL файловые полномочия:

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

Это можно изменить, тем не менее, при помощи параметра метаданных.

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

По умолчанию WSL будет монтировать файловую систему Windows при помощи UID и GID установленного по умолчанию пользователя дистро, обычно 1000 и 1000, соответственно.

Мы можем достичь того же самого результата выполняя такую команду:

> sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000,gid=1000,umask=22,fmask=11
		

Если вы знакомы с командой монтирования Linux, вы способны распознать некоторые из этих настроек.

Дополнительно к изменению сведений о том как обрабатываются полномочия систем NTFS и Linux, также имеется возможность того, как обрабатывать чувствительность к регистру между Linux и Windows.

Одним из самых больших отличий, которые способны обнаружить пользователи между Linux и Терминалом Windows состоит в обработке чувствительности к регистру файлов.

В файловой системе Linux, FILE.TXT и file.txt рассматривались бы как отдельные файлы, которые способны сосуществовать в одном и том же каталоге. Файловые системы Linux, тем самым, рассматриваются как чувствительные к регистру.

В файловых системах Windows, по умолчанию, Windows не позволил бы вам создать файл с названием file.txt в неком каталоге с уже имеющимся файлом, также именуемым FILE.TXT , потому что они бы рассматривались как один и тот же файл; значение регистра в имени файла отбрасывается. По умолчанию в Windows файловые системы будут, таким образом, рассматриваться как не чувствительные к регистру. Windows 10, как потомок Windows NT, которая имела целью до некоторой степени совместимость с POSIX, обладал естественной способностью трактовать файлы как чувствительные к регистру, как и Linux; это просто отключено в угоду обратной совместимости с приложениями Windows 98 и прочими инструментами, которые исходят из ожидания от Windows нечувствительности к регистру.

Эту настройку можно изменить глобально, для всего Windows через установку в Реестре Windows, однако имейте в виду, что изменение этой настройки может иметь результатом необычное поведение приложений сторонних разработчиков, включая повреждения и утрату данных. Итак, как WSL обрабатывает чувствительность к регистру при монтировании папок Windows? Он применяет иной механизм, который обходит значение ключа Реестра, позволяя дистро WSL получать доступ к файлам, которые отличаются только регистром и, тем самым, вести себя стандартным способом “Linux”.

Однако, при работе с файловым доступом как из WSL, так и из Windws, это всё ещё способно вызывать проблемы, в особенности для программ Windows, выполняющих доступ к чувствительным для регистра файлам в подвергшихся изменениям из WSL файлам. Вместо того, чтобы принуждать пользователей изменять значение упомянутого выше глобального ключа Реестра, потенциально разрушающего сторонние приложения, команда WSL ввела чувствительность к регистру для каталогов в Windows 10 сборки 17107.

В совместно используемой между программами WSL и Windows папке, например, C:\WSLworkspace и /mnt/c/WSLworkspace, где со стороны программ WSL ожидается чувствительность к регистру, но могут быть проблемы для программ Windows, имеется возможность включения чувствительности к регистру только для C:\WSLworkspace. Такая функциональность встроена в fsutil.exe.

Для проверки состояния такой чувствительности к регистру для каталога из Windows, откройте PowerShell и исполните (Рисунок 5-3)

PS C:\> fsutil.exe file queryCaseSensitiveInfo <path>
		

Например, в каталоге нашего примера C:\WSLworkspace

PS C:\> fsutil.exe file queryCaseSensitiveInfo C:\WSLworkspace\
		

Для включения чувствительности к регистру для некого каталога Windows, откройте PowerShell в качестве Администратора и выполните (Рисунок 5-4)

PS C:\> fsutil.exe file setCaseSensitiveInfo <path> enable
		

Например, в каталоге нашего примера C:\WSLworkspace

PS C:\> fsutil.exe file setCaseSensitiveInfo C:\WSLworkspace\ enable
		

Для отключения чувствительности к регистру для некого каталога Windows, откройте PowerShell в качестве Администратора и выполните (Рисунок 5-5)

PS C:\> fsutil.exe file setCaseSensitiveInfo <path> disable
		

Например, в каталоге нашего примера C:\WSLworkspace

PS C:\> fsutil.exe file setCaseSensitiveInfo C:\WSLworkspace\ disable
		

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

Чувствительностью к регистру также можно управлять в параметрах автоматического монтирования, настраивая её установками “case”, например:

[automount]
enabled = true
mountFsTab = true
options = "metadata,case=off,umask=22,fmask=11"
		

Настройка case=dir установлена по умолчанию (default) и новые каталоги, создаваемые из WSL в файловых системах Windows будут чувствительными к регистру.

Настройка case=off означает, что новый каталог, создаваемые из WSL в файловых системах Windows будут не чувствительными к регистру и следовать традиционному методу Windows.

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

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

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

Для проверки UID и первичного вашего пользователя (Рисунок 5-6) воспользуйтесь

Для проверки UID и GID другого пользователя (Рисунок 5-7) примените

> id <username>
		

Например:

> id root
		

Изменение значений UID и GID в уже смонтированном устройстве окажет воздействие на доступность к имеющимся файлам и папкам.

Также имеется возможность персонализации устанавливаемых полномочий на вновь создаваемые файлы и папки через установку пользовательской маски создания файла. Значение пользовательской маски создания файла это значение шаблона для полномочий в новых файлах и папках. Основная цель такой маски состоит в отсечении прочь избыточных полномочий и установки безопасного набора полномочий новым файлам. Значение маски это сокращённая форма более длинного восьмеричного формата Linux для полномочий, которым вы могли пользоваться ранее.

Каждый файл в Linux обладает тремя классами связанных с ним полномочий; это полномочия для

Такие полномочия могут составляться из некой комбинации следующих полномочий для каждого класса:

Эти полномочия могут выражаться в символьном или цифровом виде

В символьной форме полномочия представляются как строка из девяти символов, составленных из r, w, x или -.

Например:

rwxr-xr--
 	   

Вы можете обнаружить полномочия файла в символьном виде при помощи команды ls -l (Рисунок 5-8).

Приведёнными выше полномочиями являются

rwxr-xr--
 	   

Дополнительные подробности до и после нашей символьной нотации также могут сообщить нам

Прочие полезные сведения здесь могут содержать

Полномочия также могут представляться в численном виде, с применением восьмеричной нотации. Чтение, запись и исполнение представляются в одном из восьми вариантов:

Наши полномочия из предыдущего примера, rwxr-xr--, превращаются в

Во многих случаях такое восьмеричное представление будет обладать цифровым префиксом. Вы можете видеть 754, выражаемое как 0754. Этот префикс содержит настройки для битов suid, sgid и “sticky”, которые являются расширенными полномочиями Linux, которые выходят за рамки данной книги, однако предоставляют вам возможность, помимо прочего, препятствовать записи в файл или его удалению даже когда пользователь обладает полномочиями, но не владелец этого файла.

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

По умолчанию, Linux назначает всем новым файлам восьмеричные полномочия 666, а всем новым папкам восьмеричные полномочия 777.

Значение файловой маски затем вычитается из назначаемых восьмеричных полномочий для установки полномочий, применяемых системой.

umask это побитовая маска; её биты вычитаются из “маскируемых” полномочий Linux.

Пример:

Для Ubuntu umask по умолчанию это 022.

В этом случае новый файл будет вначале создаваться с восьмеричными полномочиями 666 и затем вычитается “маска” 022, что приводит в результате к 644.

Fmask и dmask существуют для установки различных настроек umask под файлы и папки по отдельности.

Как уже обсуждалось ранее, файлы начинают с 666 и должны вычитать umask. Папки начинают с 777 и должны вычитать umask.

Umask допускает для вас вычитать один и тот же уровень из обоих, например 022. Однако применяя fmask или dmask вы можете устанавливать маски по отдельности, отличая дельту от значений стандартных уровней полномочий 777/666, причём как для файлов, так и для папок.

В нашем приведённом выше примере

[automount]
enabled = true
mountFsTab = true
options = "metadata,umask=22,fmask=11"
		

новые файлы и папки создавались бы с полномочиями, начиная с 666 и 777 соответственно.

Далее применение umask 022 приводило бы в результате к 644 для файлов и 755 для папок.

Однако, применяя fmask 011, которое перекрыло бы umask для новых файлов, вы бы получали для новых файлов полномочия 666 минус 011 или 655.

Новые папки создавались бы с системной umask 022, приводящей в результате 777 минус 022 или 755 для новых каталогов.

Вы также можете переопределить и это при помощи dmask по своему выбору.

Вы можете пожелать регулировать различные макси для файлов и папок, когда вы желаете яростно ограничивать доступ на чтение в прочие каталоги (высокое значение dmask), однако предоставлять широкий доступ в собственные каталоги пользователя (низкое значение fmask).

Прочие настройки монтирования

Обратите внимание на то, что прочие настройки монтирования которые могли бы обычно настраиваться дополнительными флагами при помощи mount здесь не могут вставляться. Для дополнительной тонкой настройки вам следует редактировать /etc/fstab. Ознакомьтесь с разделом Закладка файловой системы относительно установок, обеспечивающих чтение /etc/fstab.

[automount]
crossDistro = true
		

Монтирование между дистро включает некое пространство, /mnt/wsl, в котором любая монтируемая папка всяким дистро видна всем прочим дистро.

Значение по умолчанию (default) равно true.

Это поезно для совместного использования файлов между дистро.

Например, при включённом crossDistro в обоих дистро, вы можете монтировать некий файл из своего дистро WSL Ubuntu для доступа к нему из вашего дистро Fedora Remix (Рисунок 5-9).

В Ubuntu WSL:

> mkdir ~/ubuntufolder
> touch ~/ubuntufolder/helloworld
> mkdir /mnt/wsl/sharedfolder
> sudo mount --bind ${HOME}/sharedfolder /mnt/wsl/sharedfolder
		

Затем в Fedora Remix для WSL вы можете просматривать такой файл (Рисунок 5-10)

> ls /mnt/wsl/sharedfolder/
		

И наоборот, в некой корпоративной среде вы можете пожелать отключит монтирование между дистр для изолирования ваших дистро WSL с целью безопасности.

Библиотеки, которые являются коллекциями общих задач и подпрограмм, на которые полагаются приложения, являются “помещёнными” в некий кэш из какого- то набора путей, предписанного установками ldconfig.

Первичный файл настроек ldconfig располагается в /etc/ld.so.conf, однако в большинстве дистро этот файл напрямую отсылается ldconfig для загрузки дополнительных путей из множества файлов настроек, расположенных в /etc/ld.so.conf.d/.

/etc/ld.so.conf будет указывать на /etc/ld.so.conf.d/*, который, к примеру, будет содержать /etc/ld.so.conf.d/libc.conf, который содержит значение пути для пути /usr/local/lib библиотеки GNU C (Рисунок 5-11). Файлы настроек из /etc/ld.so.conf.d/* загружаются в алфавитном порядке.

Начиная со сборки 20150 Windows 10 WSL вставляет некий дополнительный файл в /etc/ld.so.conf.d/ с названием ld.wsl.conf, который добавляет для ldconfig соответствующий путь к библиотекам в /usr/lib/wsl/lib (Рисунок 5-12).

Это делает возможным доступ к особенным для WSL библиотекам под CUDA, DirectML и прочие вычислительные функции GPU (которые располагаются в %SystemRoot%\system32\lxss\lib).

Обычно вы будете желать чтобы WSL загружала эти каталоги для включения вычислений GPU. Настройки их загрузки устанавливаются в качестве установок автоматического монтирования:

[automount]
ldconfig = true
		

Значением по умолчанию является true.

Тем не менее, могут встречаться ситуации, при которых вы пожелаете отключать вычислительные функциональные возможности GPU, возможно, для сопоставления эталонного тестирования производительности с включённым GPU и без него, либо вы пожелаете подключать прочие драйверы. В таком случае вы можете предписать

[automount]
ldconfig = false
		

для отключения вставки ld.wsl.conf. Обратите внимание, что после отключения ld.wsl.conf вы пожелаете переработать свой кэш ldconfig при помощи

> sudo ldconfig
		

Файл hosts, и в Windows, и в Linux, это файл, который позволяет вам вручную настраивать разрешение доменных имён в вашем устройстве.

Когда ваш компьютер выполняет разрешение доменных имён, таких как ubuntu.com, он вначале проверяет именно это файл hosts, затем локальный кэш последних разрешённых доменов и потом, наконец, испускает запрос в ваш сетевой сервер DNS.

Если вы желаете по- простому достигать прочие устройства в своей сетевой среде по их названиям хостов, но не желаете настраивать свой собственный сервер DNS, вы можете вручную настраивать имена хостов в своём файле hosts.

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

По умолчанию, WSL скопирует ваш файл hosts Windows из C:\Windows\System32\drivers\etc\hosts через файл hosts дистро WSL в /etc/hosts при каждом запуске. Да, файлы hosts Windows и Linux совместимы.

Тот параметр, который указывает необходимость копирования файла hosts Windows (Рисунок 5-13) в ваш дистро WSL (Рисунок 5-14). устанавливается в /etc/wsl.conf при помощи Булева значения “generateHosts”:

[automount]
generateHosts = true
		

Значением по умолчанию является true.

Вы можете пожелать установку выработки hosts в значение ложь когда вы намерены сопровождать отдельный файл hosts для своего собственного дистро WSL. Обратите внимание, что хотя добавления в файл hosts вашего дистро WSL (Рисунок 5-14) будет копироваться в WSL, дополнения к файлу hosts вашего дистро WSL не будут синхронизироваться обратно в Windows. Такой файл hosts дистро WSL будет перезаписываться из файла hosts Windows при каждом новом запуске.

resolv.conf, располагающийся в /etc/resolv.conf, это файл, который позволяет вам вручную настраивать где ваше устройство будет искать доменные имена для их разрешения, которые не расположены в файле hosts или в локальном кэше DNS:

[automount]
generateHosts = true
generateResolvConf = true
		

Значением по умолчанию является true.

Как и ваш файл hosts, resolv.conf автоматически вырабатывается для вашего дистро из WSL из ваших сетевых настроек Windows.

Сама сетевая среда WSL управляется Сетевой службой хоста (Host Networking Service), службой Windows, причём в неком виртуальном адаптере Ethernet, подобно прочим сетевым адаптерам Hyper-V.

Значение IP адреса сервера имён будет тем же самым, что и IP адрес самого виртуального сетевого адаптера. Например, сопоставьте значение IP адреса в /etc/resolv.conf (Рисунок 5-15). с IPv4 адресом самого адаптера (Рисунок 5-16).

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

Традиционно ваш экземпляр WSL наследует название устройства своего устройства Windows. WSL переписывает /etc/hostname в вашем дистро именем хоста вашего Windows при “запуске” , как переписывается и /etc/host.

В Windows 10 сборки 20180 и старше, также имеется возможность настройки этого поведения и установки для вашего экземпляра WSL имени хоста вручную:

[network]
generateHosts = true
generateResolvConf = true
hostname = Biswa96
		

Значением по умолчанию является наследование имени устройства из вашего устройства Windows Тем не менее, для определённых современных сетевых функций персонализация имени хоста вашего экземпляра WSL может оказаться полезной. Изменяя имя хоста вашего дистроWSL (или множества дистро), вы можете получать обособленные имена хостов для каждого из дистро в Windows.

Возможность взаимодействия WSL включает в свой состав способность запуска программ Windows из Linux (Рисунок 5-17), программ Linux из Windows и совместного использования переменных среды. Такие настройки возможности взаимодействия из wsl.conf позволяют вам включать и отключать способность запуска программ Windows из Linux. Начиная со сборки 20190 Windows также можно запускать из WSL прикладные приложения Windows по псевдонимам исполнения, так как это имеет место в прикладных приложения UWP. Обратитесь к Главе 9, Максимизируем возможность взаимодействия Windows за дополнительными советами относительно того как получать максимум из этой уникальной функциональной возможности WSL.

[interop]
enabled = true
		

Значением по умолчанию является true.

Вы можете пожелать отключать это для ограничения своего дистро WSL, кога у вас имеются установленными в Windows git и python, это порой может вызывать проблемы, когда у вас также установлены git и python в WSL.

Существует возможность включения и отключения этой функциональной возможности в единственном сеансе без изменения wsl.conf. Для временного отключения программ Windows в Linux выполните

> echo 0 > /proc/sys/fs/binfmt_misc/WSLInterop
		

Для повторного включения Windows в Linux исполните

> echo 1 > /proc/sys/fs/binfmt_misc/WSLInterop
		

Обратите внимание что эта настройка не сохраняется между сеансами. Для непрерывного отключения возможности взаимодействия WSL вам потребуется внести изменения в ваш файл wsl.conf.

Другой функциональной возможностью взаимодействия WSL является добавление в конец переменной пути вашего дистро WSL переменной пути Windows. Это добавляет все каталоги из переменной пути вашего Windows в имеющиеся переменные пути вашего дистро Linux, превращая все исполняемые файлы из обеих платформ доступными из WSL (Рисунок 5-18).

[interop]
enabled = true
appendWindowsPath = true
		

Значением по умолчанию является true. Хотя вы и можете отключать это, оставляйте возможность взаимодействия включённой с тем, чтобы вы могли ограничивать доступные для WSL программы Windows теми, которые обнаруживаются в PATH вашим дистро WSL.

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

Переменные среды Windows можно отыскать в “Edit the system environment variables” (Изменение системных переменных среды) из меню Windows Start (Пуск) (Рисунок 5-19).

Переменные среды Linux можно просмотреть при помощи команды printenv (Рисунок 5-20).

Почему совместное использование переменных среды между Windows и WSL полезно? Та же самая причина, по которой в целом полезна WSL, вы получает всё самое лучшее от Linux и Windows. Вы можете в конце концов прийти к обладанию проектом, в котором вы желаете работать и с Linux, и с Windows. Допустим, мы хотели бы совместно применять путь, установим PATHTOPROJECT из WSL в Windows.

Мы определяем PATHTOPROJECT в WSL:

> export PATHTOPROJECT=~/project
		

Затем добавляем PATHTOPROJECT в WSLENV:

> export WSLENV=PATHTOPROJECT/p
		

Теперь переключаемся в Windows и считываем это обратно:

> cmd.exe
> set PATHTOPROJECT
		

Windows будет обладать PATHTOPROJECT в качестве переменной среды (Рисунок 5-21).

Что если у вас уже имеется нечто, определённое в WSLENV и вы не желаете переписывать это, а вместо того просто хотите добавить это в конец? В WSL вы бы экспортировали такую переменную, добавляя один из сетевых флагов, упомянутых ранее, по мере необходимости, а затем добавляя в конец имеющуюся $WSLENV следующим образом:

> export WSLENV=PROJECTLIST/l:$WSLENV
		

Когда WSL “запускается”, вы будете работать в качестве пользователя по умолчанию.

Вот как можно настроить пользователя по умолчанию:

[user]
default = root
		

Значением по умолчанию является root, однако большинство дистро, включая Ubuntu, создадут нового пользователя с полномочиями sudo при установке из Microsoft Store и установят его пользователем по умолчанию.

Говоря о запуске, начиная со сборки 21286 в Windows 10 в WSL была добавлена возможность запуска команд начального запуска:

[boot]
command = <string>
		

Например:

[boot]
command = apt update &apmp;&apmp; apt upgrade -y
		

Это совершенно новая функциональная возможность, что касается момента написания книги, раскрывает новый потенциал для запуска задач во время “запуска” WSL. Она способна заменить неуклюжие сценарии, первоначально хранившиеся в ~/.bashrc или /etc/profile. Эти команды исполняются от имени root, допуская изменения верхнего уровня в вашей среде. Эти команды запускаются только при запуске WSL вручную или из Терминала Windows, поэтому они не заменяют возможность применения службы Windows для запуска задач WSL в фоновом режиме или автоматизации задач в WSL при помощи Планировщика задач Windows, но она дополняет их.