Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you ever wanted to know about terminals

xn--rpa.cc

Post reply on HN
Print view View original

131–140 of 191 posts

Re: Everything you ever wanted to know about terminals

#131

Post by jart »

WalterGR wrote: post #88

My understanding is that control codes for [every possible modifier key combination] + ['standard' US keyboard keys] aren't all standardized. Is that correct? I seem to recall having a hell of a time trying to figure out which key combinations Emacs could understand and why (keyboard -> OS -> terminal emulator -> protocol -> program.) Are there any proposals? Workarounds? Proofs-of-concept?

They pretty much are. Terminals implement CTRL keyboard shortcuts as `c ^ 0100` and ALT works by prefixing '\e'. Stuff like arrow keys encode using VT100 codes. Those are three very simple rule that everyone knows.

    $ wget https://justine.lol/ttyinfo.com
    $ chmod +x ttyinfo.com
    $ ./ttyinfo.com
    "\001" is CTRL-A a.k.a. ^A
    "\000" is CTRL-@ a.k.a. ^@
    "\002" is CTRL-B a.k.a. ^B
    "\f" is CTRL-L a.k.a. ^L
    "\r" is CTRL-M a.k.a. ^M
    "\033\001" is ALT-CTRL-A
    "\033[A" is UP
    "\033\033[A" is ALT-UP
Unfortunately it still leaves much to be desired. For example, have you ever wanted to have CTRL-ENTER as a keyboard shortcut in your terminal? Sadly you can't, because chr(ord('\r') ^ 0100) encodes as 'M'. Another issue is it's not possible to encode CTRL+[ as a keyboard shortcut, because it overlaps with \e a.k.a. 033 a.k.a. ASCII ESC. So if you type that shortcut, it'll cause your terminal to hang for a second.

It'd be great if the standard bodies could promulgate some kind of well-defined solution to this problem. Having read the ECMA standards documents, I think they really could be doing more to focus on the people who use it for terminals!

Re: Everything you ever wanted to know about terminals

#132

Post by geocar »

_rmcx wrote: post #128
rcfox wrote: post #119

Earlier quoted context omitted.

This is my first time hearing of this functionality. How does it work with buffered stdout? For example, if you wanted to colour a single word?

> This is my first time hearing of this functionality. I was also surprised when I discovered this. IMO this should be used everywhere but I've rarely seen it. > How does it work with buffered stdout? For example, if you wanted to colour a single word? This is not affected by buffering. What matters is what the output device/file/stream gets eventually. How coloring a single word works depends on how you use it. You…

> write_and_flush_to_dev_tty(BEGIN_RED_TEXT),write_and_flush_to_stdout("word"),write_and_flush_to_dev_tty(END_RED_TEXT);

This isn't guaranteed to be serialized: Someone trying to log the output of your application might try: | tee /dev/tty | logger ... or they might be running under kubernetes/docker (which does much the same thing).

I suggest the following:

1. If fd 0 and fd 1 are both ttys (isatty), and they point to the same tty (ttyname) then use it a tty (like your first example)

2. If fd 1 is not a tty, and fd 0 is a tty, write plaintext to fd 1. The user wants to filter output.

3. If neither fd 0 or 1 is a tty, write twice: do interactive stuff and send your vt-sequences with the text embedded to /dev/tty and a plaintext copy to fd 1.

Now the user doesn't need the extra tee, and we no longer need to worry about synchronisation. Users don't typically (meaningfully) grep interactive applications, so I think it's a good compromise for interactive servers and tuis.

But if you're not reading input or doing absolute cursor movement, and you just want some spicy log lines, I don't think you should be doing any of this fiddling: Just write sequences to stdout if it's a tty (or if the user specifically tells you to).

I also recommend checking for $NO_COLOR in the environment and honouring the users wishes here: Some users are colourblind so this represents a real accessibility issue for them. One of the advantages of ncurses/terminfo is you get some accessibility features you might not have known you needed.

Re: Everything you ever wanted to know about terminals

#133

Post by sph »

_rmcx wrote: post #128
rcfox wrote: post #119

Earlier quoted context omitted.

This is my first time hearing of this functionality. How does it work with buffered stdout? For example, if you wanted to colour a single word?

> This is my first time hearing of this functionality. I was also surprised when I discovered this. IMO this should be used everywhere but I've rarely seen it. > How does it work with buffered stdout? For example, if you wanted to colour a single word? This is not affected by buffering. What matters is what the output device/file/stream gets eventually. How coloring a single word works depends on how you use it. You…

Flushing once at the end of every word is better than flushing every time you write, because at that point you might as well disable buffering.

Re: Everything you ever wanted to know about terminals

#134

Post by sph »

_rmcx wrote: post #111

One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you…

I loathe to imagine how those modern TUI libraries that have been popping up recently [1] that emulate Elm and React rendering in the terminal deal when isatty == false.

We're basically recreating Flash for the terminal, where we got a fancy UI but we lose the original text functionality, i.e. output is non pipable anymore. Not ideal when working on UNIX systems.

1: https://news.ycombinator.com/item?id=31328205

Re: Everything you ever wanted to know about terminals

#135

Post by jart »

_rmcx wrote: post #111

One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you…

Have you considered that many of us want ansi codes in the pipeline? For example, all the log viewers I use understand things like color codes. If I don't want ANSI codes in the output, then I can just pipe it through sed 's/\x1b\[[;[:digit:]]*m//g' which is easy. However if a program tries to be "smart" like you're describing w.r.t. hiding ANSI codes, then I have to go to all this trouble wrapping it inside another program which is a fake pseudo-terminal, which captures and extracts the real output.

Re: Everything you ever wanted to know about terminals

#136

Post by dllthomas »

csdvrx wrote: post #5

> but i swear to god developers have so completely forgotten how terminals work that i might be one of a handful of people left on earth who actually has the knowledge to, so they all just layer their bullshit on top of ncurses (which should never have survived the '90s) instead and it's ｍａｄｄｅｎｉｎｇ． Actually, yes, understanding the tty in detail seems to become a dark art. However it's the best way to do complex thing…

I do wish there was a save/restore cursor variant that would scroll with the text.

Re: Everything you ever wanted to know about terminals

#137

Post by hoseja »

ntoskrnl wrote: post #17
donatj wrote: post #11

Earlier quoted context omitted.

Interestingly it's not even showing in Chrome for me. Shows fine in Safari. I wonder if Chrome considers the upside down "LATIN SMALL LETTER TURNED K" potentially deceptive. They've apparently got a whole document about what Chrome will and won't display https://chromium.googlesource.com/chromium/src/+/main/docs/i...

Firefox shows the raw punycode too. If I owned that domain I'd be mildly annoyed.

Yeah, it made me toggle firefox punycode setting, to no effect.

Re: Everything you ever wanted to know about terminals

#138

Post by hoseja »

kevin_thibedeau wrote: post #82
lupire wrote: post #28

Earlier quoted context omitted.

Unicode domain names are a security threat, due to homographs.

Upgrade to Firefox and you'll only see the punycode.

I specifically want to see unicode and firefox isn't letting me.

Re: Everything you ever wanted to know about terminals

#139

Post by _rmcx »

jart wrote: post #135
_rmcx wrote: post #111

One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you…

Have you considered that many of us want ansi codes in the pipeline? For example, all the log viewers I use understand things like color codes. If I don't want ANSI codes in the output, then I can just pipe it through sed 's/\x1b\[[;[:digit:]]*m//g' which is easy. However if a program tries to be "smart" like you're describing w.r.t. hiding ANSI codes, then I have to go to all this trouble wrapping it inside another…

> Have you considered that many of us want ansi codes in the pipeline?

Yes I have. Using /dev/tty doesn't stop an application's author from adding a --color that lets their program send color codes to stdout. But if the author doesn't use /dev/tty either stdout or stderr of their application can't be redirected.

Re: Everything you ever wanted to know about terminals

#140

Post by trasz »

_rmcx wrote: post #111

One thing that the author doesn't seem to know about is /dev/tty. In the article the escape codes are just sent to stdout. Though an awful lot of applications (including the greatest ones) do this, IMHO this is wrong. The terminal control codes are used to control a terminal, and they are often not meant to be part of the output stream, for example when the output is piped or redirected to a text file. When what you…

If you want to build a TUI, you absolutely shouldn’t try to mess with devices, nor should you assume your terminal is /dev/tty. You should be using isatty(3) libc function.
Post reply on HN