mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Andy Caldwell <>
To: "" <>
Cc: Yuri Kanivetsky <>
Subject: [musl] RE: [EXTERNAL] Re: [musl] What determines the TERM variable value?
Date: Thu, 17 Feb 2022 20:37:34 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20220213095733.GC8426@voyager>

> On Sun, Feb 13, 2022 at 10:54:23AM +0200, Yuri Kanivetsky wrote:
> > I don't think it's configurable in a common sense:
> >
> >
> >
> > 752&amp;
> > 4ccf808d9eed74d25%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6378034
> > 31376969496%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> > IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Icw%2BHvFTPaaY0w%2B6
> > VcmyhhXT%2BXhube1WJ0kO5UmC0qk%3D&amp;reserved=0
> >
> Oh bloody hell. All this complexity, and this is the part they choose to make fixed?

It makes perfect sense that this is hard-coded.  As you say, the TERM variable is the way
programs running on the TTY learn what escape codes to use to ask the TTY to do things
(change colour, clear the screen, restart a line, etc.) so the TERM is _set by the TTY_.
When running a docker container with a TTY attached, the TTY is created by the docker
daemon and isn't the TTY that's hosting the docker client binary.  This is needed to allow
the client to disconnect from the deamon without killing the container, and it also needed
for cases where the client and daemon are on separate hosts.

The daemon is listening on the master side of the TTY it created then streams data to and
from the client (if there is one) which then reads _its_ TERM variable and translates the
operations that the container tried to make into the appropriate control codes for the local
TTY.  Changing the TERM inside the container only makes sense if you also change the TTY
handling that the daemon does to match, otherwise the daemon will incorrectly interpret
control characters, pass those misinterpretations to the client which will then "correctly"
apply the wrong behaviour to the user's console.

Awkwardly many TTY termcap control characters are _mostly_ compatible (since they're
all based on VT100) so if you misconfigure your TERM things _mostly_ work, then you try
to use some TUI-heavy tool (like vim) and some things subtly don't work correctly.

      reply	other threads:[~2022-02-17 20:37 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
2022-02-17 20:37             ` Andy Caldwell [this message]

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 \ \ \ \ \

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