4 ms·

> It's not on non-POSIX systems If we cannot assume POSIX, we cannot assume even the existence of environment variables. > For the OPs software, hardcoding vt

by teddyh 2y ago

> It's not on non-POSIX systems If we cannot assume POSIX, we cannot assume even the existence of environment variables. > For the OPs software, hardcoding vt100 sequences and falling back dumb mode if stdout is not a TTY is a perfectly reasonable suggestion given their requirements. Linking to ncurses and (if stdout is a TTY) using ncurses to look up the correct escape sequences is simple and guaranteed to be correct. If ncurses comes back and says “nope, this terminal does not support your requested operations”, in that case you have some leeway in what to do. (I would personally advocate to stopping there; if somebody has a capable terminal, but has not configured their system to advertise it and its capabilities correcly, that is their problem.) If you insist on doing extra work to deal with mis- or unconfigured systems, you should first certainly first handle TERM=dumb specially and not send any escape codes. But hardcoding terminal escape codes? People worked hard to make libraries to abstract away all these things for programs. Programs should offload as much work as possible to (sufficiently reliable) higher-level libraries. This feels like advocating for x86-64 assembly in, say, 2016, when the Intel/AMD hegemony was more or less absolute. It might feel like a reasonable assumption at the time, but the pendulum always swings back to multi-platform support being necessary.

hnlmorg 2y ago
> If we cannot assume POSIX, we cannot assume even the existence of environment variables. That's basically just expanding my point, but yeah, you cannot guarantee $TERM. For what it's worth though, all the major non-POSIX platforms do support the concept of environmental variables. Even Windows. > Linking to ncurses and (if stdout is a TTY) using ncurses to look up the correct escape sequences is simple and guaranteed to be correct. Simple if you want to write in a language that supports C FFIs. Some don't. Furthermore, even those C calls can be sub-optimal. For example C calls break thread safety in some languages. This particular tool was written in Go. And frankly there isn't any good options: - cgo creates build and runtime complexities - the established Go-native ncurses-style libraries come with way way way more than what is needed here. You just dont want nor need that bloat. It's more to audit, it's more to go wrong. - the Go-native terminfo libraries haven't been battle tested. So you're not really much better off with them than you are hardcoding the tiny number of escape sequences needed (more on that later) and assuming vt100 compatibility for TTYs. If we were talking about writing a full TUI then I'd agree with you regarding relying on a battle tested ncurses (or equivalent) package. But that's not what this project is. This is literally just printing an ordered list. > If you insist on doing extra work to deal with mis- or unconfigured systems, you should first certainly first handle TERM=dumb specially and not send any escape codes. You're the one insisting on doing extra work. Not me :) Plus I've already put the dumb terminal argument to bed. > But hardcoding terminal escape codes? Lets be specific here, I wasn't suggesting every application should hardcode every escape sequence. I was suggesting that the escape sequences for this specific internal company tool being discussed here are simple enough that they can be hardcoded. It's literally just 2 escape sequences needed. 3 if you want to get clever. Having that hardcoded makes more sense than having a 3rd party library that you then need audit (again, this is an internal company tool), just to print 2 escape sequences. Context matters. > People worked hard to make libraries to abstract away all these things for programs. I know. I'm the author of several such libraries ;) > Programs should offload as much work as possible to (sufficiently reliable) higher-level libraries. "sufficiently reliable" is doing a lot of heavy lifting there. See my comments about auditing imports for internal corporate tools. > This feels like advocating for x86-64 assembly in, say, 2016, when the Intel/AMD hegemony was more or less absolute. It might feel like a reasonable assumption at the time, but the pendulum always swings back to multi-platform support being necessary. That's an absurd comparison and I think even you know that. My entire point is about trying to avoid boiling the ocean -- you're the one advocating creating more unnecessary work, not me. And if you're worried about vt100 compatibility disappearing tomorrow, actually the opposite is true. We are seeing more non-POSIX platforms implement vt100 compatibility. (to be honest, I'd love to see terminals progress beyond in-band data formats presented as buggy escape sequences, but it's just not going to happen). --- I don't think we're going to see eye to eye on this. So maybe we just agree to disagree?
- teddyh 2y ago
  Hardcoding an escape sequence or two because you’re using an as-of-yet immature language environment with cumbersome and/or inadequate, or even buggy, libraries is… actually a good argument. Personally, I would have the program run tput(1) as a subprocess and capture (and save) the correct escape sequences from the pipe, for later re-use, but I could imagine how, in some special cases, that might not be practical. > You're the one insisting on doing extra work. I am insisting that programs handle terminals correctly. It was you who brought up the rather remote edge case of when TERM is not enough to identify a terminal; i.e. when the operations you want to perform are so advanced that they might differ even when TERM is the same, or be missing even if TERM is set correctly, or not even be present in terminfo. What I wrote was my suggestions to handle that case, which would indeed be extra work, but it was you who asked for that case to be handled. > I wasn't suggesting every application should hardcode every escape sequence. > I was suggesting that the escape sequences for this specific internal company tool being discussed here are simple enough You originally wrote “in reality you can get away with hardcoding vt100 sequences for most things.” But now you want to argue that you were always talking only about this specific use case? (Also, it seems that for this specific use case, only one escape sequence would be needed: “cursor_up”/“cuu1”.) > That's an absurd comparison and I think even you know that. I do not. > And if you're worried about vt100 compatibility disappearing tomorrow, actually the opposite is true. The same was said about the x86 instruction set, and it did look completely entrenched for many years. But then it wasn’t. And old ideas and concepts about what can be done with terminals, like MGR, may yet rise again. I see things like sixels only as symptoms of a pent-up demand for this. And people won’t want to go through ANSI X3.64 sequences to render their remote applications, so non-ANSI terminal protocols are likely to emerge again.
  - hnlmorg 2y ago
    > Personally, I would have the program run tput(1) as a subprocess and capture (and save) the correct escape sequences from the pipe, for later re-use, but I could imagine how, in some special cases, that might not be practical. That's not a bad suggestion generally speaking. I've seen a fair amount of shell scripts that do this too. In this specific case, they're running DNS lookups in parallel to speed the tool up, so I think forking tput wouldn't be preferable. But for tools that are more forgiving for latency (and specifically targeting POSIX too), that's definitely an option. > You originally wrote “in reality you can get away with hardcoding vt100 sequences for most things.” But now you want to argue that you were always talking only about this specific use case? Fair point. > (Also, it seems that for this specific use case, only one escape sequence would be needed: “cursor_up”/“cuu1”.) I was thinking cursor down too, but actually you're right, \n would do that job better for a multitude of reasons. Edit: thinking about this more, there’s a reverse carriage return ASCII character so you don’t actually need any ANSI escape sequences at all. > The same was said about the x86 instruction set, and it did look completely entrenched for many years. But then it wasn’t. And old ideas and concepts about what can be done with terminals, like MGR, may yet rise again. I see things like sixels only as symptoms of a pent-up demand for this. And people won’t want to go through ANSI X3.64 sequences to render their remote applications, so non-ANSI terminal protocols are likely to emerge again. Professionally speaking: I can't see that happening. More systems are implementing vt100 support, not less. And escape sequences are "easy" to implement and "good enough" that most people have a quick moan about them but then quickly move on to getting whatever job they want done, done. Plus the decline of x86 was driven by $$$ (like most changes in IT). Apple wanting to own more of the pipeline. Datacentres wanting to reduce infrastructure and operational costs. And ARM was already as old and established as x86 so it wasn't like trying to create a new standard (how many other architectures have fallen by the wayside?). There isn't anything like that happening for terminals right now. However, personally speaking: I genuinely hope you're right. The status quo sucks. Just so long as whatever new that comes along is a complete redesign. In-band meta sequences are just horrible. But I think realistically, those that don't like the status quo with terminals either use web technologies or Microsoft RPCs instead. And those that like the terminal have already learned to live with its many warts.

by teddyh 2y ago

hnlmorg 2y ago

> If we cannot assume POSIX, we cannot assume even the existence of environment variables. That's basically just expanding my point, but yeah, you cannot guarantee $TERM. For what it's worth though, all the major non-POSIX platforms do support the concept of environmental variables. Even Windows. > Linking to ncurses and (if stdout is a TTY) using ncurses to look up the correct escape sequences is simple and guaranteed to be correct. Simple if you want to write in a language that supports C FFIs. Some don't. Furthermore, even those C calls can be sub-optimal. For example C calls break thread safety in some languages. This particular tool was written in Go. And frankly there isn't any good options: - cgo creates build and runtime complexities - the established Go-native ncurses-style libraries come with way way way more than what is needed here. You just dont want nor need that bloat. It's more to audit, it's more to go wrong. - the Go-native terminfo libraries haven't been battle tested. So you're not really much better off with them than you are hardcoding the tiny number of escape sequences needed (more on that later) and assuming vt100 compatibility for TTYs. If we were talking about writing a full TUI then I'd agree with you regarding relying on a battle tested ncurses (or equivalent) package. But that's not what this project is. This is literally just printing an ordered list. > If you insist on doing extra work to deal with mis- or unconfigured systems, you should first certainly first handle TERM=dumb specially and not send any escape codes. You're the one insisting on doing extra work. Not me :) Plus I've already put the dumb terminal argument to bed. > But hardcoding terminal escape codes? Lets be specific here, I wasn't suggesting every application should hardcode every escape sequence. I was suggesting that the escape sequences for this specific internal company tool being discussed here are simple enough that they can be hardcoded. It's literally just 2 escape sequences needed. 3 if you want to get clever. Having that hardcoded makes more sense than having a 3rd party library that you then need audit (again, this is an internal company tool), just to print 2 escape sequences. Context matters. > People worked hard to make libraries to abstract away all these things for programs. I know. I'm the author of several such libraries ;) > Programs should offload as much work as possible to (sufficiently reliable) higher-level libraries. "sufficiently reliable" is doing a lot of heavy lifting there. See my comments about auditing imports for internal corporate tools. > This feels like advocating for x86-64 assembly in, say, 2016, when the Intel/AMD hegemony was more or less absolute. It might feel like a reasonable assumption at the time, but the pendulum always swings back to multi-platform support being necessary. That's an absurd comparison and I think even you know that. My entire point is about trying to avoid boiling the ocean -- you're the one advocating creating more unnecessary work, not me. And if you're worried about vt100 compatibility disappearing tomorrow, actually the opposite is true. We are seeing more non-POSIX platforms implement vt100 compatibility. (to be honest, I'd love to see terminals progress beyond in-band data formats presented as buggy escape sequences, but it's just not going to happen). --- I don't think we're going to see eye to eye on this. So maybe we just agree to disagree?

teddyh 2y ago
Hardcoding an escape sequence or two because you’re using an as-of-yet immature language environment with cumbersome and/or inadequate, or even buggy, libraries is… actually a good argument. Personally, I would have the program run tput(1) as a subprocess and capture (and save) the correct escape sequences from the pipe, for later re-use, but I could imagine how, in some special cases, that might not be practical. > You're the one insisting on doing extra work. I am insisting that programs handle terminals correctly. It was you who brought up the rather remote edge case of when TERM is not enough to identify a terminal; i.e. when the operations you want to perform are so advanced that they might differ even when TERM is the same, or be missing even if TERM is set correctly, or not even be present in terminfo. What I wrote was my suggestions to handle that case, which would indeed be extra work, but it was you who asked for that case to be handled. > I wasn't suggesting every application should hardcode every escape sequence. > I was suggesting that the escape sequences for this specific internal company tool being discussed here are simple enough You originally wrote “in reality you can get away with hardcoding vt100 sequences for most things.” But now you want to argue that you were always talking only about this specific use case? (Also, it seems that for this specific use case, only one escape sequence would be needed: “cursor_up”/“cuu1”.) > That's an absurd comparison and I think even you know that. I do not. > And if you're worried about vt100 compatibility disappearing tomorrow, actually the opposite is true. The same was said about the x86 instruction set, and it did look completely entrenched for many years. But then it wasn’t. And old ideas and concepts about what can be done with terminals, like MGR, may yet rise again. I see things like sixels only as symptoms of a pent-up demand for this. And people won’t want to go through ANSI X3.64 sequences to render their remote applications, so non-ANSI terminal protocols are likely to emerge again.
- hnlmorg 2y ago
  > Personally, I would have the program run tput(1) as a subprocess and capture (and save) the correct escape sequences from the pipe, for later re-use, but I could imagine how, in some special cases, that might not be practical. That's not a bad suggestion generally speaking. I've seen a fair amount of shell scripts that do this too. In this specific case, they're running DNS lookups in parallel to speed the tool up, so I think forking tput wouldn't be preferable. But for tools that are more forgiving for latency (and specifically targeting POSIX too), that's definitely an option. > You originally wrote “in reality you can get away with hardcoding vt100 sequences for most things.” But now you want to argue that you were always talking only about this specific use case? Fair point. > (Also, it seems that for this specific use case, only one escape sequence would be needed: “cursor_up”/“cuu1”.) I was thinking cursor down too, but actually you're right, \n would do that job better for a multitude of reasons. Edit: thinking about this more, there’s a reverse carriage return ASCII character so you don’t actually need any ANSI escape sequences at all. > The same was said about the x86 instruction set, and it did look completely entrenched for many years. But then it wasn’t. And old ideas and concepts about what can be done with terminals, like MGR, may yet rise again. I see things like sixels only as symptoms of a pent-up demand for this. And people won’t want to go through ANSI X3.64 sequences to render their remote applications, so non-ANSI terminal protocols are likely to emerge again. Professionally speaking: I can't see that happening. More systems are implementing vt100 support, not less. And escape sequences are "easy" to implement and "good enough" that most people have a quick moan about them but then quickly move on to getting whatever job they want done, done. Plus the decline of x86 was driven by $$$ (like most changes in IT). Apple wanting to own more of the pipeline. Datacentres wanting to reduce infrastructure and operational costs. And ARM was already as old and established as x86 so it wasn't like trying to create a new standard (how many other architectures have fallen by the wayside?). There isn't anything like that happening for terminals right now. However, personally speaking: I genuinely hope you're right. The status quo sucks. Just so long as whatever new that comes along is a complete redesign. In-band meta sequences are just horrible. But I think realistically, those that don't like the status quo with terminals either use web technologies or Microsoft RPCs instead. And those that like the terminal have already learned to live with its many warts.