[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 13 Feb 2022 10:57:33 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Yuri Kanivetsky <yuri.kanivetsky@...il.com>
Subject: Re: What determines the TERM variable value?
On Sun, Feb 13, 2022 at 10:54:23AM +0200, Yuri Kanivetsky wrote:
> I don't think it's configurable in a common sense:
>
> https://github.com/moby/moby/blob/v20.10.12/container/container.go#L752
>
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.
> https://github.com/moby/moby/commit/c85db1003b#diff-14bacfb63a209323729af295c64c9bb978c84e810d18e3e7b7ae66d9b3cd7acaR259
>
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
something.
> 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.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
