>> If it is (and thats still a big "if"), where can I find it ?
>
> curses library

Thats was the first thing I checked for, but it does not seem to be part of
my "bullseye lite" installation ...

But assuming I go and install it, its "man" page shows that it has got quite
a number of functions. Any suggestions to where to look how to use it for
what I described ?

Regards,
Rudy Wieser

Keith Thompson

unread,

Jun 25, 2023, 6:06:47 PM6/25/23

to

"Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
> On 2023-06-25 7:45 PM, R.Wieser wrote:
>> Hello all,
>>
>> 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 ?
>
> curses library

curses takes over the entire (text / terminal) screen, keeping track
of what character is shown at each location and using minimal output to
update it as needed.

If that's what you want, that's great, 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.

The GNU readline library may be closer, but it's at a higher level; it
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.
(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.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Pavel

unread,

Jun 25, 2023, 6:40:07 PM6/25/23

to

R.Wieser wrote:
> Hello all,
>
> 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 ?

On Linux (strictly speaking, on a GNU system) specifically, try readline
function.

AFAIK, it is available everywhere bash is so your system should already
have it. Try "man readline".

>
> Second question : How do I check for modifier keys (like alt, shift, ctrl)
> on the pressed keys or seperatily ? I would like to be able to, as an
> example, catch a ctrl-cursor-left as well as a normal or a shift-curor-left.
>
> Regards,
> Rudy Wieser
>
>

HTH
-Pavel

Scott Lurndal

unread,

Jun 25, 2023, 7:21:05 PM6/25/23

to

"R.Wieser" <add...@is.invalid> writes:
>Hello all,
>
>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

Ben Bacarisse

unread,

Jun 25, 2023, 7:53:41 PM6/25/23

to

Pavel <pauldont...@removeyourself.dontspam.yahoo> writes:

> R.Wieser wrote:
>> Hello all,
>> 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 ?
>
> On Linux (strictly speaking, on a GNU system) specifically, try readline
> 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

unread,

Jun 25, 2023, 8:10:26 PM6/25/23

to

sc...@slp53.sl.home (Scott Lurndal) writes:

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.

Pavel

unread,

Jun 25, 2023, 8:18:39 PM6/25/23

to

Keith Thompson wrote:
> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>> On 2023-06-25 7:45 PM, R.Wieser wrote:
>>> Hello all,
>>>
>>> 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 ?
>>
>> curses library
>
> curses takes over the entire (text / terminal) screen, keeping track
> of what character is shown at each location and using minimal output to
> update it as needed.
>
> If that's what you want, that's great, 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.
>
> The GNU readline library may be closer, but it's at a higher level; it
> 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

unread,

Jun 25, 2023, 10:11:01 PM6/25/23

to

unread,

Jun 26, 2023, 3:24:02 AM6/26/23

to

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

Christian Gollwitzer

unread,

Jun 26, 2023, 3:33:11 AM6/26/23

to

Hi Rudy,

Am 26.06.23 um 09:11 schrieb R.Wieser: >> Essentially it "wraps" any

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

unread,

Jun 26, 2023, 4:30:04 AM6/26/23

to

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

unread,

Jun 26, 2023, 4:31:16 AM6/26/23

to

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

unread,

Jun 26, 2023, 4:40:18 AM6/26/23

to

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

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.

wij

unread,

Jun 26, 2023, 5:06:49 AM6/26/23

to

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

unread,

Jun 26, 2023, 6:31:46 AM6/26/23

to

Op 26.jun..2023 om 09:21 schreef R.Wieser:

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.

unread,

Jun 26, 2023, 7:57:44 AM6/26/23

to

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

unread,

Jun 26, 2023, 7:57:44 AM6/26/23

to

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

Ben Bacarisse

unread,

Jun 26, 2023, 8:50:50 AM6/26/23

to

"R.Wieser" <add...@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.

R.Wieser

unread,

Jun 26, 2023, 9:29:19 AM6/26/23

to

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 Lurndal

unread,

Jun 26, 2023, 9:58:20 AM6/26/23

to

Keith Thompson <Keith.S.T...@gmail.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) writes:
>> "R.Wieser" <add...@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.

Scott Lurndal

unread,

Jun 26, 2023, 10:00:29 AM6/26/23

to

Keith Thompson <Keith.S.T...@gmail.com> writes:
>"R.Wieser" <add...@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.

Scott Lurndal

unread,

Jun 26, 2023, 10:02:25 AM6/26/23

to

"R.Wieser" <add...@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.

Scott Lurndal

unread,

Jun 26, 2023, 10:03:53 AM6/26/23

to

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

You can set that with tcsetattr(3).

Scott Lurndal

unread,

Jun 26, 2023, 10:05:29 AM6/26/23

to

unread,

Jun 26, 2023, 1:19:25 PM6/26/23

to

"R.Wieser" <add...@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.

R.Wieser

unread,

Jun 26, 2023, 1:25:17 PM6/26/23

to

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

Scott Lurndal

unread,

Jun 26, 2023, 2:36:50 PM6/26/23

to

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.

Keith Thompson

unread,

Jun 26, 2023, 3:01:19 PM6/26/23

to

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

Your newsreader should add attribution lines, like the
"R.Wieser" <add...@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

unread,

Jun 26, 2023, 3:08:42 PM6/26/23

to

Keith Thompson <Keith.S.T...@gmail.com> writes:
> sc...@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

unread,

Jun 26, 2023, 3:18:22 PM6/26/23

> 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

R.Wieser

unread,

Jun 26, 2023, 4:48:27 PM6/26/23

to

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

R.Wieser

unread,

Jun 26, 2023, 4:48:27 PM6/26/23

to

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

Ben Bacarisse

unread,

Jun 26, 2023, 5:13:00 PM6/26/23

to

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

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

I thought it was quote clear. Oh well...

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

I can't imagine what else you could think. My more general point is
that it's often worth taking a moment to see whether what was said
makes sense. It's rare the sane people (you have know that Scott is not
a crank) rarely post bullshit.

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

It's my turn to ask. I don't know what you mean here, though it's
possible I answer your question below.

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

He's explaining why many libraries (like curses) can't tell you about
keys like Alt, Ctrl and so on. They date from an era when terminals
were connected to systems by serial lines, and the system would only
ever get the data the terminal sends.

Personal workstations (that gave rise to X11) and PCs changed all that.
If there was only one keyboard, the programmer should get access to all
the details of key codes and key press/release events.

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

I think you've missed the point. Serial lines were often used to
connect terminals that simply didn't report the metadata. They just
sent character sequences. A VT220 simply does not send anything down
the line when the operator presses the control key, but if they hit the
'A' key with control down, the terminal sends the bit pattern with value
1.

--
Ben.

Keith Thompson

unread,

Jun 26, 2023, 5:16:04 PM6/26/23

to

"R.Wieser" <add...@is.invalid> writes:
> Keith,
>
>> Your newsreader should add attribution lines, like the
>> "R.Wieser" <add...@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.

Yes, I understand what you're doing and why you're doing it.

I'm asking you not to do that. I'm asking you to leave the generated
attribution lines in place, as everyone else here does. You're
expending extra effort and making your articles more difficult to read.

[...]

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

If there is such an existing library, comp.lang.c++ is not the place to
ask about it. Nothing you've written here is specific to C++.

Keith Thompson

unread,

Jun 26, 2023, 5:32:58 PM6/26/23

to

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

I do not accept responsibility for that.

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

That's not what I said. The term "console", when used correctly for
Linux-based systems and probably some others, refers to the virtual
consoles typically accessed via Ctrl-Alt-FN or Alt-FN -- *not* to
terminal emulators like xterm. Some people are sloppy about the usage
(and it often doesn't matter, since they really are quite similar in
most ways.)

(There's also an "xconsole" command that runs under X11 and displays
messages sent to /dev/console. The fact that these things that were
once handled in hardware are now almost entirely handled in software
does create some confusion.)

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

They're called virtual consoles.

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

Yes. A literal *terminal* is a hardware device that includes a monitor,
a keyboard, and some kind of connector. The VT100 is an example. A
terminal emulator is a software program designed to emulate a terminal.
Terminal emulators are far more common these days than physical
terminals.

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

Right -- except that it doesn't have to run on another computer.

Keith Thompson

unread,

Jun 26, 2023, 5:35:37 PM6/26/23

to

termcap and terminfo are specific to Unix-like systems, not to C++.
I suggest asking elsewhere.

Christian Gollwitzer

unread,

Jun 26, 2023, 5:58:49 PM6/26/23

to

Am 26.06.23 um 22:48 schrieb R.Wieser:

The termcap library is only a way to do the forward translation, i.e.
you can ask it for a key and get back the string that is represented
like this:
https://stackoverflow.com/questions/55090078/termcap-tgetstr-getting-arrow-keys

However, I still believe you are much better off using the ncurses
library, which also does the backwards translation. Look, e.g. at this
example:

https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/keys.html

As you can see here, the getch() function translates the special keys to
their symbolic code liek KEY_UP etc.

But cave: I gave up text mode programming a long time ago.

Christian

Scott Lurndal

unread,

Jun 26, 2023, 6:36:14 PM6/26/23

to

"R.Wieser" <add...@is.invalid> writes:
>Keith,
>
>> Your newsreader should add attribution lines, like the
>> "R.Wieser" <add...@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.

No, you deleted the standard attribution lines. Which when properly
done, allow easy determination of who wrote what. That convention is
likely older than you are.

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

You would be wrong.

Scott Lurndal

unread,

Jun 26, 2023, 6:41:57 PM6/26/23

to

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

The unix 'tty' command will tell you the name of
the node in /dev that corresponds to your controlling
terminal. That name might be /dev/console for the
device that owns the host keyboard/mouse/graphic card;
normally known as the system console.

The name might instead be /dev/ttys0, or /dev/usbtty0, or
/dev/serial/0 for a serial attached device, or may be
/dev/pts/17 for a pseudo-terminal pair (e.g. used by
xterm, gnome terminal and other gui and non-gui
terminal emulators.

Keith Thompson

unread,

Jun 26, 2023, 7:26:58 PM6/26/23

to

Christian Gollwitzer <auri...@gmx.de> writes:
> Am 26.06.23 um 22:48 schrieb R.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
>> ?
>
> The termcap library is only a way to do the forward translation,
> i.e. you can ask it for a key and get back the string that is
> represented like this:
> https://stackoverflow.com/questions/55090078/termcap-tgetstr-getting-arrow-keys

No, terminfo is newer and is intended to replace termcap, and provides
the same information. If you're starting something new, ignore termcap
and use terminfo (unless you have some specific requirement to use
termcap).

> However, I still believe you are much better off using the ncurses
> library, which also does the backwards translation. Look, e.g. at this
> example:
>
> https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/keys.html
>
> As you can see here, the getch() function translates the special keys
> to their symbolic code liek KEY_UP etc.

Yes, but it's not suitable for the OP's purposes. getch() implicitly
refers to the current ncurses screen (stdscr), and it can't be used
without first setting things up properly, which takes over the terminal
screen. (And comp.lang.c++ isn't the place to ask about it.)

wij

unread,

Jun 27, 2023, 4:32:51 PM6/27/23

to

On Monday, June 26, 2023 at 7:57:44 PM UTC+8, R.Wieser wrote:
> 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

Class RawTerm was revised from the previous post, because I felt class RawTerm
could be quite reusable for terminals and keyboard input(set open flags to O_RDONLY).
So I revised RawTerm, added a member function kbhit().

------------------------
#include <Wy.stdio.h> // for cin,cout,cerr
#include <Wy.termios.h>
#include <Wy.unistd.h>
#include <Wy.select.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 kbhit();
};
RawTerm::RawTerm(const char* pathname, int flag)
try : ChrFile(pathname,flag)
{
Errno r=tcflush(*this,TCIFLUSH);
if(r!=Ok) {
WY_THROW(r);
}
if((r=tcgetattr(*this,m_ptio))!=Ok) {
WY_THROW(r);
}

// 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(r);
}

// Read back check
Termios tmptio;
if((r=tcgetattr(*this,tmptio))!=Ok) {
WY_THROW(r);
}

// Omitted: Check termios setting accepted or not
}
catch(const Errno& e) {
throw Reply(e);
};

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!=sizeof(ch)) {
WY_RETURN(EIO);
}
return r;
};

Errno RawTerm::kbhit()
{
FdSet fds;
fds.set(*this);
return pselect(&fds,NULL,NULL,NULL,NULL);
};

int main(int, char* [])
try {
RawTerm mtty("/dev/tty",O_RDWR);
Errno r;

mtty << "Press any key. 'q' to quit:";
for(;;) {
char ch;
if((r=mtty.getch(ch))!=Ok) {
WY_THROW(r);
}
if((ch=='q')||(ch=='Q')) {
break;
}
mtty << (unsigned char)ch << " ";
}

// cin.reset(mtty); // dup2 cin to use mtty
return 0;
}
catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return e.c_errno();
}
catch(...) {
cerr << "main caught(...)" WY_ENDL;
throw;
};

Kenny McCormack

unread,

Jun 27, 2023, 10:17:57 PM6/27/23

to

In article <1dd24214-49c8-4f61...@googlegroups.com>,
wij <wyni...@gmail.com> wrote:
...

>Class RawTerm was revised from the previous post, because I felt class
>RawTerm could be quite reusable for terminals and keyboard input(set open
>flags to O_RDONLY). So I revised RawTerm, added a member function kbhit().

This is actually an interesting post, in terms of newsgroup politics.

This post is actually on-topic for the newsgroup, since it contains actual,
real, live C++ code, but entirely off-topic for the thread, since it has
nothing to do with OP's problem (which, in fact, has nothing to do with C++).

Interesting, that.

--
Modern Christian: Someone who can take time out from using Leviticus
to defend homophobia and Exodus to plaster the Ten Commandments on
every school and courthouse to claim that the Old Testament is merely
"ancient laws" that "only applies to Jews".

unread,

Jun 29, 2023, 8:05:53 AM6/29/23

to

Scott,

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

> The unix 'tty' command will tell [snip]

Alas, I thought that my above question (in the above quote) was clear
enough. But no.

I'll try again, but now dotting some "i"s.

1) The screen the boot process is outputting its progress into is called :

a) a console
b) a system console
c) a terminal
d) a virtual terminal
e) a tty
f) something else altogether.

Explain why.

2)The screen that becomes visible when the ALT F2...F6 keys is pressed is
called :

a) a console
b) a system console
c) a terminal
d) a virtual terminal
e) a tty
f) something else altogether.

Explain why.

Bonus question :

For any of the choices in the above that have not already been used explain
when those are used and why.

Regards,
Rudy Wieser

R.Wieser

unread,

Jun 29, 2023, 8:05:53 AM6/29/23

to

Scott,

>> 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.
>
> You would be wrong.

No, I don't think so. It could really easily imagine that.

/s

Regards,
Rudy Wieser

R.Wieser

unread,

Jun 29, 2023, 8:05:53 AM6/29/23

to

Scott,

> However, readline and libedit internally handle vim and emacs line
> editing, for which they must set the terminal to RAW mode, so the
> library sources would be a useful resource for someone who wishes
> similar functionality.

But of little, if any, use to someone who started his initial post with
"I've set the console input to raw so I can see keys coming in when they are
pressed."

Indicating both already having done that /and/ getting a result he can work
with.

Regards,
Rudy Wieser

Kenny McCormack

unread,

Jun 29, 2023, 11:44:28 AM6/29/23

to

Indeed. Well put. There have been several responses on this thread that
have "totally missed the point" - assuming that your issue was "How do I
set the terminal to raw mode?" - when, obviously, you'd already done that.

Maybe a language barrier problem. English not being their first language.

Aside: Some have suggested, as above, that you read/study the readline
source code for inspiration. I doubt that will help, as that code is
pretty opaque.

What this all boils down to is that there really should be an off-the-shelf
solution to this all-too-common problem. There apparently isn't. It should
be possible for someone to rip that functionality out of (n)curses, so that
you could use it, without the full-on commitment to (n)curses.

--
No puppet.
No puppet.
You're a puppet.

R.Wieser

unread,

Jun 29, 2023, 12:38:05 PM6/29/23

to

Kenny,

> Maybe a language barrier problem. English not being their first
> language.

There is also a good possibility that, as you mentioned yourself, the
responder just read a single post and took their (absense of a) clue from
there. Not bothering to even check out the threads starting post.

> What this all boils down to is that there really should be an off-
> the-shelf solution to this all-too-common problem.

:-) and that was/is pretty-much exactly what I was thinking, and tried to
find out, thru this newsgroup, if it exists.

Color me surprised that I now have to conclude a programmer has to write,
for *every program* which does not use a line-based input method, such a
parser himself.

> It should be possible for someone to rip that functionality out of
> (n)curses, so that you could use it, without the full-on commitment
> to (n)curses.

Depends on how it needs to be used. Currently I've got some code which
times out if nothing comes in or something incomplete has been parsed (it
doesn't block).

And by the way: I have quite a problem with the ^Z (26) being send as the
start of a command sequence as well on its own when the ESC key is pressed
(IOW, no escaping of the ESC key). I do not see any way to, in a stream,
detect if its one or the other. Its just asking for trouble. :-(

Regards,
Rudy Wieser

Keith Thompson

unread,

Jun 29, 2023, 4:59:19 PM6/29/23

to

None of these questions are about C++.

I can understand that you might think attribution lines are
unnecessary, but you refuse to leave them in place after being asked
to do so. It's *easier* to leave them alone than to delete them,
and for many of us it makes it easier to follow the discussion.
You even delete attribution lines from quoted text; there's no
indication who wrote the text above starting with "Currently I
still do not know".

You continue to post here in comp.lang.c++ when it's clear that
another forum such as comp.unix.programmer would be more appropriate
and more likely to get you the information you're looking for.

You want answers? Learn where and how to ask.

Pavel

unread,

Jun 29, 2023, 10:22:39 PM6/29/23

to

R.Wieser wrote:
> 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.

I got it from your first post :-).

With readline, you *don't have to wait till <enter> is pressed* to get
the key.

I have posted this example in my response to Keith Thompson on 6/25/23
10:18 pm, it might just work for your purpose.

#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;
}

>
> Regards,
> Rudy Wieser
>
>

HTH
-Pavel

Ben Bacarisse

unread,

Jun 30, 2023, 9:15:17 AM6/30/23

to

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

>> What this all boils down to is that there really should be an off-
>> the-shelf solution to this all-too-common problem.
>
> :-) and that was/is pretty-much exactly what I was thinking, and tried to
> find out, thru this newsgroup, if it exists.

As far as I can tell there /is/ a solution, but this, being a C++ group,
is not the best one for the question so maybe no one has given the
details.

> Color me surprised that I now have to conclude a programmer has to write,
> for *every program* which does not use a line-based input method, such a
> parser himself.
>
>> It should be possible for someone to rip that functionality out of
>> (n)curses, so that you could use it, without the full-on commitment
>> to (n)curses.

I think the solution is right there in ncurses.

> Depends on how it needs to be used. Currently I've got some code which
> times out if nothing comes in or something incomplete has been parsed (it
> doesn't block).

ncurses provides a function to do this parsing with and without a
timeout. If that is not, in fact, what you want then you should explain
why ncurses's "keypad" setting does not do what you want.

--
Ben.

R.Wieser

unread,

Jun 30, 2023, 12:13:17 PM6/30/23

to

> [quote=Alf P. Steinbach, Sun, 25 Jun 2023 15:06:29 -0700]
> curses takes over the entire (text / terminal) screen, keeping track of what
> character is shown at each location and using minimal output to update it as
> needed.
> [/quote]
>
> Which is /absolutily not/ what I'm currently looking for. Thats like using
> a cannon to kill a mosquito.

It may not do /only/ what you want, but wanting to parse input into keys
and /not/ wanting the other stuff if rare enough that it's a reasonable
starting point.

--
Ben.

Keith Thompson

unread,

Jun 30, 2023, 4:46:10 PM6/30/23

to

"R.Wieser" <add...@is.invalid> writes:
>> As far as I can tell there /is/ a solution, but this, being a C++
>> group, is not the best one for the question so maybe no one has
>> given the details.
>
> I assumed that a good percentage of users here would be using Linux, and the
> question would make sense to them. I must have assumed wrong.

And yet you're still posting here and *not* posting in an appropriate
place. Why?

>> ncurses provides a function to do this parsing with and without
>> a timeout. If that is not, in fact, what you want then you should
>> explain why ncurses's "keypad" setting does not do what you want.
>
> I would need to install it (its not part of the OS installation) and I've
> heard that its a bit "demanding" :
>
> [quote=Alf P. Steinbach, Sun, 25 Jun 2023 15:06:29 -0700]
> curses takes over the entire (text / terminal) screen, keeping track of what
> character is shown at each location and using minimal output to update it as
> needed.
> [/quote]

You see, this is why you should leave attribution lines alone. Alf
Steinbach didn't write that. I did. (He quoted it in a followup.)

> Which is /absolutily not/ what I'm currently looking for. Thats like using
> a cannon to kill a mosquito.

I have no problem with using a cannon to kill a mosquito. If ncurses
had a good way to detect arrow key input without taking over the whole
screen, I'd recommend that.

Thomas Dickey, in response to a question I posted on Stack Overflow a
few years ago, suggested something that might be the basis of a
solution:

https://stackoverflow.com/q/48715793/827263
https://stackoverflow.com/a/48716136/827263

James Kuyper

unread,

Jun 30, 2023, 5:00:37 PM6/30/23

to

On 6/30/23 12:12, R.Wieser wrote:
> Ben,
>
>> As far as I can tell there /is/ a solution, but this, being a C++
>> group, is not the best one for the question so maybe no one has
>> given the details.
>
> I assumed that a good percentage of users here would be using Linux, and the
> question would make sense to them. I must have assumed wrong.

Why would you go to a forum where "a good percentage of users would be
using Linux", rather than a forum devoted to Linux, where that
percentage could reasonably be assumed to be 100? It's significantly
less than 100% here - several of the people who post here dismiss any
Linux-specific comment in the belief that Linux is unimportant compared
to Windows.

Kenny McCormack

unread,

Jul 1, 2023, 3:53:28 AM7/1/23

to

In article <u7nfp3$2kvh5$1...@dont-email.me>,

Those people are mostly idiots and can (and should) be ignored. So,
really, no worries on that front.

--
A Catholic woman tells her husband to buy Viagra.

A Jewish woman tells her husband to buy Pfizer.

R.Wieser

unread,

Jul 1, 2023, 4:47:33 AM7/1/23

to

James,

> Why would you go to a forum where "a good percentage of users would
> be using Linux", rather than a forum devoted to Linux, where that
> percentage could reasonably be assumed to be 100?

If I would know everything (including the knowledge of a more apropriate
newsgroup ) than I would not have needed to post a question to begin with.
Ever thought about that ?

> It's significantly less than 100% here

You don't say.

> several of the people who post here dismiss any Linux-specific comment in
> the belief that Linux is unimportant compared to Windows.

And those are not the ones who would have the Linux knowledge to answer my
current question, so thats fine by me.

But thank you for the warning.

And for the record, if I would have had that other newsgroup in my shortlist
I would have posted there.

Regards,
Rudy Wieser

R.Wieser

unread,

Jul 1, 2023, 4:47:33 AM7/1/23

to

Keith,

>> I assumed that a good percentage of users here would be using Linux,
>> and the question would make sense to them. I must have assumed wrong.
>
> And yet you're still posting here and *not* posting in an appropriate
> place. Why?

Are you telling me I should just have stopped responding here and taken off
to that other newsgroup ? Where I live thats considered rude going on
offensive.

> You see, this is why you should leave attribution lines alone. Alf
> Steinbach didn't write that. I did. (He quoted it in a followup.)

Funny, I took his name from your post, where the attribution lines where
(ofcourse) present ...

But yes, I made a mistake. As you say, it was you who wrote that, in a
response to Alf. My apologies.

... But do I at least get points for using the correct date ? :-)

> I have no problem with using a cannon to kill a mosquito. If
> ncurses had a good way to detect arrow key input without taking
> over the whole screen, I'd recommend that.

And in that "no taking over of stuff" case I would most likely have used it.

> Thomas Dickey, in response to a question I posted on Stack Overflow
> a few years ago, suggested something that might be the basis of a
> solution:

Both of those links seem to end up showing the same content.

I skipped the ncurses part, as it, as mentioned by yours truly, wants to
take over the screen. The "How to distinguish between escape and escape
sequence" link shows some code, but as mentioned, I've already got that part
down.

Thanks nonetheless.

Regards,
Rudy Wieser

R.Wieser

unread,

Jul 1, 2023, 4:47:33 AM7/1/23

to

Paavo,

> $ cat `find aws-sdk-cpp/ -name '*.c' -o -name '*.cpp' -o -name '*.h'` |
> wc -l
> 15210261
>
> That's pretty impressive for a library which just copies files from one
> place to other (at least that's what we are using it for).

With that size I can only assume that it supports copying those files by
"avian carrier" (rfc 1149) for the transport. :-)

> $ cat `find ncurses/ -name '*.c' -o -name '*.cpp' -o -name '*.h'` | wc -l
> 129139

but its not about the size, but about the "side" effects. I don't want to
have to relinquish control of the screen just to be able to get access to
preparsed keystrokes. Thats not an acceptable solution.

Regards,
Rudy Wieser

Malcolm McLean

unread,

Jul 1, 2023, 6:04:09 AM7/1/23

to

Actually the usual pattern is that Linux programmers consider themselves to be technically
and even morally superior to those who program for some other proprietary platforms.
And so Linux-specific discussions get a free pass, unlike those on other operating
systems.

Mut...@dastardlyhq.com

unread,

Jul 1, 2023, 6:30:18 AM7/1/23

to

I disagree. We may be snooty about Windows compared to other OS's - not just
linux - but a C++ dev is a C++ dev regardless of platform. Having written C++
on both I am in no wish to hurry back to Windows due to the hoops you often
have to jump through to do basic (for *nix) stuff such as process forking,
multiplexing sockets and the absurd distinction between console and GUI apps.
That said Visual Studio is definately superior as an IDE to anything Linux has
to offer and blows the bug ridden abortion known as Eclipse out of the water.

Keith Thompson

unread,

Jul 1, 2023, 2:59:08 PM7/1/23

to

"R.Wieser" <add...@is.invalid> writes:
> Keith,
>
>>> I assumed that a good percentage of users here would be using Linux,
>>> and the question would make sense to them. I must have assumed wrong.
>>
>> And yet you're still posting here and *not* posting in an appropriate
>> place. Why?
>
> Are you telling me I should just have stopped responding here and taken off
> to that other newsgroup ? Where I live thats considered rude going on
> offensive.

You could post a single message on this thread saying that you're going
to continue the discussion in comp.unix.programmer. Or you could
cross-post a message to comp.lang.c++ and comp.unix.programmer, with
followups directed to comp.unix.programmer.

You can still do that. It would be far less rude than what you're
doing now.

>> You see, this is why you should leave attribution lines alone. Alf
>> Steinbach didn't write that. I did. (He quoted it in a followup.)
>
> Funny, I took his name from your post, where the attribution lines where
> (ofcourse) present ...
>
> But yes, I made a mistake. As you say, it was you who wrote that, in a
> response to Alf. My apologies.
>
> ... But do I at least get points for using the correct date ? :-)

You get no points for continuing to deliberately flout longstanding
Usenet conventions.

>> I have no problem with using a cannon to kill a mosquito. If
>> ncurses had a good way to detect arrow key input without taking
>> over the whole screen, I'd recommend that.
>
> And in that "no taking over of stuff" case I would most likely have used it.
>
>> Thomas Dickey, in response to a question I posted on Stack Overflow
>> a few years ago, suggested something that might be the basis of a
>> solution:
>
> Both of those links seem to end up showing the same content.

The first link was to my question, the second to Thomas Dickey's
answer. They both appear on the same web page.

> I skipped the ncurses part, as it, as mentioned by yours truly, wants to
> take over the screen. The "How to distinguish between escape and escape
> sequence" link shows some code, but as mentioned, I've already got that part
> down.

You skipped the part where Thomas Dickey demonstrated using ncurses
without taking over the screen.

Alf P. Steinbach

unread,

Jul 1, 2023, 4:38:11 PM7/1/23

to

On 2023-06-29 6:37 PM, R.Wieser wrote:
>
> And by the way: I have quite a problem with the ^Z (26) being send as the
> start of a command sequence as well on its own when the ESC key is pressed
> (IOW, no escaping of the ESC key). I do not see any way to, in a stream,
> detect if its one or the other. Its just asking for trouble. :-(

Timing.

- Alf

James Kuyper

unread,

Jul 2, 2023, 4:04:39 AM7/2/23

to

On 7/1/23 04:30, R.Wieser wrote:
> James,
>
>> Why would you go to a forum where "a good percentage of users would
>> be using Linux", rather than a forum devoted to Linux, where that
>> percentage could reasonably be assumed to be 100?
>
> If I would know everything

...

> than I would not have needed to post a question to begin with.

Of course.

[Rearranging slightly]
> (including the knowledge of a more appropriate
> newsgroup )

However, I did expect you to know how to search for an appropriate
newsgroup.

...

> And for the record, if I would have had that other newsgroup in my shortlist
> I would have posted there.

Your message headers indicate that your newsreader is Microsoft Outlook
Express. I use the Outlook app on my smartphone, which has no obvious
way to access usenet newsgroups. I don't know how Outlook works on it's
native platform, Windows, so I'm afraid I can't help you with that.

However, most newsreaders have some way of searching for appropriate
newsgroups on a specified news server. I use Mozilla Thunderbird to
access the Eternal September news server. When I select that server,
right click and select "Subscribe" from the pop-up menu, and type
"Linux" in the search box, it lists several hundred newsgroups, many of
which would be a more appropriate place to post this question than this
newsgroup. I also use Google Groups, which has a similar capability. I
would expect the same would be true of Outlook.

You'll get better answers from people with more Linux-specific knowledge
in those newsgroups than here.

And of course, usenet newsgroups are far from being the only forums for
discussing Linux. See <https://www.linux.org/forums/>, for instance.

R.Wieser

unread,

Jul 2, 2023, 5:04:18 AM7/2/23

to

Alf,

>> And by the way: I have quite a problem with the ^Z (26) being send as the
>> start of a command sequence as well on its own when the ESC key is
>> pressed
>> (IOW, no escaping of the ESC key). I do not see any way to, in a stream,
>> detect if its one or the other. Its just asking for trouble. :-(
>
> Timing.

Yep, thats what I used.

But now imagine that I'm not using it to parse a raw, but instead a cooked
(line-based) input. Bye-bye timing. :-(

Granted, I did not indicate I would be using my/the parser for that (quite
the opposite actually), but it did already enter my mind.

Regards,
Rudy Wieser

R.Wieser

unread,

Jul 2, 2023, 5:04:18 AM7/2/23

to

Keith,

> You could post a single message on this thread saying that
> you're going to continue the discussion in comp.unix.programmer.

Ah yes, about that : Are you aware that Linux != Unix ? I might well be
told to leave that group for the same reason you are trying to eject me from
this one ...

> You can still do that. It would be far less rude than what
> you're doing now.

Which is ? That I ignore your "I'm a Windows C++ programmer and could not
care less about the Linux C++ programmers that are here" attitude ?

Something about the pot calling the kettle black ...

> You get no points for continuing to deliberately flout longstanding
> Usenet conventions.

And you get no points from trying to push such conventions upon others as if
they are Laws.

You also should re-read it. It rather specifically tells you that what
they say in there are /not/ strict rules, but *guidelines* for keeping
usenet conversations running smoothly.

And seeing how you are able to pick out my responses to you without showing
any problems with it I think that my "just the posters name" works quite
well.

And to be frank about it, in this newsgroup (and several others that I
visit) you are one of less than a handfull in many years having a problem
with it. What does that tell you ?

IOW, you're behaving like the equivalent of a "grammar nazi". And I don't
like them either.

> You skipped the part where Thomas Dickey demonstrated using
> ncurses without taking over the screen.

Lol.

Third paragraph, first sentence :

"Here's a *non-working* example of what I'm trying to do."

(bolding by me).

A quick peek at the result could have told you the same :

"
Press UP, DOWN, Escape, LEFT, RIGHT
Incorrect input: (-1, -1, -1, -1, -1)
"

He even mentions the "intimately tied to taking over the entire screen" as a
standing problem in his "update" paragraph.

Regards,
Rudy Wieser

R.Wieser

unread,

Jul 2, 2023, 5:27:53 AM7/2/23

to

James,

> However, I did expect you to know how to search for an appropriate
> newsgroup.
...

> it lists several hundred newsgroups,

Yeah, when I did ask my newsreader I got such a long list too.

> many of which would be a more appropriate place

And you know that one of those others would be more apropriate .... how ?
Just by looking at the name ? I did, and I by it posted here.

IOW, I (and you too) have to make a choice on very limited information. And
when I than do I get people like keith and you telling me I did it wrong
*and wave me off* (1) to find another - which I would need to choose on the
same, limited info I used for this one.

(1) As in : I could not care where you go as long as its not here. Which is
a few notches below being helpfull and causes me to ignore it. Sorry (not
sorry).

And I'll be damned if I would just subscribe to all of them, follow them for
a few weeks to figure out what they are all about, and than pick one (with
possibly still getting a "not here" response).

Besides, keith isn't all that good in picking a "more apropriate" newsgroup
either, and you are not even trying ...

> You'll get better answers from people with more Linux-specific knowledge
> in those newsgroups than here.

:-) The Linux people here will /really/ like you for implicitily calling
them non-knowledgable.

Regards,
Rudy Wieser

James Kuyper

unread,

Jul 2, 2023, 2:52:03 PM7/2/23

to

On 7/2/23 05:27, R.Wieser wrote:
> James,
>
>> However, I did expect you to know how to search for an appropriate
>> newsgroup.
> ...
>> it lists several hundred newsgroups,
>
> Yeah, when I did ask my newsreader I got such a long list too.
>
>> many of which would be a more appropriate place
>
> And you know that one of those others would be more apropriate .... how ?

Primarily because I know that this is outside the scope of this newsgroup.

> Just by looking at the name ? I did, and I by it posted here.

You came here with a question that was primarily about Linux
functionality, because you thought that "C++" in the newsgroup name was
a stronger indication of appropriateness than "Linux"?

> IOW, I (and you too) have to make a choice on very limited information.

No, we don't. One of the best ways to find out which newsgroup is most
appropriate for a given topic is to do a search for messages containing
relevant keywords in Google Groups. Not all such messages will be about
the topic you're actually interested in, but you should be able to scan
the first several pages of search results to identify a newsgroup that's
appropriate.
On the other hand, if "C++" strikes you as a more relevant keyword than
"linux", your judgement of such matters is not to be trusted, so perhaps
asking for advice would be a better idea.

> Besides, keith isn't all that good in picking a "more apropriate" newsgroup
> either, and you are not even trying ...

It's your search, I was just explaining how to conduct it. I've used and
programmed exclusively on Linux, both at work and at home, for nearly
three decades, but I've never had any reason to worry about the issues
you're worrying about, so I'm not sure where to direct you.
More importantly, as a general rule, when I am looking for OS-specific
solutions, I'm more interested in a POSIX generic solution rather than a
Linux-specific one. If such a solution would be acceptable to you, I'd
recommend going to comp.unix.programmer

>> You'll get better answers from people with more Linux-specific knowledge
>> in those newsgroups than here.
>
> :-) The Linux people here will /really/ like you for implicitily calling
> them non-knowledgable.

Huh?
I suggested nothing of the kind. Only that there are far fewer Linux
experts here than you could expect to find in an active Linux oriented
group. The average level of Linux expertise in this group is lower that
of the linux groups. The minimum level of linux expertise in this
newsgroup is 0, but should be non-zero in those newsgreups.

R.Wieser

unread,

Jul 2, 2023, 4:49:50 PM7/2/23

to

James,

>> And you know that one of those others would be more apropriate .... how ?
>
> Primarily because I know that this is outside the scope of this newsgroup.

Wrong answer. Perhaps this is, outof all the newsgroups, the most
apropriate. But you would not know and you do not care. As long as I
believe your claim and leave.

> You came here with a question that was primarily about Linux
> functionality,
> because you thought that "C++" in the newsgroup name was a stronger
> indication of appropriateness than "Linux"?

I already answered that. At least twice. You going in circles doesn't work
for me. Sorry.

> One of the best ways to find out which newsgroup is most appropriate for
> a given topic is to do a search for messages containing relevant keywords
> in Google Groups.

Nice. So you are going to do that for me ? 'Cause I have zero wish to sign
up for "google groups". Or any other like it. I already have to see them
necro-bumping multiple years old posts or adverts for viagra, hacking
services and crap like that.

besides, I already did my searching. Quite a bit of it actually. If my
answer would have been in there I would have already found it, and not have
posted here.

> On the other hand, if "C++" strikes you as a more relevant keyword than
> "linux", your judgement of such matters is not to be trusted, so perhaps
> asking for advice would be a better idea.

Good, than we are now on the same page. I seek advice, and you think me
asking for advice is a good idea. So ? Or are you no Linux person ?
Actualy, I don't think I have to ask that.

>> Besides, keith isn't all that good in picking a "more apropriate"
>> newsgroup
>> either, and you are not even trying ...
>
> It's your search, I was just explaining how to conduct it.

As I already explained to you, no you didn't.

> If such a solution would be acceptable to you, I'd recommend going to
> comp.unix.programmer

Another nitwit who doesn't seem to understand that Unix != Linux.

As I said it to Keith, I might there well be asked to leave for the same
reason you use to try to eject me here. And where you don't, they would
actualy have a point.

>> :-) The Linux people here will /really/ like you for implicitily calling
>> them non-knowledgable.
>
> Huh?
> I suggested nothing of the kind.

You're not really smart, are you ? I ask a Linux and programming related
question as I assume that there would also be linux people here, some of
which might well know what the answer to my question is.

But you're saying that my question is not apropriate here. I can only
assume that you do not think the Linux people could know the answer.

Actually, someone has already proven you wrong in that regard.

> The minimum level of linux expertise in this newsgroup is 0

You like to throw some great-sounding but actually meaning absolutily
nothing blurbs like that around, do you ? First the "significantly less
than a 100%" - from a 100% you can only go down, and "significantly" can
mean about /anything/ in that 100% range. Is "5% less" significant ? Is
"50% less" significant ? Well, that depends on what that "significant" is
applied.

Yes, ofcourse the mininmum level is Zero. Perhaps one of the Windows people
has not ever heard about that OS (hard to imagine, but hey, its possible).

In the same vein I can, with absolute certainty, tell you that the maximum
level of linux expertise here is 100%.

Next you will probably try to tell me that water is wet. Or is that a bit
of a spoiler ?

Regards,
Rudy Wieser

Christian Gollwitzer

unread,

Jul 2, 2023, 5:15:23 PM7/2/23

to

Am 02.07.23 um 11:03 schrieb R.Wieser:
> Keith,

>> You skipped the part where Thomas Dickey demonstrated using
>> ncurses without taking over the screen.
>
> Lol.
>
> Third paragraph, first sentence :
>
> "Here's a *non-working* example of what I'm trying to do."
>
> (bolding by me).

Is it your first time you read StackOverflow? Of course, the one who
asks the question has a non-working solution. You should read the
answer, not the question.

Christian

Keith Thompson

unread,

Jul 2, 2023, 6:40:03 PM7/2/23

to

"R.Wieser" <add...@is.invalid> writes:
> Keith,
>
>> You could post a single message on this thread saying that
>> you're going to continue the discussion in comp.unix.programmer.
>
> Ah yes, about that : Are you aware that Linux != Unix ? I might well be
> told to leave that group for the same reason you are trying to eject me from
> this one ...

Yes, I'm aware. At least the first part of your original question was
not specific to Linux. Recognizing arrow keys on input, for example,
can be done using interfaces defined by POSIX, which is supported by all
Unix-like systems. The curses interface (which provides similar
functionality in a way that doesn't quite meet your requirements) is
defined by POSIX.

You mentioned the "console", apparently referring to the Linux virtual
console, but in most ways it behaves very similarly to any other modern
terminal emulator.

I'm not the only person who has suggested that comp.unix.programmer
would be a better place for your question. Apparently you'd rather
stay here and argue with people who are trying to help you.

Detecting modifier keys (shift, control, alt) separately is another
matter. It's impossible in some contexts. Detecting them on a
Linux virtual console is probably possible, but I don't know how.
That might be a question for a Linux-specific newsgroup; I don't know
which one, but perhaps something under the comp.os.linux.* hierarchy.
"man console_codes" might be helpful; it does discuss modifier keys.

>> You can still do that. It would be far less rude than what
>> you're doing now.
>
> Which is ? That I ignore your "I'm a Windows C++ programmer and could not
> care less about the Linux C++ programmers that are here" attitude ?

No, you've been posting here repeatedly without asking anything that's
specific to C++.

[...]

>> You skipped the part where Thomas Dickey demonstrated using
>> ncurses without taking over the screen.
>
> Lol.
>
> Third paragraph, first sentence :
>
> "Here's a *non-working* example of what I'm trying to do."
>
> (bolding by me).

Yes, I know. I wrote that in my question.

> A quick peek at the result could have told you the same :
>
> "
> Press UP, DOWN, Escape, LEFT, RIGHT
> Incorrect input: (-1, -1, -1, -1, -1)
> "
>
> He even mentions the "intimately tied to taking over the entire screen" as a
> standing problem in his "update" paragraph.

Yes, *I* wrote that as part of the *question*. I was suggesting
that you read Thomas Dickey's *answer*. (FYI, he's been maintaining
ncurses since 1996.)

Don't expect any more help from me.

James Kuyper

unread,

Jul 2, 2023, 6:57:04 PM7/2/23

to

On 7/2/23 16:49, R.Wieser wrote:
...

> Nice. So you are going to do that for me ? 'Cause I have zero wish to sign
> up for "google groups". Or any other like it. I already have to see them
> necro-bumping multiple years old posts or adverts for viagra, hacking
> services and crap like that.

"comp.os.linux.answers" appears to be a fairly active linux oriented
group, which frequently contains messages matching my search terms
"linux console raw keyboard terminal". I would still suggest that
<https://www.linux.org/forums/> might be more useful than any Usenet
Newsgroup.

Interestingly enough, when I also included "multi-byte", the messages
retrieved were posted almost exclusively in various newsgroups that had
"freebsd" rather than "linux" in their names. The reason might be
obvious to someone who knows more than I do about the relationship
between freebsd and linux.

> Good, than we are now on the same page. I seek advice, and you think me
> asking for advice is a good idea. So ? Or are you no Linux person ?

As I indicated, I have been using almost exclusively Linux for 30 years
now. I also don't know how to solve your problem to your satisfaction.
If there is in fact a solution, you'll need someone with more Linux
expertise than me.

[Restoring snipped context]

>> I'm more interested in a POSIX generic solution rather than a Linux-specific one.

[End of restored context]

>> If such a solution would be acceptable to you, I'd recommend going to
>> comp.unix.programmer
>
> Another nitwit who doesn't seem to understand that Unix != Linux.

I very clearly distinguished Unix and Linux in the part of my message
that you chose to snip - how could you derive from that the conclusion
that I was confusing them?

>>> :-) The Linux people here will /really/ like you for implicitily calling
>>> them non-knowledgable.
>>
>> Huh?
>> I suggested nothing of the kind.
>
> You're not really smart, are you ? I ask a Linux and programming related
> question as I assume that there would also be linux people here, some of
> which might well know what the answer to my question is.
>
> But you're saying that my question is not apropriate here. I can only
> assume that you do not think the Linux people could know the answer.

No, I think you'll get answers of varying quality, depending upon how
subtle the issue is. The biggest danger is that if a linux issue is too
subtle, an answer given by a Linux user in a C++ group might be wrong in
a way that's too subtle for any of the other Linux users here to catch.
That's less likely to be the case in a newsgroup devoted to Linux.

> Actually, someone has already proven you wrong in that regard.

Oh - who? The only response you've received that you haven't denigrated
yet was the one suggesting that you use readline(), and you haven't
posted any follow-up indicating that it actually met your needs. If
that's the solution to your problem, then your description of your
problem made it seem far more complicated than it actually was.

...

> Yes, ofcourse the mininmum level is Zero. Perhaps one of the Windows people
> has not ever heard about that OS (hard to imagine, but hey, its possible).

It's not just one such person - there's many people here who have made
it quite clear that they don't know much of anything about Linux, and
couldn't care less.

> In the same vein I can, with absolute certainty, tell you that the maximum
> level of linux expertise here is 100%.

That seems incredibly unlikely to me. I've seen the levels of Linux
expertise displayed both here and in comp.UNIX.programmer - those levels
are much higher in c.u.p., which is entirely reasonable. If a lowly UNIX
group displays more linux expertise than a c.l.c++, how much higher
should the Linux expertise be in a group that actually has "linux" in
the group name?

R.Wieser

unread,

Jul 3, 2023, 5:00:45 AM7/3/23

to

Christian,

> You should read the answer, not the question.

Can you tell me what the first line of that answer was ? Was it something
like

[quote]
The filter function, called before initscr, tells curses to use a single
line (rather than the whole screen).
[/quote]

?

Yeah, no. I have been quite clear I can't use cooked input, and it still
messes with the screen.

Luckily Pavel was a bit more forthcoming than you, and made it clear that
there was a bit of a trick involved. Which ofcourse was not mentioned
there.

But if it actually does grab a screenline (and displays any output and/or
restores that screenline after exiting the call) while allowing me to grab
keystrokes (does the callback have a "ignore this keystroke" return value ?
I have not looked yet) than I again can't use it.

Bottom line : Yes, I ready that answer. To me it looks that you didn't.
Or perhaps just ignored the "side effects" of that method, because they do
not matter to you.

If I'm wrong and that method actually doesn't mess with the screen *at all*
than you're welcome to point out how thats been done.

Regards,
Rudy Wieser

R.Wieser

unread,

Jul 3, 2023, 5:00:45 AM7/3/23

to

James,

> "comp.os.linux.answers" appears to be a fairly active linux oriented
> group

Thank you for that suggestion. Alas, ethernal september (my newsgroup host)
doesn't seem to carry it. :-\

> I would still suggest that <https://www.linux.org/forums/>

Thank you again for that suggestion. Alas, I'm quite reluctant to sign up
to anything just to get a single answer.

Also, when I try to have a peek at what they are offering I 1) get an
"insecure connection". When I than bypass the certificate problem I 2) end
up on a cloudflare server which returns a "403 Forbidden". It also
doesn't help that 3) it demands JS to be enabled, which I keep disabled.

> As I indicated, I have been using almost exclusively Linux for 30 years
> now. I also don't know how to solve your problem to your satisfaction.

*Thank you* for saying that. It means that I can stop trying to search
for it (and just use whatever I already came up with myself).

>> Actually, someone has already proven you wrong in that regard.
>
> Oh - who? The only response you've received that you haven't denigrated
> yet was the one suggesting that you use readline(),

I rejected it the first time, as I have no use for cooked input. It was
Pavel who clarified it and showed that I could possibly use its callback to
get what I wanted.

... though a more recent post seems to indicate that that call still grabs
part of the the screen, which again/still makes it (way) less usable to me.

As for "denigrated" ? Think (read) again. I'm not known for just saying
"no" to something, I tend to describe why there is a mismatch between the
offered solution and what I am after. If you can't handle a "thats not
quite it and {this} is the reason why" than thats your problem, not mine.

> I very clearly distinguished Unix and Linux in the part of my message
> that you chose to snip - how could you derive from that the conclusion
> that I was confusing them?

By trying to push my Linux related question into a Unix related newsgroup.
Are you daft or something ? Or just suffering from dementia ?

> No, I think you'll get answers of varying quality,

Which is another "water is wet" kind of thing. Skipped.

> That's less likely to be the case in a newsgroup devoted to Linux.

I recently asked a RPi platform-specific hardware and Linux OS specific
question in an RPi specific newsgroup. For some reason people there where,
for whatever reason, coming up with all kinds of Non-RPi references. You
where saying ?

IOW, that pendulum swings both ways.

But granted, there is a distinct possibility, and I'm open to suggestions.
Just not bogus ones. :-(

>> In the same vein I can, with absolute certainty, tell you that the
>> maximum
>> level of linux expertise here is 100%.
>
> That seems incredibly unlikely to me. I've seen the levels of Linux
> expertise displayed both here and in comp.UNIX.programmer

:-) Thats the problem with grabbing the correct interpretation of what
you're reading. As I tried to explain as reponse to your "less than a 100%"
and "minimum is 0" blurbs.

Knowledge-wise you /cannot/ go under zero, just as your "significantly less
than 100%" /cannot/ be anything than being less than that 100% (besides what
"significantly" might actually be).

IOW, just like your "minimum is 0" blurb, the maximum is 100%. And water is
wet. But while the minimum might actually be reached by just having a
single nincompoop in the group, I grant you that the opposite will be much
harder to reach - even for just a single person.

Regards,
Rudy Wieser.

R.Wieser

unread,

Jul 3, 2023, 5:00:45 AM7/3/23

to

Keith,

>> Ah yes, about that : Are you aware that Linux != Unix ?

...
> Yes, I'm aware.

Than why did you try to push me to that newsgroup. It makes zero sense.

> At least the first part of your original question was
> not specific to Linux.

You mean the part above the "second question" ? If so, what *didn't* you
understand about

[quote=me, initial message]
I was wondering if this perhaps is already part of Linux ...
[/quote]

?

Also, thruout the thread there are multiple mentionings of Linux specific
usage, some of which I acknowledged to having found them myself. If
nothing than that should have given you a clue to what OS I was working on.

You complain abut me not reading everything and thus missing stuff ? I
suggest you take a long, hard look in the mirror.

> You mentioned the "console", apparently referring to the Linux virtual
> console

I have no idea, as my "/please/ tell me the difference between them"
requests have never been answered. Which, by the way, feels to me like
nobody here actually knows the distinction themselves.

... and you have now introduced yet another phrase to that list, bringing it
up to ... six?

But looking at the "virtual" part of it, isn't that not something that can
only be true when you use a GUI ? In that case I think you might also have
missed my mentioning (in my second post) of "my "bullseye lite"
installation".

... Which also should have been a clue-by-four that I was indeed using
Linux.

> I'm not the only person who has suggested that comp.unix.programmer
> would be a better place for your question.

True. You're one of exactly two who said that. And that makes it better
... how exactly ? How many people are there in this newsgroup ?

Besides ofcourse that you tried to dump me into a non-Linux newsgroup. :-(

> Apparently you'd rather stay here and argue with people who are
> trying to help you.

The people who wanted to help me already did. You and james are just
keeping on claiming I should not be here. Other than some "because I say
so" I have not gotten any clarification of that.

> I was suggesting that you read Thomas Dickey's *answer*.

I refer you to my reply to 'Christian', just before my reply to you.

> Don't expect any more help from me.

Like you trying to set me up to fail by suggesting I (re)post in a Unix
related group ? Yeah, I surely could do without such shennigans.

But, thank you for your (initial) attempts to come up with something
workable. Alas, as I've mentioned, something with a "side" effect of
touching the screen is unusable to me.

Regards,
Rudy Wieser