How does it compare to zsh (more specialy the package o-my-zsh)? The only thing that catch my eyes was the shell command being completed automatically in grey in the background. That will be great to have this in zsh.
Fish shell 2.2
51–60 of 73 posts
Re: Fish shell 2.2
#52Fish is probably my favorite shell after having worked with csh, bash, and zsh. But I have to use RVM at work, and it's a real bummer that RVM and Fish don't play nice with each other. I know rbenv works great with Fish, but I'm stuck with RVM at work. So using zsh as a second choice for now.
Re: Fish shell 2.2
#53I'd like to use Fish more, but my biggest worry is that many tools don't come with instructions or support for Fish. I think that means you have to be committed to learning a lot about Fish, or use two shells?
Re: Fish shell 2.2
#54I'd like to use Fish more, but my biggest worry is that many tools don't come with instructions or support for Fish. I think that means you have to be committed to learning a lot about Fish, or use two shells?
I use fish primarily. Once in a while I drop into bash. For example, one tool requires me to "source environment.sh" (similar to virtualenv) and this cannot be done in fish.
Re: Fish shell 2.2
#55I use fish exclusively and swear by it. I switched to zsh some years ago and enabled fish emulation, but it was slower, and I realized all I was doing was using fish by proxy, so I switched back to fish. It's fantastic, I urge everyone to give it a try. Pretty much the only valid complaint I see here is from people who have bash code that needs to be sourced to run. I definitely think that it's worth rewriting some c…
Ack.
If I need to source, a quick "bash" drops me back to bash. This is good enough for me.
Re: Fish shell 2.2
#56Earlier quoted context omitted.
It just makes Fish feel desktopy, a toy shell, and not something serious. Ask the vim crowd that even in 2015 uses vim in the terminal, even on desktops. You just don't do the things Fish does, it's that simple. Make the web server an addon and keep everybody happy!
You want the web server to be an add-on so you can feel more hardcore?
I was being sarcastic, but I don't really like the idea of my shell having a built-in web server even if it's just a few lines of code - feels like a Rube Goldberg machine. You can do nice TUIs in the console as well, even with graphics, but it's not necessary in this case. Configuration files are just fine for nearly 100% of the people who use Fish.
Re: Fish shell 2.2
#57Earlier quoted context omitted.
How come your scripts don't work with #!/bin/bash ?
Because we don't always source a shell script, you may need to source functions for certain functionality to work.
Imho "source" is an anti-feature. I think instead of "source", you always should create a subshell. It properly encapsulates your modified environment and avoids leakage and confusion. Exiting an environment is a straighforward exit/-D like with any shell. You do not need to remember a special "deactivate" command like with virtualenv.
Obviously, virtualenv and others disagree. ;)
Re: Fish shell 2.2
#58Earlier quoted context omitted.
Yeah, I keep seeing this complaint come up. Interesting that so many people don't realize you can run bash scripts from another shell without fanfare.
There's just a couple tricky ones in these scenarios. For me, there's virtualenv and rvm that both mess with shell stuff deeply enough to where running them in fish can be tricky. virtualenv has good fish support, but never really got rvm working. I ended up going back to zsh after 2 years or so in fish because of small issues like that and realising that so long as I had reverse search I wasn't really gaining much i…
In my terminal I usually have several tabs opened by default in fish, but have another open to the python repl, and sometimes bash if I need something. Easy enough to do.
Re: Fish shell 2.2
#59Earlier quoted context omitted.
Because we don't always source a shell script, you may need to source functions for certain functionality to work.
Imho "source" is an anti-feature. I think instead of "source", you always should create a subshell. It properly encapsulates your modified environment and avoids leakage and confusion. Exiting an environment is a straighforward exit/ -D like with any shell. You do not need to remember a special "deactivate" command like with virtualenv. Obviously, virtualenv and others disagree. ;)
I swear by subshells. They solve so many problems. People object that they don't let you do environment autoloading on `cd`, though (which I also hate, so... Yeah).
Re: Fish shell 2.2
#60Earlier quoted context omitted.
You want the web server to be an add-on so you can feel more hardcore?
I was being sarcastic, but I don't really like the idea of my shell having a built-in web server even if it's just a few lines of code - feels like a Rube Goldberg machine. You can do nice TUIs in the console as well, even with graphics, but it's not necessary in this case. Configuration files are just fine for nearly 100% of the people who use Fish.
You may feel better to know that the web server is not part of the shell itself. It's a separate Python script that does its work by invoking fish and sending it commands. Its source is here: https://github.com/fish-shell/fish-shell/blob/master/share/t...