Ubuntu – Any way to use Visual Studio Code editor instead of nano/vim/emacs to edit files

bashrccommand linehidden-filesvisual-studio-codewindows-subsystem-for-linux

I'm having an issue where I can only edit .bashrc or .zshrc files with the nano command.

When I input code .bashrc it just opens up an empty .bashrc file. With nano it works within the shell and it displays the file properly through the command nano .bashrc, but I hate editing files through nano and I'd rather do that on Visual Studio, any idea how to fix this so that Visual Studio Code could read . files?

Hell, even when editing normal files (i.e. files that aren't hidden with .) with code, while it works, git status doesn't register the change, but it does register it if the file was edited with nano. Super frustrating as someone who dislikes editing through shell and it's making me consider going back to Git Bash.. even though I much prefer working with zsh on WSL.

Best Answer

You can start Visual Studio Code in Windows, then connect to your WSL system with it and open whatever files you want to edit. This works almost the same way as remote editing via SSH of files on another machine (which can be done both from Windows and GNU/Linux clients and is itself separate from WSL). The only difference from a user interface perspective is which menu item you select to connect. Furthermore, depending on what's going wrong, the procedure of setting that up may also make the code command work the way you want.

I recommend installing the Remote Development Extension Pack in Visual Studio Code, if you haven't already. But really you only need the Remote - WSL extension for this. (The Remote Development Extension Pack installs that extension as well as others for remote editing on non-WSL systems via SSH.) You can install it from within Visual Studio Code; those links are mainly for reference. Once it's installed, you should be able to run code from within the WSL system and open editor windows on the host system that connect to the WSL system, though I've always found this awkward at best.

Note that installing the Visual Studio Code itself, i.e. the client program, inside a WSL system is not supported and is not particularly likely to work even on a Windows system with an X server like VcXsrv on which other graphical Ubuntu programs usually work. (I've tried.) If you installed Visual Studio Code packages inside the WSL system, I suggest removing them, and doing so may even get your code command to start working properly.

Anyway, you can connect to the WSL system within the editor, which is what I recommend. With the necessary extension(s) installed, you should see a > < button at the lower-left corner of every Visual Studio Code window, with the mouseover text Open a remote window.

"Open a remote window" button on the lower-left corner of Visual Studio Code - in the default color scheme, this button is white on green

When you click that, a menu appears at the top of the window with various actions to start remote editing. You'll probably want to select Remote-WSL: New Window most of the time.

Menu showing selections relating to remote editing

In the new window, on the lower-left corner, it will show WSL: Ubuntu.

The remote editing button the lower-left corner of the screen is now wider and says WSL: Ubuntu in it, indicating that most actions in this window apply to the remote editing session

If you go to open a file in the remote editing window, then instead of showing you a native file-open dialog, you get menus in Visual Studio Code through which you can navigate to any location in the system you're connected to. In this case, that's your WSL system. Press Ctrl+O to open a single file. You can also open folders (in the usual way) in this mode, which you may often want to do, especially if you want Git integration in the editor. But for editing a .bashrc file in place, you probably wouldn't want to do that.

The menu that comes up with you press Ctrl+O to select an individual file on the remote system to open in the editor

In the menu that comes up when you press Ctrl+O, it should say /home/you/, but with your username (on the WSL system) in place of you. For example, it says /home/ek/ for me. If so, you're in the right place. You may see .bashrc listed if you scroll down, but you can simply type in .bashrc, so it says /home/you/.bashrc. Then press Enter or click OK.

The open-file menu, brought up by Ctrl+O, showing the user's home directory, in which the filename .bashrc has been entered, causing that file to be selected in the menu and ready to open

You can open other files the same way; this procedure is not specific to .bashrc.

Having opened the file, you can edit it and save your changes. The modifications are made within the WSL system.

editing the file on the WSL system

Although you need to open a folder to get Git-integration in the editor--just as typically you do when editing locally--you can use Git and perform other actions from a terminal. When you open a terminal in a remote editing window, the terminal gives you a shell on the system you're connected to (which in this case is your WSL system). You may already have such a shell; if not, press Ctrl+`.

a remote terminal at the bottom of the remote Visual Studio Code window

The way this works is that Visual Studio Code is actually running a separate server program on the remote system (in this case, the WSL system). It stores its files in ~/.vscode-server in your home directory on that system. When connecting to actual separate machines (or virtual machines), that directory is still used, even if those systems also happen to have a normal (i.e., client) Visual Studio Code installation. Running the code command in a shell running on the remote machine to open files through the remote connection is only supported for WSL (not other remotes), and even with WSL it can be easily done without.

Finally, note that you shouldn't expect your remote editing windows to have a different color scheme than your regular editing windows (like the blue you see in mine), unless you've set that up. The absence of a different color scheme doesn't mean anything is wrong.

Related Question