> The only programs that cause an issue are tools that send ANSI escape sequences (eg for ncurses) and check if STDOUT is a TTY before sending them.
Sure, but aren't those programs the whole point of having sophisticated terminal emulators? If plain streams of text was all we cared about for CLI applications, it would indeed make things a lot easier. So much easier, in fact, that we can dump our current terminal emulators in favor of a more simple alternative without ever having to complicate the shell. But since people do care about terminal UIs, this isn't a realistic solution.
> Sure, but aren't those programs the whole point of having sophisticated terminal emulators?
What we currently have isn't sophisticated terminal emulators. It's a buggy superset of hundreds of kludges due to 60s years of legacy. I mean there's a lot I do love about the design but there's a lot to legitimately dislike as well.
> If plain streams of text was all we cared about for CLI applications, it would indeed make things a lot easier. So much easier, in fact, that we can dump our current terminal emulators in favour of a more simple alternative without ever having to complicate the shell.
The shell isn't the complication here. The shell is just a program launcher. The real issues with terminals is:
- Formatting is inlined with the data stream.
- There isn't any type information in pipes (it is just a raw byte stream) so applications can't easily do context sensitive processing.
- ASCII isn't just a text format but also a data format (there's ASCII characters for tables and records) and flow control (EOF) and job control (^c, ^z).
- It's that responsibility for all of this is divvied up between the TTY driver (in Linux's case, the kernel), the terminal emulator, and any user space applications reading and writing to their respective file descriptors.
- Terminals were never built to be API driven and while there are some interactive ANSI escape sequences they're not widely supported by terminal emulators. So from a shell or tty perspective, the terminal is a black box
- Plus since file descriptors are literally files and TTYs are literally files, it means actually any other process can write to the TTY even if they're not part of the shell's process group (hence why tools like `wall` can exist). So even if the shell could keep track of what was in STDOUT of the processes it spawned, it can't possibly know if anyone else has written to that same TTY.
There some ingenious design in Linux terminals but there are soooo many rough patches thrown in too.
> But since people do care about terminal UIs, this isn't a realistic solution.
Right, but I was never suggesting people don't care about terminal UIs nor that shells don't offer a valuable function. In fact the opposite is true: I've written my own shell because I thought I could create a better UI/UX than Bash.
Sure, but aren't those programs the whole point of having sophisticated terminal emulators? If plain streams of text was all we cared about for CLI applications, it would indeed make things a lot easier. So much easier, in fact, that we can dump our current terminal emulators in favor of a more simple alternative without ever having to complicate the shell. But since people do care about terminal UIs, this isn't a realistic solution.