Hacker News Reader

Comment by jonfw | Hacker News Reader

I used fish for a couple of years and really liked it. But I recently learned that I can configure ZSH to have all of the same auto-complete and plugins that I loved from fish. Now I have all of the creature comforts I like, with POSIX compliance

I found that while fish has better syntax than bash for most things, the hassles with incompatibility or unexpected behavior brought me much more trouble than BASH's syntax ever has

View on HN

The best reason to choose fish over zsh is that everything works so well out of the box that you stop messing with it.

I haven’t tweaked my shell config in 7 or 8 months now.

This is a different mindset from the giant zsh configs, “plugin managers” and other junk that is wholly irrelevant to using the shell. You’d think that fish incorporating a lot of functionality that zsh has would manifest as bloating fish, but, IMO the reality is that zsh’s “bloat” is pushed into user configuration and the user is tasked with making it work.

Another issue with zsh plugins is that they are incredibly slow. Oh-my-zsh makes every terminal feel like it’s running on another machine over ssh

And that delay when it updates itself is just the worst

I thought there was something in, like, Powerman10k or something, which managed to avoid that issue?

You probably mean powerlevel10k[0], although that's mostly a replacement of powerlevel9k, which is only one of the (theming) plugins that oh-my-zsh commonly handles.

As for a replacement for oh-my-zsh itself, I had good experiences with zgen[1] but the fastest I've found is zim-fw[2] which produces acceptable start times for me[3].

[0] https://github.com/romkatv/powerlevel10k/

[1] https://github.com/tarjoilija/zgen

[2] https://github.com/zimfw/zimfw/

[3] https://i.imgur.com/mPPQuyh.png

This is the framework, not the plugins.

You don't need that much plugins at all. The only plugin that I use is gitstatus, and zsh-syntax-highlight, and both of them are avoidable without loosing features.

this is probably the git plugin doing a "git status" or similar. Check the "plugins" array in .zshrc

But we have the same in the fish world (my prompt shows me which branch i’m on if my working dir is a git repo) and it’s not slow.

Hence, my issue with the "infinitely configurable" idea: once you add plugins to the mix, it feels like responsibility for the end user experience falls on no one, so the users end up shouldering that, and, worse, sometimes develop a Stockholm Syndrome for it.

For example, to me, it is _insane_ that in 2021 async prompts are not a completely solved problem. The shell should provide a mechanism to do so easily, rather than duct-taping thin veneers over syscalls via a scripting language.

Ditch omz and use Prezto with the Powerlevel10k prompt (just change the theme in the zpreztorc file to 'powerlevel10k' and restart your terminal), follow the initial prompts for setup, with "instant prompt" enabled and you'll never go back.

Thank you for this, I had somehow stumbled across powerlevel10k years ago on my "fooling around" laptop and liked it but couldn't remember how I'd gotten there. Long time zsh user here, just last week started playing with oh-my-zsh to integrate into my main system's shell environment.

It sounds like oh-my-zsh issue, not Zsh.

I use starship and it’s been pretty great and very fast.

> The best reason to choose fish over zsh is that everything works so well out of the box that you stop messing with it.

I've found that sometimes the opposite can be true (in a good way!). At one workplace, I introduced Fish to some fellow developers who until then mostly saw using the command line as a strange, difficult, and unpleasant part of their jobs.

Once I got them started with Fish, they were happy enough with default interactive behaviors, convenient documentation, and simple scripting syntax that it encouraged them to do a little more scripting, and eventually to customize some of the aesthetic stuff by writing custom prompts!

It was pretty cool to see.

I use fish. I haven’t tweaked my shell config in 9 years

> The best reason to choose fish over zsh is that everything works so well out of the box that you stop messing with it.

This is such an incredibly odd perspective to me. I use zsh and have not touched my shell config in years. Messing with configurations to get things working to your liking is a one time thing. I don't even use plugins.

On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible. You are forced to give up and use something else. Your reason to choose fish is only a good reason if you already agree with every minute choice the developers made and refuse to let you adjust.

> On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible.

What do you want to do that isn't possible? I also haven't messed with it in months if not more (fish in my case, not zsh) but years ago I messed with the prompt a lot to get it to my liking. (From a previous zsh config.) It was perfectly possible.

> On the other hand, if fish doesn't work to your liking out of the box, and for many people it does not, there's no "messing with it" that's possible. You are forced to give up and use something else. Your reason to choose fish is only a good reason if you already agree with every minute choice the developers made and refuse to let you adjust.

Which part of fish makes this impossible? You can tweak the startup, the completions, the key bindings, the prompt, and so on.

Even less ergonomic shells like bash can work very well out of the box if you just train yourself to use them. If you train yourself to use bash without any plugins, you'll be strong on any machine without any config.

I went through a "distro hopping" phase at some point with Linux and ended up settling on a system with very little custom config. It's close to the defaults so I can work very comfortably even in a random server.

Of course this is not ideal. If you have a tool or set of config that you like, then you should use it. I've just found that the human brain can overcome bad UX quite well with a little effort ;)

There are other benefits to your approach. Relatively little time is spent configuring software and it tends to be easier to copy over a handful of simple configuration files than to replicate a complex setup.

Put your configuration for stuff like this in a private github repo.

What I do on Linux is keep bash with a minimal config, and then have zsh with oh-my-zsh and all the other goodies. I used bash for a long time, so I don't get too confused by context switching.

Not to mention the speed of fish vs zsh launching is quite noticeable, zsh taking a second or so longer to launch

I moved from bash => zsh => fish. I wanted reasonable features on my shell, and fish was much faster and needed almost no plugins.

The fact that I can write a simple for loop without needing to look up how to do it by far beats the POSIX compatibility, if I need it I can still write a bash script, but when using the shell I don't need to recall where semicolons or `do`, brackets (and how many) go.

Is it that hard to remember a bash for loop?

  for i in $(seq 1 10)
  do echo $i
  done

Then you can just replace new lines with ; if writing a one liner.

  for i in $(seq 1 10); do echo $i; done

I guess it isn't as simple as python

  for i in range(10): print(i)

but it's pretty close aside from the variable binding.

  for i in {1..10}

In zsh you can avoid the do if you have a single instruction:

    for i in {1..10}; echo $i

to me is as clear as the python version. Very compact and useful for one liners.

Bash has some subtleties around loops that can be frustrating, like the body of your loop _may_ actually be running in a subshell (common when iterating over a file), making it difficult to extract what you want from it.

i bet it's the `cat file | while read …` loop what you are referring to, not any loop. but correct me.

As someone dealing with new remote machines on a daily basis, I cannot fantasize about any other shell. Bash is pretty straightforward.

And look at all of those finger bending symbols!

> I moved from bash => zsh => fish

Did the same, but moved on.

Now it is: bash => zsh => fish => nu

What did you prefer about nu?

Working with tables of data feels more right, more like programming then the usual shell. I also work quite often with CSV and it's nice to be able to manipulate/filter it like any other data that nu is able to read (just: open file.csv | find "foobar" | select name message).

Not quite a straightforward as nu seams to be, but I used to have ipython as my shell when I did a lot of work with CSV. It’s “not a shell” but includes some shell like functions to make listing dirs and such easier.

I don't get why people expect POSIX compliance from fish. Your interactive shell and your scripting shell can be, should be, and often are, different.

I use bash as my default user shell, fish as the default shell of my terminal emulator, and I write scripts for both POSIX sh (dash and busybox ash) and bash. I end up using three different shells with different purposes.

Sure, I could use zsh both as an interactive and scripting shell but I don't have the time or willingness to configure it when fish offers a nice out of the box experience. Not to mention that zsh shouldn't be used as a scripting shell in the first place.

> Not to mention that zsh shouldn't be used as a scripting shell in the first place.

Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?

It's more "why not write scripts?" Actually making use of a shell's control structures is code smell until we have far better shells than we currently do. They're optimized for user interaction, not necessarily anything else.

If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky.

I know what you mean, though. Most shell languages don't feel like flexible, expressive programming languages in the way that they ought to and could.

As you may know, there are some new shells/languages that are trying to bridge the gap in a way that still leaves the shell well-suited to interactive use. The Oil shell wiki has a great list of them (and Oil is one such shell itself, of course): https://github.com/oilshell/oil/wiki/Alternative-Shells

> If you're gonna be calling a lot of external programs and interacting with files a lot, non-shell scripting languages tend to feel pretty clunky.

Perl's actually pretty good here; I'm pretty new to it, but it's generally what I reach for when I feel like a bash script has gotten just a bit too complicated.

Perl definitely is the sweet spot. Even then, I think python with multiprocessing and the pipe class is better than bash in some circumstances.

If all you're doing is `a | b | c | d` then use bash but if you're pulling stuff out of the middle in a loop, yeah, might want to use a real language.

> Why not? If I'm writing scripts for automating configuration on modern macOS, for example, where ZSH is installed by default, why not write ZSH scripts?

I guess there are two reasons

- if the script doesn't need arrays, POSIX sh (dash) scripts will be much faster than bash/zsh scripts

- if you do need arrays, bash is vastly more ubiquitous than any other shell on the planet right now (except POSIX sh). It's installed on almost all Linux distributions by default. I'm not gonna use a ZSH script because I'd have to install ZSH, which seems unnecessary. A good example is tomb, which is a ZSH script for encryption on Linux.

If you're sure that your scripts will always run on macOS, use POSIX sh if you don't need arrays and ZSH if you do need them.

Good advice, thank you..

Exactly this.

I script in bash (though I'm super interested in oil), and use fish as my interactive shell, it's pinned to screen 0 in my screen session.

Then you have to learn two languages. And switch from one to another when you need to do some scripting.

I don't write shell scripts a lot, I prefer to write python scripts (that are more maintainable and simple to write). But I write complex commands in the shell a lot, for example I may need to convert a bunch of images from one format to another, just use a for loop with imagemagik directly from the command line, then maybe a regex with sed to rename them, and done. It's not rare that I write commands that are more than 5 lines long.

With all the quirks of POSIX shell scripting languages (well in reality I use zsh that is nicer) they let you hack things together fast, and that makes them powerful.

> Then you have to learn two languages.

Why would I need do to that?

> But I write complex commands in the shell a lot ... It's not rare that I write commands that are more than 5 lines long.

Ah, well, yeah, in that case, you might wanna stick to ZSH. I don't write complex commands on the shell. If it's more than 1 line long, I will make it a script. Multiple lines of commands with, or without, backward slash separators look ugly and unwieldy to me. A text editor like vim would do a far better job handling those 5 lines instead of an interactive shell.

For what it’s worth, as another long line she’ll user, I actually do write those in some combination of the terminal and C-x C-e bringing up my nvim.

Right, as I said, writing multiple lines of commands on a shell doesn't really make sense because it's not interactive usage, it's scripting. And scripting should be done using an editor, which is what you're doing by using nvim to write the command.

> Then you have to learn two languages. And switch from one to another when you need to do some scripting.

The more languages you know the more valuable you are. I prefer to only write golang but sometimes that leads to typescript, Makefiles and bash scripting as well.

I am a fish shell user, but for me the biggest drawback is that a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish`.

> ... a lot of tools rely on updating bashrc as part of installation and some of them don't have an equivalent `config.fish`

such as?

For example, Macports puts its installed binaries into /opt/local/bin (and sbin), and the installation process put this into my .profile:

  # MacPorts Installer addition on 2016-07-01_at_00:46:04: adding an appropriate PATH variable for use with MacPorts.
  export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
  # Finished adapting your PATH environment variable for use with MacPorts.

And I had to put the fish equivalent of that into ~/.config/fish/config.fish myself.

Umm, you don't need to define your PATH variable in `config.fish`, not unless you make it your default login and user shell.

You should keep using bash as your default login and user shell, define your environment variables, like PATH, in your `.bashrc`/`.bash_profile` but use fish as the default shell of your terminal emulator. In that case, fish should pick up the PATH from bash.

That addresses only the part of setting up PATH variable. Some init scripts go beyond that and have additional code embedded in them (see sdkman, pyenv). These needs separate init scripts for fish users. Just a cursory look at github issues can show how prevalent this issue is:

https://github.com/search?q=fish+support&type=issues

Python venv works fine with fish shell for me. But yeah, this is something that'll always be an issue with fish simply because bash is more widely used.

Unlike what some people may think, it's not just about the tool itself but its ecosystem as well.

Interestingly I moved from such a zsh setup to fish a couple of years back. Zsh with add-ons was noticeably slow compared to fish and syncing the config to all the devices I used.

ZSH plus oh-my-zsh cd’ing into a git repo with large LFS files will hang your shell even on very fast NVME storage.

That’s the git plugin doing it’s thing. You can fix it in config but I admit is an annoying default.

You can get reasonable version control integration from zsh without any kind of wild oh-my-zsh config. Most distributed versions of zsh are compiled with vcs_info enabled.

    autoload -Uz vcs_info
    zstyle ':vcs_info:*' enable git hg
    zstyle ':vcs_info:*' check-for-changes true
    zstyle ':vcs_info:git*' formats "%{$fg[cyan]%}(%{$fg[green]%}%s %{$fg[blue]%}%r%{$fg[cyan]%}:%{$fg[green]%}%b%{$fg[yellow]%}%m%u%c%{$fg[cyan]%})%{$reset_color%} "

    setopt prompt_subst
    export PROMPT="%{$fg_bold[red]%}%n%{$reset_color$fg[white]%}@%{$fg_bold[green]%}%m%{$reset_color$fg[white]%}:%{$fg[cyan]%}%1~ \${vcs_info_msg_0_}%{$fg_bold[white]%}%(#.#.\$) %{$reset_color%}"

I found that all I really wanted to show was the current branch, which I do with https://gist.github.com/ivan/79de5e87210e8cf21e305bb4c30c436...

You can do this in fish with a direct call to git branch, and it’s not slow and doesn’t require catting files:

  set -l git_branch (git branch 2>/dev/null | sed -n '/\* /s///p')
  if test -n "$git_branch"
    echo -n -s (set_color yellow) "<$git_branch>" (set_color normal) " "
  end

Any suggestions?

I’ve recent switched from vanilla bash to ZSH. I mainly use oh-my-zsh and Power10k. Once again the defaults without much customization.

I prefer prezto to oh-my-zsh for performance reasons.

https://github.com/sorin-ionescu/prezto

My only plugins are zsh-autosuggestion (https://github.com/zsh-users/zsh-autosuggestions) zsh-syntax-highlighting (https://github.com/zsh-users/zsh-syntax-highlighting) and zsh fzf-tab (https://github.com/Aloxaf/fzf-tab) its been wonderful using these plugins

Slimzsh[1] is a very nice default configuration. Just a slim prompt, fast-syntax-highlighting and some vanilla settings.

I keep a personal fork with a few added plugins (most notably zsh-autosuggestions and ssh-agent). No need for a plugin manager.

oh-my-zsh is way too bloated. But it's a nice repo if you're looking for plugins and aliases.

[1]: https://github.com/changs/slimzsh

The popularity of OMZ with the performance issues and update nags really makes me wonder if people even notice or care about those two things.

If you use just a few plugins, it's really not that slow. But if you have a lot more, performance might become a real issue.

zinit did wonders for my config, would highly recommend:

https://github.com/zdharma-continuum/zinit

Better to use zgenom, it supports almost every plugins and faster.

I just start scripts in bash for compatibility at the beginning or use scripts that state it, avoid scripting as much as possible, and I spent a lot of wasted time with configuration of zsh to get most of the functionality of fish but never as good. What did you install?

This is my problem as well. I’ve been using fish for quite a long time, and I’m still frustrated by weird posix incompatibility.

bass can be helpful for some of those posix issues:

https://github.com/edc/bass

Another random tip: python virtualenv generates a activate.fish script that you should use instead of the plain activate script.

Bass has never worked for me, in any scenario. I'm curious to see how you use it. I have never successfully been able to feed it any bash script. At this point I suspect I'm either holding it wrong or it is a thing that is invoked as a thing that works without ever being used in earnest.

bass works for things you're meant to source. If the script is not meant to be sourced, just run bash yourscript.sh .

It basically runs the script in bash, diffs the environment, and applies the environment changes to your outer fish shell. I use it for some internal tools, and previously used it for nvm though I moved from nvm to fnm now which has fish support.

Hadn't heard of fnm before, thanks. Seems worth checking out.

If your bash script has a shebang you shouldn’t need bass at all. Fish will read the shebang and just run your script with bash.

The only thing I ever used bass for was this edge case where at work the way we login to AWS is using this Okta AWS integration that prints out a list of export commands.

Since fish isn’t compatible with bash export commands, I just run that command result through bass, which automatically converts them to the fish set -x commands.

If I remember right, I think the reason why the bash script my company made didn’t work is that the export commands that were run in bash weren’t propagated to the underlying fish environment. I was using fish to run a script with a separate shell, so it didn’t affect my environment variables.

Or maybe it was because running exec inside a bash script throws you back into fish which then can’t understand the export command.

I could have definitely done my own thing with sed/awk instead, but I suck at those tools and someone else already implemented the functionality in bass.

    bass exec aws_okta_thing_that_prints_export_commands_to_stdout

(Off the top of my head, I think it was something like that, could be misremembering! And by this comment you might be able to tell that I’m far from an expert on how everything works.)

> If your bash script has a shebang you shouldn’t need bass at all. Fish will read the shebang and just run your script with bash.

Shebangs are actually handled by the operating system kernel! I only know this because certain kinds of shebangs work on Linux, but not on other OSes

That’s pretty neat information! I honestly barely know how all the pieces come together.

I was kind of hoping my comment would bait some OS person lurking on HN into really explaining interpreter directives, hahaha

>I’m still frustrated by weird posix incompatibility.

Can you also share what are the most significant problems with posix incompatibility for you? Why is it a problem?

The one I see is really, all of Linux vs OSX/MacOS. And which version of Bash is shipped by default.

Internally we have a boot strap run book developers/operations to bring up either Windows/WSL or MacOS to a consistent shell env.

This shouldn't be an issue! Shell scripts begin with e.g.

    #!/usr/bin/env bash

which means the interactive environment is irrelevant. Users of nonstandard shells like fish need to learn a bit of on-the-fly translation if they expect to copy/paste into their terminals, but it isn't too onerous.

Not going to ping my coworker that deals with this (Happy Thanksgiving), but the version shipped with OSX was several versions behind Linux.

I just checked it on my Mac and my Ubuntu server.

MacOS has version 3.2.57(1) Ubuntu has version 5.0.17(1)

Apparently Apple cites license concerns as the reason for not upgrading it. Don't know how valid that is.

License on version 3.2.57 is GPLv2 License on version 5.0.17 is GPLv3+

It's simple enough to update if you use homebrew.

`brew install bash`

Add the brew version of bash to the /private/etc/shells and change the shell.

That's basically one of the developer setup steps, in addition to running through installing things like jq and yq. Point is, it was a significant enough of a delta (easily fixed) that we ran into compatibility issues with the scripts we wrote.

Honestly, I think it’s just fighting years of muscle-memory more than anything. Not necessarily a valid complaint, I know.

Sadly this is the exact reason I switched away from it. I couldn't copy/paste in commands from coworkers or use common web projects (I'd have to either search for a fish replacement or convert it myself... Or just launch bash/zsh).

Really nice shell though, I hope it gets more traction.

Same, I used oh-my-zsh, I mucked around and didn't use it for some years, but since re-installing it, I have to say it's one of the most useful and reliable software packages I know of.

I kind of forgot that even use it until I read your comment :)

zsh is not POSIX compliant and never had a goal of being POSIX compliant. (Amusingly, I use bash and I can pretty much replace “zsh” in your claim with “bash” and have it apply to my usage-except in this case it would be true :P)

zsh has a POSIX compatibility mode, but it is not enabled by default. (You can see some details in the release notes: https://zsh.sourceforge.io/releases.html)

Came here to say the same. The default zsh config in Kali has some pretty nice autocompletions, which I've borrowed and use on all my other systems.

It is understated how powerful and ergonomic ZSH is.

I hated Apple, but my opinion changed when I learned how to configure ZSH.

POSIX compliance has never brought me any issues, if I want bash syntax I just use `bash -c COMMAND`. You can invoke bash scripts with `bash SCRIPT` or just add the bash shebang `#!/bin/bash` to the top of your script, set the executable bit and invoke directly.

Reply on news.ycombinator.com