From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8795 invoked by alias); 8 Jan 2019 11:27:13 -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 8778 invoked by uid 89); 8 Jan 2019 11:27:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-98.5 required=5.0 tests=BAYES_20,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=drawing, profit, sk:operati, developing X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.130) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Jan 2019 11:27:11 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MpUQm-1h3q5o0Exw-00pxPB for ; Tue, 08 Jan 2019 12:27:08 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id DB9A0A8075F; Tue, 8 Jan 2019 12:27:05 +0100 (CET) Date: Tue, 08 Jan 2019 11:27:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Bash heredoc on FD 3 Message-ID: <20190108112705.GF593@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20190107190313.GD593@calimero.vinschen.de> <5c33ec76.1c69fb81.10fee.7eef@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <5c33ec76.1c69fb81.10fee.7eef@mx.google.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-01/txt/msg00031.txt.bz2 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2934 On Jan 7 16:19, Steven Penny wrote: > On Mon, 7 Jan 2019 20:03:13, Corinna Vinschen wrote: > > I can't reproduce this with my latest code. It works fine for me > > every time, independently of POSIXLY_CORRECT. > >=20 > > I uploaded new snapshots to https://cygwin.com/snapshots/ with all > > the latest changes. Please try again. >=20 > I retested with cygwin1-20190107.dll.xz. My results below. Note that "suc= cess" > means that with Bash, the script runs without error, regardless of > "POSIXLY_CORRECT" variable as you said. "failure" is to mean that with Ba= sh, > running with "POSIXLY_CORRECT" produces this error: >=20 > awk: error: can't open source file `/dev/fd/3' for reading (Permission > denied) >=20 > Windows 10: success > Windows 8.1: failure > Windows 7: failure >=20 > Testing done using virtual machines from here: >=20 > https://developer.microsoft.com/microsoft-edge/tools/vms >=20 > Even if we must leave things as is, maybe its not that bad. Ideally it sh= ould be > working regardless of the variable as you said, but on all 3 Windows vers= ion. > But at least we have a workaround if need be. I would like to avoid unset= ting > POSIXLY_CORRECT if I can though as it tends to be a net positive for me -= as it > forces me to be more strict with code writing. >=20 > Also some might have the opinion "so what", lul those are old. Well, yes = they > are but Windows 7 still has a higher marketshare than Windows 10: >=20 > https://netmarketshare.com/operating-system-market-share?id=3DplatformsDe= sktopVersions >=20 > so until that changes I think we should consider it in the decsion making > process. I could reproduce this on W8.1. After some debugging it turned out that this is, in fact, not related to POSIXLY_CORRECT at all. POSIXLY_CORRECT only changes the way the file is used in gawk. If POSIXLY_CORRECT isn't set, it just uses the incoming file descriptor 3 due to some code handling the path "/dev/fd/" differently. This works fine under all circumstances because it does not trigger my new code for /proc//fd/ at all. However, as soon as POSIXLY_CORRECT is set, my new code is triggered and falls flat on its face on pre-W10 systems (serves me right for developing and testing on W10 only). The reason is that file delete semantics have changed on W10. On pre-W10, reopening a file by handle (equivalent to the Win32 API call ReOpenFile) does not work on files for which the delete dispostion has been set. This works fine on W10, though. Back to the drawing board. I have an idea or two how to workaround this shortcoming of pre-W10 systems. Just FTR, I really like what MSFT changes in W10 under the hood. I'm especially happy that the changes for WSL are exposed to the Windows subsystem, too, so we can profit from them as well. Personally I'm not looking back to pre-W10 systems at all. Corinna --=20 Corinna Vinschen Cygwin Maintainer --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlw0iQkACgkQ9TYGna5E T6Aiyw//TyX60x/TeEHkmw68KC9cy1fXHvvKYDTNEnRUIfhWmnhUhhp65MrWKRga oLBjyRys+iG/vfpjHxzO6kMZZhj47+qWDAoa3TOanAuOWtddN5NdQBj8Fp9j494n vXYPxdSxep3uXDV/t7AFnorfKMiOd/TE4cX6PWfn5GSl9cTsK8JglYLElXBkcvOs 8ZurukAW0wtMTdCGNvvi2nMV0R22R1UdtfMFBKtzely7bOC0e0wmn45LBUFuCdME cbvYGvh+PwIUz71r9VAAzHTu7uLY4O5SunEKGm1ixWtFD6JR+56kw58z//f3HxIl aK1FtoU63FUfwD71qkDioPrLDuOk1BU1Xdmx2NLNxa6bmA9ZYgs8j0llApRrFU7v qfNQ6hzAxP4nNmhoYIqITOK8dozOvHRqNr01Ri+r8DZDtb0CQZC4g1TYTty6PGyL 4BnA2b5Jpo16PmNSHiwQsEWAVmvMYQFsH661wKt5Jse1P8DAh7coLxdHGrqnJVhe sDLI/kFmPrnsBCLxFykFQ12YdN/7+rgtVcELPCD673cjvdSRIBz2jYGze37r6VcP Atfw0kPTLaOFbXzALy6EFsk7ZjTJSAGyuFT0/GxWCBDXl/CM4CnbKJX5DQI6PePP 68d/h+PgscyUgYf7dnDzWCdAisk7POmsvgAVJ/C00lt50FOnAiE= =NJwM -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13--