Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: RCS for DOS (long)
Message-ID: <1584@sixhub.UUCP>
Date: 23 Aug 90 00:41:55 GMT
References: <1990Aug21.183747.9854@athena.mit.edu> <3235@gmdzi.UUCP>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Distribution: comp
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 36

In article <3235@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes:

|This is a misleading description. MSDOS doesn't differentiate here
|between text and binary files, either. MSDOS inherited the standard
|conforming ASCII newline sequence Carriage Return / Line Feed
|from CP/M. Unix used the simpler, but nonstandard interpretation of
|Line Feed as a single character newline indicator. 
|
|The MSDOS open call does not have a text/binary flag. This flag
|and the translation CR/LF <-> LF are a feature of the libraries
|which come with the current MSDOS C compilers and are there to
|make the C programmers interface to the file system Unix
|compatible.

  Actually this is the way the C language is supposed to work, and has
little to do with DOS. For text files whatever separates records shows
up on input as a \n character. In binary mode the data read is what's in
the file. Other operating systems like VMS or GCOS use other
conventions, such as counts of characters in a record, or various
characters separating lines.


| 
|Of course, this is a minor point. But I am a bit tired to see  
|features where Unix is actually compatible to most versions 
|of itself ;-) presented as inherent Good Things, when they 
|are in fact arbitrary implementation decisions. 
|

  There is an ANSI standard X3J11 which defines this. Followup to
comp.lang.c. 
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me