Package: glibc Version: 2.7-5 Severity: important Since 2.7, glibc changed behavour of fflush() wrt pending write in the FILE* buffer. Before, the pending write data was cleared on fflush(), now it's keept in the buffer.
As a result, we see some.. interesting stuff, like this: $ echo foo > /dev/full bash: echo: write error: No space left on device $ echo bar foo bar $ _ Note the 2nd echo prints BOTH foo and bar. Here, echo(1) is built-in to bash, and bash just switches filedescriptor #1 behind the scenes of stdio when doing redirects. It correctly calls fflush() (which reports error on first echo) and clearerror(), but neither of them now clears the pending write, and the data remains in the buffer attached to stdout FILE* structure. The same behavour is reported for zsh, too, which seems to do similar behind-the-scenes trick when doing redirections. As far as I can see, this is a grey area in C standard - whenever the pending write should be cleared and when. More, I see no stdio function to force clearing the pding write - at least not a standard one. So the bug seems to be in bash (and in zsh) - (ab)users of fflush(), but I'm filing bugreport against glibc as the change lies here, and it's more generic. I see several possible portable, "white" way to do it all cleanly: o issue freopen() on each redirection (which is tricky too, because freopen() does not accept a file descriptor) o use separate FILE stream instead of stdout (requires many changes in bash and other places) o don't use stdio at all And finally, to revert glibc to do the same as was done before 2.7. What exactly to do is a.. good question. Oh well. /mjt -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23-i686smp Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages bash depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii bash 3.1dfsg-8 The GNU Bourne Again SHell -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]