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

141–150 of 191 posts

Re: Everything you ever wanted to know about terminals

#141

Post by jart »

_rmcx wrote: post #139
jart wrote: post #135

Earlier quoted context omitted.

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.

Yes but no one agrees on what that should be. For example, I need to flip through a 623 page manual to discover -fdiagnostic-color=always is the magic incantation for gcc. I have to repeat that for every app I use. Some do it using environment variables, except no one agrees on names there either, so I have to bloat my environment and it slows down process creation. Whereas with my sed solution, anyone who knows regex can could write it in a few minutes, and it only has to be figured out one time. Furthermore, there will eventually come a day when the tools we pipe stuff into all get good enough to gracefully consume ANSI codes, and there's no longer a need for sed. But we can't evolve in that direction if we use the solution you're proposing, which binds us to a colorless past. Erring on the side of having more information is always a good thing. The burden of the flag should be on disabling, not enabling, and there shouldn't even need to be a flag since there's sed.

Re: Everything you ever wanted to know about terminals

#142

Post by trasz »

_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…

FWIW, all this stuff above about /dev/tty is absolutely wrong.

Re: Everything you ever wanted to know about terminals

#143

Post by duskwuff »

jart wrote: post #116
duskwuff wrote: post #66

Earlier quoted context omitted.

The relevant ECMA standards are full of crazy bullshit that, to the best of my knowledge, nobody has ever implemented in any hardware or software terminal, like control sequences to make lines of text run vertically (SPD), or to fully justify text (JFY), or to use a Fraktur font (SGR 20). They're also incomplete -- they go into very little detail explaining what various control sequences should do, especially in exce…

Hi I'm one of the people cited by the article. Fraktur is awesome. I implemented it in my terminal. https://github.com/jart/cosmopolitan/blob/c6bbca55e9f977e386... Now that unicode makes it easy, there's no excuse not to have fraktur!

Wow, okay, guess I can cross that one off my list of "ECMA-48 features nobody implements".

There's still plenty left on that list, though -- including at least one escape sequence I'm fairly certain was included as a joke (SPQR).

Re: Everything you ever wanted to know about terminals

#145

Post by easrng »

hnlmorg wrote: post #47
metroholografix wrote: post #27

Earlier quoted context omitted.

https://www.ecma-international.org/publications-and-standard...

Not all terminal emulators follow that completely. Most only include a subset and some include their own proprietary escape codes too (like iTerm and Terminology have codes for rendering images. tmux has an escape code for changing the session title). Then there's other specs not included in that doc even outside of the aforementioned proprietary codes. Like Sixel, conventions on non-POSIX terminals, etc. Also lets n…

hTerm and also IIRC kitty have image-rendering escape sequences too.

Re: Everything you ever wanted to know about terminals

#146

Post by mikevin »

d0mine wrote: post #89
broses wrote: post #40

A while ago I was trying to find a way to make my terminal scroll back up after a command executed, so that if the output was long I could read it from the top without having to scroll up manually. There are ways to get yours shell to print something after the command executes, so I just needed to find an ansi escape sequence that would scroll up. Unfortunately I didn't see any sequences that do this. Anyone have any…

vterm in emacs has a command to jump to the previous shell prompt.

eshell has a module called eshell-smart that borrows from Plan 9's 9term, it automatically pages long commands, stays on the same line for editing if you show intent to change it and automatically scrolls to the end if you start typing a new command.

Re: Everything you ever wanted to know about terminals

#148

Post by teddyh »

> being compatible only with ANSI-capable terminals is a feature, not a bug, go the fuck away. terminfo is a fucking joke. nobody needs to target obscure dumb terminals (or smart terminals, for that matter) from 1983 anymore.

No, terminal emulators differ all over the place, especially for new features. Do you want to lock yourself in and only use the ancient ANSI codes? In, like you say, “THE TWENTY FIRST FUCKING CENTURY”? Great, you do that.

What’s that you say? You want to use modern features on terminals which support it? Do you then write “if getenv("TERM") == "spiffy-terminal"”? Congratulations, you’ve just begun implementing your very own ad hoc, informally-specified and bug-ridden terminal UI library.

> my hope is that this tutorial will curtail some of the more egregiously trivial uses of ncurses and provide others with the knowledge needed to implement a 21st-century terminal UI library

If you don’t like curses specifically, then don’t use it, but there are now myriads of alternatives.

Re: Everything you ever wanted to know about terminals

#149

Post by Normal_gaussian »

jart wrote: post #141
_rmcx wrote: post #139

Earlier quoted context omitted.

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

Yes but no one agrees on what that should be. For example, I need to flip through a 623 page manual to discover -fdiagnostic-color=always is the magic incantation for gcc. I have to repeat that for every app I use. Some do it using environment variables, except no one agrees on names there either, so I have to bloat my environment and it slows down process creation. Whereas with my sed solution, anyone who knows rege…

> man gcc

Search color, its the first result as an abbreviated reference and the second as a full explanation. Its also the first result on google/ddg/etc.

You have a good argument, but claiming you have to "flip through a 623 page manual" and "with my sed solution, anyone who knows regex could write it in a few minutes" detracts from your point.

Re: Everything you ever wanted to know about terminals

#150

Post by [deleted] »

_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…

[deleted]
Post reply on HN