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

Discussion in 'C Programming' started by sudhir, Nov 21, 2005.

  1. sudhir

    sudhir Guest

    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.
    sudhir, Nov 21, 2005
    #1
    1. Advertising

  2. sudhir

    Flash Gordon Guest

    sudhir wrote:
    > 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.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Nov 21, 2005
    #2
    1. Advertising

  3. In article <>,
    sudhir <> wrote:
    >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.

    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
    Walter Roberson, Nov 21, 2005
    #3
  4. "sudhir" <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Nov 21, 2005
    #4
  5. sudhir

    Mike Wahler Guest

    "sudhir" <> wrote in message
    news:...
    > 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
    Mike Wahler, Nov 21, 2005
    #5
  6. In article <_qrgf.597$>,
    Mike Wahler <> wrote:

    >"sudhir" <> wrote in message
    >news:...


    >> how to check escape key is pressed when accepting the string as input.


    >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; }
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
    Walter Roberson, Nov 21, 2005
    #6
  7. sudhir

    Joe Wright Guest

    Walter Roberson wrote:
    > In article <_qrgf.597$>,
    > Mike Wahler <> wrote:
    >
    >
    >>"sudhir" <> wrote in message
    >>news:...

    >
    >
    >>>how to check escape key is pressed when accepting the string as input.

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

    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?
    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Nov 21, 2005
    #7
  8. Joe Wright <> writes:
    > 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'.)

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Nov 22, 2005
    #8
  9. sudhir

    Mike Wahler Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:dlth26$ls4$...
    > In article <_qrgf.597$>,
    > Mike Wahler <> wrote:
    >
    >>"sudhir" <> wrote in message
    >>news:...

    >
    >>> how to check escape key is pressed when accepting the string as input.

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


    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, Nov 22, 2005
    #9
  10. sudhir

    Mike Wahler Guest

    "Mike Wahler" <> wrote in message
    news:gTtgf.2045$...
    >
    > "Walter Roberson" <-cnrc.gc.ca> wrote in message
    > news:dlth26$ls4$...
    >> 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()'.


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


    -Mike
    Mike Wahler, Nov 22, 2005
    #10
  11. sudhir

    Jordan Abel Guest

    On 2005-11-21, Joe Wright <> wrote:
    > 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
    Jordan Abel, Nov 22, 2005
    #11
  12. In article <>,
    Joe Wright <> wrote:
    [I wrote]

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


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


    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.
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
    Walter Roberson, Nov 22, 2005
    #12
  13. sudhir

    Old Wolf Guest

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


    #include <stdio.h>
    int main(void) { puts("That's my 2c worth!"); return 0; }
    Old Wolf, Nov 22, 2005
    #13
  14. sudhir

    Lew Pitcher Guest

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

    Old Wolf wrote:
    > 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; }

    >
    >
    > #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-----
    Lew Pitcher, Nov 22, 2005
    #14
  15. sudhir

    Joe Wright Guest

    Jordan Abel wrote:
    > On 2005-11-21, Joe Wright <> wrote:
    >
    >>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.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Nov 22, 2005
    #15
  16. In article <>,
    Jordan Abel <> wrote:

    >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.
    --
    Prototypes are supertypes of their clones. -- maplesoft
    Walter Roberson, Nov 22, 2005
    #16
  17. On Mon, 21 Nov 2005 18:39:48 +0000 (UTC), -cnrc.gc.ca
    (Walter Roberson) wrote:
    <snip>
    > 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
    Dave Thompson, Dec 5, 2005
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Harvey
    Replies:
    1
    Views:
    354
    Raterus
    Jun 22, 2004
  2. Replies:
    2
    Views:
    1,267
  3. Rune
    Replies:
    6
    Views:
    1,221
    Richie Hindle
    Jan 29, 2004
  4. slomo
    Replies:
    5
    Views:
    1,494
    Duncan Booth
    Dec 2, 2007
  5. Jim Cain
    Replies:
    1
    Views:
    186
    Yukihiro Matsumoto
    Jul 18, 2003
Loading...

Share This Page