Your problem is with ASCII itself. CRLF is the correct ASCII line ending because LF only advances the line and CR only returns to the beginning of the line. Just CR would overwrite characters on the same line and just LF would keep the same horizontal position.
VMS has STREAM (CRLF ending), STREAM_CR (CR ending), STREAM_LF (LF ending), and VARIABLE (two-byte length prefix) types of text files so this wouldn't even be a problem on VMS. UNIX doesn't even have a concept of text files, just sequences of bytes.
https://tools.ietf.org/html/rfc854
NAME CODE MEANING
NULL (NUL) 0 No Operation
Line Feed (LF) 10 Moves the printer to the
next print line, keeping the
same horizontal position.
Carriage Return (CR) 13 Moves the printer to the left
margin of the current line.
UNIX "translates" it's special line endings to the real CRLF control characters. If you display UNIX "text" on a real terminal or "raw" settings, the next line will begin in the same column as the previous line because that's how the ASCII control characters are defined.
$ stty raw; printf "\r\nAT&T sucks\rUNIX\n but VMS doesn't\r\n"
UNIX sucks
but VMS doesn't
>In another article WD writes:
>|> [of VMS]
>|> I sure hope so. Any o/s which puts file types in the o/s
>|> instead of the program is really creating problems for the
>|> user, and I find that more of a problem than the user
>|> interface. If programs really want a "$ delimited left
>|> handed nybble swapped hexadecimal" file type, let it be
>|> done in the program or shared library, and not at a level
>|> when all user-written file transfer and backup programs
>|> have to deal with it. As my youngest says "yucky-poo!"
Huh? Let's think about this.
Tighter integration of file types to the OS are not a
problem. In my experience, UNIX offers the weakest file
maintenance offerings in the industry, save for MS-DOS. In
using Tandem Guardian and VMS I've found that ultimately,
one could:
* Back up files.
* Transfer files.
* Convert files.
...much more easily and safely than with UNIX. Yes, it was
between Guardian or VMS systems but instead of going into an
"open systems" (whatever THOSE are) snit, read on.
As a result:
* Each RDBMS has its own backup and restore facility of
varying functionality, quality, and effectiveness,
complicating support for sites adopting more than one
RDBMS.
* All existing UNIX backup and restore facilities are highly
dysfunctional compared to similar facilities under the
aforementioned operating systems. They can make only the
grossest assumptions about file contents (back it up or
not, bud?) and thus cause vast redundancy in backups; if
you change a single byte in the file, you back up the
whole thing instead of changed records.
* Transferring files from system to system under UNIX
requires that all layers of functionality be present on
both sides to interpret files of arbitrary form and
content. Embedded file systems ensure that file transfer
is enhanced because the interpretation and manipulation
facilities will be there even if the highest layers
aren't (ie: you can at least decompose the file). Find
me one person who guarantees they can decompose an Oracle
or Ingres file (ie: someone who has a product that will
always do it and guarantees it'll work for all successive
releases of these packages).
Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages. How many B*Tree
packages do we NEED? I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas. So why not support certain
common denominators in the OS?
Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy. If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...