On Jan 22 10:25, Houder wrote: > On 2019-01-22 10:06, Corinna Vinschen wrote: > > On Jan 22 09:57, Houder wrote: > > > On 2019-01-22 09:50, Houder wrote: > > > > On Sun, 6 Jan 2019 21:19:50, Corinna Vinschen wrote: > > > > > This should work in the latest developer snapshot uploaded to > > > > > https://cygwin.com/snapshots/ Please give it a try. > > > > So, for the record only: > > > > > > and as another example, this STC succeeds on Linux ..., but fails on > > > Cygwin. > > > > > > 64-@@ ./stca /dev/fd/0 < > > > bla > > > > EOF > > > fd1 = 0 > > > argv[1] = /dev/fd/0 > > > fd2 = 3 > > > id = writefd2, errno = 13, errstr = Permission denied > > > 64-@@ > > > > Not sure what you're testing. This is the result for me on both, > > Windows 8.1 and Windows 10 1809: > > Curious! It fails (for me) on W7 ... It works for me just as well on W7: $ uname -a CYGWIN_NT-6.1 vmbert764 2.12.0(0.333/5/3) 2019-01-21 22:47 x86_64 Cygwin $ ./stca /dev/fd/0 < > Not sure what you're testing. > > STC inherits a "read-only" open file descriptor from bash. On Linux > the file can be opened read-write (via procfs), because a new entry > is created in the open file table. > > (opening the file read-write (via fdescfs) on FreeBSD would fail) > > For this reason the output does not show what has been entered via > the here-doc. > > In short, I was merely testing the semantics of Linux. Ah, ok. This is a bit of a problem on Windows. The code tries to reopen the file by handle. Under some circumstances(*) we can't reopen the file. In that case the code just tries to duplicate the handle. However, a duplicated file handle can't have more permissions than the original handle. So if it fails for you, it seems the reopen failed and the handle only got duplicated. In that case, you can't gain write perms if the original handle only got read perms. What the code fails to do is trying to open the file by name as a last resort. There was a (good?) reason I didn't implement that, but I don't remember ATM. Corinna (*) E.g., deleted files on systems older than Windows 10 1709, or files on filesystems not supporting the "reopen-by-handle" semantics. However, the latter case should work at least for non-deleted files -- Corinna Vinschen Cygwin Maintainer