I use Fish shell on Ubuntu and OS X for basic stuff: file manipulation, using command-line apps, and occassionally doing some light shell scripting to automate my workflow.
Coming from BASH this shell feels like a much-needed update! Instead of worrying to make sure my terminal has all of these feature and then having a different experience in each terminal app - now All of the features are in shell not the terminal and I can connect anywhere, from any device, and enjoy the same setup.
The only two downsides are actually the same downside: its not compatible with BASH's shell scripting, which means you often cant just run shell scripts written by others, you may have to reformat it a little first. Same if true for how you format aliases and a few other shell-related stuff you put in your options file. It will still all work, but unless it's been ported to Fish's syntax it may need to be updated or rewritten.
This means that all of my scripted automation I have done is Fish-specific for now and wont run in regular BASH.
> its not compatible with BASH's shell scripting, which means you often cant just run shell scripts written by others, you may have to reformat it a little first.
What exactly do you mean by “Shell scripts”? If the script contains a proper Shebang you can easily run it via `./script.sh`. If not you use: `bash ./script.sh`.
The biggest problem I have is scripts that are meant to be exec-ed from the interactive shell. For example, scripts that set environment variables and change the current directory.
I have several bash functions that need to be sourced to be included. For instance, I use `cdc` to change to my code directory, where I keep my source for projects I am working on. If I type `cdc name` it changes it to my projects source directory, save me a lot of keystrokes in a day as I have many that I flip between. This sourcing of a function is required due to the way cd is handled, and in it's current form, not directly usable under fish. Maybe it's easier under fish, but fish isn't backwards compatible to make this work out of the box.
CDPATH is not a very good bookmarking system, as you can't bookmark several directories that have the same name, and you are forced to bookmark all the siblings of the item you wish to bookmark, which can be a problem with flat hierarchies. So if bookmarking directories is the goal, CDPATH might not be the best way. And one off bookmarking functions are easy to write.
Admittedly for the description given, it does sound like CDPATH would work. But I'm going to assume there's a reason, and functions that change the current working directory are the perfect example of functions that can not be run in a subshell, so will have to be rewritten to fish, which is what the author was providing.
I simplified the example, cdc does more than just a change the directory. `cdc -t name` changes to the directory and attaches to the tmux session of the same name if it exists, and if it doesn't, sets up my tmux layout for development.
whilst reading your above comment i wondered why you chose not to use environment variables instead. e.g.:
$ export cdc_stuff='/Users/me/src/project_stuff'
$ cd $cdc_stuff
however, now it's clear.
in the event you're looking for alternatives, perhaps porting your code to (e.g.) ruby could work.
just in case, here's the isbn number of a book called, 'Build Awesome Command-Line Applications in Ruby 2,' from the pragmatic bookshelf: 978-1-93778-575-8
It seems a lot of people don't realize `bash`, `sh`, `zsh` etc... are executable binaries just like any other on the system, and that you don't need to be logged in to a bash shell to run bash scripts.
This isn't the case for sourced scripts. Running a script in bash from fish that changes your current directory will do one of two things: It'll move you to that directory but inside of a bash shell, or it will move you to that directory in a bash shell, bash's cd will return, and you'll be in the same directory as before, still in the fish shell.
I'm no CLI wizard, so when I sit down to make my own function or alias I'm going to be googling how to do it whether it's for Bash or Fish.
What I meant in my comment above is a lot of 'download an install' instructions in tutorials, and sometimes installation wizards for programs are written for bash, and can't be run without modification in Fish. Not a major setback, but for a Bash user it would just work.
I 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 code to switch to a much superior shell, though.
Fish shell is awesome. But yes, compatibility of sourced functions was a bit of a problem for me. After about a year with it, I switched back to zsh. With a couple plugins I was able to get much of the fish features out it, while keeping the bash compatibility. Here is how I do it.
Install oh-my-zsh, and enable I couple plugins. Here's what I have in my config:
plugins=(git history-substring-search zsh-syntax-highlighting docker sudo)
In terms of 'enjoying the same setup on all devices', I use dropbox (or owncloud), to sync my config. All I have to do is add this at the bottom of my .zshrc file:
source ~/Dropbox/global.zshrc
My last tip about directory jumping, for keedot, is there are methods that will do this for you. I use fasd (https://github.com/clvv/fasd) which you can add to your shell and will remember the directories you use often so you dont have to make special cases for specific ones. Check out the 'z' command. It has been amazingly useful.
My main gripe with a shell like Fish is that it won't work with the trusted ol' BASH scripts. Seeing as I deal with quite some BASH scripts on a day-to-day basis at work this keeps me from trying it out, even though I'd love to be able to use something more sophisticated/evolved than plain BASH.
My main gripe with 'BASH scripts' is that in most cases they could simply be 'Shell scripts' and in most cases they call and require Bash for no reason at all ;)
I guess most people cannot be bothered to remember which features are bash specific and which will work in any /bin/sh. I don't think there is such a thing as a generic "shell script", csh has completely different syntax.
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 in productivity from fish.
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.
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/<ctrl>-D like with any shell. You do not need to remember a special "deactivate" command like with virtualenv.
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).
Fish 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.
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.
You might be interested in oh-my-fish which tries to be pretty similar to oh-my-zsh, including an optional theme that matches the default zsh theme. I'd definitely recommend it.
I've been using fish shell on osx for the last 3 years. It's fun and puts ctrl-r in front of my typing without being obtrusive. I'm glad to see it here.
I'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.
Downvotes? Come on, the 90s were fantastic. I haven't heard of Fish before but what I said was meant as a supportive pat on the shoulder; projects like these are great. So whoever's pressing the down button, please, try to crack a smile, or at least stop ruining mine.
Comments which add little or no value to the discussion are discouraged by HN community mores [edit: the "avoid me too comments" has been removed from the guidelines but habits die hard]. The reason is illustrated by this subthread: such comments often devolve into metadiscussion about behavior and complaints about community norms.
The up arrow expresses support for the story. The delete link allows a person to revoke comments that don't merit upvotes. The edit link lets comments to be modified with supporting details, examples, evidence and rationales that contribute to HN'ers understanding and knowledge by extending the content.
That's more constructive than complaining about downvotes and implying that people don't get it.
I think the downvotes are because you completely failed to grasp what Fish shell is. It is a newer more modern shell than bash not some type of retro 90's toy.
The web server is only active if you run the command fish_config. When you run this command, if finds the next available port, starting at localhost:8000 and opens a web browser pointing to that port.
Once in the web interface, you can click around to implement some pre-supplied recipies to your fish configuration.
If you hit ctrl-c, the fish_config program exits and stops listening on the port.
I don't think it automatically starts up. You have to run fish-config to start it yes?
$ fish_config
Web config started at 'file:///Users/bjorn/.cache/fish/web_config-6VIDFM.html'. Hit enter to stop.
::1 - - [12/Jul/2015 11:13:31] code 403, message Forbidden
When I kill this and refresh the config in the browser doesn't load anymore. So I don't see the problem.
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!
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...
You guys keep beating around the bush and keep downvoting me! Is the web server built-in? Yes, it is. Why do you keep finding excuses and why do you keep downvoting the voice of reasons - a shell should not have a web server in its codebase, period. Put this into an optional package and make everybody happy!
You are just shouting that a shell should not have a web server in it's codebase, but you are giving no reasons why. I am using vim in the console to this day, and I don't mind my shell having a web interface for the most common use cases.
Some people do find the web interface useful, otherwise it wouldn't be there. On the other hand, you are not providing any reasons why a web server is harmful, why would anybody listen to you as the voice of reason, if your axiom is "a shell should not have a web server in its codebase, period"?
Fish is a deviant. There are thousands of *nix projects out there, many with a much more desperate need for a web UI, but they simply don't do it, because they know that they shouldn't cross that line.
Coming from BASH this shell feels like a much-needed update! Instead of worrying to make sure my terminal has all of these feature and then having a different experience in each terminal app - now All of the features are in shell not the terminal and I can connect anywhere, from any device, and enjoy the same setup.
The only two downsides are actually the same downside: its not compatible with BASH's shell scripting, which means you often cant just run shell scripts written by others, you may have to reformat it a little first. Same if true for how you format aliases and a few other shell-related stuff you put in your options file. It will still all work, but unless it's been ported to Fish's syntax it may need to be updated or rewritten.
This means that all of my scripted automation I have done is Fish-specific for now and wont run in regular BASH.