H
hugo27
hugo27 July 13, 2004
P
Pedro Graca
[newbie answer]
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?
hugo27 said:
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?
M
Mike Wahler
hugo27 said:
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'.
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'.
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
M
Mike Wahler
Pedro Graca said:[newbie answer]
hugo27 said:
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
R
Rouben Rostamian
[newbie answer]
hugo27 said:
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.
E
E. Robert Tisdale
hugo27 said:
#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;
}
13
49
51
10
^[
27
10
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.programming 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
K
Keith Thompson
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.)
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.
G
Gordon Burditt
The teachy books and documentation I've read do not
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.
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.
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
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.
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.
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
D
Dan Pop
In said:
Mine don't. They have no reason to.
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.
Nothing special.
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)?
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
D
Default User
Dan said:
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
M
Mabden
Default User said:
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.
M
Mabden
Mabden said:
hehe that should read "without failing"!
D
Default User
Mabden said:
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
O
osmium
Mabden said:
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.
D
Default User
Default said:
Actually, it's doing nothing, literally. The ESC generates no input
character on stdin. The bug was something else entirely.
Brian Rodenborn
M
Mark McIntyre
Actually, it is, at least to the same extent as any other OS.
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.
This is true.
M
Mark McIntyre
Actually, it is, at least to the same extent as any other OS.
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.
This is true.
K
Kenneth Brody
osmium wrote:
[...]
Only if you don't set the modes to tell Windows to pass them through.
Nothing, if you tell it so.
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.
[...]
Only if you don't set the modes to tell Windows to pass them through.
Nothing, if you tell it so.
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.