

Fish sucks (but your shell sucks more) - mhansen
http://markhansen.co.nz/fish-sucks/

======
poink
"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.

~~~
pudquick
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.

~~~
jff
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.

------
presto8
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)

~~~
saurik
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.

------
rufugee
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...

~~~
jimbokun
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.

~~~
technomancy
> 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...](http://www.masteringemacs.org/articles/2010/12/13/complete-
guide-mastering-eshell/)

~~~
jimbokun
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...

------
Sandman
_"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.

~~~
alinajaf
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.

~~~
scott_s
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.

~~~
nodata
Isn't the "one place" the shell?

~~~
scott_s
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.

------
EAMiller
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.

~~~
rikthevik
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.

~~~
technomancy
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.

------
mhd
_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).

~~~
burgerbrain
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.

~~~
mhd
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!).

------
jawee
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.).

------
JoeAltmaier
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.

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

~~~
telemachos
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.

~~~
rmc
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.

~~~
telemachos
> 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/>

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

~~~
viraptor
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.

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

~~~
viraptor
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.

------
mithaler
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/>

------
daleharvey
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

~~~
stevelosh
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/>

~~~
ortatherox
or install it through homebrew: brew install fish

------
philjackson
"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?

~~~
pyre
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.

~~~
buster
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.

