Fish sucks (but your shell sucks more) | Hacker News Reader

Fish sucks (but your shell sucks more)

markhansen.co.nz

71 pointsmhansen60 comments

"Configurability is the root of all evil"

I'm getting so tired of the overuse of this principle. Look, I don't care what options are available (really...) when I'm dealing with a word processor, or a spreadsheet program, or whatever. I expect people who don't use a computer so much might say the same thing about their web browser or email client.

But a shell (and a text editor, and a window manager) is an extremely general tool by necessity, and I have a very specific way in which I use it to get things done. If a highly configurable terminal can make that marginally easier, over time it's worth it.

I don't disagree that many/most programs could do with fewer options and more informed choices on the part of the developer, but there's nothing inherently wrong with putting well-considered options into your program.

I love simple, discoverable interfaces as much as the next guy, but let us not stray too far from "fast" and "powerful" in search of "pretty" and "simple", where it counts.

I agree completely. Every time I demo some code, people remark at my zsh setup (which I cloned from an article posted here some time ago). Unfortunately, when I suggest they do some customizations themselves, they make excuses and complain that they don't have any free time.

This is completely backwards. If setting up a good shell saves you several seconds per command, then you're saving minutes every day, and several hours a month. I probably spent 30 minutes configuring zsh initially, and I occasionally spend a minute here and there tweaking small things (or not, if it looks like it will be too much trouble), but the payoff is worth it in the end.

The moral of the story is try things, it really isn't as hard (or time consuming) as you think. If it is, then give up and do something else (or try later).

I think an unspoken aspect to that principle, but very much along the same thought lines as the article, is: Try something new, don't try to shoehorn this product into your existing method.

"Configurability is the root of all evil" because if you can change everything, you'll eventually change it into the same stagnant workflow you've had all along.

Take for example his mentioning of lack of 'man'. man has been with us since 1971. Lynx came 20 years later in 1992. There's no information that man encapsulates that couldn't be represented in hypertext - so why haven't the majority of shells moved away from man already?

Sometimes that crutch of configuration can hobble you worse than it'll support you.

The shells have no relation to man, except that being programs they typically have man pages. When you run man, it parses some file (often using nroff) and outputs it to standard output, usually through some form of pager.

A shell can't "move away" from man. It could ship with its documentation in a different format, or the authors could even develop a new documentation reader... but if you think man and the shell should somehow be specially related, you're forgetting how Unix works.

I fell in love with fish while watching a video tutorial for Babushka[1]. I immediately switched all of my boxes over to it as the default shell. Switching over decades of bash scripts was tough at first, but I bought into the whole simplified shell philosophy.

But unfortunately I had to abandon fish after a solid month of using it exclusively. Active development seems to have ceased on it. There are a lot of bugs in the code, at least a couple of which make the shell almost completely unusable for me (for example, running fish from screen is problematic). The mailing lists have some activity, but nothing much from developers. At this point it seems like an abandoned project. As an example of the lack of oversight, the main project web site's domain registration lapsed earlier in the year and it is only back thanks to a good Samaritan.

So I switched to zsh. And it has been pretty great. The configuration files are daunting, but it can do pretty much everything that fish can (and a whole lot more), it is under active development, and is backward-compatible with bash.

[1] http://vimeo.com/6782671 (it's about babushka, but he uses fish as the shell)

Unfortunately, yes. I still use it as my main shell everywhere, but it has debilitating bugs that aren't getting fixed (such as fish freezing when logging in to another tty). I wish someone knew enough about it to pick it up...

People are way too quick to compete rather than collaborate. Rather than writing their own shell, a shell that certainly hardly anyone was going to use and was certainly going to end up in the abandon-ware bin, they should of manned up and worked with bash/zsh to add some of these features, syntax highlighting for example, to a project where everyone could have benefited.

That good samaritan is reads Hacker News. ;)

Development is still happening at http://gitorious.com/fish-shell

I've always wondered why shells based on popular scripting languages don't catch on more...especially after living with Bash's horrible (my opinion) syntax over the years, and Korn before that. I know there have been a few shells created based on perl and perhaps python, but when I played with them years ago they seemed half-assed. Is there something special about the shell that requires one to create their own scripting language? I for one would love to have a well-done, reliable login shell based on ruby...

There are a few shells like that. At least 5 different ruby-based (all barely doing the basic stuff, although http://rush.heroku.com/ is not bad at all). Zoidberg (perl) is ok, but there is a lot of perl involved so you can run into situations where typical bash stuff triggers perl execution...

I really like iPython's psh - unfortunately it's not well known, since it's not advertised properly (they concentrate on the python's repl part a lot). It does work quite well though: http://ipython.scipy.org/doc/manual/html/interactive/shell.h...

You may be interested in ripl (https://github.com/cldwalker/ripl) which is modular enough to serve as a base for more complex shells. It has already been used to create a web shell (http://github.com/cldwalker/nirvana), a ruby/system shell (https://github.com/janlelis/fresh) and a js shell (http://github.com/cldwalker/ripl-johnson).

Traditional shells provide some small conveniences that are hard to give up. You cannot shoehorn this stuff into an existing language by defining global functions, it must be syntax. Ruby could come close by not requiring parens, but still cannot allow something like the following zsh command without extra quoting, parens, or function calls.

    for f ({foo,bar}/*(.)) { cp -v $f ${f%.js}.min.js } > output.txt

Scsh (a Scheme based shell) is probably the most promising example of the shell revisited and done in an established language that I've seen, but there are serious problems with it's implementation. It won't run on x86_64 for starters...

S-Expressions should allow you to do anything a shell can do, and with good completion (it'd have to be at least as good as Zsh's) I could see it being usable. Somebody just needs to do it right.

I've used eshell for years because I can't be bothered to learn a crazy one-off language like bash just to configure my shell. Elisp is atrocious compared to other lisps, but it's a dream compared to any other shell language.

It solves most of the complaints in TFA; the only downside is poor documentation and poor performance for IO-heavy operations.

I was a M-x shell guy until one job where starting to build the project in M-x shell caused the build script to bork. I still have no fucking idea why it happened, but it's scared me off of everything but standard bash since.

If that had happened to me it would have scared me off custom build scripts.

If your environment is anything like mine, someone in your organization probably thought using curses in the build script would be a clever thing to do, but didn't gracefully fall back when the script was not running in a terminal.

For me, one issue with programming language shells is just getting ls, cd, etc. working with tab completion.

The other big issue is having to build up commands to execute through String concatenation, which feels just as awkward and inelegant as building up SQL commands through String concatenation. Maybe you could do some funky namespace stuff where programs on your path are imported as functions?

    grep("foo", "bar.txt")

(Note we still have the superfluous quotation marks. How to get rid of those?)

In short, a shell is a DSL for executing programs, redirecting IO, and exploring a file system. It is hard to tweak a general purpose programming language to the point where it is better at those tasks than a shell.

I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are.

> I imagine some of the programming language specific shells mentioned in the article have found ways of solving these problems, and I would be interested in hearing what those solutions are.

Eshell does a great job at this; it feels like a shell, but it also feels like invoking lisp functions. Obviously you're not typing direct function invocations otherwise you would have to quote all your strings, etc; but it's pretty close. You can pipe output from processes straight into Emacs buffers or even into functions. All the shell commands that have nicer Emacs equivalents (grep, top, man, etc) get intercepted so you get the enhanced hyperlinks in grep results, etc. I find it absolutely indispensible.

http://www.masteringemacs.org/articles/2010/12/13/complete-g...

Um, wow! Eshell could be just what I've been looking for, considering I spend much of my day in Emacs anyways. Might be time to brush up on Emacs Lisp...

What does DSL stand for?

Edit: Ah, I guess it is Domain-specific language.

I don't think a Tcl command shell would be out of the question. It's simple and powerful, but still quite terse. Most EDA software includes an interactive Tcl shell as well - they're quite popular with ASIC and FPGA designers.

Yep, I think so as well - TCL could be nice replacement for current shell syntax, but choice and state of TCL shells is quite sad. :(

take that one step further.

Currently an Ubuntu system depends on bash, ash, perl and python scripts for various tasks - booting up, init, etc.

Take one scripting language and use that completely. Not an easy task, since you will have to do stuff like have a perfectly compatible PCRE library, etc.

"The shell is one of the places where you’ll spend most of your time as a ['nix] coder"

Maybe if you're a *nix system administrator. Otherwise, no, not really. I spend most of my time in Eclipse. People who prefer using editors to an IDE spend most of their time in Emacs or Vi(m). But shell? Maybe to hack together a script now and then, but certainly not most of the time.

Hmm. Are you saying that one's shell is not very important, then? That one shouldn't care what shell they are using? I'm sorry, but, otherwise, I don't think I understand why you felt compelled to pick out this single quote from the article and argue about it. Could you explain your point?

I would say "most" of the time as a definite exaggeration, but I do spend close to 100% of my time between emacs / shell and a web browser.

As a developer who uses vim I can confirm that the vast majority of my time is spent in the shell, running scripts, working with vcs etc. It's the equivalent of my 'IDE'. At least three other developers I currently work with have a similar setup, so I'm fairly sure its not just me.

Well, in that case - I stand corrected.

I think it's important to remember what IDE actually stands for: integrated development environment.

That implies that the standard development environment used to not be integrated. And that's exactly what Unix is: a development environment where the tools are not integrated into one place. That sounds like a bad thing on the face of it, but I do not think it is. I think it allows for more flexibility.

Isn't the "one place" the shell?

But that is a completely open-ended interface, as opposed to an IDE where you can only perform pre-defined actions. You access it all from one place, but all of your tools are not integrated together.

No, the shell is the integration. The shell provides plumbing, not the environment itself.

I'm a Java developer using IDEA. I still spend most of my time in a shell. Mouse pointing and clicking to do things like run builds annoys me when I can alt-tab and run a script to run unit tests.

I think IDEA is a fantastic IDE, and possibly there are shortcuts to do what I'm doing in a shell, but even screen redraws etc take up needless time and force me to wait when I don't need to with smart use of a shell.

I'm an old school vim/perl hacker though, so maybe I just am used to working a particular way, having "grown up" with the shell, I can't imagine not using it to do most of my work for me.

I'm always interested in the idea of learning a new shell - but the ubiquity of bash is what generally holds me back. I fear that switching gears for each system I log into would seriously break the flow.

That's the same reason I stick with vim and a relatively vanilla vimrc. I know that I can ssh into almost any machine and be productive. GNU screen, vim and bash mean I can get work done.

Once you throw Screen into the mix it's a lost cause IMO. Having it bind control-a by default means it's absolutely unusable without a .screenrc. Anyway, it's easy enough to just hit "curl p.hagelb.org/d | tar xzf -" first thing you do once you log in, and bam--all your stuff is there.

Would you ever use an editor without syntax highlighting? Of course not!

Speak for yourself. I also don't care a lot about "intellisense" in editors. That's why I'm not too entranced by the advanced tab completion features that a lot of shells (bash, zsh, fish) offer. Most of the time I'm better off just typing, using the history (!!, ^) or writing small aliases, scripts or functions. And in that regard, all those "modern" shells still have a lot to learn from ksh93 (or even ksh88).

If I want advanced editor features in a shell, I can always use an advanced editor (i.e. use eshell).

You realize that all modern shells have those features too right? I know I find zsh's up-line-or-search to be invaluable. I just type the first few letters of whatever command I want to run and have run before, press whatever key I happened to bind that to (I use the up arrow), and whammo, it's completed out to the last item in history that starts with what I typed out. Wack it again to get the one before it.

The main draw of the "modern" shells is their completion, particularly history related completion. The function I use for it is just one of god-knows how many, and they can be customized to the extreme. If all you want is advanced editing features, just about every shell under the sun supports vi-mode (my preference) or firing up an editor with the contents of the current line in it's buffer. Just advanced editing isn't really the main attraction.

Sorry if that didn't come across clear enough. When I said that a lot of the current shells can learn a thing or two from ksh, I was talking about the scripting part. And there it's mostly POSIX/Bourne with a few things from ksh and some idiosyncratic new features. The rc shell from Plan 9 was an interesting approach, too.

Zsh/bash/fish don't try to innovate in that area. The readline library (which is the basis for most of the interactive history features) is quite nice, but I'd much rather save me some repetition than make sure that the repetitive commands can be entered fast enough.

I guess it all comes down to how repetitive your shell usage is. If you're very exploratory, i.e. use different paths, systems and command line options all the time, completion helps, just like it helps you navigate a huge mess of a class inheritance tree. If you find yourself able to factor out common tasks, scripting is a bit more helpful. And most of the time, I fall into the second camp, which is why I've never found fish all that attractive. Which is what I wanted to point out (although a bit too bluntly – curse my German nature!).

I definitely liked the idea of fish. I tried using for a little while when I first came across it a few years ago, but it´s new features were outweighed by simple things I had become use to in Bash such as operators like && to run commands at the same time and the keyboard short-cuts (Ctrl+A, Ctrl+U, etc.).

Lovely discussion here. Looks like you could argue forever. But the rule about that is, the less the differences matter, the longer you can argue. Folks campaign for what they know, because they are more productive in a familiar environment. Makes sense. But its definitely not an argument about the thing itself.

For the record bash has the smart tab completion turned on by default now. (At least it does in my Ubuntu machine)

Indeed, I was reading through his tab completion examples noting that I can already do much of this in my Ubuntu environment. Now, that doesn't mean it's not a pain to accomplish this in Bash, I just don't know. It's rather transparent to this end-user though.

That's your distro, however, not Bash itself. On OSX (for example), you must install bash_completion and source it.

I'm not saying that this is a significant amount of work, but the author's complaint that other shells don't do per-app completion out of the box is valid. However, there are good reasons for keeping such completion code separate from the shell itself.

Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash. Before that file-completion was hardcoded in.

> Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash.

No, I don't think it's new at all. From Ian McDonald's site, Working more productively with bash 2.x/3.x[1]:

> A relatively new feature in bash is programmable completion, which has been available since the beta version of 2.04.

Taking a quick look at Bash's official downloads site[2], Bash 2.04 was released in March of 2000.

[1]: http://www.caliban.org/bash/

[2]: http://ftp.gnu.org/gnu/bash/

Not wanting to learn a new shell, is there any movement in the bash community to implement some of these features?

I haven't seen any user-visible new features in bash the last couple of years, so wouldn't count on it. (see http://tiswww.case.edu/php/chet/bash/NEWS)

On the other hand I'm slowly migrating to ipython shell as the main login shell. Since every other terminal I open runs ipython, that makes sense. It also lets me script a lot of stuff without the crazy *sh syntax.

Off the top of my head didn't bash4 include multiple globs? ie * * (no space...formatting)

Sorry - by user-visible, I meant actually the stuff that "normal" users see, not the shell programming bits. Those are polished all the time of course. Magic symbols and internal functions change all the time with new exciting ways to do basic process calling (</sarcasm>). But on the outside, it's still same old bash you run 2 years ago - no major usability improvements.

there's a lot of action going on in zsh at the minute, see: https://github.com/robbyrussell/oh-my-zsh

I'm perfectly fine with zsh, it gives me all that except syntax highlighting (which I don't really need)--I just use the GRML zsh scripts with some of my own personal aliases (and I don't have to learn a non-bashlike syntax). http://grml.org/zsh/

This article got my excited to try out a new shell, I moved to zsh a while ago but not been particularly impressed, its a shame their site is currently down, http://www.fishshell.org/, hopefully they realise / get it back up sharpish

In the mean time, here's the Wikipedia page for it, which has a decent overview and a couple of examples: http://en.wikipedia.org/wiki/Friendly_interactive_shell

You can download it from Sourceforge: http://sourceforge.net/projects/fish/

or install it through homebrew: brew install fish

"When I’m browsing a path on a slow-ass NFS connection, it slows down my typing to a crawl while it does a network roundtrip ls’ing the directory every damn time I press a key."

Huh?

I think that he's complaining that the directory listing is hit up on every keypress, probably in an attempt to populate an auto-complete list.

My guess is that it lists the directory everytime to underline correct paths (as he explains later) instead of listing a directory after each / and remembering the files and directories in it.

Reply on news.ycombinator.com