Bruno Haible wrote: > Actually, the only places where bash-4.0 calls fpurge is directly after fflush > on the same stream, and only on output streams: > > fflush (stdout); > fpurge (stdout); > > Does someone understand the purpose of this code? IMO fpurge is a nop, > right after fflush (assuming that fflush succeeded).
That's a dangerous assumption. You can't always assume that fflush will succeed. And when it fails, newer versions of glibc leave data in the stdio buffer. Now, the assumption is that when fflush fails, it fails due to some problem with the underlying file descriptor, and, further, that that file descriptor will never change or repair itself. Under those conditions, it's ok for stdio/fflush to leave the data. However, bash will change the file descriptor underlying a stdio buffer when it performs redirection. In that case, subsequent writes will succeed, and those writes will include the data left by the previous failed fflush. When bash changes file descriptors, it needs to make sure that the stdio buffers are empty. I chose to use fflush for this purpose (reluctantly), even though it's less than completely portable. There aren't any good portable solutions for the issue. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
