You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 22, 2023. It is now read-only.
Feature Request: Make path.normalize() expand "~/" #2857
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.)
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.
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.
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.
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 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.
@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
Activity
jonlong commentedon Mar 2, 2012
YES, +1 for this!
isaacs commentedon Mar 2, 2012
This can't be done in path.normalize.
pathis 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 commentedon Mar 2, 2012
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.
~ expansion in path.normalize not ~username nodejs#2857
stevesims commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
~ is a valid path character.
rogeriopvl commentedon May 11, 2012
+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 commentedon May 11, 2012
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/baretc.) belongs in a library like node-glob, not in the path module, which is strictly for string munging, and cannot perform IO.breck7 commentedon Mar 3, 2013
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 commentedon Jun 9, 2013
@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.sindresorhus commentedon Jun 24, 2013
👍 I too was expecting this to work. Would be a useful addition.
In the meantime I did a module for this: untildify
blockloop commentedon Aug 9, 2013
+1 for this
jacobsvante commentedon Feb 24, 2014
How can this not be in the stdlib?
kroggen commentedon May 19, 2014
+1 for this
here is an enhanced version of @breck7 function that works on Windows too:
yanickrochon commentedon May 21, 2014
@kroggen I would remove OS checks altogether and simply check for
envvariables. Sinceprocess.env.HOMEis probably the most used key, I'd have your snippet slightly changed intoAlso, your snippet might convert paths like
"~foo/bar"into"/home/foofoo/bar".jcblw commentedon Sep 7, 2014
👍 I was confused when this didnt work with
normalize.For now @sindresorhus's module works great. Thanks
reggi commentedon Nov 26, 2014
+1 Would love to see this in
path!Thanks for the module @sindresorhus! 🌈 ☔ 🐬
jasnell commentedon May 18, 2015
@joyent/node-coreteam ... io.js decided not to pursue this. There are userland modules supporting this function. Closing.