> If the child could not change things about the open file in a way that > would affect the parent, then shell scripts would not be possible. For > instance, after a command that reads from a seekable stdin, the parent > (shell) would still be looking at the old file position, not the new > one.
True. Some state needs to be shared. But the blocking/non-blocking flag should not; the flag should be attached to every copy of the descriptor, not to the file. The current semantics brings nothing but trouble for programmers and users alike. > head has no reason to do so, and *cannot* do this. (It's not allowed to.) It was supposed to be an example. Replace "head" with your favourite utility. But anyway, I don't see what prevents "head" from doing this. There is nothing that forbids it in the specification. If I want to implement "head" asynchronously, with a select loop on stdin and stdout, why wouldn't I be allowed to ? The only reason why it _could_ be forbidden is, precisely, that the blocking/nonblocking state is shared, so if "head" was implemented via an asynchronous loop, it could mess up other programs using copies of its stdin and stdout. In other words, head cannot be asynchronous *because* the flag is shared. Doesn't it strike you as a problem ? > No, nonblocking mode has *no effect* on ordinary files. Even on NFS. Again, /nfs/file was an example. Replace it with /dev/random if you like. Or a FIFO. The problem remains. > No, the way to workaround the problem is not doing stupid things. Do you mean I'm not allowed at all to use programs that need asynchronous I/O in shell scripts, and that if I do, I'm being stupid ? Look at multitee: http://code.dogmap.org/fdtools/multitee/ Don't you agree that the *natural* way to write such a program would be an asynchronous loop? Yet, for the very same reason, the author jumped through hoops to avoid that. Doesn't that bother you ? It sure bothered him. > Irrelevant. gets is part of ISO C and POSIX/Unix defers to C. It did not have to. POSIX could have declared gets() insecure and not part of it, even though it belongs to ISO C. Somewhere, someone decided that it was acceptable to accept gets() into the standard. Enough said. > I hate it when fools who don't know what they're doing and don't > respect standards lobby for nonstandard behavior in Linux, thereby > making the portability landscape *worse* than it already it. And I hate it when technical discussions turn personal for no reason. If I do not know what I am doing, then it should be easy to refute the technical points above; please do so. I am genuinely interested in hearing good reasons why things are as they are; as for now, I have heard none. > Instead try to understand why things are the way they are Please explain, then. I (and I'm not alone) have given plenty of reasons why the nonblocking flag should not be shared. I am still waiting for one argument in favor of sharing it - apart from "it's the standard, it's like this, it's always been like this, you have to follow it or you're stupid". > and just stop insisting on doing stupid things (like setting > nonblocking mode on a fd you inherited). I'm insisting on the Unix flexibility. I'm insisting that multitee should be writable as an asynchronous program. I'm insisting that things should not break if for some reason some program sets a nonblocking flag somewhere; if a fcntl() call after every command in ash is what it takes to avoid random breakage, then it should be done. I'm insisting that you should stop having so much (blind) respect for what is Standard, and start thinking about what is Right instead. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
