On Dec 16 21:28, Corinna Vinschen wrote:
> 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.
  shows a path

Sorry,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer