Binaries conflicting with existing commands creates error

[SimenB]

Such as greenkeeper, which has the short form gk, which on my machine is aliased (gk: aliased to \gitk --all --branches).

I then get a warning when nvm loads gitk:unset:1: no such hash table element: gk.

$ nvm ls
nvm:unset:1: no such hash table element: gk
       v0.10.47
       v0.12.16
->       v6.8.1
default -> 6 (-> v6.8.1)
node -> stable (-> v6.8.1) (default)
stable -> 6.8 (-> v6.8.1) (default)
iojs -> N/A (default)
lts/* -> lts/argon (-> N/A)
lts/argon -> v4.6.0 (-> N/A)

Worse is trying to use gk makes it loop infinitely.

$ gk enable
gitk:unset:1: no such hash table element: gk
gitk:unset:1: no such hash table element: greenkeeper
gitk:unset:1: no such hash table element: ncu
gitk:unset:1: no such hash table element: node
gitk:unset:1: no such hash table element: npm
gitk:unset:1: no such hash table element: npm-check-updates
gitk:unset:1: no such hash table element: typings
gitk:unset:1: no such hash table element: yarn
gitk:unset:1: no such hash table element: yarnpkg
gitk:unset:1: no such hash table element: gk
gitk:unset:1: no such hash table element: greenkeeper
gitk:unset:1: no such hash table element: ncu
gitk:unset:1: no such hash table element: node
gitk:unset:1: no such hash table element: npm
gitk:unset:1: no such hash table element: npm-check-updates
gitk:unset:1: no such hash table element: typings
gitk:unset:1: no such hash table element: yarn
gitk:unset:1: no such hash table element: yarnpkg
gitk:unset:1: no such hash table element: gk
gitk:unset:1: no such hash table element: greenkeeper
gitk:unset:1: no such hash table element: ncu
gitk:unset:1: no such hash table element: node
gitk:unset:1: no such hash table element: npm
gitk:unset:1: no such hash table element: npm-check-updates
gitk:unset:1: no such hash table element: typings
gitk:unset:1: no such hash table element: yarn
gitk:unset:1: no such hash table element: yarnpkg
gitk:unset:1: no such hash table element: gk
gitk:unset:1: no such hash table element: greenkeeper
gitk:unset:1: no such hash table element: ncu
gitk:unset:1: no such hash table element: node
gitk:unset:1: no such hash table element: npm
gitk:unset:1: no such hash table element: npm-check-updates
gitk:unset:1: no such hash table element: typings
gitk:unset:1: no such hash table element: yarn
gitk:unset:1: no such hash table element: yarnpkg
gitk:unset:1: no such hash table element: gk
gitk:unset:1: no such hash table element: greenkeeper
gitk:unset:1: no such hash table element: ncu
gitk:unset:1: no such hash table element: node
gitk:unset:1: no such hash table element: npm
gitk:unset:1: no such hash table element: npm-check-updates
gitk:unset:1: no such hash table element: typings
gitk:unset:1: no such hash table element: yarn
gitk:unset:1: no such hash table element: yarnpkg

etc.

This is using LAZY, tbw.

[lukechilds]

Hmmn, definitely an issue with lazy loading.

I'm pretty busy this weekend, I'm probably not going to get a chance to look at this until Monday. Disabling lazy loading should resolve the issue for now.

I'll let you know when it's sorted 👍

[lukechilds]

@SimenB Recreated this, working on a fix.

[lukechilds]

@SimenB Ok, I'm now checking if any commands exist globally before setting the lazy load functions. If they already exist, those commands are ignored. 4c61739

Can you checkout the fix-alias-bug branch and let me know if that resolves the issue for you? If it does I'll merge into master.

[SimenB]

So gk won't work until nvm is loaded?

I'll test tonight

[lukechilds]

No gk won't work at all because the alias overrides it. That's how it would work without lazy loading. You'll need to remove your gk alias if you want to use the gk greenkeeper binary.

[SimenB]

if nvm is loaded, then it works though. Why should lazy change that (other than the hit we get loading nvm the first time)?

[lukechilds]

Hmmn, it shouldn't do. The alias should be overwriting the function. That's how it's working on my dev VM.

If you disable lazy loading what happens when you run gk? Do you run gitk or Greenkeeper?

[SimenB]

@lukechilds OK, tested now, and you are correct! It's gitk which is run when lazy is false.

And your branch fixes the issue 😄

I had to set lazy to false btw, it seems to default to true. That hasn't happened before, unsure why it happened now

[lukechilds]

@SimenB Merged 👍