Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They need to update the slogan? "A command line shell for the 90s" doesn't really draw me in.

What I want to know:

1. In what specific ways is it better than zsh?

2. Is it absolutely, rock-solid stable?



1:

a. Superb readline colouring. Nonexistent commands are shown in red, commands that exist and are on PATH in green. Unclosed string literals become obvious.

b. A history search that is orders of magnitude better that Ctrl-r in Bash. (Though oh-my-zsh has the history-substring-search plugin which provides this functionality.)

c. Features work out of the box, fish helps you avoid managing a .zshrc equivalent file.

d. Tab completion offers hints. If I type l<tab><tab>, I get:

  leaftoppm  (Convert Interleaf image format to a portable anymap)
  less                                          (Opposite of more)
  lessecho                                 (Expand metacharacters)
  lessfile                        ("input preprocessor" for less.)
  lesskey                          (Specify key bindings for less)
  lesspipe                        ("input preprocessor" for less.)
  lexgrog                  (Parse header information in man pages)
(These summaries are the first lines of the man pages.)

2: I've only seen it crash on me once, which matches my experience with zsh. YMMV.

I used fish exclusively for a number of years, but eventually moved back to something sh-compatible. Too many wrapper scripts assume this.


I do not understand your last paragraph. Don't your wrapper scripts have "#!/bin/sh" at the top?


That's being explicit, the problem is with wrapper scripts that omit that, assuming a sh compatible shell.

Still running fish on one of my systems, excited to see new development work as it was getting past the point where I was comfortable using it on anything new.


An old trick for convincing (some) shells that your script is an sh-compatibile shell is to use a colon on the first line. Support for this trick was added to fish back in 2007: https://gitorious.org/~ridiculousfish/fish-shell/fishfish/bl...


Thanks for the pointer. I can't say how much I wish more people would include pointers to code fragments or specific commits on a site called hacker news.

Tangential question: is gitorious's syntax highlighting usually this awful? The first thing I need from syntax highlighting is distinguishing comments from code.


I'm not sure how to use it. Can you give an example of where it works, and what changes if this is not done?


The point isn't executables that happen to be written in {ba,}sh, it's wrappers that attempt to add functionality to your commandline. For example, Python's virtualenv and Ruby's rvm presumably don't work.


I agree with your point. But virtualenv has support for fish:

    . your_env/bin/activate.fish
https://github.com/pypa/virtualenv/blob/develop/virtualenv_e...


Ah, I didn't think of that (no experience with neither virtualenv nor rvm). So thanks for the clarification.


Please elaborate on point 1b. I certainly see ways ctrl-r can be improved, but orders of magnitude (while obviously subjective in something like this) would surprise me. That said, I hope to be surprised!


Sure. There's no single feature improvement that is much better, but when considering the improvements together the difference is striking.

1. The search term is highlighted.

2. The search is far more discoverable, its key binding means you can stumble across it.

3. The up cursor key is a better key binding choice. Pressing up without a search term may be considered as searching for commands that match "", namely everything. This conforms with fish's aim for orthogonality.

4. (Most importantly) The up cursor key has a natural undo button, down. Quick quiz: if you type "Ctrl-r foobarbaz", how do you get back to a terminal you can type in, preserving your search term? You can't. Pressing "Esc" dumps you in the middle of your history with something matching the first few characters of your search term. (Assuming you have nothing in your history matching 'foobarbaz')

Similarly, if you press "Ctrl-r foo Ctrl-r", you will get the second item in your history that matches foo. There's no way to get back to your first search result without repeating the search.

5. You can use previous commands as search terms. For example, I ran "mvn clean install", then hit "Ctrl-C" when I wanted to skip tests. I pressed "<Up> <Space> <Up>" and I was searching through all my history that contains "mvn install ". Using "Ctrl-C" I'd have had to retype "mvn clean install ".


Thanks! 1, 4, and 5 in particular do seem useful. Having up search and down cancel is a win for orthogonality, but loses a touch in flexibility (if I'm searching, find something, and then realize I want to run the command before or after it, for instance). On balance, I think fish is doing it right for new users but I don't see anything there that's worth the shift for those of us who have the muscle memory for the other.

One thing I've missed from ctrl-r is the ability to drop in (an implicit or explicit) .* in my search - often, I start my search and hit a line, and I know what will disambiguate but it's a ways down the line.


> if you press "Ctrl-r foo Ctrl-r", you will get the second item in your history that matches foo. There's no way to get back to your first search result without repeating the search.

Actually, ctrl-shift-r goes backwards.


When I saw the slogan, I thought it was ironic. I kind of like it.


Agree. I'm happy there's finally a Mac term app that can support the same emacs color scheme I was using on a Linux desktop 14 years ago!


To be fair, it's "Finally, a command line shell for the 90s."

I couldn't agree more. We've been using shells from the 80's for far too long.


1) I don't know. I haven't dug that far into zsh, I didn't like it on the surface. Or rather I love both surface and depth of fish enough that I haven't yet investigated zsh.

Maybe you could tell us? Here's a pretty good article on fish by its original author: http://arstechnica.com/information-technology/2005/12/linux-...


I'm wondering about the answer to #1 as well. After trying this out for a bit there's nothing obvious and there are definitely things I miss.


1. No need to mess with configs. Works out of the box.

2. Breaking Bourne Shell compatibility. Personally I find Bourne syntax hard to learn and hard to read. Fish syntax is much better. [1, 2]

[1]: http://en.wikipedia.org/wiki/Friendly_interactive_shell

[2]: http://ridiculousfish.com/shell/user_doc/html/index.html


Sounds like there's no reason for me to switch.

I've already messed with configs and everything is stable now, so that's a sunk cost.

I already know bourne-style syntax, so learning fish (even if it's easier) is an added cost, not to mention the fact that I have to work on various boxes that I can't install fish on so it's easier to have my fingers know how to operate a single shell (zsh) that's generally backwards-compatible with bash (which is ubiquitous).


Funny I was about to say the same thing about installing on systems. When you're a systems person or work with many different customers you can't ask them to install a custom shell. Try explaining to the CIO at a major bank why all his linux boxes need fish shell installed.

So we get stuck back at the minimal set of SH syntax that I learned to master some 25 years ago.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: