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.
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)
I am trying to find a way to paste a predefined string upon entering a specific keyboard sequence, on any app.
For example if I have to paste an url or a password into a field, I can have said password in a hidden script and when I press, say, [ctrl] + [5], it would write "example123" on the text field where my cursor is.
Ideally without copying to the clipboard (I'd prefer keeping what I have on my clipboard and also avoiding to paste a password or such by mistake elsewhere).
I have tried every solution I've found so far that include xclip, xdotool and xvkdb. All of them either do not work or are really inconsistent: They only paste the string sometimes, and when they do, it's usually only part of the string ("ample123" instead of "example123").
I thought of using compose key, which I heavily use anyway to write in french on an us keyboard, but it seems it only supports 1 character sequences, as nothing is printed when I modify my .XCompose to include custom output sequences of len > 1.
I am using Ubuntu 18.04 with Gnome as a DE. Ideally something that also works when logging back (like compose keys).
You need to walk the Document Object Model for either Gnome or your web-page. My concern is that with a desktop script you wont be able to access the web page because you will need to be able to establish a target to send string to. I see in your question that you tried using using "x{tool-name}" to grab the text field element. Delivering the sting really isn't the problem. The problem is getting the GUI element of text box pragmatically. The easiest way to get access to this in a user loaded web-page is with WebExtensions API which is how to make extensions for most modern browsers. Otherwise, if you can get away with only having access to Gnome's GUI I would try LDTP, it's a library used for testing, but it looks like it can be used for automation too.
For keyboard shortcuts:
It really shouldn't matter what the script is doing to how you want to activate it. I would just go to Gnome/Settings/Keyboard and set the path to where I saved the script to be the Command. If you go the WebExtension route, you will want to build the shortcut into your extension.
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.
I'm currently setting up a node.js server and I'm using the debug module here https://github.com/visionmedia/debug.
I'm trying to enable it so I can get the colored debugging information in my output, however my terminal looks like the last terminal screen at the bottom after it says:
When stdout is not a TTY, Date#toUTCString() is used, making it more useful for logging the debug information as shown below:
Can anyone shed some light on this? Thanks.
tty is one of those funky Unix commands that prints (or, displays) to standard output the name of the terminal connected to standard input.
These are commonly used as a way to get access to the computer to fix things, without actually logging into a possibly b0rked desktop.
Related: What is tty7 in the commandline?
By default Ubuntu has 7 tty's.
1-6 are command line only, 7 runs your X session (your normal desktop).
To access them, use this keyboard shortcut:
Ctrl + Alt + F1
(changing F1 to F1-F6 to access the terminal that you need)
To get back to your X session (the normal desktop),
Ctrl + Alt + F7
The TTY is the terminal or command prompt itself.
The screenshots are demonstrating the different results when stdout is directed to the terminal/TTY (with colors and time diffs) vs. when it's redirected elsewhere, such as to a file (via > out and with timestamps).
It determines which format to use with tty.isatty.
Note that not all terminals support the ANSI escape codes it's using to display colors.
I'm writing a game in assembly, and I need to check if a key was pressed.
So, how is kbhit implemented in Linux?
Thanks.
Google turned up a kbhit implementation for Linux in C: http://cboard.cprogramming.com/c-programming/63166-kbhit-linux.html
You could either compile this as is and call it from your assembly code, or if you really want to you could convert it to assembly.
I assume that you want also key releases. I also assume you are on the console (for X, XKeyEvent has enough info).
First, you have to put your terminal (i.e: console) in non-canonical or in raw mode. If you don't do this, you won't see any input until there is a line delimiter or EOF on input. See my answer to your previous question.
Then, to get key releases, you want to set the keyboard to RAW or MEDIUMRAW mode (this has nothing to do with terminal raw mode, this is very Linux and console specific, see console_ioctl(4)). Don't forget to set the keyboard back to its original mode before exiting.
There's a nice article about this here.