Re: Bash heredoc on FD 3

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

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.
> > 
> > I uploaded new snapshots to https://cygwin.com/snapshots/ with all
> > the latest changes.  Please try again.
> 
> I retested with cygwin1-20190107.dll.xz. My results below. Note that "success"
> means that with Bash, the script runs without error, regardless of
> "POSIXLY_CORRECT" variable as you said. "failure" is to mean that with Bash,
> running with "POSIXLY_CORRECT" produces this error:
> 
>    awk: error: can't open source file `/dev/fd/3' for reading (Permission
>    denied)
> 
> Windows 10: success
> Windows 8.1: failure
> Windows 7: failure
> 
> Testing done using virtual machines from here:
> 
> https://developer.microsoft.com/microsoft-edge/tools/vms
> 
> Even if we must leave things as is, maybe its not that bad. Ideally it should be
> working regardless of the variable as you said, but on all 3 Windows version.
> But at least we have a workaround if need be. I would like to avoid unsetting
> 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.
> 
> 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:
> 
> https://netmarketshare.com/operating-system-market-share?id=platformsDesktopVersions
> 
> 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/<descriptor>" differently.
This works fine under all circumstances because it does not trigger my
new code for /proc/<pid>/fd/<descriptor> 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

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]