1. 37
  1.  

  2. 23

    Using fish really made my life better. I don’t care about my prompt looking all crazy (I just use a $ or #) but the autocompletion features are awesome. And the syntax makes life so so easy.

    Not a great article, doesn’t actually show off some of the stuff you can do with the shell, like permanent aliases from the command line, the short-hand commands that automagically expand out (i type eix and it’s expanded to xbps-query -Rs), the web configuration interface, all that cool stuff.

    1. 8

      I love fish. I switched to it to escape my cargo-culted 10yo zsh config, and it worked out of the box. I even could configure a custom prompt (by modifying one of the builtin ones) and a few custom helpers pretty quickly, whereas zsh always scared me. And the syntax just makes more sense imho.

      1. 7

        In my opinion, the main advantage of zsh over fish isn’t the shell itself but its ecosystem; tools like powerlevel10k (a powerline-like theme that loads instantly thanks to a custom gitstatus implementation and a cached prompt), a large number of autosuggestions, and fzf-tab (replaces the builtin autocompletions with an interactive fuzzy menu) make the shell a joy to use.

        1. 10

          Have you see Starship yet? Between that and Fish’s defaults, I turned to my 100+ line ZSH config and eliminated half of it outright. Pretty cool for my set up.

          1. 2

            Starship is actually slower than powerlevel10k on my computer, probably because the cost of running another program offsets the benefit of running native code (more info from the powerlevel10k dev in another Lobsters thread). Powerlevel10k also supports displaying a cached “instant prompt” while the main prompt loads, saving another few precious miliseconds. Its custom gitstatus daemon also offers a performance boost for displaying git info.

            The result is that my prompt displays instantly as soon as I open a terminal. I often launch a terminal and start typing right away; if I have a fancy prompt that takes more than 20ms to load, I sometimes enter text before the prompt finishes loading, resulting in an ugly broken first prompt. Powerlevel10k is the only fancy prompt I’ve used that fixes this issue.

            Edit: to add, another reason I’d rather use zsh (or even bash/sh) is that I can source functions written in POSIX shell. By writing shell functions/aliases in POSIX shell, I can guarantee that I can bring them with me anywhere, including remote systems. If a remote server has a POSIX-compliant shell, I can bring along all my helper functions and aliases in a single file.

            Another edit: if anybody wants to see what my shell looks like, here’s a screenshot (mirror). The FZF-based completion menu made by Aloxaf is miles better than anything else I’ve used, including the one that comes with Fish and python_prompt_toolkit (and by extension, xonsh); it utilizes native zsh completion sources. When completing paths, typing a slash automatically selects the current item and refreshes the completion menu to select a subdirectory.

        2. 6

          I switched away from Fish (after using it for several years) because I couldn’t get used to it’s non-POSIX syntax…

          1. 13

            That’s the reason I picked it; for day to day usage, it’s a lot less warty, and if I need a bunch of POSIXy stuff, I can just exec bash.

            1. 1

              You are correct in that exec bash is a useful way to run POSIXy stuff. Unfortunately (to my knowledge), shell functions, aliases, etc. must be translated into fish. I depend on being able to source POSIX shell scripts in order to bring my functions and aliases to remote servers and containers.

              1. 2

                From my experience, 90% of shell functions and aliases can (and should) be rewritten as standalone scripts. Unless you indeed modify the current shell’s environment or even the argument handling (like noglob in zsh), there is no reason to hoard functions.

                1. 1

                  Funny; I did just that mere hours before you posted your comment. Took three commits to my dotfile repo (1, 2, 3).

                  There is one other benefit to using shell functions and aliases: it’s easy to view them all at once by running functions && alias; the result can be written to a file, giving you a single file with all your custom commands.

                2. 1

                  That’s a different use case, yeah. For me, I have two computers I ever interact with, so.

                  1. 1

                    Yeah, that’s unfortunately why I have to use bash at work even though I use fish everywhere else. Sad; fish is way nicer for shell scripting.

                3. 5

                  I switched away from Fish, despite much preferring its obviously better syntax and other UI improvements, because I still had to work with old bash and posix shell scripts day-to-day anyway.

                  1. 4

                    For the folks in this thread who found Fish was not compatible with their POSIX scripts: do you have a lot of functions that modify your shell’s state/environment, then? For me that’s limited to a few scripts related to virtualenv, changing directories, and setting the prompt. The other 95% does just fine as standalone scripts with #!/bin/sh as the hashbang.

                    To avoid misunderstanding, I’m not really asking “why do/don’t you use X”. It is me wanting to see all the things folks do with their shell that could not be done as a script, so please Share All The Things That Come Under That Heading And That You Feel LIke Sharing :D

                    1. 3

                      The biggest offenders are the version-switchers for various languages–virtualenv, chruby/rvm/rbenv, nvm, etc. For some of these things, there are fish equivalents, but it remains a point of friction.

                      The other annoyance with fish is that any time I have any problem with a shared script at work that works for everybody else, everyone assumes fish is the problem (which is rarely-to-never the case).

                      But it’s still a great shell and I continue to use it.

                    2. 4

                      I’m just writing scripts for zsh or a non-shell language when I want to do more than one thing.

                      fish has made 99% of my interactions at a shell prompt ‘just work’ with practically zero config, learning curve, or slowness.

                    3. 4

                      I use fish and have been happy with it. I don’t use any of the plugins for it, mostly because it’s good enough out of the box for the simple shell stuff I do.

                      On occasion I have used bass to work with bash scripts that were required by projects I had to work on. It runs bash scripts and exports environment changes back to your fish session.

                      1. 3

                        Damn, I’ve been wanting something like bass for years, thank you!

                      2. 3

                        The top two comments in this thread sort of justify Oil:

                        Using fish really made my life better

                        I switched away from Fish (after using it for several years) because I couldn’t get used to it’s non-POSIX syntax

                        In other words fish is great, but it’s not compatible.

                        I wrote about this a bit on the blog:

                        http://www.oilshell.org/blog/2020/02/recap.html#fish-oil-is-a-good-idea-link

                        https://news.ycombinator.com/item?id=22213001

                        Of course it hasn’t happened yet, but I found an interesting project ble.sh that creates a fish-like UI in pure bash!!! Hopefully that will help us figure out what the right API is.

                        https://github.com/akinomyoga/ble.sh (check out the screenshots)

                        1. 4

                          The incompatibility is one of the best features of fish. That’s part of why it’s so divisive.

                          1. 2

                            Oil is trying to get the best of both worlds. It’s compatible but it also gradually morphs into a brand new language:

                            http://www.oilshell.org/blog/2020/01/simplest-explanation.html

                            Basically the thesis of the project is that bash/POSIX sh will always exist regardless how how popular fish or any other shell is (and they are very popular).

                            I’m sure lots of people will continue to use fish, but there are also lots of people who want an upgrade path from bash. fish isn’t an upgrade path because it doesn’t run millions of lines of sh/bash scripts already out there.

                        2. 2

                          I use fish on every machine that I own! The only config changes I make are for one-off functions, so I love the fact that I can get something working and familiar out of the box with just an apt/brew install fish.

                          1. 2

                            Have been using Fish for many years now. Ease of use is truly amazing, and I think it’s great for beginners-experts alike. The lack of POSIX compliance does hurt sometimes, but things like bass really help with compatibility. I do miss using sudo !! though.

                            1. 4

                              I use a ctrl-s keybinding for that, which is even faster that sudo !!. You might find it useful:

                              bind \cs 'echo ''; echo Executing sudo (history -1); eval sudo (history -1); commandline -f repaint'

                            2. 1

                              I used fish heavily in the past (the fish z and fzf ports are mine), but did a shell config bankruptcy and am now on vanilla bash with just the Starship prompt. I found that I’m really not missing much from fish. Fish does have pretty nice syntax for writing plugins, I can’t imagine writing auto-completion for Bash.