Hacker News Reader

Comment by ddek | Hacker News Reader

So the massive drawback of fish is it's incompatible with bash (and other shells people use). If you're in fish, this is easily remedied because almost every machine has bash too. However, you can't expect another machine to have fish.

However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily as I flit from TypeScript to C#. To me, this is largely a non-issue, aside from when I need to work out how to set the `$SHELL` variable for a program that expects bash.

View on HN

I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it.

Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.

The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.

e.g. making bash scripts compatible with current macOS systems (outdated bash version and bsd-ish non-gnu binaries) is a far bigger pain than any compat issues fish brings.

> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases.

every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

so, i say it applies to essentially every use case where you didn't already know how to do it.

I love fish, but the fact that every answer to your questions is written in another language and has to be translated affects EVERYONE.

> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

I don't get this argument: The solution is to search for:

"how do i accomplish X task in fish"

This is what I do with xonsh.

Of course, the bigger point that is being missed is that when someone opts to use a shell like fish or xonsh, they're less likely to search how to do X! The reason they picked another shell is often because it is easier to use, etc. In the case of xonsh, it's mostly just Python. I do a lot more in it than I could do in bash, because I don't need to search the Internet for anything.

I've been using Fish as my primary shell for years. The vast majority of the time those Stack Overflow answers written for Bash work as written in Fish with no changes.

Occasionally you'll need to write the command substitution or command chaining in a different way, but once you get over the initial learning curve this is easy and pretty mechanical.

Very rarely I find some command that just doesn't work in Fish, in those instances it's easy enough to open the bash shell or throw it into a script file.

> every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash.

Those answers, imo, come in 3 forms:

1. Short simple bash commands that will work in fish

2. Overly clever "one-liners" that would be better as a script

3. Edge cases.

(3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.

> The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on the user's system.

It's a huge problem if you have stuff that is expected to be sourced into the shell rather than executed as a script., for example, because the sourced stuff provides a large API of functions.

In my experience, the only time I do this is with files that have been provided explicitly for my shell of choice.

The only exception to this that I see regularly is shell installers auto-adding some directory to the PATH env by making automated changes to bash/zsh confs in $HOME. This may be a slight annoyance for some, but tbh I like it as having to manually paste in a PATH addition myself allows me to audit them (and it's still quick enough).

About 98% of common POSIX shell usage is covered by fish, right down to identical syntax. (Not everything is.)

Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.

> Biggest tip for fish switchers: set fish as your terminal's shell instead of changing your login shell.

That's an interesting idea - I will try that. This bit me recently when I used Migration Assistant to move from a Mac with Catalina to one with Big Sur; my login shell was still set to the path for fish installed via Homebrew, but none of those packages were copied over. I managed to hack around it by copying bash into that location so that I could reinstall Homebrew and fish to finish repairing things.

IMO it's worth it to avoid Relocated Items popping up after every update.

If you do this, you will probably also want to add `-fish` to Terminal's preference Profiles > Shell > Ask before closing (*only if there are processes...). This will prevent you from getting prompted when closing a Terminal tab with the default shell running.

I just start fish from .bashrc:

https://github.com/pkulak/dotfiles/blob/master/.bashrc

I did that, but this makes it far more difficult to use bash if you need to.

To use Bash in such circumstances you just exit Fish via ^d or type exit. The bad thing about is you execute a Bash shell which uses resources. But with today's RAM even on a smartphone this wouldn't matter. The convenience and safety (to have a working default shell) is worth it.

You can use Fish on any system where Nix runs on, btw. For example, I use it on Synology's DSM.

I just type "bash".

what's the difference between the two for the non initiatives?

AFAIK, login shell can be thought of as the default shell anytime you start a shell.

By default your terminal program uses that, but most terminals let you override that to be something else.

I still fail to see a significant difference. Been using fish as my shell for perhaps 15 years.

Perhaps not having to run chsh on a new machine, which I have to run -h on to remember how to use ever few years.

The main advantage is that if you screw it up or an update borks the shell itself, it's easier to fix if it isn't your login shell. At one point I decided to set Elvish as my login shell, and it turned out to not function as a login shell. As in, won't start at all. Any time I logged in, it would just immediately exit, ending my session. Work doesn't allow us to have root access (annoying), so I ended up having to boot into single user mode to set my shell back. I've done a similar thing with bash and "set -e".

Being new increases the chances of doing something like that that breaks the shell. It's annoying to fix for those of us with experience, and extremely difficult to fix for those without experience. It gets even worse when you consider that some distros like Ubuntu don't set a root password, so you can't log into the root account without sudo, which requires your user to have a functional login shell. I wouldn't want a new user to paint themselves into a corner where the only way to get their desktop working again is to remember how to boot into single user mode or boot from removable media and mount their hard drive. Doubly so if their Linux desktop is their only PC; it's going to be really annoying if the only way to write removable media to boot from is the machine that's currently broken.

Hmm, fish is approaching twenty years old and supported login the whole time. But, bugs still happen I suppose. I always kept OS CDs and later flash drives around for glitches however. Have one an old one in the tin right now.

I really don’t get this argument. In my shell I don’t type scripts on the prompt.

I use fish most of the time as a shell, but I still write bash or even sh scripts, because fish is not installed on most systems. If you run a bash script from fish, it is still executed by bash (because of the shebang).

Even something like

   # only test if the build succeeds
   ./build.py && ./test.py

didn't work in fish until recently. It used to be 'and' but they recently added && for compatibility.

I think redirects and possibly pipelines work differently in fish too, although I don't remember the details. I type those on the command line frequently. I occasionally use loops as well, though when it gets big I do put it in a file.

It looks like all of these are the same

    echo hi > out.txt
    echo append >>  out.txt
    sort < stdin.txt
    ls /bad 2>&1 | tee out.txt

But here docs don't work the same way:

   sort <<EOF  # syntax error in fish

I don't really like the here doc syntax so I guess that is pretty good. The && issue is still there on my Ubuntu Bionic machine:

    fish: Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.

ls && ls

The && syntax was added in fish 3, released in 2018.

Redirects and pipes work as you'd expect. Loop syntax is different. The difference in subshell invocation is the thing that sticks out the most: $(cmd) vs (cmd) in fish.

Piping and redirects seem to just work, command substitution is always just parentheses with no $ in front. Process substitution is not magic syntax like in sh, it's just a command that reads from stdin, writes to a temporary file, and outputs the path to that file:

vim (ls -lh | psub)

But one of the selling points of fish is (from their website, I am not a user) that it has sane scripting.

That point appealed me most. If I continue have to use bash for scripting, I wonder what fish provides over zsh.

I think fish's syntax is cleaner, though as others have pointed out, the incompatibility is often not worth it.

Even though it's "sane", I would say it's not "powerful". It's significantly less powerful than bash, e.g. there is a list of missing things here:

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

The first one seems like one of the bigger issues: https://github.com/fish-shell/fish-shell/issues/159

I have a particular viewpoint since I'm writing a shell for scripting, and I wrote this FAQ. http://www.oilshell.org/blog/2021/01/why-a-new-shell.html#wh...

But I didn't come up with that list of issues, and I've only used fish a tiny bit.

#159 kind of works with the `string collect` mechanism, although it is indeed not very obvious, compared to bash:

    set file_contents (cat filename | string collect -N)

I understand that this is purely anecdotal, but I'm using fish for quite a long time, I've written a lot of tooling for myself in fish, and I agree that sometimes there are some things which are annoyingly missing from fish (like this multiline variable thing), but I would not say it makes fish significantly less powerful. And these things are sometimes fixed, too.

For me, the main thing fish provides over zsh is nice defaults. oh-my-zsh can be incredibly slow, and without it zsh does take a reasonable amount of scripting & setup to make it as "nice" to use (which is why oh-my-zsh exists).

I think their "sane" scripting is more about ux for writing short disposable logic (the type you write in a terminal), rather than more detailed/advanced/structured programming that you might save to a shell script file.

Bash/zsh walk the line of being usable enoughh for typing terse quick commands (terminal syntax) while also being complex enough for writing large scripts (programming language). They end up being imperfect at both.

I agree entirely. I've tried zsh and other replacements, but I keep coming back to Fish. It's intelligent, loaded with features, and ohmyfish adds a lot.

No other machine I connect to has fish, but for my own machines, it's my top choice. Still, I write a lot of utility scripts in bash for the compatibility and it can be annoying when I copy a command and I know it won't work because it uses some unsupported syntax in fish. Every now and then, and it is rare, I switch to bash locally to run something.

> So the massive drawback of fish is it's incompatible with bash (and other shells people use).

This drawback is also its advantage, as it doesn't need to repeat all the Bourne-ish problems. (You seem to like this :-), just pointing it out for the others.)

I think people who are interested in how they use the command line will not have a problem to learn two shells, fish for the personal use and something Bourne-ish for scripts that might run on other machines, or by other users.

The Bourne shell certainly has problems, but IMHO fish should have stuck with POSIX syntax when it's "good enough" (TM). Stuff like $(code) vs (code) makes Fish feel like it just wants to be different.

Things I think are big problems:

* Needing to quote practically everything

* Needing to remember if/fi, case/esac, while/do/done, for/in/do/done, etc.

Same for me. And fish is so much nicer that I’m not willing to use a less ergonomic shell on the system I use 99% of the time for the benefit of having it act exactly like the 1% environments.

And FWIW, those 1% environments don’t look and exact exactly like my local system, where I have a nice prompt configured and there are lots of aliases and functions I use frequently. My local bash is nearly as different from my remote bash as my fish is from bash.

There is no need to change `$SHELL` :-/ you can use Bass (https://github.com/edc/bass) to execute any bash script and it will apply the environment variables to the current fish environment.

Bass has never worked for me. I'm not even sure if it has worked for me once.

I run Fish on all my machines as well, and it's not like it's _that_ different from Bash. Maybe just for me, since I do not use either to write actual scripts. Only thing I notice on the command line is not using a dollar sign before open parens.

I really like this combo:

1) Use fish interactively, with quite a few aliases.

2) Write <= 10 line scripts in sh, perhaps with a bashism if it is very helpful, and only run on my machine.

3) Write > 10 line scripts in Python.

If all you do is copy paste other people's bash command than sure, stick to bash. The 99% of the time you're doing that you can use fish.

> However, you can't expect another machine to have fish.

I can, because whenever I get access to a new machine I download and compile it!

Well lucky you, that you always get download-and-compile rights on any machine you access. Not everyone is so lucky.

I find fish is a comfortable interactive shell and dash is a performant script-running shell. Bash is in the middle.

My biggest drawback for fish is that there is no way to concatenate several commands inside a block that I know of.

In bash, I can run the following do the following, and the only ways I found to do this in fish are using several commands or calling `bash -c` with a subcommand.

```

(cat file_1; cat file_2 | grep something) | sort

```

It's simply a block, and fish specifies blocks with "begin" and "end".

    begin; cat file_1; cat file_2 | grep something; end | sort

(note that this is distinct from a "subshell", which has a separate environment and typically is more confusing than helpful. In this particular case it doesn't matter)

Reply on news.ycombinator.com