Linux: Unbuffered reading from stdin

[Markus Mayer]

Hi folks.

I'm somewhat new to *nix programming and just ran into a problem. I have
to take user input from the terminal but like to constrain that to some
rules given, i.e. "numbers only" or "alphanumer ic only" etc.
scanf would do, but I don't like the fact that wrong ('disallowed')
characters are visible and all that stuff. For that I need unbuffered
input. Since there seems to be no atomic function to do that I tried to
fiddle around with ioctl() and that seems to work fine. Currently I flag
out ICANON and ECHO from the tty descriptor, set a minimum input of 1
byte, getch() or read() a byte, check, printf(), fine.
However things become nasty when the user presses an key that sends an
escape sequence. I've seen some code on the web that does the following
approach: Check for character==27. If so, read() 4 bytes into a buffer,
zero terminate the buffer accordingly then strcmp() the buffer against
the actual escape sequences.

But then there are two problems:

1) The escape sequences seem to change with every terminal type. On my
terminal the codes for F1 to F5 are ^OP, ^OQ, ^OR, ^OS, ^[15~ (etc)
while on the code given in the web they used to be [[A, [[B etc.
Are there some defines?

2) What happens when the user presses just ESC? Sounds easy to me, just
check if there are no more chars in stdin - but how do you do that? By
just read()ing STDIN_FILENO after an ESC the terminal is blocked until
another key is pressed - that is not really what I want.

Any ideas? Or am I reinventing the wheel?
Regards,
Markus

[Ian Malone]

Re: Linux: Unbuffered reading from stdin

Markus Mayer wrote:

Hi folks.
>
I'm somewhat new to *nix programming and just ran into a problem. I have
to take user input from the terminal but like to constrain that to some
rules given, i.e. "numbers only" or "alphanumer ic only" etc.
scanf would do, but I don't like the fact that wrong ('disallowed')
characters are visible and all that stuff. For that I need unbuffered
input.

However things become nasty when the user presses an key that sends an
escape sequence.

Any ideas? Or am I reinventing the wheel?

This is really a comp.unix.progr amming question, but it
sounds like ncurses is what you want.

--
imalone

[Markus Mayer]

Re: Linux: Unbuffered reading from stdin

Am 22.10.2007 13:24 postulierte Markus Mayer folgendes:

[...]
2) What happens when the user presses just ESC? Sounds easy to me, just
check if there are no more chars in stdin - but how do you do that? By
just read()ing STDIN_FILENO after an ESC the terminal is blocked until
another key is pressed - that is not really what I want.

D'oh ... that was a dumb one. By reading a maximum of n bytes into the
buffer I can check bytes 2..n if buffer[0] is 27. Okay - done.

Are there other solutions though?

Regards,
Markus

[Markus Mayer]

Re: Linux: Unbuffered reading from stdin

Am 22.10.2007 13:38 postulierte Ian Malone folgendes:

Markus Mayer wrote:

>Hi folks.
>>
>I'm somewhat new to *nix programming and just ran into a problem. I have
>to take user input from the terminal but like to constrain that to some
>rules given, i.e. "numbers only" or "alphanumer ic only" etc.
>scanf would do, but I don't like the fact that wrong ('disallowed')
>characters are visible and all that stuff. For that I need unbuffered
>input.

>

>However things become nasty when the user presses an key that sends an
>escape sequence.

>
This is really a comp.unix.progr amming question, but it
sounds like ncurses is what you want.
>

Haven't seen that group, thanks! I'll have a deeper look at ncurses, but
from what I've see so far I think that I'm not allowed to use it; I
really have to do it 'on my own'. :/

Thanks anyway!
Markus

[santosh]

Re: Linux: Unbuffered reading from stdin

Markus Mayer wrote:

<about handling escape sequences and special characters in unbuffered
input>

Just use ncurses and ask in a UNIX group like
<news:comp.unix .programming>

[Coos Haak]

Re: Linux: Unbuffered reading from stdin

Op Mon, 22 Oct 2007 18:26:28 +0530 schreef santosh:

Markus Mayer wrote:
>
<about handling escape sequences and special characters in unbuffered
input>
>
Just use ncurses and ask in a UNIX group like
<news:comp.unix .programming>

<news:comp.unix .programmer>
--
Coos

[CBFalconer]

Re: Linux: Unbuffered reading from stdin

Ian Malone wrote:

Markus Mayer wrote:
>

>I'm somewhat new to *nix programming and just ran into a problem.
>I have to take user input from the terminal but like to constrain
>that to some rules given, i.e. "numbers only" or "alphanumer ic
>only" etc. scanf would do, but I don't like the fact that wrong
>('disallowed ') characters are visible and all that stuff. For
>that I need unbuffered input.
>>
>However things become nasty when the user presses an key that
>sends an escape sequence.
>>
>Any ideas? Or am I reinventing the wheel?

>
This is really a comp.unix.progr amming question, but it
sounds like ncurses is what you want.

No, he needs getc and ungetc. A simple routine can input numbers
from a stream with that, and ensure the terminating (non-numeric)
character is left in the stream.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>



--
Posted via a free Usenet account from http://www.teranews.com

[David Thompson]

Re: Linux: Unbuffered reading from stdin

#if offtopic == pet_peeve

On Mon, 22 Oct 2007 13:24:49 +0200, Markus Mayer
<contact.me.via .my.website@def x.dewrote:

I'm somewhat new to *nix programming and just ran into a problem. I have
to take user input from the terminal but like to constrain that to some
rules given, i.e. "numbers only" or "alphanumer ic only" etc.
scanf would do, but I don't like the fact that wrong ('disallowed')
characters are visible and all that stuff. For that I need <snip>

Aside: Personally I don't share your goal. I would rather _see_ what I
entered -- with any retained invisible bits made visible, e.g. caret,X
for control-X -- plus a statement of why it's wrong and/or what would
be permitted. The allegedly user-friendly interface in my experience
seems to encourage the approach of 'oh, just push keys (or click) at
random until something happens that appears more or less right'. But
this is personal taste; I don't mind _you_ wanting it the other way.

However things become nasty when the user presses an key that sends an
escape sequence. I've seen some code on the web that does the following
approach: Check for character==27. If so, read() 4 bytes into a buffer,
zero terminate the buffer accordingly then strcmp() the buffer against
the actual escape sequences.
>
But then there are two problems:
>
1) The escape sequences seem to change with every terminal type. On my
terminal the codes for F1 to F5 are ^OP, ^OQ, ^OR, ^OS, ^[15~ (etc)
while on the code given in the web they used to be [[A, [[B etc.
Are there some defines?
>

Not really. Although I'm a bit surprised you can still find today many
different real terminals or even emulators, there used to be a huge
variety. There are some standards, notably ANSI X3.64 (I suppose now
INCITS 64), which was used on a large scale by DEC's VT100 and VT200
series and by the now prevalent Xwindows utility xterm. But even that
standard has portions that may be varied by each implementor/ation.

This is precisely why vanilla Unix tty drivers don't even try to deal
with it; they only support sequential, across-and-down-the-page,
printable plus CR LF/NL, probably BS, and maybe HT. And similarly
TELNET the protocol goes very little beyond this (although specific
TELNET _clients_ may do more), and also the CCITT equivalent X.3 if
you can find anyone who even knows of it much less uses it.

2) What happens when the user presses just ESC? Sounds easy to me, just
check if there are no more chars in stdin - but how do you do that? By
just read()ing STDIN_FILENO after an ESC the terminal is blocked until
another key is pressed - that is not really what I want.
>

The conventional approach is a short timeout, which in Unix would be
poll, select, or similar probably combined with nonblocking I/O.
But if your transmission path is anything more complicated than an
actual hardwired RS232 cable (which is limited to 50ft; well, or
RS42x/385IIRC up to maybe a thousand feet) then occasionally you will
get delays introduced to the middle of your input stream due to
encoding, routing, retransmission, congestion, or whatever and your
code will, like the villain in Indiana Jones (3?), 'choose badly'.
When this happens, the program and the terminal get out of sync, and
unless the user recognizes it quickly AND the program provides a way
to recover (such as vi ^L 're-draw') it can lead to corrupted files
and databases and even things like unintended stock trades.

The other alternative is just have people not use the ESC key. Some
people, or more commonly their organizations, used to physically
remove or block the ESC key on real physical terminals dedicated to an
application/system. Nowadays if you're using the same PC for your
terminal emulator and for other tasks you probably can't allow that.

Any ideas? Or am I reinventing the wheel?

Yes. As others have noted, the most widespread and established
solution for this, and probably most convenient for you, is (are?) the
various variants of curses/ncurses. There were plenty of other
attempts, although the ones I knew of were mostly tied to particular
systems or applications or both; but if you're interested I warn you
this can be a giant time sink -- in the '70s and into the '80s, there
were quite a few people whose fulltime job, or a major chunk of it,
was keeping track of and coping with different 'smart' terminal types
and in particular their protocols. The folks on alt.folklore.co mputers
probably can help you, but it's such hightraffic I don't have time to
follow it myself except for occasional crossposts.

#endif
- formerly david.thompson1 || achar(64) || worldnet.att.ne t