how to delete a character in a file ?

[Dik T. Winter]

Trying to clarify things.


Wrong. On the Mac the linemarker is a CR, not a LF. And there is just a
single character there. (This entirely conforms to the ASCII standard of
that time which states that when only a single character is used to mark
the end of a line, the CR should be used. Unix violated this.)

> OT: I am 100% positive that traditional MacOS (up to and including
> MacOS9) use the byte with value 13 to separate text line, with no 10.

You are right.

> Getting back on topic: Apple's own C comilers, part of MPW Shell, indeed
> defines '\n' as 13, and '\r' as 10. This is NOT an option (contrary to
> other compilers). This cause no porting problem with most code.

It better should defind '\n' as 13, because that is the way it is.
However, when transporting text files from the Mac to Unix I always

> [OT: there are headaches when moving files across a network. The
> worse is that for diacriticals such as eacute encoded on a byte, Apple
> has used FOUR different encodings on the Apple2, Lisa, Traditional MacOS,
> and MacOSX; and none of these is the same as in DOS].

MacOSX uses ISO 8859-1, I think.

 

[S!mb@]

(i.e. with "rb" as the second argument to fopen() when you want t
open the file for reading)

ok, it works perfectly !

thx.

I had to open the file for reading AND the file for writing with "b",
now, all bytes are detected.
(opening a file for writing without "b" will write CR LF under windows
when it was asked to write the car number 10).

Jerem

 

[S!mb@]

(e-mail address removed)-berlin.de wrote:

thx an other time for this tips (the "b" parameter), coz it is not
written in the man of fopen :

"The character b has no effect, but is allowed for ISO C standard
conformance. Opening a file with read mode (r as the first character in
the mode argument) fails if the file does not exist or cannot be read."

http://www.opengroup.org/onlinepubs/007908799/xsh/fopen.html

jerem.

 

[Jens.Toerring]

thx an other time for this tips (the "b" parameter), coz it is not
written in the man of fopen :

"The character b has no effect, but is allowed for ISO C standard
conformance. Opening a file with read mode (r as the first character in
the mode argument) fails if the file does not exist or cannot be read."

http://www.opengroup.org/onlinepubs/007908799/xsh/fopen.html

Well, you shouldn't use UNIX specifications when you want to know
about the properties of a function under Windows. Under UNIX it
doesn't make a difference because there the EOL marker is the
single character '\n' (ASCII 0x0A). But under Windows the
"\r\n" -> '\n' takes place when reading text files and the
reverse when writing. But, of course, you normally won't find
that mentioned in e.g. a UNIX man page. The only really relevant
piece of information is the C standard, where you find

A text stream is an ordered sequence of characters...
...Characters may have to be added, altered, or deleted
on input and output to conform to differing conventions for
representing text in the host environment. Thus, there need
not be a one-to-one correspondence between the characters in
a stream and those in the external representation...

where "text stream" is what you read from or write to a FILE* you
got from e.g. fopen() in text mode and the "external representation"
is the way the file looks like on the disk.

Regards, Jens

 

[Dan Pop]

Wrong. On the Mac the linemarker is a CR, not a LF. And there is just a
single character there. (This entirely conforms to the ASCII standard of
that time which states that when only a single character is used to mark
the end of a line, the CR should be used. Unix violated this.)

^^^^^^^^^^^^^^^^^^
From http://www.campusprogram.com/reference/en/wikipedia/n/ne/new_line.html

0A, respectively. (In the 1958 version of ASCII, for which Multics
was originally designed, there was a separate newline (NL) character
in addition to CR and LF. The 1963 revision combined NL with LF,
and Multics followed suit. Unix followed the Multics practice, and
later systems followed Unix.)

Dan

 

[Mabden]

I had to open the file for reading AND the file for writing with "b",
now, all bytes are detected.
(opening a file for writing without "b" will write CR LF under windows
when it was asked to write the car number 10).

I find it amusing that when I needed to convert Linux files to MS Windows OS
files I wrote the following program and it works!
================================================
/* lf2crlf.c
Copies lines from stdin to stdout, changing the Linefeed character
to Carriage Return / Linefeed.
*/
#include <stdio.h>
int main (void)
{
char ch;

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

 

[Tom Van Vleck]

(e-mail address removed) (Dan Pop) wrote...

(In the 1958 version of ASCII, for which Multics
was originally designed, there was a separate newline (NL) character
in addition to CR and LF. The 1963 revision combined NL with LF,
and Multics followed suit. Unix followed the Multics practice, and
later systems followed Unix.)

Two corrections. 1968, not 1958.

Second, there was not a separate NL in addition to CR and LF.
In proposed-revised-1968-ASCII, the code we used,
there were NL and CR. I think the standard said something like
"CR followed by NL should work, and if you use only one character
for a line separator, use NL."

If I remember correctly, Teletypes used CR and LF for
news and message transmission, and whether a TTY did a CR when
it received the LF code was a per-machine option. The Multics
TTY Device Interface Module converted the storage code of LF
into whatever was needed to accomplish a new line: for Teletypes
I think it sent CR, LF, and some number of delay characters.