mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Yuri Kanivetsky <>
To: Rich Felker <>
Subject: Re: [musl] What determines the TERM variable value?
Date: Sat, 12 Feb 2022 11:34:52 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

So, a program is a terminal emulator if it translates escape sequences
in both directions? And if it, as a result, changes the TERM variable?

What seems strange to me is that docker changes the TERM variable:

$ echo $TERM

$ docker run --rm -it alpine
/ # echo $TERM

Does that qualify it as a terminal emulator?

On Fri, Feb 11, 2022 at 5:54 PM Rich Felker <> wrote:
> On Fri, Feb 11, 2022 at 03:30:32PM +0200, Yuri Kanivetsky wrote:
> > Hi,
> >
> > I was told recently that I can set TERM to any value inside a docker
> > container, which is, sort of, at odds with my understanding.
> >
> > And my understanding is as follows. When a program creates a
> > pseudoterminal (a pty master/slave pair), it sort of becomes a
> > terminal emulator. I guess, it can decide not to process any escape
> > sequences in which case the pair is probably not much different from
> > an ordinary pipe. And basically what sequences it decides to process
> > determines the TERM variable value.
> No, creating the pty pair does not make you a terminal emulator any
> more than a modem or null modem cable is a terminal emulator. The pty
> is just a data channel with kernel support for certain types of data
> translation/interpretation and very basic line buffering and editing
> (if enabled). This layer has nothing to do with terminal semantics.
> > I can separate such programs into 2 categories:
> >
> > * Terminal emulators (xterm, urxvt, ...). They receive input, process
> > escape sequences, and draw the result in a window. They can invent
> > their own language (escape sequences), but it's probably best to have
> > some terminal as a base.
> >
> > * The rest (docker, ssh, tmux, screen, ...). They receive input,
> > translate escape sequences to the language of the process up the chain
> > (by using the TERM variable and the terminfo database), and pass the
> > result to stdout (text, optionally with translated escape sequences).
> tmux and screen *are* terminal emulators who use *another terminal*
> (the one they're attached to) as a presentation layer for showing
> what's on the terminals (one for each window) they're emulating
> internally. They're not just data channel carriers.
> > So, generally you have a chain of processes connected via
> > pseudoterminals (a pty master/slave pairs). E.g. xterm <-> ssh <->
> > tmux <-> docker.
> >
> > Also, you can't set TERM to an arbitrary value. Each program that
> > creates a pseudoterminal supports a fixed set of values. E.g. the tmux
> > documentation says:
> >
> > > For tmux to work correctly, this must be set to screen, tmux or a derivative of them.
> >
> >
> >
> > Is my understanding correct?
> >
> > Also, I have a pretty vague understanding of what the TERM variable
> > affects. Can you give some examples? Or categorize things in some way?
> > Is it only about escape sequences?
> Pretty much, yes. The TERM environment variable simply tells the
> program you're invoking what dialect of terminal escapes to use
> (normally found by looking it up in the terminfo/termcap database) and
> what to expect as input when different special keys are pressed. It's
> informing the application of the contract you want it to honor with
> whatever is on the other side of the tty channel.
> Rich

  reply	other threads:[~2022-02-12  9:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 13:30 Yuri Kanivetsky
2022-02-11 15:54 ` Rich Felker
2022-02-12  9:34   ` Yuri Kanivetsky [this message]
2022-02-12 10:33     ` Markus Wichmann
2022-02-12 15:05       ` Rich Felker
2022-02-13  8:54         ` Yuri Kanivetsky
2022-02-13  9:57           ` Markus Wichmann
2022-02-17 20:37             ` [musl] RE: [EXTERNAL] " Andy Caldwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).