Is it possible to print to console in color from the kernel's version of printf? Can I see the same escape codes that I can in userland? Does the kernel understand the console well enough to be able to provide termcap style APIs and constants for specific color? If so, which header are they defined in?
You can certainly print arbitrary escape sequences from kernel. It would happily put whatever bytes out on a terminal. Whether those bytes would be interpreted as color, kernel, generally speaking, has no idea.
So, it is possible to print and you can see the same escape codes once you read kernel messages (i.e. if kernel prints XTERM-style colors and you happen to look at them via serial port with a terminal program that either uses XTERM or emulates XTERM escape sequences itself)
As for whether kernel knows much about your terminal type and able to use termcap info, the answer is, in general, no.
In userland terminal type is a matter of convention. Login script tries to figure out what kind of terminal you may be connected to and then sets TERM to appropriate type in the shell's environment. Forked processes inherit it and use the type in order to figure out how to do certain things on specific terminal. Usually it involves some sort of curses library.
Kernel, on the other hand is fairly minimalistic beast that does not really give much of a damn what's on the other end of whatever happens to be its console -- serial port, firewire or video card. For all practical purposes, console may not even be connected to anything at all.
Practically, you will need to solve two problems:
Have a way to configure terminal type for particular TTY device you want to use.
Provide kernel with som sort of termcap/terminfo data for that terminal type and an API to produce appropriate escape sequences for output on specific TTY. In other words -- in-kernel curses library.
Related
When some time ago I had developed a script to query network interfaces via snmpwalk and IF-MIB::ifDescr the output format was like STRING: eth0.
The OS was SLES11 using net-snmp (it still works in SLES12 using net-snmp-5.7.3).
However on a different OS (still Linux) the interface strings are represented as STRING: "port1" (note the surrounding double-quotes).
Now the question is: Who is responsible for the extra double quotes? A different version of net-snmp, or a different SNMP agent? Or is one of the results incorrectly implemented in the agent?
As far as I understand SNMP the double quotes are not necessary for the protocol as strings are always transmitted with their length.
While it would be unusual (and undesirable) for an SNMP Agent to provide a quoted string in response to a query for ifDescr (or for anything else!) as they are indeed not part of the contract of a string at that level, the SNMP world is rife with oddities and variations and specification deviations, so this is not something you can assume will never happen.
Meanwhile, the format of the command-line output of a tool like Net-SNMP is effectively arbitrary: the developers can choose whether or not to quote strings, and as long as they document their choice, the end result is the same. So you cannot make any assumptions here either.
You should examine the actual data. You can do this by sniffing the SNMP packets with a tool like tcpdump and loading them into a UI like Wireshark (previously Ethereal). Then you can observe the actual contents of the datagram without the Net-SNMP formatting. If it contains quotes, it's the agent's fault; if it doesn't, the app is adding them for display.
(There's probably a Net-SNMP flag to make it display the bytes, in hex form, making up the string, which would be an easier way to gather this evidence if I remembered what the flag was.)
As an editorial note, if you'd told us what the "different" Linux OS actually was, and what version of Net-SNMP you were using on it, we could have confirmed (or ruled out) option two for you.
(For what it's worth, I'm not aware of any Net-SNMP change that added or removed quotation marks from the command-line output, so this is probably an oddity of the agent on that "different" system.)
I am trying to write a C program that uses Linux system calls to emulate the behaviour of the more command in the Linux terminal. Since the users might enter commands such as q to finish the execution, I am trying to find a way in which to read keystrokes from the standard inout without using read(...), as I don't want the pressed key to appear on the standard output.
In other words, I want to be able to detect pressed keys without them being written.
I have read that ioctl() and the termios struct can somehow be used for this purpose, but I am not sure how they are used (I find the man pages somewhat cryptic).
I have found a few answers to the use of those functions, but all of them seem too complicated. There must be an easier way to detect simple keystrokes, isn't there?
man 3 termios, tcsetattr, disable ECHO on stdin.
For a longer explanation see: Hide password input on terminal
Alternatively, you could go through below termios abstraction, use input layer, /dev/input/*, but I think you'll need to disable forwarding events from your input devices to upper layers then.
When I'm writing a program for use on the command line, I notice that there's some limitations. For instance, I can't draw a 1-pixel-thick horizontal or vertical line like tmux does when it separates panes in a window. I can only move the cursor down, not up like VI seemingly does. I can't refresh information on the top of the page if the cursor is at the bottom.
So, when programs like tmux and vi do this, I have to wonder if they are:
drawing the screen from top to bottom every update (which I think is highly unlikely because otherwise I could scroll up in my terminal and see each redraw)
using some library that enables graphics in the terminal, like SDL, which I also think is unlikely.
using some standard syscall I don't know about
or finally
taking advantage of some feature of Linux/Unix of which I'm completely unaware.
So, how do these programs generate such a rich UI in such a seemingly limited shell? So long as the answer gives me just enough fodder to go on a Google rampage, I'll be happy.
I'm also assuming that these programs use some common method to do these things, but if that's wrong let me know.
A typical terminal emulator has a lot more features than are immediately apparent.
Essentially a program just needs to output short sequences of bytes that represent various commands such as move cursor (up|down|left|right), change color, scroll region, erase region, etc.
These commands typically begin with the escape character (the same character that is generated when you press the esc key while typing in a terminal) followed by various other characters, depending on which action is desired.
A good starting point for understanding how it works would be the Wikipedia Article about ANSI escape codes
You can do it by hand by putting the terminal into raw mode and writing directly to the terminal using low-level operations but the standard way to do it is to use the ncurses library.
I've started working on a little project in Lua that involves making a text-based interface that updates constantly, and allows keyboard input for interaction.
I need a way to get keyboard input, but I also need it to either not block, or have some kind of timeout (which can be set to a fraction of a second, preferably). I've done research myself, but I found nothing that worked for me.
I need something that works with Lua 5.1.5 and Linux. Windows compatibility would be nice, but is not a requirement as I'm also doing things that require an ANSI terminal.
As stated in the comments of my post by hyde, I can use a Lua wrapper for ncurses to get input. In addition to this, I can use its features for some other parts of my code that I was going to program myself anyways.
I'm doing this in Lua 5.1 with Luasocket and opening two separate Lua processes. I have two Lua console windows- "INPUT WINDOW" AND "OUTPUT WINDOW". INPUT WINDOW sends keypresses over localhost. OUTPUT WINDOW reads the localhost socket I'm using for this. It's non-blocking; you can set a very quick timeout on the udp receive. It's ugly, but it's the most vanilla solution I've found. That said, input data from INPUT window doesn't appear on the OUTPUT window (unless I want it to), which can be nice for a console-based UI.
On linux, console applications have the ability to format their output. They can set font color, set background color and can place signs everywehre on the console. Using that it is, for example, possible to implement a tetris game right into the console.
I´m wondering how one can do that. I think they use a output markup language or something else. Can anyone tell me where I can learn more about this?
Thanks very much!
Most console applications involving a lot of motion or color are built using the ncurses library. Some very common examples would be irssi (IRC client), mc (Midnight Commander, the console file browser), mutt (POP3/IMAP mail client)
It seems like you are already aware of the escape codes used to modify console colors. A good list of console color escape sequences (for Bash) can be found here.
You obviously need to get a hold of those every-popular Unix video games, rogue, srogue, larn, hack, and/or nethack. They have a long and venerable history.
Notably, these all use the standard curses — or more recently, ncurses — library. Here’s a screen shot.
Since they have no joystick, motion is with vi commands. They are hands-down the very best way to hone your vi motion skills ever invented: no more two-finger typing for you! You stop thinking about motion; it just becomes a part of your fingers’ muscle memory. You really have to play them to get a feel for the awesome “Zen” state you can get into playing them:
After enough practice, it feels as though your fingers themselves remember how to play the piece. You don’t even watch them. They've a job to do, and once they’ve learned it, can go about that job remarkably free of direct supervision. The key to clearing the mind of the outside world, so that the program becomes the dominant reality, is what a musician would call “finger memory”. (You might have heard athletes or dancers refer to it as muscle memory, but when we’re talking about using the computer, it really is the fingers that count.)
[...] Of course, that's not really what’s going on; it only seems to be. Your fingers don’t really remember. But a part of your brain that controls them does, even though “you” don’t realize it. What’s happened is that you've so successfully assimilated the moves needed that conscious direction is no longer required. The little lighthouse keeper behind your forehead can worry about other things, assured that your fingers will do the job you’ve trained them to do. Your eyes are on the screen, the program in your head, and your head is in the program. Your fingers become an unnoticed extension of your will. [...]
[...] There’s no question that, for certain tasks, the keyboard is clearly the optimally efficient input device. Consider the game of rogue or one of its more recent incarnations. You wouldn’t want to use anything but a keyboard there. The command set is just too rich. Trying to play the game with a mouse‐and‐menu interface instead of a keyboard one would slow you down by at least two orders of magnitude.
The rogue family of video games are also notable for showing how to write a video game for a regular terminal like a vt100 or an xterm, which I believe is what you are looking for. I’d probably use a more modern language than C these days, but all the same principles still apply. Both Perl and Python have good interfaces to these standard libraries.
It's not so much a markup language as a series of escape sequences that trigger the terminal viewer to format in a certain way.
You can send ANSI escape sequences before your output to indicate that the following output should be a certain color, weight, background. You can also send sequences that jump the cursor to specific locations to continue writing output.
If you are going to do a full blown app you should consider using some library such as ncurses which makes these manageable.