I switched to fish shell with star ship. Fish has autocomplete and syntax highlighting out of the box which is quite neat and the main features I use in omgzh so fish was a safe choice for me
Fish is also not POSIX which has always been its, and my, issue. I use zsh+starship and my own very minimal init stuff+zsh autocomplete and syntaxhighlihg plugins. It’s not a perfect setup. I wish fish would “just work” but it doesn’t. Frequently I had to look up for “workarounds” for my setup. 25 years in, I think I got it and i just keep my zshrc and `machine-init.sh` on point for my-own-style-experience. I think a lot of that could be simplified with fish+starship, but it’s just not there.
> Fish is also not POSIX which has always been its, and my, issue
Could you give some examples of issues you encountered because of that? I've been using fish for about 8 years now I can't remember an instance where that was a problem in interactive use.
Same here. More than 5 years with fish and it’s been like 5 times when not-POSIX was an “issue”, which I’ve been solving by temporarily entering bash and rerunning the command there.
Issue is the cognitive overhead to know 2 distinct shell languages. One you use, and one (almost) everyone else uses. If later isn't of your concern and Fish is all you interact with then no issue whatsoever for interactive or/and scripting use.
Not to be funny, but is POSIX scripting even still relevant? It's well understood that they should only be used for quick and simple tasks, and anything more serious or demanding should be done using something like python instead. But these quick and dirty tasks are very easy for LLM coding agents to do in python. I used to have dozens of shell scripts, each no more than tens of lines long, in my ~/bin/, but I had an LLM rewrite all of them in python, adding proper argument handling, --help messages and error handling too in the process. I sincerely don't think I'll ever write another bash script again.
Do you know how many CI/CD pipelines run on shell scripts?
Another example is small utilities. I wrote one to login to MySQL DBs at work. We have to use Teleport, which I dislike, and it has MFA. So I made a small SQLite DB that has cluster names, endpoints, and secret ARNs (no actual secrets, only metadata), and then wrote a shell function that uses fzf to parse the SQLite DB contents, then ssh tunnels through an EC2 with Teleport to the selected MySQL DB, using expect with a call to 1Pass to answer the password request, and then picks the first available port >=6033 to connect the mysql client. It also tracks the MySQL DB : port assignments in the SQLite DB and waits for the client to exit so it can tear down the ssh tunnel. The only input I have to do beyond selecting the DB is answering a push notification on my phone for MFA.
> replacing 10-LOC shell scripts with Python
The startup time would drive me insane. I love Python, but it’s not great for stuff like that, IMO.
For me it’s always been an inability to “copy this command from stackoverflow” (or in the modern day, it’ll be copy this from ChatGPT) into your shell. Maybe it’s better now, but the last time I seriously gave fish a chance was 2014.
Also one of may main use case is documenting things other developers can do to make their life easier. There are handful of things where zsh behaves differently than bash. And while those handful of thins are not even a POSIX or shell things, they often come up.
The reality is, every day I’m fighting with “developers” who don’t know what the difference between AWS, Linux, and bash is. Throwing “fish” into the mix seems like I’m just being obtuse for no reason. I have sept hours trying to explain to some dumbass that git-bash on windows is not the same thing as Linux only for them to call me “oh he really cares about ‘bash’”-guy. While claiming they are “Linux developers” as they use macOS.
I confess I don't really get this. Fish and Bash are different languages in the same way that Ruby and Perl are different languages. And if I want to run a Perl script, I don't try to run it in a Ruby interpreter, and I don't get grumpy at Ruby for not being source-compatible with Perl.
Which is to say, if you need to run a Bash script, run it via `bash foo.sh` rather than `./foo.sh`. There's no need to limit yourself to a worse shell just because there exist some scripts out there written in that shell's language.
There's nothing even preventing the second form from working either. Just put the right shebang at the top of the script and it'll run through that interpreter. I've been on fish for a decade, but still write all my shell scripts in Bash. It's never been an issue.
Yeah. I used zsh for decades, invested a reasonable amount of emotion and time in my config but swapped to fish last year as a sort of January trial and it stuck.
It's not perfect, the lack of HEREDOCs are annoying sometimes, and no background-able blocks (eg `{x}&`) means you can't async things as easily in scripts.
Zsh has a lot of advanced stuff (at least for a shell) that can deliver pretty complex scripting such as throw/catching, mountains of variable flags and switches which I do miss when I write fish scripts but really -- I've abused them a lot over the years and now days I would be more likely to just use a "builds to a single binary" language.
I will probably swap to nushell when it gets a bit more stable (in my experience it's runtime is stable, but it's feature set / command names are still shaking out. I really like it's general ideas though in terms operating on structured data.
https://ruky.me/moving-from-zsh-to-fish-nixos-darwin/