> 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/
