On Sun, Aug 25, 2013 at 11:32 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Aug 24, 2013 at 10:23 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: >> >> We are really stuck with the current semantics here - switching to >> *BSD one would not only mean serious surgery on descriptor handling >> (it's one of the wartier areas in *BSD VFS, in large part because >> of magic-open-really-a-dup kludges they have to do), it would change >> a long-standing userland API that had been there for nearly 20 years >> _and_ one that tends to be used in corner cases of hell knows how many >> scripts. > > Actually, I'm pretty sure we did have the "dup" semantics at one point > (long ago), and they were really nice (because you could use them to > see where in the stream the fd was etc). It just fit so horribly badly > into the VFS semantics that it got changed into the current "new file > descriptor" one. Afaik, nothing broke. > We have fdinfo now, which is IMO much less scary. Programs can find the stream position, but they can't change it. OTOH... > So I'm not really sure about the "we're stuck with it" for semantic > reasons, and it turns out that very few programs/scripts actually use > /proc/<pid>/fd/<nr> at all (random use of /dev/stdin is likely the > most common case). But I agree about the "serious surgery on > descriptor handling" part. .../dev/stdin doesn't actually do what you expect if input comes from something seekable. $ cat /proc/self/fd/3 test $ cat /proc/self/fd/3 test $ cat /proc/self/fd/3 test $ cat <&3 est $ cat /proc/self/fd/3 test $ cat <&3 (I'm not going to advocate for changing this.) --Andy > > Linus -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
