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

[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.

 

[Flash Gordon]

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.

 

[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.

 

[Keith Thompson]

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.

 

[Mike Wahler]

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

 

[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; }

 

[Joe Wright]

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?

 

[Keith Thompson]

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'.)

 

[Mike Wahler]

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

 

[Mike Wahler]

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

 

[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

 

[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.

 

[Old Wolf]

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; }

 

[Lew Pitcher]

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

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-----

 

[Joe Wright]

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.

 

[Walter Roberson]

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.

 

[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