- Parsing multi-byte keystrokes - 25 Updates
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 26 12:53AM +0100 > function. > AFAIK, it is available everywhere bash is so your system should already > have it. Try "man readline". I don't know if it's what's wanted but the rlwrap program is not as well know as it should be. Essentially it "wraps" any interactive program with a readline-driven editing, completion and history interface. -- Ben. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 25 05:10PM -0700 >>perhaps is already part of Linux ... >>If it is (and thats still a big "if"), where can I find it ? > $ man console_ioctl I believe that only applies to the Linux system console (the text-only interface you typically get by typing Ctrl-Alt-N, where N is a small integer). I know the OP wrote "console", but I suspect they're looking for something that works on a terminal emulator. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jun 25 08:18PM -0400 Keith Thompson wrote: > handles things like arrow key input, but it doesn't give you information > like "the user just pressed up-arrow". In the past, I've tried and > failed to find a library that gives access to that kind of information. These codes are terminal-specific but basic things like up-arrww are more or less standardized in ANSI terminal. Unsure if this is what you were looking for, but works for me: #include <stdio.h> #include <stdlib.h> #include <string.h> #include <readline/readline.h> int up_callback(int count, int key) { printf ("the user just pressed up-arrow\n"); return 0; } int main(int argc, char *argv[]) { rl_bind_keyseq ("\\e[A", up_callback); free(readline("press a button > ")); printf("\n"); return 0; } > (The terminfo database gives you the character sequences corresponding > to the various keys, but I don't think it provides code to detect them > on input.) HTH -Pavel |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 25 07:10PM -0700 >> failed to find a library that gives access to that kind of information. > These codes are terminal-specific but basic things like up-arrww are > more or less standardized in ANSI terminal. These days, yes, mostly. Termcap, terminfo, and [n]curses were developed when there were a wide variety of terminals (not just emulators) with incompatible control sequences. Today if you assume VT100-compatible codes, you can probably get away with it. But there are still a lot of libraries that support other terminal types. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| "R.Wieser" <address@is.invalid>: Jun 26 08:50AM +0200 Pavel, > On Linux (strictly speaking, on a GNU system) specifically, try readline > function. The problem with that is that I need the keys at the moment they are pressed (and released ?), not only after "enter" is pressed. Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 09:21AM +0200 Keith, > I know the OP wrote "console", but I suspect they're looking > for something that works on a terminal emulator. Nope, not an emulator. As said, "bullseye lite" doesn't have a GUI. As for the difference between a "console" and a "terminal" ? I must say that its not quite clear (read: confusing) to me , as it seems to be used interchangably. If you have a good description about the differences between a "console" and a "terminal" than I would like to hear about it. Simply said, to me a "console" is the text-based interface you get on a 'puter thats executing the commands. A "terminal" is the program you use to remotely(?) connect to such a console. Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 09:11AM +0200 Ben, > Essentially it "wraps" any interactive program with a > readline-driven editing, completion and history interface. Thats pretty-much the opposite of what I currently want/need. I'm trying to write something thats interactive - For example, imagine a list of items you can move thru using the cursor keys and select pressing the spacebar. Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 08:46AM +0200 Keith, > curses takes over the entire (text / terminal) screen ... > but as far as I can tell curses is not suitable for, for example, > detecting the user pressing an arrow key *without* controlling > the whole screen. That indeed makes it pretty-much unusable for me. > In the past, I've tried and failed to find a library that gives access > to that kind of information. IOW, it probably doesn't exist and I need to create my own solution for it. You telling me that saves me a /lot/ of further googeling. Thanks. > (The terminfo database gives you the character sequences corresponding > to the various keys, but I don't think it provides code to detect them > on input.) Its something to look at and see if it can be used to do the reverse. Thanks for the info and heads-up. Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 08:56AM +0200 Scott, > $ man console_ioctl Yeah, I found that one too. Correct me if I'm wrong, but that looks like it only works for the local keyboard and won't be of much use in a remote session ... Regards, Rudy Wieser |
| Christian Gollwitzer <auriocus@gmx.de>: Jun 26 09:32AM +0200 Hi Rudy, Am 26.06.23 um 09:11 schrieb R.Wieser: >> Essentially it "wraps" any interactive program with a > I'm trying to write something thats interactive - For example, imagine a > list of items you can move thru using the cursor keys and select pressing > the spacebar. Then you might want something even more higher level than curses. For example, CDK gives you widgets in order to program a GUI that runs in the terminal: https://github.com/lnkgyv/cdk_examples If you are actually looking to do it on your own, you might want to look at termcap, which tells you the raw codes involved: https://www.gnu.org/software/termutils/manual/termcap-1.3/html_node/termcap_37.html Christian |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 26 01:29AM -0700 > Simply said, to me a "console" is the text-based interface you get on a > 'puter thats executing the commands. A "terminal" is the program you use > to remotely(?) connect to such a console. The term "console", on Unix-like systems, typically refers to the system console, sometimes accessed via /dev/console, while a "terminal" is a more general term for a text-based interface, usually accessed via /dev/tty* or similar. (A typical user might never see the console.) The details beyond that are probably off-topic here. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 26 01:30AM -0700 > Simply said, to me a "console" is the text-based interface you get on a > 'puter thats executing the commands. A "terminal" is the program you use > to remotely(?) connect to such a console. The term "console", on Unix-like systems, typically refers to the system console, sometimes accessed via /dev/console, while a "terminal" is a more general term for a text-based interface, usually accessed via /dev/tty* or similar. (A typical user might never see the console.) Historically, you'd have a single system console (hardware terminal) connected directly to the computer, and one or more remote terminals for users. More modern interfaces (virtual consoles and terminal emulators) are based on that. The details beyond that are probably off-topic here, if they aren't already. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 26 01:39AM -0700 >> function. > The problem with that is that I need the keys at the moment they are pressed > (and released ?), not only after "enter" is pressed. You might take a look at the readline source code to see how it does that. It's certainly able to recognize the user pressing up-arrow (which typically sends Esc-[-A) and acting on it immediately, even if it doesn't expose that ability directly to the user. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| wij <wyniijj5@gmail.com>: Jun 26 02:06AM -0700 On Monday, June 26, 2023 at 1:45:54 AM UTC+8, R.Wieser wrote: > example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left. > Regards, > Rudy Wieser /* Copyright is licensed by GNU LGPL, see file COPYING. by I.J.Wang 2005 Raw mode TTY for keyboard input. Build: g++ t_kb.cpp -lwy */ #include <Wy.stdio.h> // for cin,cout,cerr #include <Wy.termios.h> #include <Wy.unistd.h> using namespace Wy; // TTY i/o (raw mode terminal) // RawTerm changes tty attributes so that we can read key stroke without press ENTER // // Warning: Many virtual members of ChrFile are not reimplemented for simplicity. // class RawTerm : public ChrFile { Termios m_ptio; // Previous(original) termios setting public: WY_DECL_REPLY; RawTerm() {}; RawTerm(const char*, int); ~RawTerm(); Errno getch(char&); Errno write(const char); Errno write(const char*); } static mtty("/dev/tty",O_RDWR); RawTerm::RawTerm(const char* pathname, int flag) : ChrFile(pathname,flag) { Errno r=tcflush(*this,TCIFLUSH); if(r!=Ok) { WY_THROW( Reply(r) ); } if((r=tcgetattr(*this,m_ptio))!=Ok) { WY_THROW( Reply(r) ); } try { // Set the terminal mode // Termios ntio(m_ptio); ntio.iflag_and(~(BRKINT| ICRNL| IXON| INPCK | ISTRIP)); ntio.lflag_and(~(ICANON| ECHO| ISIG| TOSTOP| IEXTEN)); ntio.oflag_and( ~(OPOST) ); ntio.cflag_or( CS8 ); ntio.cc_VMIN(1); ntio.cc_VTIME(0); if((r=tcsetattr(*this,TCSANOW,ntio))!=Ok) { WY_THROW( Reply(r) ); } // Read back check Termios tmptio; if((r=tcgetattr(*this,tmptio))!=Ok) { WY_THROW( Reply(r) ); } // Omitted: Check termios setting accepted or not } catch(const Termios::Reply& e) { WY_THROW( Reply(r) ); }; }; RawTerm::~RawTerm() { // If *this is default, these functions just fail (no effect for any device) Errno r; r=tcflush(*this,TCIFLUSH); r=tcsetattr(*this,TCSANOW,m_ptio); }; / Get one char from terminal // Errno RawTerm::getch(char& ch) { Errno r; size_t n; if((r=ChrFile::read(&ch,sizeof(ch),n))!=Ok) { WY_RETURN(r); } if(n==0) { WY_RETURN(EIO); } return r; }; Errno RawTerm::write(const char ch) { Errno r; size_t n; if((r=ChrFile::write(&ch,sizeof(ch),n))!=Ok) { WY_RETURN(r); } if(n!=1) { WY_RETURN(EIO); } return r; }; Errno RawTerm::write(const char* str) { if(str==NULL) { WY_RETURN(EFAULT); } const size_t slen=Wy::strlen(str); Errno r; size_t n; if((r=ChrFile::write(str,slen,n))!=Ok) { WY_RETURN(r); } if(n!=slen) { WY_RETURN(EIO); } return r; }; int main(int, char* []) try { Errno r; if((r=mtty.write("中文"))!=Ok) { WY_THROW(r); } for(;;) { char ch; if((r=mtty.getch(ch))!=Ok) { WY_THROW(r); } if((ch=='q')||(ch=='Q')) { break; } /* if((r=mtty.write(ch))!=Ok) { WY_THROW(r); }*/ cout << (unsigned char)ch << ','; } return 0; } catch(const Errno& e) { cerr << wrd(e) << WY_ENDL; return e.c_errno(); } catch(...) { cerr << "main caught(...)" WY_ENDL; throw; }; ---------------------------------- []$ ./a.out 中文27,91,51,126,27,91,51,59,50,126,27,91,51,59,53,126,27,91,51,59,51,126, // keystroke: del, sh-del, ctrl-del, alt-del |
| "Fred. Zwarts" <F.Zwarts@HetNet.nl>: Jun 26 12:31PM +0200 Op 26.jun..2023 om 09:21 schreef R.Wieser: > Simply said, to me a "console" is the text-based interface you get on a > 'puter thats executing the commands. A "terminal" is the program you use > to remotely(?) connect to such a console. Console for Linux is normally used for the console which uses a keyboard directly connected to the computer, e.g. with USB, or PS2. A terminal is more generic. E.g., originally terminals where connected with a serial line to a computer ad the terminal did the interpretation of the keyboard. This made it impossible to detect certain keypresses, such as Ctrl, Shift, etc. The terminal in such a case does not send e.g. a 'Shift' press, an 'a' press, an 'a' release and a 'Shift' release, but it sends an uppercase 'A'. Therefore, your request to detect pressing and releasing keys is not possible for generic terminal software. |
| "Fred. Zwarts" <F.Zwarts@HetNet.nl>: Jun 26 12:47PM +0200 Op 26.jun..2023 om 12:31 schreef Fred. Zwarts: > it sends an uppercase 'A'. > Therefore, your request to detect pressing and releasing keys is not > possible for generic terminal software. And, of course, with software keyboards on a touch screen, the situation is again completely different. Generic terminal software hides such differences, but that limits the possible operations. |
| "R.Wieser" <address@is.invalid>: Jun 26 01:49PM +0200 Wij, [snip code] Thank you. Looking at the code I'm going to assume that receiving CTRL, ALT and SHIFT modifier keys too is just a setting added to the "ntio.iflag" field. I'll just have to check/find out which one it is. :-) Regards, Rudy Wiesr |
| "R.Wieser" <address@is.invalid>: Jun 26 01:43PM +0200 Keith, > up-arrow (which typically sends Esc-[-A) and acting on it > immediately, even if it doesn't expose that ability directly > to the user. As mentioned in my initial post, I have already switched the console input to "raw", and as such I can see bytes coming in when I press keys. Thats not the problem. What is is turning those streams of bytes into individual keystrokes. I can and already have parsed most keys for the "$TERM=linux" environment, but would like *NOT* to use my own code if something build-in is available - and getting support for other $TERM environments for free. :-) Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 01:30PM +0200 Keith, > system console, sometimes accessed via /dev/console, while a "terminal" > is a more general term for a text-based interface, usually accessed via > /dev/tty* or similar. (A typical user might never see the console.) As I said, the difference between them is /at best/ confusing. That you than introduce "system console" without offering any explanation to it does not help either. :-| I found a link which says that all things are terminals, and that a console is just a special one (your "system console"). In that case I'm working on/in the system console. Though I'm going to have a hard time remembering that ALT F1 is a console, but that ALT F2...F6 are terminals (I probably, likely won't. Too little, if any, distinction). And it doesn't help that I have a couple of WYSE WY60 terminals standing behind me. :-) Regards, Rudy Wieser |
| "R.Wieser" <address@is.invalid>: Jun 26 01:56PM +0200 Fred, > A terminal is more generic. E.g., originally terminals where connected > with a serial line to a computer ad the terminal did the interpretation of > the keyboard. Yep, that is how I defined "console" and "terminal" myself too. The first one part of the computer (in my case, all the ones behind the ALT F1...F6 keys), the second one remote to it (and talking to it using some kind of serial connection). But as you might have noticed, the definition does seem to differ between the different people (noticed the same while searching the internet) > Therefore, your request to detect pressing and releasing keys is not > possible for generic terminal software. I was already "afraid" of that, but it could not hurt to ask. Perhaps times have changed and being able to capture a key release was added to (some versions of) Linux. Regards, Rudy Wieser |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jun 26 01:50PM +0100 >> Essentially it "wraps" any interactive program with a >> readline-driven editing, completion and history interface. > Thats pretty-much the opposite of what I currently want/need. Good to know. I suspected it was not the right thing but I had not read every post carefully. > I'm trying to write something thats interactive - For example, imagine a > list of items you can move thru using the cursor keys and select pressing > the spacebar. There used to be libraries built on top of curses (and/or ncurses) that provided higher-level user interaction widgets like this. I can't remember if any caught on, but it might be worth looking before building your own. -- Ben. |
| "R.Wieser" <address@is.invalid>: Jun 26 03:03PM +0200 Ben, > There used to be libraries built on top of curses (and/or ncurses) > that provided higher-level user interaction widgets like this. I'm not looking for specifically the widgets (the example was just that, something to be able to relate to), but for how to be able to do something interactive with the keyboard. And for that I need to be able to extract keystrokes from the input stream. Regards, Rudy Wieser |
| scott@slp53.sl.home (Scott Lurndal): Jun 26 01:58PM >interface you typically get by typing Ctrl-Alt-N, where N is a small >integer). I know the OP wrote "console", but I suspect they're looking >for something that works on a terminal emulator. I thought about that, but "console-based program" pretty much implied no GUI. With graphics, the toolkit (X11, GDK) provides interfaces to handle and parse keystrokes. |
| scott@slp53.sl.home (Scott Lurndal): Jun 26 02:00PM >console, sometimes accessed via /dev/console, while a "terminal" is a >more general term for a text-based interface, usually accessed via >/dev/tty* or similar. (A typical user might never see the console.) Although prior to running unix on PC's, all consoles were serial terminals (or real teletypes or DECwriters), the only difference between /dev/console and /dev/tty1 was that they were two different serial ports. |
| scott@slp53.sl.home (Scott Lurndal): Jun 26 02:02PM >Yeah, I found that one too. >Correct me if I'm wrong, but that looks like it only works for the local >keyboard and won't be of much use in a remote session ... There is no way to transmit keystroke metadata over a serial line generally, so for anything other than the "console" terminal, all you get are ascii characters. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment