From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1099 invoked by alias); 13 Sep 2006 23:46:45 -0000 Received: (qmail 1089 invoked by uid 22791); 13 Sep 2006 23:46:45 -0000 X-Spam-Check-By: sourceware.org Received: from neptune.phys.ufl.edu (HELO neptune.phys.ufl.edu) (128.227.64.7) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Sep 2006 23:46:42 +0000 Received: from [127.0.0.1] (neptune.phys.ufl.edu [128.227.64.7]) by neptune.phys.ufl.edu (Postfix) with ESMTP id B1B6E6076 for ; Wed, 13 Sep 2006 19:46:39 -0400 (EDT) Message-ID: <45089854.8010705@scytek.de> Date: Wed, 13 Sep 2006 23:46:00 -0000 From: Volker Quetschke User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: bash-3.1-7　BUG References: <091320060438.11140.45078B490008FD8600002B8422007610640A050E040D0C079D0A@comcast.net> <20060913052510.GB1256@trixie.casa.cgf.cx> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E69E5F85BCF4B3D6566A320" X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2006-09/txt/msg00258.txt.bz2 --------------enig4E69E5F85BCF4B3D6566A320 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 1715 Hi, mwoehlke wrote: > Eric Blake wrote: >> mwoehlke 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. >=20 > 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. Not many people that just "use" the tools read this ml and therefore test if their favorite application still builds. It is definitely in the eye of the beholder if one calls shell scripts that worked so far as broken just because they have /r/n line endings. I'll try to build my favorite testcase OpenOffice.org to see if there are s= ome shell scripts with "broken" lineendings hidden in this 500MB sourcecode mon= ster. On a separate note, both gcc and Microsofts cl.exe don't care about the lineendings, neither does tcsh, why should bash start to punish the offenders? Volker --=20 PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D --------------enig4E69E5F85BCF4B3D6566A320 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 250 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MinGW) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCJhcPTXJup+KeF0RAqAhAKCBgn2rlJkaVZ7AH8dwH/SKvQB7tgCfVh/f suFEMZLnAqzOXo2qvaC8d00= =dYLZ -----END PGP SIGNATURE----- --------------enig4E69E5F85BCF4B3D6566A320--