Choosing the right default editor in Linux keeps command-line work predictable when programs open a text editor on your behalf. Tools such as crontab, git commit, and visudo often hand control to an editor without asking each time, so setting a preferred editor avoids context switches and editing mistakes.
Command-line programs usually look at the $VISUAL and $EDITOR environment variables to decide which editor to launch. Many tools prefer $VISUAL first and fall back to $EDITOR, while shells such as Bash and Zsh pass those exported values to child processes started from the terminal. On Debian and Ubuntu, the generic /usr/bin/editor command is managed separately through update-alternatives, so changing that link does not replace shell-based editor settings by itself.
The safest workflow is to confirm the editor command first, test the change in the current shell, and then make it persistent in the startup file your shell actually reads. Use a quoted command string when the editor needs arguments, such as code --wait, and replace existing $VISUAL or $EDITOR assignments instead of stacking duplicates in multiple startup files.
Steps to change the default editor in Linux:
- Inspect the current editor variables before making any change.
$ printf 'VISUAL=%s\nEDITOR=%s\n' "${VISUAL-}" "${EDITOR-}" VISUAL= EDITOR=
An empty value means the variable is not currently set in the shell environment.
- Resolve the command for the editor you want to use.
$ command -v nano /usr/bin/nano
Replace nano with vim, nvim, emacs, or another editor installed on the system. For GUI editors, export a waiting command such as code --wait or subl -w so the calling program waits for the editor to close.
- Set the editor for the current shell session.
$ export VISUAL=/usr/bin/nano $ export EDITOR=/usr/bin/nano
Many command-line tools check $VISUAL first and fall back to $EDITOR when $VISUAL is unset.
- Verify that the current shell now sees the new values.
$ printf 'VISUAL=%s\nEDITOR=%s\n' "$VISUAL" "$EDITOR" VISUAL=/usr/bin/nano EDITOR=/usr/bin/nano
- If Git is installed, confirm that an application resolves the same editor choice.
$ git var GIT_EDITOR /usr/bin/nano
Git checks $GIT_EDITOR first, then core.editor, then $VISUAL, and then $EDITOR, so this command is a quick way to confirm the effective editor that Git would launch.
- Check which shell will need a persistent change.
$ printf '%s\n' "$SHELL" /bin/bash
Interactive Bash shells usually read ~/.bashrc, while interactive Zsh shells use ~/.zshrc. Add the same exports to ~/.profile when login shells should inherit the editor choice before the interactive shell rc file runs.
- Open the startup file for that shell and add or update the editor exports.
$ nano ~/.bashrc
export VISUAL=/usr/bin/nano export EDITOR=/usr/bin/nano
If the file already defines $VISUAL or $EDITOR, replace the old values instead of leaving multiple conflicting assignments in the same startup path.
For Zsh, edit ~/.zshrc instead. If you use a command with arguments such as code --wait, quote the full value in the file.
- Start a new shell and confirm that the values now persist automatically.
$ bash -ic 'printf "VISUAL=%s\nEDITOR=%s\n" "$VISUAL" "$EDITOR"' 2>/dev/null VISUAL=/usr/bin/nano EDITOR=/usr/bin/nano
Use zsh -ic ... instead when you stored the change in ~/.zshrc.
- On Debian or Ubuntu, optionally inspect the separate generic editor alternative.
$ update-alternatives --display editor editor - auto mode link best version is /bin/nano link currently points to /bin/nano link editor is /usr/bin/editor slave editor.1.gz is /usr/share/man/man1/editor.1.gz /bin/nano - priority 40 slave editor.1.gz: /usr/share/man/man1/nano.1.gz
Use sudo update-alternatives --config editor if you also need programs that call the generic editor command to change. That setting does not replace $VISUAL or $EDITOR; it only changes the /usr/bin/editor link group.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
