The blame for that behavior almost certainly lies with your ls implementation. Which ls are you using?

I can reproduce that behavior with GNU ls. I cannot reproduce it with busybox ls. A closer look using strace (I booted a Linux system just for this ) confirmed my suspicions: GNU ls isn't even trying to write a line at a time.

This is how GNU ls and Busybox ls attempt to write an error message for a nonexistent file named idont:

Code:

# GNU ls
write(2, "ls: ", 4)
write(2, "cannot access idont", 19)
# In Lem's example, interleaving occurred here
write(2, ": No such file or directory", 27)
write(2, "\n", 1)

# Busybox ls
write(2, "ls: idont: No such file or directory\n", 37)

There is no way to fix or workaround that, short of fixing GNU ls (or whatever code it depends on for generating its error messages). Perhaps other ls implementations (and other utilities for that matter) suffer from that problem, but there's nothing that can be done about this at the shell level.

With that many writes for a single, relatively short error message, there's a good chance that another process will be given the chance to write to the shared pipe. Each write is still atomic, it's just the message that's broken.

Regards,
Alister

---------- Post updated at 04:31 PM ---------- Previous update was at 04:26 PM ----------

You need to save stdout at the time that it's pointing to the cat-pipe because, later, when the shell builds the script|tee pipeline and redirect's script's stdout to the tee-pipe, if not for fd 3, there would be no way to refer to the cat-pipe (which script needs so that its stdout can bypass tee).

Regards,
Alister