I’m really confused. I’m seeing an issue right now, reproducible on multiple computers, where in the Nix build environment (either a normal build or a nix-shell
), after invoking /usr/bin/ibtool
(even just /usr/bin/ibtool --version
), invoking the Nix yes
fails after a few hundred lines with yes: standard output: Resource temporarily unavailable
. Anything else that emits a reasonable amount of output fails with a similar error (e.g. type genericBuild
usually fails). /usr/bin/yes
doesn’t fail but Nix tools do. If I create an interactive subshell (e.g. run bash
), the problem goes away, even after I exit the subshell, but short of that, non-trivial amounts of output produce write errors. Even pagers like man bash
produce truncated output.
I did recently upgrade my Xcode from Xcode 10.3 to Xcode 11 GM (which is where /usr/bin/ibtool
comes from), which explains why I’m seeing a behavior difference right now, but what I can’t figure out is what the heck is going on. I can’t reproduce this outside of the Nix environment. What could running /usr/bin/ibtool
possibly be doing to trigger this, why does it only happen in Nix, and why does spawning an interactive subshell fix it?
Is it possible that ibtool
marks stdout as nonblocking, and that this setting somehow affects the spawning shell? How would I properly test for this?
I was about to publish this and I discovered a new twist. Bash’s read
builtin fails instantly in this scenario as well:
> read
bash: read: read error: 0: Resource temporarily unavailable
Again, spawning an interactive subshell fixes it.