This is a fairly subtle bug: We were implicitly creating a temporary std::string object and requesting c_str from this object.
This C string’s lifetime was that of the temporary std::string, and as we did a lot of std::string creation in the following line, with the new libc++, there was a good chance that the temporary string buffer would be re-used and so, our working directory would be set to a bogus value.
This closes issue #329.
I was initially under the impression that no data should be sent past EOF but from testing it is clear that this assumption is incorrect. It’s unimportant though as we do handle the case (though we didn’t initially, and that’s why I put in the fprintf, to verify the situation I guarded for actually was happening).
Previously this was under the OakSystem framework which depends on the io framework meaning that the io framework itself was unable to obtain a basic environment, which is necessary for next commit.
