http-server: command not found

[zeke]

I'm trying to run globally-installed modules with monu, but it's failing. Here's my config.json:

{
  "logs": "./logs",
  "pids": "./pids",
  "processes": {
    "web-1": "http-server . -p 8081",
    "dot-clipboard": "dot-clipboard"
  }
}

The logs say:

http-server: command not found

I have http-server installed globally:

 » npm list -g http-server
/Users/z/.nvm/v0.10.38/lib
└── http-server@0.8.0

What should I do to help monu find it?

[max-mapper]

hmm this is supposed to fix it https://github.com/maxogden/monu/blob/master/index.js#L13-L14

i know it was working before @sindresorhus sent me the PR that added that (i had a ghetto fix before)

[zeke]

Ahh I'm using the 1.0.6 Alpha -- should I run master, or nag for a release? :)

[zeke]

I'm seeing the same issue running from the master branch.

[sindresorhus]

I just tried monu master as a built app, and process.env.PATH before the fix is:

/usr/bin:/bin:/usr/sbin:/sbin

After it's:

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

It uses shell-path to spawn your shell and echo out the $PATH as it's not available automatically for GUI apps on OS X.

@zeke What does echo $PATH give you?

This might have something to do with the use of nvm.

[zeke]

echo $PATH
/Users/z/.nvm/v0.10.38/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:./node_modules/.bin

@ljharb, maintainer of nvm, might have a bright idea. :)

[ljharb]

If you're using nvm, and also using things like the npm config setting prefix, or similar env vars, things will break. See nvm-sh/nvm#606

[zeke]

I'm using a fresh installation of nvm and a nearly-empty ~/.npmrc on a new machine. I'm not explicitly doing anything with prefix, though I see it's being set, presumably by nvm itself:

npm config get prefix
/Users/z/.nvm/v0.10.38

[ljharb]

I believe that's just the default npm behavior when prefix isn't set. Sounds like my hunch isn't the issue though.

What does fix-path do, exactly?

edit: based on #21 (comment), in order for the PATH to work right with nvm, the shell that it shells out to needs to have nvm use as well. I believe this would cause a problem with nave as well, since it also uses the PATH in a similar fashion.

[zeke]

@maxogden and @sindresorhus, how are you managing multiple node/iojs installations and keeping your PATH happy?

[max-mapper]

I only ever use latest iojs :)

[sindresorhus]

how are you managing multiple node/iojs installations and keeping your PATH happy?

I use n as it's given me the least amount of trouble (I've tried them all), and it doesn't use subshells or sourcing.

@ljharb Is there any way to get the bin folder from nvm without forcing the user to manually do something?

[ljharb]

@sindresorhus sure, dirname "$(nvm which X)" where X is the versionish you want to locate. However, you could also just do dirname "$(which node)" to be truly portable, and to always grab the current node's bin folder.

[zeke]

n did the trick for me, and monu is now finding my globally installed modules. Closing. Thanks for all the help.

[ljharb]

if monu isn't working with nvm or nave, then it's still a monu bug.

n, nave, and nvm are each for three different use cases, and they're all used pretty widely, so it's ideal for tools to work the same with all of them as with a system-installed node.

[sindresorhus]

dirname "$(nvm which X)" where X is the versionish you want to locate.

I don't know the version. I'm just a node module wanting to know the users node module bin dir.

However, you could also just do dirname "$(which node)" to be truly portable, and to always grab the current node's bin folder.

And "current node's bin folder" is also the bin folder for globally installed modules when using nvm?

if monu isn't working with nvm or nave, then it's still a monu bug.

I would argue it's the other way around.

[ljharb]

@sindresorhus ah - i see what you mean. No, the folder for globally installed modules is usually `"$(npm root -g)../../bin" but I don't think there's an easy way to get at it directly.

As for who's got the bug, if your module is using any PATH that's different from the one available in the current shell session, that could always cause a bug - for example, if i installed node from source but put it in a nonstandard location.