[EMAIL PROTECTED] (Eric Blake) writes: > After further thought and discussion on the cygwin list, I'm convinced > that dd should default to binary mode (on non-ttys) on systems that > have a distinct text mode.
That sounds reasonable, but I'm beginning to worry that the code is becoming more ad-hoc and hard to maintain. This isn't just dd; it's cat, md5sum, split, etc. And I don't really understand how it works, or why some programs use binary modes and not others. For example, POSIX says that the input to "head" must be a text file, so why does GNU "head" set binary mode? Why does (say) "unexpand" use binary mode, but "uniq" uses text mode? Why does md5sum invoke setmode (..., O_TEXT) on a file that has just been fopened with "r" (doesn't that mean text?). None of this stuff really makes sense to me, and this makes the code hard to maintain. Is there some way that we can simplify this by using wrapper functions on DOS-like hosts? I'd rather get rid of the SETMODE and SET_BINARY macros entirely. If Cygwin open or fcntl doesn't do the obvious thing with O_TEXT and O_BINARY, let's define a wrapper function, used only on cygwin, that does the right thing. > But on cygwin, setmode can return -1 on failure with EBADF or EINVAL. Would it ever do that with the arguments we present to it? If not, I wouldn't worry about it. Your patch assumes that (O_BINARY != 0 && O_TEXT != 0); is this really true on all platforms? It seems to me that one could be zero. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
