Only the file browser and the ‘path_variables’ function (used for filters) made use of this method to set the working directory. Previously drop commands also used it, which is probably the only time we really need to set a working directory, as we provide the command with a relative file path.
Instead of passing the file descriptor to the child, and have the child close it, we set FD_CLOEXEC on the file descriptor in the parent process.
While it limits the window in which another thread can fork() and cause the file descriptor to be “leaked”, it doesn’t eliminate the problem.
You need to set this variable for launchd, so that it is inherited by TextMate. Unfortunately launchd only reads /etc/launchd.conf so unless you want to set this variable globally then you need to run something like the following before starting TextMate:
launchctl setenv LOG_PATH "$HOME/Library/Logs"
The user can manually disable session restore, which is undesired when relaunching due to a software update or installing a plug-in, so we now override the user’s choice for the new instance launched.
When we quit, objects with static storage are destroyed. Since the order is undefined, we basically cannot reference other objects in destructors, unless we own them or they are reference counted.
One case that seems to be an actual problem is the oak::process_t type — based on crash logs this often seems to be destroyed last, and it unregisters itself in its destructor, but using an object that it previously did not own (but obtained via a sort of factory function).
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.
