(sorry about the long reply latency) On Sat, Feb 18, 2023 at 07:46:24PM -0500, Mouse wrote: > >> I think that input line editing, no matter how fancy, should be > >> invisible to simple applications, as invisible as erase and kill > >> processing is for applications that run in cooked mode today. [...] > > > Ultimately the problem is that teletypes are baked into the core > > architecture of Unix and all more sophisticated user interaction has > > been bolted on top instead of being redesigned in. > > I agree and I disagree. > > If by "teletypes" you mean "octet streams", well, it might be an > overstatement to say that "everything is an octet stream" is the > unifying concept that has made Unix Unix, but not by much. I'm not > sure I'd call that "the problem", though.
No, I mean "teletypes". The reasons we can't have real input line editing except as a bolt-on library are: - Real editing, as opposed to cooked mode, requires terminal control operations. But the abstraction in the kernel is a teletype, not a terminal, and it doesn't have any such concept as terminal control. Because termcap and then curses got bolted on top of the teletype layer, you can't have its concepts _in_ the teletype layer. - Editing also requires, or at least strongly desires, cursor keys and other function keys beyond typing single characters on a teletype keyboard. But similarly, because termcap and curses got bolted on top of the teletype layer, those concepts are not available in the teletype layer either. Furthermore, because input handling in curses has always been rubbish, the world is full of application code that does its own input interpretation; the situation is far worse than with output. - And then, completion and history are application-level functions, so they inherently can't be done in the teletype layer, or any other system-level input layer. Instead, the input read by the application has to have enough structure that the application can read and go "aha, the input layer has sent me this much and wants completions for the rest", or "aha, the input layer is asking for history entry 72, let me send it off". But because everything other than typing single characters on a teletype keyboard got bolted on top, there's no straightforward way to have that structure that doesn't interfere with other things that might be happening. - It only gets worse if you start considering that there might be other ways to produce input that have different semantics from typing (e.g. under normal circumstances if you paste you are intending to paste text and not editing operations; and also, input from dictation has different editing requirements), or additional functionality beyond completion and history (such as autocorrect). These reasons are obviously addressable -- at least some of them should have been addressed forty years ago or more, and it's been at least thirty since cooked mode became clearly inadequate -- but they require making fundamental changes. And that's just for input line editing for programs that are still basically using standard input. It only gets more complicated when you also have screen-mode programs and GUI programs and whatnot. And then, today the consoles of computers have a lot more functionality than typing ASCII characters. Quite apart from GUI programming and video, there's also pointing devices, stylus or other drawing-type input, assorted HID objects, stuff you plug into the front panel like scanners and cameras, and audio... along with stuff that Unix basically just doesn't handle at all like GPS/location services, accelerometers, or battery state. All of this ought to be available systematically as input to applications (or not, depending on permissions) rather than a mess of ad hoc devices and libraries. But that's not what we have; we have teletypes. > The very notion of a command line owes a good deal to that unifying > principle, it seems to me. I was never fortunate enough to use > interactive OSes designed without Unix available to draw on (while it > is just an assumption on my part that such exist, it seems likely). Well, there were quite a few; e.g. RT-11 and RSX-11 (which eventually grew into VMS), not to mention assorted mainframe horrors; plus the BASIC interpreter UIs of the 8-bit machines. I'm not sure where CP/M stood. MS-DOS ultimately had a notion of standard input, but I don't know/remember how early it appeared; but applications that had user interfaces tended to ignore it, just as they ignored DOS's standard output and wrote directly to the video card. Then there's MacOS Classic, but it never had anything resembling a command line of any kind. (Even today, Unix with curses or readline and whatnot is still, from the point of view of an application wanting to have a user interface and take input, largely a regression from the MS-DOS environment.) Anyway, one of the ways Unix was different is that the shell wasn't magic or privileged, and that does owe a great deal to the concept of standard input. > > By the time you fix it, it's not Unix any more. > > Depending on what the "it" is. If it's the octet-stream unifying > principle, then, yes, eliminating, or even substantially changing, that > will break what makes Unix Unix. > > But, if we assume the existence of an interactive command line? I'm > not so sure. You can certainly have a command line that's nothing like Unix. But that's not what I meant. What I meant was that by the time all of these input and console-related issues get sorted out into any kind of coherent abstraction-based design, the resulting abstractions are things Unix never had and work in ways Unix never anticipated. -- David A. Holland dholl...@netbsd.org
