Subject: RE: ASCII and BINARY files. Why?
From: [email-masked] (Fran Litterio)

30 Jan 1997 09:14:29 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <c=US%a=_%p=Amulet._Inc.%l=[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Original-To: "'Jim Balter'" <[email-masked]>
Original-Cc: "[email-masked]'" <[email-masked]>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
Original-Sender: [email-masked]

Jim Balter wrote:

>Fran Litterio wrote:
>> I just tried Notepad under NT 4.0 Workstation, and it works fine on text
>> files lacking any CRs.
>
>Did you check the file size to be *sure* that it does not contain CR's?
>On my NT 4.0 system, Notepad shows naked linefeeds as solid blocks
>and does not break the line after them.

Mea culpa.  I was trusting the output of od -x to show me every byte in
the text file (even though I wasn't using mount -b).  od -x didn't show
me any CRs, even though they were there.

>unix deals with byte streams, and there are many tools for
>manipulating them, rather than having systems that think
>they know what they are doing deleting every byte after a ^Z
>and destroying valuable work.

Yes.  I am now completely convinced that gnu-win32 should switch to an
all-binary-all-the-time scheme.  read() should not convert CRNL to NL
(nor write() do the reverse).  cat should not have implicit knowledge of
what a ^Z means (i.e., nothing under UNIX).  The gnu-win32 DLL should
probably even be made recognize a ^D typed on the keyboard (not coming
down a pipe) to mean end-of-file.  I'm not opposed to activating these
non-UNIX behaviors conditionally (i.e., via environment variables, mount
options, filename prefixes, etc.), but the default behavior should be
all-binary-all-the-time.
--
Francis Litterio
[email-masked]
http://world.std.com/~franl/

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".