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.