Fix #166 On Unix-like OS, use unsafePerformIO (lookupEnv "TERM")

[mpilgrem]

Relying on CI to test.

[Bodigrim]

There is also hSupportsANSIColor, which also reads environment variables.

[Bodigrim]

(As I said in #150 (comment), I think we should just define hSupportsANSIColor = hSupportsANSI - and maybe this PR is a good opportunity to do so)

[mpilgrem]

@Bodigrim, on hSupportsANSIColor, I did look at the source code for System.Environment.getEnvironment and I could not see that it used C function getenv(). It has:

foreign import ccall unsafe "__hscore_environ"
  getEnvBlock :: IO (Ptr CString)

Is that also problematic?

[Bodigrim]

Is that also problematic?

I think so. The C definition is

#if !HAVE_DECL_ENVIRON
extern char** environ;
#endif
INLINE char **__hscore_environ(void) { return environ; }

Now if one thread got Ptr CString and another thread executed setenv, extending the environment and causing reallocation of char** environ elsewhere, the original pointer can be freed, causing the first thread to segfault.

Quoting Setenv is not Thread Safe:

As a final problem, environ is a NULL-terminated array of pointers (char**) that an application can read and assign to (see definition in POSIX.1-2017). This is how applications can iterate over all environment variables. Accesses to this array are not thread-safe.

[mpilgrem]

@Bodigrim, now with the same approach to hSupportsANSIColor.

[Bodigrim]

Thanks!