Fish Shell Design Principles | Hacker News Reader

Fish Shell Design Principles

fishshell.com

116 pointscharlax71 comments

Every now and again I give Fish a try, think how great it is, and then try to do something like `sudo !!` and give up in a fit of rage.

I understand the desire to avoid using the special chars but the alternative (using the cursor keys) is just too cumbersome. It turns out that when you use the shell for everything, efficiency is the thing that matters the most.

Not complaining - I'm not the target audience - I just find it an interesting observation about usability.

Every now and again, I give Fish a try, and I'm definitely wow'd (usually by the automatic colors), but not enough to completely ditch Eshell.

If you really really hate cursor keys there are keybindings you can use instead. Don't remember what they are though because I personally don't mind using the cursor keys. (I do know that they add vim keybindings in the latest version, which was a commonly requested feature)

Not only are special characters useful but some shells went to the other extreme. In the early days of the Mac, the system’s default keybindings made it so easy to type “weird” characters that the MPW Shell had many more special characters than shells on other platforms at the time, leading to creative uses of ƒ and ∂, etc.

Now that Unicode support is becoming more common, perhaps some bold shells will bravely adopt new special characters.

As you noted, avoiding arcane magical characters is a primary design goal for Fish. But the alternative you mention — using the cursor keys — is indeed cumbersome and not at all what Fish users would normally do. In my case, I added a "sdl" command (for "sudo last") as a plugin for my Tacklebox and Tackle projects:

https://github.com/justinmayer/tacklebox

https://github.com/justinmayer/tackle/blob/master/plugins/sd...

Some may feel that these kinds of functions should be built-in, and if so, that's probably where the philosophical divide lies. For me and many others, avoiding esoteric syntax makes it easy to compose small snippets that accomplish precisely what we want, without having to remember unintuitive special characters or deal with their often-idiosyncratic behavior. (^_^)

Thanks for sharing, I do like the philosophy that avoiding esoretic syntax and unnecessary configuration, that would prevent anyone from writing clean and solid code.

Yeah the bang commands are the biggest thing I miss. Such an easy powerful feature.

On the other hand I love how much fish does for me. I really take a huge amount for granted and noticably miss it when I have to use a different shell.

Incidentally, I've been using fish for a while, and it's really nice. Coworkers wandering past while I'm working have been known to stop and state; the fish autocompletion/history magic is really impressive if all you've known before is the standard bash Ctrl-R stuff. And once you get used to it, and huge productivity boost, especially if you work a lot with tools like HTTPie.

(And while compatibility with tools which expect bash gets brought up a lot, I've had zero issues. YMMV.)

I've been using it for years and swear by it. Z is another tool that makes my life much easier: https://github.com/sjl/z-fish

If you aren't using fish, you need to switch to it right now.

Same here. One particular thing about fish is problems with OTHER people’s scripts that don’t setup their shebangs properly, and start causing all kinds of fuss.

We had this really old build system that worked, but man, it was riddled with a lot of scripts that did not declare the shebang and used all trickery shell scripting. It took almost a month to fix them and make them more portable. It was good, because I converted three people to fish after that. :)

Devil's advocate here: could you have gotten away with having a shell script (build-fish.sh?) that opened a `sh` shell and ran the build? Seems like a month spent on making a build script work with a minority's choice of (non-mainstream) shell is a lot. :-)

(I should note that I've been guilty of spending time on non-valuable things. So this is most certainly a bit of the pot calling the kettle black :)

That's what he did. He added the shebang lines so they'd run with sh. Although I don't know why that took months, I would have written a script to find executable files and check if they had a shebang line.

For ease of installation, you can also get Z as a plugin from my Tacklebox/Tackle projects:

https://github.com/justinmayer/tackle

I haven't used fish, but I'm curious about the auto-completion/history magic. Is it similar to dynamic-complete-history(CTRL-META-i) in bash?

  """
  [...]
  Configurability is the root of all evil

  Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it.
  [...]
  """

That's so wrong. Providing configurability is flexibility. No programmer will ever know what the user really wants. The most he could do, is to define the most reasonable default values. But there are freaks out there who love to do stuff differently.

I don't think he's talking about the power user. It's geared at the pragmatic user who wants to get work done.

However, it assumes there is always an objective better way. That's something I'm not convinced of.

The rational that reducing choices will lead to less software bugs is certainly true, though. That's the reason I'd pick to have less config. Config options generally map directly to conditionals in your code base, which means more potential code flows and multiplicative combinations of possible things your code can do depending on what is turned on and off. There is a real maintenance cost to having lots of configuration.

Surely the pragmatic user who wants to get stuff done is the power user. You take the effort to learn the advanced stuff because you want the shell to get out of your way.

> It's geared at the pragmatic user who wants to get work done.

So the person who would just use preinstalled bash then

You might have misunderstood the sentence you are quoting. From my point of view, the quote and what you are saying are not different goals, just that your way of achieving that goal has to involve configuration and the quote's goal tries to do away with it. I completely agree with the quote, a program should do what the user wants it to do, without any config. However that is unfortunately not yet possible, as you are saying, but is certainly the desired end goal. If the program does what you want, >always<, then no configuration is needed because it could only defer from that goal. Therefore I believe the quote is a very good one, albeit somewhat philosophical.

It sounds radical, but it is very reasonable when you bring in the proper context.

It is not talking about that kind of configuration like keybinding and color scheme, which is simple to implement, simple to understand, and something most users would happily play with. Fish even encourages users to customize such things by providing a web interface.

A good choice for the proper context here is the 180 options that zsh offers (http://linux.die.net/man/1/zshoptions). All of them exist for a reason -- mostly because "this is cool but some will dislike it / it will break other features, so let's make it an option".

This strategy does its job in keeping old users. But the problem is that you only add options and never remove options, and over the course of development, many options are used by fewer and fewer people. When a new user picks up zsh, it behaves almost the same as 20 years ago -- because breaking changes are introduced as options that are off by default -- and you never know which combination of the 180 options will give you a good experience. They either get frustrated and not use zsh, or copy someone else's .zshrc and never care about which options do what. Either way, it is a clear sign that 180 options for a shell is simply too much.

And from that frustration, is born the sentiment that you just read.

Configurability also leads to complexity, which will be more than linear as options can interact with each other. Often it's just an easy exit for how to satisfy users and pass the blame. Users can't blame the program anymore for being bad, users are getting blamed that they aren't configuring the program correctly.

It gets totally absurd when even the defaults aren't sane, like in some text editors syntax highlighting is off by default.

In my experience with fish, most of my configuration were aliases, custom functions and stuff in my config.fish. There is less need for hundreds of configuration options when the primary way to configure your system is by writing small scripts in a Turing-complete language :)

My tolerance for lack of configurability correlates inversely with the complexity of the interface. I'd be very annoyed at the behavior of tig, vim, and tmux if I didn't have my .tigrc, .vimrc, and .tmux.conf. Shells have a pretty straightforward interface, so I customize very little other than environment variables and the prompt. My issue with fish then isn't really about its lack of configurability per se, but that by adding a lot of complex behavior to the shell, it's added a lot of stuff I would want to configure.

It breaks many bash one-liners and other commands, today I discovered I cant `git merge HEAD@{1}` because fish shell strips the curly braces. Its good but it can be quite annoying sometimes.

Even '&&' to join two commands (fish uses '; and').

What happens if you enclose 'HEAD@{1}' in single quotes?

Should word just fine. Double quotes too. You can also quote just the braces, in case there is some variable expansion going on in the rest of your word:

   set foo HEAD
   git reset $foo"@{1}"

For me, it was the "Fish breaks flow control in child processes" bug/feature, https://github.com/fish-shell/fish-shell/issues/2315

Super annoying, to me at least.

Fish is the shell I wish I could use, but I'm afraid of the tinkering I have to do to get common tools and workflows to work.

What do you mean? The main limitation I know of is tab-completion.

Bass might provide some help with that.

https://github.com/edc/bass

I transitioned from zsh without any hassle, though I did need to port my environment variable config.

Fish works great in everyday use, especially the 'smart completion'. I didn't encounter shell scripts that wouldn't work in fish, since they don't run though fish, but sh or bash. Naturally some bash things don't work on the command line (for instance backticks), for these I usually quickly jump into a bash session, run the bash expressions, and then go back to fish.

fish simply replaced `backticks` with (parentheses). give it a go.

Backticks aren't recommended even in POSIX anymore, $() is the newer, preferred alternative.

Huh? Does sh have "$()"? I thought we had to use backticks for POSIX-only environments.

Yes, POSIX sh has $(): 2.6.3 Command Substitution (http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu...)

I spent a long time feeling that way too, and then took the job one day. Turns out its generally fine - I had a bit of pain getting NVM to work, but otherwise its been really smooth.

One of my users is using fish in an otherwise zsh-only environment, so far we've only ran into problems once: virtualenv's activate script needs to be shell-specific to muck around with env variables. Every other tooling we use for webdev (npm, bower, whatever the kids are using now to pretend make doesn't exist, …) runs without problem.

There is activate.fish provided by virtualenv. In case you didn't already know (you didn't menation, thought it might be good to let others know if they see this).

I use virtualfish, which is even better:

https://github.com/adambrenecki/virtualfish

99% of shell scripts are just executables that have a shebang line at the top. As a rule of thumb, the only time when using a posix-compatible shell as your interactive shell matters is when you are expected to "source" or "eval" a sh script that is generated by some other program (as the virtualenv example)

My Tacklebox/Tackle projects bundle Virtualfish, which addresses this very elegantly.

More info: https://hackercodex.com/guide/tacklebox-fish-shell/

Just take the plunge! Support for popular tools is better than it used to be. I've been using it for a few years now and it's been quite a while since I faced any sort of issues.

It's subjective of course, based on what your workflows are and how much bash-fu they involve.

I tried fish, but their vi line editor mode was a bit broken, so I tried to rebind some keys, which was also broken.

I really dislike the anti-customization bent they have. It has 'sensible defaults' but it is extremely painful or impossible to change them. I went back to ZSH.

Yeah, I found a lot of the default configuration was confusing or unexpected and then I found ohmyzsh and switched, it is so much nicer by default (I just switch the theme to gentoo and all is good). The only thing I don't like about ohmyzsh is the constant updates.

I switched to antigen from ohmyzsh, I like it a lot.

I used to use Fish but switched over to zsh due to the better support. It'd be great to see Fish get more popular in the open-source community as I'd love to give it another try.

One of the things that I found really helpful for using Fish is importing all the variables and aliases in bash_profile into Fish the config. This way when I go through install processes that automatically append configurations to bash_profile they get carried over to my Fish config painlessly.

Here's a recent blog post describing this strategy:

https://blog.gospodarets.com/fish-shell-the-missing-config

If I were using a 'real' shell, I'd probably be using Fish. However, since I pretty much live in emacs, I spent the time to configure eshell to do what I need and it works well enough, and gives me the ability to manipulate the results as text. There are a few funny edge cases and quirks to get used to, but they are few enough that it is a viable option for my purposes.

Fish sensible defaults can go a long way and the scripting language is fairly easy to pick up. If you want more that what's provided out of the box, then check out Fisherman: http://fisherman.sh

Fisherman has a lovely website and even docs, but what does it actually do? The list of plugins is not very impressive, many of which seem to be placeholders that don't do anything at all (see the "plugins" with numeric names):

https://github.com/fishery

I use fish for a year now. I was actually gonna give a try on fisherman. But I found out that oh-my-fish (which I currently use) repos are down because of one guy that maintain the fisherman and is abusing of DMCA all over oh-my-fish repositories. https://github.com/oh-my-fish/oh-my-fish.

Not gonna give a try on a project that is primary maintained for bad people with bad intentions.

It seems interesting the 'wa' repositories now redirect to a Fishery account that does, guess what? fish plugins. I’m not defending oh-my-fish, because it looks like they didn’t give attribution, but it’s all too convenient.

In any case, it’s clear this is just a stunt to open the path for Fisherman to become the de facto framework. Hopefully no one will really use them, but I know some people will.

This is no doubt the funniest (but most miserable, really): http://ohmy.fish (guess where it redirects)

We detached this subthread from https://news.ycombinator.com/item?id=11108656 and marked it off-topic.

Tackle/Tacklebox is rarely updated and still has open issues from up to 2 years ago.

Fisherman supports Tackle modules and functions, so if you are using Tackle, you can migrate to Fisherman without any hassle and still reuse and enjoy their plugins.

+ http://fisherman.sh

Wait... what? This is just rude, not to mention patently untrue. My last commit to Tackle was 8 hours ago. Why do you feel the need to denigrate someone else's work? No wonder there are multiple comments in this thread that refer to your unsavory reputation.

We detached this subthread from https://news.ycombinator.com/item?id=11111846 and marked it off-topic.

Tackle/Tacklebox is rarely updated and still has open issues from up to 2 years ago.

Fisherman supports Tackle modules and functions, so if you are using Tackle, you can migrate to Fisherman without any hassle and still reuse and enjoy their plugins.

+ http://fisherman.sh

You have sunk to a new low, copy-pasting this same falsehood. The other comments here that speak of your past misdeeds are now all the more clear.

2-year old issue proof:

• https://github.com/justinmayer/tackle/issues/3

Tackle support for "modules" and "function" snippets in Fisherman proof:

• https://github.com/fisherman/fisherman/blob/master/functions...

⁣⁣

I exhort you to demonstrate my comment was false.

⁣

Bonus Points ⁣⁣

PRs are ignored for months:

• https://github.com/justinmayer/tackle/pull/16

Issues are left unanswered for months:

• https://github.com/justinmayer/tackle/issues/14

⁣

All I am saying is, if you need first-class support for your fisheries, Fisherman is the man for the job, not Tackle. But hey, Fish is great out of the box and you don't really need anything to get up and running :)

Hehe... Okay, buddy. Want proof? That "issue", which is merely a suggested adoption of someone else's function, isn't even 18 months old.

You are unnecessarily hostile and misrepresent facts. As other commenters here have already noted, you clearly cannot be trusted.

We detached this subthread from https://news.ycombinator.com/item?id=11111884 and marked it off-topic.

That's not true. Oh My Fish! is down because they are still using my old Wahoo code. I have since moved from that old code base in Fisherman, but they haven't. Do as you please, but learn your facts.

Do as you please, but learn your free-software licenses. https://opensource.org/licenses/MIT

Who actually submitted each line of code is visible in the commit history. The copyright is attributed to the Oh-My-Fish! group as a whole. You pushed the Wahoo code and you were part of the group until you started trolling, moving and deleting the repository, creating fake users, sending annoying DMCA claims, etc etc...

Much of the Wahoo code was removed, changed, or about to be phased out. If it was any good you wouldn't start your new framework from scratch.

And if attribution was really all you wanted, you could have simply asked for it. Why would anyone deny that from you?

Anyway, I'm tired of chasing you to put a counter to your spread of skewed truth and your generous omission of facts.

All rubbish. 1 year late to the party and you talk like you knew what happened. By the way, are you chasing me? This is creepy.

Oh My Fish! is down because you gave Github a DMCA request to take it down. This taken with your bizarre domain redirect is about the most egregiously bad behavior I've ever seen in open source.

Watching you two quarrel has left me with such a sour taste in my mouth that I'm now wondering why my shell needs a plugin manager in the first place.

You are right. Fish works beautifully out of the box and you should not bother really.

We detached this subthread from https://news.ycombinator.com/item?id=11109294 and marked it off-topic.

Reply on news.ycombinator.com