You wouldn’t believe how common it is for people using Emacs in a terminal to bump up against the limitations. Assigning a key binding to M-[ is a particularly bad idea (<https://emacs.stackexchange.com/questions/68703/m-causes-ema...>)!
the idea of your program not doing graphics, but instead invoking and interacting with a simulated model of a teletype (a device nobody born after 1990 even knows what is) so then the graphics stack can render its behavior to screen is completely asinine, like on the "anyone who uses this in their work should be fired" level.
i could never decide what's stupider, this or the C language. both were obsolete 30 years ago. yet diehard patriotic nostalgia tripping nerds who have no idea how software engineering works but just want to learn complicated things to look cool fought tooth and nail to keep this crap alive for decades. whenever someone says "the UN*X way", they really are saying, "I designed something modularily, you could have never thought of that", but what it really means are all these insane nonsense ideas that don't even begin to make sense, like:
-a filesystem centric security model that doesn't even begin to address real world use cases
-C
-ad hoc encodings that never mattered like octal, everything being a int<my machine word size>
-*sh
-perl, tcl
-terminal emulators
-DNS
-all these shitty little tools that compose horribly, like sed, where you have to pass --sandbox to make up for the fact that it indeed composes horribly
-web and email, which are thoroughly embedded in UN\*X influence, and ergo, suck big time
-X.509
i have
It's not about "open source", it's about compatibility. Changing the terminal text protocol is akin to changing a public API and would break programs. Actually, it's worse than changing a public API as you get no error and either nothing happens or the wrong thing happens and there is no good way to signal versioning (you can do some communication in "raw mode", but in the default buffered/cooked mode you can't really).
Almost all your gripes are about compatibility, really.
why does the console (it should be called console, as terminal refers to a setup that was obsolete 30 years ago) not have a proper input line? why does pasting a newline make it run? i should be able to type a command and edit it in a line that is a separate UI element from the text output. there is no compatibility argument here. only 0.001% of programs actually need to do anything other than be run and output text (and just text, not escape characters that do funny stuff). there's no dilemma that you love to imagine where changing it to work this way would cause massive incompatibility problems. we could even just make a new console called dumbtextconsole that works this way
viewing some logs from the shell is annoying as hell because the input goes into the program and once the program exits the shell runs whatever you typed. this is obviously a bad UI design. you will always have this stupid invisible buffer that you have to keep track of in your head the number of times you accidentally typed a letter there. if you ssh or tmux in, then you are more likely to enter bogus characters by accident when mistyping a command to ssh/tmux. the argument that its needed for compatibility is still moot if you only want a console for running commands. you dont need those interactive commands either. those are the most bogus hacky scripts that serve no purpose. i dont need a terminal to edit files either, that can be done with a proper GUI that runs outside the console.
it's also a security vulnerability the way shell input works. since you might paste something with a newline on the end and it will automatically execute. the idea that you should be responsible for what's in your clipboard is just bogus. you are resorting to some ad-hoc philosophy to argue this. if there was simple a proper input line where you pressed enter to run it, this wouldn't be a concern.
that one python shell.. Dreampy does this, no problem. the insane user who thinks it's a thing for some function to hijack random parts of the terminal[1] has his program break, and the rest of stuff just continues to work
this post also answers the "there are no alternatives" hackjobs in this comment chain. clearly there are alternatives, i just stated some, and once you follow this line of thought it actually leads to an entirely different OS (duh, why did i even have to state this, oh yeah, because you're disingenuous hackjobs). the fact that these people have the audacity to claim that UN*X, which is a absolutely highly specific way of designing things, that would never happen in isolation, is the only way to design an OS, proves how big of an issue this is in the software industry.
1. the insanity here being obviously that once you change random attributes about the global shared state, you have to assume other programs don't get the same idea as you and do stuff in conflicting ways
BTW, those terminal emulators, Perl and the tools allow you to easily debug your IoT device over serial.
The terminal issue it's about configuration; some of them allow mouse actions, such as XTerm.
Unfortunately, the IT industry seems to have at some point decided that UNIX and C are somehow fundamental to computing, and the only way forward is to build more and more layers of abstraction on top of it.
The most depressing thing is that even "indie" OSes buy into this garbage (Serenity, Redox, ...). Yes, you get tons of (crappy) portable software that now runs on your platform for free, but at the cost of being stuck with a lowest-common-denominator API.
It’s a sincere question, because I also believe that user interfaces could be better and there is a room for discussion, but ggp only enumerated observable downsides without explaining how to transform them without losing functionality. Maybe I’m thinking in-the-box, but how could I e.g. control process groups if a terminal was just a canvas and some app wouldn’t support C-z? Or if a process group is also “UNIX”, then what’s the alternative to, well, a group of processes? The initial comment brings many questions without mentioning anything that could at least direct the line of thought.
For tiny games (and applications) in these machines, SDL ran everywhere, so most 320x240 and 640x480 ran on these embedded machines. Uberportable, fasts an dedicated UIs existed such as the GP2X menu. Thank libre software and Unix like OS and libraries for that. SDL and framebuffer based software exists, such as PDF readers and video players. Thus, you could design an electronic billboard for ads in the streets/subway with very little and a ridiculous power cost, being the big screen the most costly component here.
Back in the day, for SCUMMVM (Lucas Arts adventure games) they used tons of Unix utilities to generate the engine and data handling, they saved lots of hours on engineering. The same happens today. These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.
UN*X does not have anything that makes it inherently performant in contrast to a sanely designed OS with one language instead of 10 that all do the same thing, a terminal emulator which is by design non performant, and a bunch of text formats that are also non performant and have bad semantics
> These small tools, with little preparation (The AWK programming language, man ksh, "perldoc perlintro"...) can do in days what for the programmers of non-Unix OSs took weeks of clumsy Python hacking.
no, it really can't. if you are string flinging on such a high level, your code is broken to hell. the reason perl awk bash sed suck so much is that they are intrinsically insecure the moment any input anywhere can be controlled by an adversary (and just wonky and gets in the user's way without even talking about security). working around that requires extreme levels of discipline that go far beyond programming in a real general purpose programming language (java, C#, ML, Pascla, Ada, etc). the moment you are able to write a secure *sh program, you are spending 3x as much time per line of code than in a real language.
>Perl/awk/sed suck so much...
Perl replaces awk, sed and sh and it's far better than python for system scripting. Python with whitespaces it's a clusterfuck.
>Secure sh program.
Perl has pledge(4) and unveil(4) support under OpenBSD from base. Far better than Java and C#. And I consider OpenBSD the correct BSD descendant following the best philosophies from Unix, even if I use Hyperbola GNU/Linux as a daily basis because of the freedom of sharing. And OFC a good bunch of OpenBSD tools are installed here, such as Oksh and sndio, doing proper audio mixing in userspace (and loopback monitoring, cool for WebSDR's and radio tools). Easy peasy. Try that with Windows.