Print

Print


At 11:19 +0100 2001/02/15, Rainer Schoepf wrote:
>> Are these OS's in continued widespread use, or are they dying? -- The thing
>> is that without those OS line separator convetions, one can decide that a
>> line separator should be \l, \r, or a \r\l (as in Java), and that would be
>> platform independent.
>
>That's totally irrelevant. You are confusing OS level and library level.
>What you see in Java is at the library level and has near to nothing to do
>with the underlying operating system.
>
>To take OpenVMS, it has various OS level file formats (both stream and
>record oriented), many of which can be used for textual data. In every
>case you can read characters or lines or whatever if your language library
>offers the functionality. In Java you see \r\l, in C \n.

No, you got it wrong: One can open a file as a text file or as binary file:
In C, if you open it as a text file, the local OS convention line
separators are translated into \n, but if you open it as a binary, you see
whatever is in the file.

The idea of open a file as text file does not work well say on a Mac, if
you happen to have a mixture say UNIX, MSOS & MacOS files. So one way
around it, is to let your program read either of \n, \r, or \r\n as a
single line separator. Under C this can be done either by requiring the
files to be opened as binary and add such parsing, or to tweak the C text
file open mode to translate them into the usual \n.

However, the first way does not work under OS's that does not use the UNIX,
MSOS  or MacOS conventions. So one must then know what exactly they are
doing.

>And still, it has nothing to do with input encoding or internal
>representation.

Please explain: To me \n and \r seems different. Or are you claiming that
there is God given law that requires one to open all files in text mode? :-)

  Hans Aberg