Bash heredoc on FD 3

Bash heredoc on FD 3

[Steven Penny]

Using this file:

    $ cat hello.sh
    awk -f /dev/fd/3 3<<eof
    BEGIN {
      print "hello world"
    }
    eof

it runs as expected with Dash:

    $ dash hello.sh
    hello world

However it fails with Bash:

    $ bash hello.sh
    awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or
    directory)

I tried also with Debian and both Dash and Bash work as expected. What is
causing Cygwin Bash to fail here?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[cyg Simple]

On 12/2/2018 1:43 PM, Steven Penny wrote:
> Using this file:
> 
>     $ cat hello.sh
>     awk -f /dev/fd/3 3<<eof
>     BEGIN {
>       print "hello world"
>     }
>     eof
> 
> it runs as expected with Dash:
> 
>     $ dash hello.sh
>     hello world
> 
> However it fails with Bash:
> 
>     $ bash hello.sh
>     awk: fatal: can't open source file `/dev/fd/3' for reading (No such 
> file or
>     directory)
> 
> I tried also with Debian and both Dash and Bash work as expected. What is
> causing Cygwin Bash to fail here?

Same for me and interestingly:

$ ls -ld /dev/fd/*
ls: cannot access '/dev/fd/3': No such file or directory
ls: cannot access '/dev/fd/31': No such file or directory
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/0 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/1 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/2 -> /dev/pty2

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[cyg Simple]

On 12/3/2018 10:43 AM, cyg Simple wrote:
> 
> On 12/2/2018 1:43 PM, Steven Penny wrote:
>> Using this file:
>>
>>     $ cat hello.sh
>>     awk -f /dev/fd/3 3<<eof
>>     BEGIN {
>>       print "hello world"
>>     }
>>     eof
>>
>> it runs as expected with Dash:
>>
>>     $ dash hello.sh
>>     hello world
>>
>> However it fails with Bash:
>>
>>     $ bash hello.sh
>>     awk: fatal: can't open source file `/dev/fd/3' for reading (No 
>> such file or
>>     directory)
>>
>> I tried also with Debian and both Dash and Bash work as expected. What is
>> causing Cygwin Bash to fail here?
> 
> Same for me and interestingly:
> 
> $ ls -ld /dev/fd/*
> ls: cannot access '/dev/fd/3': No such file or directory
> ls: cannot access '/dev/fd/31': No such file or directory
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/0 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/1 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/2 -> /dev/pty2

And:

$ dash -c '/bin/ls -l /dev/fd/'
total 0
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 0 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 1 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 2 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 3 -> /proc/27356/fd

$ dash -c '/bin/ls -l /dev/fd/'
total 0
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 0 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 1 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 2 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:51 3 -> /proc/18740/fd


So in Bash the process is no longer available.  Adding -d to the above:

$ dash -c '/bin/ls -ld /dev/fd/*'
/bin/ls: cannot access '/dev/fd/3': No such file or directory
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/0 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/1 -> /dev/pty2
lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/2 -> /dev/pty2


-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Eliot Moss]

On 12/3/2018 10:43 AM, cyg Simple wrote:

> Same for me and interestingly:
> 
> $ ls -ld /dev/fd/*
> ls: cannot access '/dev/fd/3': No such file or directory
> ls: cannot access '/dev/fd/31': No such file or directory
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/0 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/1 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:39 /dev/fd/2 -> /dev/pty2

Every process gets a standard input, output, and error file descriptor.
Other exist only if they're opened.  These are process-specific.

What's mysterious about the reported case is that the 3<< ... did not
seem to create a /dev/fd/3, at least not at the right "time" ...

Regards - Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Houder]

On Sun, 02 Dec 2018 10:43:17, Steven Penny  wrote:
> Using this file:
> 
>     $ cat hello.sh
>     awk -f /dev/fd/3 3<<eof
>     BEGIN {
>       print "hello world"
>     }
>     eof
> 
> it runs as expected with Dash:
> 
>     $ dash hello.sh
>     hello world
> 
> However it fails with Bash:
> 
>     $ bash hello.sh
>     awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or
>     directory)
> 
> I tried also with Debian and both Dash and Bash work as expected. What is
> causing Cygwin Bash to fail here?

File to which symlnk /dev/fd/3 refers has "gone"; different from Linux, where
the file is "deleted", but still "available".
(note: dash uses a different implementation)

I used fd 7 in testing. Below the output on Cygwin ... Observe the difference
when executed on Linux.

Henri

hello.sh:

#cat 7<<\EOF 0<&7 # works on both Linux and Cygwin
#cat 7<<\EOF 0<&7 /dev/fd/7 # fails on Cygwin
#ls 7<<\EOF 0<&7 -l /proc/self/fd /tmp /dev/fd/7
ls 7<<\EOF 0<&7 -lL /proc/self/fd /tmp /dev/fd/7
Hello world!
EOF
exit

# Using: ls 7<<\EOF 0<&7 -l /proc/self/fd /tmp /dev/fd/7

64-@@ bash hello.sh
lrwxrwxrwx  1 Henri None 0 Dec  4 12:37 /dev/fd/7 -> /tmp/sh-thd.3PSuc2

/proc/self/fd:
total 0
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 0 -> /tmp/sh-thd.3PSuc2
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 1 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 2 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 3 -> /proc/4972/fd
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 7 -> /tmp/sh-thd.3PSuc2

/tmp:
..

64-@@ dash hello.sh
lrwxrwxrwx  1 Henri None 0 Dec  4 12:37 /dev/fd/7 -> pipe:[4294969740]

/proc/self/fd:
total 0
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 0 -> pipe:[4294969740]
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 1 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 2 -> /dev/pty1
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 3 -> /proc/3740/fd
lrwxrwxrwx 1 Henri None 0 Dec  4 12:37 7 -> pipe:[4294969740]

/tmp:
..

# Using: ls 7<<\EOF 0<&7 -lL /proc/self/fd /tmp /dev/fd/7

64-@@ bash hello.sh
ls: cannot access '/dev/fd/7': No such file or directory
/proc/self/fd:
ls: cannot access '/proc/self/fd/0': No such file or directory
ls: cannot access '/proc/self/fd/7': No such file or directory
total 0
l????????? ? ?     ?         ?            ? 0
crw--w---- 1 Henri None 136, 1 Dec  4 12:39 1
crw--w---- 1 Henri None 136, 1 Dec  4 12:39 2
dr-xr-xr-x 2 Henri None      0 Dec  4 12:39 3
l????????? ? ?     ?         ?            ? 7

/tmp:
..

64-@@ dash hello.sh
prw-------  1 Henri None 0 Dec  4 12:40 /dev/fd/7

/proc/self/fd:
total 0
prw------- 1 Henri None      0 Dec  4 12:40 0
crw--w---- 1 Henri None 136, 1 Dec  4 12:40 1
crw--w---- 1 Henri None 136, 1 Dec  4 12:40 2
dr-xr-xr-x 2 Henri None      0 Dec  4 12:40 3
prw------- 1 Henri None      0 Dec  4 12:40 7

/tmp:
..

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[cyg Simple]

On 12/4/2018 7:13 AM, Houder wrote:
> On Sun, 02 Dec 2018 10:43:17, Steven Penny  wrote:
>> Using this file:
>>
>>      $ cat hello.sh
>>      awk -f /dev/fd/3 3<<eof
>>      BEGIN {
>>        print "hello world"
>>      }
>>      eof
>>
>> it runs as expected with Dash:
>>
>>      $ dash hello.sh
>>      hello world
>>
>> However it fails with Bash:
>>
>>      $ bash hello.sh
>>      awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or
>>      directory)
>>
>> I tried also with Debian and both Dash and Bash work as expected. What is
>> causing Cygwin Bash to fail here?
> 
> File to which symlnk /dev/fd/3 refers has "gone"; different from Linux, where
> the file is "deleted", but still "available".
> (note: dash uses a different implementation)

Dash is faster in processing the data but can be made to fail if you add 
-d to the ls commands you're using.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Houder]

On Tue, 4 Dec 2018 09:21:55, cyg Simple  wrote:

> Dash is faster in processing the data but can be made to fail if you
> add -d to the ls commands you're using. 

?

Oh, I believe you refer to:

    https://cygwin.com/ml/cygwin/2018-12/msg00035.html
    ( Re: Bash heredoc on FD 3 )

> So in Bash the process is no longer available.  Adding -d to the above:
> 
> $ dash -c '/bin/ls -ld /dev/fd/*'
> /bin/ls: cannot access '/dev/fd/3': No such file or directory
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/0 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/1 -> /dev/pty2
> lrwxrwxrwx 1 eboyd53 eboyd53 0 Dec  3 10:50 /dev/fd/2 -> /dev/pty2

uhm, the facts are slightly different ...

/dev/fd is, well, a "moving target", it is symlnk to /proc/self/fd.

self refers to the "current process" ... it changes each time.

/proc/self/fd shows the open fd's of the current process ...

Currently, I am on Linux (Fedora) ...

@@ # currently I am executing the shell (bash)
@@ # self points to the procid of my bash ...

@@ printf "%s\n" /dev/fd/*
/dev/fd/0
/dev/fd/1
/dev/fd/10
/dev/fd/11
/dev/fd/2
/dev/fd/255
/dev/fd/3

@@ # however ls has NO open fd 3 if I invoke it like this:
@@ # (self points to the procid of my ls command)

@@ ls -ld /dev/fd/* # /dev/fd/* expands to the list above (bash)
ls: cannot access '/dev/fd/255': No such file or directory
ls: cannot access '/dev/fd/3': No such file or directory
lrwx------ 1 henri henri 64 Dec  5 07:26 /dev/fd/0 -> /dev/pts/0
lrwx------ 1 henri henri 64 Dec  5 07:26 /dev/fd/1 -> /dev/pts/0
lrwx------ 1 henri henri 64 Dec  5 07:26 /dev/fd/10 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:26 /dev/fd/11 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:26 /dev/fd/2 -> /dev/pts/0

@@ # ls HAS an open fd 3 if I invoke it like this:
@@ (# use strace to see it happen -- ls opens the directory)

@@ ls -lL /dev/fd # /dev/fd refers to /proc/self/fd
total 0
crw-------  1 henri tty   136, 0 Dec  5 07:38 0
crw-------  1 henri tty   136, 0 Dec  5 07:38 1
crw-rw----+ 1 root  video 226, 0 Dec  5 07:01 10
crw-rw----+ 1 root  video 226, 0 Dec  5 07:01 11
crw-------  1 henri tty   136, 0 Dec  5 07:38 2
dr-x------  2 henri henri      0 Dec  5 07:38 3
@@ ls -l /proc/self/fd
total 0
lrwx------ 1 henri henri 64 Dec  5 07:38 0 -> /dev/pts/0
lrwx------ 1 henri henri 64 Dec  5 07:38 1 -> /dev/pts/0
lrwx------ 1 henri henri 64 Dec  5 07:38 10 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:38 11 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:38 2 -> /dev/pts/0
lr-x------ 1 henri henri 64 Dec  5 07:38 3 -> /proc/2605/fd

Same w/ dash:

@@ dash
$ printf "%s\n" /dev/fd/*
/dev/fd/0
/dev/fd/1
/dev/fd/10
/dev/fd/11
/dev/fd/12
/dev/fd/17
/dev/fd/18
/dev/fd/2
/dev/fd/3
/dev/fd/55
$ ls -ld /dev/fd/*
ls: cannot access '/dev/fd/12': No such file or directory
ls: cannot access '/dev/fd/3': No such file or directory
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/0 -> /dev/pts/3
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/1 -> /dev/pts/3
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/10 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/11 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/17 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/18 -> /dev/dri/card0
lrwx------ 1 henri henri 64 Dec  5 07:25 /dev/fd/2 -> /dev/pts/3
lr-x------ 1 henri henri 64 Dec  5 07:25 /dev/fd/55 -> /home/b/henri/.local/share/baloo/index

=====


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Corinna Vinschen]

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

On Dec  2 10:43, Steven Penny wrote:
> Using this file:
> 
>    $ cat hello.sh
>    awk -f /dev/fd/3 3<<eof
>    BEGIN {
>      print "hello world"
>    }
>    eof
> 
> it runs as expected with Dash:
> 
>    $ dash hello.sh
>    hello world
> 
> However it fails with Bash:
> 
>    $ bash hello.sh
>    awk: fatal: can't open source file `/dev/fd/3' for reading (No such file or
>    directory)
> 
> I tried also with Debian and both Dash and Bash work as expected. What is
> causing Cygwin Bash to fail here?

This should work in the latest developer snapshot uploaded to
https://cygwin.com/snapshots/  Please give it a try.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: Bash heredoc on FD 3

[Steven Penny]

On Sun, 6 Jan 2019 21:18:52, Corinna Vinschen wrote:
> This should work in the latest developer snapshot uploaded to
> https://cygwin.com/snapshots/  Please give it a try.

Hm interesting:

    $ uname -a
    CYGWIN_NT-6.1 Steven-PC 2.12.0s(0.330/5/3) 2019-01-06 19:42 x86_64 Cygwin

    $ dash hello.sh
    hello world

    $ bash hello.sh
    awk: error: can't open source file `/dev/fd/3' for reading (Permission
    denied)

    $ unset POSIXLY_CORRECT
    $ bash hello.sh
    hello world


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Corinna Vinschen]

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

On Jan  7 10:28, Steven Penny wrote:
> On Sun, 6 Jan 2019 21:18:52, Corinna Vinschen wrote:
> > This should work in the latest developer snapshot uploaded to
> > https://cygwin.com/snapshots/  Please give it a try.
> 
> Hm interesting:
> 
>    $ uname -a
>    CYGWIN_NT-6.1 Steven-PC 2.12.0s(0.330/5/3) 2019-01-06 19:42 x86_64 Cygwin
> 
>    $ dash hello.sh
>    hello world
> 
>    $ bash hello.sh
>    awk: error: can't open source file `/dev/fd/3' for reading (Permission
>    denied)
> 
>    $ unset POSIXLY_CORRECT
>    $ bash hello.sh
>    hello world

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.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: Bash heredoc on FD 3

[Steven Penny]

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.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Corinna Vinschen]

[-- 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 --]

Re: Bash heredoc on FD 3

[Corinna Vinschen]

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

On Jan  8 12:27, Corinna Vinschen wrote:
> 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
> > [...]
> 
> 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.

I added some changes to make this work in older systems as well.
I uploaded new snapshots to //cygwin.com/snapshots/

Please try.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: Bash heredoc on FD 3

[Steven Penny]

On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote:
> I added some changes to make this work in older systems as well.
> I uploaded new snapshots to //cygwin.com/snapshots/
>
> Please try.

Confirmed fixed.

Note I only retested with Windows 7 this time, but I think we’re good.

Thank you!


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bash heredoc on FD 3

[Corinna Vinschen]

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

On Jan  8 16:17, Steven Penny wrote:
> On Tue, 8 Jan 2019 22:05:34, Corinna Vinschen wrote:
> > I added some changes to make this work in older systems as well.
> > I uploaded new snapshots to //cygwin.com/snapshots/
> > 
> > Please try.
> 
> Confirmed fixed.
> 
> Note I only retested with Windows 7 this time, but I think we’re good.
> 
> Thank you!

Thank you for testing!


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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