9 ms·
Every time my terminal blows up because I wrote some binary data and I have to run `reset` or `stty sane` I'm amazed that we let things get to this point. Frank
by andrewla 3y ago
Every time my terminal blows up because I wrote some binary data and I have to run `reset` or `stty sane` I'm amazed that we let things get to this point. Frankly I'm surprised that there are not significantly more vulnerabilities.
Even things like the use of ESC, and the overloading of ESC for the actual ESC key, for a signal for keycodes, and for the ALT/META key are crazy.
I've thought for a while that I should implement an extremely reduced set of escape sequences which use a non-ESC character (maybe SOH or something) for control sequences and key encoding. A minimal set -- color / cursor position / save-screen / query-size -- whatever it takes to make vim/emacs + tmux/screen work, and call it a day.
- candiddevmike 3y agoI don't know what magic combination it is but I keep hitting something on WSL2 and Windows Terminal that makes my session freeze into a blinking cursor. This results in me having to close the current tab and start a new terminal session completely. We're still inventing new ways of breaking arguably the most basic user interfaces.
- _a_a_a_ 3y agocontrol-Q and control-S freeze/unfreeze the output stream (can't remember which is which). May be that?
- candiddevmike 3y agoIt doesn't seem to be that, I can't even reliability reproduce it. I originally thought it was something with the right control or right alt, but it's not consistent.
- jstanley 3y agoI keep doing this in gnome-terminal, and for years I was confused about what was going on, I thought it was a bug, but I found out what it is! It turns out there is a "read-only" mode, with some keyboard shortcut that I was triggering by accident. You just have to right click in the terminal and uncheck "read-only" to get it back.
- audidude 3y agoDunno how long it's been since you used it, but I believe keybindings for this are disabled by default now and you have to toggle them on in your profile preferences.
- orev 3y agoProbably CTRL-S, which is the software XOFF flow control. If so, CTRL-Q sends XON, which will un-hang the session and resume data flow.
- sillysaurusx 3y agoAh yes, CTRL-Q, the most intuitive keybind for resuming a frozen terminal after pressing CTRL-S, the least likely combination to accidentally be pressed while typing.
- estebank 3y agoIt's mnemonic! [S]top and [Q]ontinue :o)
- bee_rider 3y ago[Q]ontinue was the next best option, c is already taken up to [C]ill the current process obviously.
- MenhirMike 3y agoReminds me of the game NetHack. How do you consume a potion? Well, you [q]uaff it, of course!
- layer8 3y agoThey really should have switched the latter with Verti[k]al Tab.
- bee_rider 3y agoCTRL-whatever does something funky often enough that I only hit CTRL on purpose.
- peterfirefly 3y agoStop/Qontinue.
- 3y ago
- pjmlp 3y agoTerminals in UNIX systems are anything but basic. Windows terminal takes it to the extra level by supporting two OS terminal models. Terminals in non UNIX, that not pretend to be serial printers, like the Amiga DOS, or plain MS-DOS, those are the basic ones.
- veilrap 3y agoWindows might even support 3 if you count cmd and powershell separately :lolsob:
- jcotton42 3y agocmd and powershell are shells, not terminals.
- vidarh 3y agoThe Amiga terminal is simple in some ways, but it supports stuff most Unix terminals, won't, such as the ability to shift the text positioning by individual pixels in both x and y direction, which was of course promptly "abused" to draw bitmap graphics (exceedingly slowly) to the terminal.
- kryptiskt 3y agoMS-DOS had ANSI support with ANSI.SYS [0], that support never got into Windows NT's CMD.COM. [0]: https://en.wikipedia.org/wiki/ANSI.SYS https://en.wikipedia.org/wiki/ANSI.SYS
- pjmlp 3y agoYeah, but that is a device driver, not part of the command.com itself.
- JdeBP 3y agoYou are conflating and confusing several different things, including what operating systems even had a terminal paradigm. Windows NT started out with a "console" paradigm, like OS/2 before it, not a "terminal" one. And command processors like CMD are not what provide the "console" parts of those systems.
- ElectricalUnion 3y agoIn theory, `reset`/`tset` from ncurses, or an equivalent, is this "thing" that programs are supposed to be using when they need to engage in terminal shenanigans. Those use TERM/TERMCAP environment variables and some educated guessing reading stdin/stdout/stderr behaviour to figure out what terminal you're using, search for said entry in terminfo/termcap database, and finally invoking native terminal behavior or simulating it with other terminal behavior. In theory, one could "just implement" an alternative terminal, and put said simplified entries in terminfo/termcap database and things will be all fine. In practice several of those ANSI escape code behaviors are hard-coded and everyone pretends everything is "at least as capable as xterm" (a oxymoron, given that xterm is one of the most capable and feature-rich terminals around), so you're also gonna have to implement a converter from "xterm ANSI" to your alternative terminal system - sort of how winpty does convert Win32 terminals conventions to ANSI ones. Then we're back to the starting issue in this converter.
- andrewla 3y agoYes, this is one of the avenues that I've chased down a bit. One problem is termcap/terminfo itself. The definition has expanded greatly over time, and documentation is poor to non-existent. In many cases termcap/terminfo has been implicitly extended to support ncurses specifically. And like you say, everyone just sort of assumes ANSI/xterm -- nobody has `PS1="$(tput setaf 3)\w $(tput setaf 0) $", you just hard-code the codes. The last time I chased the rabbit down this hole I got mired in TTY-land and was not able to dig myself out. Too many insane layers, and before you know it you're writing code to emulate serial connections in a vain attempt to make things work without burning the whole world down. Both (n)vim and tmux have internal TTY emulation as well which makes things even crazier; I think vim uses libvterm and tmux has one internally hand-coded. It's a mess.
- db48x 3y agotmux, screen, emacs, and vim all have terminal emulators in them because it’s required, not because they’re crazy. Consider a really simple case. You are using screen (or tmux, or emacs, or whatever) and you have your terminal divided in half so that you can use a program in one half and tail a log file in the other. The program sends a ^L to clear the screen. Screen (or tmux or whatever) must read the ^L and then _not_ send it on. If it sent it on, the whole screen would be cleared, not just the half with the program in it. Instead it has to send whatever control sequences would erase the text from just the right portion of the screen while leaving everything else alone. Virtually everything sent by the program(s) has to be intercepted and reinterpreted in order for it to work right.
- IshKebab 3y agoYes, the terminal is an embarrassment. It's telling that Sixel is state-of-the-art. A format from the 80s designed to support dot matrix printers.
- blueflow 3y ago> and the overloading of ESC for the actual ESC key What else was the ESC key made for if not the control code? > I've thought for a while that I should implement an extremely reduced set of escape sequences which use a non-ESC character (maybe SOH or something) for control sequences and key encoding. A minimal set -- color / cursor position / save-screen / query-size -- whatever it takes to make vim/emacs + tmux/screen work, and call it a day. I did that as a 8086 boot sector and it would render tmux with unicode characters stripped. You need surprisingly few sequences.
- silon42 3y agoOn a modern PC, Esc key is Esc key... whatever the application wants to use it for (99% time, cancel some UI operation). To me it's insane that one of the most used key command has a 1 second delay in the terminal. Or that typically Esc + some function/arrow key results in some junk.
- blueflow 3y agoIf you type in junk into the keyboard, junk is what you get on the screen. I see the fault with the developers that overload the keys for existing control characters with a different meaning. > whatever the application wants to use it for With the application being a terminal emulator, that is emitting an ESC character.
- bityard 3y ago> one of the most used key command Found the vim user! The vast, _vast_ majority of Unix command-line or text-based programs do not use the Esc key because they were not written with a particular terminal or keyboard layout in mind. (Unlike vim.) But for whatever it's worth, I use vim every day and I notice no 1 second delay when switching modes with the Esc key, so perhaps this is something you can configure in your terminal.
- mfontani 3y agoCtrl + [ instead of Esc gets one back into normal mode, with no delay Takes a while getting used to it (I still haven't)
- bityard 3y agoHmm, which terminal? I remember catting binary files to the terminal used to hose things up pretty good, but any decent terminal emulator seems to have made that not a thing in recent years. I just did `cat /bin/*` in Konsole and it left me with a perfectly good prompt.
- db48x 3y ago> Even things like the use of ESC, and the overloading of ESC for the actual ESC key, for a signal for keycodes, and for the ALT/META key are crazy. It actually happened the other way around. The escape character was originally only there as an escape character at the start of a control sequence. It was added to the keyboard back in the teletype era specifically so that the operator could control the behavior of the device on the other end. And it was labeled “Alt Mode”! See <https://upload.wikimedia.org/wikipedia/commons/2/23/TTY33ASR.jpg https://upload.wikimedia.org/wikipedia/commons/2/23/TTY33ASR...>, though it is a little blurry.
- jandrese 3y agoTerminal behavior dates back to a time when everybody was just making stuff up because there were no established standards or even conventions. What standards we have are mostly just whatever the most popular or longest lived company did. Terminals are in a bad place because there was a whole lot of effort put towards compatibility instead of standardization. The same curse that email suffers under. So the "standards" end up hopelessly complex and also terribly vague because they're trying to support every dumb thing every single company did at the same time. And the worst part is that most all of those companies would cease to exist in short order afterward, so the system is chock full of bug-accurate support for long dead systems that literally nobody uses anymore.
- JdeBP 3y agoWell, yes and no. ECMA-48 is an established standard, and dates from 1976. The standards in use today have been around that long, long enough even that terminals that aren't ECMA-48 compatible are exceedingly rare nowadays. So it's really the reverse of what you state. There has been a lot of effort put into standardization, and compared to the 1960s we are highly uniform in the 21st century and widely adhere to an almost 50-year-old standard. It's not the long-dead systems that spoil this. As evidenced from the headlined article, it is the still active systems adding things like vendor-specific commands for setting titles and clipboards and colours and displaying images and whatnot that have introduced the complexity. A strictly ECMA-48 only emulator doesn't have even half of the problems mentioned in the headlined article, because the control sequences mentioned are extensions to the standard introduced by various GUI terminal emulator programs.
- ComputerGuru 3y agoIf you use fish, that should never happen. (If it happens, we would consider it a bug.)
- dgl 3y ago(Author here.) Unsure how fish can fully protect from this, as if you run "cat" in fish, then it isn't between you and the terminal anymore? Or do you mean fish should do a reset before displaying each prompt? If I run the printf commands from the "flash.c" example in fish I end up with a messed up terminal.
- ComputerGuru 3y agofish maintains its own tty state and pushes/pops it each time control is returned to fish or fish shells out to another process.
- dgl 3y agoThat's still only best effort, for example it will depend on the terminal but it doesn't reset things like xterm's control keys send escape sequences property, so: printf "\e]4;1;?\a\e[>4;2m" In xterm+fish will result in a messed up shell which you can't escape from (as ^C to clear the input doesn't work anymore).
- ComputerGuru 3y agoCorrect, it only handles prevents the basic kind of borked that can be reset with `stty sane` or `stty reset`.
- 1vuio0pswjnm7 3y ago"Every time my terminal blows up because I wrote some binary data and I have to run `reset` or `stty sane` I'm amazed that we let things get to this point." Rather than reset or stty sane, I use something like one of the following, based on what software is available, e.g., there is no reset on NetBSD echo w1b63|ired -n /dev/stdout echo 1b63|xxd -p -r echo -e '27\n99\n'|nc-data -g printf \\33c
- JdeBP 3y ago> Every time my terminal blows up because I wrote some binary data and I have to run `reset` or `stty sane` I'm amazed that we let things get to this point. Every time that your terminal emulator does this in response to binary data, wonder why your terminal emulator hasn't taken the very sensible route that was taken by the authors of mosh years ago, to simply not support alternative GL and GR character set switching, treating it as something whose time has passed given that we live in a UTF-8-to-the-terminal world nowadays.