Hi Barry,
Probably not but you can suppress it easily enough.
No. The newline is coming *before* scanf(3) even *sees*
the characters typed by the user. The terminal handler
is buffering the input -- "cooking" it -- and only
passing it on to the application -- scanf() -- once the
user has typed ENTER.
When scanf is processing characters for computing the value to store
in b, it will stop at the first character which cannot be part of an
int. With an obedient typist, this will be the \n produce by the
ENTER key but it could be any other non-digit (alpha, imbedded +,
etc). The remove all these extraneous characters from the input
buffer simply code
while (getchar() != '\n')
;
after the call to scanf. This will remove one character at a time
from the input buffer until the character just removed is the one
produce by ENTER.
But the buffer isn't made available to the application until
the user has typed ENTER! The terminal handler is receiving
keystrokes, echoing them and accumulating them in a buffer
*before* passing the entire buffer to scanf. I.e., the
characters typed have already been echoed (including ENTER)
before scanf() even sees the first character in the buffer.
The OP needs to look at the termios(4)-related features of his
hosted OS. In UN*X, you can exercise a lot of control over what
the terminal handler does to keystrokes prior to passing them
to the application (scanf(), gets(), or whatever *other* input
hook might be waiting).
To take the terminal handler out of the picture completely,
you can tell it to pass each keystroke directly to the
application without echoing, without checking for "control
characters" (not the same as the "control characters" you
think of when you think of ASCII), without even *waiting*
for a keystroke! I.e., "nothing has been typed since the
last time you called me".
You can also control things like whether CR and NL are equivalenced.
If input keystrokes are automatically echoed. etc.
But, then the application has to do all of that processing
itself! If you want to allow the user to delete the last
character that he typed, then *you* have to check for the
receipt of a backspace (or DEL?) character *and*, when detected,
backup one keystroke and delete the keystroke that preceded
it -- and inform the user that you are doing this (by some
mechanism)!
You even have to enforce your own processing of localization
criteria: is "three and a half" typed as "3.5"? Or, 3,5"?
In this way, you strip keys of any particular meaning and
just use the terminal handler to get the keystrokes *to*
you. This is usually an unnecessary burden for the majority
of applications.
If, for example, you want the user to be able to interactively
navigate between "fields" in a visual "form" -- perhaps using
TAB to advance to the next field -- you need to operate the
interface in raw mode. Otherwise, the user would have to type
"TAB ENTER", "TAB ENTER", "UPARROW ENTER", "LEFTARROW ENTER", etc.