proposal: os: add UserHomeDir

[kolyshkin]

This is a proposal to add Home() method to os/user package to get the user's home directory.

There is a bad trend to use the data returned by user.Current() in order to get user's home directory. It's bad to use Current() to get the value of home dir for two reasons:

1. $HOME should be used, if available, as user's home directory. Quoting http://man7.org/linux/man-pages/man3/getpwuid_r.3.html:

The pw_dir field contains the name of the initial working directory
of the user. Login programs use the value of this field to
initialize the HOME environment variable for the login shell. An
application that wants to determine its user's home directory should
inspect the value of HOME (rather than the value
getpwuid(getuid())->pw_dir) since this allows the user to modify
their notion of "the home directory" during a login session.

2. user.Current() is not implemented for some platforms (notably, Linux when building statically with glibc).

In a sense, currently os/user provides a not-quite-right way to get user's home directory, and lots of software is using this way. Why it's out of scope of this project to fix broken third-party software, perhaps providing the right way would do some good.

Unix/Linux/Darwin implementation of Home() can look as simple as:

func Home() string {
        if v := os.Getenv("HOME"); v != "" {
                return v
        }
        // fallback
        if u, err := Current(); err == nil {
                return u.HomeDir
        }
        return ""
}

Windows version can be like:

func Home() string {
        return os.Getenv("USERPROFILE")
}

Example

Here is an example (of bad usage of user.Current()) from this very repo:

go/src/crypto/x509/root_darwin.go

Lines 70 to 82 in d278f09

	u, err := user.Current()
	if err != nil {
	if debugExecDarwinRoots {
	println(fmt.Sprintf("crypto/x509: get current user: %v", err))
	}
	} else {
	args = append(args,
	filepath.Join(u.HomeDir, "/Library/Keychains/login.keychain"),
	// Fresh installs of Sierra use a slightly different path for the login keychain
	filepath.Join(u.HomeDir, "/Library/Keychains/login.keychain-db"),
	)
	}

[mvdan]

#22536 acts as a bit of a precedent. Also drawing from that proposal, I presume that the function should be called os.HomeDir.

[kolyshkin]

@mvdan thanks for the input. I tend to agree that it should be named os.HomeDir() (and maybe not include a call to Current() as $HOME is supposed to always be set).

[mvdan]

I've re-titled the issue to be a proposal, and to use the same package and naming scheme as the previous proposal for consistency. @kolyshkin feel free to change it if you disagree.

Another open question is whether or not the function should return an error. UserCacheDir initially didn't, but now it does. I think the reasoning is that without the error return, users may forget to check if the result is the empty string. If the function returns an error, it's obvious what the user should do to check if something went wrong.

[kolyshkin]

Yes, I believe it makes sense to return an error.

One other related thing is, it might make sense to add simple /etc/passwd parser to use as replacement for calling getpwuid_r (which is what user.Current() does), as it's not working for the linux static build case.

[bcmills]

(Wow, os has many owners!)

CC: @rsc @robpike @ianlancetaylor @bradfitz @griesemer

[ianlancetaylor]

This differs from os.UserCacheDir in that the os package can not import the os/user package. Either this has to be in the os/user package, or it has to simply return $HOME (on Unix).

What should it look like on Plan 9? @0intro

[0intro]

On Plan 9, I think it should look like Unix, except the environment variable is called home instead of HOME.

The Home function would look like:

func Home() string {
        if v := os.Getenv("home"); v != "" {
                return v
        }
        // fallback
        if u, err := Current(); err == nil {
                return u.HomeDir
        }
        return ""
}

[josharian]

This differs from os.UserCacheDir in that the os package can not import the os/user package.

FWIW, I still don’t understand why it is os.UserCacheDir instead of os/user.CacheDir.

[ianlancetaylor]

FWIW, I still don’t understand why it is os.UserCacheDir instead of os/user.CacheDir.

#22536 (comment)
and subsequent discussion.

[rsc]

os.UserHomeDir is OK to add, alongside os.UserCacheDir. The "User" in UserCacheDir was there to distinguish the user-local cache directory from any system-wide cache directories. There is less ambiguity for HomeDir but maybe UserHomeDir fits next to UserCacheDir better.

[gopherbot]

Change https://golang.org/cl/139418 mentions this issue: os: add UserHomeDir

[stapelberg]

Is it intentional that UserHomeDir no longer matches UserCacheDir in how errors are handled?

UserHomeDir unconditionally returns Getenv("HOME"), whereas commit 50bd1c4 changed UserCacheDir to return an error instead of an empty string when HOME is unset.

Shouldn’t they be consistent?

[ianlancetaylor]

@stapelberg Thanks, opened #28562 for this.