sed error on Ubuntu 14.04 server

[kematzy]

I'm unable to use nvm on Ubuntu server 14.04 VPS as I'm getting this error in the console when login or source ~/.bash_profile.

sed: -e expression #1, char 18: invalid reference \1 on s' command's RHS`

Something is wrong in the ~/.nvm/nvm.sh file relating to the sed commands, but which one is sadly beyond my skills.

Any chance of assisting in this matter?

[ljharb]

Which version of nvm are you using?

[kematzy]

Hi, I'm using the latest version I guess, I just deleted and reinstalled today a few hours ago.

curl https://raw.githubusercontent.com/creationix/nvm/v0.13.0/install.sh | bash

After some commenting out and trials I found this version "works" (no warranty).

nvm_format_version() {
  // echo "$1" | sed -e 's/^\([0-9]\)/v\1/g'
  echo "$1" | sed -e 's/^\([0-9]\)/v\\1/g'
}

Note the escaped \\1 reference. (added one extra \ in front of \1)

Hope that helps and is not messing other things up.

[ljharb]

By doing that, it turns the backreference \1 into a literal \ plus a literal 1, so that doesn't help.

To get this error, are you typing any nvm commands? Or is this just when sourcing?

If when sourcing, could you paste the relevant lines in your .bash_profile?

[kematzy]

Just when I'm sourcing. I can't even get the nvm command to work with the default line (shown in snippet above), but it works now (after my hack).

My .bash_profile ends with:

export NVM_DIR="/home/kematzy/.nvm"
# source $NVM_DIR/nvm.sh
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm

I also tried the commented out line: ie: source $NVM_DIR/nvm.sh but it's the same result.

What is the nvm_format_version() function actually supposed to do?

AFAIU, it's used in handling the output from the nvm ls command.

So when I test this on my local OS X machine and on my hacked VPS I get two different results even though I've got almost the same Node versions installed.

On non-hacked OS X install:

$ nvm ls

  v0.10.24
  v0.10.28
  v0.10.29
  v0.10.30
   v0.11.7
   v0.11.9
current:    v0.10.29
default -> v0.10.29

$ nvm ls v0.1
       N/A

$ nvm ls v0.10
       N/A

$ nvm ls v0.11
       N/A

$ nvm ls v0.10.2
   v0.10.2

$ nvm ls v0.10.29
  v0.10.29

On hacked VPS install:

$ nvm ls
->  v0.10.29
    v0.10.30
     v0.11.9
      system
default -> v0.10.29

$ nvm ls v0.11
     v0.11.9

$ nvm ls v0.10
->  v0.10.29
    v0.10.30

$ nvm ls v0.10.2
         N/A

$ nvm ls v0.10.29
->  v0.10.29

Which one is outputting things correctly?

[ljharb]

You shouldn't need to specify the "v" - nvm_format_version makes sure the v is prefixed. ie, nvm use 0.10 and nvm use v0.10 should be identical.

[ljharb]

@kematzy Can you try this again on the latest nvm, v0.16.1?

[ivan-kleshnin]

I've got the same problem on OSX

# .bashrc
export NVM_DIR=~/.nvm
source $NVM_DIR/nvm.sh

leads to

sed: 1: "s/^\([0-9]\)/v\1/g
": \1 not defined in the RE

nvm version 0.22.0

[ljharb]

@ivan-kleshnin What's your nvm alias output? Do you have an .nvmrc file anywhere?

[drkibitz]

Would this work across shells or is this specific to bash? Sorry, saw this thread and thought I'd throw something out there.

nvm_format_version() {
    echo ${1/#[0-9]/v${1:0:1}}
}

[ljharb]

@drkibitz I believe that syntax is not bash-specific, but not portable. It errors out in dash although it works in sh/zsh/ksh/bash.

[ivan-kleshnin]

What's your nvm alias output?

$ nvm alias 
sed: 1: "s/^\([0-9]\)/v\1/g
": \1 not defined in the RE
sed: 1: "s/^\([0-9]\)/v\1/g
": \1 not defined in the RE

Do you have an .nvmrc file anywhere?

No

[ljharb]

@ivan-kleshnin thanks - a few more :-) which sed,type sed,alias sed,nvm_format_version 1.2,nvm_normalize_version 1.2(should be1000002000000),nvm_ensure_version_prefix 1.2. Also, do you have any env variables set that might affectsed` or regex parsing?

[ivan-kleshnin]

Thank you, Jordan, I've nailed it down with your help. It was line
$ alias sed='sed -E' which causes the error.
I don't have much time to investigate this further, but looks like nvm should be ok now.

[ljharb]

Ah, yes - aliasing builtin commands can always cause trouble. That said, I can fix this particular one, and hopefully it will fix @kematzy's issue as well.

[ivan-kleshnin]

So it's better to always give aliased builtins new names, to avoid similar problems in future, right?
I was too naive, following some guide, when introduced that trap.

[ljharb]

@ivan-kleshnin yes, exactly.