I am not sure what to search for. "Terminal lines overlap" mostly brings up posts where that is the desired behavior.

Let me demonstrate what I am experiencing over SSH to Raspberry Pi running dietpi. jq -h is just an example.

dietpi@tv22-rpi1:~$ jq -h
jq - commandline JSON processor [version 1.5-1-a5b5cbe]
Usage: jq [options] <jq filter> [file...]
jq - commandline JSON processor [version 1.5-1-a5b5cbe]
Usage: jq [options] <jq filter> [file...]inputs, applying the
        given filter to its JSON text inputs and producing the
        jq is a tool for processing JSON inputs, applying the
        given filter to its JSON text inputs and producing the,
        filter's results as JSON on standard output.(except for
        The simplest filter is ., which is the identity filter,
        copying jq's input to its output unmodified (except forq")
        For more advanced filters see the jq(1) manpage ("man jq")
        and/or https://stedolan.github.io/jq
         -c             compact instead of pretty-printed output;
jq - comSome of the options include:sion 1.5-1-a5b5cbe]value;
Usage: j -coptions] <jq compact instead of pretty-printed output;put;
         -n             use `null` as the single input value; output;filter to it;
         -eis a tool forset the exit status code based on the output;filter to it;
         -sen filter to read (slurp) all inputs into an array; apply filter to it;
         -rter's resultsoutput raw strings, not JSON texts;
         -R simplest filread raw strings, not JSON texts;ilter,
         -Cying jq's inpcolorize JSON;n't colorize JSON);pt for
         -Mmatting).tabsmonochrome (don't colorize JSON);
         -Stabreuse tabssort keys of objects on output; ("man jq")
         --tab ause tabs for indentation;o value <v>; <v>;
         --arg a v a v fset variable $a to value <v>; <v>;y of JSON texts read from <f>;
         --argjson a v fset variable $a to JSON value <v>;y of JSON texts read from <f>;
dietpi@t --slurpfile a ffor moreset variable $a to an array of JSON texts read from <f>;
dietpi@tSee the manpage for more options.

Old lines don't get cleared or moved up as they should. Instead, new lines just interleave with the old line creating an unreadable "soup".

I wonder if tmux on dietpi is to blame. I did a quick check and couldn't reproduce the behavior without tmux yet.

dietpi@tv22-rpi1:~$ tmux -V
tmux 2.8

Many other posts revolve around these settings so I include them. They don't look problematic to me.

dietpi@tv22-rpi1:~$ shopt | grep checkwinsize
checkwinsize    on
dietpi@tv22-rpi1:~$ echo $PS1

Clarifying TERM variable, as suggested in the comments.

  1. Outermost TERM=xterm-256color (Linux laptop GNOME Terminal 3.18.3; note putty on Windows behaves similarly)
  2. TERM=screen in local tmux
  3. TERM=screen after connecting over ssh
  4. TERM=screen inside tmux over ssh
  • Many such Q&As in fact involve the TERM environment variables, in particular the one seen by the tmux process itself and the one seen by programs using the tmux-provided terminal. You need to show those, as well as tell potential answerers the type of the rendered-upon (outer) terminal.
    – JdeBP
    Commented Oct 30, 2020 at 8:22
  • Thank you for the feedback @JdeBP. I added information on TERM. Commented Oct 30, 2020 at 8:45

1 Answer 1


tmux is (re-)drawing the display on its rendered-upon terminal in a way that that terminal does not understand. tmux is emitting terminal control sequences, in order to redraw its display after its (rendered) terminal displays scroll up, that do not match the actual terminal that is in use. This is because you've lied to tmux about the type of that rendered-upon terminal.

TERM=xterm-256color (Linux laptop GNOME Terminal 3.18.3 […] putty […]

This is wrong.

  • The correct terminal type for GNOME Terminal, and other terminal emulators that use the VTE widget library (including GNOME Terminator), is vte or vte-256color.
  • The correct terminal type for PuTTY, and programs based upon it such as KiTTY and (the misleadingly-named) MobaXTerm, is likewise putty, putty-256color, or putty-sco.
  • The correct terminal type for Kovid Goyal's kitty, not to be confused with the PuTTY derivative KiTTY, is kitty or kitty-direct. (kitty itself provides a terminfo record by a different name, the very misleading "xterm-kitty" that does not follow the long-established terminfo naming conventions. kitty and kitty-direct are the names of the vanilla records in the Dickey terminfo database, following those naming conventions.)
  • The correct terminal type for MacOS iTerm is iTerm.App and for George Nachman's iTerm2 is iTerm2.App.
  • The correct terminal type for MacOS Terminal is nsterm or nsterm-256color, "ns" indicating its heritage as NeXTSTEP Terminal.
  • The correct terminal type for Terminator (the Java one, not the GNOME one) is terminator.
  • The correct terminal types for the terminal emulators that are built into the Linux, OpenBSD, NetBSD, and FreeBSD kernels themselves, are linux, linux-16color, pccon, pcvt25, and teken. (My nosh toolset provides an additional teken-256colour termcap record, as it comes with a terminal emulator that intentionally behaves as the FreeBSD kernel's one but adds Indexed and Direct colour capabilities.)

These are what the TERM environment variable inherited by tmux should be in order to correctly describe the rendered-upon terminal to it.

The correct terminal types for the rendered (interior) terminals, in the TERM environment variables inherited by processes using those terminals for I/O, are tmux, tmux-256color, and tmux-direct, although one can get away with screen.

It is a widespread incorrect assumption that terminal emulators are all compatible with XTerm, and that the xterm and xterm-256color entries in the terminfo database correctly describe them. This erroneous thinking is called out in Thomas Dickey's XTerm FAQ and it is worth observing that the xterm and xterm-256color entries do not even describe all versions of XTerm itself, let alone other terminal emulators.

The only time that you should set the TERM environment variable to xterm, xterm-256color, or indeed "xterm-anything", are when the terminal emulator actually is the XTerm program.

Telling a full-screen TUI program, like tmux, the wrong terminal type can have all sorts of effects: from parts of the screen not being refreshed, through things being drawn in the wrong places and background colours going awry, to box drawing coming out as letter characters.

Further reading

You must log in to answer this question.

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