Dear OpenSSH developers, OpenSSH setting non-blocking mode on its standard files creates serious problems.
Setting non-blocking mode violates many of the semantics of how files are supposed to behave and most programs (and most, if not all, stdio libraries) are not prepared to deal with it. That wouldn't be a problem except that non-blocking mode is not a property of the file descriptor but a property of the underlying file table entry and thus affects *all* file descriptors that are bound to that file table entry, not just the one used to set non-blocking mode. Thus, you really shouldn't use non-blocking mode unless you're in complete control of the underlying file. Since the standard files (stdin, stdout, and stderr) are inherited from the parent process, that's never the case. Consider: $ cat bigfile | wc -c 10858893 $ (ssh localhost sleep 120& sleep 3; cat bigfile) | wc -c cat: stdout: Resource temporarily unavailable 270336 When ssh puts its stdout into non-blocking mode, it also puts cat's stdout into non-blocking mode. cat notices the problem, but doesn't actually handle it correctly (most likely because it's using stdio and thus *can't* handle it correctly), so the vast majority of the data just disappears into the bit bucket. I understand the necessity to keep ssh from blocking in order to keep port-forwarding working, but wouldn't it be possible to do that by just selecting for write before trying to write to stdout or stderr rather than setting non-blocking mode? -Larry Jones My brain is trying to kill me. -- Calvin _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs