←back to thread

103 points linsomniac | 10 comments | | HN request time: 1.258s | source | bottom
1. jchook ◴[] No.42182267[source]
Isn't it true that ANSI sequences can vary depending on the terminal emulator? Does this program account for that somehow?

In my shell scripts I often use `tput bold` etc instead of hardcoding the sequences.

replies(2): >>42182375 #>>42182672 #
2. Joker_vD ◴[] No.42182375[source]
Well, yes, the meaning can depend, although many sequences have standardized meanings. The format of the sequences itself is also standardized but of course, the terminals don't need to use it either! There has been lots of terminals that use their own bespoke control sequences.

Still, nowadays people who write new terminal emulators tend to approach with "do what xterm/libvte does" attitude which is quite sensible: very few people use actual, physical terminals anymore, and the software ones are, well, are generally based on xterm or libvte (or that third library I keep forgetting).

And when was the last time terminfo has been updated anyhow? Not to mention that it lacks info about modern features such as e.g. the version of Unicode used/supported by the terminal.

replies(1): >>42182768 #
3. teddyh ◴[] No.42182672[source]
> Isn't it true that ANSI sequences can vary depending on the terminal emulator?

Yes, historically, many terminals were not even ANSI compatible. That is why the terminfo database (and its predecessor termcap) exist; for programs to look at the TERM environment variable, use that to look up the terminal’s capabilities in terminfo, and see what the terminal can and cannot do, and then choose to output whatever sequences the terminal does support. Normally, a program uses yet another library, like ncurses, to do this, but you can do it yourself if you want to, like in a shell script or similar. Outputting raw escape codes is wrong, since the correct way is so very easy.

replies(1): >>42182781 #
4. zokier ◴[] No.42182768[source]
> And when was the last time terminfo has been updated anyhow?

Two weeks ago?

https://lists.gnu.org/archive/html/bug-ncurses/2024-11/msg00...

> misc/terminfo.src | 40 ++++++++++++++++++++++++++++++-------

replies(1): >>42184354 #
5. Joker_vD ◴[] No.42182781[source]
Don't forget to take care about the terminal code pages as well! Thankfully, terminfo tells you which commands to use when you want to print e.g. β, right?
replies(1): >>42182997 #
6. teddyh ◴[] No.42182997{3}[source]
The easy way is to either restrict yourself to ASCII, or to output raw characters in whatever encoding your locale (LC_CTYPE, LANG, etc.) specifies. If you want to get really fancy with ancient terminals, some of them have, for instance, line drawing characters (and, yes, sometimes things like β) hidden behind special escape sequences, which you can, IIRC, look up in terminfo.
replies(1): >>42184130 #
7. Joker_vD ◴[] No.42184130{4}[source]
So the "correct" way is not that easy, after all.

On the other hand, ignoring ancient terminals and simply pretending everything is color-enabled, VT-220 compatible, UTF-8 aware terminal emulator works well enough™ almost everywhere, including recent versions of Windows (which IIRC don't even have terminfo; not that it'd help since the legacy Windows console uses ioctl()-like interface instead of the escape sequences) — and is actually easy.

replies(1): >>42195656 #
8. Joker_vD ◴[] No.42184354{3}[source]
Wow, reading the history at the end of that file is... depressing. Well, good luck to Thomas E. Dickey, testing the vt/xterm-compatibiity of all the newfangled terminal emulators and maintaining capabilities on stuff like DJGPP in perpetuity.
replies(1): >>42189936 #
9. Gormo ◴[] No.42189936{4}[source]
What's depressing about it?
10. teddyh ◴[] No.42195656{5}[source]
Outputting UTF-8 to a UTF-8 locale is not easy? Most of this is automatically handled by appropriate libraries.

I.e. I would expect

  python3 -c 'print("\N{GREEK SMALL LETTER BETA}")'
to just work on any terminal, as Python does the right thing for you.