Install step 2 - primary option only relevant to Mac OS X, partially CentOS/REHL about nodenv

[jasonkarns]

Can you provide some more details on what your situation is?

Virtually all bash shells will read .bash_profile for login shells (if it exists, otherwise they'll read .profile). This is where env vars and things should live that are intended to apply to one's entire session.

.bashrc is read when invoked as an interactive, non-login shell. But since .bash_profile (or .profile) would have already been read during login, your env is already set up correctly.

More details on bash's startup sequence can be found in its man pages under Invocation: https://linux.die.net/man/1/bash

To verify again, we followed the instructions step by step on a pristine Debian (and Ubuntu) droplet on Digital Ocean. The instructions work as advertised.

What exact OS are you running on? Is this issue manifesting locally or on a cloud instance somewhere? How are you connecting to it?

[joshmorel]

Hi jasonkarns - Sorry, I realize now my initial issue was not articulated very well.

What I meant was that if followed to the letter this will cause other issues because .profile would no longer be read on Ubuntu/Debian (because .bash_profile now exists). I guess most users would know well enough to use .profile instead. Or, as I did, they would quickly correct the issue and keep going. I do agree now that editing .profile makes more sense than .bashrc because the env is set-up properly once on login so thanks for the thorough response.

Perhaps a better note for the step would be:

Note: If ~/.profile is in use, modify that instead of ~/.bash_profile.

I've confirmed this will work in Ubuntu Desktop as well (instead of .bashrc).

Edited to add. I now remember the nature of the original issue a little more. I did add to .profile but ran into a problem when following this instruction:

$ ~/.nodenv/bin/nodenv init
# Load nodenv automatically by appending
# the following to ~/.bashrc:

eval "$(nodenv init -)"

Adding eval "$(nodenv init -)" to .bashrc means that .profile sources .bashrc before updating the path. So I got this error:

 -bash: nodenv: command not found

This is fixable I think by adding this code for in nodenv-init (@ line 47) as this is the order bash will look for login startup files in.

  bash )
    if [ -f "${HOME}/.bash_profile" ]; then
        profile='~/.bash_profile'
    elif [ -f "${HOME}/.bash_login" ]; then
        profile='~/.bash_login'
    else
      profile='~/.profile'
    fi
    ;;

Let me know if you'd like me to try this and make another PR. It's up to you.

[jasonkarns]

I'm going to assume that one (or both) of the following are true:

1. during initial setup, you added the configuration to .profile (or .bash_profile) and then added the nodenv init step to bashrc. Then you started a new shell (new tab, or whatever). Thus bashrc was read (because new shell), but .profile wasn't because you're still in the original login session. This is a common, but one-time issue. Anytime you make changes to your .profile, it will need to be manually resourced for those changes to be reflected in your currently active session.

OR:

2. your .profile sources .bashrc at the beginning. Debian and derivatives source .bashrc from .profile. Indeed, my .bash_profile sources .profile and then sources .bashrc.

However, .bashrc files assume that .profile/.bash_profile has been sourced already. (By definition, the ``bashrcfile which is sourced for every instance of bash would naturally be run after the.profile` file which is only sourced once - at login.) In short: if your `.profile`/`.bash_profile` sources `.bashrc` (which is fine and even recommended); it should be at the very last thing it does.

I'm not going to say this is common knowledge, because all of this is quite archaic and confusing. And the sheer number of results on stack overflow, or google indicate just how misunderstood it all is, myself included. However, I don't think it's the responsibility of nodenv (just a single unix tool) to document *nix best practices or expected system defaults under which it should be configured. On the flip side, I wouldn't be against a page on the wiki that documents some of this in more detail. Which we could link to from the readme.

[joshmorel]

I guess that is fine - I understand that you don't want to clutter up the README with all those details. But as archaic as these Bash login scripts are at least Bash is consistent (as I now better understand it) - .bash_profile is read if it exists, if not then .bash_login, if not then .profile.

I guess I could explain my motivation in recommending the change. I decided to try all the node version manager and found this to be the best in terms of usability and speed. The only downside was the set-up and the fact that the readme could lead one astray if not using MacOSx or REHL/CentOS. In writing up a recommendation for use on Ubuntu Server, for example, I would need to recommend not following
a step in the readme. That's not a problem, but I thought, why not improve the README itself? Certainly the first PR was properly rejected for reasons explained but there remains issues - someone with a .profile file (default in Debian-based) deciding to follow the recommended step and echo to .bash_profile because they were not "Ubuntu Desktop" will then have some fixing to do. All very reversible I know but why not avoid a possible barrier for adoption?

If you don't want to clutter the README you could generically instruct the user to add the lines to their bash login file with a link to a wiki page with all the nuanced details.