Concurrently 3.0.0 runs the wrong version of node

[aaronjensen]

I use asdf to manage my node versions. The new shell execution method in concurrently 3 appears to ignore my asdf setup and my previous environment so it runs w/ an older, system node. This makes everything fail.

[kimmobrunfeldt]

Sounds like a problem with PATH. Could you run

npm i spawn-default-shell && node -e "console.log(require('spawn-default-shell/src/get-shell')())"

and paste the last line of the output here? That will tell which shell concurrently is spawning to get forward with this. It may be that the spawned shell doesn't read configuration from .bash_profile or similar env files.

[aaronjensen]

{ shell: '/bin/zsh', executeFlag: '-c' }

[kimmobrunfeldt]

Ok I have the same shell, and I can correctly use the node version but I'm using nvm. Could you run concurrently 'which node && node -v' and concurrently 'echo $PATH'. You could then try to resolve why the spawned shell is using the wrong node binary.

[kimmobrunfeldt]

For me theses commands return:

➜  ~ concurrently 'which node && node -v'
[0] /Users/kbru/.nvm/versions/node/v6.3.1/bin/node
[0] v6.3.1
[0] which node && node -v exited with code 0
➜  ~ concurrently 'echo $PATH'
[0] /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/kbru/.gem/bin:/Applications/Postgres.app/Contents/Versions/latest/bin:/Users/kbru/.nvm/versions/node/v6.3.1/bin:/Users/kbru/.rvm/bin
[0] echo $PATH exited with code 0

[aaronjensen]

$ concurrently 'which node && node -v'
[0] node is /usr/local/bin/node
[0] node is /usr/local/bin/node
[0] v0.10.35
[0] which node && node -v exited with code 0
$ concurrently 'echo $PATH'
[0] /usr/local/heroku/bin:/Users/aaronjensen/Library/Haskell/bin:/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/opt/local/bin:/opt/local/sbin:/usr/local/share/npm/bin:/Users/aaronjensen/.bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
[0] echo $PATH exited with code 0

My setup for asdf is in my zprofile

[kimmobrunfeldt]

Ok thanks for reporting this bug. It seems that when we are running commands with /bin/zsh -c "...", profile files are not read. If anyone knows a flag to enable the profile file reading, I'm interested to know.

[kimmobrunfeldt]

Ok found it from man bash, we need to invoke the shells as a login shell (use -l flag). Read more from https://github.com/kimmobrunfeldt/spawn-default-shell README.

[kimmobrunfeldt]

@aaronjensen Ok this is now fixed in spawn-default-shell, it will by default use -l flag when running shell. E.g. with bash: /bin/bash -l -c "...". This will invoke bash as a login shell and it will execute ~/.bash_profile before running the command. With zsh the same flag will read ~/.zprofile correctly.

To my mind this is the expected behaviour of concurrently, but could there be some unwanted side-effects? Should I make the -l flag default in concurrently, or should it be an optional flag(e.g. --invoke-login-shell) for concurrently?

[aaronjensen]

@kimmobrunfeldt now that I've thought about this some more, I think that this method won't actually work, even with -l.

What concurrently should do is use a shell that shares the same exact environment as the shell running it.

Here's why:

Let's say you are using concurrently in continuous integration. You also have some secrets that you keep in environment variables associated with your build. Your CI server injects those environment variables via a script it runs to execute your build. This enables anything run within that script to have access to them. It does not update your profile or anything along those lines. This would mean that any shell started to run things that require those environment variables must share that environment. Starting a totally fresh shell would be bad, and making it a login shell would not bring those environment variables in. As a matter of fact, even if you inherited the environment and made it a login shell your login shell scripts may be overriding things that were exported in the parent environment.

In short, concurrently should behave as running bash -c ... or zsh -c ... from an existing shell. It should not have its environment reset at all.

[kimmobrunfeldt]

@aaronjensen I'm not sure if I understand what you mean. Concurrently does already share the environment as well as possible. Running concurrently "x" in your current shell is from environment variable perspective same as running bash -c "x". I think PATH is an exception to this and running bash -c "x" some how resets the PATH variable, but e.g. the env variables set by your CI are available at that new shell.

I don't know any better way to "use a shell that shares the same exact environment as the shell running it." than the current solution. If you have an idea please share.

In short, concurrently should behave as running bash -c ... or zsh -c ... from an existing shell. It should not have its environment reset at all.

There is no special "reset" done by concurrently or spawn-default-shell. So it is as close to running these commands from an existing shell as possible. It's just the way bash -c ... and others work. E.g. see this output:

➜  ~ bash -c "nvm"
bash: nvm: command not found
➜  ~ nvm

Node Version Manager
...

nvm is available in my "normal" shell, but not when using bash -c "nvm". The only way I know to fix this is to use bash -l -c "nvm", which correctly reads my .bashrc and makes nvm available.

[aaronjensen]

You're right, bash/zsh will exec the rc files regardless, which will usually override PATH.

If you want to maintain all env vars, I think bash -fc "..." will work, but that won't copy over functions or aliases. Since it will maintain path it may be exactly what concurrently needs.

I guess one thing I don't understand is why does concurrently need to run each thing in its own shell? I don't understand it well enough to know that.

The other option would be to do something like bash -lc "PATH=$PATH ..." which would copy your current path over to any command you ran, but that's fragile since a command could have && in it or the like. Maybe there's another way, I'm not sure.

[kentcdodds]

Anyone here want to try out my fork and comment back if it worked? I think that'll fix the issue.

npm install https://github.com/kentcdodds/concurrently.git#pr/use-spawn-command

[gustavohenke]

Published v3.3.0.
Could you try it, @aaronjensen?

[aaronjensen]

This works. Thank you @kentcdodds and @gustavohenke!