What is the difference between '\n' versus pressing return at the prompt

[Chad]

Given:

#include <stdio.h>
#include <stdlib.h>

#define MAXLINE 200

int main(void) {

char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");

}


How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

Chad

 

[CBFalconer]

#include <stdio.h>
#include <stdlib.h>
#define MAXLINE 200
int main(void) {

char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");
if(ferror(stdin))
fprintf(stderr, "input error \n");
}

How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

It's perfectly obvious to me, but I find it hard to explain :-(
For one thing, it is not needed in console input, because the input
system is quite capable of translating your press of 'return' into
a '\n' to transmit to the program. Notice that at the same time
that input system is probably echoing both a '\r' and a '\n' to
your terminal, which will be the ascii sequence <0x0d><0x0a> (if
your system is using Ascii). Notice also that you (probably)
generated a '\r' with the enter key, but the program received a
'\n'.

However, within the program source, you can't just enter a <return>
willy nilly, because that would be the end of the source line, and
probably a syntax error. So C has escape characters, signalled by
the \, to represent various special characters IN THE SOURCE. Some
of these same escape sequences are used elsewhere in various
systems, but that is another matter entirely.

With any luck you are now totally confused.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Keith Thompson]

Given:

#include <stdio.h>
#include <stdlib.h>

#define MAXLINE 200

int main(void) {

char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");

}


How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

Do you mean that you typed
quotation mark
letter 'l'
letter 'a'
backslash
letter 'n'
(etc.)
on your keyboard?

The sequence of a backslash followed by a letter 'n' is interpreted as
a newline only in a string or character literal in a C source file.
On input, it's just a backslash followed by a letter 'n', and has no
special meaning.

 

[santosh]

Given:

#include <stdio.h>
#include <stdlib.h>

#define MAXLINE 200

int main(void) {

char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");

}


How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

The backslash based escape sequence is only valid within string and
character literals in C. If input is from the console, the operating
system and the C library translate the actual newline sequence, (i.e.
the Enter or Return keypress), into the C newline character. The
character sequence \n is treated literally.

 

[Chad]

Given:

#include <stdio.h>
#include <stdlib.h>

#define MAXLINE 200

int main(void) {

char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");

}


How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

Do you mean that you typed
quotation mark
letter 'l'
letter 'a'
backslash
letter 'n'
(etc.)
on your keyboard?
Yes.


The sequence of a backslash followed by a letter 'n' is interpreted as
a newline only in a string or character literal in a C source file.
On input, it's just a backslash followed by a letter 'n', and has no
special meaning.

I think the confusion is stemming from the fact that I still have no
real grasp over how the Unix Shell works. I'm suspecting that I might
have to the archane Unix questions to either comp.unix.programmer or
comp.unix shell

Chad

 

[santosh]

Given:

#include <stdio.h>
#include <stdlib.h>
#define MAXLINE 200

int main(void) {
char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");
}

How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

The sequence of a backslash followed by a letter 'n' is interpreted as
a newline only in a string or character literal in a C source file.
On input, it's just a backslash followed by a letter 'n', and has no
special meaning.

I think the confusion is stemming from the fact that I still have no
real grasp over how the Unix Shell works. I'm suspecting that I might
have to the archane Unix questions to either comp.unix.programmer or
comp.unix shell

This has nothing to do with the shell or the operating system. Escape
sequences are a mechanism to include control characters, invisible
characters, or characters which are otherwise hard to type, _within_ C.
These're then "translated" to the actual character/s they represent
when the string is sent to an output stream. When input from a stream
is read into an array, these formatting character/s are again
translated to their corresponding C escape sequence.

For example under Unix, the end-of-line marker is a single
carriage-return character, which is generated when you press the Enter
or Return key. The same keypress under DOS/Windows generates two
characters, a carriage return and a linefeed character.

To abstract out these system specific details, yet provide a consistent
mechanism, the C library, translates a predefined set of character/s
into their C equivalents, which we syntactically denote in the \xx form
in strings.

If these had not been defined, you'd have to include the actual
character code into your strings, something that's awkward to do.

 

[Flash Gordon]

santosh wrote, On 26/01/07 06:45:

Given:

#include <stdio.h>
#include <stdlib.h>
#define MAXLINE 200

int main(void) {
char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");
}

How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

The sequence of a backslash followed by a letter 'n' is interpreted as
a newline only in a string or character literal in a C source file.
On input, it's just a backslash followed by a letter 'n', and has no
special meaning.

I think the confusion is stemming from the fact that I still have no
real grasp over how the Unix Shell works. I'm suspecting that I might
have to the archane Unix questions to either comp.unix.programmer or
comp.unix shell

This has nothing to do with the shell or the operating system. Escape
sequences are a mechanism to include control characters, invisible
characters, or characters which are otherwise hard to type, _within_ C.

Correct up to here.

These're then "translated" to the actual character/s they represent
when the string is sent to an output stream. When input from a stream
is read into an array, these formatting character/s are again
translated to their corresponding C escape sequence.

Whilst it *could* be done that way it normally isn't, and I don't think
that is the best way to think of it.

On compiling the program the '/n' if converted in to a newline
character. The libraries do whatever is needed to make pressing the
return key send a newline character to the program. It also does any
magic required for printing a newline character to "do the right thing"(tm).

For example under Unix, the end-of-line marker is a single
carriage-return character,

No, it is a newline character not a carriage return character.

> which is generated when you press the Enter
or Return key. The same keypress under DOS/Windows generates two
characters, a carriage return and a linefeed character.

To abstract out these system specific details, yet provide a consistent
mechanism, the C library, translates a predefined set of character/s
into their C equivalents, which we syntactically denote in the \xx form
in strings.

If these had not been defined, you'd have to include the actual
character code into your strings, something that's awkward to do.

This is true although you are mixing up two issues.

To the OP, if you think of the escape sequences (things like /n) as
being translated during compilation it should become obvious that they
do not exist at run time so typing slash-n does not send a newline to
the program, just as typing 'printf("Hello");' as an input to the
program will not make the program print an extra "Hello".

 

[Ben Bacarisse]

This has nothing to do with the shell or the operating system.

For example under Unix, the end-of-line marker is a single
carriage-return character,

*nix systems use LF, not CR.

which is generated when you press the Enter
or Return key. The same keypress under DOS/Windows generates two
characters, a carriage return and a linefeed character.

This is an example of why OT answers should not be offered since any
errors either have to be left uncorrected or the topic drifts. I may
have added errors, confusions and such like so my correction may need
correcting, and so on.

My apologies if ignoring OT corrections is considered the better
option.

 

[Richard Heathfield]

Ben Bacarisse said:

*nix systems use LF, not CR.


This is an example of why OT answers should not be offered since any
errors either have to be left uncorrected or the topic drifts. I may
have added errors, confusions and such like so my correction may need
correcting, and so on.

My apologies if ignoring OT corrections is considered the better
option.

No, you're right that OT answers are a nuisance and you've correctly
identified one of the reasons. Your reply was well-formed and useful.

Nevertheless, in his defence I'd like to say that the reply "santosh" gave
to a clearly topical question was equally clearly an attempt to draw on
various machine differences to illustrate a point about portability, and in
that sense his remarks were not exactly off-topic. They were, however,
incorrect!

 

[santosh]

santosh wrote, On 26/01/07 06:45:

Keith Thompson wrote:
Given:

#include <stdio.h>
#include <stdlib.h>
#define MAXLINE 200

int main(void) {
char buff[MAXLINE];
while( fgets(buff, MAXLINE, stdin) != NULL)
if( fputs(buff, stdout) == EOF)
fprintf(stderr, "output error \n");

if(ferror(stdin))
fprintf(stderr, "input error \n");
}

How come when I go like:
cdalten@linux:~> ./ef3
"la\nla\nla\n"
"la\nla\nla\n"

Why doesn't it print
la
la
la

The sequence of a backslash followed by a letter 'n' is interpreted as
a newline only in a string or character literal in a C source file.
On input, it's just a backslash followed by a letter 'n', and has no
special meaning.

I think the confusion is stemming from the fact that I still have no
real grasp over how the Unix Shell works. I'm suspecting that I might
have to the archane Unix questions to either comp.unix.programmer or
comp.unix shell

For example under Unix, the end-of-line marker is a single
carriage-return character,

No, it is a newline character not a carriage return character.

Sorry about that. Got that mixed up.

<snip>

 

[santosh]

*nix systems use LF, not CR.

Thanks and apologies to Chad. That was a thinko.

This is an example of why OT answers should not be offered since any
errors either have to be left uncorrected or the topic drifts. I may
have added errors, confusions and such like so my correction may need
correcting, and so on.

You're probably right. My first reply to Chad should've been enough.

My apologies if ignoring OT corrections is considered the better option.

I think a quick correction, a you've done here, is okay, since
misleading information is subtly dangerous.