#if offtopic == pet_peeve
On Mon, 22 Oct 2007 13:24:49 +0200, Markus Mayer
<co***********************@defx.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 "alphanumeric 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.computers
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.net
