Re: Bash heredoc on FD 3
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 signature.asc Description: PGP signature
Re: Bash heredoc on FD 3
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
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/" 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. 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 signature.asc Description: PGP signature
Re: Bash heredoc on FD 3
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/" 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 -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Bash heredoc on FD 3
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
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 signature.asc Description: PGP signature
Re: Bash heredoc on FD 3
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
On Dec 2 10:43, Steven Penny wrote: > Using this file: > >$ cat hello.sh >awk -f /dev/fd/3 3print "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 signature.asc Description: PGP signature
Re: Bash heredoc on FD 3
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
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< 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
On Sun, 02 Dec 2018 10:43:17, Steven Penny wrote: > Using this file: > > $ cat hello.sh > awk -f /dev/fd/3 3< 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
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
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< 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
On 12/2/2018 1:43 PM, Steven Penny wrote: Using this file: $ cat hello.sh awk -f /dev/fd/3 3< 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