Message-ID: <860934040609271346ue482106q9af69c06d6ee000f@mail.gmail.com>
Date: Wed, 27 Sep 2006 13:46:50 -0700
From: "Malcolm Nixon" <malcolm DOT nixon AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: RE: Bash 3.1.17(8) CR/LF problem
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

> So why isn't using a textmode mount a solution?
Packages generally contain the sources, build scripts, tools binaries, etc
in a single directory tree. For example a ./configure script located in the
package root directory along side other project files. As such placing just
the bash scripts in a textmode mount would be virtually impossible.

In my case we're talking about a number of non-unix developers
with existing Cygwin installations (with no textmode mounts) that they
update periodically. They're going to take their functioning Cygwin
installations, run an update at the end of the month to get the latest
stable security patches, and have their build environment turn to goo.


>>     * Some revision control systems make the files read-only.
>  Huh?  You mean, permanently?  How are you supposed to edit them?  You don't
> need an RCS for a read-only file that can't ever be changed, you can just burn
> a copy to CD.
The revision control system I'm using as an example here is Perforce. Perforce
will build you a local repository with all files read-only. If the
files are modified
to read-write and/or are modified in any way, then Perforce will
refuse to manage
the file until it is deleted and re-fetched.

>>     * Some detect the change to <LF> as changes require manual merging.
> What, on lines that you /haven't/ edited locally?  That's just a bug.
Perforce translates to CR/LF when it gets the file on a Windows system. Any
modification at all (read-only / line-ends) is a local edit.

>>     * Some translate files to a "Local" format (CR/LF on Windows).
> FCOL, what on earth does an rcs think it's playing at, tampering with your
> data?  Any rcs that doesn't give you back exactly what you put into it is just
> plain buggy.  Nobody asked for a "automatically mangle my data whether I want
> you to or not" feature.
This is a Perforce 'feature' if you wish to call it that. Perforce
will translate
files you have specified as 'Text' to whatever 'Text' means on the local system
 - LF on Unixes and CR/LF on Windows. One potential workaround would be to
declare the script files as binary files so they aren't touched, but
then you loose
the ability to diff.

>>   I think the bigger issue here is that this arbitrary change will break
>>   a "significant" number of existing scripts.
> YM a "significant" number of /broken/ scripts.  Try running any of them on a
> linux box and see what you get.
Agreed, on a linux box the Perforce command-line utility would get me a LF
terminated bash script which would run fine. The point I was trying to make was
for backwards compatibility. If Cygwin Bash had never supported CR/LF on
a virgin installation then we wouldn't be having this discussion. The problem
sems from introducing CR/LF as a feature, and then removing it once the
feature is depended upon by members of the community.

>  Then according to your opinion, everyone else in the world has to suffer
> from crippled bash performance because you can't be bothered to fix your
> systems.  Better for /you/ maybe, but it's not always all about you.  In MY
> opinion, a better solution would be to err on the side of efficency, and only
> use the old slow readline code if manually enabled.
It would be better for Windows(tm) if they completely removed support for
16-bit applications, but the community they are supporting would be up in
arms over it. If people want pure Linux behavior, then they just install
Linux. I know that CR/LF sucks, but at the same time I am forced to
recognize that's the Windows standard, and a significant number of Windows
tools require it.

My issue comes from breaking compatibility and forcing people to expend
time and money to fix systems that used to work. I think part of my
frustration comes from the fact that I can't even fix this by adding a few
checks/commands to the root build script because I can't get the root build
script to run any more.

Instead I'll have to create a document and get it out PDQ before the next
security patch that describes how to modify Cygwin from the default virgin
configuration to one with textmode mounts or an equivalent modification.

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