Not sure this is the best place to ask for this, but since the other MrBayes questions were also posted here, I'll give it a try.
So I'm trying to run MrBayes on Arch Linux (4.4.1-2-ARCH) and the program works fine but the arrow keys don't work.
The output for the arrow keys looks like this:
MrBayes > ^[[A^[[C^[[B^[[D
In the terminal (xterm etc.) the arrow keys work just fine.
Googling this turned up nothing... Any idea why this happens?
Arrow keys on almost all terminals send escape sequences. If a program handles arrow keys, it does this by noticing that an escape character is read, and follows up by looking for the rest of the escape sequence.
A program that does not expect escape sequences would generally be using the default terminal I/O modes, in which the operating system's terminal driver conventionally echoes an escape character as ^[ (because on most keyboards you can type an escape character that way).
From your description, it sounds as if MyBayes does not expect escape sequences.
Rather than using arrow keys for command-line editing, you should be able to use the backspace or delete (erase) character which the terminal sends.
To fix this behaviour, installing rlwrap does the trick.
rlwrap will convert the escape characters to their corresponding actions and also provides a history. Sadly though no tab-completion for directories.
For linux execute MrBayes like this:
$ rlwrap mb
or for mpi version:
$ rlwrap mpirun -np x mb
where x is number of processors/threads used.
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.
Could anybody be so kind to give me a link where I can get enough of information about special character sequences like "\033[0m"?
They are called ANSI escape codes, there are understood by the terminal emulator like xterm or gnome-terminal (and in the 1970s by real terminals like VT100; see the tty demystified). See termcap, termios(3), isatty(3), console_codes(4) etc...
In the previous century, escape codes have been terminal specific!
You probably want to use some terminal I/O library like ncurses (then avoid expliciting escape codes, ncurses will do that), or, for input only GNU readline.
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.)