What does it add exactly? As far as I can tell, it's needlessly incompatible with POSIX shells, and doesn't do as much as e.g. zsh (or even bash?).
I'm not saying that zsh & bash are the end-all, be-all of shells, but I just don't see that fish improves on them.
And honestly, for config files I think we could do a lot worse than an s-expression language.
Here's where I think fish fits in. The main goals of fish are:
1. Thoughtful UI that just works
2. Sane scripting
zsh does more than fish, and we're happy to let it. The tradeoff is that zsh requires substantial configuration to realize that power - and once you get into the weeds, you will learn which options are incompatible with each other. zsh has 21 options controlling history, and fish has none, but you'll probably be happier with fish's defaults.
fish has a smaller feature set, but that feature set just works out of the box: tab completions, syntax highlighting, autosuggestions, etc. Customizations (prompt, colors, etc) can be done with a web UI or a nice command line interface, and not arcane syntax (PS1=...)
The hope is you can be more productive in your shell without needing to invest tons of time configuring and learning it.
The biggest amazing default is to be able to start typing and have it be searching the history. When I'm ready to start work on a project I can start typing part of the project's name, say "bar", and fish will come up with a history item for "cd /customers/foocorp/barproject".
I still do my "scripting" shell work in bash though, since it runs everywhere.
Parent's comment is misleading, then. As someone who already has a pretty solid grasp of Bash, when I peeked at Fish it looked like there was nothing that it would gain me -- though I understand that the preconfigured shell can be useful for people who don't have the time to learn and tweak it.
If you're a die-hard bash user, autosuggestions are the feature most likely to pique your interest and make the command line more pleasant.
Probably (although I use a zsh distribution to get a sane setup). I definitely appreciate the idea of sane defaults, rather than forcing the user to set everything up properly from scratch. And your autosuggestions do look pretty swell.
> Customizations (prompt, colors, etc) can be done with a web UI or a nice command line interface, and not arcane syntax (PS1=...)
You ship a web server in the shell? Is it always running, or does the user have to do something to start it up?
I kinda like setting variables, to be honest. But I'm old-fashioned.
One thing I really wish y'all'd done was use more standard shell syntax. It's really painful working in an office where someone uses fish and lets fish-isms creep into shared command libraries.
> Is it always running, or does the user have to do something to start it up?
Looks like the latter: https://fishshell.com/docs/current/commands.html#fish_config* Syntax highlighting
* Implicit cd to directory
* 100,000 line history
* History de-duplication
* Inline auto-suggestions
* Tab completion using man page data
* Paginated completion
* Copy/paste using X clipboard
The only things I feel the need to configure on a new fish install, is PATH and my prompt. Because I'm pedantic and like things exactly so.
You can get these with zsh, but it's more than apt-get install.
I do not want that my lines get deleted silently. ever. I would rather prefer that random files on my disk are deleted, before that. Is there any shell without line history limit?
bash's history limit is by default the last 500 commands, without considering duplicates. In practice this limit is easy to exceed, which is why bash config guides recommend upping it.
fish's history limit of 2^18 (~256k) commands is really more of a sanity check. Duplicate commands are counted only once, and commands are discarded by LRU (not oldest). This means history only starts being dropped after hundreds of thousands of unique commands. If you in fact run that many distinct commands, I'd love to hear more about your use case!
export HISTSIZE=-1
export HISTFILESIZE=-1
When the history file is not in the disk cache, startup time will increase noticeably after a while though (think a second, maybe two).
I also like that the author mentioned runit. I wish there was more documentation for runit, but I've been using it on Void linux and it's an amazing, damn simply init system. If an init script is missing for any package in Void, they are trivial to write. Most are less than three lines.
I also really like how the post author demonstrated how shell commands are composed in ways that traditional functions aren't composed; that is commands that change the environment for the command they run (environment variables, processor scheduling, security, input/output redirection). This is the very nature of an _implicit_.