The previous impl had facilities for controlling this - you could label handles as being connected (i.e., read() on one caused flushes on the other.) By default, stdin was connected to stdout and stderr. If that turned out to be troublesome, the connection could be broken (I could be mistaken, but I believe the implementation of hConnectTo didn't provide this; trivial to add.) My guess is that most of _your_ users wouldn't want to modify that default. As a data point, I cannot remember this ever being reported as a problem.

Yes, I'm aware of hConnectTo. It was a conscious decision not to re-implement it in the new IO library. There are really two separate issues: - Should we provide hConnectTo? I can only think of one reason why not: it adds a small but non-zero overhead to lots of I/O operations. - Should stdin and stdout/stderr be connected by default? Defaulting to connecting stdin and stdout is not always the right thing: consider the case when the input and output are connected to different pipes. This is a dynamic property, so the program itself would have to include code to check whether stdin and stdout are connected to the same terminal and disable the hConnectTo if not. Doing the right thing in general is hard - suppose the program opens /dev/stdin itself and starts to read from it, should this cause a flush of stdout? You're probably right that we get more bug reports the way it is just now, but it has the advantage of being simple and consistent. Cheers, Simon