how to find that escape key is pressed while taking the string

S

sudhir

hi

how to check escape key is pressed when accepting the string as input.
Because I do not want to receive a string if user presses the ESCAPE
key.. I used ascii code for comparision but I didn't get any fruitful
results. Please help me.
 
F

Flash Gordon

sudhir said:
how to check escape key is pressed when accepting the string as input.
Because I do not want to receive a string if user presses the ESCAPE
key.. I used ascii code for comparision but I didn't get any fruitful
results. Please help me.

You will have to use some system specific extension, so I suggest you
ask in a group dedicated to whichever system you are using.
 
W

Walter Roberson

how to check escape key is pressed when accepting the string as input.
Because I do not want to receive a string if user presses the ESCAPE
key.. I used ascii code for comparision but I didn't get any fruitful
results. Please help me.

The escape key isn't portable ;-)

If you have an input string that you know to be ASCII (or ISO-8859-*)
then you can test each character against the ASCII escape value, which
you can code in several different ways. One such way would be

#include <string.h>
#define ESCAPE '\027'

.....

if ( strchr( STRING, ESCAPE ) != NULL ) { /* you got an ESCAPE */ }



Note that your operating system or shell might be "eating" the escape
character before sending it on to you. Mechanisms to prevent that
happening are operating-system specific and best explored in a
newsgroup specific to your operating system.
 
K

Keith Thompson

sudhir said:
how to check escape key is pressed when accepting the string as input.
Because I do not want to receive a string if user presses the ESCAPE
key.. I used ascii code for comparision but I didn't get any fruitful
results. Please help me.

Please help us to help you. If you'll show us the code you've tried
*and* tell us how it misbehaves, we can help you determine why it
doesn't work.

If you want to terminate the attempt to read a line immediately if the
user presses ESCAPE, there's no portable way to do that; see question
19.1 in the comp.lang.c FAQ, <http://www.eskimo.com/~scs/C-faq/faq.html>.

Walter Roberson's also gave you some excellent advice.
 
M

Mike Wahler

sudhir said:
hi

how to check escape key is pressed when accepting the string as input.
Because I do not want to receive a string if user presses the ESCAPE
key.. I used ascii code for comparision but I didn't get any fruitful
results. Please help me.

The C language does not see 'keystrokes', it only sees 'streams
of characters' as input. Some character sets, such as ASCII do
define an 'escape' character, but pressing an 'escape' key on
a keyboard might or might not insert such a character into C's
'standard input stream'. Your best bet is to find a platform
specific solution (and ideally isolate it in your code for ease
of porting). Often a compiler targeting a system where it's
appropriate will provide a function for direct hardware (and/or
driver) interface, such as with a keyboard. There also exist
third party libraries for such things, which are portable among
a certain set of platforms. But none of this is standard C,
thus not topical here.

-Mike
 
W

Walter Roberson

The C language does not see 'keystrokes', it only sees 'streams
of characters' as input. Some character sets, such as ASCII do
define an 'escape' character, but pressing an 'escape' key on
a keyboard might or might not insert such a character into C's
'standard input stream'. Your best bet is to find a platform
specific solution (and ideally isolate it in your code for ease
of porting).

Well, since we don't talk much about Unicode or i18n
(internationalization) here, I don't think we are going -too- far
astray to admit that ASCII characters beyond the basic execution set
exist, and if we do not insist that someone must head to another newgroup
if they don't mind the minor portability loss of assuming ASCII
compatability.


I'm not sure I want to see the "portable" equivilent to

#include <stdio.h>
int main(void) { puts("That's my $0.02 worth!"); return 0; }
 
J

Joe Wright

Walter said:
Well, since we don't talk much about Unicode or i18n
(internationalization) here, I don't think we are going -too- far
astray to admit that ASCII characters beyond the basic execution set
exist, and if we do not insist that someone must head to another newgroup
if they don't mind the minor portability loss of assuming ASCII
compatability.
We don't talk about Unicode or i18n at all. There are no ASCII
characters beyond the basic execution set (0..127). There is no 8-bit
ASCII character. Not One.
I'm not sure I want to see the "portable" equivilent to

#include <stdio.h>
int main(void) { puts("That's my $0.02 worth!"); return 0; }

I don't see anything obviously wrong. What's the problem?
 
K

Keith Thompson

Joe Wright said:
Walter Roberson wrote: [...]
I'm not sure I want to see the "portable" equivilent to
#include <stdio.h>
int main(void) { puts("That's my $0.02 worth!"); return 0; }

I don't see anything obviously wrong. What's the problem?

'$' is not guaranteed to be a member of the execution character set.
(Though if it isn't, I don't think there's even a non-portable way to
do the same thing, unless you allow replacing '$' by 'USD'.)
 
M

Mike Wahler

Walter Roberson said:
Well, since we don't talk much about Unicode or i18n
(internationalization) here, I don't think we are going -too- far
astray to admit that ASCII characters beyond the basic execution set
exist,

I never denied that they do.
and if we do not insist that someone must head to another newgroup
if they don't mind the minor portability loss of assuming ASCII
compatability.

But an implementation can be fully 'ASCII compatible', without
necessitating platform-specific behavior, such as keyboard
interfaces. After all, the ASCII standard makes no requirements
pertaining to keyboards.

Or have I somehow misunderstood whatever point you're
trying to make?
I'm not sure I want to see the "portable" equivilent to

#include <stdio.h>
int main(void) { puts("That's my $0.02 worth!"); return 0; }

The portable equivalent isn't that bad:
Insert #include <locale.h> and one call to 'setlocale()'.

(That is, unless you demand the
current exchange rate taken into account). :)

-Mike
 
M

Mike Wahler

Mike Wahler said:
The portable equivalent isn't that bad:
Insert #include <locale.h> and one call to 'setlocale()'.

and 'localeconv()' (which of course means using 'printf()'
instead of 'puts()'


-Mike
 
J

Jordan Abel

We don't talk about Unicode or i18n at all. There are no ASCII
characters beyond the basic execution set (0..127).

The basic execution character set only contains 96 characters:

NUL TAB LF VT SP
! " # % & ' ( ) * + , - . / : ; < = >
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _
a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~

ASCII contains, according to you, 0..127, including 32 that are not in
the basic execution set:

SOH STX ETX EOT ENQ ACK BEL BS FF CR SO SI
DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
$ @ ` DEL
 
W

Walter Roberson

Well, since we don't talk much about Unicode or i18n
(internationalization) here, I don't think we are going -too- far
astray to admit that ASCII characters beyond the basic execution set
exist,
[/QUOTE]
We don't talk about Unicode or i18n at all. There are no ASCII
characters beyond the basic execution set (0..127). There is no 8-bit
ASCII character. Not One.

All that C guarantees about the basic execution set is that it
includes the basic source set together with alert, backspace, carriage
return, and newline. No promises are made about the values that
any of the 91 mandated printable characters will assume upon execution,
other than that 0 thru 9 shall be consequative.
There are no ASCII
characters beyond the basic execution set (0..127).

But the basic execution set is *not* 0..127: it is the 91 printables,
and a handful of whitespace and control characters, no matter -what-
values those assume internally. Executing in EBCDIC is perfectly legal
in C.
I don't see anything obviously wrong. What's the problem?

You have assumed the existance of characters beyond the basic
execution set -- in this case, the existance of the dollar sign.
And by your comments, you have assumed ASCII.

In C, any use of information such as 'A' == 65 or 'A' + 1 == 'B'
is non-portable. Any use of @, $, or ` is non-portable.
Any assumption of the existance of escape or any control other than
\a \b \t \n \r \t \v is not portable.

We don't talk about Unicode or i18n at all.

Quite -- and yet we also do not wag our fingers every time someone
uses $ or build in an assumption about character values into their
programs. To be consistant, every time someone uses $ or @ or `
we should be telling them to go find another newsgroup because
they have used a system-specific feature... but we don't.

This suggests to me that in clc, the presumption of ASCII is
-generally- acceptable, except in contexts where it is obviously
inappropriate, such as for programs that are inherently multilingual.
 
O

Old Wolf

Walter said:
I'm not sure I want to see the "portable" equivilent to

#include <stdio.h>
int main(void) { puts("That's my $0.02 worth!"); return 0; }

#include <stdio.h>
int main(void) { puts("That's my 2c worth!"); return 0; }
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Old said:
Walter Roberson wrote:




#include <stdio.h>
int main(void) { puts("That's my 2c worth!"); return 0; }

#include <stdio.h>
int main(void) { puts("That's my 2c\b| worth!"); return 0; }


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD4DBQFDgpA0agVFX4UWr64RAjGbAJY56Noq7sXDzIBIyEKFt2A9y8qMAKCv2S+D
B2eDeeGfp2ynosenroWT3Q==
=TQn4
-----END PGP SIGNATURE-----
 
J

Joe Wright

Jordan said:
We don't talk about Unicode or i18n at all. There are no ASCII
characters beyond the basic execution set (0..127).


The basic execution character set only contains 96 characters:

NUL TAB LF VT SP
! " # % & ' ( ) * + , - . / : ; < = >
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _
a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~

ASCII contains, according to you, 0..127, including 32 that are not in
the basic execution set:

SOH STX ETX EOT ENQ ACK BEL BS FF CR SO SI
DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
$ @ ` DEL

I wonder how I've missed that? Thank you.
 
W

Walter Roberson

Jordan Abel said:
The basic execution character set only contains 96 characters:
NUL TAB LF VT SP
! " # % & ' ( ) * + , - . / : ; < = >
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _
a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~

That is the basic source set, not the basic execution set, except that
LF is not part of the basic source set.
ASCII contains, according to you, 0..127, including 32 that are not in
the basic execution set:
SOH STX ETX EOT ENQ ACK BEL BS FF CR SO SI
DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
$ @ ` DEL

The basic execution set includes alert and backspace and carriage return
and linefeed (translated to BEL BS CR LF in ASCII), as well as the
basic source set.
 
D

Dave Thompson

The escape key isn't portable ;-)

If you have an input string that you know to be ASCII (or ISO-8859-*)

or 646.* or 10646/Unicode, while we're at it
then you can test each character against the ASCII escape value, which
you can code in several different ways. One such way would be

#include <string.h>
#define ESCAPE '\027'
<ahem> \033 </>

For those who remember back to bit-paired keyboards like Teletypes,
'[' & ~ '@' might be clearer. Or, maybe not. :)

ObCLC: macro-names beginning with E are reserved if you use <errno.h>,
which wasn't in your example but might be in a real program.

- David.Thompson1 at worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top