I generally set both VISUAL and EDITOR environment variables to the same thing, but what's the difference? Why would I set them differently? When developing apps, why should I choose to look at VISUAL before EDITOR or vice versa?

6 Answers 6


The EDITOR editor should be able to work without use of "advanced" terminal functionality (like old ed or ex mode of vi). It was used on teletype terminals.

A VISUAL editor could be a full screen editor as vi or emacs.

E.g. if you invoke an editor through bash (using C-x C-e), bash will try first VISUAL editor and then, if VISUAL fails (because terminal does not support a full-screen editor), it tries EDITOR.

Nowadays, you can leave EDITOR unset or set it to vi -e.

  • 17
    Most applications treat $VISUAL as a shell snippet that they append the (shell-quoted) file name to, but some treat it as the name of an executable which they may or may not search in $PATH. So it's best to set VISUAL (and EDITOR) to the full path to an executable (which could be a wrapper script if you want e.g. options). Commented Dec 15, 2010 at 18:27
  • 6
    In modern times, ed and similar are not very popular so I believe it is OK to just ignore VISUAL and use EDITOR. Commented Mar 30, 2014 at 17:35
  • 21
    Thanks for the tip about C-x C-e in bash. Very handy.
    – mndrix
    Commented Mar 25, 2015 at 19:22
  • 6
    @PavelŠimerda, just setting EDITOR is not enough e.g. for git on Ubuntu 12.04. Without VISUAL being set git ignores EDITOR and just uses nano (the compiled in default, I guess). Commented Apr 25, 2015 at 10:24
  • 8
    @PavelŠimerda It doesn't make sense, but it's the convention. EDITOR used to be for instruction-based editors like ed. When editors with GUIs came about--and by GUI, I mean CLI GUI (vim, emacs, etc.--think ncurses), not desktop environment GUI--the editing process changed dramatically, so the need for another variable arose. In this context, CLI GUI and desktop environment GUI editors are more or less the same, so you can set VISUAL to either; however, EDITOR is meant for a fundamentally different workflow. Of course, this is all historical. Nobody uses ed these days.
    – Zenexer
    Commented Sep 17, 2016 at 22:34

The accepted answer is probably a good, short treatment, but this will be an attempt to go deeper on when the distinction between VISUAL and EDITOR might still matter (building on Adam Katz's answer).

The POSIX spec still distinguishes between visual mode editors and line editors. This really mattered back in the days when cursor positioning over serial connections was hard (especially because of the speed of the serial connection). The Wikipedia article for vi gives some useful background on the distinction between vi (a visual mode editor) and ex (a line editor). If you dig deep enough down the research, you'll find the "RATIONALE" section of the "ex" spec, which gives a reason for the distinction still being in the spec:

It is recognized that portions of vi would be difficult, if not impossible, to implement satisfactorily on a block-mode terminal, or a terminal without any form of cursor addressing, thus it is not a mandatory requirement that such features should work on all terminals. It is the intention, however, that a vi implementation should provide the full set of capabilities on all terminals capable of supporting them.

I haven't needed this since giving up my 300 baud modem, but I can imagine that people who use slow serial lines to connect to embedded systems (and/or over really dicey connections) might still appreciate being able to have a preferred line mode editor distinct from a "visual" editor like vi. VT100-style terminal codes over a lossy, laggy, narrow connection might be "bloat" in limited applications.

For the rest of us, it seems the "correct" answer seems to be "set them both to be your preferred editor". It might be ok to co-opt this distinction for graphical editor (e.g. Sublime, gvim or emacs) vs a terminal editor (e.g. vi/vim or emacs with -nw option), but there's likely a mountain of legacy reasons why that probably won't work as hoped.


$VISUAL is a more capable and interactive preference over $EDITOR. If undefined, anything seeking $VISUAL should then try $EDITOR next.

Some people have adopted a modern convention denoting $VISUAL as graphical and $EDITOR as an interactive terminal. Historically, $VISUAL (like vi) referred to an interactive terminal display while $EDITOR (like ed) was a line editor incapable of handling (text) cursor movement. See robla's answer for more historical notes.

At the moment, I have stuff like this in my ~/.bashrc and ~/.zshrc:

# Prefer vim or else fail over to vi
EDITOR="$(command -v vim 2>/dev/null || command -v vi)"

# we have gvim, not in an SSH term, and the X11 display number is under 10
if command -v gvim >/dev/null 2>&1 \
&& [ "$SSH_TTY$DISPLAY" = "${DISPLAY#*:[1-9][0-9]}" ]; then
  export VISUAL="$(command -v gvim) -f"

gvim without -f won't work with programs that expect to act on your edits. This definitely includes sudoeditor (sudo -e).

This may break if you have whitespace in the path to vim. If that's a problem, either install it properly or else consider symlinks like /usr/local/bin/gvim

  • 5
    Whether to use $VISUAL depends whether you have a terminal capable of cursor positioning, not whether you have a window system available. Commented Mar 13, 2018 at 23:01
  • Ah, great! Can you provide a definitive reference link for that? I think my code is still safe since I'm also checking for $DISPLAY, but that's good to know.
    – Adam Katz
    Commented Mar 14, 2018 at 14:24
  • Never mind, it appears such a references exists in robla's answer, which even mentions my answer.
    – Adam Katz
    Commented Mar 14, 2018 at 14:43
  • 2
    Back when I wrote my 2016 answer, I didn't have enough reputation to write a comment (which I would have done). Thanks for the writing prompt, @AdamKatz !
    – robla
    Commented Apr 1, 2020 at 2:36

Some tools only accept EDITOR, for example the shell builtin fc:

-e ENAME  select which editor to use.  Default is FCEDIT, then EDITOR, then vi

Since there don't seem to be any environments where vi or similar would fail, I've taken to setting VISUAL to something that needs an X DISPLAY, and EDITOR to ex.

Mostly, that just seems to cause me problems when some program doesn't use VISUAL.

  • just be aware that this won't work with ssh. VISUAL means "tui" not X11, and many programs, like git, will assume the editor is being rendered through the terminal. Commented Mar 18 at 23:30

In general, you shouldn't have to worry about EDITOR or VISUAL, because the default for EDITOR is "vi" and for VISUAL it is EDITOR.

  • Only set EDITOR if you want stone cold ex or ed
  • Set VISUAL only to override EDITOR and if a graphical environment exists and emacs, vim, nano etc. are installed

In short, if you really want to set these variables, you have to have a good reason, because their concept is default-proof. Don't bother and you always get vi. That's tough for younglings but this way there are no surprises ever. For example, on remote systems where you don't have your fancy tools and initialization files (.emacs .vimrc) and therefore would suffer, you are not really suffering because you get the reliable vi. Back on your own system you'll get vi too unless you set VISUAL.

BTW, both should be set in $HOME/.bash_profile, so only for login shells and only overridden in $HOME/.bashrc if (and only if) there are good reasons. The latter file is only executed for interactive shells, and each interactive shell can only be run under a login shell whose variables interactive shells inherit.

If you want to override them in $HOME/.bashrc then you most likely want to query the TERM variable ("dumb") and make sure DISPLAY is not empty (i.e. there is a graphical environment). This is one more reason not to worry about both variables and to leave it on your system with the defaults. Just learn to edit commit messages with vi and start your editor or IDE directly from the command line and you'll be fine.

But to really understand what's been said here and why the recommendation not to care about these variables was made, look at how Git uses these variables:


All you need to know.

  • This is only true in systems that define these variables for you. In my Arch Linux install, (which I use, btw), neither are set out of the box. It then is left up to each program to decide what to do - and they don't always behave "correctly." Commented Mar 18 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .