From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30355 invoked by alias); 13 Feb 2017 19:15:36 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 30311 invoked by uid 89); 13 Feb 2017 19:15:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=relying, lazily, crs, states X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Feb 2017 19:15:20 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BD9D5811A7 for ; Mon, 13 Feb 2017 19:15:20 +0000 (UTC) Received: from [10.10.123.249] (ovpn-123-249.rdu2.redhat.com [10.10.123.249] (may be forged)) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1DJFJML005882 for ; Mon, 13 Feb 2017 14:15:20 -0500 Subject: Re: [ANNOUNCEMENT] Updated [test]: sed-4.4-1 To: cygwin@cygwin.com References: <589f97c1.1c139d0a.60fe5.98e2@mx.google.com> <20170212113222.GF11666@calimero.vinschen.de> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: <5f509f48-5da7-45f8-fc9e-edc8e541724c@redhat.com> Date: Mon, 13 Feb 2017 19:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170212113222.GF11666@calimero.vinschen.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wsoBm5X7OQIIGi7dbAxVjpKBQ88L2WQOv" X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00175.txt.bz2 --wsoBm5X7OQIIGi7dbAxVjpKBQ88L2WQOv Content-Type: multipart/mixed; boundary="o5OT4E4iUdITFk6CBWgcUrVQoH5sXvI28"; protected-headers="v1" From: Eric Blake To: cygwin@cygwin.com Message-ID: <5f509f48-5da7-45f8-fc9e-edc8e541724c@redhat.com> Subject: Re: [ANNOUNCEMENT] Updated [test]: sed-4.4-1 References: <589f97c1.1c139d0a.60fe5.98e2@mx.google.com> <20170212113222.GF11666@calimero.vinschen.de> In-Reply-To: <20170212113222.GF11666@calimero.vinschen.de> --o5OT4E4iUdITFk6CBWgcUrVQoH5sXvI28 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 1848 On 02/12/2017 05:32 AM, Corinna Vinschen wrote: > I understand the desire but it's s a pretty tricky problem. awk is > used to manipulate text input in the first place so it treats all > input, files as well as stdin, as text. So, shall we drop this > behaviour for files only? Or for stdin as well? How many existing > setups are bound to fail after a change? I think part of the confusion is that POSIX states that awk behavior is only well-defined on "text files" - but that is the POSIX definition of a text file (no invalid characters in multibyte encoding, no over-long lines, no NUL bytes, trailing newline), and not strictly related to the Windows definition of text file (one with CRLF line endings). But remember, just because POSIX says that awk is only required to be well-behaved on text files does not mean that awk cannot be usefully used on non-text files, and anything we do that silently converts binary data into corrupted text, when a binary mount was requested, gets in the way of that usage pattern. As long as we aren't using fopen("rb") to force binary mode, but rather just fopen("r") to let the mount mode rule, we should be okay for any file that we open. As for stdin, ideally stdin is either from a file (where the shell opened it according to mount mode) or from a pipeline (where presumably the other end of the pipe opened the file in the correct mount mode, or where the user can inject a d2u into the pipeline if they want CR stripped). Yes, it means that any existing users that were lazily relying on the forced text mode to automatically strip CRs will now have to fix their scripts to add a d2u invocation, but I already hit some of that fallout when I changed bash to quit forcing text mode. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --o5OT4E4iUdITFk6CBWgcUrVQoH5sXvI28-- --wsoBm5X7OQIIGi7dbAxVjpKBQ88L2WQOv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 604 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYogXGAAoJEKeha0olJ0Nqm/EH/i+MXCfZsnkq9yIIr4MU5vWO EV7i9GZ8+fQwLLw5EpZ4h0YQo82rHPmPPLZYmiYyMbVYxAMyCs+yZas0nnbJmX/B BFjomw8+fJeY3hKyGOKhky0QT3QHYXNqVBo+UUNUbyac8Sm4iIfDwazmnMOI9kmY w0hK3mN559jIFPv4saK63ZTJBytiIQsH5Ll/iwqeBbkKsTqV+u6WdKjVrtHOpUsT C9lwTtu2IsCVEry+s/JlN0t8NrLpav4eCuDKgErvOdTzMOJRgXtO/jHqedmCiBEv x/6tG9XVnVH611Xn622v3bA+PZv+sJy/SFpRDxS0/4gyJGFq5YwsNAJvPUXxbqk= =29+l -----END PGP SIGNATURE----- --wsoBm5X7OQIIGi7dbAxVjpKBQ88L2WQOv--