mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <>
Cc: Yuri Kanivetsky <>
Subject: Re: [musl] What determines the TERM variable value?
Date: Sun, 13 Feb 2022 10:57:33 +0100	[thread overview]
Message-ID: <20220213095733.GC8426@voyager> (raw)
In-Reply-To: <>

On Sun, Feb 13, 2022 at 10:54:23AM +0200, Yuri Kanivetsky wrote:
> I don't think it's configurable in a common sense:

Oh bloody hell. All this complexity, and this is the part they choose to
make fixed?

> But you can do:
> $ docker run --rm -it -e TERM=xterm-256color alpine
> / # echo $TERM
> xterm-256color

Yes, as I said, anyone can change TERM.

> So, to sum it up, a terminal emulator is a program (let's not bring up
> virtual consoles here) that emulates a terminal. It creates a pty (a
> master/slave pair), drawing in a window what it receives from the pty,
> and sending what user types to the pty. It also processes some escape
> sequences it receives from the pty, and transforms some user
> keystrokes into escape sequences before sending them to the pty. And
> that determines the TERM variable value (for it to work correctly
> you've got to have it set to a correct value).

Slightly off. It does create a PTY, and then translates what it receives
from it to things that are displayed on screen, speaking a certain
language. It also translates all user inputs into sequences to send back
to the terminal application. And the file that describes these sequences
in both directions is the terminfo database. TERM is used to locate the
terminfo database. As long as you set TERM to something you have the
database for, and the sequences described in the database match (for the
most part) the ones the terminal uses, things will work out.

Bear in mind that most terminals are very similar to each other and use
VT102-style escape sequences. They differ in the fine details. You can
use infocmp not only to print your own terminal's info, but also to
compare it with other terminals. Doing that on screen and xterm, there
are a lot of differences, but a lot of it is just xterm defining keys
that you don't have anyway (F13-F63 you probably only have if your
keyboard is used to control a nuclear power station, for example).

> Then there are some programs like screen and tmux, that are not
> strictly terminal emulators, but in a way they are.

They do translate user inputs into sequences and program outputs into
screen displays. It's just that they do so while being TUI applications
themselves. The point I was making with the Linux VTs is that the
concept is not tethered to any given GUI, or any GUI, for that matter.


I tend to argue against comments a lot. Most of the time they do not
add, and often take away from the important stuff. But if, like here,
you do something questionable, and you don't have a comment, and you
don't have a commit message saying the reason, I really do want

> So, basically with programs like ssh and docker, you generally want to
> keep TERM unchanged. Granted that the corresponding terminfo entry
> exists on a server/in a container.

Yes. And if not, arrange for it to be installed. It isn't hard. For
administrators, installing a new terminfo file is low-risk, since it can
only ever possibly screw over the user that requested it, and all others
would have to opt into using it.

> But why would a program like ssh or docker want to create a pty in the
> first place? If a pty on its own is just a data channel, then they
> could just pass data as is, letting a terminal emulator handle things.
> Isn't having TERM set enough for the programs down the chain to see
> that they're connected to a terminal?

You also want certain kernel interfaces to work. In case of SSH, there
is an encrypted TCP tunnel between the application and the client
terminal. So everything the user types must be encrypted and sent up,
and everything the application sends must be encrypted and sent down. So
what should the standard file descriptors in the process on the server
be? They can't be the socket directly, then nothing would be translated.
And if they were pipes, they would not get treated as terminals.

Many terminal applications make a distinction whether isatty() works on
the standard file descriptors. And that is true for PTYs, as well as VTs
and serial lines, but not for pipes or sockets.

That TERM is set does not say anything about what FD 0 is connected to.


  reply	other threads:[~2022-02-13  9:57 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
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 [this message]
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=20220213095733.GC8426@voyager \ \ \ \

* 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).