This package turns out to be a dependency of https://github.com/ipfs/go-ipfs. I am in the process of packaging IPFS for Gentoo where we prefer to build our software from source when we install it. Thus I am also packaging this project and would kindly like to ask you to push a semantic version tag, which makes things a lot easier for me.

If HOME is not defined and getent(1) is not found, dirUnix() currently immediately returns an error without even trying the third method (sh -c 'cd && pwd'). It means HOME is the only source for obtaining the home directory on Darwin where getent(1) is missing.

One possible bug here is that the condition to detect if getent(1) is not found might be reversed, which I addressed in the first commit.

The second commit adds a fallback method specially for Darwin. It is to execute dscl(1) via the shell, so no dependency on cgo will be involved.

Path expansion currently disallows paths starting with ~. The ~ character is a valid part of a directory or file name. A leading ~ is most commonly found in university server paths where the users have a public web directory, e.g., https://cs.fit.edu/~mmahoney/.

Return the path as-is if the leading ~ is not referring to a directory name as in ~/ or ~.

I'd like to use this library as one of my users has run into the OSX issue mentioned in the README.

I currently build plan9 binaries - is it likely to work there?

Thanks

Nick

In a MR in containers/common someone mentioned this package after I already reimplemented this module. While looking into this, I found a bug in your code: homedir.Expand("~something")

This throws an "cannot expand user-specific home dir". Directory names starting with a "~" are valid, so this is a bug in my opinion.

I implemented the function (using os/user) as follows:

// resolveHomeDir converts a path referencing the home directory via "~"
// to an absolute path
func resolveHomeDir(path string) (string, error) {
	// check if the path references the home dir to avoid work
	// don't use strings.HasPrefix(path, "~") as this doesn't match "~" alone
	// use strings.HasPrefix(...) to not match "something/~/something"
	if !(path == "~" || strings.HasPrefix(path, "~/")) {
		// path does not reference home dir -> Nothing to do
		return path, nil
	}

	// only get HomeDir when necessary
	home, err := unshare.HomeDir()
	if err != nil {
		return "", err
	}

	// replace the first "~" (start of path) with the HomeDir to resolve "~"
	return strings.Replace(path, "~", home, 1), nil
}

By replacing unshare.HomeDir with your Dir function, this issue should be fixed.

This line within dirUnix() (L87) fails in macOS, as it assumes getent is installed, which is not the case for macOS, as this is a Unix/Linux-only utility.

cmd := exec.Command("getent", "passwd", strconv.Itoa(os.Getuid()))

This is the error that's returned

"getent": executable file not found in $PATH

Suggest detecting whether the user is on a Mac and use a Mac name resolving binary like dscacheutil or dns-sd.

What

Move OS based implementations behind build flags.

Why

The fork for choosing the OS based implementation for the home directory is a runtime fork. Go has build flags and can choose code at runtime and this is more efficient and results in the library containing less code.

Note

No changes were made to the windows or non-windows implementations. The functions were copied, renamed to dir() and then imports were updated to match the usage in each file.

If the home environment varible ended with slash ('/'), the the expanded string would have two slashes at some point. For detailed information, see the changed unit tests. homedir now uses filepath.Join to join the string correctly.

I originally opened this in a downstream terraform provider including go-homedir as a dependency. The main issue is that HOMEDRIVE/HOMEPATH are relics of NT4 and not standard environment variables post Windows Vista. They appear to exist sometimes in environments with a history of roaming profiles.

You may read the explanation in the original issue: https://github.com/terraform-providers/terraform-provider-azurerm/issues/1395

This document has a table of standard environment variables on Windows: https://msdn.microsoft.com/en-us/library/dd378457(v=vs.85).aspx

https://github.com/mitchellh/go-homedir/blob/3864e76763d94a6df2f9960b16a20a33da9f9a66/homedir.go#L138-L155

Environment variables are lowercase on Plan 9, unlike the traditional unix system where they're uppercase.

This fixes the check for the "HOME" environment variable under Plan 9.

What

Change tests to use path/filepath instead of fmt and hardcoded / path separators.

Why

Joining paths with / causes the tests to fail when run on windows because it's file path separator is \. Using path/filepath allows the code to join paths together using the system path separator without the code needing to know what the separator is.

https://github.com/mitchellh/go-homedir/blob/af06845cf3004701891bf4fdb884bfe4920b3727/homedir.go#L148-L167

TL;DR, change code to

func dirWindows() (string, error) {
	home := os.Getenv("LOCALAPPDATA")
 	if home == "" {
		return "", errors.New("LOCALAPPDATA environment variable is missing or empty")
	}
	return home, nil
}

$HOME is non-standard on Windows, and likely references $USERPROFILE. $USERPROFILE is not meant to be a location that applications store files other than via a save dialog box or similar situation where the user is explicitly putting files there. The proper location to store data that should be automatically synced to a network or uploaded to the cloud is $APPDATA. For data that should be machine-local (e.g., caches, application data, etc.) it should be stored in $LOCALAPPDATA.

In this library, it doesn't appear that you distinguish between data types so $LOCALAPPDATA is the best location. If someone throws a cache in there you don't break the user's profile.

Note: $LOCALAPPDATA has been around since Windows XP/2003 while the fallback you were using of $HOMEDRIVE I think has been deprecated and $HOMEPATH is fairly new (and I think also deprecated), so this is not only more correct, but also more backward compatible than the code currently present.

Go 1.9 ships with os/user.LookupId, os/user.Lookup, os/user.LookupGroup, os/user.LookupGroupId that work without cgo. If you compile without cgo enabled, those functions will read /etc/passwd and /etc/group respectively to find answers to the questions you ask. Which may be good enough for your use case.

(I wrote the functions in question, and I'm curious how well they work for folks. I would appreciate feedback on how well they work or don't. If they don't work, I'd love to help fix them. Thanks!)

I don't have getent on my system, so the dirUnix function failed to execute it. It checks (https://github.com/mitchellh/go-homedir/blob/master/homedir.go#L87) if the exec.ErrNotFound error is returned, but this error is wrapped by exec.Error() so the returned error will never be exec.ErrNotFound.

The actual returned error message is: exec: "getent": executable file not found in $PATH, whereas it expected the following: executable file not found in $PATH.

A fix would be if strings.HasSufix(err.Error(), err.ErrNotFound.Error()) {.