Changes:
- Add WindowsPty, which uses the ConPTY API to create a pseudo console
- Pty now selects between PosixPty and WindowsPty
- Windows support in Command, including the ability to launch a process with a pseudo console
- Enable Command tests on windows
- Add some environment variable abstractions to handle the missing libc APIs on Windows
- Windows version of ReadThread
Instead of checking if a locale is valid, let's change this logic:
1. We first try setlocale to inherit from env vars, system default.
2. Next, we fall back to unsetting LANG if it was set manually,
allowing us to fall back to system defaults.
3. We fall back to en_US.UTF-8.
See #201 for more information.
Problem is that while we fall back to a default value to pass to
`setlocale`, we don't set a `LANG` and instead reset it to `""`.
What this does here is it changes the resetting to `""` and instead sets
it to the default value.
Fixes#201
I don't fully understand locales, but it appears that the locale
returned from NSLocale can be "valid" in general but invalid according
to libc's locale API. If you attempt to `setlocale` with this bad
locale, it defaults everything to "C", which ends up breaking a lot of
things.
This commit validates the locale, and if it is invalid, we default to
"en_US.UTF-8" so things tend to work. This behavior can be overridden
using standard environment variables (LANG, LC_ALL, etc.).
This also doesn't touch env vars so further subprocesses from the shell
see original locale env vars.
