Circular alias causes infinite loop

[Prinzhorn]

Caution: Reproducing this may cause your PC to not boot anymore, since nvm.sh is executed inside .bashrc.

I wanted to alias v0.10.5 with default but wasn't sure about the parameter order. So I did nvm alias v0.10.5 default. After I noticed that this was the wrong order, I did nvm alias default v0.10.5. To confirm it worked nvm ls. From this moment on nvm was slowly filling all of my 8GB of RAM, forcing Ubuntu to kill several other processes. I had to boot into a root shell and disable/remove nvm in order to boot normally again.

[ljharb]

Fixed with 7a339bd , 9b91734, and 2d529cc.

[emilbayes]

I just adccendentially did the same thing in nvm 0.31.0:

nvm install v5.10
nvm alias v5.10 default # oops
nvm alias default v5.10

It still seems to cause an infinte loop here. I get a the following when spawning a new terminal:

[forkpty: Resource temporarily unavailable]
[Could not create a new process and open a pseudo-tty.]

[ljharb]

@emilbayes when I try that, nvm alias prints out

default -> v5.10 (-> ∞)
v5.10 -> default (-> ∞)

and nvm use outputs The alias "node" leads to an infinite loop. Aborting. and exits 8. What does your nvm debug say, and what OS/platform are you on?

[emilbayes]

I can't run nvm debug before I remove the aliases. The terminal seems to be stuck in a at a tail command. I'm on OS X 10.11.3. I'll try to figure out how to remove the aliases manually, unless you get to me before that :)

[emilbayes]

So I ended up deleting both ~/.nvm and /usr/local/var/nvm (the latter being the nvm dir used). Here's the nvm debug output after nvm install v5.10:

nvm --version: v0.31.0
$SHELL: /bin/bash
$HOME: /Users/emil
$NVM_DIR: '/usr/local/var/nvm'
$PREFIX: ''
$NPM_CONFIG_PREFIX: ''
nvm current: v5.10.1
which node: $NVM_DIR/versions/node/v5.10.1/bin/node
which iojs: which: no iojs in ($NVM_DIR/versions/node/v5.10.1/bin:$HOME/perl5/bin:/usr/local/opt/php70/bin:/usr/local/var/rbenv/shims:$HOME/Development/tixz/dotfiles/bin:/usr/local/sbin:/usr/local/opt/gnu-tar/libexec/gnubin:/usr/local/opt/gnu-sed/libexec/gnubin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin)
which npm: $NVM_DIR/versions/node/v5.10.1/bin/npm
npm config get prefix: $NVM_DIR/versions/node/v5.10.1
npm root -g: $NVM_DIR/versions/node/v5.10.1/lib/node_modules

Here's the output now:

$ nvm alias v5.10 default
v5.10 -> default (-> v5.10.1)
$ nvm alias default v5.10
default -> v5.10 (-> ∞)

So it seems that this is a non-issue now, I might have had some old state lingering?

[ljharb]

@emilbayes i'm not sure why you'd have an nvm dir outside $HOME, since nvm is meant to be used per-user :-/ but it's very possible that the presence of both could have messed something up. Alternatively, you might have been sourcing two copies of nvm - the old one (that hangs on infinite loops) and then the new one on top of that, making --version output the new version? Just a guess.

[leftdevel]

If it helps anyone, this is how I fixed it: I created an infinite loop when creating an alias for version 10 as default, I didn't put the args in the right order:

$ nvm alias 10 default # Wrong. This tells nvm that 10 is an alias of "default"
$ nvm alias default 10 # correct, tells nvm that default is an alias of 10.

But the final result is that there was an infinite loop whenever I tried to switch to version 10:
$ nvm use 10

The way I fixed it was to delete ~/.nvm/alias/10, which is text file that contains "default".

Not sure if there's a better way, but it worked :P

[ljharb]

@leftdevel theoretically nvm alias or nvm ls would have helped you realize that, and then nvm unalias 10 would have fixed it.

[spoelstraethan]

Oddly enough I ran into this when using a workaround to fix the fact that using an lts name in the .nvmrc doesn't play well with nvm_version_path. The frustrating part was that while my change had fixed it for lts/whatever it broke it for using a specific version, and I still haven't fully figured out why.

Using this in an Azure DevOps pipeline in a Bash step.

        # Setup node using nvm
        # NODE_VERSION=12  # or whatever your preferred version is
        # We are using .nvmrc instead of specific version
        npm config delete prefix  # avoid a warning
        . ${NVM_DIR}/nvm.sh
        nvm install # uses .nvmrc
        nvm use
        # alias should understand lts/erbium better than nvm_version_path which can't resolve the lts/* aliases
        nvm alias default $(cat .nvmrc)
        VERSION_PATH="$(nvm_version_path $(cat $(nvm_alias_path)/$(cat $(nvm_alias_path)/default)))"
        echo "##vso[task.prependPath]$VERSION_PATH"
        npm install -g npm # upgrades to latest that supports lockfileVersion@2
        npm install

I ended up switching the VERSION_PATH invocation a bit, and maybe if I get some time I'll add a conditional that sets it differently depending on whether the .nvmrc is using an lts definition or a specific version.

        # alias should understand lts/erbium better than nvm_version_path which can't resolve the lts/* aliases
        nvm alias default $(cat .nvmrc)
        VERSION_PATH="$(nvm_version_path $(cat .nvmrc))"
        echo "##vso[task.prependPath]$VERSION_PATH"

[ljharb]

@spoelstraethan lts/argon etc should work perfectly fine in .nvmrc; there should be no need for any workarounds. If there is, please file that as a bug - but also, make sure you've tested on the latest version of nvm first.

[artemkiselev-sxope]

nvm unalias v5.10