Bash 3.1.17(8) CR/LF problem

[mwoehlke]

Dave Korn wrote:
> On 27 September 2006 20:42, Malcolm Nixon wrote:
>>     * 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.

I assume he meant 'if you d2u them'.

>>     * 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.

Anyone that has ever had both UNIX and Windows developers working on a 
source tree has had a use for such a feature. Some Windows editors 
(notepad) don't play nice with UNIX line endings, and some UNIX editors 
don't play nice with Windows line endings (more often, mixed endings 
cause problems). Oh, and then there are Mac line endings, too.

It's useful to have the rcs give you text files with native line 
endings. The rcm might then expects the file to stay this way (see 
previous bullet), and will translate it back for storage in the repo. 
Although you're right that this should never be behavior you can't turn off.

OTOH, we all know what the problem is; Microsoft's idiotic decisions to 
Be Different. Thanks to that we have abominations like "ftp 'text' 
mode". :-)

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

Or perfectly valid scripts managed by an unfortunate rcs that insists on 
u2d'ing them on the way down.

-- 
Matthew
The hippo made me do it! What? What do you mean you can't see the hippo?