[zbentley]

This is an interesting idea--that in a reimagined OS, programs could have their output connected to all sorts of sinks (terminal, file, GUI, web content) without carrying baggage related to those sinks' behaviors.

I think the core question is whether some middle layer of output processing between program and sink/display could be created that knows enough about (using terminals as an example sink) raw mode/console dimensions/buffering to make most programs display correctly enough for most users without knowing specifics about the program writing the output's internals. If that can be done, then programs that need more specifics (e.g. complex animated/ncurses GUIs) could either propose overrides/settings to the output middleware or configure it directly, and programs that don't wouldn't.

That's possible to implement, sure, but can that be done without just reinventing the POSIX terminal API, or any one of the bad multiplatform-simple-GUI APIs, badly?

[Joker_vD]

> programs could have their output connected to all sorts of sinks (terminal, file, GUI, web content) without carrying baggage related to those sinks' behaviors.

We already have this. The TTY itself is not very special at all. It's just that the applications, traditionally, decide that they should special-case the writing to TTYs (because those, presumably, are human-oriented and should have as little batching as possible). But you, as an application developer, can simply not do this, you know.

[wahern]

Automatically changing behavior by testing if the output sink is a TTY is traditionally considered an anti-pattern by those with enough time and hair loss spent at the terminal. It's one of those things where there are definitely occasions where it's useful, but it's overused and can end up frustrating people more than it helps, like when they're attempting to replicate a work flow in a script.[1] A classic example of "just because you can do something doesn't mean you should do it".

I don't know how it works today, but IIRC colorization by GNU ls(1) used to require an explicit option, --color, typically added through an alias in default interactive shell configs, rather than ls automatically enabling it by default when detecting a TTY.

Explicit is generally better than implicit unless you're reasonably sure you're the last layer in the software stack interacting with the user. For shell utilities this is almost never the case, even when 99% of usage is from interactive shells. For example, `git` automatically invokes a pager when it detects output is to a TTY; this is endlessly frustrating to me because most of the time I'd prefer it dumped everything to the screen so I could more easily scroll using my GUI terminal window, as well as retain the output in the scroll buffer for later reference. Git does have the -P option to disable this behavior, but IMHO it has proper defaults reversed; usually I just end up pipe'ing to cat because that's easier to remember than bespoke option arguments for frilly anti-features.

[1] Often times it forces people to use a framework like expect(1) to run programs with another pseudo TTY for child programs just to replicate the behavior.

[Joker_vD]

> I don't know how it works today, but IIRC colorization by GNU ls(1) used to require an explicit option, --color, typically added through an alias in default interactive shell configs, rather than ls automatically enabling it by default when detecting a TTY.

It works exactly like this today. Plus, lots of software added support of NO_COLOR today.

> For example, `git` automatically invokes a pager when it detects output is to a TTY; this is endlessly frustrating to me because most of the time I'd prefer it dumped everything to the screen so I could more easily scroll using my GUI terminal window.

Set your pager to cat? That's what I personally do, never really liked this built-in convention either.

[direwolf20]

ls is usually aliased to ls --color=auto in the bashrc that comes with your distribution

Auto means to enable if output is a terminal. I think this is reasonable. The default is no color, ever.

[pocksuppet]

We use them today - terminal emulators. They intermediate between bytes and pixels.

If colours were delivered via a sideband, you wouldn't have to know whether the other side was a terminal to disable colours. You could send colours to a file and they wouldn't be stored - or would be stored in RTF format, if you were sending to an RTF file.

The design we use on Linux is very "worse is better". Some mechanisms were developed because they could be developed, and those mechanisms, because they were the ones available, were made to fulfil every purpose they could fulfil, and now we're locked into this design for better or worse.

Windows used to have APIs to directly set text colour. You could set the colour to blue and print some text and it would be blue. You could call a function on a console window object to ask how big the console window was, or to change it. This obviously doesn't compose through pipes or ssh, but Windows doesn't have a pipe culture or ssh culture so that was never a design criterion. They've since deprecated that and moved to the worse-is-better escape-code design, in order to increase compatibility with Linux.

[direwolf20]

Why is the sibling comment about Windows [dead]?

[zbentley]

I don't know. I vouched for it (as I did for GP to start this thread) just now. It's from a sockpuppet-rhyming username with 0 feedback. I hope I'm not enabling some bad behavior that they're being marked dead for elsewhere.