On Dec 16 17:31, Houder wrote:
> L.S.,
> 
> /dev/fd/N not synonymous with file descriptor N; it is on Linux

Yes, it is.  Most of the time.  Try this:

$ echo foo | cat /dev/fd/0

The problem is that some of the concepts don't work as desired:

> 64-@@ cat /dev/fd/0 <<\EOF

If you observe what happens in tcsh in this situation you see that it
doesn't even execute cat as long as you didn't type EOF.  What you type
is written to a tmpfile:

$ ls -l /proc/5980/fd
total 0
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 0 -> /tmp/sh.lVQq04
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 15 -> /dev/pty0
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 16 -> /dev/pty0
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 17 -> /dev/pty0
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 18 -> /dev/pty0
lrwxrwxrwx 1 corinna vinschen 0 Dec 16 21:15 19 -> /dev/pty0

However, this tmpfile has been unlinked already, so it has been moved to the
recycle bin:

$ ls -l /tmp/sh.lVQq04
ls: /tmp/sh.lVQq04: No such file or directory

So the path in the fd subdir doesn't reflect the actual file path.

But after starting cat, cat tries to open /proc/self/fd/0 which
is in fact the non-existing path /tmp/sh.lVQq04.  Bad luck.

In contrast to Linux the symlinks are not just faked symlinks with the
underlying OS having direct access to the file descriptors.  The way
it's implemented in Cygwin uses the actual file path resolution and then
either works or fails as above.  I'm not sure how to fix that easily.
I guess the fd/0 symlink would have to show the actual file path pointing
to the recycle bin.  But that's often not what you want either since it
hows a patch outside the POSIX namespace.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer