VMS vs. UNIX file system

[Guy Harris]

> I disagree.  I much prefer VMS's variable-length-record text file format
> to Unix's byte-stream.  Why?  Because the Unix byte stream uses perfectly
> legitimate data as a record separator.  To make matters worse, the standard
> C method for dealing with strings uses a *different* character as a string
> terminator!  Unix has a lot of GREAT ideas in it, but this isn't one of them.

Umm, as others have already pointed out, UNIX doesn't use '\n' as a record
separator; it uses it as a *line* separator.  UNIX - like VMS - ultimately (at
the kernel level) implements files as a sequence of bytes (RMS sits on top of
QIOs that read virtual blocks of the file, *n'est ce pas?*).

One file format UNIX happens to implement atop this abstraction is the "text
file"; "text files" consist of "lines", which are sequences of bytes (not
containing '\0' - some applications can't handle them, since it's the C string
terminator) ending with '\n'.

Other file formats exist, such as executable images and archives, which are,
respectively, the UNIX equivalents of images (and object files - object files
and images use the same format) and library files.

However, UNIX doesn't come standard with any libraries that implement "record"
files.  Such libraries are available from third-party vendors (e.g., C-ISAM),
and I very much doubt that they use '\n' or any other particular byte value as
a record separator.

Some of the real differences between UNIX and VMS here are that:

	1) As already stated, VMS comes with libraries that implement "record"
	   files, while UNIX doesn't;

	2) Many UNIX utilities (e.g., "cp") deal with files at the byte-stream
	   level, so they don't care *what* format the file is in;

	3) Many more UNIX facilities use text files, rather than record files,
	   as their underlying file format; while one reason for this may be
	   the absence of a "record file" library, another reason is that you
	   can use the standard UNIX text file tools to manipulate those files.