-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pull in sindresorhus/user-home
as os.homedir()
#682
Comments
Anybody else feel like #596 is getting out of hand or am I the only one? |
@vkurchatkin I'm not sure whether we should include the functionality or not, but I'm gonna throw in my own module (https://github.com/cjihrig/userinfo) for consideration. It works at the C level and doesn't rely on environment variables. @rvagg yes. Seems like something that could live outside of core. |
@rvagg I agree with you, but there's a reason why. @cjihrig I'm not sure how this could live outside of core. |
@cjihrig repl history definitely can't live outside of core |
I haven't dug deeply into this, but just based on a little Googling, it does seem possible: |
We also have this: https://github.com/iojs/io.js/blob/v1.x/lib/module.js#L495 |
Would love to see this in core (along with If the C functions in @cjihrig's module work universally, I'd say that would be the best approach. |
As I mentioned before, there are existing packages that will give you fancy repl functionality outside if core, including history but also lots of other features. replpad by @thlorenz is just one example. My contention here is that the amount of additional code burden to get this feature in to core may suggest that it probably doesn't belong here. Core should remain lean and the node philosophy has evolved strongly into "small-core, vibrant-userland" so we need to always keep that in mind when assessing what pet-feature someone wants to bundle into core. |
Actually history is that one feature I didn't get to yet, but am very open to have this added. |
On the topic of user home detection in core I'm a strong -1 at this stage. It's not a clean operation and exposing it to users as if it were is fraught with danger. Consider how the suggested user-home module works for instance. If $HOME is not set on a non-Windows, non-Mac platform (i.e. the most common platforms for Node deployment: Linux and other unixes) then it assumes /home/user, which is absolutely not safe even if the common case. There is a strong case that if you cannot safely detect user home then you should fail and report. For example, an application started from Upstart or systemd where $HOME is optional, NY preference would be to fail if we really need to access user home and haven't been told where it is. A transparent operation from core conveys the impression that it's safe and can be trusted, best to encourage manual detection or using a userland module which comes with all the standard caveats that userland modules come with. |
I'm also -1 on any type of detection involving environment variables. |
@cjihrig do you know if |
I'm not comfortable saying all. I've tested on OS X and Ubuntu. |
tmpdir()
/cc @a8m @sindresorhus
The text was updated successfully, but these errors were encountered: