Hacker News Reader

Comment by kungfufrog | Hacker News Reader

I used to love zsh and it's endless customisation options, it definitely felt more robust and sophisticated than bash as a shell and was my preferred daily driver.

Then I discovered fish and to be honest the sane defaults and out of the box functionality means I haven't looked back in a few years now.

If fish didn't exist, I'd absolutely still be using zsh with Zim or presto.

View on HN

I switched from zsh/oh-my-zsh to fish mostly because fish does everything I want for an interactive shell and is simply one package from my package manager.

With frameworks like oh-my-zsh I'm always worried about supply chain attacks.

I do use https://starship.rs (which is also a package away), and I think things like fisher https://github.com/jorgebucaran/fisher are useful when you need a specific fish script.

I also don't really like writing zsh scripts because I always run them through https://www.shellcheck.net which works best with posix sh/bash

What do you use as terminal emulator? I Switches from iterm2 to kitty and omz to starship. It is for sure faster now to start the terminal, even running commands has different response time, visible to the eyes.

Could I ask How does fisher come into play if you have something like starship already?

As far as I know, fish is not compatible with bash scripts ( most legacy stuff) and this makes zsh attractive.

I don't get it. Are you executing extremely convoluted bash one liners at your shell prompt?

I still write for bash and use a bash shebang to run it when I need to script. Mostly because the likelihood a colleague or whoever else comes along later happens to be using fish is pretty low. Bash remains the most portable option!

I tried fish and uninstalled it because nothing from stackoverflow worked.

Sure, I could spend time learning the fish syntax. But I won’t, since zsh works.

I see. I just dump that kind of stuff in a bash script or bash -c '...' it directly if necessary.

Still, to each his own! That's the great thing about having a glut of viable options.

I often find I write out a series of commands interactively in the shell, then decide I want to save them as a shell script, which I might then want to share.

I enjoyed fish, but found it too annoying to have to translate things into bash when I wanted to share them.

exactly, that's why im back too.

back to zsh from fish, that is.

A lot of CLIs don't ship with fish autocompletion :/

Generally my workflow when developing scripts is running individual commands on the CLI so I can see what it's doing so I can get it right. This is not possible with fish unless I start a bash shell, so at that point, what is the point? With zsh, most of the code I would run in a bash script still runs in a zsh interactive session. Sure there a few edge cases, but they're quite well documented.

Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right.

This isn't possible with bash unless I start the python repl, so at that point, what is the point?

Hey, it's possible you spend a lot of time writing scripts, and they need to be bash compatible. Zsh is great for that.

Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language.

> Generally my workflow when developing scripts (in Python) is to run individual functions in the repl so I can get it right.

As a matter of fact, this is exactly what I do when I write Python scripts too. It helps understand exactly what things do quickly and figure certain smaller things.

> Just wanted to reflect how made-up this sounds to those of us who treat sh like any other language.

What do you think sounds made-up?

I mean that "can't use fish because I have to use bash to write bash" makes about as much sense to me, given how I use the terminal, as "can't use fish because I have to use python to write python".

I'm assuming that means you write more shell scripts than I do, or think of the context switch between shells as qualitatively different from the context switch between shell and (some other) repl. All of which is fine.

From the fush documentation:

  Special variables

  Some bash variables and their closest fish equivalent:
    $*, $@, $1 and so on: $argv
    $?: $status
    $$: $fish_pid
    $#: No variable, instead use count $argv
    $!: $last_pid
    $0: status filename
    $-: Mostly status is-interactive and status is-login

Replacing «$$» with «$fish_pid»? A contentious choice at the very least – does it also apply to non-interactive fish scripts? «…use count $argv» instead of «$#» – why? Both, $$ and $#, are non-bashism's and go way, way back into the UNIX prehistoric times – hardly bash-ism's.

Fish does not appear to have basic conditional variable expansions, matching affix removals and pattern substitutions, either; i.e. ${_var:-substitute}, ${parameter<# / ##>word}, ${parameter<% / %%>word} and ${parameter/pattern/string}. Or, at least their nearest equivalent are not prominently featured in the documentation.

How often do you type these things in an interactive shell though? Also things like $status and $argv are reminiscent of csh, which also goes back a long way!

With a varying frequency but I do use them in interactive sessions:

  $ grep -c '\$\?' ~/.history
  137
  $ grep -c '\$\$' ~/.history
  30
  $ grep -c '\$!' ~/.history
  6
  $ grep -c '\$#' ~/.history
  13

Less so when it comes to affix removals… I use them liberally in scripts as well as in data transformation pipelines or more complex one-liners, though.

I also semi-frequently quit the shell with «kill -9 $$» when I do not want to pollute the shell history with garbage, which is not refelcted in the count above for obvious reasons. It is quick and efficient.

> Also things like $status and $argv are reminiscent of csh, which also goes back a long way!

Ah, I thought somebody would mention csh as the prior art! Frankly, the C shell syntax have never really clicked with me precisely because of the more verbose syntax, and, as soon as other shells have borrowed history, job control, aliases and a few other features from (t)csh, I was out of the house!

Ah right; I never do that kind of stuff.

I wonder if you can set "$$=$pid" in some hook in fish (I don't use fish, or even like it for that matter, albeit for different reasons).

Longer names like $status and $pid are actually nicer in scripts IMHO, I typically use those in zsh (which often supports for csh-ish long names and Bourne short names) scripts as it's just a bit clearer. Same with short (-q) vs. long (--quiet) flags: short is great for interactive CLI, long often nicer in scripts. especially with lesser used flags.

Yes, zsh – which has been my daily driver for more than two decades – offers the best of both worlds, long and short names for most of the useful variables, but those do not affect the [expected] core shell functionality.

I suppose, I should have made my point clearer earlier on. A UNIX shell (along with the terminal) is such a fundamental tool that a substantial departure or a paradigm shift from long standing foundational conventions or from the familiar syntax had better bring at least a tenfold increase in productivity for me – to substantiate the said departure. Then I will happily change my workflow and retrain my muscle memory to adapt. scsh is the only other shell that came close to that at some point in space and time, however, it seems to have perished into the oblivion.

A new shell with reasonable and more new user friendly defaults at the expense of missing core shell features does not reach the tipping point for me.

bash isn't compatible with python either, unless you use #!/usr/bin/python or the like.

All my shell scripts start with #!/bin/sh, so the language my user shell runs is irrelevant. Sometimes I do have to preface copypasta with "bash" and end it with "exit", but it ain't the end of the world.

There are a bunch of good reasons to prefer one shell over another, this isn't one of them.

Indeed, just use the shebang #!/bin/sh (if it's posix sh), and #!/bin/bash if you must use bash functionality. There is no reason to not use a different interactive shell.

Please use #!/usr/bin/env bash if you're using bash. It seems more common to have env in /usr/bin than it is to have bash in /bin. On BSD systems, bash is often in /usr/local/bin, and on macOS the user often has a more modern bash in /opt/homebrew/bin or other package manager directory.

> bash isn't compatible with python either, unless you use #!/usr/bin/python or the like.

You're rather aggressively missing the point.

If you need to write and maintain bash scripts but use fish as your command line, you now need to know the idiosyncrasies of both shells ...

If you want to write portable scripts and use a reasonable interactive shell, you need to know two shells anyway. Scripts should ideally be written to only use shell features defined in POSIX, since bash isn't available on every system. It's available pretty widely, but not on e.g. Alpine Linux by default, and the version on macOS is so ancient it doesn't have features like wait -n.

Unless you're going to use rlwrap /bin/dash as your default interactive shell (please don't) you need to know both your interactive shell and standard shell if you're going to write portable scripts.

> Scripts should ideally be written to only use shell features defined in POSIX, since bash isn't available on every system.

I don't write system scripts that need to run on systems without bash and have not needed to do that for a long, long time.

Ha! Funny, I just switched _back_ to Bash because I found ZSH so flakey and amateur.

I tried for years to like it, even tried oh-my-zsh, and fine tuning myself. Finally got fed up with its laggy "smart" crap and went back, and oh man am I happy I did. Everything works, it works fast, and it does exactly what I tell it to and no more.

My experience id aldo the zsh is slow compared to bash. I am using the defaults from Apple on an M1 with some minor modifcations.

On raw defaults, I find it hard to see that you can do anything with either bash or zsh where the shell itself does anything where you can even notice a delay. Things like basic file completion or history searching are basically instant. For scripting there are plenty of benchmarks out there and zsh typically beats bash but both are beaten my minimal shells like dash.

You don't need to use oh-my-zsh and "laggy smart crap" though; it works just fine without it.

I don't have most of the advanced features enabled, except that listing completion options doesn't push text up, which I found really useful after I got used to it. As well as being able to navigate it with the arrow keys. I never noticed it's slow, and I used zsh on a Pentium N-something budget laptop that definitely wasn't fast.

I think you're judging zsh based on third party add-ons or non-default config. You can make bash flaky and amateur that way too.

Stock zsh is neither though. It's quick and solid. No surprises.

Ditto with Vim/Emacs/VSCode/etc. All of them can be slowed to a crawl or be unpredictable with plugins.

Yeah, one shouldn't be judging the performance and stability of zsh based on oh-my-zsh of all things. oh-my-zsh is one giant mix of everyone's configs, which severely degrades performance and stability. It's for people who want most features out of zsh in the quickest way possible. Those who prefers an optimized config would be better off configuring zsh themselves. Even getting the autocompletion right would provide a great QOL improvement over anything bash can provide, though it's unfortunately a bit trickier to configure than is ideal.

Unfortunately, it doesn't get you most features out of zsh. It leaves a lot disabled too. It turns on the included completions, adds flashy prompt themes and a pile of aliases that you still need to learn if you want to get any benefit from them. Key bindings are largely left untouched with none of the advanced widgets.

I don't know, I mean I got rid of all that oh-my-zsh stuff and tried configuring it lean, too.

An example of the flakey feeling I'm talking about is the way auto-complete works. I hit tab, and it does a fuzzy suggestion? Then when you're done with the suggestions and picked (or not), they disappear? Or just the fact that auto-correction exists at all? Okay these things are subjective, and maybe not exactly "flakey", but they make if feel like that to me.

Interestingly, I just took _all_ configuration out and tried it, and startup was blazing fast! It looks like whatever was slowing it down is actually in my Bash configuration (which I also load in ZSH). Doesn't slow down Bash startup though, wonder what it is :P

Reply on news.ycombinator.com