By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,680 Members | 1,578 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,680 IT Pros & Developers. It's quick & easy.

How does ESC key interact with ANSI C programs?

P: n/a
hugo27 July 13, 2004

The teachy books and documentation I've read do not
mention the Escape key, but everytime I hit it during
runtime my programs go bananas.

This relates to a larger issue, namely, what is
standard C good for? Of what use is it?
We have the null set: each person writes and
uses their own progams. This works to a degree, but
it makes for a small world. What happens when you
venture into the larger world and meet up with
Other People (aka, The Damm Thing)?
Suppose one writes a common menu program for an
employer and someone sonetime presses ESC, the
program crashes, and the client wants their money
back? Are you going to tell the judge that the
complaint is Off Topic?

Is there a way in ANSI C to disable or manage
the Escape key? I've tried capturing ascii 27
with scanf and getchar, but it drives the program
batty.

Thanks for your thoughts.
hugo

Nov 14 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
[newbie answer]
hugo27 wrote:
Is there a way in ANSI C to disable or manage
the Escape key?


I guess there isn't.

A microwave oven could have programs written in ANSI C.
A mobile phone could have programs written in ANSI C.
A electronic stopwatch could have programs written in ANSI C.
....

Where is the Escape key in all these things? :-)

--
USENET would be a better place if everybody read: | to email me: use |
http://www.catb.org/~esr/faqs/smart-questions.html | my name in "To:" |
http://www.netmeister.org/news/learn2quote2.html | header, textonly |
http://www.expita.com/nomime.html | no attachments. |
Nov 14 '05 #2

P: n/a

"hugo27" <ob****@yahoo.com> wrote in message
news:a7**************************@posting.google.c om...
hugo27 July 13, 2004

The teachy books and documentation I've read do not
mention the Escape key, but everytime I hit it during
runtime my programs go bananas.

This relates to a larger issue, namely, what is
standard C good for? Of what use is it?
We have the null set: each person writes and
uses their own progams. This works to a degree, but
it makes for a small world. What happens when you
venture into the larger world and meet up with
Other People (aka, The Damm Thing)?
Suppose one writes a common menu program for an
employer and someone sonetime presses ESC, the
program crashes, and the client wants their money
back? Are you going to tell the judge that the
complaint is Off Topic?

Is there a way in ANSI C to disable or manage
the Escape key?
No, because ANSI (formally "ISO") C does not define
such a thing as a 'key', a 'keyboard', or any hardware
devices at all. All i/o is abstracted as 'streams of
characters'.
I've tried capturing ascii 27


The ASCII character set does define a value 27 with
the mnemonic 'ESC', but that doesn't necessarily
correspond to what a PC keyboard's 'escape' key
generates.

The C language does not require using the ASCII character
set. It allows any character set which contains the mimimum
set of characters required by the standard. The actual encodings
of these characters is left to the implementation. None of them
is called 'escape'.
with scanf and getchar, but it drives the program
batty.


On a typical PC, neither 'scanf()' nor 'getchar()' will 'see'
any input from the 'ESC' key. It doesn't generate a 'character'
from the perspective of C's i/o library.

You'll need to use a library 'extension' (if your implementation
provides one), or perhaps a third party library.

What you're trying to do involves direct communication with
your operating system and/or hardware, neither of which is
supported by ISO C.

E.g. if you're working with a Windows system, try www.msdn.microsoft.com

-Mike
Nov 14 '05 #3

P: n/a

"Pedro Graca" <he****@hotpop.com> wrote in message
news:sl*******************@ID-203069.user.uni-berlin.de...
[newbie answer]
hugo27 wrote:
Is there a way in ANSI C to disable or manage
the Escape key?


I guess there isn't.

A microwave oven could have programs written in ANSI C.
A mobile phone could have programs written in ANSI C.
A electronic stopwatch could have programs written in ANSI C.
...

Where is the Escape key in all these things? :-)


Prison security control systems could be written in C.
The hardware probably won't have an escape key. :-)

-Mike

Nov 14 '05 #4

P: n/a
In article <sl*******************@ID-203069.user.uni-berlin.de>,
Pedro Graca <he****@hotpop.com> wrote:
[newbie answer]
hugo27 wrote:
Is there a way in ANSI C to disable or manage
the Escape key?


I guess there isn't.

A microwave oven could have programs written in ANSI C.
A mobile phone could have programs written in ANSI C.
A electronic stopwatch could have programs written in ANSI C.
...

Where is the Escape key in all these things? :-)


Why, in the same place where the "&" key is.

--
rr
Nov 14 '05 #5

P: n/a
ob****@yahoo.com (hugo27) writes:
hugo27 July 13, 2004

The teachy books and documentation I've read do not
mention the Escape key, but everytime I hit it during
runtime my programs go bananas.
We have no way of knowing why that happens without more details. The
C standard says nothing about the escape key. On any system I've
used, I wouldn't expect hitting escape while a program is running to
do anything more drastic than hitting the space bar, unless the
program itself (or some routine it calls) specifically handles it.

It would also be useful to know what you mean by "go bananas".

You don't mention what operating system you're using; since your
problem is probably system-specific, that could be a vital piece of
information.

You mention a "menu program", which leads me to guess that you're
using the curses library on a Unix-like system. If so, you may be
having problems with escape sequences. Arrow keys, for example,
typically send sequences starting with <escape>, and your program
could be seeing the <escape> and waiting for the rest of the sequence.

This is not an ISO C (or ANSI C, if you prefer) issue. If my guess is
correct, you should consult your documentation; if that doesn't work,
try searching the web; if that doesn't work, ask in comp.unix.programmer,
but be sure to provide more details than you've given us here. (If my
guess isn't correct, replace comp.unix.programmer with some newsgroup
appropriate to your system.)
This relates to a larger issue, namely, what is
standard C good for? Of what use is it?


No, it really doesn't.

One more thing: when you post to Usenet, *please* don't start each
line you write with '>'. The '>' characters you see in Usenet
postings aren't just decorative; they indicate text that you've quoted
from somebody else's article. If every line of your article starts
with '>', it looks like you've replied to someone else without adding
anything of your own, and you're likely to be ignored.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #6

P: n/a
hugo27 wrote:
The teachy books and documentation [that] I've read
do not mention the Escape key
but, everytime I hit it during runtime,
my programs go bananas. This relates to a larger issue, namely,
what is standard C good for? Of what use is it?
We have the null set: each person writes and
uses their own progams. This works to a degree,
but it makes for a small world.
What happens when you venture into the larger world
and meet up with Other People (aka, The Damm Thing)?
Suppose one writes a common menu program for an
employer and someone sonetime presses ESC,
the program crashes,
and the client wants their money back?
Are you going to tell the judge that
the complaint is Off Topic? Is there a way in ANSI C
to disable or manage the Escape key?
I've tried capturing ascii 27 with scanf and getchar,
but it drives the program batty.
cat main.c #include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
int c = '\0';
while (EOF != (c = getchar()))
fprintf(stdout, "%d\n", c);
return EXIT_SUCCESS;
}
gcc -Wall -std=c99 -pedantic -o main main.c
./main 13
49
51
10
^[
27
10 gcc --version

gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

I typed ^D to input End Of File (EOF) to terminate the program.
It seems to work fine for me.

This is the comp.lang.c newsgroup and not the
everything.you.need.to.know.about.computer.program ming newsgroup.
You will need to consult other resources
if you need to write platform dependent device drivers.
We don't know everything -- we're just know-it-alls --
but, if you tell us which platform is a target for your C program,
we may be able to redirect your question to a more appropriate forum
where you can get reliable expert advice.

platform = computer architecture + operating system + C compiler

Nov 14 '05 #7

P: n/a
>>The teachy books and documentation I've read do not
mention the Escape key, but everytime I hit it during
runtime my programs go bananas.
What brand of bananas?
You need to be more explicit what happens. I have some problems
with the computer rebooting every time I press the RESET button,
and it seems to go completely dead if I press the POWER OFF button.
Bug reports on this topic generally go unanswered for some reason.

If your platform even HAS an escape key, it's just a character.
A sequence beginning with the escape character (including one
that is echoed) might cause your terminal to do something special.

Some technical terms:

"doesn't work" means that at least 4 members of an AFL-CIO union
are picketing outside your house or place of residence carrying
signs that have at least the word "UNFAIR" on them.

"crashes" means that a reboot is required to get the operating
system working again. It is unusual for an operating system
with memory protection to have problems with a user-level
program crashing it, but some vendors manage to have bugs like this.
Suppose one writes a common menu program for an
employer and someone sonetime presses ESC, the
program crashes, and the client wants their money
back?
What platform does this happen on? Your program should be
able to tell the user that escape isn't a valid choice, and
repeat the menu.

It is unnecessary to trap() characters, with or without bait().
Neither of those functions are supported by ANSI C or much
of anything else.
Is there a way in ANSI C to disable or manage
the Escape key? I've tried capturing ascii 27
with scanf and getchar, but it drives the program
batty.


How did you do this? Most platforms don't support capture(),
trap(), or bait().

"batty": the program runs around in a cape and mask searching
for The Penguin, but ends up capturing Linus instead.

Gordon L. Burditt
Nov 14 '05 #8

P: n/a
In <a7**************************@posting.google.com > ob****@yahoo.com (hugo27) writes:
The teachy books and documentation I've read do not
mention the Escape key, but everytime I hit it during
runtime my programs go bananas.
Mine don't. They have no reason to.
This relates to a larger issue, namely, what is
standard C good for? Of what use is it?
Writing code that works everywhere. Or, more realistically, writing
code whose non-portable sections can be isolated from the portable
sections, so only the former need to be touched in the porting process.
The smaller they are, the easier to port the code.
We have the null set: each person writes and
uses their own progams. This works to a degree, but
it makes for a small world. What happens when you
venture into the larger world and meet up with
Other People (aka, The Damm Thing)?
Nothing special.
Suppose one writes a common menu program for an
employer and someone sonetime presses ESC, the
program crashes, and the client wants their money
back? Are you going to tell the judge that the
complaint is Off Topic?
No, but I have yet to write a program that crashes when the user presses
the ESC key. Can you show me some sample code, so that I get a clue about
how to do it (other than by *explicitly* testing for the ESC character and
deliberately crashing the program when finding it in the user input, of
course)?
Is there a way in ANSI C to disable or manage
the Escape key? I've tried capturing ascii 27
with scanf and getchar, but it drives the program
batty.


It should be trivial to detect the ESC character in user input, but
why bother? It's much easier to only focus on correct user input and
reject everything else as bad input.

For much better advice, post some code causing problems when the ESC
key is pressed and accurately describe the nature of those problems.

If I accidentally press the ESC key while providing input to my programs,
the tty driver displays ^[, the convetional printable representation of
the ASCII ESC character. I can press the backspace key to remove it,
just as I can press the backspace key to remove any typo.

Here's a sample/simple program:

fangorn:~/tmp 426> cat test.c
#include <stdio.h>
#include <string.h>

#define ESC '\33'
char buf[BUFSIZ];

int main()
{
if (fgets(buf, sizeof buf, stdin) == NULL) return 0;
if (strchr(buf, ESC) == NULL) printf("No ");
puts("ESC detected in user input.");
return 0;
}
fangorn:~/tmp 427> gcc test.c
fangorn:~/tmp 428> ./a.out
qwertyuioighj
No ESC detected in user input.
fangorn:~/tmp 429> ./a.out
qwer^[erty
ESC detected in user input.

Yeah, for toy programs, even fgets is good enough ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #9

P: n/a
Dan Pop wrote:
No, but I have yet to write a program that crashes when the user presses
the ESC key. Can you show me some sample code, so that I get a clue about
how to do it (other than by *explicitly* testing for the ESC character and
deliberately crashing the program when finding it in the user input, of
course)?

I tried what he said with my text adventure game, running under windows,
and it does crash when the input from the user is <ESC> <ENTER>. The
program reports back that [some long line of screen-draw characters] is
not a valid verb, then the system itself pops a dialog: The instruction
at "0x6f36572" referenced memory at "0x6f36572". The memory could not be
"read".

I'll have to run through in debug and see if I can figure out why it's
doing that. Probably a bug on my end. Doesn't happen under Solaris.


Brian Rodenborn
Nov 14 '05 #10

P: n/a
"Default User" <fi********@boeing.com.invalid> wrote in message
news:40**************@boeing.com.invalid...
Dan Pop wrote:
No, but I have yet to write a program that crashes when the user presses
the ESC key. Can you show me some sample code, so that I get a clue about how to do it (other than by *explicitly* testing for the ESC character and deliberately crashing the program when finding it in the user input, of
course)?

I tried what he said with my text adventure game, running under windows,
and it does crash when the input from the user is <ESC> <ENTER>. The
program reports back that [some long line of screen-draw characters] is
not a valid verb, then the system itself pops a dialog: The instruction
at "0x6f36572" referenced memory at "0x6f36572". The memory could not be
"read".

I'll have to run through in debug and see if I can figure out why it's
doing that. Probably a bug on my end. Doesn't happen under Solaris.


When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead) on
the keyboard with failing.

IOW, any input stream should be "sanity checked" before use.

--
Mabden
Nov 14 '05 #11

P: n/a
"Mabden" <mabden@sbc_global.net> wrote in message
news:o9*******************@newssvr29.news.prodigy. com...
"Default User" <fi********@boeing.com.invalid> wrote in message
news:40**************@boeing.com.invalid... When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead) on the keyboard with failing.
hehe that should read "without failing"!

IOW, any input stream should be "sanity checked" before use.


--
Mabden
Nov 14 '05 #12

P: n/a
Mabden wrote:

"Default User" <fi********@boeing.com.invalid> wrote in message
news:40**************@boeing.com.invalid...

I'll have to run through in debug and see if I can figure out why it's
doing that. Probably a bug on my end. Doesn't happen under Solaris.


When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead) on
the keyboard with failing.

IOW, any input stream should be "sanity checked" before use.

Well, it's supposed to be. The problem is, I'm not sure what that ESC is
actually doing, vis--vis fgets(). I'll have to check and see.


Brian Rodenborn
Nov 14 '05 #13

P: n/a
Mabden writes:
When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead) on the keyboard with failing.

IOW, any input stream should be "sanity checked" before use.


I don't think that is possible in the case of using the Windows OS. I know
of no meaningful specification on Windows, Microsoft says "Here it is, it
does what it does, give me some money." Windows captures ^ c and ^ z before
they even get to the user. What else do they capture and fiddle with?
Certainly ESC is a candidate for capturing by the OS and in particular by
Microsoft written and/or influenced programs because of Windows widespread
use of ESC to clear the most recent dialog box/whatever. I wouldn't be
surprised if some other program captured ESC and forget to restore it to the
proper state when done.

You need a comprehensive list of signals that *your* program can expect to
receive to do a complete sanity check, I don't think such a list exists.
Nov 14 '05 #14

P: n/a
Default User wrote:
Well, it's supposed to be. The problem is, I'm not sure what that ESC is
actually doing, vis--vis fgets(). I'll have to check and see.


Actually, it's doing nothing, literally. The ESC generates no input
character on stdin. The bug was something else entirely.

Brian Rodenborn
Nov 14 '05 #15

P: n/a
On Wed, 14 Jul 2004 14:55:58 -0700, in comp.lang.c , "osmium"
<r1********@comcast.net> wrote:
Mabden writes:
When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead)on
the keyboard with failing.

IOW, any input stream should be "sanity checked" before use.


I don't think that is possible in the case of using the Windows OS.


Actually, it is, at least to the same extent as any other OS.
does what it does, give me some money." Windows captures ^ c and ^ z before
they even get to the user.
Nope. You can capture both these yourself. Even with Visual Basic. And FWIW
most unices capture control D and others, so W32 would not be unique in
that.
You need a comprehensive list of signals that *your* program can expect to
receive to do a complete sanity check, I don't think such a list exists.


This is true.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #16

P: n/a
On Wed, 14 Jul 2004 14:55:58 -0700, in comp.lang.c , "osmium"
<r1********@comcast.net> wrote:
Mabden writes:
When I was learning to program a wise man once told me that any program I
write should be able to handle the user smashing their fist (or forehead)on
the keyboard with failing.

IOW, any input stream should be "sanity checked" before use.


I don't think that is possible in the case of using the Windows OS.


Actually, it is, at least to the same extent as any other OS.
does what it does, give me some money." Windows captures ^ c and ^ z before
they even get to the user.
Nope. You can capture both these yourself. Even with Visual Basic. And FWIW
most unices capture control D and others, so W32 would not be unique in
that.
You need a comprehensive list of signals that *your* program can expect to
receive to do a complete sanity check, I don't think such a list exists.


This is true.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #17

P: n/a
osmium wrote:
[...]
I don't think that is possible in the case of using the Windows OS. I know
of no meaningful specification on Windows, Microsoft says "Here it is, it
does what it does, give me some money." Windows captures ^ c and ^ z before
they even get to the user.
Only if you don't set the modes to tell Windows to pass them through.
What else do they capture and fiddle with?
Nothing, if you tell it so.
Certainly ESC is a candidate for capturing by the OS and in particular by
Microsoft written and/or influenced programs because of Windows widespread
use of ESC to clear the most recent dialog box/whatever. I wouldn't be
surprised if some other program captured ESC and forget to restore it to the
proper state when done.
Set raw input mode (how to do this is platform-specific and off-topic
for c.l.c) and you will get everything exactly as the user types it.

I have an application that "sees" every keystroke that isn't explicitly
defined by Windows (such as Alt-Tab) for Windows' own use. Ctrl-C, Ctrl-Z,
and ESC are read as they should be -- 0x03, 0x1A, and 0x1B, respectively.

Certainly a program crash simply by pressing a key means there is something
drastically wrong with the program in question.
You need a comprehensive list of signals that *your* program can expect to
receive to do a complete sanity check, I don't think such a list exists.


--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Nov 14 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.