how can I test for backspace if( (c = getchar()) == '\b' )

G

G Patel

Hi,

I would like to write a program that checks to see if the user has hit
backspace (so the program can go back to a previous stage).

How would I test for this?

I tried if( (c = getchar()) == '\b' ) but this doesn't work.

It's as if '\b' is not allowed to come into stdin. So how else can I
check for backspace?

Any help would be great :)
 
J

Jack Klein

Hi,

I would like to write a program that checks to see if the user has hit
backspace (so the program can go back to a previous stage).

How would I test for this?

I tried if( (c = getchar()) == '\b' ) but this doesn't work.

It's as if '\b' is not allowed to come into stdin. So how else can I
check for backspace?

Any help would be great :)

You probably can't, in standard C, when stdin is connected to an
interactive device like a serial terminal or a console window.

The C library calls the system's driver, which in the case of
interactive user devices is generally line buffered, that is lower
level code handles things like back space in an entry itself, and only
transmits the full input to your program when the user presses the
enter or return key.

The only way to do this is to use some non-standard extension, if your
compiler and OS provide one, to get raw input.
 
W

Walter Roberson

:> It's as if '\b' is not allowed to come into stdin. So how else can I
:> check for backspace?

:The only way to do this is to use some non-standard extension, if your
:compiler and OS provide one, to get raw input.

Or you could use the standard extensions provided by POSIX.1
such as tcgetattr() and tcsetattr()
 
G

G Patel

Jack said:
You probably can't, in standard C, when stdin is connected to an
interactive device like a serial terminal or a console window.

The C library calls the system's driver, which in the case of
interactive user devices is generally line buffered, that is lower
level code handles things like back space in an entry itself, and only
transmits the full input to your program when the user presses the
enter or return key.

The only way to do this is to use some non-standard extension, if your
compiler and OS provide one, to get raw input.

Thanks for your help. I was so frustrated that I couldn't get \b into
stdin especially when K&R2 had a supposedly "easy" exercise that asked
me to check for \b. Without newsgroups like clc, I would still been
trying :)

Thanks Jack And Walter
 
R

Richard Bos

Thanks for your help. I was so frustrated that I couldn't get \b into
stdin especially when K&R2 had a supposedly "easy" exercise that asked
me to check for \b. Without newsgroups like clc, I would still been
trying :)

Note that K&R are not being silly, and Jack's answer is incomplete. For
input to stdin that comes from the keyboard, he is quite correct.
However, on most systems you can also have your program get standard
input from a file, or from another program (for example, using the
syntax "program <file", or "program1 | program2"); and in those cases,
it is quite possible to see a '\b' on stdin.

Richard
 
M

Mark McIntyre

:> It's as if '\b' is not allowed to come into stdin. So how else can I
:> check for backspace?

:The only way to do this is to use some non-standard extension, if your
:compiler and OS provide one, to get raw input.

Or you could use the standard extensions provided by POSIX.1
such as tcgetattr() and tcsetattr()

Yes, but they're not Standard C, they're Posix, and may not exist on all
platforms of interest.

Since the topic of this group is standard C, its worth making such
distinctions very clear.
 
W

Walter Roberson

|On 10 Feb 2005 02:54:58 GMT, in comp.lang.c , (e-mail address removed)-cnrc.gc.ca
|(Walter Roberson) wrote:

|>In article <[email protected]>,

|>:The only way to do this is to use some non-standard extension, if your
|>:compiler and OS provide one, to get raw input.

|>Or you could use the standard extensions provided by POSIX.1
|>such as tcgetattr() and tcsetattr()

|Yes, but they're not Standard C, they're Posix, and may not exist on all
|platforms of interest.

True.


|Since the topic of this group is standard C, its worth making such
|distinctions very clear.

Jack did, though, say that the "only" way is to use
some "non-standard extension". POSIX.1 is a -standard- extension,
not a non-standard extension.

We see lots of postings from people using basic C I/O operations
such as printf() even though those "may not exist on all platforms
of interest" in a standard-compliant C implimentation. It doesn't
hurt us to admit that very few programs are written in the portion
of C that is certain to exist on any compliant implimentation.
 
C

Chris Croughton

I would like to write a program that checks to see if the user has hit
backspace (so the program can go back to a previous stage).

How would I test for this?

I tried if( (c = getchar()) == '\b' ) but this doesn't work.

It's as if '\b' is not allowed to come into stdin. So how else can I
check for backspace?

Any help would be great :)

By default most systems are line-buffered, with the OS interpreting
backspace (and cursor keys) before the line gets anywhere near the
program. You need to investigate ways of getting individual keys from
your OS (on Unix this can be done with the stty(1) program, or by
issuing ioctl(2) calls, I have no idea about Windows or other systems;
or (again mostly for Unix-like systems) you could look at (n)curses
library).

It's not possible in a portable way, anyway...

Chris C
 
M

Mike Wahler

Walter Roberson said:
|On 10 Feb 2005 02:54:58 GMT, in comp.lang.c , (e-mail address removed)-cnrc.gc.ca
|(Walter Roberson) wrote:

|>In article <[email protected]>,

|>:The only way to do this is to use some non-standard extension, if your
|>:compiler and OS provide one, to get raw input.

|>Or you could use the standard extensions provided by POSIX.1
|>such as tcgetattr() and tcsetattr()

|Yes, but they're not Standard C, they're Posix, and may not exist on all
|platforms of interest.

True.


|Since the topic of this group is standard C, its worth making such
|distinctions very clear.

Jack did, though, say that the "only" way is to use
some "non-standard extension".

His assertion is correct (as usual).
POSIX.1 is a -standard- extension,

The ISO C standard does not define 'standard extensions'.
(However, it does enumerate certain 'common extensions'
in an informative (i.e. non-normative) section).

In the context of comp.lang.c, "standard" means "ISO
standard C", not any other standards. POSIX is not
part of standard C. It's a separate standard, and
afaik doesn't even require the language used with it
to be C.

ASCII is a standard. So is JPEG. Etc. etc. Should we
include those in our definition of standard C as well?
Where does it end?
We see lots of postings from people using basic C I/O operations
such as printf() even though those "may not exist on all platforms
of interest" in a standard-compliant C implimentation.

They must exist in a compliant hosted implementation.

The functions declared by <stdio.h> are indeed part of
standard C, but are not required to be supplied by a
freestanding implementation. "Standard, but optional
in some contexts" is not the same as "non-standard".
Don't confuse the language with implementation.
It doesn't
hurt us to admit that very few programs are written in the portion
of C that is certain to exist on any compliant implimentation.

I don't see anyone refusing to admit that. But the parts of
programs which are not ISO standard C are not topical for
comp.lang.c

I integrate nonstandard (r.e. C) additions (some of them
are defined by other standards) to my C programs almost
always. But I don't discuss them here, because they're
not topical here.


-Mike
 
M

Mark McIntyre

Jack did, though, say that the "only" way is to use
some "non-standard extension". POSIX.1 is a -standard- extension,
not a non-standard extension.

No, its not.

Or at least, its only a standard extension in the same sense that the
extension under my desk is a standard one because it complies with teh BS
relating to electrical safety for extension cables. Both comply with some
standard. Neither complies with THE Standard that defines C. Ergo, both are
definitionally nonstandard as far as C is concerned.
We see lots of postings from people using basic C I/O operations
such as printf() even though those "may not exist on all platforms
of interest" in a standard-compliant C implimentation.

printf is required to exist on all hosted implementations.
 
J

Jack Klein

Note that K&R are not being silly, and Jack's answer is incomplete. For
input to stdin that comes from the keyboard, he is quite correct.
However, on most systems you can also have your program get standard
input from a file, or from another program (for example, using the
syntax "program <file", or "program1 | program2"); and in those cases,
it is quite possible to see a '\b' on stdin.

Richard

How was it incomplete? In the OP's original post, which you did not
quote, G Patel specifically asked:
I would like to write a program that checks to see if the user has hit
^^^
backspace (so the program can go back to a previous stage).
^^^^^^^^^

Specifically in the context of interactive user input from a keyboard.

And I very clearly limited my reply to that context, with what seem to
me to be suitable disclaimers. In part of my reply that you did not
quote:
You probably can't, in standard C, when stdin is connected to an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
interactive device like a serial terminal or a console window.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And again, in the part of my reply that you did quote:
^^^^^^^^^^^^^^^^^^^^^^^^

I certainly don't mind being corrected if I am wrong, which happens
often enough, or clarified if I am misleading.

But how could I have been more explicit about the fact that my reply,
like the OP's question, was specific to interactive user input to
stdin from a keyboard? Discussing what the OP could do when stdin was
coming from a file was irrelevant to his need.
 
F

Fao, Sean

Walter said:
|On 10 Feb 2005 02:54:58 GMT, in comp.lang.c , (e-mail address removed)-cnrc.gc.ca
|(Walter Roberson) wrote:

|>In article <[email protected]>,

|>:The only way to do this is to use some non-standard extension, if your
|>:compiler and OS provide one, to get raw input.

|>Or you could use the standard extensions provided by POSIX.1
|>such as tcgetattr() and tcsetattr()

|Yes, but they're not Standard C, they're Posix, and may not exist on all
|platforms of interest.

True.


|Since the topic of this group is standard C, its worth making such
|distinctions very clear.

Jack did, though, say that the "only" way is to use
some "non-standard extension". POSIX.1 is a -standard- extension,
not a non-standard extension.

We see lots of postings from people using basic C I/O operations
such as printf() even though those "may not exist on all platforms
of interest" in a standard-compliant C implimentation. It doesn't
hurt us to admit that very few programs are written in the portion
of C that is certain to exist on any compliant implimentation.

The debate on what should/shouldn't be topical on comp.lang.c has been
argued thousands of times and the general consensus of this group has
*never* changed. Why must people continue to throw out the debate as if
it were some ingenious idea that's never before been discussed?
 
W

Walter Roberson

:> It doesn't
:> hurt us to admit that very few programs are written in the portion
:> of C that is certain to exist on any compliant implimentation.

:The debate on what should/shouldn't be topical on comp.lang.c has been
:argued thousands of times and the general consensus of this group has
:*never* changed. Why must people continue to throw out the debate as if
:it were some ingenious idea that's never before been discussed?

I would say that there are several answers to that.

The first answer would be that a continued demand for discussion
on the topic indicates that there is an unmet need "in the market"
for discussions about C in contexts that lie -somewhere- between
the limits of freestanding implimentations and operating
system specific. There isn't necessarily one "right" cutoff point
in this: it could be that more than one new newsgroup should be
the result.

The second answer would be that comp.lang.c has no newsgroup
charter and its existance proceeds *any* of the standardizations
that its current denizens insist on. If the newsgroup is really
to be repurposed to only discussing programs whose behaviour
is well-defined by one of the C standards, then according to
Usenet traditions, that repurposing needs to be put out to
an RFD, possibly followed by a CFV.

The third answer would be that I have been answering questions in
technical newsgroups and LISTSERVs and mailing lists and such since
before Usenet escaped from Universities, but I have never before
encountered a technical newsgroup that has been so narrow-minded
and hair-splitting about what the cliques deem discussible or
not. Even the *advocacy groups, with their many more flames,
allow a much broader list of topics. It's like the
[hypothetical] newsgroup sci.ice deciding it will only discuss
river ice, and saying that ocean ice, pack ice, glaciers, frost,
ice-fog, and the frozen gasses such as CO2 ice, are all off topic
because the formation of those is "situation dependant".


It seems to me that there is room and call for a newsgroup, perhaps
"comp.lang.c.portable", perhaps some other name, that allows
discussion of C programs which are intended to fit within well-
defined international standards such as the IEC/ISO standards,
including POSIX.*.
 
A

Alan Balmer

:> It doesn't
:> hurt us to admit that very few programs are written in the portion
:> of C that is certain to exist on any compliant implimentation.

:The debate on what should/shouldn't be topical on comp.lang.c has been
:argued thousands of times and the general consensus of this group has
:*never* changed. Why must people continue to throw out the debate as if
:it were some ingenious idea that's never before been discussed?

I would say that there are several answers to that.

The first answer would be that a continued demand for discussion
on the topic indicates that there is an unmet need "in the market"
for discussions about C in contexts that lie -somewhere- between
the limits of freestanding implimentations and operating
system specific.

I haven't seen much of that need. What I've seen is a need for people
to find the correct discussion group, rather than try to bend this one
to fit their needs.
There isn't necessarily one "right" cutoff point
in this: it could be that more than one new newsgroup should be
the result.

Possibly, though again, I really haven't seen many requests that were
not appropriate in some existing group.
The second answer would be that comp.lang.c has no newsgroup
charter and its existance proceeds *any* of the standardizations
that its current denizens insist on. If the newsgroup is really
to be repurposed to only discussing programs whose behaviour
is well-defined by one of the C standards, then according to
Usenet traditions, that repurposing needs to be put out to
an RFD, possibly followed by a CFV.

There is no re-purposing involved. The discussion of conforming C code
is *already* the purpose of this group.
The third answer would be that I have been answering questions in
technical newsgroups and LISTSERVs and mailing lists and such since
before Usenet escaped from Universities, but I have never before
encountered a technical newsgroup that has been so narrow-minded
and hair-splitting about what the cliques deem discussible or
not.

I suspect that you have rarely or never encountered a newsgroup which
is so consistently useful, on topic, and free of politics and flames,
either. This is a good thing.
 
W

Walter Roberson

:On 11 Feb 2005 16:02:28 GMT, (e-mail address removed)-cnrc.gc.ca (Walter
:Roberson) wrote:

:>The third answer would be that I have been answering questions in
:>technical newsgroups and LISTSERVs and mailing lists and such since
:>before Usenet escaped from Universities, but I have never before
:>encountered a technical newsgroup that has been so narrow-minded
:>and hair-splitting about what the cliques deem discussible or
:>not.

:I suspect that you have rarely or never encountered a newsgroup which
:is so consistently useful, on topic, and free of politics and flames,
:either. This is a good thing.

Your suspicion would be wrong. I have participated for many years
in newsgroups that are more consistantly useful, on topic, and free
of politics and flames. In those groups, I was usually, for several
years in each case, the second or third most active contributor to the
group (one of the appropriate manufacturer's people would usually be
more active, with myself usually being the most active person who did not
work for the company.)

In the newsgroups I have been active in, the only people who have
been made unwelcome have been the ones who a) are asking that someone
else do their homework for them; or b) are asking that someone steal
or break the law for them; or c) spammed. In comp.lang.c, on
the other hand, one need seldom read more than half a dozen postings
before encountering pointed dismissals of someone who had asked a question
that ay even just a little outside of what can be done outside of the
ISO standards.


:There is no re-purposing involved. The discussion of conforming C code
:is *already* the purpose of this group.

Sorry, that is incorrect.

comp.lang.c has no recorded charter in the ftp.uu.net archive
of control messages.

comp.lang.c was renamed from net.lang.c; the announcement
was November 7, 1986
http://www.google.ca/[email protected]

net.lang.c was created Oct 22, 1982 by Jerry Schwarz,
http://www.google.ca/groups?selm=bnews.eagle.565

My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.

It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

Jerry Schwarz
BTL -- Murray Hill
harpo!eagle!jerry


Notice the point about "Suggestions for C modifcations or extensions".
Any such message would be outside the scope of a newsgroup
restricted to discussing "conforming" C. Similarily, "compiler bugs"
and "availability of compilers" distinctly fall into the
"platform dependant" category that people are told is inappropriate
in comp.lang.c .

I repeat the question: how can comp.lang.c be about "conforming"
C code when the newsgroup clearly predates the existance of *any*
standard to conform -to- ?
 
D

Default User

Walter Roberson wrote:

I repeat the question: how can comp.lang.c be about "conforming"
C code when the newsgroup clearly predates the existance of *any*
standard to conform -to- ?


What do you think you will accomplish, besides irritating the majority
of participant? Your opinion is at odds with the consensus of the
groups, we won't be changing. You've been informed, so now you are
effectively just trolling. Congratulations, we'll get your E. Robert
Tisdale coffee mug ready.




Brian
 
M

Mark McIntyre

The second answer would be that comp.lang.c has no newsgroup
charter and its existance proceeds *any* of the standardizations
that its current denizens insist on.

You proceed from fact to falsehood, by way of accidental ignorance. The
very first post, the one establishing net.lang.c, defined the topic. We're
still sticking to it.
If the newsgroup is really
to be repurposed to only discussing programs whose behaviour
is well-defined by one of the C standards, then according to
Usenet traditions, that repurposing needs to be put out to
an RFD, possibly followed by a CFV.

There has been no repurposing, and the lack of charter merely shows this
group's antiquity. In fact should you want to start discussing nonstandard
C here, *you* would have to raise the RFD.
The third answer would be that I have been answering questions in
technical newsgroups and LISTSERVs and mailing lists and such since
before Usenet escaped from Universities, but I have never before
encountered a technical newsgroup that has been so narrow-minded
and hair-splitting about what the cliques deem discussible or
not.

Pardon me, but thats complete poppycock. And even if it weren't, so what?
It seems to me that there is room and call for a newsgroup, perhaps
"comp.lang.c.portable",

Then feel free to start one. Nobody's stopping you.
 
M

Mark McIntyre

:There is no re-purposing involved. The discussion of conforming C code
:is *already* the purpose of this group.

Sorry, that is incorrect.

You lie.
comp.lang.c has no recorded charter in the ftp.uu.net archive
of control messages.

Indeed, thats correct.
comp.lang.c was renamed from net.lang.c; the announcement

makes it completely clear the topic is the C *language*. That was codified
by Standard not long afterwards.

Notice the point about "Suggestions for C modifcations or extensions".

It mentions *suggestions* for extensions and modifications, and thats
different to discussion about using common ones. And in any events
Comp.std.c was formed for that purpose, and now forms the right place for
it.

You can argue all you want, all it'll get you is flamed then plonked.
I repeat the question: how can comp.lang.c be about "conforming"
C code when the newsgroup clearly predates the existance of *any*
standard to conform -to- ?

Because as the original post itself clearly states, the topic is the C
*language*. That is now codified by by Standard. Think it thru.

If this is hard to understand, I'm sure someone will write it in all caps
for you.
 
W

Walter Roberson

:What do you think you will accomplish, besides irritating the majority
:eek:f participant?

I don't know anything about your background, but in my background,
technical newsgroup participants pride themselves on providing
postings which are as correct and complete as is reasonably feasible.

If someone were to quote the C standard incorrectly, would you not
correct them, even if it isn't what they wanted to hear? You put
truth above convenience or above the possibility that you
might "irritatei" them, do you not?

Just so, if someone misspeaks about the purpose of the newsgroup,
then is it out of place to speak the truth that few people seem to
want to hear?

:Your opinion is at odds with the consensus of the
:groups, we won't be changing.

You know, there's already been an RFD and CFV on the topic, and
the result was that comp.lang.c.moderated was created with a charter
that left comp.lang.c as the appropriate newsgroup for OS-specific
issues not covered by the clc FAQ. The result was announced
March 7, 1995.

:You've been informed,

I have been "informed" by people who obviously didn't know what
they were talking about. The newsgroup has *not* "always" been
only about "conforming" C.

There's a big difference between saying that "clc is only about
ISO C standards-conforming code" and saying "Sorry, there has been
an overwhelming number of messages, and we have found it a practical
necessity to restrain discussions to ISO C standards-conforming code".
The first leads to the "Go peddle your wares elsewhere,
you don't belong here and never did!" attitude I have seen in a
number of postings in a short time; the second leads to replies
closer to "Sorry, this newsgroup gets very busy and we just don't
have the resources to deal with those kinds of questions; please
try other venues where you question is less likely to get lost."

It's "We don't want your kind around here!" vs
"We're doing the best we can but we just can't cope with that, sorry."


When someone posts an answer to a question and that answer fits within
the environment stated by the question-poser, the "We're doing the best
we can" camp says "Hey, it's great that someone with the knowledge and
experience was able to help that person out."; the "We don't want your
kind around here!" camp makes themselves visible by then replyng to
that servicable answer with a "That's not part of Standard C and so is
inappropriate in this newsgroup!".
 
E

E. Robert Tisdale

Walter Roberson wrote:

[snip]

I see that you have already met some of our indigenous trolls.
It is important to learn to recognize and ignore them
as soon as possible. Please don't feed the trolls.
 

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,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top