Back in the early 90s the local university used to have a free dial-up that you'd connect to via modem and then could telnet anywhere. You didn't need to be a student or anything. As a teenager I used this to connect to various shell accounts I had around, and to various MUDs. (This was in the pre-ISP days -- there was nobody in my area offering dial-up Internet at all.)
At some point they pulled this and made it for students only. But they had a dial-up gopher service for campus information and library access that was actually a telnet session to a gopher client on a SunOS machine somewhere.
But they didn't disable the telnet escape character.
So for a few months back then the way I got Internet access was to dial into the gopher client, hit ^], close the session to the gopher client, and open to anywhere else I chose. Eventually they closed this hole, too, but it was glorious for a while.
Oh man, I have the same memory. Back in ‘92 or ‘93, in addition to the “^]” telnet trick, our local dial up gopher could launch vi sessions for sending emails which they hadn’t thought to lock down to prevent it from executing “sh”. Poking around in those university systems was my first exposure to Unix and I’d say pretty directly influenced my career path.
My roommate volunteered as the webmaster for a non-profit, and they had a little tool that gave him vi access but no shell access.
Apache won't serve certain files unless the permissions are just so, and he could not get them to fix them or give him a shell to do it himself. So he couldn't do his job.
I ended up telling him about the shell escape trick.
Ah, reminds me of using Slirp back on those dialup links to get a proper SLIP/PPP connection and TCP/IP over my regular shell account. Of course that hole to was closed eventually also. Though their first attempt at it was just blacklisting the executable by name which was quickly worked around but they wised up after that.
We had to ban the IP block for an entire university due to troublemakers, but the problem is that one of our regulars was from the same U. One of us happened to know about such a forwarding service, so we gave him the address after a strict warning and promise that he'd behave himself.
He was having a rough time, and nobody wanted to be the one to tell him he was going to be kicked by association, so it was lucky we had a workaround.
“The early 90’s” is coming up on 30 years ago. Do you even remember 30 years ago?
The sort of people who could do that back then generally had much better things to do with their time. And resources. When you’re dealing with idiots who only have access to dialup or their university computer lab, it doesn’t take much to stop them. It was just a bunch of 20 year olds trying to have fun. Not defense networks.
"At some point they pulled this and made it for students only. But they had a dial-up gopher service for campus information and library access that was actually a telnet session to a gopher client on a SunOS machine somewhere."
One key thing to know, is that typing a character with the Control key held into a CLI session (real or PTY) causes the TTY driver to receive an octet that looks like that letter ANDed with ~0x40. In other words—referencing an ASCII table—you emit NUL by typing ^@, BEL by typing ^G, and so forth. ^H is literally BS (the ASCII backspace character.)
Another key thing to know, is that old pre-PS/2 keyboards actually emit these ASCII symbols, or something like them, directly, when you hit the appropriate key; and also do the appropriate Control-masking in hardware. When you hit the Backspace key on an IBM Model-M keyboard, it's sending 0x08 down the line. When you hit Control+H, it's also sending 0x08 down the line. The computer receiving these can't tell the difference (and, in fact, does not receive KeyDown/KeyUp signals for the Control key. It's not a "key" as such.)
And so, what's happening with the author's "cheat sheet", is that there's some particular key on these keyboards that has 0x5D ']' as its scancode; and, despite modern keyboards no longer doing Control-masking in hardware, the author's Terminal emulator is doing it in software, translating the key-chord of "the key with scancode 0x5D" + "control being held" into "the ASCII symbol 0x1D" (that's GS/Group Separator, for those wondering) and emitting that octet through the TTY driver into the telnet client, which receives it and treats it indistinguishably from someone who had typed Control+] on a US 101-key keyboard.
Not going to lie: when I discovered that `^` means _control_ and that `^]` means _control-]_, I suddenly started making sense of a ton of manpages^H^H^H^H^H^H^H^Hdocumentation.
Then the `tmux` dude goes on and uses `C` instead of `^` [0]. God that was hard to figure out. But it gets worse: he continues to describe it as `C` even when he's not actually meaning _control_. No, that's just the _default_. He actually means `C` to mean whatever was bound to the configured "meta control". Uhh, at least, that's my understanding of it right now.
Tmux author (if you read this): I still haven't figured out why your software can't redraw lines. I'm continuously seeing garbled nonsense on the session from software clearing a line but tmux not actually clearing that line. `htop` works and looks great outside of tmux but inside of it? Oh god I can't read anything at all because it's all garbled.
But yeah, after learning that `^` means "press control", getting out of Telnet was eas....oh man I'm stuck in telnet stil.. Halp
> But it gets worse: he continues to describe it as `C` even when he's not actually meaning _control_. No, that's just the _default_. He actually means `C` to mean whatever was bound to the configured "meta control".
As far as I can tell, emacs[0] denoted control as 'C' first. The tmux docs most likely follow that trend. I'm only starting to learn emacs, so haven't yet come across any key combos that require a capital letter 'C' preceded by Ctrl. Will be interesting to see how that's represented.
I'm pretty sure it's a version + terminal + configuration issue.
I work in terminals all day long at home and work. I have a consistent user profile. On the other hand different operating systems have different terminals. I've seen the symptom occur locally (Ubuntu -> Gnome-Terminal -> bash -> tmux) and usually go away after an update of one of the components. But most frequently it occurs when crossing boundaries ({Windows, Fedora, Ubuntu} | {putty,gnome-terminal,tilix,serial tty} | tmux | literally anything). It happens more frequently when embedding tmux sessions while crossing those boundaries.
I _really_ wish there existed some software which would try to debug terminal display issues, even if it involved echoing something in a client program and then asking me "does this show up as intended and/or garbled?", with a timeout value for "it's so garbled that the user couldn't read or respond" similar to configuring a video display.
All the terminal emulators support xterm-256color and that's what the TERM is set to outside of tmux. The TERM inside of tmux (and ssh sessions inside tmux and etc) is `tmux-256color` as tmux is documented to want. I just wish I knew how to debug it.
It's only in the last few weeks that I've started noticing people using "C" to mean "Control."
I've used "^" for "Control" for at least 40 years.
And more confusing is that these days "C-x" is supposed to mean "Control X." But since I'm used to Control being ^, I read it as "Control-minus, followed by x."
The only thing missing is something to represent the excessive beeping that accompanies that moment!
My first foray into vi on an ancient Unix as opposed to Vim on Linux led to my manager at the time coming up behind me, startling the crap out of me and saying, "beep beep, what? You OK?".
Let's look at a typical novice's session with the mighty ed:
golem$ ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.
I suspect it may be down to the use of the Caret key on typewriters and teleprinters as a modifier on other characters. Often the caret was a ‘dead key’ that did not advance the carriage, so you could then type another character in the same location, which would be accented by the caret mark. If you wanted a caret by itself you had to then press the space bar. The control key is also used to modify the meaning of another key, and does not advance the cursor.
Don’t use Telnet to check a port. It’s overkill that puts you in the situation where you have to force it to abort because the server doesn’t speak telnet.
Netcat (based on the old Hobbit code) or nmap’s ncat are pretty universally installed. It just opens a socket and lets you type away until EOF (^D). Or you can just do “nc -v host port < /dev/null” (or just do ”-z” for non-ncat). Hilariously my phone doesn’t have backticks for me to denote those as commands.
I feel the pain. When you are switching platforms from anything to a Mac for the first time and your Mac Book comes with, say, a German keyboard, you will find yourself googling where to find all the different brackets you need for coding first thing as they are not printed on the keys. Judging from this article this seems to be similar for many other keyboard layouts as well.
I just did an image search, and you're right — no brackets printed on the keyboard.
I find this interesting, because back in the 90's I happened to be in Austria and I bought a German keyboard for the sole reason that it had all of the brackets on it, and the US keyboard I was using at the time didn't.
Keyboards can be so random. I wonder what goes into these kinds of decisions amongst keyboard designers. (I know there's an ISO committee for this, but we all know "standard" ≠ "best")
Fun fact: If you use muscle memory, coming from a German non-Mac keyboard layout to a Mac keyboard layout you'll end up constantly closing applications.
The combination for @ on non-Mac keyboards is AltGr + Q and on Mac is Alt+L. Now if you use your left hand to type @ the AltGr key is roughly where the Command key is on an Apple keyboard. Thus you end up pressing Command + Q: quit.
It's great fun when adding additional recipients to a lengthy email you are writing. Thank god for auto save and terminal buffers.
Which leads to the following question (for future language designers)...
How do developers in foreign countries, using keyboards with no '[' or ']' symbols on them, type square brackets '[]' for array notation, when they are using arrays, in any programming language that requires brackets for array notation?
For example, in C, ??( is [ and ??) is ] which isn't so bad, but then there's this:
// Will the next line be executed????????????????/
a++;
The answer is no, it won't, because ??/ is \ which means the next line gets pasted onto the end of the previous one, which is commented out.
But this all goes back to ALGOL, which had some important digraphs:
> Early versions of ALGOL predated the standardized ASCII and EBCDIC character sets, and were typically implemented using a manufacturer-specific six-bit character code. A number of ALGOL operations either lacked codepoints in the available character set or were not supported by peripherals, leading to a number of substitutions including := for ← (assignment) and >= for ≥ (greater than or equal).
I think square brackets are available in all (?) keyboard layouts, but they may not have dedicated keys.
On the Swedish layout, for example, [] are typed using Alt Gr (i.e. right alt) + 8/9. I know a few developers who use an English keyboard layout when programming, just to avoid contorting their hands for these awkward key combinations.
Great answers everyone! Thanks! (I aspire to be a future programming language designer (amongst too many other future aspirations!), so this information will be remembered into the future!)
I wrote a MUD client for VMS because telnet in VMS was so broken. However, I never documented the exit command (it was "Control-Y", not /quit or /exit. I got email for years saying it was impossible to quit MUDding. Eventually I just told people it was a feature.
The square bracket buttons seem like fairly fundamental characters to relegate to very non-clear three-button shortcut that isn't even labeled on a keyboard. I also don't see curly braces? Seems like an impractical keyboard layout, no?
{} are certainly not punctuation you'd find in a newspaper, but [] are—those are editorial parenthetical markers! How do your journalists subtly make fun of their sources if they can't type "[sic]"‽
There's some kind of typographical logic to it, like alt-t is †, alt-l is ¬, alt-shift-l is |, alt-/ becomes ÷, ? and ! get upside down Spanish-style, you can probably guess where ≤≥≠± come from...
Does anyone actually use a Dutch keyboard? It is something from Belgium? In the Netherlands, where I lived my whole life, I've never seen a Dutch keyboard. I've only seen US-English QWERTY keyboards.
Azerty is actually more of a French layout than a Dutch layout. Keeping in mind Belgium has three official languages (Dutch, French and German).
Azerty is pretty much the default in the non-IT world in Belgium. But, as for software engineering, everywhere I worked though they asked if I wanted qwerty or azerty layout on my machines.
I'd also recommend switching to qwerty as it's just more natural for programming than azerty. Plus I got up to speed (~130wpm) after just a few weeks of using it, so it's not a huge effort either.
On Linux, when I remap the keyboard to Belgian (setxkbmap be), typing ] is done with AltGr+the-key-two-to-the-right-of-P. At least on PC keyboards, ] is printed on this key, on the right as is usual for AltGr combinations. Exiting telnet is done with Control+AltGr+the-key-two-to-the-right-of-P.
When I set it to Danish, typing ] is done with AltGr+9, and exiting telnet is done with Control+AltGr+9. ] is also printed on this key.
Why is Mac confusingly different?
For testing:
telnet towel.blinkenlights.nl
Edit: if you think this is not a Mac-only issue, please elaborate...
The lesson here is that if you want to do programming-type work, use an English-friendly keyboard. Which should make sense because most popular programming languages are written in English (and 7-bit ascii to boot).
Either that or Belgians need a modernized keyboard with easy keys for popular programming language chars.
I was surprised so many international keyboards don't have brackets! Do software engineers in those language just remap those to accessible keys? It would be super annoying to use one keyboard at home and a totally different layout at work.
We have {}[], but for me they're a pain to type since it breaks my typing pace. When I was gifted an old laptop with US layout I saw the light and changed my desktop keyboard to US as well. When I started working my employer asked whether I wanted US of our local layout (I think 30% use US).
I'm using a US intl no dead keys layout, and can easily type our Umlaute (actually much easier than {}[]).
The mac belgian keyboard layout is worse than the standard belgian layout because it requires two modifiers to use square brackets instead of one.
There are indeed many programmers that use qwerty layout in belgium, but laptops with the ISO qwerty layout can be harder to get depending on the brand than azerty and convincing employers to buy one can be challenging.
It is never an issue except for weird control key combinations that are impossible to make. I think we should promote multiplicity keyboards layouts and input devices in general!
On many keyboards, ^] can be typed with ctrl-5. Also, ctrl-2 is ^@ (NUL), ctrl-3 is ^[ (ESC), ctrl-4 is ^\, ctrl-6 is ^^ and ctrl-7 is ^_, all of which can be hard to type on national layouts. Except for ^@, these correspond to the last digit of the character code in octal: ^[ is 033 etc.
The thing to remember is that it is "on several keyboard layouts" not "on many keyboards". The actual keyboards themselves are completely agnostic as to what the chords mean.
Should be "Dutch (Belgian)" or "Belgian Dutch". In the Netherlands, no one has such a keyboard, or any AZERTY keyboard for that matter (apart from the occasional imported Belgian or French person), it's almost entirely US keyboards.
It would actually be cool if somebody posted a patch to improve this. For example when you start it could say "enter the key sequence you want to enter to exit". Or it could adapt to different languages. Or just say "control-]"
For those who don't know about this, that's close, but a newline needs to precede the tilde: See https://linux.die.net/man/1/ssh and use browser find for "Escape Characters". I find this is one of those things that can pleasantly surprise people who have been using SSH for years without knowing about it. (Another one I see a lot is using the "authorized keys" to limit what command can be run with a particular key.)
(Along with the utility of force-closing connections, this is also why it can be surprisingly difficult to use SSH in situations where you want a low-privilege user to be able to access the shell of a remote system, but not immediately get up to crazy network shenanigans. SSH is actually too feature-rich for that use case, and this escape-character menu is an example of why; even if you somehow take control of the command line entirely, they can still start opening reverse forwards and doing a variety of other things. Very useful for reasonably privileged users, though.)
The tilde character can be surpisingly hard to type on some keyboards as well. I can't even figure out how to do it on my current keyboard because in place of the backtick/tilde key is the escape key. On a norwegian keyboard the tilde character is "dead", meaning you have to press the tilde character followed by spacebar to get it, and that might not work in situations like wanting to exit an SSH session due to... reasons.
That's how you gracefully shut down an SSH session, with the socket close initiated from the remote end (where the shell is running.)
\n~. is for gracefully exiting a stuck/hung SSH session (e.g. one where the remote isn't responding to input) without force-killing the SSH client itself (which might do bad things to the process group it lives in.)
Unfortunately not all Telnet servers support that.
Being the least interesting programmer on Hacker News, I don't always write code to handle Telnet-compatible ASCII input, but when I do, I always support ^D.
This is bizarre. I understand that not all keyboards are made the same, but why would a technical person not have a keyboard with square brackets? Perhaps one keyboard for writing volumes of text in his native language and another keyboard for doing technical work?
The French language doesn't use the standard quotation mark to indicate dialogue, but I would still expect a French programmer to have a keyboard capable of producing one.
" and ' are on the standard French (and Belgian) keyboards.
In general on European keyboards, letters like ê, å, ç, ñ, ß are more useful, so some of the punctuation only of interest to programmers and mathematicians ([], {}, ^, #, |, \, `, ~, _) is accessed using the AltGr (right alt) key.
Usually, the AltGr symbol is printed on the bottom right of the key (Shift+AltGr symbols on the top right). Sometimes only some of these keys are printed -- typical British keyboards print € on the 4 key, but not á, é etc -- although (of course!) they still work.
My point is that if you work with computers then probably is a good idea. Most special symbol usage is because of that and escape sequences are derived from those keyboards.
That's what the reset button on old computers was for.
In all seriousness can't you just Ctrl+C or Ctrl+Z and kill the process instead? Maybe there's something that prevents this that I don't remember, my shell game is rusty.
No, you can't, because telnet occupied the position SSH now does of remote connection to a shell on another machine. Your Ctrl+Z or Ctrl+C gets passed right through to control that remote machine, assuming you have a proper telnet server on the other side that negotiated the appropriate options.
Reminds me of being a first time user trying to get out of VIM while following a tutorial. How frustrating it was then!
If you have flailed around and messed with a file because when you type, it ignores your input until you use the 'i' character, suddenly you need to stop, close and reopen the file (because you don't know to hold the u key to undo). So, you do what works on DOS or nano, and hit Ctrl + C.
Someone coded it such that if you hit Ctrl + C to exit, instead of exiting out of VIM immediately, the editor writes a message that says "to exit vim, you must type :quit".
So you type that, and VIM responds with 'you have unsaved changes, please add ! to overwrite', so you type ! and it does nothing. After several seconds of confusion, you google how to get out of vim and the internet reveals the magic keystrokes ":q!" to finally get out of this dad blame file and get back to what you were doing.
All of that (probably, in my cynical mind) to avoid following the principle of least surprise and have Ctrl + C = close, discard changes.
I don't know what the fuzz is all about, any sane person would open a different console an just 'killall telnet'
Obviously this is a joke, but I have to admit that's usually my go to solution for those rare cases where I need to actually use telnet (to some tcp socket for debugging).
Did you not read the article? Keyboards can be very different depending on your region and language. The author shows a picture of an AZERTY keyboard. Even ISO layouts can vary per country/language. That's why macOS asks you to hit the keys to the left/right of the shift keys in an attempt to lookup your keyboard layout.
Actually, the keyboards are not different. The keytop engravings differ, but that's it.
There are really only a few actual physical differences amongst Model M/Windows and workalike keyboards. (i.e. I am not talking about things like Maltron keyboards.) Those are the differences between 101/104, 102/105, 103/106, 104/107, and 106/109 key keyboards.
Ironically, that's really all that looking at the keys next to the shift keys gives one. The 102/105-key and 104/107-key keyboards add a key at B00, in between the left shift and B01. The 104/107-key and 106/109-key keyboards add a key at B11, in between the right shift and B10. So it's possible to detect the number of keys somewhat by seeing what USB HID codes come down the wire for "next to the shift key".
But this does not tell the computer anything about what is engraved on the keytops, and is not sufficient information for determining, say, Dvorak from AZERTY. (It's not even sufficient for detecting the 103/106-key keyboard, whose extra keys are on row A.)
Since practically all keyboards are USB these days, one wonders why there isn't a standard to have the keyboard just report its layout and language and whatnot to the OS.
So? Monitor electronics (the panel) are the same, but the EDID chip in a monitor still describes not only things about the panel, but about the monitor itself, like its orientation or factory color-calibration, and in fact the make and model of the monitor. Why not have such a chip in other peripherals? They're not expensive. Many keyboards already have flash for firmware updates or remembering F13-F24 binds.
That is not an analogous situation. Keyboard layouts are entirely a software thing. Modern keyboards have zero knowledge of keyboard layouts. Their communications protocol does not deal in keyboard layouts. They effectively speak entirely in terms of ISO 9995-1 key positions and a big bitmap.
Entirely a software thing? Seems like ISO 9995 and its extensions don't specify anything about the top row of the keyboard (Escape, F1-F24, PrintScreen/ScrollLock/Pause, etc.)
I know that "media keys" (e.g. a Calculator button) aren't actually keys but another kind of USB HID device hanging out on the keyboard like a Touchpoint mouse; but F1-F12 keys really are keys, events sent from the same device that sends regular keysyms. Are they just random non-positional codes hiding out outside the ISO 9995 reserved range?
Yes, entirely. Function keys are not different to the others, and constitute row K. Nor are "media" keys, which are just more keys. Apart from one key, [Fn], they are all just bits in a giant bitmap, indexed by USB HID usage and (usually but not necessarily) partly encoded as an inverted array, on the wire. The keyboard layouts, in software on the host, define the meanings for all of them.
Exactly.
This is standard PC behavior (even older than IBM PC) for all keys other than a-z.
Control/shortcut keys are bound to the physical key, not to the regional layout characters bound to them. The displayed shortcut is often shown as the one for the US/UK layout.
As someone that often switches from US layout for programming to local layout for a few national characters, I'd consider any other behavior to be incorrect.
(People using QWERTZ/AZERTY might not agree/don't switch layouts that much. I'd be really annoyed if location for Ctrl+Z moved around... This is why standard key for Undo on PC was Alt+Backspace, which I still often use).
> Control/shortcut keys are bound to the physical key, not to the regional layout characters bound to them.
There's no reason that would have to change. If the OS was aware of both the key's physical location and what character it was supposed to represent it could easily keep the same physical mapping while simultaneously displaying the correct characters for that mapping.
Back in the early 90s the local university used to have a free dial-up that you'd connect to via modem and then could telnet anywhere. You didn't need to be a student or anything. As a teenager I used this to connect to various shell accounts I had around, and to various MUDs. (This was in the pre-ISP days -- there was nobody in my area offering dial-up Internet at all.)
At some point they pulled this and made it for students only. But they had a dial-up gopher service for campus information and library access that was actually a telnet session to a gopher client on a SunOS machine somewhere.
But they didn't disable the telnet escape character.
So for a few months back then the way I got Internet access was to dial into the gopher client, hit ^], close the session to the gopher client, and open to anywhere else I chose. Eventually they closed this hole, too, but it was glorious for a while.