Fish: Finally, a command line shell for the 90s
ridiculousfish.com
ridiculousfish.com
* 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)
zstyle ':completion:*:manuals' separate-sections true
zstyle ':completion:*:manuals.*' insert-sections true
zstyle ':completion:*:man:*' menu yes selectAbout fish, for the history based autocompletion of commands, how is that different from Bash's C-r?
LANG=C fooValid 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.
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":(
I think my favorite feature was that history was instantly shared among all your open fish instances.
Oftentimes my execution lines are somewhat long -- enabling/disable debugging info in certain sections of the program while tracing programs, etc, and I'd not want to type them out continuously. As a result I'd use the command history a lot, muscle memory would automatically hit CTRL-P once I switched to one of my execution terminals. If I'd visited something in the documentation terminal in the meantime, I'd be staring at 'man 2 timer_create' instead of my expected './aesalon --set listen=6421 --set ::debug-shm --set ::debug-interaction'. The third-second or so I'd need to do a sanity check would seriously interrupt my train of thought.
It's neat, and I can see why people like it. But for my particular one use-case of terminals/shells, it was annoying. Took me about a week before I realized just how much it was slowing me down and disabled it.
[I probably should have just set up another zsh configuration for those particular terminals, but enough years with bash have trained me, I guess, to not expect it from my shell.]
For future reference, I use the following Zsh history options:
setopt incappendhistory
setopt extendedhistory
setopt histignorespace
setopt histignoredupshttp://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.
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:
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)
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.
. your_env/bin/activate.fish
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-...
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 :(
batman@batman ~/D/S/rails> alias foo="cd ~/"
fish: Could not expand string '$tmp[2]'
/usr/local/share/fish/functions/alias.fish (line 19): set body $tmp[2]
^
in function 'alias',
called on standard input,
with parameter list 'foo=cd ~/'
Edit: didn't take me long to find something worse. I defined my aliases as functions, but apparently fish executes all functions when it sources the file? By putting this function in:
function foo
cd ~/
end
That infinite loop thing is a bug for sure, it shouldn't do that! I have defined that type of function to jump to the directories of current projects - that should work.
What do you mean? Even if I define a function like so:
function foo; cd /var; end
For example, I'd type something like this:
function gogogo
cd ~/src/teh_project
end
funcsave gogogo
Explicitly: No, it definitely shouldn't try to run functions right away. Bug!
FWIW I haven't tried the fishfish fork/update, just used the original version for a number of years.
It'd be greatly appreciated if you could spare a moment to send a bug report! (I'm not a dev by any means, just a fish lover ...)
fish doesn't have aliases, only functions. 'alias' is itself a function, which looks like it has a bug. I filed https://github.com/ridiculousfish/fishfish/issues/48 to track this.
(The usual way a fish user would add this function would be to put a file 'foo.fish' in ~/.config/fish/functions, or to use 'funced fish' to create one interactively.)
As for your infinite loop - fish certainly does not execute all functions when it sources the file. I wasn't able to reproduce your problem. Can you explain how you added this function?
Thanks!
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)
Why can't a better interactive history go hand in hand with something like "sudo !!"?
find . | xargs -I {} grep pat {} find . | xargs -I \{\} grep pat \{\}In fish you could do this:
grep pat (find .)
for i in (find .)
grep pat $i
end
And the for loop in fish is so elegant and convenient that it's worth using for small random stuff.
(Everything I say is pending that I understand the find/xargs/grep example!)
Wow, that 'autoescaping the commands in parens' syntax is great. But it doesn't seem to be list related. For example: grep pattern (echo "foo.txt") just passes the result from the echo to grep. It's grep which is doing the right thing with a list, right? Still this is interesting. So fish stuff isn't necessarily written left to right and joined with pipes, instead it's written in nested form like in a more modern langauge.
Alas you still need to use the "find | grep" technique in fish because of the argument size limit. For example:
grep pattern (find .)
Failed to execute process '/usr/bin/grep'. Reason: The total size of the argument and environment lists 34kB exceeds the operating system limit of 34kB. Try running the command again with fewer arguments.
The equivalent in bash gives you:
-bash: /usr/bin/grep: Argument list too long
find . | xargs -I XXX grep pat XXXHistory file should apply some kind of maximum history length
Fine, but the default needs to be large, like 100MB. Disks are big now. I hope ridiculousfish agrees.
I'd be happy with 100 MB as a maximum size but there should also be time-based limits, like remove anything from history that is older than a few months.
more: http://www.linuxjournal.com/content/using-bash-history-more-...
Yes.
visible to anyone with physical access to your box
Maybe not. That's an auth problem, not a reason to throw away your archives. I keep all my email even though there's probably something in there embarrassing to me given some audience.
This bug is actually fixed with my changes (see the release notes at http://ridiculousfish.com/shell/release_notes.html). The maximum history length is now 250k unique items, with an LRU discard policy. A full history would be around 15 MB.
Processing time is one concern. fish doesn't do anything as clumsy as keeping the entire file in memory, but scanning a large history file can still add up.
But the larger concern is writing it out. fish saves its history atomically by writing an entirely new file to disk, and swapping it in. You may not notice a 100 MB file, but you would probably notice a frequent 100 MB write!
That's so you get sync'd histories across one user's logins? Good feature, but I need my history. It's invaluable to me. Still, maybe 250k lines is enough. Is there a way I could bump that up and judge for myself the consequences?
(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.
You can put this stuff in your ~/.config/fish/config.fish .
There's a useful set of completions and utilities at https://github.com/zmalltalker/fish-nuggets with a variety of forks that add and remove various things. If nothing else, it's a pretty solid starting point.
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.
[1] http://ridiculousfish.com/shell/user_doc/html/index.html#tod...
Also judging by your blog you might like something like
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo $$ $USER \
"$(pwd) $(history 1)" >> ~/.bash_eternal_history'
Also, in the blog post I linked to the link you mention.
Yeah, I now noticed that you already put that link in the blog.
That brings me to the question: What is different in this fork? Is it worth to use this fork or should I stick to the original?
"\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
I shall have to give it a try!
~/.config/fish/config.fish
I'd hazard a guess that fish_config may do that for you.
I'm sure you know that that's a joke ... ?
Since there are many fish fanboys here, and since it seems like it would be cool if it worked, I'm hoping someone can tell me the simple obvious thing I should have done. Can you help?