I am attempting to fill my keyboard with more bindings for tmux and vim, and I thought about using Ctrl+1, Ctrl+2, etc.
In tmux Ctrl+4 caused it to create a vertical split, which was interesting, then I tried it outside of tmux inside of cat and got this:
% cat
^#^[^\[1] 5730 quit (core dumped) cat
Here I typed Ctrl+1 (produced no output), Ctrl+2 (^#), Ctrl+3 (^[), and Ctrl+4 after which point it promptly died like this.
Now I will say that I have Ctrl+\ bound to vertical split in tmux, so that makes sense, but at this point I'm wondering why these bindings are like this. I fear that it means I can never distinguish e.g. Ctrl+3 from the Esc key.
There's not a real definite answer. It's all based on the operating system you're using. For example, I'm using Ubuntu 12.04 on one computer, and its key bindings are different than what I have another system with an older version that I keep as a server.
Related
The script should treat 'enter' as sending the users string but instead it just prints '^M' to the terminal.
I'm not sure why this is happening suddenly, it wasn't happening yesterday. Something has changed about this particular terminal session because if I open a new terminal window it works as expected in that.
Any ideas?
I'm using iterm on Mac (xterm?)
TL;DR: just type the reset command on the OS shell whenever the terminal starts acting funny.
Terminal emulator programs (as iterm) feature complicated internal states in order to provide literally decades of features to allow prettier programs on the terminal.
Terminals started as keyboards that would physically print the typed text into paper, back in mainframe era - and "stdin" and "stdout" concepts: a single stream going forward with all data that is typed and another with all data that is printed out, are up to today, more than 50 years later, the default way to interact with the text terminal.
Internal state changes by programs that deal with the terminal in different ways (like being able to read a keypress without waiting for "enter"), should be reverted when the programs terminate. But due to errors and bugs that is not always the case.
I don't know which possible state would change "ˆM" to be displayed instead of a CR code being applied to the terminal. There are tens or hundreds of other possible misbehaviors, including completely messing up all characters. The reset command in modern *nixes (MacOS, Linux, BSDs) will fix everything.
Although, of course, if "enter" is not being applied, it won't be possible to issue the command at all from the os shell. You will have to start a new terminal session then. From within a Python program, if you happen to make a call to some code that will always break the terminal, you might run "reset" as a subprocess by calling os.system('reset').
In particular, "ˆM" represents "ctrl + M", which is a control character with value "13" (0x0d in hex). It is the value for the "Carriage Return" control code (AKA. "return", "enter", "CR"). If you never did this: try pressing "ctrl+M", and see that it behaves the same as "enter". It is being displayed in "human readable form" instead of acting as a control character in your case.
(regarding xterm and iterm: all they have in common is that they are both "terminal emulator" programs, xterm being one of the oldest existing such programs, which probably pioneered a lot of adaptations from text-only video modes to a graphic environment. "iterm" is just a normal modern app which implements terminal functionality)
when I sshed into another machine in xterm, the character I deleted by either backspacce or ctrl+k, remains on the screen. but physically they have been deleted, as when you exectue the script, the machine responds in a way that the delete has conducted. The only way to display properly is to let the cursor moving through the deleted words, either by space or typing other characters.
Same thing applies when you using vim. specifically after page down, the screen displays a overlap between the previous page and current page.
The screen displays properly without ssh.
I am using gentoo with the following compile flag (if it is related).
[ebuild R ] x11-terms/xterm-314 USE="openpty truetype unicode -Xaw3d -toolbar" 0 KiB
Sounds like a locale problem. Some Linux's by the way honor an stty -iutf8 setting, and others may not. Either that, or a difference in locale settings on the local and remote machines is the first place to check.
Thomas's answer led me to a solution for this very same problem. My LANG environment variable was incorrectly set on my local machine. For my case,setting LANG=en_US.UTF-8
fixed the problem.
I recently understood that if I write characters inside /dev/tty it will simulate key presses with a keyboard.
I was wondering if I can simulate holding a key or a key combination.
What I'm looking for is to simulate the Alt + Tab to switch between open applications.
I'm not looking for alternatives. I am practising to learn how can I simulate a physical key press on a keyboard.
Is it possible to simulate key combinations (like Alt + Tab)?
Also, how can I press the Enter key?
It seems it's not '\n' or '\r' or "\r\n" or "\n\r".
The reason I'm looking for the Enter key is that I want do a "sudo" command in the terminal and when it prompts for a password, I use the /dev/tty to answer that, but it seems standard input or standard output (using "-S" option with sudo) don't work.
Is there anything I'm doing wrong?
Are there some libraries I should be looking for (like Expect)? Or is what I'm trying to do impossible?
I am using C++. All I want to do is to try to simulate a physical key press on my keyboard. The OS is Ubuntu 13.04 (Raring Ringtail). (Just as a practise)
But I have two goals:
To create a program which switches between applications using Alt + Tab.
interact with a Linux terminal.
I've found two solutions:
Write characters/codeASCII s of the corresponding keys to /dev/tty
Write characters/codeASCII s of the corresponding keys to standard output and/or standard input
But none of them worked. Is what I'm doing correct or not?
X does not read keystrokes from /dev/tty. If you want to simulate keystrokes in X, you’ll need to send them another way. If you’re writing a shell script, xdotool is your friend; if you’re writing C, though, you’ll probably want to use libxdo, the library underlying xdotool. If you’re looking for something a bit more low-level, you might be interested in the XCB Test API, on which both xdotool and libxdo rely.
Unless you can provide more information about your experience with sudo, I don’t think anybody will be able to answer your second question. sudo -S is definitely the intended mechanism for programmatically providing a password to sudo.
I have a recurrent problem when using R with a Linux console. I sometimes suspend it with [Ctrl+Z], then put it to the background with bg, (execute some other commands), then put it to the foreground again with fg.
R resumes correctly with all the workspace intact, but when I type, the characters are invisible (just like when we type passwords).
I still can execute commands though, and I see the response. Moreover, when I type [enter], the prompt doesn't go to the next line, but does something like this: > > >.
Then I need to quit R using q(), in order that everything returns to normal. I didn't manage to find any reference to this problem on internet.
Would you have an idea? Thanks a lot for your help.
No direct answer but via
"Doctor, doctor, it hurts when I do this."
"Then just don't do this."
I would suggest that if you must have an R console open, place it inside screen --- or if you have it, byobu a fancier extensions, or even tmux.
Or even inside the One True Editor (TM) using ESS. For what it is worth, I always run emacs --daemon and then connect to the same R session either via emacsclient -nw on the terminal or under X11 via emacsclient -c (both of which I aliased to emt and emx). I also run byobu sessions for command-line work where I often use littler for command-line tasks and tests.
Unix is a multitasking system. There is no need to limit yourself to one prompt, especially if you suffer side-effects as a consequence.
Next week I am getting an exam on using basic commands and shell scripting using terminal in Ubuntu. Please help me out with two quick questions:
-Does a practice environment for the Ubuntu terminal exist? I don't want to dual boot with Linux, so I want to find somewhere I could practice using some basic terminal commands as Cygwin seems to be quite different from the ubuntu terminal.
-What does the col command in Linux do? The manual page is here: Link, but I find that hard to understand, and since it doesn't work in Cygwin, it's hard to interpret! Also, why would one use man piped to col -b -x?
Thank you very much and sorry for the probably silly questions!
You can use the Ubuntu LiveCD boot (boots up an Ubuntu system without actually installing it) and experiment with the Ubuntu terminal shell. Its actually the same CD as the standard Ubuntu installtion CD... you just chose "Try Ubuntu" instead of "Install Ubuntu" once it boots up:
https://help.ubuntu.com/community/LiveCD
col is program to filter out reverse-linefeeds (i.e. the backspace character) from text input. In the olden days of line printers, a common method to achieve boldface print was to print a character, then print a backspace character, then print the character again. This would make the printer strike the character twice in the same place. Some programs would emit text files formatted in this way (man is one such program)-- but if you then tried to display that text file to your terminal screen, you might end up seeing something like this: "here is b^Hbo^Hol^Hld^Hd text".
col -b simply filters text input to strip out those extra backspace and double-strike characters. The -x option converts tab characters to space characters, which might be useful if the output was formatted for a device with a particular tab width, but then displayed on a different device.
man pages often have the backspace/double-strike text embedded in them, so man piped into col was often useful.
Nowadays, most terminal emulators actually know how to handle the backspace/double-strike, so col doesn't get used as much.
Far better (easier to use, install, maintain, etc.) than Cygwin, and perhaps less resource-using than a virtual machine, is http://andlinux.org . That will give you a shell on your Windows desktop, and you can play with the col command to better understand it.
Win-bash is essentially the same shell as linux, but on windows. You can use this to experiment outside Linux but I'm not sure how effective it is.
Other options are virtual machines, and if you don't mind a reboot, you can install ubuntu with wubi which means it can be deleted from windows' add/remove programs when you are done with it. (Or just use the live disc)
Col has very limited use for most people, it only affects programs that write lines asynchronously as opposed to line by line...