Mail Archives: cygwin/2006/09/27/23:02:55
> From: Eric Blake
> Sent: Wednesday, September 27, 2006 8:42 PM
> Subject: Re: Problems with archiver "ar"
>
[snip]
> >
> > But due to the newest bash update, I rather need "textmode"
> to re-use
> > my existing scripts without conversion, as the come from a revision
> > control system which always generates the EOLs according to
> the underlying system.
>
> See the other thread on this today. First, why can't you
> teach your revision control system that on a cygwin binary
> mount, the underlying system uses \n line endings, not \r\n?
I hate to sound like a broken record, but not-quite-correct statements such
as the above give aid and comfort to our common enemy, The "/r/n vs /n vs
/r" Debacle Which None Of Us Shall Live Long Enough To See Resolved, and I
therefore must wax pedantic:
The "underlying system" (i.e. Windows, Linux, Cygwin binary mounts,
whatever) has no notion of what a "line ending" even is, much less what
values might represent it. Bytes is bytes; have been since CP/M died.
Programs which manipulate text in some way, and the libraries they link
with, are who and what define the notion of a text file, and hence text file
formats, and hence "line endings".
Most of these programs and/or libraries are broken in either implementation
or design, in that they are only capable of reading one text file format.
When faced with the simple task of reading a plain text file with a format
other than the One True Format which they can handle, they fail, with
varying degrees of spectacularity. Researchers have been unable to
determine why, in the 21st century, this problem is still as bad as its ever
been, but such is the sorry state of affairs of the Computer Science world
we live in.
At any rate, in an effort to mitigate the inevitable problems caused by
these broken programs, workarounds such as Cygwin's "text mode mount" were
invented. Of course, Life never closes a door without also closing a
window, and these workarounds are not without their own problems. There can
be speed issues, especially if the broken program wants random access to the
file (lseek()/fseek()). Programs that are broken in the opposite direction,
i.e. programs which treat all files - executables, binaries, graphics,
whatever - as if they were text files in their One True Format, can be
broken (and yes, as impossible as it is to believe, such programs are not at
all uncommon!).
The good news, Gentle Reader, is that there is a teeny-tiny glimmer of hope
on the horizon: Unicode. The Unicode standard actually had the courage to
define not one, but no less than *seven* valid line terminator sequences
(q.v.: http://en.wikipedia.org/wiki/Newline). So, as Unixoid, Windowsoid,
and Macoid tools slowly become Unicode-capable, and assuming they make even
a token attempt at meeting the standard, perhaps, some day, our great,
great, great, greatgreatgreat grandchildren will be able to creat a plain
text file on one computer and have it be understood on another.
But I wouldn't put money on it.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -