Comment by ElectricalUnion | Hacker News Reader

Comment by ElectricalUnion | Hacker News Reader

Parent Full thread

ElectricalUnion

In theory, `reset`/`tset` from ncurses, or an equivalent, is this "thing" that programs are supposed to be using when they need to engage in terminal shenanigans.

Those use TERM/TERMCAP environment variables and some educated guessing reading stdin/stdout/stderr behaviour to figure out what terminal you're using, search for said entry in terminfo/termcap database, and finally invoking native terminal behavior or simulating it with other terminal behavior.

In theory, one could "just implement" an alternative terminal, and put said simplified entries in terminfo/termcap database and things will be all fine.

In practice several of those ANSI escape code behaviors are hard-coded and everyone pretends everything is "at least as capable as xterm" (a oxymoron, given that xterm is one of the most capable and feature-rich terminals around), so you're also gonna have to implement a converter from "xterm ANSI" to your alternative terminal system - sort of how winpty does convert Win32 terminals conventions to ANSI ones.

Then we're back to the starting issue in this converter.

> In practice several of those ANSI escape code behaviors are hard-coded

The most common examples I see these days are for red/green/yellow status text in shell scripts. To anyone planning to do that, or even more complex stuff, please consider using tput instead.

tput setaf 1; echo this is red

tput setaf 2; echo this is green

tput setaf 3; echo this is yellow

tput setaf 8; echo this is dim

tput bold; echo this is bold

tput sgr0; echo this is normal

blue=$(tput setaf 4); normal=$(tput sgr0); echo ${blue}Color${normal} text.

(man terminfo for arcane details.)

It's wise to make sure output is going to a terminal before using colors, because they don't play well with logs or text processing commands. You can check with: test -t 1

If you use colors, please consider making them optional, since they don't work well for everyone or in every desktop color scheme. An environment variable makes a sensible switch.

> The most common examples I see these days are for red/yellow/green status text in shell scripts.

Please don't do that without first checking the background colour. Yellow in particular on a light background is unreadable.

(On an xterm-compatible terminal you can get the current background colour with OSC 11 ; ? BEL. Some popular terminals lie about being xterm-compatible, though.)

Make sure one has ncurses installed before switching to tput. Alpine Linux does not install this by default for what it's worth.

# No tput, no cry:

red=$(tput setaf 1 2>/dev/null || true)

echo ${red}text

You tryin' to get Bob Marley stuck in my head? Because it worked.

`tput` is POSIX, though, so you can reasonably¹ expect it to be present.

¹ Ha, ha. The distro I use, Debian, also omits at least one POSIX standard utility by default, even though all of them used to fit nicely on systems with less disk than your current CPU's cache.

Please don't; the possibility of being connected to a non-ANSI terminal disappeared before most of us were born.

Counterexample: https://github.com/nushell/nushell/issues/4096

Old glass terminals are still in use here and there, too.

Win32 console is unfortunately a thing. Not anymore, but was a thing for too long.

And PC/3270. Some very powerful systems like Linux on IBM Z are POSIX and your default "interactive login" choice is PC/3270.

And in the long term, isn't this exactly the problem? Do we really want to perpetuate the status-quo of "I am in a somewhat POSIX environment, so the STDOUT/STDERR if interactive must behave exactly like xterm and if not I will just pretend it is xterm anyways and output garbage."?

Whilst it is true that ECMA-48 terminals are overwhelmingly the norm nowadays, that is not a counterpoint to "If you use colours, please consider making them optional".

Yes, this is one of the avenues that I've chased down a bit.

One problem is termcap/terminfo itself. The definition has expanded greatly over time, and documentation is poor to non-existent. In many cases termcap/terminfo has been implicitly extended to support ncurses specifically. And like you say, everyone just sort of assumes ANSI/xterm -- nobody has `PS1="$(tput setaf 3)\w $(tput setaf 0) $", you just hard-code the codes.

The last time I chased the rabbit down this hole I got mired in TTY-land and was not able to dig myself out. Too many insane layers, and before you know it you're writing code to emulate serial connections in a vain attempt to make things work without burning the whole world down.

Both (n)vim and tmux have internal TTY emulation as well which makes things even crazier; I think vim uses libvterm and tmux has one internally hand-coded. It's a mess.

tmux, screen, emacs, and vim all have terminal emulators in them because it’s required, not because they’re crazy.

Consider a really simple case. You are using screen (or tmux, or emacs, or whatever) and you have your terminal divided in half so that you can use a program in one half and tail a log file in the other. The program sends a ^L to clear the screen. Screen (or tmux or whatever) must read the ^L and then _not_ send it on. If it sent it on, the whole screen would be cleared, not just the half with the program in it. Instead it has to send whatever control sequences would erase the text from just the right portion of the screen while leaving everything else alone. Virtually everything sent by the program(s) has to be intercepted and reinterpreted in order for it to work right.

No, they're crazy. I already have a window manager I like; I don't need my terminal to implement their own half-assed one, and my multiplexer (running on the terminal) to implement their own half-assed one, and my editor (running on the multiplexer on the terminal) to implement their own half-assed one.

So don't use tmux then. The entire reason most people use something like tmux is because they want a window manager in their terminal.

This is one of the great joys of FOSS, if you don't like a terminal-based utility then you can bet there's a dozen other options available for you to use.

If you really want crazy, run `xterm -ti 340`, then run run an X server from the xserver-sixel repository <https://github.com/saitoha/xserver-SIXEL> in it. Now y ou can run as many terminal emulators, complete with real truetype fonts and all the colors you could want, inside the one terminal. Use a tiling window manager and you’ll be able to avoid using tmux entirely.

  > No, they're crazy. I already have a window manager I like; I don't need my 
  > terminal to implement their own half-assed one,

Basically agree, though note that ssh and dtach and similar tools need to create pty's on the server and client ends because they implement essentially an adapter between a tty and a byte stream.

I agree with your overall point but your example isn't a great one because ^L would be handled by the controlling process regardless of the terminal state. You don't need any special magic here. And blanking specific sections of a screen wouldn't need any special magic unless you're launching other processes and forwarding their output to the terminal. But if you're not forwarding the output of other processes then you can use standard ANSI escape sequences (or even just \s) to blank specific parts of the screen.

\s is a bit hacky for blanking though, it can produce some undesired results in terms of copy/pasting from the terminal and resizing. But if you've got a "full screen" process like you're describing, you'd be trapping SIGWINCH for resize events anyway.

Since I'm getting downvoted so I'll evidence my point a little more:

Bash source for the ^L hotkey: https://git.savannah.gnu.org/cgit/bash.git/tree/lib/readline...

Notice it's calling termcap:

     _rl_clear_screen (0);  /* calls termcap function to clear screen */

So lets look at what termcap does:

    $ tput clear | hexdump -c
    0000000 033   [   H 033   [   2   J
    0000007

Which isn't the ASCII character ^L (0xC) but instead an ANSI escape code (CSI sequence, to be exact) https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_...

The actual ASCII character for ^L is form feed, (FF: https://www.ascii-code.net) which does serve a similar function but designed for old printers: https://en.wikipedia.org/wiki/Page_break#Form_feed

It doesn't actually clear the screen on modern TTYs. You can try this yourself:

    $ printf "\f"
    
    $ awk 'BEGIN{printf "%c", 12}'
    
    $

Notice how each time it's effectively doing the same as \n?

So in conclusion, ^L clearing the screen isn't something built into the TTY. It's just a hot key like ^U.

There are some hot keys are are driven by the TTY though. ^C, for example. When you press ^C you're not actually sending the 0x3 ASCII character to the controlling process, your TTY gobbles that up and sends a signal to the controlling process instead (albeit this behaviour can be changed by altering the TTYs mode, which requires making a SYSCALL).

So here we've discussed ANSI escape codes, signals and SYSCALLs. However none of these interactions are ASCII characters despite how they're depicted in printed media. Suffice to say, terminals are complicated :)

Amusingly, FF is almost never the control character for clearing the screen. The idea that it is, is widespread, and attributable to some home computers of the 1980s. But it was never the case for DEC VTs. It's equivalent to VT.

Terminal multiplexers like tmux need to create a pseudo-TTYs otherwise they couldn’t multiplex your terminal.

My shell also creates PTYs on some rare occasions too. I’d prefer not to because it’s messy but sometimes there’s no way around it if you want your command line applications to behave like they would on a TTY whilst still having your utility capture that applications output as if it were writing to a pipe.

This is a limitation of TTYs.

The most annoying part of it all is that creating a PTY differs from one Unix-like OS to another. So it’s definitely not a rabbit hole developers go down happily.

> Terminal multiplexers like tmux need to create a pseudo-TTYs otherwise they couldn’t multiplex your terminal.

[Edit: I misread the parent comment as saying multiplexers needed to do terminal emulation. Dtach only multiplexes (using pesudo-TTYs, of course) but unlike screen or tmux does not do terminal emulation. Original comment follows:]

That isn't strictly true; the one I use (dtach) is just a multiplexer.

dtach creates pseudo-TTYs too:

- https://github.com/crigler/dtach/blob/master/master.c#L53

- https://github.com/crigler/dtach/blob/master/master.c#L108

As an aside, that projects source is surprisingly easy to follow. I was able to grok it in just a couple of minutes. Kudos to the author.

Yes, I misread your comment, sorry, having had my mind stuck on terminal emulation.

A PTY is an intrinsic part of terminal emulation.

I think what you’re alluding to is that tmux gobbles up escape sequences (which is configurable by the way) and tracks cell positions. But as I said in another comment, the value add of tmux is its window management capabilities. That’s precisely why people like myself use it. And you cannot have that without complexity. In some edge cases that complexity causes issues, but on the whole I’m more productive for it.

Saying it’s stupid that tmux does that is like saying it’s stupid that motorbikes have gears and fast patrol engines when a bmx works just as well. Sure, to someone who’s never seen a bike before they both look similar. But don’t be fooled by the fact that they both have 2 wheels because they cater to very different needs, hence their very different engineering designs.

Several popular terminals default to calling themselves xterm (e.g. `TERM=xterm-256color`), but are not xterm-compatible, and ignore bug reports (*cough* GNOME *cough*).

Interesting. I don't work on VTE but just landed dozens of patches with no issue at all from pleasant maintainers.

Reply on news.ycombinator.com