Hacker News Reader

Comment by oersted | Hacker News Reader

I've used Fish for many years, but frankly only for the great autocompletion. The streamlined theme/prompt system and oh-my-fish plugin management are quite nice too, but minor.

The rest of Fish features that are not bash-compatible are rather a pain, particularly environment variable management. In principle these features have a better design than in bash, but not that much better, and their use is infrequent enough to have to re-learn them every time. Unfortunately, they just end up being a minor inconvenience when you try to copy-paste setup instructions from docs, and I don't interact with these features otherwise.

View on HN

It's the opposite for me; things that are intuitive in Fish would involve inscrutable magic incantations copied from StackOverflow in Bash.

If you only want to use Fish for the autocompletion though, you can! Bash is always still there alongside Fish, you can just open a Bash shell when you're copypasting instructions, or `bash $SCRIPT` any scripts.

That's fair, and that's why I'm happy to keep using Fish. I suppose that I'd just prefer a leaner package and more focus on core features, but it's still my preferred option.

It's just that I never find myself needing to do anything fancy in the command line. I just want it to be fast, ergonomic, beautiful and unobtrusive.

And I wouldn't say it's because my workload is any simpler, I'm a relatively senior computer engineer working on large-scale data engineering, LLMs, non-trivial webdev and some systems programming in Rust. And it's not because I use UIs more often either, I use the command-line as much as anyone.

I guess that I have more of a "RISC" approach to the command-line.

ZSH is pretty compatible and has great auto completion. The best thing for me is inline documentation (bash-completion only shows the list of available completions and you have to derive their meanings by yourself).

It's also much easier to write your own completion scripts than for bash. The syntax is relatively sane, although fish completion scripts are much cleaner than bash or ZSH.

Stick to plain ZSH to avoid losing performance on bloated mess like oh-my-zsh, add fzf to quickly dig through history and find files/directories, and it's really the best option we have.

This.

I've been using fish as my primary shell for a couple years, primarily for the autocompletion. I started off with some zsh plugins that made the shell TOO fancy (and slow). I'd really like to see it be compatible but with some compelling improvements, rather than having them be just incompatible. Every time I can't do $() or fi... But for anything slightly complex I'll drop back down to bash rather than figure out the fish way to do it, because those things are rare enough that I have a hard time keeping them in my head.

I guess I could ask an LLM how to do it in fish, but for things that I already have stuck in my head it's just easier to drop to bash.

The better syntax used to be a selling point, but now with AI being able to generate any trivial one-liner and minor scripts you need on a day-to-day basics, have a bad syntax would only affect bigger projects, which I would not write in Fish shell anyway.

It's a hard sell.

Speak for yourself, but I would not want to be beholden to AI for every trivial shell one-liner. "Sorry boss, ChatGPT is down, I can't count how many *.txt files are in this directory. See you tomorrow!"

I'll take the better syntax, thanks.

Heaven forbid you read a man page. Even though Bash is weird, it's fully documented.

Documentation is useless if you don’t know what to look for. Which manual page do I open to find out what :(){:|:&};: means without already knowing?

To be fair, even local, small language models fare pretty well in such things (both explaining and writing).

Generative AI might be able to generate them, but it's still on you to understand the result and check that it indeed does what you want. And with the sometimes very nuance- or foot-gun-rich syntax of bash, that's rather a significant burden, if you're not familiar enough with the syntax to write the script yourself in the first place.

Scripting languages are so dynamic, flexible, arcane, and subtle and the consequences for getting scripts wrong are so potentially catastrophic for a system that they are absolutely the last thing I would ever dare generate via LLM.

The great autocompletion is a great inspiration to me as well. It's intuitive in how it works and requires no user manual, although when you sit down to analyze it, it actually has some subtle states. It's such a great design that I essentially copied its UX to a web app I was working on: https://github.com/kccqzy/smartcal/commit/10d32d18d257d5093d...

What I truly appreciate is the completion system from a dev perspective. Writing completions is comfortable. Even wrapping completions into other completions is fairly clean (e.g. sudo {cmd}TAB).

Can I ask what you find difficult about the environment variables system in Fish? Personally I find it absolutely lovely to use.

When you don't use it all the time it's impossible to remember what all the flags are for. The names/scopes are also not helpful, I usually want universal, but think I want global because I don't remember there is a universal. And the thing I have to look up every time is how to set a variable for the current line.

I'm not saying these are hard things, to figure out. I just agree that they're hard to remember when you don't use them all the time.

I don't know if this helps at all but you can use `export FOO=bar` in Fish, and the prefixing a line with an envvar should work the same as in Bash etc. like `FOO=bar echo $FOO`

Reply on news.ycombinator.com