`env::home_dir()` should use `SHGetKnownFolderPath()` on windows.

[Diggsey]

At the moment, it first looks at %HOME%, and then at %USERPROFILE%. This is bad for two reasons:

1. The home directory will be different when run from an msys or cygwin terminal. Unless the program is specifically compiled to run in an msys/cygwin environment (they have their own target triples) then it should not be affected by %HOME% (only %USERPROFILE% stores the home directory on windows).

2. Environment variables may be overridden. SHGetKnownFolderPath() will always give the correct path to the user's home folder.

[FaultyRAM]

Adding to this, env::temp_dir() also parses environment variables where SHGetKnownFolderPath() would be more appropriate.

[barosl]

By looking at the code, it seems that home_dir already utilizes GetUserProfileDirectory, which is a bit more portable option than SHGetKnownFolderPath (albeit Rust basically targets Vista, so this won't be much a concern). The thing is, %HOME% and %USERPROFILE% are explicitly checked first before using the Windows API. I guess this is an intended behavior to enable the exact overriding behavior you described (so that you could get the "incorrect" path by setting %HOME% manually), but I'm not very sure. Could you confirm, @alexcrichton?

As for temp_dir, it is already using GetTempPath to return the appropriate path. The reason why the Rust documentation says it checks the environment variables is that it is exactly the behavior described in MSDN. It states: "The GetTempPath function checks for the existence of environment variables in the following order and uses the first path found". And also, SHGetKnownFolderPath seems to not support the temporary directory.

[nagisa]

Relevant PR which contains some related discussion.

[FaultyRAM]

@barosl Oops, you're right. In that case, I'd say this is bad documentation - not mentioning GetUserProfileDirectory() seems to be an oversight, and we should be describing the actual behaviour of env::get_temp() on Windows even if the effective behaviour is the same as what's described now, because that's not what I expected, and certainly not what others will expect. That and, of course, GetTempPath() could always change or be deprecated in the future, and then the docs would be wrong anyway.

[barosl]

@FaultyRAM I sent a PR that resolves the documentation issue, please review it: #28960.

[FaultyRAM]

@barosl Looks good!

[alexcrichton]

Believe it or not, this behavior has been here since literally the beginning (dafd649) of this module. The fallback to GetUserProfileDirectory was added relatively recently (70ed3a4) after it was suggested. I think it's safe to say that this was not highly scrutinized to the point of vetting the implementation as to what it should be.

I'll also note that this basically matches what python does as well as what ruby does. My personal opinion is that it's working as intended.

[Diggsey]

I'll also note that this basically matches what python does as well as what ruby does. My personal opinion is that it's working as intended.

And in every case it just makes the user experience worse on windows. The convention for getting the home directory on windows is (obviously) to use the helpfully provided OS functions to do so. That's what .net, java and other software does, that has a runtime which is actually written for windows, and is not just a barely functioning wrapper in order to provide a unix-like interface.

At best, the python and ruby interpreters can be slightly let off the hook as they are scripting languages, and so you might expect behaviour to be a little "fuzzy" with respect to the environment. At worst, they're shoving unix-like conventions onto a platform where they don't work or belong.

It's also one of the reasons why msys doesn't try to override the %USERPROFILE% environment variable: native windows software isn't supposed to change behaviour when run from msys: the only way msys functions properly is if native windows software is oblivious to it.

If you want a unix-like environment on windows, then target msys or cygwin - it's what they're there for after all... If you don't, then don't start looking for unix environment variables!

[retep998]

I am personally in favor of disregarding the environment variables entirely and just calling the OS function directly and leaving it at that.