versus a manager forcing you to fix the damn problem nobody cares whose fault it is.
of course this difference is not innate, just a tendency.
It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either.
Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit.
This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be.
Software business models have absolutely nothing to do with why you can't have key up events in ttys.
EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).
In the end, you'll be choosing between a platform that requires you update every piece of software you maintain every six months and a platform that doesn't. And while the former might seem better from a pure-ideals perspective, the latter is vastly preferable for actual usage. (That's why so many people use Windows, and it's why I now run Linux on my MacBook.)
And while Windows maintains near-perfect binary compatibility (I've run programs on Windows 10 that were last compiled a decade ago), Linux instead has excellent source compatibility. I've successfully compiled and used decade-old Linux utilities with no problems.
This difference speaks to the different economic philosophies these platforms have. Microsoft expects you to buy software in a box at a store and use it forever. Linux expects you to use free software developed by volunteers. And Apple expects you to pay over and over again to avoid losing functionality.
In practice this means that statically-linked executables from a decade ago will run just fine on Linux today, at least as far as interactions with the kernel is concerned (interactions with other parts of the system, it depends). The same is not necessarily true of dynamically-linked applications because user-space libraries' maintainers are not as exacting about backwards-compatibility. Note that this is not an argument for static linking, at least not in its current form.
One problem with doing this is that the only reason anyone uses Linux is to run programs that are currently out there. If Linux started to make breaking changes like this, people would switch to some other operating system that didn't break their software.
Sure, lots of people use macOS, and macOS breaks a bunch of APIs every year. But macOS users also buy expensive recurring subscriptions for every app they use, so Mac software companies can afford to employ developers to clean up after Apple every year. Linux doesn't have that; a lot of Linux software is either unmaintained or maintained by volunteer developers in their spare time.
I don't know about this mythical "one", but I can. I just see no reason to fix it.
It is not so hard to make a patch for a /usr/src/linux/drivers/tty/vt.c to make it accept one more esc-seqeuence which would switch terminal into special state, when terminal will send keyup and keydown escape sequences instead of raw-keys for each keypress. A week of tinkering with vt.c and viola, terminal can send keyup and keydown. (Plus maybe one more week to decide how to encode keyups and keydown the best, so ideally terminal would be useable even after wrong esc-sequence sent to it in the wrong time).
The right question is: and what? Why might I wish to do this? I might invent some application for this new feature, but I'm pretty sure I couldn't invent something useful what can't be done without keyup event.
In most of those cases, because of the historical precedent, these libraries/runtimes don't even have a concept of "keyup" for their TTY-like abstraction, so adding this to them may entail a bit more work than it sounds—especially if, like the JVM, they have a static interface/protocol built in to specify the API of a "TTY-like object", which cannot be changed, since third-parties have compiled code against it and expect that code to remain ABI-compatible with new versions of the runtime.
No. You miss the point. I need to do nothing. I have no reason to do anything. Give me a reason and then we can discuss what I need to do. I need a rationale to do something, without rationale my work would be pointless and you might argue indefinitly that anything that I've done already is not enough.
"This", in that phrase, stands for the problem in the OP post title—"it being so hard to detect keyup event on Linux."
And "on Linux", in the OP post, is a shorthand for "in all the arbitrary applications that exist in the Linux userland, or that one might choose to write in the Linux userland." (You can tell that it has this meaning, because under the more literal meaning of "on Linux"—working within the Linux kernel itself—it is already quite easy to detect keyup events.)
Obviously, fixing the entire Linux userland is an unbounded amount of work. That is precisely why the other commenters above are saying that it cannot be done. Not "done" as in "worked upon", but "done" as in "finished."
The nice thing about escape sequences is that they are ignored if not understood.
> Microsoft can't fix this either (in Windows
Because it's not an issue in Windows? The Windows console, as primitive as it is, supports monitoring the status of the keyboard (which can be used to infer key up events).
This is not what I find when I press my arrow keys in a container terminal set up with no TERM variable. I get funky characters spewed across the input line.
The problem with having the terminal emulator implement it is getting the terminal emulator to know when to insert these new key-up escape codes into the psuedo-terminal. The terminal emulator shouldn't send them to the psuedo-terminal when it's in raw mode, because every existing program that runs in raw mode won't know what to do with them. And inserting them into a cooked mode pty simply makes no sense. So it becomes clear that the terminal needs a "rawer than raw" (still bleeding?) mode, and some way for the program requesting bleeding mode to communicate that desire to the terminal emulator. Right now, that's not how the whole stack works. A program tells the psuedo-terminal (kernel) whether it wants raw or cooked mode, that's not something that terminal emulator is involved in.
You could potentially have a terminal emulator that accepts a proprietary "toggle bleeding mode" escape sequence, at which point the terminal emulator starts inserting key up escape codes into the pseudo-terminal which it assumes has been placed into raw mode appropriately. There's not really any technical reason this couldn't be done, but there's a strong "nobody needs this" social reason for why it hasn't been done. Sure, if you want responsive controls while play aalib quake in your terminal emulator across ssh, you'd want this. But who does that as anything other than a gimmick?
I've actually outlined in this thread how to implement key up events, if that really was desired, in ttys, but I argue there's no real demand, and it won't happen. And it is impossible now in the sense that... the functionality does not exist.
Incidentally if you ssh into an untrusted system using iterm2 (or otherwise get foreign escape codes going into iterm2, for instance if you cat the wrong file), I believe it's possible for that system to drop files into your ~/Downloads/ directory without prompting you.
It could be worse though, there used to be terminal emulators you could exploit by setting the title, because they weren't bounds checking correctly.
I don’t know what there is to tell about displaying images. There are terminal emulators that can display images inline when a program emits the image data properly.
I don’t understand your final sentence. How does it make sense to say that it’s impossible because it doesn’t currently exist? That’s like saying it’s impossible for me to drive because I’m not currently in a car. You didn’t say that nothing currently supports it, you said “no one can fix this.”
> So, yes, it's absolutely impossible to get key up events in tty context, and at this point it will almost certainly stay that way forever, as it's too late to retrofit terminal emulators, drivers, and applications to understand whatever protocol for communicating key up events. (The right way to do this would be to develop an escape sequence protocol that the tty/pty drivers could decode and turn events into out-of-band events to be delivered via ioctl()s, that way applications that don't care about key up events don't see them and don't need to be modified. But who is going to do all that work?)
So "it's impossible [right now]" and "it can be done" but "it's not gonna happen". Is that not a fair summary? Perhaps we can disagree as to the last part.
EDIT: Ah yes, further below I wrote this:
> Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all).
> It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either.
That's overbroad, yes. The fix I outlined is not as much as boiling great lakes.
Ah, but can terminology render tektronix vector graphics? :)
It's been solved twice, but I'd like to get that down to just once :)
https://sw.kovidgoyal.net/kitty/protocol-extensions.html#key...
The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling.
If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.
Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
The general statement I made was that VS is slow and that it has bugs. I also know from my own experience that this was more true in 2011 than it is now. I still don't like it.
That's one aspect, sure. The rest of Windows is a mess as far as programming goes, especially once you leave the simple case of "Oh I'll write everything how Microsoft currently prefers and hope it doesn't pull another COM-to-.Net again, pulling the rug out from under my whole ecosystem."
It doesn't sound like you do Windows development? Batch files are hardly at the center of it. Things just work differently over here, and if you're gonna insist on doing things the way you're used to then there's going to be corresponding friction, just like I would if I tried Linux's GUI dev tools. Though even the CLI friction on Windows is far less now that WSL has come around. (Though PowerShell's been around for a while, which you somehow omitted.)
I do, although I have only done it part time for about 16 months. And I don't do business software. I'm working on a compiler in my spare time, and on an industrial dashboard for work. Both are written in plain C (plus OpenGL and FreeType for the latter) and run under Linux as well.
Command window and batch files are still way more productive for me than using a pile of junk that I don't understand, hidden behind an IDE that I cannot automate.
Detecting key-up fits that category. It isn't a big deal, and hard to make it happen, so it won't happen (and in this case maybe it shouldn't)
1) The programmer does not need to synchronize with the results displayed on screen. That's because the command-line is technically not that interactive. Input is coming from a serial line. As long as the programmer knows by heart the state transitions that his previous inputs will effect, he can simply continue typing without caring if the effected state is already displayed on screen. This is serious because typical systems can often not keep up with user input since processing is jerky and many operations simply take a certain amount of time. But GUIs with their focus based input model absolutely require that the state is updated on screen before the programmer can continue with inputs. The interpretation of inputs in GUIs is a function of the on-screen state (besides the user devices' inputs).
So the serialized nature of command-lines not only saves time, but significantly reduces the stress induced upon the programmer.
2) All operations that the programmer knows how to do "interactively" can easily be combined in a script for automation.
Both points are arguably missing from IDEs. The only ad
It won't work properly, and you'll constantly be screwed over by it, but hooray, you've got "paid software" which your boss knows was able to "fix the damn problem" so there's no point even saying it can't be done, even though it can't be done - after all they paid good money, and whoever heard of a manager spending good money on a product that doesn't work...
Most of you have probably used software built to this philosophy, a lot of the middle boxes for example. Most anti-virus software. Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it...
Some of those products actually worked. They compressed RAM instead of paging it to disk. Which was a net benefit back then, and often still is.
Similar techniques are in use in modern Windows, macOS and Linux.
Those RAM doublers fixed the "damn problem" so well, that the implementation of them now lives in Linux AND macOS kernel and is enabled by default on all Macs, Android phones and several other devices.
So I think the "fix the damn problems" mentality actually works.
It is not a difference between FOSS and paid software but more about context: is fixing more important than consistency?
Most FOSS is actually written by paid programmers, with grumpy managers who want that impossible problem to get fixed. If anything, the issue is that it is not always pushed back in the main line, sometimes for good reasons.
https://docs.microsoft.com/en-us/dotnet/api/system.managemen...
It can also be too late to fix something in a deployed system because the resources required exceed the benefit derived in which case there will be no manager forcing anyone to fix anything.
Anything relates to FOSS if it gets people riled up and makes the thread longer.
All I'll say on this matter is that I find your views surprising, and we'll leave it at that...