By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,312 Members | 1,248 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,312 IT Pros & Developers. It's quick & easy.

K&R2 2.3 : /n vs /r

P: n/a
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ
Nov 14 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ


'\r' is simply a carriage return whereas '\n' is a carriage return followed
by line feed. Note that a carriage return is simply that, it moves the
cursor to the beginning of the current line and does not move on to the
next line.

It is here you have to be careful as UNIX text files are of a different
format from Windows text files and need conversion when moving from one o/s
to the other.
Nov 14 '05 #2

P: n/a
"Merrill & Michele" <be********@comcast.net> wrote in
news:ma********************@comcast.com:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?
I guess so.
Q2) What on earth is the difference between newline and carriage
return?


First, unlike you wrote it in the subject line, they are: \n and \r. A new
line moves the "cursor" down one line, that is, to a new line. A carriage
return brings the "cursor" back to the left margin. Whether they are
treated separately or do the same thing may be implementation specific.

--
- Mark ->
--
Nov 14 '05 #3

P: n/a
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?
Probably not.
Q2) What on earth is the difference between newline and carriage return?


I think carriage return ('\r') returns to the left margin without
advancing a line;
and newline ('\n') advances a line *and* returns to the left margin

#include <stdio.h>

int main(void) {
printf("1. VERY LONG LINE\r----\n");
printf("2. VERY LONG LINE\n----\n");
printf("3. VERY LONG LINE\r\n----\n");
return 0;
}
Output on Linux (gcc 3.3.5) *and* Windows 2000 (gcc 3.3.3 / DJGPP)
----ERY LONG LINE
2. VERY LONG LINE
----
3. VERY LONG LINE
----
--
USENET would be a better place if everybody read:
http://www.expita.com/nomime.html
http://www.netmeister.org/news/learn2quote2.html
http://www.catb.org/~esr/faqs/smart-questions.html
Nov 14 '05 #4

P: n/a
Merrill & Michele <be********@comcast.net> wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?
Since these escape sequences are defined by the ISO C standard, yes.

Q2) What on earth is the difference between newline and carriage return?


Newline ('\n') moves the cursor (or equivalent) to the beginning of the
*next* line, while carriage return ('\r') moves the cursor to the
beginning of the *current* line.
Exactly which character-codes they are represented by is
implementation-defined.

On systems using ASCII (or some derivative thereof) it is usually the
case the \r corresponds to Carriage Return (CR, ASCII code 13) while \n
corresponds to Linefeed (LF, ASCII code 10).

(On some systems (e.g. MS-DOS) it is the case that when you write a \n
to a text file, \n is translated the two characters CR,LF with
corresponding translation in the other direction is done when reading
from a text file. No such translation is done for files opened in
binary mode.)

--
<Insert your favourite quote here.>
Erik Trulsson
er******@student.uu.se
Nov 14 '05 #5

P: n/a
Mark A. Odell <od*******@hotmail.com> scribbled the following:
"Merrill & Michele" <be********@comcast.net> wrote in
news:ma********************@comcast.com:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?
I guess so. Q2) What on earth is the difference between newline and carriage
return?

First, unlike you wrote it in the subject line, they are: \n and \r. A new
line moves the "cursor" down one line, that is, to a new line. A carriage
return brings the "cursor" back to the left margin. Whether they are
treated separately or do the same thing may be implementation specific.


Seeing as it's now become customary to use \ in all contents where a
divisor sign or an abbreviation for "or" is used, it's only logical that
/ is used as an escape sequence marker in program source code. Bill
doesn't only control our computers, he controls our minds as well.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"There's no business like slow business."
- Tailgunner
Nov 14 '05 #6

P: n/a
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ

An interesting aside: do you know why they always have carriage return
followed by line feed rather than the other way round ?

It goes back to mechanical teletypes; if you issued a line feed followed by
carriage return you got a few characters printed backwards in a diagonal
stripe because there was insufficient time for the carriage to move back to
the left before it started printing. To overcome this, the carriage return
is issued first to give the carriage enough time to return, whilst line
feeding, before printing started. It has stuck as a standard ever since.

:-)
Nov 14 '05 #7

P: n/a
Merrill & Michele wrote:

Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference
between newline and carriage return?


int difference = '\n' - '\r';

But serioulsy,
the newline character has a special meaning in terms of text streams.

7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines, each line consisting of zero or more
characters plus a terminating new-line character. Whether
the last line requires a terminating new-line character is
implementation-defined.

--
pete
Nov 14 '05 #8

P: n/a
On Wed, 20 Oct 2004 14:13:16 UTC, john blackburn
<jo*********************@lintonhealy.co.uk> wrote:
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ
'\r' is simply a carriage return whereas '\n' is a carriage return followed
by line feed. Note that a carriage return is simply that, it moves the
cursor to the beginning of the current line and does not move on to the
next line.


No, you should not look on a spezific implementation for that:
\n newline. On one implementation it may be 0x0a,
on another it may be 0x0d, on a third it may be 0x0d0a
on another it may be something else
\r return. on some implementations it is 0x0a
on others it may be something else
\t tab. Often it is 0x09 but other implementations may
use something else

\b bell
\f formfeed
and some more symbolic constant refering to a specific hardware
function - but having different binary codes in different
implementations.

Always get the meaning, not the binary representation. On Win, DOS and
so on \n is 2 binary characters in file, on the stream different:
binary: two, text: only one. On other implementations its only one but
been different to others.
It is here you have to be careful as UNIX text files are of a different
format from Windows text files and need conversion when moving from one o/s
to the other.


There are clearly more implementations with different meaning of them.
It is the C runtime that converts 0x0d0a to only \n - and reverse in
DOS/Win text streams. It is the C runtime that converts \n to 0x0a and
reverse on MAC, it is the C runtime that converts another char(s)
from/to \n.

So whenever you has to handle a text stream use the codes (e.g. \n für
newline). Be sure that you can fall into hard compatibility problems
when the stream does NOT ordinate from your system or is destinated to
another. Yeah, there are filters around that will convert text files
from one system to another and back. Use them to im/export files from
other systems.

When you use a network like tcp/ip the network will do that under
cover for you - except you have to write something on low level.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

Nov 14 '05 #9

P: n/a
On Wed, 20 Oct 2004 15:05:13 UTC, Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Mark A. Odell <od*******@hotmail.com> scribbled the following:
"Merrill & Michele" <be********@comcast.net> wrote in
news:ma********************@comcast.com:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?
I guess so.

Q2) What on earth is the difference between newline and carriage
return?

First, unlike you wrote it in the subject line, they are: \n and \r. A new
line moves the "cursor" down one line, that is, to a new line. A carriage
return brings the "cursor" back to the left margin. Whether they are
treated separately or do the same thing may be implementation specific.


Seeing as it's now become customary to use \ in all contents where a
divisor sign or an abbreviation for "or" is used, it's only logical that
/ is used as an escape sequence marker in program source code. Bill
doesn't only control our computers, he controls our minds as well.


No. '\' is the ecape character in C in any case.
In file pathes you should use '/' as path separator. Even old DOS
understunds it in its APIs even as command.com would not. Whenever you
have to use '\' as path separator you must escape the escape character
('\\' to get it as single character in the source file. Coming in/from
stream the '\' itself is interpreded as path separator.

Has nothing to do with software from Redmont.

Using always '/' as path separator in source makes things much easier.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

Nov 14 '05 #10

P: n/a
Herbert Rosenau <os****@pc-rosenau.de> scribbled the following:
On Wed, 20 Oct 2004 15:05:13 UTC, Joona I Palaste
<pa*****@cc.helsinki.fi> wrote:
Mark A. Odell <od*******@hotmail.com> scribbled the following:
> "Merrill & Michele" <be********@comcast.net> wrote in
> news:ma********************@comcast.com:
>> Section 2.3 of K&R enumerates the complete set of escape sequences.
>>
>> Q1) Is it possible to ask the following question without getting into
>> implementation/platform talk?
> I guess so.

>> Q2) What on earth is the difference between newline and carriage
>> return?

> First, unlike you wrote it in the subject line, they are: \n and \r. A new
> line moves the "cursor" down one line, that is, to a new line. A carriage
> return brings the "cursor" back to the left margin. Whether they are
> treated separately or do the same thing may be implementation specific.


Seeing as it's now become customary to use \ in all contents where a
divisor sign or an abbreviation for "or" is used, it's only logical that
/ is used as an escape sequence marker in program source code. Bill
doesn't only control our computers, he controls our minds as well.

No. '\' is the ecape character in C in any case.
Would you believe I knew that?
In file pathes you should use '/' as path separator. Even old DOS
understunds it in its APIs even as command.com would not.
Would you believe I knew that?
Whenever you
have to use '\' as path separator you must escape the escape character
('\\' to get it as single character in the source file. Coming in/from
stream the '\' itself is interpreded as path separator.
Would you believe I knew that?
Has nothing to do with software from Redmont.
Yes it has. 99.99999999999999999999999999999999999999999999999 99999999%
of computer users have never seen anything other than '\' as a path
separator. Therefore they think it is, and has always been, the only
path separator in existence. As they use the Bill software more and
more, they become accustomed to it, and it starts replacing '/' in
their minds.
I repeat, IN THEIR MINDS. Not in the actual world. But they start
thinking '\' is the normal slash and '/' is a bastardised abomination,
instead of the other way around.
Using always '/' as path separator in source makes things much easier.


I agree completely, utterly, fully and totally. But Bill, in his
"infinite wisdom", decided otherwise. Microsoft - "if it's a standard,
we'll break it".

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I am not very happy acting pleased whenever prominent scientists overmagnify
intellectual enlightenment."
- Anon
Nov 14 '05 #11

P: n/a
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk? Yes.

Q2) What on earth is the difference between newline and carriage return?

There are three terms involved here: newline, linefeed and carriage
return. They are technically different.

A newline creates a new line, which may involve returning the carriage
to the starting position and advancing one line.

A line feed advances the medium one line text line, which may or may
not cause the carriage to return to the starting position.

A carriage return causes the carriage to return to the start position.
Generally, this does not involve advancing to the next line, but some
output devices may also advance the media after returning the
carriage.

Some newer output devices may also require a Formfeed before the
media is ejected so you can see it.

The exact behavior is implementation defined and not portable. There
are many output devices that contradict the classical definitions.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

Nov 14 '05 #12

P: n/a
john blackburn wrote:
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ
'\r' is simply a carriage return whereas '\n' is a carriage return
followed
by line feed.


Well, from the persprective of this newsgroup, this is certainly wrong.
'\r' is a carriagge return, '\n' is a newline character. From a C
programmers point of view, '\n' is _the_ line separator.
Note that a carriage return is simply that, it moves the
cursor to the beginning of the current line and does not move on to the
next line.

It is here you have to be careful as UNIX text files are of a different
format from Windows text files and need conversion when moving from one
o/s to the other.


On a T200 teletype you had to be carefull to always use _two_ carriage
returns and a linefeed at 75 baud, because the time to move the carriage
from the leftmost position to the rightmost position took almost 1/25
of a second. With '\r\n' you would end up with the first character of
the new line in the middle of the line. However, this is about as relevant
to text file formats from a C programming point of view as the different
_physical_ representations of line separators used in different
environments.

Kurt Watzka
Nov 14 '05 #13

P: n/a
"Herbert Rosenau" <os****@pc-rosenau.de> wrote in
news:wm***************************@URANUS1.DV-ROSENAU.DE:
Using always '/' as path separator in source makes things much easier.


I do not believe compilers are required to support '/' as a path separator
as I do not believe ISO C specifies such a thing.

--
- Mark ->
--
Nov 14 '05 #14

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joona I Palaste wrote:
[snip]
But they start
thinking '\' is the normal slash and '/' is a bastardised abomination,
instead of the other way around.


Sad, but truer than you realize.

A year or so ago, I heard a radio announcer read off a URL as "aich tea
tea pea colon BACKSLASH BACKSLASH double-u double-u double-u ..."

Apparently, he thought that the \ was called "slash", and the / was
called "backslash".
- --

Lew Pitcher, IT Consultant, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFBdp2ragVFX4UWr64RAkxuAKD2PjnlYKv+ow2/CLCF2UkrZrHigwCg1Qbp
B+w9PAvlpEfy2R0rqUlsF3g=
=aWcl
-----END PGP SIGNATURE-----
Nov 14 '05 #15

P: n/a
Joona I Palaste wrote:
I agree completely, utterly, fully and totally. But Bill, in his
"infinite wisdom", decided otherwise. Microsoft - "if it's a standard,
we'll break it".


I always like to think that the '/' character in web URL's and the like are
a nice reminder that the internet is a UNIX invention.

Bill does have a point in the standards arena though; it's not what is
technically best nor what is most technically appropriate nor indeed what
has set the precedent that matters; it is politics and money that matters
(with the emphasis on the latter). This has been proven time and again with
the classic example being VHS versus Betamax.
Nov 14 '05 #16

P: n/a
Lew Pitcher <Le*********@td.com> writes:
Joona I Palaste wrote:
[snip]
But they start
thinking '\' is the normal slash and '/' is a bastardised abomination,
instead of the other way around.


Sad, but truer than you realize.

A year or so ago, I heard a radio announcer read off a URL as "aich tea
tea pea colon BACKSLASH BACKSLASH double-u double-u double-u ..."

Apparently, he thought that the \ was called "slash", and the / was
called "backslash".


Either that, or he uses a browser that allows "http:\\www.whatever"
(though the browser in question does display URLs with the proper '/'
characters).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Nov 14 '05 #17

P: n/a
"Herbert Rosenau" <os****@pc-rosenau.de> writes:
[...]
No. '\' is the ecape character in C in any case.
In file pathes you should use '/' as path separator. Even old DOS
understunds it in its APIs even as command.com would not. Whenever you
have to use '\' as path separator you must escape the escape character
('\\' to get it as single character in the source file. Coming in/from
stream the '\' itself is interpreded as path separator.

Has nothing to do with software from Redmont.

Using always '/' as path separator in source makes things much easier.


The choice of which character is used as a path separator depends on
the operating system. ISO C has no concept of path separators, or
even directories. File names are strings; the interpretation of that
string is entirely system-specific.

<OT>
Unix-like systems use '/' as a path separator. MS-DOS and Windows
normally use '\', but allows it to be replaced with '/' in many (but
not all) contexts. VMS uses '.', but as part of a more complex
syntax. I think some systems have used '>' and ':'.

(Yes, I know that the C character constant for backslash is '\\'; I'm
writing English, not C.)

It's commonly suggested that programmers should use '/' as a path
separator on Windows. I suggest that comp.os.ms-windows.programmer.win32
would be a good place to discuss the pros and cons.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Nov 14 '05 #18

P: n/a
On Wed, 20 Oct 2004 08:11:05 -0500, in comp.lang.c , "Merrill & Michele"
<be********@comcast.net> wrote:
Q2) What on earth is the difference between newline and carriage return?


Think about a typewriter. Carriage return moves the carriage back to the
starting point. Newline moves it to a new line.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #19

P: n/a
On Wed, 20 Oct 2004 16:48:08 +0000 (UTC), in comp.lang.c , "Herbert
Rosenau" <os****@pc-rosenau.de> wrote:
In file pathes you should use '/' as path separator. Even old DOS
understunds it in its APIs even as command.com would not.


There was a hack to fix this. I would explain it, but there's not enough
room in this margin.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #20

P: n/a
john blackburn wrote:
Joona I Palaste wrote:
I agree completely, utterly, fully and totally. But Bill, in his
"infinite wisdom", decided otherwise. Microsoft - "if it's a standard,
we'll break it".


I always like to think that the '/' character in web URL's and the like are
a nice reminder that the internet is a UNIX invention.

Bill does have a point in the standards arena though; it's not what is
technically best nor what is most technically appropriate nor indeed what
has set the precedent that matters; it is politics and money that matters
(with the emphasis on the latter). This has been proven time and again with
the classic example being VHS versus Betamax.


*g* Should I bring up Video 2000 which certainly was better than VHS
and had some advantages over Betamax, too...
Nah, better not.

Cheers,
Michael
--
E-Mail: Mine is a gmx dot de address.
Nov 14 '05 #21

P: n/a
Joona I Palaste wrote:
Mark A. Odell <od*******@hotmail.com> scribbled the following:
"Merrill & Michele" <be********@comcast.net> wrote in
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting
into implementation/platform talk?
I guess so.

Q2) What on earth is the difference between newline and carriage
return?

First, unlike you wrote it in the subject line, they are: \n and \r.
A new line moves the "cursor" down one line, that is, to a new line.
A carriage return brings the "cursor" back to the left margin.
Whether they are treated separately or do the same thing may be
implementation specific.


Seeing as it's now become customary to use \ in all contents where a
divisor sign or an abbreviation for "or" is used, it's only logical
that / is used as an escape sequence marker in program source code.
Bill doesn't only control our computers, he controls our minds as
well.


This is ridiculous. \n has two distinct treatments. One is during
output to a terminal, when its function is to select the next line,
i.e. roll the figurative platen up one line. Nothing more. At the
same time \r returns the platen to the left with whatever
resounding crash is required. This may be very quiet on a display
with no hard copy. The \r was traditionally used to signify the
end of a single line of input, and the magic smoke in the terminal
usually converted it into a \n\r sequence.

However Unix, in its infinite wisdom, decided that all text lines
should be terminated by a single character when in internal
storage. They chose \n for this purpose, although there were more
logical characters available even then. So in this usage it is
used to mark end-of-line, sometimes named EOL. This is just a
convention, principally used in marking line ends on disk files.
Various systems use different conventions (including no or multiple
terminator characters), but they all have to convert to this one
simple one by the time the data hits the fan (which is the churning
CPU).

So make sure you separate the internal usage from the external
usage.

--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan"
"I listened to Toronto come back from 3:0 in '42, I plan to
watch Boston come back from 3:0 in 04"
Nov 14 '05 #22

P: n/a
On Wed, 20 Oct 2004 16:42:09 +0000 (UTC), "Herbert Rosenau"
<os****@pc-rosenau.de> wrote in comp.lang.c:
On Wed, 20 Oct 2004 14:13:16 UTC, john blackburn
<jo*********************@lintonhealy.co.uk> wrote:
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into
implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?

MPJ


'\r' is simply a carriage return whereas '\n' is a carriage return followed
by line feed. Note that a carriage return is simply that, it moves the
cursor to the beginning of the current line and does not move on to the
next line.


No, you should not look on a spezific implementation for that:
\n newline. On one implementation it may be 0x0a,
on another it may be 0x0d, on a third it may be 0x0d0a
on another it may be something else
\r return. on some implementations it is 0x0a
on others it may be something else
\t tab. Often it is 0x09 but other implementations may
use something else

\b bell


No, '\b' is back space. '\a' is 'alert', frequently some sort of
audible ring or beep.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #23

P: n/a
Sometimes.

\n goes to the next line.
\r moves the cursor to the left.

HOWEVER....

Many terminals will take either and do both (CR LF) look in hypreterm it is an
option.

Others require both and in the write order \n\r or \r\n.

So in the end it depends on what you are talking to.
Nov 14 '05 #24

P: n/a
john blackburn wrote:
Joona I Palaste wrote:
I agree completely, utterly, fully and totally. But Bill, in his
"infinite wisdom", decided otherwise. Microsoft - "if it's a standard,
we'll break it".


I always like to think that the '/' character in web URL's and the like are
a nice reminder that the internet is a UNIX invention.

Bill does have a point in the standards arena though; it's not what is
technically best nor what is most technically appropriate nor indeed what
has set the precedent that matters; it is politics and money that matters
(with the emphasis on the latter). This has been proven time and again with
the classic example being VHS versus Betamax.


I have a Sony Betamax recorder for sale.

--
"I support the Red Sox and any team that beats the Yankees"
"Any baby snookums can be a Yankee fan, it takes real moral
fiber to be a Red Sox fan"
"I listened to Toronto come back from 3:0 in '42, I plan to
watch Boston come back from 3:0 in 04"
Nov 14 '05 #25

P: n/a
CBFalconer <cb********@yahoo.com> scribbled the following:
Joona I Palaste wrote:
Mark A. Odell <od*******@hotmail.com> scribbled the following:
"Merrill & Michele" <be********@comcast.net> wrote in

Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting
into implementation/platform talk?
I guess so.

Q2) What on earth is the difference between newline and carriage
return?

First, unlike you wrote it in the subject line, they are: \n and \r.
A new line moves the "cursor" down one line, that is, to a new line.
A carriage return brings the "cursor" back to the left margin.
Whether they are treated separately or do the same thing may be
implementation specific.


Seeing as it's now become customary to use \ in all contents where a
divisor sign or an abbreviation for "or" is used, it's only logical
that / is used as an escape sequence marker in program source code.
Bill doesn't only control our computers, he controls our minds as
well.

This is ridiculous. \n has two distinct treatments. One is during
output to a terminal, when its function is to select the next line,
i.e. roll the figurative platen up one line. Nothing more. At the
same time \r returns the platen to the left with whatever
resounding crash is required. This may be very quiet on a display
with no hard copy. The \r was traditionally used to signify the
end of a single line of input, and the magic smoke in the terminal
usually converted it into a \n\r sequence. However Unix, in its infinite wisdom, decided that all text lines
should be terminated by a single character when in internal
storage. They chose \n for this purpose, although there were more
logical characters available even then. So in this usage it is
used to mark end-of-line, sometimes named EOL. This is just a
convention, principally used in marking line ends on disk files.
Various systems use different conventions (including no or multiple
terminator characters), but they all have to convert to this one
simple one by the time the data hits the fan (which is the churning
CPU). So make sure you separate the internal usage from the external
usage.


Could you please read my other reply in this thread?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"This isn't right. This isn't even wrong."
- Wolfgang Pauli
Nov 14 '05 #26

P: n/a
On Thu, 21 Oct 2004 01:30:34 UTC, Jack Klein <ja*******@spamcop.net>
wrote:
No, you should not look on a spezific implementation for that:
\n newline. On one implementation it may be 0x0a,
on another it may be 0x0d, on a third it may be 0x0d0a
on another it may be something else
\r return. on some implementations it is 0x0a
on others it may be something else
\t tab. Often it is 0x09 but other implementations may
use something else

\b bell


No, '\b' is back space. '\a' is 'alert', frequently some sort of
audible ring or beep.


My mistake, you're right.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation

Nov 14 '05 #27

P: n/a
"john blackburn" <jo*********************@lintonhealy.co.uk> wrote in
message news:41***********************@news.zen.co.uk...
Merrill & Michele wrote:
Section 2.3 of K&R enumerates the complete set of escape sequences.

Q1) Is it possible to ask the following question without getting into implementation/platform talk?

Q2) What on earth is the difference between newline and carriage return?
MPJ
'\r' is simply a carriage return whereas '\n' is a carriage return

followed by line feed. Note that a carriage return is simply that, it moves the cursor to the beginning of the current line and does not move on to the next line.

It is here you have to be careful as UNIX text files are of a different format from Windows text files and need conversion when moving from one o/s to the other.


I wrote a conversion program for Unix files, as I use Windows, mainly.
This is compiled using MS VC++ compiler (but it's C! Honest).
==================
#include <stdio.h>
int main (void)
{
char ch;

// read in chars until EOF
while ( (ch=getc(stdin)) != EOF )
putc (ch, stdout);

return (0);
}

==================
Note that I read in a character and write it back out. The compiler
emits a crlf when it reads in lf! Magic!

--
Mabden
Nov 14 '05 #28

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
[...]
I wrote a conversion program for Unix files, as I use Windows, mainly.
This is compiled using MS VC++ compiler (but it's C! Honest).
==================
#include <stdio.h>
int main (void)
{
char ch;

// read in chars until EOF
while ( (ch=getc(stdin)) != EOF )
putc (ch, stdout);

return (0);
}

==================
Note that I read in a character and write it back out. The compiler
emits a crlf when it reads in lf! Magic!


getc returns an int, not a char; your code can't distinguish between
EOF and a valid character that maps to the same value.

Apart from that, your code probably works (on Windows) because stdio
recognizes a lone ASCII LF character on input as an end-of-line
marker, but writes a CR-LF pair on output. I'm not sure you can
depend on this behavior.

A more reliable way to convert between Windows and Unix formats is to
read and write the data. (I'm not sure how a lone LF in a Windows
text file should be interpreted.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Nov 14 '05 #29

P: n/a
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
[...]
I wrote a conversion program for Unix files, as I use Windows, mainly. This is compiled using MS VC++ compiler (but it's C! Honest).
==================
#include <stdio.h>
int main (void)
{
char ch;

// read in chars until EOF
while ( (ch=getc(stdin)) != EOF )
putc (ch, stdout);

return (0);
}

==================
Note that I read in a character and write it back out. The compiler
emits a crlf when it reads in lf! Magic!
getc returns an int, not a char; your code can't distinguish between
EOF and a valid character that maps to the same value.


Well, that would be a -1 on my system, so it would require a 255 in the
file. The text files I convert "would never have that character". ;-)

I have corrected the program, per your observation. Thank you.

Apart from that, your code probably works (on Windows) because stdio
recognizes a lone ASCII LF character on input as an end-of-line
marker, but writes a CR-LF pair on output. I'm not sure you can
depend on this behavior.
Depend on it how? The program is working fine (better now). If you mean
that it may change in a future compiler, I have comments in the code
that I excluded to explain what is going on.

A more reliable way to convert between Windows and Unix formats is to
read and write the data. (I'm not sure how a lone LF in a Windows
text file should be interpreted.)


You mean in a binary format? I'm not sure what you are saying here, as I
do read and write the data. My original program read in a lf and output
a crlf. This resulted in a crcrlf. That's when I realized it was
automagically adding the cr "for me".

--
Mabden
Nov 14 '05 #30

P: n/a
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]
Apart from that, your code probably works (on Windows) because stdio
recognizes a lone ASCII LF character on input as an end-of-line
marker, but writes a CR-LF pair on output. I'm not sure you can
depend on this behavior.


Depend on it how? The program is working fine (better now). If you mean
that it may change in a future compiler, I have comments in the code
that I excluded to explain what is going on.


The Windows text file format uses a CR-LF pair to mark the end of a
line. If this is based on some written standard, I don't know what
that standard says about a CR or LF character that's not part of a
CR-LF pair. Apparently the stdio implementation you're using treats a
lone LF as an end-of-line marker, and you're depending on this
behavior to "magically" read Unix-format text files that you've
presumably copied without conversion to a Windows system.

If there's a guarantee somewhere that Windows treats a lone LF
character as an end-of-line marker, that's ok. <OT>The fact that
Notepad doesn't do this leads me to suspect that there is no such
guarantee.</OT>
A more reliable way to convert between Windows and Unix formats is to
read and write the data. (I'm not sure how a lone LF in a Windows
text file should be interpreted.)


You mean in a binary format? I'm not sure what you are saying here, as I
do read and write the data. My original program read in a lf and output
a crlf. This resulted in a crcrlf. That's when I realized it was
automagically adding the cr "for me".


Sorry, I left out some words and failed to proofread. I meant "to
read and write the data in binary mode". I believe it's safer to do
this and control the interpretation of the input data yourself, than
to depend on behavior that isn't guaranteed and could change
unpredictably.

Here's what I think is happening in your program. You read a
character at a time from a file opened in text mode. If the next two
bytes are a CR-LF pair (the Windows standard end-of-line marker),
getc() gives you '\n' (C's internal single-character representation of
an end-of-line marker). If the next byte is an LF character, getc()
gives you an LF character, which happens to be the same as C's '\n'
character. The result: your program happens to accept either CR-LF or
LF as an end-of-line marker. Given that getc() happens to work this
way, I *think* you can conclude that the rest of stdio will behave
consistently, for example that fgets() will treat a lone LF character
as an end-of-line marker, but I wouldn't bet large sums of money on
this conclusion.

This happens to work because of the relationship between the Windows
and Unix conventions for marking end-of-line and the value chosen by C
implementations for '\n' (it happens to be the same on both; it
needn't have been). Note that this doesn't work in the opposite
direction. If you copy a Windows text file to a Unix system without
conversion, then read it as a text file, you'll get an extra CR ('\r')
character at the end of each line.

Your program works. With enough research, you might even be able to
prove that it's guaranteed to work. The problem, in my view, is that
the chain of reasoning is too long for comfort.

The best way to convert Unix-format text files to Windows-format text
files is to treat them as binary files (or at least to treat the
"foreign" format as binary) and to do the conversion based on
knowledge of the actual format.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Nov 14 '05 #31

P: n/a
On Sat, 23 Oct 2004 08:47:42 GMT
"Mabden" <mabden@sbc_global.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Mabden" <mabden@sbc_global.net> writes:
[...]
I wrote a conversion program for Unix files, as I use Windows, mainly. This is compiled using MS VC++ compiler (but it's C! Honest).
==================
#include <stdio.h>
int main (void)
{
char ch;

// read in chars until EOF
while ( (ch=getc(stdin)) != EOF )
putc (ch, stdout);

return (0);
}

==================
Note that I read in a character and write it back out. The
compiler emits a crlf when it reads in lf! Magic!

<snip>
Apart from that, your code probably works (on Windows) because stdio
recognizes a lone ASCII LF character on input as an end-of-line
marker, but writes a CR-LF pair on output. I'm not sure you can
depend on this behavior.


Depend on it how? The program is working fine (better now). If you
mean that it may change in a future compiler, I have comments in the
code that I excluded to explain what is going on.

A more reliable way to convert between Windows and Unix formats is
to read and write the data. (I'm not sure how a lone LF in a
Windows text file should be interpreted.)


You mean in a binary format? I'm not sure what you are saying here, as
I do read and write the data. My original program read in a lf and
output a crlf. This resulted in a crcrlf. That's when I realized it
was automagically adding the cr "for me".


I think that the suggestion is to open input and output files as binary
files, then the only translations done will be those done by you. That
way the program will do what you've told it to regardless of what OS you
run it on.

The conversion of \n to CRLF that you see is because stdout is a text
stream and the implementation knows that text files on Windows use CRLF
for line terminations. However, since an LF on it's own is not the
standard line termination for Windows I don't think the implementation
has to report it to you as a \n it could, for instance, treat it as an
error since it is invalid for a text stream.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #32

P: n/a
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Your program works. With enough research, you might even be able to
prove that it's guaranteed to work. The problem, in my view, is that
the chain of reasoning is too long for comfort.

The best way to convert Unix-format text files to Windows-format text
files is to treat them as binary files (or at least to treat the
"foreign" format as binary) and to do the conversion based on
knowledge of the actual format.


I agree with you, that would be better.

For now, however, I think I'll keep my 3 line program and worry about
writing a better conversion routine when Windows command prompts stop
running .COM files properly. It's small, it works, and I only use it
once in a blue moon. The day it fails I'll spend the time to make a
better one. The criticality of performance is essentially zero.

Thanks for all the input.

--
Mabden
Nov 14 '05 #33

P: n/a
"Mabden" <mabden@sbc_global.net> wrote:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
getc returns an int, not a char; your code can't distinguish between
EOF and a valid character that maps to the same value.
Well, that would be a -1 on my system, so it would require a 255 in the
file. The text files I convert "would never have that character". ;-)


So you say. Perhaps you'll one day have to deal with a text file which
uses the character '˙', and you'll scratch your head wondering what on
earth could have caused your program to terminate prematurely...
I have corrected the program, per your observation. Thank you.


It is, after all, a very simple correction. It's doubly useful, btw: if
you ever find yourself using <ctype.h>, passing a negative character
value, _any_ negative character value except the one that happens to be
equal to EOF, causes undefined behaviour (and that one exception doesn't
behave as expected). Passing the original int you got from getc(), which
has the value of either an unsigned char or EOF, works perfectly.

Richard
Nov 14 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.