VMS vs. UNIX file system
Guy Harris
guy at gorodish.Sun.COM
Mon Sep 19 13:43:59 AEST 1988
> 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.
More information about the Comp.unix.wizards
mailing list