Problem description

If I increase the width of a Terminal version 2.3 (309) window, and then use less (or some command invoking less, like man) in that window, I often get garbled output, since the lines wrap at 80 characters even though the window is wider and less tries to format the text for that wider window.

  • This is the same for native OS X 10.8.5 less and the less 458 MacPorts installs. It is even the same if less is invoked remotely on some other host from an interactive ssh session.
  • resize does print the correct size, and eval `resize` does not help. Which is not surprising, since less does seem to have the right idea as to how wide the window is, it's just confused by the fact that lines break too early.
  • Normal command line output (outside less) will span the whole window.


This appears to be a bug in how cup (cursor positioning mode) is handled by the application. The following code can be used to reproduce the problem:

tput smcup; echo {0..200}; sleep 2; tput rmcup

The whole issue appears to be related to the fact that I have configured Terminal to set the emulation mode and TERM environment variable to xterm-color instead of the default xterm-256color. I did so since the latter is not available on several hosts that I ssh to, causing applications on those hosts to complain about missing functionality.


One way to avoid this issue seems to be executing the command

tput -T xterm-256color smcup; tput -T xterm-256color rmcup

after every change of terminal size. But that's quite annoying. Another workaround would be changing the terminal emulation back to xterm-256color and copying the terminfo data to those remote hosts which do not support that value out of the box. Which can be annoying, too, if you only want to have a quick look at some remote host.

Core question

On the whole it seems to me as if emulation of the xterm-color setting is not supported as well as one would hope. Is this a bug in Terminal.app, or did I misunderstand something about how this whole mess is supposed to work?

Does someone have a more appropriate solution how to handle these incompatibilities?

Technical details

For further information, here is the output of infocmp xterm-color xterm-256color, slightly trunkated by removing some key definitions:

comparing xterm-color to xterm-256color.
    comparing booleans.
    bce: F:T.
    ccc: F:T.
    mc5i: F:T.
    npc: F:T.
    comparing numbers.
    colors: 8, 256.
    ncv: NULL, NULL.
    pairs: 64, 32767.
    comparing strings.
    blink: NULL, '\E[5m'.
    cbt: NULL, '\E[Z'.
    civis: NULL, '\E[?25l'.
    cnorm: NULL, '\E[?12l\E[?25h'.
    cvvis: NULL, '\E[?12;25h'.
    ech: NULL, '\E[%p1%dX'.
    el1: NULL, '\E[1K'.
    enacs: '\E)0', NULL.
    flash: NULL, '\E[?5h$<100/>\E[?5l'.
    hpa: NULL, '\E[%i%p1%dG'.
    ich: NULL, '\E[%p1%d@'.
    indn: NULL, '\E[%p1%dS'.
    initc: NULL, '\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\'.
    invis: NULL, '\E[8m'.
    is2: '\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8', '\E[!p\E[?3;4l\E[4l\E>'.
    kDC: NULL, '\E[3;2~'.
    kEND: NULL, '\E[1;2F'.
    kHOM: NULL, '\E[1;2H'.
[ ⋮ ]
    kri: NULL, '\E[1;2A'.
    kslt: '\E[4~', NULL.
    mc0: NULL, '\E[i'.
    mc4: NULL, '\E[4i'.
    mc5: NULL, '\E[5i'.
    op: '\E[m', '\E[39;49m'.
    rin: NULL, '\E[%p1%dT'.
    rmacs: '^O', '\E(B'.
    rmam: NULL, '\E[?7l'.
    rmcup: '\E[2J\E[?47l\E8', '\E[?1049l'.
    rmm: NULL, '\E[?1034l'.
    rmso: '\E[m', '\E[27m'.
    rmul: '\E[m', '\E[24m'.
    rs1: NULL, '\Ec'.
    rs2: '\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8', '\E[!p\E[?3;4l\E[4l\E>'.
    setab: '\E[4%p1%dm', '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m'.
    setaf: '\E[3%p1%dm', '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m'.
    sgr: NULL, '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m'.
    sgr0: '\E[m', '\E(B\E[m'.
    smacs: '^N', '\E(0'.
    smam: NULL, '\E[?7h'.
    smcup: '\E7\E[?47h', '\E[?1049h'.
    smm: NULL, '\E[?1034h'.
    vpa: NULL, '\E[%i%p1%dd'.
  • Possible duplicate of What terminal is the Mountain Lion Terminal app emulating?
    – mmmmmm
    Dec 6, 2015 at 11:31
  • @mark: There are a lot of similarities, but they are different questions. This asks “how do I fix this 80-column wrapping issue” whereas “What terminal is the Mountain Lion Terminal app emulating?” asks about terminfo and terminal emulation in general, and only incidentally mentions an 80-column wrapping issue as a motivation for asking the question.
    – Chris Page
    Dec 7, 2015 at 8:39

1 Answer 1


xterm-color represents an older branch from Xterm that does not accurately reflect a number of important features supported by Terminal (and Xterm).

In older versions of Terminal, the default value of the TERM environment variable was xterm-color because it was more compatible with Terminal, but that has not been the case for several OS X releases. The current default is xterm-256color.

If you're connecting to a remote host that doesn't include xterm-256color, first try xterm-16color and then xterm and see if those are available. They are essentially the same except that they declare different numbers of supported colors. They represent the current Xterm, and are much more compatible with Terminal than xterm-color.

See my answer https://apple.stackexchange.com/a/79016/6883 for more details.

  • If the answer is the same as another question then the question is a duplicate and should be closed as such
    – mmmmmm
    Dec 6, 2015 at 11:32
  • 2
    The question is different, and the answers only partially overlap. That's why I merely referred to it instead of flagging this as a duplicate.
    – Chris Page
    Dec 6, 2015 at 11:44

You must log in to answer this question.

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