From: Cameron Simpson To: unix-basics@yahoogroups.com Cc: Bcc: Subject: Re: why the arrow key does not working when telnet Reply-To: cs@zip.com.au In-Reply-To: ; from lindawu6@yahoo.com on Tue, Jan 15, 2002 at 12:07:52AM -0000 On 00:07 15 Jan 2002, lindawu6 wrote: | Does there anyone know that why the arrow key does not working when | telnet? Firstly, could you tell us in which applications they seem not to work, and what they do do (nothing, produce weird characters, etc)? Still, lacking this information there may be a few reasons. Firstly, the arrow keys and a few other special keys like PageUp etc do not send single character codes like the usualy keys (letters, so forth). Instead they send multibyte escape sequences. In order for them to work over a telnet connection: - the receiving end must be expecting them - the escape sequences sent must match the escape sequences expected - often, the characters must all get sent sufficiently close to each other Taking each of these points in turn: ---------- In most modern shells (zsh, bash etc) knowledge of the usual codes for the arrow keys is wired in and the keys will usually work all the time. However, most other applications which recognise these keys (vi, less, etc) do so by consulting a record in the terminfo database describing the "current" terminal. In this fashion these apps have worked happily for decades on a very large number of terminals from many vendors. However, it does mean the far end must know what terminal to expect. Type this: echo $TERM That should be the name of a terminal type, like "linux" for a Linux system console, "vt101" for most common terminal emulation programs (as found on Windows telnet clients etc) or perhaps xterm (the commonest UNIX terminal emulator). If it says "dumb" (a common default) or something equally unsuitable it may be that you must set it to the right value for your emulator. This is _supposed_ to be passed through transparently by your telnet client, but Windows telnets at least have traditionally not implemented this part of the telnet specification. To set this variable, say this: TERM=vt101 export TERM This is only an example, but that _vast_ majority of terminal emulators (including xterm, linux consoles, Gnome terminals, rxvt, Windows telnet etc) implement a superset of this particular terminal, so it's a fairly safe first try unless you know a better value (such as the value of $TERM _before_ you issue the telnet command, if you're doing so from a UNIX system). ---------- The second item refers to the fact that the arrow keys can be set to send a couple of different escapes. You can examine these sequences with the "od" command, like so: od -c Type that command at your prompt (inside your telnet session) and then type each arrow key followed by [Enter]. For example, for left, right, up and down respectively I get this: 0000000 033 [ D \n 033 [ C \n 033 [ A \n 033 [ B \n Note that you'll have to type all 4 before "od" gives you any output - it's waiting to fill up a whole output line (16 chars, which we happen to get neatly once we've typed all 4 keys). This output shows that I am getting "ESC [ D newline" (for left) and so forth for the other three. So my left arrow is sending "ESC [ D" (the newline is from pressing [Enter]). These are the normal sequences for these keys. It's worth checking. ---------- The third point about timing is a little esoteric, but sometimes applies. Telnet makes rather poor use of network bandwidth - in order to send the characters for immediate echo by the system you're telnetted to, pretty much every character will go in a separate packet unless you're a fairly fast typist. This is grossly inefficient. Therefore it actually hangs about for about 1/10th of a second after you type a character in the hopes of getting another to put into the stream. Also, the TCP protocol (which is what arranges for reliable delivery of your data) has to cope with dropped packets. On loaded networks the routers may discard packets when there is congestion. Also, badly configured network cards or half duplex network connections can cause packets to be dropped. TCP keeps track of this and does resends as needed so that you don't have to worry about this kind of thing most of the time, but the decision to resend a packet is partly based on timeouts and partly on noticing out of order packet arrival (eg getting packets 6 and then 8, and inferring that 7 has gone missing). Because there is a delay before requesting a missing packet and because the packets must be presented to you, the user, in the correct order, this can result in delays between delivery of the data you've typed to the program listening. In our example, the 8th character typed can't be delivered until the packet with the missing 7th character has arrived, or things would be very garbled, which is exactly what TCP is to prevent. So what, you ask? Well, your arrow key sends three characters: "ESC [ D" for example. But the character ESC is legitimate all on its own - it's sent by the Escape key. So programs listening to you must do some guesswork, which goes like this: only if the "[ D" arrive sufficiently soon after the ESC code will this be considered an arrow key; otherwise we'll consider it the key Escape and then two more keys: "{" and "D", which you may well have typed for whatever reason. And that guesswork is timing related, and may be confused by TCP network delays. For this reason I don't use arrow keys myself (aside from have grown up without such new fangled things). In most shell environments you have single keystroke equivalents for the arrow keys: ^A goes to the start of the line, ^B goes back one character, ^F goes forward one character, ^E goes to the end of the line, ^P goes to the previous line, ^N goes to the next line. These come from Emacs (and maybe even further back, from TECO). In the VI editor's command mode "h" goes left, "j" goes down, "k" goes up and "l" goes right. Or you can use BackSpace and Space for left and right. ---------- And finally, of course, your terminal emulator may not be sending the arrows at all. Better check that, too. Cheers, -- Cameron Simpson, DoD#743 cs@zip.com.au http://www.zip.com.au/~cs/ I'm a volunteer EMT-I on our local ambulance service; one of our Paramedics calls squid style motorcycle accidents "ZoomSplats", as in "we had a good ZoomSplat the other night". ;-) - Scott