5 ms·

> Those who don't understand Unix are doomed to reinvent it, poorly. Let's avoid hollow arguments to authority that preclude any interesting criticism or discu

> Those who don't understand Unix are doomed to reinvent it, poorly. Let's avoid hollow arguments to authority that preclude any interesting criticism or discussion. Unix has its fair share of flaws. > it's important when changes in presentation take effect. [...] They are just not independent streams, period. Not independent, but separate. Your argument would also apply to stdout and stderr - these are separate even though not independent. ioctls could very well apply to a specific position in the data stream instead of being immediate. And if you don't like ioctls, there could well be a third output fd instead. In that case, the synchronization problem could be solved with a "barrier" feature. Can we at least agree that the actual terminal protocol situation as it is now quite frankly sucks? The poor documentation and completely inconsistent implementations have caused me quite some stress.

jstimpfle 10y ago
> Let's avoid hollow arguments to authority that preclude any interesting criticism or discussion. It's not an argument. It's just a category for the rest of the comment. > Not independent, but separate. Your argument would also apply to stdout and stderr - these are separate even though not independent. No - technically they are completely independent. There is no ordering or interleaving or association defined. Actually stdin/out/err are nothing but conventions introduced by the shell. > ioctls could very well apply to a specific position in the data stream instead of being immediate. The general idea of a stream does not include positions - they don't have a clearly defined beginning or end. Streams are not like files on a filesystem, which do indeed have a size and can be indexed. Stream positions are another specialist concept that eases development for some apps or environments, but gets in the way of development of general purpose environments. > Can we at least agree that the actual terminal protocol situation as it is now quite frankly sucks? The poor documentation and completely inconsistent implementations have caused me quite some stress. Frankly there are not many problems with Unix terminals. They are quite simple. As Unix in general they just won't keep you from shooting yourself in the foot. Job control is hairy, though, but mostly because it's an ill-defined problem. In particular there was never a good agreed on mechanism for starting processes in independent environments. Systemd might have solved that to some degree (not a systemd fan). The situation with incompatible instruction sets (escase sequences) has also dramatically become better, partly because there are libraries like ncurses, partly because pretty much everything is VT100 compatible these days, partly because we have GUIs for complex graphical specialist applications. If you have a concrete problem - get in touch with me and I am happy to help.

jstimpfle 10y ago

> Let's avoid hollow arguments to authority that preclude any interesting criticism or discussion. It's not an argument. It's just a category for the rest of the comment. > Not independent, but separate. Your argument would also apply to stdout and stderr - these are separate even though not independent. No - technically they are completely independent. There is no ordering or interleaving or association defined. Actually stdin/out/err are nothing but conventions introduced by the shell. > ioctls could very well apply to a specific position in the data stream instead of being immediate. The general idea of a stream does not include positions - they don't have a clearly defined beginning or end. Streams are not like files on a filesystem, which do indeed have a size and can be indexed. Stream positions are another specialist concept that eases development for some apps or environments, but gets in the way of development of general purpose environments. > Can we at least agree that the actual terminal protocol situation as it is now quite frankly sucks? The poor documentation and completely inconsistent implementations have caused me quite some stress. Frankly there are not many problems with Unix terminals. They are quite simple. As Unix in general they just won't keep you from shooting yourself in the foot. Job control is hairy, though, but mostly because it's an ill-defined problem. In particular there was never a good agreed on mechanism for starting processes in independent environments. Systemd might have solved that to some degree (not a systemd fan). The situation with incompatible instruction sets (escase sequences) has also dramatically become better, partly because there are libraries like ncurses, partly because pretty much everything is VT100 compatible these days, partly because we have GUIs for complex graphical specialist applications. If you have a concrete problem - get in touch with me and I am happy to help.