isaacs/nave

nave for fish shell

MrBri opened this issue · 7 comments

MrBri commented

Would like to start a discussion on the possibility of porting this to fish.
I've been using nvm-fish just fine but it doesn't have iojs.

Just started using this nvm-fish-wrapper but am having issues with it.

Not yet a master bash or fish shell scripter yet.

isaacs commented

I have discussed this idea with a few people in meatspace and on IRC, but never in a github issue. Thanks for the nudge :)

  1. We're not going to "port nave to fish". That's just silly. Nave itself will remain a bash program.
  2. I would like to add support for fish, in the same sense that nave supports zsh users, by dropping them into a zsh shell.

Here's a rough outline of how nave works:

  1. You type some nave command telling it what version you want to run (perhaps by specifying a version, perhaps by specifying a keyword like "stable")
  2. Nave sets up the binaries in its working dir if they're not already there (builds node, unpacks the binary tgz, whatever)
  3. Nave runs the shell of your choice (bash by default, but zsh is also supported) in such a way that the PATH and other environment variables are set up so that the desired node version is the one you'll get by default.

The step 3 is the part that's easy for bash, kinda tricky/buggy for zsh, and not implemented for fish.

The easiest way to do it is to say "run the shell, and before dropping into user-interactive mode, run this specified script file". So, instead of running ~/.bashrc, it'll run this file instead. With bash, this is super easy, you just specify the specific file with --rcfile <filename> when you invoke bash. With zsh, it's a bit wonky; you can specify the folder with an environment variable (!!), but the file must be named .zshenv.

So, we have this file named .zshenv which gets dumped in the nave dir at ~/.nave/.zshenv, and when we invoke bash, we do bash ... --rcfile=~/.nave/.zshenv and when we do zsh, we do ZDOTDIR=~/.nave zsh ... (and then have to unset the ZDOTDIR in the file, or else it'll get screwey.)

The tricky bit here is that zsh and bash are both mostly-sh-compatible, so you can pretty easily write a single rc file that works with both. But fish is a dramatically different language, so the task is:

  1. Figure out how to invoke fish with an rc file we control.
  2. Write a fish rc file that does the same stuff that nave's .zshenv does, but in fish lingo.
  3. Detect with reasonable accuracy whether the user is using fish, and if so, spawn a fish shell.

Patch welcome! Happy to answer any questions and provide guidance along the way if anyone is interested in doing this. I am not a fish user, and unlikely to ever get to it myself.

Probably the best place to start is with man fish.

ceejbot commented

@MrBri You might find https://github.com//passcod/nvm-fish-wrapper helpful. This is what I'm using to get nvm working with fish, including iojs support.

michaeljones commented

I have experimented a little and come up with this michaeljones/nave@cea3eb2 which appears to work though I've yet to test it thoroughly and would welcome feedback. I'm not sure if it is good enough for merging but perhaps others would find it useful.

isaacs commented

@michaeljones I left some really minor nitpick suggestions on the commit.

I think the approach is clever! However, I'd be a little bit concerned if fish's startup scripts set a PATH environment variable explicitly, since that'll mess with the nave startup script.

isaacs commented

As far as I can tell, fish doesn't use a startup script or set the PATH explicitly... so, maybe this is fine? Wanna send a PR?

michaeljones commented

Hi, thanks for the feedback. Happy to clean it up a bit. Your suggestions are all very reasonable I just didn't have the right "PR" mindset when trying to get it working.

Fish does have a ~/.config/fish/config.fish file that acts like a .bashrc file and it also sources other files in the ~/.config/fish directory. I can't see a way to stop it though. The docs don't list something obvious. I though maybe combining a file argument with the --interactive flag might work but no luck.

Personally I'm ok working with tools that result in my standard rc file or fish.config being sourced multiple times and I just assume it is my responsibility to make sure that it does no harm. I can imagine wanting to avoid it though if possible. Perhaps listing it as a known issue for fish support is enough? Or perhaps I'm misreading the situation.

Cheers!

isaacs commented

Published on 2.2.0