Find the answer to your Linux question:
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 11 to 20 of 28
The arrow keypress returns two characters - escape (ASCII 27) and another value like '[' You have to look for the escape sequence, then get the next character and respond ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Linux Newbie
    Join Date
    Oct 2004
    Posts
    158

    The arrow keypress returns two characters - escape (ASCII 27) and another value like '['

    You have to look for the escape sequence, then get the next character and respond correctly.


    You may also want to learn about ANSI escape sequences the standard is listed here:

    http://astronomy.swin.edu.au/~pbourk...mats/ansi.html

    tty's use a subset of that. See this for arrow keys:

    http://www.dee.ufcg.edu.br/~rrbrandt/tools/ansi.html

  2. #12
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    That's a common problem, actually. There is no way to distinguish between a user typing a left arrow and a user typing "ESC [ D". The way ncurses "solves" this is by waiting a second or so after receiving an ESC, and if a left bracket (`[') comes in during that time, it interprets it as an extended key. Otherwise, it interprets it as an isolated ESC key event. That, of course, means that if your program uses the ESC key, the user will have to wait a second every time she uses that function.

    Many programs assume that the user never types an ESC alone, and decide only to interpret it as the start of an escape sequence.

    It is true that for full terminal compatibility, you'll need to use the termcap or terminfo databases. In fact, why not just do as emacs does it -- use C-f and C-b instead of left and right arrows, and so forth?

  3. #13
    Linux Enthusiast
    Join Date
    Jan 2005
    Posts
    575
    Quote Originally Posted by Dolda2000
    That's a common problem, actually. There is no way to distinguish between a user typing a left arrow and a user typing "ESC [ D". The way ncurses "solves" this is by waiting a second or so after receiving an ESC, and if a left bracket (`[') comes in during that time, it interprets it as an extended key. Otherwise, it interprets it as an isolated ESC key event. That, of course, means that if your program uses the ESC key, the user will have to wait a second every time she uses that function.
    I don't think it's as bad as that.If I remember correctly if a
    key produces more than one characters terminfo will specify what
    is the time interval between each character and the next and that time
    interval will generally be a lot less than what it takes a human to press
    two keys consecutively.So you can reliably distinguish between the two
    cases and it doesn't require the reader to wait for any noticeable amount
    of time.I use vi all the time where you use the ESC key to go from insert mode
    to command mode and the response of the programme is instantaneous.
    The book I mentioned has some info on that stuff but I can't exactly
    remember what and as I've said it didn't say much.

    It is true that for full terminal compatibility, you'll need to use the termcap or terminfo databases.
    Actually termcap only has historical value.Only terminfo is used anymore.
    Quote Originally Posted by termcap man page
    The termcap database is an obsolete facility for describing the capa-
    bilities of character-cell terminals and printers. It is retained only
    for capability with old programs; new ones should use the terminfo(5)
    database and associated libraries.

  4. $spacer_open
    $spacer_close
  5. #14
    Linux Enthusiast
    Join Date
    Jan 2005
    Posts
    575
    One day someone should create a terminal emulator for X windows which
    puts key presses in some environment variable or a special file or something
    so that a programme only has to read the file to know which keys have been
    pressed.This I believe should make life much simpler.

  6. #15
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Quote Originally Posted by Santa's little helper
    One day someone should create a terminal emulator for X windows which
    puts key presses in some environment variable or a special file or something
    so that a programme only has to read the file to know which keys have been
    pressed.This I believe should make life much simpler.
    In what way would that be simpler than reading them from the terminal? The only difference at all that I can see is the handling of the ESC key, but if you really, really want to solve that, then you might as well just put escape sequences on something else instead of changing the entire scheme of things.

  7. #16
    Linux Enthusiast
    Join Date
    Jan 2005
    Posts
    575
    I was thinking that the terminal emulator could place in a file every
    key combination which has been pressed or the most recent n ones so
    that the file doesn't get huge.So the file would look something like
    Code:
    a
    b
    insert
    shift+6
    ctrl+alt+h
    ...
    The obvious advantage is that any programme which can parse text (like
    a shell script) can respond to the keyboard immediately instead of waiting
    for a full line followed by ENTER.As things are can you detect key presses
    from a shell script ? I don't think so.

    Another thing: unless you use the X windows libraries I don't think you can
    detect all key combinations either.Could you tell for example just using curses
    or read() that ctrl+shift+f5 are pressed ? I doubt it.

    And of course you wouldn't have to worry about macros corresponding to special
    keys , how close to each other the characters were read (to decide if it was a single
    key producing many characters or many keys), putting the terminal in raw mode etc.
    ...but if you really, really want to solve that, then you might as well just put escape sequences on something else
    What do you mean put escape sequences on something else ?
    ...instead of changing the entire scheme of things.
    I'm not proposing changing the current scheme , just enhancing it.The older
    methods would still work.

  8. #17
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Quote Originally Posted by Santa's little helper
    The obvious advantage is that any programme which can parse text (like
    a shell script) can respond to the keyboard immediately instead of waiting
    for a full line followed by ENTER.As things are can you detect key presses
    from a shell script ? I don't think so.
    Yes, you can. For example:
    Code:
    #!/bin/sh
    stty -icanon -echo
    while read -rn1 c && [ -n "$c" -a "$c" != $'\004' ]; do
        echo -n "$c" | od -t c | head -n1 | sed 's/^[^ ]* //'
    done
    stty icanon echo
    That will echo the symbolic codes of all keys received, as they are typed, until a newline or EOF is received.

    Quote Originally Posted by Santa's little helper
    Another thing: unless you use the X windows libraries I don't think you can
    detect all key combinations either.Could you tell for example just using curses
    or read() that ctrl+shift+f5 are pressed ? I doubt it.
    Yes, you can. For example, the output from the shell script above gives:
    Code:
    [F5 pressed]
    033
      [
      1
      5
      ~
    [Shift+F5 pressed]
    033
      [
      1
      5
      ;
      2
      ~
    [Alt+F5 pressed]
    033
      [
      1
      5
      ;
      3
      ~
    [Alt+Shift+F5 pressed]
    033
      [
      1
      5
      ;
      4
      ~
    As you can see, the function keys are returned as CSI-sequences, with the second parameter indicating modifiers. I'm no TTY expert, but it seems that if you subtract one from that second parameter, you get a bitmask with 1 representing Shift, 2 representing Alt and 4 representing Control.

    Quote Originally Posted by Santa's little helper
    And of course you wouldn't have to worry about macros corresponding to special
    keys...
    Actually, you still would -- they would just be different, the way it seems. Reading "shift+alt+f5" instead of a CSI sequence (can't type it out thanks to BBcode...) is just a different way of expressing things, and actually seems rather harder to parse to me.
    Quote Originally Posted by Santa's little helper
    ...how close to each other the characters were read (to decide if it was a single
    key producing many characters or many keys)...
    Even so, that still only regards the ESC key, and no others. Also, see below for a complete solution to that problem.

    Quote Originally Posted by Santa's little helper
    ...putting the terminal in raw mode etc.
    Even so, putting the terminal is raw mode is just another operation, just as opening this new special file would be.

    Quote Originally Posted by Santa's little helper
    ...but if you really, really want to solve that, then you might as well just put escape sequences on something else
    What do you mean put escape sequences on something else ?
    For example, making the terminal send ASCII 28 instead of ASCII 27 on escape sequences. Since ASCII 28 is Ctrl+Backslash, it's not as big a loss as the escape key. Admittedly, that's still pretty ugly, but you could also output a press on the escape key as an entire escape sequence, and the problem would be completely alleviated.

  9. #18
    Linux Enthusiast
    Join Date
    Jan 2005
    Posts
    575
    I must say this is a rather nice script but it still doesn't do exactly what
    I had in mind. For example pressing AltGR+e just gives e ,
    the same as pressing e on its own.Pressing Ctrl+, just gives ,
    So it doesn't distinguish between all combinations.But I
    was even more ambitious.I thought it would be nice if pressing
    shift on its own or Ctrl on its own could be detected.I'm not even
    sure you can do that using the X libraries.

    Also how does one find out which CSI-sequence (what does
    CSI stand for by the way) corresponds to which key combination ?
    That's the troublesome part , not parsing the line.
    Even so, putting the terminal is raw mode is just another operation, just as opening this new special file would be.
    I probably didn't express myself accurately.The point isn't putting
    it in raw mode.The point is *learning* about raw mode or CSI sequences etc.
    It seems that one has to learn a whole new terminology to be able to
    handle these things.How easy do you think would be for a lot of people
    to come up with a script like yours ? On the other hand with the method
    I'm suggesting one only needs to know how to open file and use for example
    the shell command read.People learn to do these things anyway.

  10. #19
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I think I see your point now that you mention capturing individual presses of even the modifier keys. However, it's certainly not without problems. First of all, if you have to open a file, then it won't be transparent. Consider, for example, using this terminal emulator to ssh to another machine. Then the processes running on that other machine won't able to access the extended key information.

    The most prevalent problem is, of course, that only your terminal emulator will be able to do this, and thus programs that rely on that functionality, will also implicitly be relying on X. Therefore, such programs may just as well be written using Xlib to begin with.

    The basic reason why TTYs don't support this to begin with is, of course, because the TTY "protocol" sends ASCII, not human interface data. The Control key is basically a means of sending ASCII control characters (it subtracts 64 from the ASCII value that would have been sent if the Control key had not been held down, and if the result is between 0 and 31, it sends it). Sending ASCII is much more independant of platform and input method than sending human interface data is.

    Quote Originally Posted by Santa's little helper
    Also how does one find out which CSI-sequence (what does CSI stand for by the way) corresponds to which key combination ? That's the troublesome part , not parsing the line.
    That's what terminfo and ncurses are good for, though.

    Quote Originally Posted by Santa's little helper
    I probably didn't express myself accurately.The point isn't putting
    it in raw mode.The point is *learning* about raw mode or CSI sequences etc.
    It seems that one has to learn a whole new terminology to be able to
    handle these things.How easy do you think would be for a lot of people
    to come up with a script like yours ?
    Then again, using your method, one has to learn that (not how) one has to open a special file. That's probably about as obvious as putting the terminal in raw mode. And, to be honest, I don't think it should be very hard to come up with that kind of script. Apart from all the fanciness of presentation, the only non-obvious parts is turning off echo and canonical input with stty, and reading a character at a time with the `-n' switch to read. It doesn't seem all that hard to me.

    Quote Originally Posted by Santa's little helper
    I'm not even sure you can do that using the X libraries.
    That's certainly possible. Try running xev, and you'll see all which you can catch.

  11. #20
    Linux Newbie
    Join Date
    May 2005
    Location
    Chennai,TamilNadu, India
    Posts
    141
    Dolda

    i tried it out once more the arrow keys and got the sequence you have given. I had printed them using %d instead of %i that was why

    anyway i am learning a lot of new things from u guys.....

    but anyway i have to manipulate the cursor positions so i guess i still have to go with ncurses since i need to do editing of the command line

Page 2 of 3 FirstFirst 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •