Fred,

> 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.

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

"R.Wieser" <address@is.invalid> writes:

> 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.

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.

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> "R.Wieser" <address@is.invalid> writes:
>>>I've set the console input to raw so I can see keys coming in when they are
>>>pressed.
>>>
>>>For that I've been writing a big "switch ... case" to parse the multi-byte
>>>keystrokes into "records" that than can be easily worked with or discarded.
>>>
>>>As this parsing needs to be done by pretty-much every console-based program
>>>which wants to do any kind of interactive stuff I was wondering if this
>>>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.

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.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>"R.Wieser" <address@is.invalid> writes:
>> 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.
>
>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.)

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.

"R.Wieser" <address@is.invalid> writes:
>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 ...

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.

"R.Wieser" <address@is.invalid> writes:
>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.

Ah, you want "raw" mode rather than "cooked" mode.

You can set that with tcsetattr(3).

"R.Wieser" <address@is.invalid> writes:
>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. :-)

You cannot get CTRL, ALT and SHIFT modifier keys explicitly on serial
ports. The terminal applies them (well except for ALT, which is a PCism)
before transmitting the character over the serial line.

On Mon, 26 Jun 2023 13:43:50 +0200
"R.Wieser" <address@is.invalid> wrote:
>Keith,
>
>> 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.
>
>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. :-)

Other than curses as someone has mentioned there's no library to process
keystrokes other than the code in the terminal/xterm/console itself. YOu'll
have to write your own. Tbh its not that hard , I did it for a telnet client
I wrote. There's a limited number of multibyte sequences you can expect
usually prepended with an ESC, eg "<esc>[A" is *usually* up arrow, "<esc>[B"
is *usually* down arrow. But some terminals can be awkward and send alternative
versions. The Linux console itself tends to differ from dumb terminals.

Scott,

> There is no way to transmit keystroke metadata over a serial line
> generally,

Bullshit.

Regards,
Rudy Wieser

Scott,

> Ah, you want "raw" mode rather than "cooked" mode.

Yes, but I already did that.

.... as I mentioned in the first line of my initial mesage.

Regards,
Rudy Wieser

Scott,

> You cannot get CTRL, ALT and SHIFT modifier keys explicitly on
> serial ports.

Is that what the parent of the message you are responding is talking about ?
I think not. So, what are you complaining about ?

Regards,
Rudy Wieser

Muttley,

> YOu'll have to write your own. Tbh its not that hard

I already did. But I would like to replace it with something that has been
time tested, as well as being able to cope with a number of other $TERM
types.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> writes:

> Scott,
>
>> There is no way to transmit keystroke metadata over a serial line
>> generally,
>
> Bullshit.

Rather than jump to this sort of conclusion, why not ask about what
Scott said?

Lots of terminals that you used to plug into a serial line simply sent a
sequence of processed characters to the other end. By "keystroke
metadata" I presume Scott means things like "left shift key down" or,
more likely, "key F12 while shift and control down" won't get sent.
Thus historical terminal interfaces would assume that only the processed
character sequence generated by the terminal hardware can be handled.

--
Ben.

wij,

[snip code]

Alas. Although I've set the exact flags you've shown I only get the normal
"del" (and other keys), regardless of which modifier keys I also press.

Any idea why ? $TERM setting perhaps (mine is "linux").

Regards,
Rudy Wieser

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>"R.Wieser" <address@is.invalid> writes:
>
>> Scott,
>>
>>> There is no way to transmit keystroke metadata over a serial line
>>> generally,
>>
>> Bullshit.
>
>Rather than jump to this sort of conclusion, why not ask about what
>Scott said?
>
>Lots of terminals that you used to plug into a serial line simply sent a
>sequence of processed characters to the other end. By "keystroke
>metadata" I presume Scott means things like "left shift key down" or,
>more likely, "key F12 while shift and control down" won't get sent.
>Thus historical terminal interfaces would assume that only the processed
>character sequence generated by the terminal hardware can be handled.

Correct. I also qualified the statement with 'generally'.

R didn't specify (other than the generic 'console terminal')
anything about the other end of the 'terminal' - whether it is
an antique glass tty on a 9600 baud serial port, or the other
end of a psuedo-terminal pair, or a kernel console driver.

"R.Wieser" <address@is.invalid> writes:
> Keith,

Your newsreader should add attribution lines, like the
"R.Wieser" <address@is.invalid> writes:
line above. Please don't delete those lines. They're there to
show readers who wrote what.

>> 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.
>
> 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.

So if the user presses the up-arrow key, you see three bytes: Escape,
'[', and 'A', right? And you want to recognize that sequence as
"up-arrow"? I'm saying that readline does exactly that internally, and
examing the readline source code might be helpful.

> 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. :-)

--
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> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
[...]
>> $ 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.

My mistake, the Linux virtual consoles are accessed via Alt-FN or
Ctrl-Alt-FN (function keys), where N is a small integer.

--
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> writes:
> Keith,
>
>> 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.)
>
> 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. :-|

Apparently it helped you to find more information.

> 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).

It's fairly common to use the word "console" (perhaps incorrectly) to
refer to terminals in general.

On Linux-based systems, and probably others, all the Alt-FN screens are
*virtual consoles*. They're supported by the OS more or less directly,
and they don't depend on any GUI system like X11. Terminal emulators
typically run as windows under X11 (or Wayland, or whatever).

And since this is all specific to Unix-like systems, and perhaps more
specifically to Linux-based systems, you might get better information in
a Unix-specific newsgroup, perhaps comp.unix.programmer. (This is
comp.lang.c++, and I don't think I've seen any C++ code in this thread,
and the libraries we've been discussing are C, not C++.)

[...]

--
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 */

scott@slp53.sl.home (Scott Lurndal) writes:
> "R.Wieser" <address@is.invalid> writes:
>>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.
>
> Ah, you want "raw" mode rather than "cooked" mode.
>
> You can set that with tcsetattr(3).

I think R.Wieser was saying that readline doesn't give any information
to the client until you press "enter" -- not because readline uses
cooked mode, but because readline presents a line-oriented interface.
(But examining the readline source code might be useful.)

--
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 */

Ben,

>>> There is no way to transmit keystroke metadata over a serial line
>>> generally,
>>
>> Bullshit.
>
> Rather than jump to this sort of conclusion, why not ask about what
> Scott said?

Because I'm getting tired of people who say one thing, but (bloody likely)
mean something *completely* different. And I mean *completely*.

I could ask him. I could even tell him what he (likely) tried to say
instead.

But no. It would be me fighting to get him to say what he actually means,
and I do not care for yet another struggle like that *at all*.

> By "keystroke metadata" I presume Scott means things like "left shift key
> down" or,
> more likely, "key F12 while shift and control down" won't get sent.

Yeah, I figured that its /possible/ that that is what he ment.

But if that is actually what he ment (our guesswork!) than you get the next
problem : By whom/what ?

How many terminal programs does he know of and has checked for that
behaviour ? how many *doesn't* he know and might do just that (absense of
proof is not proof of absense) ? In that regard his reply is *way* to
absolute for its own good.

> Thus historical terminal interfaces would assume that only the
> processed character sequence generated by the terminal hardware
> can be handled.

Disagree. It will, rather likely, make sure that unknown sequences are
silently discarded - leaving it up to newer parsers to handle the extra,
newer keys too.

Think of that as similar to old-style keyboards, and the newer ones with a
slew of fancy keys at the top to shut down the 'puter, change volume, call
up the default browser, etc. An old OS will just ignore those extra keys.

IOW, although I've not yet seen such modifier-key sequences come by, I could
easily imagine that they can be enabled, or that the modifier keys become
part of the keystroke packet as an extra field.

Regards,
Rudy Wieser

Am 26.06.23 um 15:03 schrieb R.Wieser:
>> 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.

As written above, you can use the termcap or terminfo library. It tells
you what keystrokes correspond to which keys.

Christian

Keith,

> Your newsreader should add attribution lines, like the
> "R.Wieser" <address@is.invalid> writes:
> line above. Please don't delete those lines. They're there
> to show readers who wrote what.

Thats why I have name the person I'm talking to at the top of my message -
just like yours now.

Also, my newsreader is more than 20 years old, and even it has got a tree
view with which I can easily go backwards to parent messages and forwards to
replies to my posts. I seldom-if-ever use it though. I could imagine that
yours has the same capability.

> So if the user presses the up-arrow key, you see three bytes: Escape,
> '[', and 'A', right? And you want to recognize that sequence as
> "up-arrow"? I'm saying that readline does exactly that internally,
> and examing the readline source code might be helpful.

As mentioned in my initial post, I already wrote a parser. But I would like
to replace it with something build-in, which is likely to support other
$TERMs than just "linux". If a build-in method doesn't exist I will just
continue using what I currently have.

Regards,
Rudy Wieser

Keith,

>> 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. :-|
>
> Apparently it helped you to find more information.

No, it didn't. I could not care less about what, on my machine, the
difference is between a "system console" and a "console". But I *had* to
search for it, because it *could* have been of importance in regard to the
distinction between a "console" and a "terminal". It wasn't. IOW, I wasted
my time.

> It's fairly common to use the word "console" (perhaps incorrectly)
> to refer to terminals in general.

Thats what I said. They are pretty-much used interchangably.

Currently I still do not know with what I should refer to the
console/terminal/tty/whatever on which the boot-process outputs its progress
and I than use to program in. Or with what I should refer to the ones under
ALT F2...F6.

> Terminal emulators typically run as windows under X11 (or Wayland,
> or whatever).

Any reason for the "emulator" postfix ? Other than by habit I mean ? And
yes, I recognise that a console in a window puts character based content in
a pixel-based environment.

To be honest, I took the "terminal emulator" as being a /program/ which runs
on another computer, translating whatever it gets into screen output, and
translates keyboard input to whatever the other side needs (VT100 codes or
alike).

> And since this is all specific to Unix-like systems, and perhaps more
> specifically to Linux-based systems, you might get better information
> in a Unix-specific newsgroup, perhaps comp.unix.programmer.

I was assuming that there would be linux programmers here too.

But a good one, thanks.

Regards,
Rudy Wieser

Christian,

> As written above, you can use the termcap or terminfo library. It tells
> you what keystrokes correspond to which keys.

A quick search shows me that "termcap" is a textfile which as been marked
obsolete and that both are used to translate keystrokes into escape
sequences. There where no results shown in regard to translating escape
sequences back to keystrokes though.

IOW, do you have any link(s) that show how the latter is supposed to be done
?

Regards,
Rudy Wieser