WSL: повседневная работа и грабли

Две файловые системы

После установки у вас есть два разных хранилища, и это главный источник путаницы.

Файловая система Linux живёт внутри WSL. Домашний каталог там /home/<имя>, он же ~. Это быстрый диск, права доступа настоящие.

Файлы Windows подключены в каталог /mnt. Диск C: виден как /mnt/c, диск D: как /mnt/d. Читать и писать можно, но у этого есть цена.

Держите проекты в Linux, а не в /mnt/c

Обращения к /mnt/c идут через прослойку между Linux и Windows. На одном файле разница незаметна. На проекте, где тысячи мелких файлов, она превращается в мучение: git status думает секунды, установка зависимостей тянется в разы дольше, сборка еле шевелится.

Правило простое. Рабочие файлы держите в ~, то есть внутри Linux:

cd ~
mkdir projects
cd projects
git clone https://github.com/example/repo.git

/mnt/c оставьте для обмена: забрать скачанный файл из папки «Загрузки», положить отчёт на рабочий стол.

Как добраться до этих файлов из Windows

Файлы внутри Linux не спрятаны. Откройте проводник и введите в адресной строке:

\\wsl$\Ubuntu\home\<имя>

Откроется домашний каталог, обычной папкой. Можно перетаскивать файлы мышкой, можно закрепить в «Быстром доступе».

Обратный путь тоже работает. Из терминала WSL:

cd /mnt/c/Users/<имя_windows>/Downloads

Редактор

Ставить редактор внутрь Linux не нужно. VS Code умеет работать так: интерфейс остаётся в Windows, а вся работа идёт внутри WSL.

Поставьте VS Code в Windows и расширение WSL к нему. Дальше из терминала WSL, находясь в каталоге проекта:

code .

Откроется окно редактора, а в левом нижнем углу появится метка с именем дистрибутива. Она означает, что встроенный терминал, отладчик и расширения работают на стороне Linux. Именно это и нужно.

Права доступа на дисках Windows

У файлов на /mnt/c прав в привычном смысле нет. Windows хранит доступ иначе, и WSL показывает всё подряд как 777, то есть доступное всем.

Отсюда неприятность: chmod +x script.sh на диске C по умолчанию не запоминается. После перезапуска флаг исполнения снова пропадает.

Это ещё одна причина держать проекты в ~. Там права настоящие и ведут себя как положено.

Переносы строк

Windows завершает строку двумя символами, Linux одним. Если открыть файл редактором Windows и сохранить, в конце строк появится лишний символ.

Для shell-скриптов это ломает всё: строка #!/bin/bash превращается в #!/bin/bash\r, и система такого интерпретатора не находит. Ошибка выглядит загадочно, вроде bad interpreter: No such file or directory.

Лечится настройкой git один раз:

git config --global core.autocrlf input

Так git будет хранить в репозитории переносы в Unix-формате.

Сколько памяти забирает WSL

WSL2 работает в виртуальной машине и по умолчанию готов занять заметную часть оперативной памяти. Если Windows начал подтормаживать, ограничьте аппетит.

Создайте в Windows файл C:\Users\<имя>\.wslconfig:

[wsl2]
memory=4GB
processors=2

Затем перезапустите подсистему из PowerShell:

wsl --shutdown

systemd

Многие инструкции в интернете предполагают systemd, то есть команды вида systemctl start docker. В WSL он включается отдельно.

Откройте файл /etc/wsl.conf внутри Linux и добавьте:

[boot]
systemd=true

Затем wsl --shutdown в PowerShell и запуск заново. После этого systemctl начнёт работать.

Что важно запомнить

• Проекты держите в ~, диски Windows в /mnt/c только для обмена файлами.
• Работа в /mnt/c тормозит, и заметно это именно на больших проектах.
• Из Windows файлы Linux видны по пути \\wsl$\Ubuntu\home\<имя>.
• code . открывает проект в VS Code, работающем внутри WSL.
• Права на /mnt/c ненастоящие, chmod там не запоминается.
• core.autocrlf input спасает скрипты от лишнего символа в конце строк.

Чек-лист

• Проект лежит в домашнем каталоге, а не на диске C.
• Домашний каталог Linux открывается из проводника Windows.
• code . запускает редактор с меткой WSL в углу.
• Понимаете, почему chmod +x на /mnt/c не срабатывает.