From Newsgroup: comp.unix.shell

Searching for 'getkey' functions I stumbled across https://linux.die.net/man/1/getkey

getkey(1) - Linux man page

Name getkey - wait until a key is pressed
Synopsis getkey [OPTION]... [KEYS]

But that's not available on my Linux systems.

Where is that obtainable from, or is that a hoax?

Janis, puzzled
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 9/21/25 16:33, Janis Papanagnou wrote:

Searching for 'getkey' functions I stumbled across https://linux.die.net/man/1/getkey

getkey(1) - Linux man page

Name getkey - wait until a key is pressed
Synopsis getkey [OPTION]... [KEYS]

But that's not available on my Linux systems.

Where is that obtainable from, or is that a hoax?

Debian doesn't provide it.
You could write a shell function or C/python/awk/pascal/....
program that mimics it.

Here's the man page for the specs:
https://linux.die.net/man/1/getkey
--
Regards,
Kees
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10ap2ci$1pgnr$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions I stumbled across >https://linux.die.net/man/1/getkey

getkey(1) - Linux man page

Name getkey - wait until a key is pressed
Synopsis getkey [OPTION]... [KEYS]

But that's not available on my Linux systems.

Where is that obtainable from, or is that a hoax?

Nowadays, anything anyone doesn't like is labelled a "hoax".

Anyway, I assume if you were willing to dig, you could find source code for
it somewhere. FWIW, it didn't come up in a repo search of either of the
two Linux systems I just checked.

As it happens, a zillion or so years ago, I wrote a utility (in C) called "pause" that was based (loosely) on the functionality of the DOS/Windows command of the same name. At that time, there was no built-in way to do
it on Unix. I still use my "pause" in my scripts to this day.

Nowadays. you can use "read -sn1" in bash or ksh. I've used it on bash,
and I just now checked that (at least the ksh on this system) it works on
ksh, too.
--
If your answer to the question below is any number other than 1, then you're an atheist.

Q: How many religions are worthy of respect? (i.e., how many religions are valid?)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Kees Nuyt <kees@nospam.demon.invalid> wrote or quoted:

Debian doesn't provide it.
You could write a shell function or C/python/awk/pascal/....
program that mimics it.

Maybe on bash,

read -n 1 -s -r -p "Press any key to continue..."

. With,

"-n 1": read only one character,
"-s": do not echo the character (silent),
"-r": raw input (prevents backslash escapes), and
"-p": prompt text before waiting for the keypress.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions I stumbled across https://linux.die.net/man/1/getkey

getkey(1) - Linux man page

Name getkey - wait until a key is pressed
Synopsis getkey [OPTION]... [KEYS]

But that's not available on my Linux systems.

Where is that obtainable from, or is that a hoax?

OK, I found it like this.

On GitHub, I searched for the man page using a source code
search for "path:getkey.1".

Among the results, that led to this project which contains
the man page, and provides C program implementing it:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

This "rc-scripts" project claims to be a derivativre of
"initscripts 3.78" from Red Hat.

getkey.c has a copyright header confirming it to be
a Red Hat thing.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-21, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

I don't understand why, if you're writing a package providing
initSCRIPTS that you'd write a C program for getting a key,
when it's trivial scriptusing a combination of stty and dd.

I bet you that guy is now oozing about how productive he is with AI.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 17:23, Kees Nuyt wrote:

On 9/21/25 16:33, Janis Papanagnou wrote:

Searching for 'getkey' functions I stumbled across
https://linux.die.net/man/1/getkey

Here's the man page for the specs:
https://linux.die.net/man/1/getkey

Funny response (given my post).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10apd8g$1sb19$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 17:23, Kees Nuyt wrote:

On 9/21/25 16:33, Janis Papanagnou wrote:

Searching for 'getkey' functions I stumbled across
https://linux.die.net/man/1/getkey

Here's the man page for the specs:
https://linux.die.net/man/1/getkey

Funny response (given my post).

Some people approach Usenet as a write-only medium.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Cancer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 17:25, Kenny McCormack wrote:

In article <10ap2ci$1pgnr$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions I stumbled across
https://linux.die.net/man/1/getkey
[...]
But that's not available on my Linux systems.

[...]
Anyway, I assume if you were willing to dig, you could find source code for it somewhere.

I found several things (C, C++, etc.). Here I was asking specifically
for a Linux (standard?) command that was described on the link above.

FWIW, it didn't come up in a repo search of either of the
two Linux systems I just checked.

Neither did I. (Thus my post.)

As it happens, a zillion or so years ago, I wrote a utility (in C) called "pause" that was based (loosely) on the functionality of the DOS/Windows command of the same name. At that time, there was no built-in way to do
it on Unix. I still use my "pause" in my scripts to this day.

I also found some code (was it in "C") that had a "dos.h" or similar
included. (My topic was "Linux", though.) - I skipped that variant.

Nowadays. you can use "read -sn1" in bash or ksh. I've used it on bash,
and I just now checked that (at least the ksh on this system) it works on ksh, too.

I doubt it's in ksh (as advertised here); '-s' feeds the history.

I had also found a sample with 'stty', 'dd', and so on. Maybe I'll
extend that to my needs if there's no "standard" command.

Thinking about it; I might also write my own "C" version to create
a ksh-builtin myself. Though such approaches are from my perspective
inferior to a standard tool. - Well, I'll see what gets suggested...

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 18:29, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions [...]

OK, I found it like this.

On GitHub, I searched for the man page using a source code
search for "path:getkey.1".

Among the results, that led to this project which contains
the man page, and provides C program implementing it:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

I have a problem with that code; it refers to a "popt.h" that leads
to a fatal error when compiling a git clone of that package. (I'm
reluctant to start invest time in projects of this type of quality.
I suppose it's easier to "re-invent" my own tool. *sigh*)

I haven't thought that there would be problems to find some standard
tool. But, OTOH, I had noticed that I already asked for such function
some time ago and also didn't find some "standard" tool. Also on the
Net (where some other folks had also asked for such tools over time)
they often got just snippy responses, and no suggestions. - It seems
to be a hard (or unworthy) request. :-)

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10apenm$1squ0$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

Nowadays. you can use "read -sn1" in bash or ksh. I've used it on bash,
and I just now checked that (at least the ksh on this system) it works on
ksh, too.

I doubt it's in ksh (as advertised here); '-s' feeds the history.

I don't know what the problem is.

The "ksh" on this system seems to be some sort of ksh93. I don't know how
to check the version directly. Is there a variable like BASH_VERSION to
check?

Anyway:

% ksh
$ echo -n "Hit a key: ";read -n1; echo "You said: $REPLY"
Hit a key: kYou said: k
$

It looks like neither -s or -p (from bash) are supported, but -n1
definitely is. From what I can see, it works the same with or without the
's', but adding -p generates an error message. In bash, -s means don't
echo the key (so you would not see the first "k" in the display above).

You could have just tried this on your ksh instead of complaining that it
would not work.
--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 18:29, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions [...]

OK, I found it like this.

On GitHub, I searched for the man page using a source code
search for "path:getkey.1".

Among the results, that led to this project which contains
the man page, and provides C program implementing it:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

I have a problem with that code; it refers to a "popt.h" that leads
to a fatal error when compiling a git clone of that package. (I'm
reluctant to start invest time in projects of this type of quality.
I suppose it's easier to "re-invent" my own tool. *sigh*)

I haven't thought that there would be problems to find some standard
tool. But, OTOH, I had noticed that I already asked for such function
some time ago and also didn't find some "standard" tool. Also on the
Net (where some other folks had also asked for such tools over time)
they often got just snippy responses, and no suggestions. - It seems
to be a hard (or unworthy) request. :-)

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 20:35, Kenny McCormack wrote:

In article <10apenm$1squ0$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
...

Nowadays. you can use "read -sn1" in bash or ksh. I've used it on bash, >>> and I just now checked that (at least the ksh on this system) it works on >>> ksh, too.

I doubt it's in ksh (as advertised here); '-s' feeds the history.

[...]

You could have just tried this on your ksh instead of complaining that it would not work.

Obviously you didn't know what -s does in ksh; I did know it, so
there's no need to test feature -s [with bash semantics] in ksh.
(Frankly, since you don't know that about ksh I wondered why in
the first place you had mentioned it at all. - Note I was merely
replying to that -s part of your post with the statement above.)

Actually the idea with 'read' is basically fine, though the [in
ksh] non-existing input-suppression with 'read' is a drawback.
But it's fixable with additional 'stty' calls.

Thanks.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Another suggestion, to use 'read -n1', maybe in the form of
read -r -t0 -n1
might already suffice, and being a built-in it may be faster.
(The timer -t0 setting is nice for polling.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

We were both trained on the same data set, so we predict
about the same tokens.

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.09.2025 03:34, Kaz Kylheku wrote:

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

We were both trained on the same data set, so we predict
about the same tokens.

There's a chance that we're both just AIs? ;-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

(BTW, "requires to not require" is a noteworthy formulation.)
What's the reason for that POSIX non-requirement? Because the
'stty' data isn't delimited by whitespace?

Some data contains no space and it requires with standard IFS
no quoting or are robust to delimiters. Variables expanded in
"specific shell contexts" also need no quoting. - In context
of arguments to external commands and unknown IFS I generally
quote variables. (I variable expansions I typically also use
{ } around the name, for various reasons.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

read -n 1 -s -r -p "Press any key to continue..."

FWIW, an attempt in C:

getkey.c

#include <stdio.h>
#include <termios.h>
#include <unistd.h>
#include <string.h>

int getkey() {
struct termios oldt, newt;
int ch;
tcgetattr(STDIN_FILENO, &oldt);
newt = oldt;
newt.c_lflag &= ~(ICANON | ECHO);
tcsetattr(STDIN_FILENO, TCSANOW, &newt);
ch = getchar();
tcsetattr(STDIN_FILENO, TCSANOW, &oldt);
return ch;
}

int main(int argc, char **argv) {
if (argc > 1 &&
(strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-h") == 0)) {
printf("Usage: getkey\nPrints a single keypress to stdout.\n");
return 0;
}
int c = getkey();
putchar(c);
return 0;
}

, possible commands:

gcc getkey.c -o getkey

./getkey | xxd

./getkey --help

.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

(BTW, "requires to not require" is a noteworthy formulation.)
What's the reason for that POSIX non-requirement?

Presumably historical practice. Existing implementations wrote a
string without whitespace or shell meta-characters, people had
been using
stty $saved
without quotes, so this was codified.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22/09/2025 at 01:42, Janis Papanagnou wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Another suggestion, to use 'read -n1', maybe in the form of
read -r -t0 -n1
might already suffice, and being a built-in it may be faster.
(The timer -t0 setting is nice for polling.)

Janis

Strikes me neither of these functions do what is described in the getkey manual page (above) which was select a keypress from a list, return 0 if
in list, 1 if not in list. My suggestion (bash):

getkey ()
{
local R S;
(($#==0)) || {
# remove spaces
S="$*";
S="${S// /}";
S="${S,,}";
S+="${S^^}"
};
read -n1 -r -s -p "Press a key ... " R;
if [[ "$R" == [$S] || "$S" == "" ]]; then
printf '%s' "$R";
return 0;
else
echo;
return 1;
fi;
return 255
}

I'm not sufficiently conversant with ksh.
--
Chris Elvidge, England
THE FIRST AMENDMENT DOES NOT COVER BURPING
Bart Simpson on chalkboard in episode 2F22

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22/09/2025 at 01:42, Janis Papanagnou wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Another suggestion, to use 'read -n1', maybe in the form of
read -r -t0 -n1
might already suffice, and being a built-in it may be faster.
(The timer -t0 setting is nice for polling.)

Janis

For ksh tried this:
getkey() {
sstty=$(stty -g)
S="$*"
stty raw -echo
read -n1 -r R?"Press a key ... "
stty $sstty
[[ "$R" == [$S] ]] && printf '%s' "$R" || return 1
}
--
Chris Elvidge, England
FIVE DAYS IS NOT TOO LONG TO WAIT FOR A GUN
Bart Simpson on chalkboard in episode 1F20

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.09.2025 18:05, Chris Elvidge wrote:

On 22/09/2025 at 01:42, Janis Papanagnou wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

[snip]

[anip]

Strikes me neither of these functions do what is described in the getkey manual page (above) which was select a keypress from a list, return 0 if
in list, 1 if not in list.

Yes, that's correct.

Actually, at the moment, I'm not too much concerned about an exact
mimic of the getkey tool described on that web page. I will be able
to get what I need from all the various suggestions and adapt that
as necessary.

There's also various possibilities of how such a tool should behave;
wait for a key-press, wait for a key-press of a specific character
set, poll for a key-press, or poll for a key-press of a specific
character set. Then returning the characters/keys; what/how should,
e.g., a 'Right Arrow' key be returned; that's usually a multi-octet
(and on that abstraction level we might not have access to the key
codes as returned from the keyboard). And so on, and so on...

My suggestion (bash):

getkey ()
{
local R S;
(($#==0)) || {
# remove spaces
S="$*";
S="${S// /}";
S="${S,,}";
S+="${S^^}"
};
read -n1 -r -s -p "Press a key ... " R;
if [[ "$R" == [$S] || "$S" == "" ]]; then
printf '%s' "$R";
return 0;
else
echo;
return 1;
fi;
return 255
}

Thanks.

I'm not sufficiently conversant with ksh.

That's no problem. (As said, I can transcribe it where necessary.)

Janis

PS:
Actually, my real concern stems from another goal; I wanted to have
some "getkey" function available in the Algol 68 Genie interpreter!
It's not supported there so I have to make my mind about the options
how to get that function there. There's a lot options in principle,
most kludgy. My wish would be to have it inherently available as an
Algol 68 function. I could try to write a "C" function to integrate
it in the code of the Genie project. Or I could use the provided
'system' function (or the 'exec' and 'pipe' facilities) of Genie to
call an external tool, as to not touch the code of the Genie project.
Most of these or equivalent workarounds are not very appealing, and
they revealed the necessity for more ugly (and unreliable) kludges.

Need a "simple function", and got wandering from detail to detail...
:-/

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 22.09.2025 03:34, Kaz Kylheku wrote:

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

We were both trained on the same data set, so we predict
about the same tokens.

There's a chance that we're both just AIs? ;-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

(BTW, "requires to not require" is a noteworthy formulation.)

Yes; it makes perfect sense. If I write a document which says not to ask
for the user's personal information before continuing, my document
requires the implementation not to require personal information from
the user. The implementation requires things (from users, environments,
system capabilities) and a documenta about the implementation is
a collection of requirements also.

What's the reason for that POSIX non-requirement? Because the
'stty' data isn't delimited by whitespace?

I don't know, but it's an obvious good idea. The exact
requirement is:

The form used [by stty -g] shall not contain any sequence that would
form an Informational Query, and shall consist of one line of text
consisting of only printable characters from the portable character
set, excluding white-space characters (other than the terminating
<newline>) and these characters that could be altered by pathname
expansion performed by the shell: '*', '?', and '['"

If you get to design this from scratch, it's a good requirement
to add.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-22, Christian Weisgerber <naddy@mips.inka.de> wrote:

On 2025-09-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

(BTW, "requires to not require" is a noteworthy formulation.)
What's the reason for that POSIX non-requirement?

Presumably historical practice. Existing implementations wrote a
string without whitespace or shell meta-characters, people had
been using
stty $saved
without quotes, so this was codified.

Pretty much everything having to do with TTY's contains a lot of POSIX invention. Once upon a time, there wasn't any <termios.h>.
For controlling the TTY, there were ioctls. They were different
and in differnt header files based on whether you were on BSD
or AT&T Unix and whatnot.

The stty command is basically an detailed command line interface
to tcgetattr, tcsetattr and their termios.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-22, Chris Elvidge <chris@internal.net> wrote:

On 22/09/2025 at 01:42, Janis Papanagnou wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>> [...]

Quick proof-of-concept bang-up:

getkey()
{
local save=$(stty -g)
stty raw -echo
local char=$(dd bs=1 count=1 2> /dev/null)
stty $save
printf "%s" "$char"
}

key=$(getkey)

This looks very much like the function I've written for ksh
(in my various tries of all sorts of variants)... :-)

f_getkey () {
stty_g=$( stty -g ) # save state
stty -echo raw
dd bs=1 count=1 2> /dev/null
stty "${stty_g}" # restore state
}

Another suggestion, to use 'read -n1', maybe in the form of
read -r -t0 -n1
might already suffice, and being a built-in it may be faster.
(The timer -t0 setting is nice for polling.)

Janis

Strikes me neither of these functions do what is described in the getkey manual page (above) which was select a keypress from a list, return 0 if
in list, 1 if not in list. My suggestion (bash):

I stopped reading after "getkey: command not found". :)

I figured Janis found that due to searching for a way to get a key, not
for something with some peculiar requirements beyond that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21/09/2025 at 19:15, Janis Papanagnou wrote:

On 21.09.2025 18:29, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions [...]

OK, I found it like this.

On GitHub, I searched for the man page using a source code
search for "path:getkey.1".

Among the results, that led to this project which contains
the man page, and provides C program implementing it:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

I have a problem with that code; it refers to a "popt.h" that leads
to a fatal error when compiling a git clone of that package. (I'm
reluctant to start invest time in projects of this type of quality.
I suppose it's easier to "re-invent" my own tool. *sigh*)

I haven't thought that there would be problems to find some standard
tool. But, OTOH, I had noticed that I already asked for such function
some time ago and also didn't find some "standard" tool. Also on the
Net (where some other folks had also asked for such tools over time)
they often got just snippy responses, and no suggestions. - It seems
to be a hard (or unworthy) request. :-)

Janis

[...]

'gcc -lpopt getkey.c -o getkey' seems to work on slackware.

It's all to do with RPM AFAICS - hence DedRat reference.
Still barfs on up-arrow etc., though.
--
Chris Elvidge, England
I WILL NOT CARVE GODS
Bart Simpson on chalkboard in episode 8F11

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22.09.2025 21:53, Chris Elvidge wrote:

[...]

'gcc -lpopt getkey.c -o getkey' seems to work on slackware.

Maybe. - On my Linux there's no local #include "popt.h" file
(there's neither one locally as part of the package, nor one
in any other directory on my system), so it won't even come
to the stage of linking -lpopt (or other).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 18:29, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

Searching for 'getkey' functions [...]

OK, I found it like this.

On GitHub, I searched for the man page using a source code
search for "path:getkey.1".

Among the results, that led to this project which contains
the man page, and provides C program implementing it:

https://github.com/glensc/rc-scripts/blob/master/src/getkey.c

I have a problem with that code; it refers to a "popt.h" that leads

This is a coding infelicity. The other files like ipcalc.c properly
use angle brackets: #include <popt.h>.

A double quote include, upon failing, will fall back on the same
search strategy as an angle brackets include, but it's bad form
to rely on this. Tsk, tsk!

As could be guessed, popt is another Red Hat thing:

https://github.com/rpm-software-management/popt

The GitHub repos belong to some projects that revolves around
maintaining RPM.

C utilities in something derived from Red Hat Initscripts
depending on some option parsing from RPM: shocker, eh?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 22 Sep 2025 11:29:45 GMT, Stefan Ram wrote:

FWIW, an attempt in C:

HererCOs a Python version demoing a routine that supports an optional
timeout:

import os
import termios
import select

STDINFD = 0
STDOUTFD = 1

assert os.isatty(STDINFD), "Run this script from a real terminal."

def getkey(timeout = None) :
"waits for the user to type a single keystroke and returns it." \
" timeout is optional float number of seconds to wait; if omitted," \
" default is to wait forever."
saveattr = termios.tcgetattr(STDINFD)
try :
newattr = list(saveattr)
newattr[3] &= ~termios.ICANON
termios.tcsetattr(STDINFD, termios.TCSANOW, newattr)
polo = select.poll()
polo.register(STDINFD, select.POLLIN)
evt = polo.poll((lambda : None, lambda : round(timeout * 1000))[timeout != None]())
gotin = list(e for e in evt if e[0] == STDINFD)
if len(gotin) != 0 :
ch = os.read(STDINFD, 1)
else :
ch = None
#end if
finally :
termios.tcsetattr(STDINFD, termios.TCSANOW, saveattr)
#end try
return ch
#end getkey

while True :
os.write(STDOUTFD, "Type something: ".encode())
ch = getkey(1.0)
os.write(STDOUTFD, b"\n")
if ch != None :
os.write(STDOUTFD, ("You typed: %s\n" % repr(ch)).encode())
break
#end if
#end while
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 21.09.2025 16:33 Janis Papanagnou wrote:

https://linux.die.net/man/1/getkey

getkey(1) - Linux man page

Name getkey - wait until a key is pressed
Synopsis getkey [OPTION]... [KEYS]

But that's not available on my Linux systems.

die.net is just a collection of man pages from various systems. Dunno
which they prefer if different distributions ship different manpages
(as certain config files are different there).

Another reason can be that the package that provides that command is
not installed. This also includes the manpage.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Kaz Kylheku <643-408-1753@kylheku.com>:

On 2025-09-22, Janis Papanagnou
<janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou

<janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

local save=$(stty -g)

[rCa]

stty $save

[rCa]

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

As far as I can see, POSIX requires
stty -g
to output one line of text consisting of only printable
characters from the portable character set, excluding white-space
characters (other than the terminating <newline>) and these
characters that could be altered by pathname expansion performed
by the shell: '*', '?', and '['.
As '(', '\', ')', '{', '|', and '}' are nonrCEwhiterCEspace
characters from the portable character set, I prefer not to do
without quoting the variable expansion:
save=$( stty -g )
stty "$save"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-09-23, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:

Kaz Kylheku <643-408-1753@kylheku.com>:

On 2025-09-22, Janis Papanagnou
<janis_papanagnou+ng@hotmail.com> wrote:

On 21.09.2025 21:02, Kaz Kylheku wrote:

On 2025-09-21, Janis Papanagnou

<janis_papanagnou+ng@hotmail.com> wrote:

[...]

Quick proof-of-concept bang-up:

local save=$(stty -g)

[rCa]

stty $save

[rCa]

Why I don't quote the variable holding stty -g settings is that
POSIX requires it not to require quoting.

As far as I can see, POSIX requires

stty -g

to output one line of text consisting of only printable
characters from the portable character set, excluding white-space
characters (other than the terminating <newline>) and these
characters that could be altered by pathname expansion performed
by the shell: '*', '?', and '['.

That requirement is given exactly right with respect to the
intent that youc an write stty $save.

As '(', '\', ')', '{', '|', and '}' are nonrCEwhiterCEspace
characters from the portable character set, I prefer not to do
without quoting the variable expansion:

The above are syntactic tokens in the shell which are not interpreted
as such when they are the result of expansions. (For completness
we should include & && || ; $ -- and what else?)

The result of an unquoted parameter expansion can only undergo word
splitting and pathname expansion.

Treatment of the expansion as other shell syntax requires eval.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Kaz Kylheku <643-408-1753@kylheku.com>:

On 2025-09-23, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:

As far as I can see, POSIX requires


stty -g


to output one line of text consisting of only printable
characters from the portable character set, excluding white-space
characters (other than the terminating <newline>) and these
characters that could be altered by pathname expansion performed
by the shell: '*', '?', and '['.

That requirement is given exactly right with respect to the
intent that youc an write stty $save.

As '(', '\', ')', '{', '|', and '}' are nonrCEwhiterCEspace
characters from the portable character set, I prefer not to do
without quoting the variable expansion:

The above are syntactic tokens in the shell which are not interpreted
as such when they are the result of expansions.

[rCa]

The result of an unquoted parameter expansion can only undergo word splitting and pathname expansion.

Treatment of the expansion as other shell syntax requires eval.

You are right.-a I apologize.-a But it won't do any harm to
quote anyway?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Helmut Waitzmann wrote:

Kaz Kylheku <643-408-1753@kylheku.com>:

On 2025-09-23, Helmut Waitzmann <nn.throttle@xoxy.net> wrote:

As far as I can see, POSIX requires

stty -g

to output one line of text consisting of only printable
characters from the portable character set, excluding white-space
characters (other than the terminating <newline>) and these
characters that could be altered by pathname expansion performed
by the shell: '*', '?', and '['.

That requirement is given exactly right with respect to the
intent that you can write stty $save.

[...]

But it won't do any harm to quote anyway?

Indeed, and the example code in POSIX does so. Without the parts
to save and restore the terminal size, it is:

saveterm=$(stty -g)
...
[ -n "$saveterm" ] && stty "$saveterm"
--
Geoff Clare <netnews@gclare.org.uk>
--- Synchronet 3.21a-Linux NewsLink 1.2