I would like to understand the values I get from read command in console. Are these outputs combinations of some keys?
F2 ^[OQ
F3 ^[OR
F4 ^[OS
ESC ^[
My problem is that I use special 128 keys keyboard that is programmed for specific software. I need to send these "keys" into this software using code below. Don't be confused about the fact that I'm using Linux to read keyboard and in code below I use Win. I'm just trying to figure it out first on my Linux box.
import win32api, win32com.client
shell = win32com.client.Dispatch('WScript.Shell')
shell.AppActivate('Some Application Title')
shell.SendKeys('%fo') # Alt+F, O
win32api.Sleep(100)
Thnx guys
These are standard ANSI Escape Sequences. The "^[" is an CSI = Control Sequence Introducer (not a TV series).
See http://en.wikipedia.org/wiki/ANSI_escape_sequences or a similar source on ANSI Escape Sequences.
If you send such sequences to something that recognises them, you can cause the effect they imply, like clear screen, change colour or, indeed, act as if the F1 key was pressed. However, you do need a recipient which does handle them! (like an linux console) A simple File stream would just write the characters.
Related
I am working on a ncursesw app that uses function keys.
Unfortunately it seems that there are some terminal emulators (notablly putty) that claim to be of terminal type "xterm" but send different escape sequences for the f1 to f4 keys from what a modern xterm sends (from some googling it seems that very old versions of xterm did the same).
ncursesw on my system just passes these escape sequences through to the app without interpreting them.
I would like to make my program accept these additional escape sequences for function keys. Is there a way to programatically add escape sequences to ncurses or will I need to write my own escape sequence interpreter?
Yes it is possible, using the call "define_key" ( http://invisible-island.net/ncurses/man/define_key.3x.html )
The documentation is not clear on whether it allows more than one escape sequence for a given "key" or not. My testing shows that it does allow it. So one can simply define the additional sequences.
define_key("\e[11~",KEY_F1);
define_key("\e[12~",KEY_F2);
define_key("\e[13~",KEY_F3);
define_key("\e[14~",KEY_F4);
You may want to surround this with a termname check so it only applies when the claimed terminal type is xterm (I did in my actual program but my actual program was written in pascal).
i have Vim with plugin vim-go and neocomplete, when o move the cursor from left to right in insert mode this happens
Note: this only happens with go code and vim-go required binaries (such as gocode, godef, goimports, etc..)
someone have same problem?
i am running Ubuntu 14.04.2 LTS 64bits with Kernel 3.13.0-48 Vim 7.4.52 with lua support
thanks in advance
It looks as if you are using gnome-terminal or konsole.
When you use cursor-keys to move around in insert-mode, the keys send escape sequences. In particular, if you happen to press the shift- or control-keys, those can send different escape sequences (with numbers), possibly with semicolons to separate the numbers. There are some limitations on vim's handling strings of that sort, and in some cases (see this discussion) it will get confused and stop interpreting the string, leaving junk on the screen.
The root of the problem is that in vi, the program (mis)uses the escape character for two different reasons:
a special "command" character sent by the user to the editor
the first character in the strings sent by most special keys to an application (including an editor).
The latter requires the program (vim) to wait "a while" to determine which case to use. If you are using a slow machine (or a slow connection) and your keyboard-repeat is fast, that defeats vim's attempt to distinguish the two cases. Likewise, your plugins send many characters to the screen for each keystroke, making vim slower.
It is aggravated by modified keys (using shift- or control-modifiers) since xterm and other terminals encode that information as a number. gnome-terminal and konsole use an older variant of xterm's (see xterm FAQ How can I use shift- or control-modifiers?) which is more easily mistaken by vim as not being an escape sequence.
If it is only a matter of timing, then moving your cursor more slowly would avoid the problem (agreeing that is only a workaround). You can gauge the amount of output done by vim by running it in script to capture the output into a typescript file. I do that to analyze bugs, by sending the data back to the terminal more slowly. Some of those typescript files are surprisingly large, for the little apparent work done.
I changed from neocomplete to YouCompleteMe, the random characters is not showing anymore.
I have a switch (CLI based) that takes me to the present STP setting when you hit the alphabets (which iam able to automate with tcl) but when it comes to changing the STP setting say from RSTP to MSTP, manually, I have to hit the up arrow and down arrow keys( only option available).
I need help to give the up arrow and down arrow commands in tcl format to automate it.
I read about rlwrap but thats more of history/ file editing which may not be helpful for me.
I have tried the " ^[[A" and "[A" options and hexacodes with no success.
I have tried "\u001b[A" etc but the value STP does not change. The CLI is A XML CLI. This is my script .
spawn telnet $DUT1_IP expect "login:" send "$user\r" expect "Password:" send "$password\r" expect "sh-3.2#" #sleep 2 send "xml_cli\r" expect ">> " send "bridge_config_mode = STP"
If i have to change mode STP to MSTP i need to use up arrow key in my keyboard to change it to MSTP /RSTP . how to use in expect to handle the same . Please give your thoughts if we can use shell scripting for the same (or any other).
Thanks and Regards
Mo
Up is mapped by your system keyboard driver to a three-character sequence: ^[[A. The first character, rendered as ^[ here, is an Escape character that is not normally renderable on your screen, and you write a real one in a Tcl script with \u001b. Down is correspondingly ^[[B. (Strictly, it could be other character sequences — it depends on the terminal type after all — but virtually everything uses the same thing here, and thank goodness!)
Let's simplify things for you by putting those key sequences in variables (we also need a backslash before the real [ because it is a Tcl metasyntax character):
set up "\u001b\[A"
set down "\u001b\[B"
Now you can do this to send the characters to the remote side:
send $up
expect "...whatever..."
send $down
expect "...blah..."
I'm using emacs in TTY mode (-nw), and I can use most of the key bindings out of the box. However, there are key combinations I cannot find the xterm escape sequences for (like C-;, C-<, C->, etc.) I would like to configure my terminal emulator to send them, but can't find out where to start.
I also don't want to resort to defining custom escape sequences that I will later configure emacs to interpret via key remapping.
Any ideas/pointers I can use?
First answer of this question will explain it: https://superuser.com/questions/83166/using-c-m-to-do-a-query-replace-regexp-in-emacs-running-in-mac-terminal
Basically there are just some key codes that cannot be sent to terminal applications. I have noticed this behavior a number of times; C-4 does not work the same way it does for me in the GUI version of Emacs.
If I do something like:
$ cat /bin/ls
into my terminal, I understand why I see a bunch of binary data, representing the ls executable. But afterwards, when I get my prompt back, my own keystrokes look crazy. I type "a" and I get a weird diagonal line. I type "b" and I get a degree symbol.
Why does this happen?
Because somewhere in your binary data were some control sequences that your terminal interpreted as requests to, for example, change the character set used to draw. You can restore everything to normal like so:
reset
Just do a copy-paste:
echo -e '\017'
to your bash and characters will return to normal. If you don't run bash, try the following keystrokes:
<Ctrl-V><Ctrl-O><Enter>
and hopefully your terminal's status will return to normal when it complains that it can't find either a <Ctrl-V><Ctrl-O> or a <Ctrl-O> command to run.
<Ctrl-N>, or character 14 —when sent to your terminal— orders to switch to a special graphics mode, where letters and numbers are replaced with symbols. <Ctrl-O>, or character 15, restores things back to normal.
The terminal will try to interpret the binary data thrown at it as control codes, and garble itself up in the process, so you need to sanitize your tty.
Run:
stty sane
And things should be back to normal. Even if the command looks garbled as you type it, the actual characters are being stored correctly, and when you press return the command will be invoked.
You can find more information about the stty command here.
You're getting some control characters piped into the shell that are telling the shell to alter its behavior and print things differently.
VT100 is pretty much the standard command set used for terminal windows, but there are a lot of extensions. Some control character set used, keyboard mapping, etc.
When you send a lot of binary characters to such a terminal, a lot of settings change. Some terminals have options to 'clear' the settings back to default, but in general they simply weren't made for binary data.
VT100 and its successors are what allow Linux to print in color text (such as colored ls listings) in a simple terminal program.
-Adam
If you really must dump binary data to your terminal, you'd have much better luck if you pipe it to a pager like less, which will display it in a slightly more readable format. (You may also be interested in strings and od, both can be useful if you're fiddling around with binary files.)