On Sun, Sep 09, 2007 at 10:18:07PM +0100, Stephane Chazelas wrote:
> Now, I'm not sure if we can say that the new glibc behavior
> observed is bogus (other than it's different from the behavior
> observed in all the libcs I tried with).
What libc have you tried?
To me, the new behavior makes much more sense, as dropping buffer on
error is really weird thing to do. I have looked at the source code of
newlib and dietlibc, none of them drops buffer on error, and I am not
aware about any other implementation of libc that does.
> It is not a harmless
> change, for sure as it seems to have broken at least bash, zsh
> and possibly ksh93.
Unfortunately, you are right. I did not foresee that some shells may use
"dup2(open("file.txt"), fileno(stdout))". It is a dirty hack, which may
cause some other problems. Frankly, I am a bit surprised that bash uses
printf instead of write(2). BTW, you cannot use 'printf' in signal
handlers, so it seems that you cannot use 'echo' in trap commands too.
Perhaps, we should rollback my patch and give some time for developers
to fix their broken shells, but, in this case, what is actually broken
are those shells, not libc!
Regards,
Dmitry
