From: Yuri Kanivetsky <firstname.lastname@example.org>
To: Rich Felker <email@example.com>
Subject: Re: [musl] What determines the TERM variable value?
Date: Sat, 12 Feb 2022 11:34:52 +0200 [thread overview]
Message-ID: <CAMhVC3bAw3EP4ExDdkj=UNwZ-h+0bn7aWidH2o0-W8Lxz1Gmng@mail.gmail.com> (raw)
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 <firstname.lastname@example.org> 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.
> > https://man.archlinux.org/man/community/tmux/tmux.1.en
> > 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.
next prev parent 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
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 \
* 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).