Text files

[rafal_]

Is difference between interpretation of \n only difference ?

[santosh]

On Thursday 19 Jul 2007 11:33 pm, Kenneth Brody
<ke******@spamcop.netwrote in message
<46***************@spamcop.net>:

ra****@op.pl wrote:

>>
Is difference between interpretation of \n only difference ?

Difference in what?

Oh, I see... You put some critical information in the subject
and failed to include it in the body of your message. The
relevent information is "text files".

So, I assume your question is "are there any differences between
text mode and binary mode, other than '\n' interpretation?"

I rather think the OP meant to ask whether there were any other
differences apart from end-of-line interpretation, between different
text files on different systems.

To the OP:

As far as text files of different system's are concerned, they are
meant to be portable, and to a Standard C program, there should be
no difference between text files created by it and those created by
other implementations.

Under the hood, there may well be many more differences than just the
end-of-line one, but they're all supposed to be well hidden by the
operating system and the C library.

[Barry]

<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

Is difference between interpretation of \n only difference ?

The behavior of fseek.

[Malcolm McLean]

<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker. However on most
systems the text and binary formats are in fact identical.#
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[santosh]

On Friday 20 Jul 2007 1:29 am, Malcolm McLean
<re*******@btinternet.comwrote in message
<jL******************************@bt.com>:

>
<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

>>
Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker.

[ ... ]

AFAIK, this is rare among most modern systems.

[Flash Gordon]

Malcolm McLean wrote, On 19/07/07 20:59:

>
<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker. However on
most systems the text and binary formats are in fact identical.#

So you think most systems are not DOS/Windows/VMS/MacOS-9/whatever? I'm
sure at least one other OS I know has a different format for text files
to binary files, but I'll stick to the ones where I know there are
differences. Also, remember that Windows probably includes WinCE and its
successors which are used in some PDAs and mobile phones.
--
Flash Gordon

[Keith Thompson]

Flash Gordon <sp**@flash-gordon.me.ukwrites:

Malcolm McLean wrote, On 19/07/07 20:59:

><ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegr oups.com...

>>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker. However
on most systems the text and binary formats are in fact identical.#

So you think most systems are not DOS/Windows/VMS/MacOS-9/whatever?
I'm sure at least one other OS I know has a different format for text
files to binary files, but I'll stick to the ones where I know there
are differences. Also, remember that Windows probably includes WinCE
and its successors which are used in some PDAs and mobile phones.

What exactly does "binary format" mean? On many (most?) systems,
there's no such thing as a "binary format" -- or rather, there's a
practically infinite number of such formats, at least potentially.

A text file is (usually) just a special case of a binary file, with
some structure imposed on it.

Now it would make sense to ask what translations are performed when
access a file in text mode as opposed to binary mode, but I'm not sure
whether that's what the OP asked.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

"Malcolm McLean" <re*******@btinternet.comwrites:

<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker. However
on most systems the text and binary formats are in fact identical.#

What on earth is "binary format"?

And what are "most systems"?

[santosh]

Richard wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:

><ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegr oups.com...

>>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker.
However on most systems the text and binary formats are in
fact identical.#

What on earth is "binary format"?

A catch-all name, I presume, for all human-unreadable
information.

[Richard Heathfield]

santosh said:

Richard wrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:

>><ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googleg roups.com...
Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker.
However on most systems the text and binary formats are in
fact identical.#

What on earth is "binary format"?

A catch-all name, I presume, for all human-unreadable
information.

Binary doesn't necessarily mean human-unreadable. Those amongst us who
have written programs in binary, as I have, will almost certainly agree
that, whilst reading binary isn't necessarily top of their Ten Fun
Things To Do Today list, it is nevertheless possible.

In any case, if you're right /and/ Malcolm is right, then text files are
unreadable too, on most systems. Is that your contention?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[osmium]

"Malcolm McLean" wrote:

<ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...

>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker. However on
most systems the text and binary formats are in fact identical.#

The most common form of text files use ASCII code, and there is no character
called 'control Z' in ASCII. Furthermore, I don't know of any compiler for
desktop computers that expects EOF to be encoded in the data, EOF is a
*condition* detected by the OS. One can signal EOF from a keyboard by
pressing the key combination ctrl + 'z', usually written as ^Z, on a DOS
based machine. I think that is what is referred to above, but it has
nothing to do with files. Files are an *external* representation of a data
set, a keyboard is not an external representation.

[santosh]

osmium wrote:

"Malcolm McLean" wrote:

><ra****@op.plwrote in message
news:11**********************@m3g2000hsh.googlegr oups.com...

>>Is difference between interpretation of \n only difference ?

No. Text files often have a control Z as end of file marker.
However on most systems the text and binary formats are in
fact identical.#

The most common form of text files use ASCII code, and there is
no character
called 'control Z' in ASCII.
Furthermore, I don't know of any
compiler for desktop computers that expects EOF to be encoded
in the data, EOF is a
*condition* detected by the OS. One can signal EOF from a
keyboard by pressing the key combination ctrl + 'z', usually
written as ^Z, on a DOS
based machine. I think that is what is referred to above, but
it has
nothing to do with files. Files are an *external*
representation of a data set, a keyboard is not an external
representation.

Many systems though *did* have a so-called end-of-file marker.
For DOS it's ASCII character code 26, which is generated by
pressing CTRL-Z. DOS doesn't use it itself but CP/M systems used
it to mark the end of valid data in a disk block.

[Roberto Waltman]

"osmium" wrote:

>"Malcolm McLean" wrote:

>No. Text files often have a control Z as end of file marker. However on
most systems the text and binary formats are in fact identical.#

The most common form of text files use ASCII code, and there is no character
called 'control Z' in ASCII. Furthermore, I don't know of any compiler for
desktop computers that expects EOF to be encoded in the data, EOF is a
*condition* detected by the OS.

[Off-Topic] CP/M used a 0x1A character (a.k.a "Control-Z") as an EOF
marker "encoded in the data", since the OS kept track of file sizes
only as multiples of 128 byte blocks. (This convention was used only
in text files, obviously.)

Since every CP/M program that manipulated text expected this, and
Microsoft's DOS started its life as a CP/M look alike for the 8086/8
family, DOS programs also interpreted (and many still do) a CTRL-Z as
an EOF mark, and added automatically a CTRL-Z at the end of text files
when closing them. (Try COPYing a file that contains a CTRL-Z in a
Windows system, with and without the /B switch)

There is enough software relying on this, and enough files created
with a CTRL-Z at the end, that the C# language definition includes
provisions to deal with it:

"The C# Programming Language", 2nd ed., (c) 2006

2 - Lexical Structure ...
2.3 - Lexical Analysis ...
2.3.1 - Line Terminators ...
"If the last character of the source file is
a Control-Z character (U+001A) this
character is deleted"

I was forced to do the same eons ago, when writing C programs that had
to be portable between MSDOS, CP/M and DEC's operating systems.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[Peter J. Holzer]

On 2007-07-20 14:10, Roberto Waltman <us****@rwaltman.netwrote:

"osmium" wrote:

>>"Malcolm McLean" wrote:

>>No. Text files often have a control Z as end of file marker. However on
most systems the text and binary formats are in fact identical.#

The most common form of text files use ASCII code, and there is no character
called 'control Z' in ASCII. Furthermore, I don't know of any compiler for
desktop computers that expects EOF to be encoded in the data, EOF is a
*condition* detected by the OS.

[Off-Topic] CP/M used a 0x1A character (a.k.a "Control-Z") as an EOF
marker "encoded in the data", since the OS kept track of file sizes
only as multiples of 128 byte blocks. (This convention was used only
in text files, obviously.)

Since every CP/M program that manipulated text expected this, and
Microsoft's DOS started its life as a CP/M look alike for the 8086/8
family, DOS programs also interpreted (and many still do) a CTRL-Z as
an EOF mark, and added automatically a CTRL-Z at the end of text files
when closing them.

[...]

I was forced to do the same eons ago, when writing C programs that had
to be portable between MSDOS, CP/M and DEC's operating systems.

When I wrote C programs for MS-DOS (eons ago), the stdio libraries of
the compilers I used at the time (Borland and Microsoft) did that
automatically if a file was opened in text mode.

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Roberto Waltman]

"Peter J. Holzer" wrote:

>When I wrote C programs for MS-DOS (eons ago), the stdio libraries of
the compilers I used at the time (Borland and Microsoft) did that

[deleting control-Z]

>automatically if a file was opened in text mode.

Correct. I never had that problem with Borland or MS compilers. The
ones that gave me trouble were: a very early C compiler for DOS, (I
may have been one of the first versions of Lattice-C, I am not sure)
and another for VAS/VMS.
In the second case it was not the compiler's fault. I had to process
data produced by several programs run in sequence, the last one was
some file conversion utility that left the CTRL-Z in place when
producing a regular VMS record-oriented text file.
I found it easier to write a wrapper around the standard file
operations and use it in all systems, deleting a trailing CTRL-Z if it
was there, and doing nothing if it wasn't.

Roberto Waltman

[ Please reply to the group,
return address is invalid ]