N: Can't select different node versions with node 6.x on Ubuntu

[valgaze]

@qw3rtman
To add another data point to the pile, using a Bitnami AMI (basically a batteries-included Linux image for quick deployments) on Amazon Web Services with node 6.2.1 as default exhibits behavior similar to the kind described in Issue #355 The solution proposed by @ElegantSudo did not resolve the issue.

Bare minimum number of steps to reproduce here: https://gist.github.com/valgaze/728a9758d6abd73702ef27f7986f4b59

• Image: http://aws.amazon.com/marketplace/pp/B00NO1HJ56?ref=cns_srchrow [Linux/Unix, Ubuntu 14.04.3 | 64-bit Amazon Machine Image (AMI) | Updated: 7/7/16]
• OS: Ubuntu 14.04.3
• Running $ uname -or: 3.13.0-87-generic GNU/Linux
• Starting node version (preinstalled on image): 6.2.1

Here's a gif the wacky behavior described:

Will post a gist of replication instructions in a moment: https://gist.github.com/valgaze/728a9758d6abd73702ef27f7986f4b59

[valgaze]

This only seems to occur on 6.2.1, for some reason seems OK on 6.3.1

[hk0i]

Seeing similar behavior on node v7.10.0,

Pressing the up key reveals the grep usage message as shown in the image above:

Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.

    node/0.10.31
    node/8.2.1

Edit: I'm using Linux Mint 17.1 Rebecca, also Ubuntu Based

[kmsheng]

This also occur on node v8.4.0

[garuda]

Nothing on this huh? I'm seeing the same :( Uninstalled, reinstalled, nadda

[adrianlyjak]

same thing on macos 10.11.6, n version 2.1.7. Using up and down arrows to select version just outputs grep help documentation:

usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
    [-e pattern] [-f file] [--binary-files=value] [--color=when]
    [--context[=num]] [--directories=action] [--label] [--line-buffered]
    [--null] [pattern] [file ...]
    node/5.0.0
    node/5.7.0
    node/6.11.0
    node/8.0.0
    node/8.1.2
    node/8.9.4
    node/9.2.1
    node/9.3.0
    node/9.4.0

[apretto]

I've had this same problem, and figured out that it's an installation issue.

You should be able to fix this problem by making sure that $N_PREFIX/bin is present in your PATH, and is listed before any system wide Node installation.

Maybe you also need to have $N_PREFIX/lib, $N_PREFIX/include, and $N_PREFIX/share on your path as well. I got n to work without adding them, but I'm not 100% sure I won't run into any problems in the future.

[hezedu]

same problem on Ubuntu 16.04, node v8.9.3, n 2.1.12

[takamakiValtteri]

Same here on Mac Mojave.

[shadowspawn]

The problem with the menu selection is that the active version of node is not in the list of versions cached by n and triggers a bug selecting from the menu. This can happen when you have more than one version of node installed, and the version being installed by n is later in PATH.

Run which -a node to see the versions of node you have installed.

You could delete the other version of node, or reorder the directories in PATH (as described by @apretto above).

[spences10]

I was having this issue, I installed with [n-install] which has an [issue, with a solution] that I used for use in Fish but I was having the same issue with bash, so I changed the n-install line in my .bashrc file:

export N_PREFIX="$HOME/n";
 [[ :$PATH: == *":$N_PREFIX/bin:"* ]] || PATH="$N_PREFIX/bin:$PATH"  # Added by n-install (see http://git.io/n-install-repo).

[tstackhouse]

I'm seeing this issue with 8.11.4. I get the above output, complaining about grep, and yet 8.11.4 is listed as an installed version.

Running which -a node as suggested gives me an odd result:

8883$ which -a node
<home>/.n/bin/node
<home>/.n/bin/node

[shadowspawn]

@tstackhouse
The double listing is probably due to <home>/.n/bin appearing in your PATH twice. Have a look in your shell startup file, I suspect you have the path addition twice.

(I don't know why that would trigger the grep error though, but try fixing PATH first.)

$ export PATH=~/.n/bin:$PATH
$ export PATH=~/.n/bin:$PATH
$ echo $PATH
/Users/john/.n/bin:/Users/john/.n/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
$ which -a node
/Users/john/.n/bin/node
/Users/john/.n/bin/node

[tstackhouse]

@JohnRGee I figured that out. My path needs some housekeeping desperately. I apparently had both .n _and_ n paths in my home directory. I ended up blowing them both away and reinstalling and everything is hunky dory.

[spences10]

I've had this problem and found a solution with Fish shell but it still happened when using bash, also, my team leader picked through the issue and found that it was the way in which n-install orders the prefix:

# Added by n-install (see http://git.io/n-install-repo).
export N_PREFIX="$HOME/n";
[[ :$PATH: == *":$N_PREFIX/bin:"* ]] || PATH="$N_PREFIX/bin:$PATH"

So this will only work if you used n-install to install n??

[shadowspawn]

@spences10 Those lines work for anyone who wants to install node to "$HOME/n", it does not matter whether you used n-install to install n.

The fix @spences10 has made is to put $N_PREFIX/bin at the start of PATH rather than adding on the end, which is what n-install does by default. When there is more than one version of node installed we want our own version of node to be found first.

The complex looking conditional code comes from n-install and is to avoid modifying the PATH if run again or already set by some other code.

[shadowspawn]

Of interest, I found a good comment about security implications of putting local bin first in path, so an interesting tradeoff to be aware of.

https://stackoverflow.com/a/25151631/1082434

[spences10]

Of interest, I found a good comment about security implications of putting local bin first in path, so an interesting tradeoff to be aware of.

https://stackoverflow.com/a/25151631/1082434

Thanks for this @JohnRGee, steps for me then.

1. looks like I should un-hack what I did and check with which -a node what versions I have installed
2. ... follow @apretto's advice?

[shadowspawn]

Your "hack" is fine @spences10 and is the same as apretto advises, putting $N_PREFIX/bin ahead of system folders in PATH. (As long as you are ok with npm globally installed commands being found before system commands. Global installs are less common these days so less of an issue.)

The order in PATH only makes a difference when there are multiple installs, which is where which -a node comes in to check what you currently have, and whether it is reasonable to delete the system install.

[shadowspawn]

Fixed the erroneous error message when making menu selection in n v3.0.0