Obvious joke is obvious, but he could have called it the Unno Fish Shell?
Looks interesting. I expect my fingers will be even more confused than ever switching machines now (they've never learned that Alt-3 isn't # on linux or that middle-click isn't paste in Putty)
That one always bites me at other people's desks; I'd figure out how to reconfigure it if it was mine. But there's always something jarring like that when you switch between similar-but-not-quite-the-same environments.
i've gotten to the point where i can subconciously key off the window chrome to know how to paste. (half my coworkers use xterm, the other half putty.)
It's not called that yet: "Its working name is fishfish, but I hope eventually it will just be fish!"
The ambition is quite reasonable as work on the fish shell itself has petered out, there was a recent dead cat bounce after a long fallow period, but it seems to be back to stasis there.
I'm on the fish mailing list and it has been well received by current contribs and the original author. I expect that the two forks will be one at some point.
I use fish (http://fishshell.com/), and it's amazing. However, they're missing the most important feature from their front page: Syntax highlighting!
Valid executables are colored green, as you type.
Invalid commands are red, as you type.
Valid files are underlined, as you type.
Like the carpenter who can feels the feedback of the grain of the wood through the handle of his plane can adjust his technique as he planes, fish shell lets me 'feel' the programs and files I'm working with through the shell.
I stopped using fish a while ago, when it would crash whenever I opened a console session (so I couldn't do anything when X didn't start). I switched to zsh with fish emulation, but lately I realized I have a shell that takes much longer to start up and basically does everything fish does, and nothing more.
If fishfish is more stable, I'll switch in a heartbeat.
I just downloaded it and while it looks awesome, I see the rvm problem. I haven't used zsh but I'm assuming from your comment that zsh is compatible with RVM. Seems like it shouldn't be too hard to write a fish version of the script that sets up your rvm environment, but if you've gone down that path and it proved too painful I won't bother. However, perhaps fish + rbenv works. Has anyone tried that?
Yes, I switched from rvm to rbenv because rvm didn’t work with fish. rbenv did work with fish.
I switched away from fish after that because go (a directory-jumping tool) required bash to install (http://code.google.com/p/go-tool/wiki/InstallNotes). I didn’t know how to port that bash code to fish, since I don’t know bash scripting, and I also anticipated that I would keep finding cool programs that didn’t work with fish.
> I stopped using fish a while ago, when it would crash whenever I opened a console session (so I couldn't do anything when X didn't start)
This is why I launch my interactive shell from a failsafe /bin/sh instead of using chsh. If zsh ever messes up horribly, I end up back in a good old bog standard shell prompt.
REALSHELLS="/usr/local/bin/zsh /usr/bin/zsh"
for REALSHELL in $REALSHELLS; do
if [ -e $REALSHELL ]; then
if ! $REALSHELL -l; then
echo "$REALSHELL exit $?"
fi
echo "$SHELL exit in 1s, Ctrl-C to abort"
sleep 1 && exit
fi
done
echo "No shells in [$REALSHELLS] found, falling back to $SHELL"
Welcome to our fork of the fish shell, a command line shell like bash. Its working name is fishfish, but I hope eventually it will just be fish! (http://ridiculousfish.com/shell/beta.html)
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.
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.
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.
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.
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.
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.
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.
I've been using the original fish[1] for years. I'm very biased, I love fish for many reasons and despite the claims that zsh can do the same things I've never had cause to switch from it. Now it was quite disappointing to see the original fish project seemingly halted. So this isn't simply great news, in the sense that development has been picked back up in the fishfish fork, some great improvements have been made at the same time!
* autosuggestion
(this actually has a great amount of utility for me.
it complements tab-completion quite well!)
* optional web-based config
(great for quickly editing your config settings)
* speed improvements
(although I never suffered from much lag with fish
to begin with)
Overall I think the usability and utility of fish is greatly improved in this fork. Also it's worth pointing out that in terms of out-of-box functionality, some of fishfish features would be very hard to match. Things like autocompletion and simple history scrollback based one partial string matching set fish apart from the pack imo. So far, I'm quite impressed and I hope that more people adopt fishfish as the de facto replacement for fish.
Yes. zsh can also auto-complete command line arguments for a lot of commonly used commands (including the GNU utilities, git, mutt, mplayer, imagemagick's convert and others.)
Bash too can do that. It does by default in Debian for instance, it also does cool things like autocompleting filenames based on which command is already typed (so it won't autocomplete to some pdf filename if the command is mplayer), autocompletion depending on config files (alias from ~/.ssh/config and /etc/hosts, remotes from the git config, package names when the command is apt-*…).
About fish, for the history based autocompletion of commands, how is that different from Bash's C-r?
Bash has completion, of course, but does it have autocompletion? Big difference as getting completions without hitting the tab key changes how you interact with the line editor.
People say this kind of thing a lot, but I’m pretty sure it’s simply not true. bash-completion handles pretty much everything I can imagine already, and can be extended to handle anything you can express programmatically.
This is missing the point of a shell by a mile. Extra features are nice. As an extra. Preferably on top of a rock solid platform that works everywhere, on everything, under any conditions. Same reason your PC boots in 16 bit real mode.
Isn't this entire shell an extra? I wouldn't replace bash with it, it seems more like a nicer interactive frontend but you could always drop down to bash if it didn't work for something. Sort of like KDE being a more fully-featured frontend to X, but you can drop back to Fluxbox if you want to test X without all the gizmos.
Your PC boots in 16 bit real mode because Intel is too locked into x86 to get rid of legacy modes and instructions. A proper architecture starts in its intended mode.
But I agree, adding all this fluff to a shell is a bit much. I use bash and keep ls colors disabled.
It gives me great joy every time a new command-line-related project is released (or, as in this case, gets a major update). I will dedicate a few hours of my weekend to take this for a thorough spin!
I tried fish a few years ago, but stopped for some reason that I can't remember. I will try again, and will either keep using it, or will remember why I stopped in the first place.
If you run chsh and get error "/usr/local/bin/fish: non-standard shell" simply add /usr/local/bin/fish to /etc/shells. Just to save you a Google search :)
A bit more context: Ridiculous Fish is an Apple Engineer on the AppKit team. He also has a nice hex editor for the Mac (Hex Fiend) and an interesting programming Blog:
The package doesn't work on Debian testing/unstable/experimental: fish: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by fish)
(I am running GLIB 2.13).
I tried compiling from source, but I am clearly missing dependencies. So far, I had to install:
libncurses5-dev, gettext, xsel, libxt-dev (alternatively, I could use --without-xsel and ignore these last two depends). You may want to add this to the project somewhere.
At any rate, I am looking forward to giving this a try.
Maybe you already know this, but glibc and glib are two entirely different libraries. (The similarity in their names is unfortunate.) So be precise when asking for help.
When using auto-completion is there a way not to use arrow keys? Especially when completing a match it seems like I need to use the right arrow key. I would prefer not to use arrow keys at all, but use something like CTRL+(HJKL).
Well, the normal tab-based autocompletion works like you'd expect. You can go backwards in history the same way you do with the up arrow by using CTRL+P, and CTRL+N is the same as down arrow.
Unfortunately I can't try this right now, but do suggestions support something like taking only part of the suggestion? I.e. move left/right from cursor into the suggestion instead of writing. Shift+Arrow would work as expected, thus allowing quickly using part of the suggestion and writing the rest out if needed. It seems to be a better solution than deleting things from the end.
you could always put "set editing-mode vi" in your ~/.inputrc .. this has the advantage of affecting all programs which use readline, gnuplot, python shell, mysql etc.. I also put
154 comments
[ 2.9 ms ] story [ 235 ms ] threadhttp://fishshell.com/
http://ridiculousfish.com/shell/beta.html
"Welcome to our fork of the fish shell, a command line shell like bash. Its working name is fishfish, but I hope eventually it will just be fish!"
Looks interesting. I expect my fingers will be even more confused than ever switching machines now (they've never learned that Alt-3 isn't # on linux or that middle-click isn't paste in Putty)
The ambition is quite reasonable as work on the fish shell itself has petered out, there was a recent dead cat bounce after a long fallow period, but it seems to be back to stasis there.
http://ridiculousfish.com/blog/about.html
Valid executables are colored green, as you type. Invalid commands are red, as you type. Valid files are underlined, as you type.
Like the carpenter who can feels the feedback of the grain of the wood through the handle of his plane can adjust his technique as he planes, fish shell lets me 'feel' the programs and files I'm working with through the shell.
And that makes me happy.
If fishfish is more stable, I'll switch in a heartbeat.
The main reason for me to give it up is because I could not get it to work smoothly with rvm.
I've gotten quite used to zsh by now, and I have to say, I don't feel much for having another go at fish just to run into the same limitations again.
I switched away from fish after that because go (a directory-jumping tool) required bash to install (http://code.google.com/p/go-tool/wiki/InstallNotes). I didn’t know how to port that bash code to fish, since I don’t know bash scripting, and I also anticipated that I would keep finding cool programs that didn’t work with fish.
This is why I launch my interactive shell from a failsafe /bin/sh instead of using chsh. If zsh ever messes up horribly, I end up back in a good old bog standard shell prompt.
:(
Welcome to our fork of the fish shell, a command line shell like bash. Its working name is fishfish, but I hope eventually it will just be fish! (http://ridiculousfish.com/shell/beta.html)
What I want to know:
1. In what specific ways is it better than zsh?
2. Is it absolutely, rock-solid stable?
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
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).
So we get stuck back at the minimal set of SH syntax that I learned to master some 25 years ago.
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:
(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.
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.
Tangential question: is gitorious's syntax highlighting usually this awful? The first thing I need from syntax highlighting is distinguishing comments from code.
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 ".
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.
Actually, ctrl-shift-r goes backwards.
I couldn't agree more. We've been using shells from the 80's for far too long.
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-...
Why can't a better interactive history go hand in hand with something like "sudo !!"?
[1] http://fishshell.com/
About fish, for the history based autocompletion of commands, how is that different from Bash's C-r?
I'm quite happy living in the 80s.
But I agree, adding all this fluff to a shell is a bit much. I use bash and keep ls colors disabled.
I'd hazard a guess that fish_config may do that for you.
http://ridiculousfish.com/blog/
[1] http://ridiculousfish.com/shell/user_doc/html/index.html#tod...
Now it's time to change to fishfish and decide what's best suited for me! :)
edit: Also, i am disappointed that the ASCII-art fish on the frontpage is actually a picture and not ascii :(
(I am running GLIB 2.13).
I tried compiling from source, but I am clearly missing dependencies. So far, I had to install:
libncurses5-dev, gettext, xsel, libxt-dev (alternatively, I could use --without-xsel and ignore these last two depends). You may want to add this to the project somewhere.
At any rate, I am looking forward to giving this a try.
I shall have to give it a try!
"\e[A": history-search-backward
"\e[B": history-search-forward
in the ~/.inputrc which maps arrow up/down to history search.. more tips here http://vim.wikia.com/wiki/Use_vi_shortcuts_in_terminal
zsh has a better vi-mode than most of the shells I've tried, although I can't say I've made a serious attempt at using fish..
the color syntax highlighting implemented in zsh is much slower than the fish equivalent though, and can be quite laggy ime