This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Bash 3.1.17(8) CR/LF problem


Malcolm Nixon wrote:
mwoehlke wrote:
Right; non-standard behavior (and any non-binary treatment
of '\r' certainly counts!) should - and I might dare even to say
"must" - be disabled by default. Although in this case I can't
think of any reason why you would ever have a '\r' in a shell
script (other than as part of a line ending). Although if we
make any of this optional, then IMO it needs to be done the
right way, which is to just ignore '\r', at least at the end of
lines. That way we can ALWAYS read in binary mode, and
it isn't a major performance penalty.

I guess I'm 50/50 here. On one hand <CR> is most certainly not a standard line terminator character on Unix systems, but at the same time Cygwin advertises a "collection of tools which provide Linux look and feel" for Windows.

If pure Linux compatibility/restrictions was the only goal, then
it could be achieved far easier by running Debian in a VM.


Not true.  Running a different O/S on the same or other machine
does not give the same interoperability that Cygwin does, regardless
of issues that come up where UNIX/Linux conventions clash with
Windows.  This argument is a red-herring.


Instead Cygwin tries to add the power of the Linux-like tools
into the cruftiness of Windows. Unfortunately I believe that implies
supporting Windows/DOS crufty CR/LF files.

No one said that Cygwin tools don't support CR/LFs. If they didn't, there would be no text mounts. Every text file generated by Windows apps would need to be filtered before processed by Cygwin apps. And bash and all the other shells wouldn't work with text files in any way. But they do. The fact that you haven't been able to bash to work transparently in your environment is merely an indication that you don't completely understand the problem yet (or haven't been able to communicate it well to the list). Obviously, whether bash changes in any way based on your feedback is a decision completely in the hands of the maintainer. But what you've described so far isn't adding up and my guess is you're going to have to offer a more convincing argument based on detailed facts relevant to the problem you're having to sway the hearts and minds of those who do the work.


-- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746

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


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