Editing .bashrc in WSL safely

Question

How do I edit the .bashrc file in Windows Subsystem for Linux safely?

This article warns to never edit files stored in the WSL AppData folder using Windows tools.

But then how do you edit files like .bashrc in a safe manner?

Answer 1

Use the built-in nano editor as:

nano ~/.bashrc

The most important shortcuts for nano are Ctrl+O to save the file and Ctrl+X to close the editor.

A simple guide for using nano can be found in the Gentoo Linux Wiki.

Answer 2

I think Visual Studio Code works fine. Just install the Remote - WSL extension.

To use it just open cmd and type bash. In bash type cd, then use code .bashrc.

Voila! VS Code opens in WSL and you can edit the files you want.

Answer 3

Sorry to add yet another answer here, but the question itself (along with all the other answers here) needs context that is missing for anyone else coming along and trying to understand it.

The Microsoft warning that is linked in the original question refers to editing WSL1 files through Windows using Windows' %AppData% path. In WSL version 1 (but not version 2), WSL stored the entire filesystem for the Linux instance in a Windows folder. Those files, while visible to the user in Windows, should not be edited in Windows. As the warning says, corruption of the WSL instance is likely if unheeded.

This is not a problem on WSL version 2. Since the filesystem is stored in a virtual disk, it's just not possible to edit the filesystem directly anyway.

On either version, however, it is safe to edit the files (including ~/.bashrc) inside the WSL instance. There, it's just a normal file in the WSL filesystem. The two answers from 2019 (BeastOfCaerbannog's and WinEunuuchs2Unix's) utilize this approach. Nothing wrong with that - they are both correct answers. Although I'd say that installing a Windows X Server and gedit just to edit a WSL file is probably overkill. Just about any other editor could have been cited as well (does someone want to throw in an Emacs answer for completeness? ;-)).

The 2020 answer from Brixton Mavu, which mentions using VSCode, is also a spin on the same idea. Even though it uses a Windows tool, VSCode launches a server inside the WSL instance with which it communicates to allow editing, browsing, and even debugging of the WSL instance.

Then there's @Jon's recent answer (which bumped this question, and is why I saw it). This is (mostly) the correct answer for how to safely edit WSL files from inside Windows, rather than from inside the WSL instance. It's actually already mentioned, though, in the Microsoft blog entry that was linked in the original question.

I say "mostly", because you should, in general, avoid using Windows tools to edit Linux files, since many Windows editors default to using DOS/Windows line-endings, which will cause ~/.bashrc to fail as well. Some tools are smart enough to recognize that the existing file is a Linux file, some tools aren't, but most tools will default to CRLF (DOS/Windows) in absence of any other format.

If the WSL instance won't start due to an error in the ~/.bashrc, then you could use @Jon's suggestion of \\wsl$\ to edit it, but there are also (IMHO) other, safer alternatives.

To edit the ~/.bashrc when that file is preventing you from launching, run:

wsl -e bash --norc -c "vi ~/.bashrc"

or

wsl ~ -e bash --norc
vi .bashrc

This will launch bash without sourcing the existing ~/.bashrc.

Other alternatives include launching the session as root:

wsl -u root

And then make any needed edits.

WSL, in general, has some amazing recovery mechanisms through the use of the wsl command's arguments to starting the instance.

Answer 4

Open Windows File Explorer and type \\WSL$ in the address bar. This will open a pseudo-share that WSL provides for each running WSL instance where it is safe to edit the files.

Note that the instance does need to be started and running for this to work.

Answer 5

If you prefer a GUI editor then install VcXsrv as detailed here:

• What's the easiest way to run GUI apps on Windows Subsystem for Linux as of 2018?

Then use gedit ~/.bashrc