[masklinn]

> I honestly have no idea what you are talking about. The whole point of standard i/o streams is for them to be portable and composable by other programs without those programs having to be designed to work with yours.

His point is that two streams are not enough, you don't want to present the same output stream or a human, a logfile or an other utility.

> And what 'formatting markup'? There is no 'markup' on a terminal, unless you're dealing with colors or something

Right, so there is markup on a terminal.

> which you would disable if your fd wasn't a tty.

Which would be much simpler to handle if there was a stream for human consumption and one for piping

> And why would you send 'headers' to a completely different file descriptor anyway?

Because headers are useful to human users or when capturing output in a file to read later rather than in an other utility?

[peterwwillis]

In practical terms, everything you mention should be done by different programs, not one giant monolithic subsystem that manages 10 completely different tasks. Each component should be reusable, independent, and interoperable. Not tied into one program.

In your program's design, the 'cat' program would handle all kinds of file i/o, provide some kind of ncurses text GUI to select a file, a progress bar for the progress of text flowing through it, sending errors to a logging subsystem, storing header metadata in some object passed along its output streams, etc. The Unix designers had dealt with this kind of crap before, and were sick of it, and so they wrote a program which did only one thing.

What you describe is the systemd school of design. If I just make my program more complex and technically superior, i'll have a better program. Who cares that nobody wants to use it, or that it's burdensome, hard to extend, difficult to understand, and incompatible with everything that exists today? Who cares if we can already do all these things without all the downsides? Technical superiority trumps practicality. Well, that's not Unix.

The Unix environment flourished not only because it was widely available, but mainly because it was incredibly efficient. By removing all the things they didn't need, they made the system better. There are four words that accurately express all of this, and that should guide the development of any Unix tool:

Keep it simple, stupid. https://people.apache.org/~fhanik/kiss.html