From:	gewalker AT iquest DOT net (Gary Walker)
Subject:	Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTE
11 Jan 1998 04:13:30 -0800 :
Message-ID:	<001b01bd1e45$082a2b80$38ed35ce.cygnus.gnu-win32@gewalker1>
Mime-Version:	1.0
To:	<gnu-win32 AT cygnus DOT com>

Sorry about that last dup message, fat fingered it and hit send
before adding any content.

Perhaps the slickest solution I've seen is in the Codewright
editor,
when reading a file, it determines whether the text file has been
delimited by \n or \r\n (I don't think it handles \r), and
regardless
of the original format, preserves that and uses that as the line
delimiter for that open file.

Opening pure binary files also works without corrupting the file,
since
it always preserves the original binary. Inserts are simply made
to match the format determined when opening the file (by default,
can
be changed after the file is opened as I recall).

For new & empty files, I think it defaults to native \r\n.

This is a fairly slick technique, and works well regardless.
Cygwin is
not the only place the shows up of course, ftps, nfs mounts,
sneakernet -- all have problems.

Of course, you also want the trivial filters to put the files
into your native O/S preferred format, at least until all
programs get this smart (probably in time to worry about the year
10K problem)

>[...]
>>Not necessarily.  Various programs do this, including vim and,
I think,
>>NTEmacs.
>>
>>>How do the MS-land programs that understand both line
terminations work?
>>>They probably just accept either on input, then do \r\n on
output, right?
>>


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -