Cannot source nvm.sh if readonly VERSION variable is defined

[ermshiperete]

Sourcing nvm.sh fails if a readonly environment variable VERSION (or some other readonly variables that nvm.sh uses) are defined. IMO nvm should use variables with a unique prefix even for local variables, in this case e.g. NVM_VERSION.

Operating system and version:

Ubuntu 24.04.2 LTS

nvm debug output:

nvm --version: v0.39.7
$SHELL: /bin/bash
$SHLVL: 1
whoami: 'user'
${HOME}: /home/user
${NVM_DIR}: '${HOME}/.nvm'
${PATH}: ${HOME}/perl5/bin:${HOME}/.deno/bin:${HOME}/gems/bin:${NVM_DIR}/versions/node/v20.16.0/bin:${HOME}/.cargo/bin:${HOME}/.local/share/umake/bin:/usr/lib/ccache:${HOME}/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin:${HOME}/.dotnet/tools:${HOME}/.local/bin:${HOME}/.local/share/JetBrains/Toolbox/scripts:${HOME}/.local/bin
$PREFIX: ''
${NPM_CONFIG_PREFIX}: ''
$NVM_NODEJS_ORG_MIRROR: ''
$NVM_IOJS_ORG_MIRROR: ''
shell version: 'GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)'
uname -a: 'Linux 6.11.0-25-generic #25~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 17:20:50 UTC 2 x86_64 x86_64 x86_64 GNU/Linux'
checksum binary: 'sha256sum'
OS version: Ubuntu 24.04.2 LTS  
awk: /usr/bin/awk, GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)
curl: /usr/bin/curl, curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/3.0.13 zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.2 (+libidn2/2.3.7) libssh/0.10.6/openssl/zlib nghttp2/1.59.0 librtmp/2.3 OpenLDAP/2.6.7
wget: /usr/bin/wget, GNU Wget 1.21.4 built on linux-gnu.
git: /usr/bin/git, git version 2.49.0
grep: /usr/bin/grep (grep --color=auto), grep (GNU grep) 3.11
sed: /usr/bin/sed, sed (GNU sed) 4.9
cut: /usr/bin/cut, cut (GNU coreutils) 9.4
basename: /usr/bin/basename, basename (GNU coreutils) 9.4
rm: /usr/bin/rm, rm (GNU coreutils) 9.4
mkdir: /usr/bin/mkdir, mkdir (GNU coreutils) 9.4
xargs: /usr/bin/xargs, xargs (GNU findutils) 4.9.0
nvm current: v20.16.0
which node: ${NVM_DIR}/versions/node/v20.16.0/bin/node
which iojs: 
which npm: ${NVM_DIR}/versions/node/v20.16.0/bin/npm
npm config get prefix: ${NVM_DIR}/versions/node/v20.16.0
npm root -g: ${NVM_DIR}/versions/node/v20.16.0/lib/node_modules

nvm ls output:

       v18.17.0
       v18.19.0
       v20.11.0
       v20.13.0
       v20.15.0
->     v20.16.0
        v23.6.0
       v23.11.0
         system
default -> v20.16.0
iojs -> N/A (default)
unstable -> N/A (default)
node -> stable (-> v23.11.0) (default)
stable -> 23.11 (-> v23.11.0) (default)
lts/* -> lts/jod (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.21.3 (-> N/A)
lts/gallium -> v16.20.2 (-> N/A)
lts/hydrogen -> v18.20.8 (-> N/A)
lts/iron -> v20.19.0 (-> N/A)
lts/jod -> v22.14.0 (-> N/A)

How did you install nvm?

Script in readme

What steps did you perform?

readonly VERSION=foo
. ~/.nvm/nvm.sh

What happened?

Sourcing nvm.sh failed:

$ readonly VERSION=foo
$ . ~/.nvm/nvm.sh
bash: local: VERSION: readonly variable
bash: local: VERSION: readonly variable
bash: VERSION: readonly variable
bash: local: VERSION: readonly variable
bash: local: VERSION: readonly variable
bash: local: VERSION: readonly variable
bash: VERSION: readonly variable
bash: VERSION: readonly variable
bash: VERSION: readonly variable
$ echo $?
1

What did you expect to happen?

Sourcing nvm.sh succeeds without error.

[ljharb]

readonly variables are exceedingly rare. Why do you have one set in your terminal?

[ermshiperete]

I agree, having a readonly variable in an interactive terminal is rare.

Things might be different when it comes to automation: We have a build script for our CI that has to source nvm.sh as part of the build but also sets the readonly VERSION variable.

IMO since NVM is implemented using shell functions it should not interfere (or at least as little as possible) with the normal use of the shell.

[ljharb]

That's true, and we can change it, but it won't solve the root problem - which I think is unsolvable.

[abrar109]

Can we change it

[ermshiperete]

See also #3257