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.
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:
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.
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.
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)
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.)
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.
"""
[...]
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.
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.
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.
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.
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.
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.
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 :)
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.
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:
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).
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)
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.
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 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.
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 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:
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):
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.
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.
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.
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.
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 :)
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.
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.
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.
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.