This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

LF vs. CR/LF (WAS: Problems with libtiff!)


Guys, this is the age old CR vs. LF vs. CR/LF argument.  In an ideal world
all of the freely available code, most of which was originally written for
UNIX, would specify the proper file open mode.  

But to make a point there are cross-platform paradoxes that arise when this
is attempted.  Years ago I ported RCS to MS-DOS.  At the time I had to
address the CR/LF issues in that package.  

Most of the files that are checked into RCS are source files and therefore
contain text, not binary data.  So if the local files are opened in
text-mode and the archives are opened in binary-mode, UNIX & MS-OS can share
archive files and still have their proper line ending in their local
sources.

This works wonderfully until a developer checks in a binary file, like TIFF,
BMP, etc.  Then the LF->CR/LF mapping that occurs on the MS-OS causes
problems.  If the file was checked in from UNIX it breaks on MS-OS and vice
versa.

This one of the reasons why text and binary mode are the same on UNIX, not
to mention that years ago all of the extra CRs added up to wasted storage.

Because of these development issue many of the developers/porters of cygwin
related software continue to use text=binary mounts.  This unfortunately
causes the user community much grief, since most of them come from the MS-OS
world.

The purpose of this project is to enable the easy porting of UNIX based
software to the MS-Windows environment.  Easy porting does not mean wading
through and "correcting" hundreds of file open commands in a large project.


IMO, this means that software needs to work first in text=binary mode.  Then
if a developer has the time to wade through all of the file opens and
correct their mode, wonderful.  But only if he can avoid introducing
cross-platform paradoxes and breaking binary files.

PS. MS-OS = MS-DOS or MS-Windows

-----Original Message-----
From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
Sent: Friday, June 18, 1999 1:22 PM
To: itz@lbin.com
Cc: cygwin@sourceware.cygnus.com
Subject: Re: Problems with libtiff!


--- itz@lbin.com wrote:
-8<-
> But this is a development problem, not a usage one.  Yes, developers
> and porters should be much more careful about their f?open() calls.
> But where users are concerned, I find it hard to use text mounts (and
> recommend them to other users) when even the most important program of
> them all (bash) is not yet binary/text clean.

If you believe that bash has problems with binary/text then the best
solution
would be to find the problems and submit a patch.  BTW, IMO it is readline
that
has the problem and not bash.  I've been using cygwin for a couple of years
now
processing with text default mounts and the only problem I've seen with bash
is
the initialization of the history buffer from the history file.

Changing from a default of text mode processing to a default of binary mode
processing only changes the cause of the headaches.  You still must properly
port the code.  For truly portable code you must specify how the file is to
be
processed before it's processed.  DON'T DEPEND ON DEFAULTS.

===
Earnie Boyd <mailto:earnie_boyd@yahoo.com>

Newbies, please visit
<http://www.freeyellow.com/members5/gw32/index.html>

(If you respond to the list, then please don't include me)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]