On Wed, Sep 13, 2006 at 04:46:28PM -0700, Volker Quetschke wrote: >mwoehlke wrote: >>Eric Blake wrote: >>>mwoehlke <mwoehlke <at> tibco.com> writes: >(snip) >>>... If the scan in binary mode succeeds, then leave the file in binary >>>mode, assuming that the file is unix format even though it is on a text >>>mount, and that lseeks will work. If the file starts life binary mode >>>(ie. was on a binary mount), skip the check for \r in the scan (under >>>the assumption that on a binary mount, \r is intentional and not a line >>>ending to be collapsed), and use lseeks. No guarantees on whether this >>>will pan out, or be bigger than I thought, but hopefully you will see a >>>bash 3.1-8 with these semantics soon. >> >>Sounds good! That will satisfy my request to not silently work on files >>that should be broken. :-) > >I'm seeing the next "make doesn't work anymore with DOS ... feature" >coming up here, only that it is bash this time. Apparently a lot of >people use tools from cygwin to build Windows stuff in a *NIX build >environment.
Do I have to make the observation again that whether this is the case or not, it is not a primary goal of the Cygwin project to support these people? As long as you have Corinna or myself in charge we are going to stick with the whole "Linux on Windows" thing. If bash doesn't like \r\n line endings on Linux, if we purposely recommend against using text mode files, and if we can see noticeable performance improvements in bash from not honoring \r\n line endings, then bash should definitely be using the "binmode" code. If Eric cares enough to make \r\n shell scripts work in bash, then more power to him. If he doesn't then I have no problem with releasing a bash that hiccups on files which use \r\n and informing people that they should fix their scripts. cgf -- 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/
