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.
Related
I am looking to implement a remote client in golang which connects to Linux through nc and starts bash. So I need to tell bash what features I can parse from the stdout that it sends to me, and how I am going to send keycodes and other stuff to its stdin, so that it could parse them too.
This is done with TERM=something environment variable, which I need to set to some value. If I don't set it, then various programs start to complain:
$ mc
The TERM environment variable is unset!
I found that I can set TERM to dumb to say that my client is really limited. And still it seems that I am missing something.
$ export TERM=dumb
$ mc
Your terminal lacks the ability to clear the screen or position the cursor.
From here it looks like dumb terminal don't have these two abilities, but what abilities it is still expected to have? Is there a specification or some de-facto standard about it?
Going to the source can help. The terminal database has comments. Here is a slice from that:
#### Specials
#
# Special "terminals". These are used to label tty lines when you don't
# know what kind of terminal is on it. The characteristics of an unknown
# terminal are the lowest common denominator - they look about like a ti 700.
#
dumb|80-column dumb tty,
am,
cols#80,
bel=^G, cr=^M, cud1=^J, ind=^J,
unknown|unknown terminal type,
gn, use=dumb,
The "dumb" and "unknown" terminal types are assumed, but rarely used:
"dumb" has automargins (text "wraps" at the right margin), is assumed to have 80 columns, and an ASCII BEL and carriage return. For lack of something better, cud1 (cursor down) is an ASCII line-feed. The ind (index) value is the same, implying that text scrolls up when you reach the bottom of the screen.
There is no cursor-addressing (cup) nor alternates (such as moving along a row or column arbitrarily).
"unknown" adds the "generic" flag, which marks it as unsuitable for use by curses applications. Think of it as a printer.
As for minimum requirements, that actually depends upon the individual application. ncurses can manage to move around the screen without actually having cup. It works with a half-dozen strategies. If you read the source for mvcur, you can get an idea of what it needs.
However, applications such as mc do not simply rely upon ncurses to decide if it works, since (in this case) it may link with slang (which doesn't check that closely). So mc does its own checks, which may add restrictions.
In practice, unless you choose a limited terminal description such as "dumb", most of the terminals you are likely to encounter will work.
Further reading:
terminfo - terminal capability data base
curses interfaces to terminfo database (including mvcur)
ncurses/tty/lib_mvcur.c
Your best source of information will be the terminfo entry, easily viewed with the infocmp tool:
infocmp dumb
# Reconstructed via infocmp from file: /lib/terminfo/d/dumb
dumb|80-column dumb tty,
am,
cols#80,
bel=^G, cr=^M, cud1=^J, ind=^J,
which makes it pretty clear that the dumb terminal is quite limited ...
There are multiple questions that ask about capturing keystrokes, but the solutions provided have some complications.
ncurses termios structure/stty
-Changes the console settings so that SIGSTOP/SIGTERM would leave the setting in effect for the terminal.
X based solutions
-requires X server to be running(not that is is a huge problem, but it seems unnecessary to bring X server calls into a console application)
/dev/input/event*
-requires root
Vim seems to be able to capture keystrokes without root, an X server, and without changing the console settings. Does anyone know how vim is able to achieve this in linux?
Look at TTY raw mode -- there is a ioctl call which allows you to get individual keystrokes -- i.e. taking the tty out of line mode which is the default.
A quick search on ioctl raw give this link which looks ok.
How can you set a string to be used instead of standard input? For example, when running the latex command in Unix it will always find some trivial errors, to skip through all errors you have to enter "r" into the command line (I now know that with latex specifically you can use -interactionmode nonstopmode, but is there a more general solution to do this?)
Is there anyway to specify that this should be done automatically? I tried redirecting standard input to read from a file containing "r\n", but this didn't work.
How can I achieve this?
Not all applications that need input can be satisfied with their stdin redirected.
This is because the app can call the isatty C function (if written in C, or some equivalent call for other languages) to determine if the input come from a tty or not.
In such situation, there is a valuable tool to use, and this is expect.
latex --interaction=MODE
where MODE is one of:
errorstopmode: stop at every error and ask for input
scrollmode: scroll over non-fatal errors, but stop at fatal errors (such as "file not found")
nonstopmode: scroll over non-fatal errors, abort at fatal errors
batchmode: like nonstopmode, but don't show messaes at the terminal
For interactive use, errorstopmode (the default) is fine, for non-interactive use, nonstopmode and batchmode are better.
But beware, there are no trivial errors: all errors must be fixed, and all warnings should be fixed if possible.
Redirecting stdin works without problems here:
/tmp $ tex '\undefined\end' <<< r
This is TeX, Version 3.1415926 (TeX Live 2010)
! Undefined control sequence.
<*> \undefined
\end
? OK, entering \nonstopmode...
(see the transcript file for additional information)
No pages of output.
Transcript written on texput.log.
You've got two plausible answers detailing the way to handle Latex specifically. One comment indicates that you need a more general answer.
Most usually, the tool recommended for the general solution is 'expect'. It arranges for the command to have a pseudo-tty connected for input and output, and the command interacts with the pseudo-tty just as it would your real terminal. You tell 'expect' to send certain strings and expect certain other strings, with conditional code and regular expressions to help you do so.
Expect is built using Tcl/Tk. There are alternative implementations for other languages; Perl has an Expect module, for example.
From the man page:
-interaction mode
Sets the interaction mode. The mode can be either batchmode, nonstopmode, scrollmode, and errorstopmode. The meaning of these modes is the same as that of the corresponding \commands.
Looks like -interaction nonstopmode might help you.
How to make a Linux program in the Command Line Interface who display a nice user interface?
For example when I use "wget" to download a file from internet, I can see the download advancement in the Command Line Interface. How can I do that?
ncurses is a popular option, there are APIs for lots of programming languages.
Take a look at curses. It is a library for text based UI.
You can get a basic interface by using \r to go to the beginning of the current line.
Slightly more advanced is ncurses.
The next step up is Newt.
If you want to do a GUI for Bash scripts or to wrap around other command line utilities, you can use dialog (man page).
Here two great dialog tutorial to get you started :
Dialog: An Introductory Tutorial
Improve Bash Shell Scripts Using Dialog.
If you only need a progress bar, this can be done directly with a simple print (that prints the bar), followed by the carriage return character (ANSI character #13), which puts you back at the beginning of the line. The line can then be later updated by printing over it.
For more complicated needs, ncurses is indeed the standard way to go.
I wouldn't call wget's progress report as a 'nice gui', but anyway, the classic library for building graphical interfaces without X Windows is Linux and UNIX systems is ncurses.
Recently a C# version of ncurses has been started, check out details here
If you're using Mono, you could use MonoCurses
Try curses, it is a well documented API for text based UI.Also, there is so much open source projects that are using curses for you see and learn
wget does not really have a GUI, all I see is stuff that you can already achieve using stdout and echos (e.g. printf() or std::cout)
Anyways, for simple dialog boxes of the MessageBox kind, but not limited to that, also have a look at dialog
http://linux.die.net/man/1/dialog
http://hightek.org/dialog/
You can just use ANSI escape codes. A simple example in bash
echo -e "\033[H\033[2J \033[20;20H \033[4mThis is a underlined line.\033[0m"
One should mention FTXUI. Functional Terminal (X) User interface: A simple C++ library for terminal-based user interfaces!
Cross-Platform
Support for UTF8 and fullwidth chars (→ 测试)
No dependencies
etc
after doing
$ cat /dev/input/by-path/pci-0000:00:02.0-usb-0:2:1.0-event-kbd > ~/test_kbd
as root, I got a bunch of binary codes (which was expected). Now, I wanted to know how can I interpret this binary code to figure out what key has been pressed? What format is the output in? and is there a reference I could look at that would tell me what key each binary code stands for?
Thanks
I would guess that they are scan codes. This page lists the make and break codes of keys used by modern keyboards. For more information on PS/2 keyboard programming, see Adam Chapweske's resources.
This file provides keyboard events (in binary format).
Use
evtest /dev/input/by-path/pci-0000:00:02.0-usb-0:2:1.0-event-kbd
to get some information.