Home > Archive > Unix Programming > September 2006 > Re: how to read the special keys like <shift>, <ctrl>, <home>, <
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: how to read the special keys like <shift>, <ctrl>, <home>, <
|
|
| Alan Curry 2006-09-13, 7:02 pm |
| In article <1158144620.550863.3560@h48g2000cwc.googlegroups.com>,
Subhash <msubhashreddy@gmail.com> wrote:
>
>Hi all,
>
>iam practicing some textbased(formatted output) programs in c language
>for that iam using linux2.4 and curses library function
>in that i need some special characters to read
>how to read the special keys like <shift>, <ctrl>, <home>, <end>,
><up>...
Home, End, and Up, on a typical terminal, send multi-character escape
sequences. Somewhere near the beginning of your program, put
keypad(stdscr, TRUE);
and then curses will handle interpret the escape sequences for you. wgetch()
and related functions will return KEY_HOME, KEY_END, KEY_UP, etc.
Shift and Ctrl (along with Meta, Alt, and some other oddballs you've probably
never seen) are modifier keys. Pressing a modifier key alone doesn't do
anything. If held down, it modifies the characters that are sent when other
keys are pressed, but if you simply press and release the Shift key, the
terminal will do nothing. There are no characters transmitted on the tty
line. curses has no chance to see that a key has been pressed.
If you want raw key event information, you need to get below the tty layer.
This will decrease your portability. On a Linux virtual console you can use
ioctl(KDSKBMODE, ...) to get raw key events. If there's an X session you can
get key events from the X server. If libSDL is available, you can probably
get key events from that. But if the user is on a tty at the other end of a
serial line or a telnet connection, there's just no way.
tty input is composed of characters, not keys.
--
The attacker\x92s overall goal would very probably be to convince other users
to run an unsafe program, by using the digital signature to convince them
that it is actually bona fide Microsoft software and therefore safe to run.
-- security bulletin MS01-017 ushers in a new definition of "safe"
|
|
|
|
|