Feature Request: Make path.normalize() expand "~/"

[cvee]

It would be extremely useful to have path.normalize expand HOME directory references containing the tilde.

[jonlong]

YES, +1 for this!

[isaacs]

This can't be done in path.normalize. path is only a string manipulation library.

It would be good to have a cross-platform /etc/passwd type library to look up user info, though. (Just reading /etc/passwd is not actually sufficient, since even systems with this file don't necessarily put all the relevant data into it, and Windows obviously doesn't use that same file.)

[cvee]

I was under the impression path.normalize worked similarly to [NSString stringByStandardizingPath] in Foundation.

If this isn't the case I'd love to see a new path function that provides similar functionality.

[stevesims]

Oh so very this.

I fully expected path.normalize to understand , and was shocked to find that it didn't. Seeing a supposedly resolved path that includes a "" in the middle of it is bizarre at best.

IMHO as a bare minimum if node.js's path module is to not understand ~ then it should throw an error if it encounters it.

[bnoordhuis]

IMHO as a bare minimum if node.js's path module is to not understand ~ then it should throw an error if it encounters it.

~ is a valid path character.

[ghost]

While it does rely on a runtime check to accomplish, it iis very limited in scope and predictable and I think it really does fit here. Specifically, this ONLY applies (on the os's where it's implemented) when a string begins with ~. The result is specific and (I think) functions in a uniform way that is directly translatable to windows. That is to substitute in whatever the os's env variable for the user's home directory of the user associated with the requesting process.

[rogeriopvl]

+1 for this.

This could be done in normalize or create a new function expandPath or something similar. This feature is useful for node CLI apps with config files editable by users, IMHO.

[isaacs]

If we're going to provide access to home directories, we're going to do it properly with a cross-platform passwd binding. IMO, that should go into libuv, since it relies on performing IO and doing platform-specific fiddly bits.

@piscisaureus: your thoughts?

We are not going to add this to path.resolve or path.normalize in a way that is only half-way, and sends the message that users can expect it to work.

If you want to just replace it with process.env.HOME, you can do so quite easily. However, full-on support for ~ path semantics (along with ~user/foo/bar etc.) belongs in a library like node-glob, not in the path module, which is strictly for string munging, and cannot perform IO.

[breck7]

It seems @isaacs understands the side effects of doing this the short way and wants to do it the right way which makes sense.

For those like me that just need a quick fix:

function resolvePath (string) {
if (string.substr(0,1) === '~')
string = process.env.HOME + string.substr(1)
return path.resolve(string)
}

[rex]

@breck7 Thank you so very much for providing that snippet, I already have it implemented and it works like a charm, exactly as one would expect. I am lazy enough of a programmer to love not having to think of simple fixes, but not so lazy as to forgo expressing appreciation to the author of said fixes :)

@isaacs I came into this thread fully prepared to be frustrated about path() not handling tilde ~ in path names. After reading your reasoning, I am reminded once again that I am so very much in my infancy as a programmer and that I still have a lot to learn where it concerns the bigger picture.

After putting some thought into it, expanding the ~ in the path would do a few things that I can see:

Good: Allow programmers to not have to write the resolvePath() method that @breck7 so generously posted.

BAD: Give better programmers (myself very much not included) the false confidence that they can perform far more complex operations on the home directory and other disparate parts of the operating environment, thus potentially causing severe issues and other badness.

Every time I get mad at npm or Node, it always seems to end up being my immaturity as a developer causing me to make simple mistakes (sometimes not so simple). Which is good for me, because it's made me a shitload better.

This is one of those times.

Edit: Reposting @breck7's resolvePath() method within a code block for formatting purposes.

// @breck7   https://github.com/breck7
function resolvePath (string) {
  if (string.substr(0,1) === '~')
    string = process.env.HOME + string.substr(1)
  return path.resolve(string)
}

[sindresorhus]

👍 I too was expecting this to work. Would be a useful addition.

In the meantime I did a module for this: untildify

[blockloop]

+1 for this

[jacobsvante]

How can this not be in the stdlib?

[kroggen]

+1 for this

here is an enhanced version of @breck7 function that works on Windows too:

function resolvePath (string) {
  if (string.substr(0,1) === '~') {
    homedir = (process.platform.substr(0, 3) === 'win') ? process.env.HOMEPATH : process.env.HOME;
    string = homedir + string.substr(1)
  }
  return path.resolve(string)
}

[yanickrochon]

@kroggen I would remove OS checks altogether and simply check for env variables. Since process.env.HOME is probably the most used key, I'd have your snippet slightly changed into

function resolvePath(str) {
  if (str.substr(0, 2) === '~/') {
    str = (process.env.HOME || process.env.HOMEPATH || process.env.HOMEDIR || process.cwd()) + str.substr(1);
  }
  return path.resolve(str);
}

Also, your snippet might convert paths like "~foo/bar" into "/home/foofoo/bar".

[jcblw]

👍 I was confused when this didnt work with normalize.

For now @sindresorhus's module works great. Thanks

[reggi]

+1 Would love to see this in path!
Thanks for the module @sindresorhus! 🌈 ☔ 🐬

[jasnell]

@joyent/node-coreteam ... io.js decided not to pursue this. There are userland modules supporting this function. Closing.