1. 11

The fish shell seems like a remarkably solid scripting language. I’m wondering, does anyone know of any projects that use fish for scripting, rather than bash/sh scripts?

  1.  

  2. 6

    I don’t know fish very well but, pardon my asking, why?

    There’s a commonly held belief that one should at least think long and hard about using a more established programming language rather than trying to code in the shell. This feels like an even longer slide down a slippery slope.

    Or am I missing something about fish shell’s magical-ness?

    1. 13

      Yeah, the only reason anyone ever writes scripts in shell is that it’s guaranteed to already be installed, which isn’t true of fish.

      Plus the I in fish stands for “interactive”; like … that’s very clearly what it’s designed for.

      1. 4

        [T]he only reason anyone ever writes scripts in shell is that it’s guaranteed to already be installed

        This right here.

        Fish is very much something I would install on my personal laptop, but on the environments where I run a lot of shell scripts, it’s either bash or a higher level language like Python depending on the complexity.

        1. 2

          Personally another reason I use shell scripts is cuz there are nice primitives. Every machine I use has Python 3 installed, but subprocess.Popen isn’t the funnest interface.

          I would love to have a shell script language that is fun to use and isn’t Powershell

          1. 1

            Yes, process management in your average language sucks compared to bash. That’s why you can find libraries for $YOUR_LANGUAGE that do it significantly better than the standard library of that language. In your case, google for “python shell scripting library”.

            If you are like me and believe that if something is too frequent it should get its own syntax and in general prefer a language built ground up for this type of scripting, you are welcome to try Next Generation Shell (I’m the author).

          2. 1

            Yeah, the only reason anyone ever writes scripts in shell is that it’s guaranteed to already be installed, which isn’t true of fish.

            I don’t really understand what the problem is here. OK I do not work with servers in my daily job but I’m pretty sure that most people do install some software first on those machines. Why not add fish to the list of web servers/JS packages/Python packages/etc…? I mean who runs their system bone stock (except on OpenBSD ;) ) so what’s the problem with installing fish?

            1. 4

              There is a spectrum, but with four important points:

              • Installed everywhere (in the default install). This basically means POSIX shell for *NIX systems.
              • Almost always installed, not necessarily by default, and small. Things like bash are in this list.
              • Not always installed but a simple package with no dependencies and so low friction to install. Something like Lua is a good example here.
              • Not always installed and brings in a messy load of stuff with versioning problems. Python is the common example here.

              Each step in this list adds some potential friction and so should come with some benefit. There are some nice bashisms that make shell scripting easier and bash is pretty easy to install on any system that has a POSIX shell, so it’s often worth using !#/usr/bin/env bash instead of !#/bin/sh for your shell scripts. Using a real programming language such as Lua has some bigger benefits but means that users probably need to install it.

              Something like fish or zsh is in an interesting place because it’s as much effort as installing a programming language such as Lua or Go (easier than one like Python or Ruby), but generally the uplift in functionality relative to POSIX shell or bash are fairly small.

              If your scripts are really scripts (i.e. mostly running other programs) then a shell scripting language may be a better fit than a programming language, but now you need to think about how much easier fish is than POSIX shell or bash and whether the benefit outweighs the additional friction for users.

              Note that the friction also implies to security audits. If someone is deploying your software in a container and it depends at run time on a scripting language, then that language implementation is now part of your attack surface. Things like Shellshock showed that bash isn’t always a great choice here, but it’s probably already in the attack surface for other things and so will be on the list of evaluated risks already. The same is true of something popular like Lua or Python (though that may not be a good thing as it may already be flagged as high risk). Something like fish will likely trigger extra compliance processes.

              1. 3

                It’s not that there’s a problem with installing fish; it’s that if you’re going to bother with having prerequisites, you’ve just discarded the one advantage shell programming has over regular programming languages.

                1. 2

                  Bit of a chicken and egg problem though, you have to install those interpreters and what would you install it with?

                  At some point you’re interacting with the OS primitives. The most elegant thing at that level is sh so you’re already using it.

                  1. 1

                    But is it really the most elegant? Or just lazily more convenient?

                    1. 1

                      Usually those are the same thing.

                      Ultimately there will always be some shell running. The only way to get around that is ansible (and some kind of priming system) or — well arguably it can get a lot more more complicated to do very simple things.

                      Maybe someone should make a Linux distro with fish under the hood?

                    2. 1

                      At some point you’re interacting with the OS primitives. The most elegant thing at that level is sh so you’re already using it.

                      Huh? In POSIX systems, the system libc function invokes a shell, but [v,pd]fork / clone + execve doesn’t go anywhere near the shell and these expose things that the shell does not. Any higher-level language that exposes the process-creation system calls directly will give you more control than the shell and will not depend on the shell for anything.

                      Unlike VMS or DOS, the shell is not in any way special on a *NIX system, it’s just a program that talks to a terminal (or something else) and does some system calls. This is why things like fish can exist: the program that you use for sitting between you and the operating system’s terminal facilities can be anything that you want.

                2. 12

                  I wouldn’t say fish is magical, it just seems like a small, sane shell language with fewer thermo-nuclear footguns. On paper it should be an ideal candidate for project automation and general scripting.

                  EDIT: I guess my point is that we often treat perl/ruby/python as “a better bash”, while it seems to me that fish should be a candidate for the same role.

                  1. 2

                    From a strictly technical standpoint I can see where you’re coming from, but think about this in terms of commercial viability.

                    You do what you’re suggesting and create a pile of snowflake Fish shell code to run the company.

                    You then leave a year later for greener pa$$tures, and the next person inherits a technically superior codebase which sadly resolves into a perfect black hole of sadness and despair because NO-ONE anywhere uses this tool this way and NewPerson is totally, UTTERLY alone.

                    1. 2

                      Yes. Easier to use correctly. If bash is a quoting hell where the right thing to do – using arrays – is awkward, fish trivializes both: Compare "${array[@]}" (bash) with $array (fish): Every variable is an array and you don’t need to quote it.

                      1. 1

                        Being not POSIX compatible, fish shell scripts and bash scripts are not compatible.

                        This was a deliberate choice to be better for interactive use, which makes fish an immature and non appropriate choice for a shebang.

                    2. 6

                      Fish appears to be less powerful than bash, althoug arguably the syntax is nicer. Some criticisms here:

                      https://github.com/pirate/fish-utils/blob/master/README.md

                      I have never seen a project that uses fish for scripting .. it seems to be more of an interactive shell.

                      1. 4

                        I think that Bash and Shellcheck may yield a better result than Fish. Fish is an awesome interactive shell, but I wish it was a Bash-compatible syntax. Maybe consider Oil or NuShell as well if you’re looking for an alternative?

                        1. 4

                          Fish is definitely nice but for non-interactive shell-like scripting, I’d recommend Tcl.

                          1. 3

                            I use fish personally but never for my work projects because I don’t want to have to install it on my server/Docker instance/CI space/whatever. Bash isn’t great but it’s more or less everywhere except Alpine Linux.

                            1. 1

                              And if you restrict yourself to Dash, you can write scripts that run on alpine and everywhere else there is bash.

                            2. 3

                              I wrote a small break reminder program in Fish, mostly because I could. Scripting in Fish isn’t too bad, though I generally prefer not to use any kind of shell language for that.

                              1. 3

                                Fish is an interactive shell and not intended to be a replacement for sh. If there are any projects depending on fish I would probably stay away from them. :-)

                                1. 2

                                  I’d urge you to take a look at Oil, which is being designed to solve the problem of a better shell language for scripting purposes. And let me know if you figure it out…

                                  1. 2

                                    I have used it at work for completely personal things. While it is immensely preferable to bash in that it has fewer foot-guns, I often miss things like the ${var%%.*} trick. Using psub for process substitutions is OK but it seems like it is harder to do really complex redirections. Overall, if it were already installed everywhere I would be using it instead of bash every time, until things got to a place where I would be more comfortable using Python. But it isn’t already everywhere, so when I need more than a few dozen lines of straightforward bash, I do use Python instead.

                                    1. 1

                                      I’ve been using fish for years, and its scripting language is better than sh/bash, but as others have pointed out, fish scripts wouldn’t be suitable for sharing since most machines don’t have fish installed. Instead, I have lots of personal scripts and functions. I think if you’re looking for a better sh/bash language for shared use, you might as well move “up a level” to python or equivalent.

                                      1. 1

                                        Mostly meta projects like fisher and plugins.