Fish: A command line shell for the 90s

[1] https://github.com/zsh-users/zsh-autosuggestions

[2] https://github.com/zsh-users/zsh-history-substring-search

Up arrow scrolls back through history. With the enormous caveat that it doesn't show you the most recent one, which is usually the correct one; the list is physically split into head and tail by two different keys and two different UIs, so you can't just use it like a list, you have to remember what the top is so you can choose whether to read the ghost entry or to up-arrow and read that. If you know what the most recent one is, you shouldn't have to read anything to check, you should just be able to press the right sequence of buttons that does what you want to do. (I can never be certain that the ghost entry is actually the most recent one, because I've always thought it was frecency-based, probably because that's what similar-looking search tools (Google) have taught me. That's mostly my fault, but it's not something the UI was actually capable of teaching properly because without having to press up-arrow to see it, it is not linked to any particular list ordering; it is conceptually distinct and users are within reason not to see it as part of that list at all.)

Up-arrow works differently depending on whether you have entered text in the line or not; no text and it show you the most recent, add text and it won't. And perhaps worst of all, up-arrow actually does show the most recently typed command, but only if the matching sequence of characters was not at the start of the line. Actually that's inaccurate -- if a command matches in the middle, but also as a prefix, you can't just remember that it matched in the middle and blindly press up-arrow. That's ghost-only.

So there are in fact three different lists that up-arrow could be scrolling you through. Actual history (includes most recent); filtered history where last command did not have search term as a prefix (includes most recent); and filtered history where last command had search term as a prefix (does not include most recent). This is no longer a job for muscle memory. It's an active thinking exercise. So you have to remember the history stack yourself, including where in each line your search text will match, so you can stop and pause to think whether to press up or right at any given moment. I cannot think of another search UI that requires knowing where in a string your search term will appear, just for basic use.

Ultimately, dozens of times a day, I stop to think about which button to press, and am reminded of this spectacularly poor UI, for which apparently nobody was able to express these sentiments in the four years that the GitHub issue was open. I don't believe the behaviour can be configured.

A lot of things are even defined as ordinary fish functions. In sh, aliases are a dark and evil feature that hooks into the parser and can be used to create rudimentary macros. They have some really surprising behavior. But in fish, `alias` is a shell function and you can get the complete source code on your screen by running `type alias`. It doesn't do any evil things because it can only do things you could do yourself.

Fish has sensible variables and arrays. All variables can be arrays. When unquoted, variables expand like "$@" in sh, so packing multiple arguments inside a variable is trivial and there's no need to worry about whitespace. Command output splits on newlines, which means that things like `for file in (find . -iname 'foo')` just work, assuming you don't have newlines in your filenames.

Writing one-liners in fish makes me much less anxious then doing so in sh.

   :set shell=/bin/bash