Fish shell
fishshell.com
fishshell.com
For those who are interested, the fish shell is about to release version 2.2, a very significant release that wraps up eighteen months of development. You can try the beta now: http://fishshell.com/beta/
A sampling of new features:
- vi mode (yay!)
- Abbreviations, fish's take on aliases. They expand as you type them.
- A new "inline" pager, inspired by zsh. It's searchable and supports progressive disclosure. See it in action: https://www.youtube.com/watch?v=ncVWbT-jWAw
- A redesigned theme and prompt chooser: http://fishshell.com/beta/assets/img/screenshots/web_config....
- Tons of new tab completions!
I couldn't find any information about the team though, maybe it would be a good idea to include some kudos on the website / on github just to show that real people are involved in this project. Personally, it always makes me be grateful.
Cheers!
========================================================
# count the number of the files in the dir(not sub.), use tree | wc -l for subdirs # alias lsc ls：command not found ~/.config/fish/config.fish (line 67): # alias lah 'la --color=yes --sort=time -lh | head' # count the number of the files in the dir(not sub.), use tree | wc -l for subdirs # alias lsc 'ls -all | wc -l' ^ in function 'fish_prompt' called on standard input
in command substitution called on standard input
Warning: Identity file
alias cp cp not accessible: No such file or directory.
Warning: Identity file
alias mv mv not accessible: No such file or directory.
Warning: Identity file
alias rcp rsync not accessible: No such file or directory.
unknown option -- -
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port]
[-Q cipher | cipher-auth | mac | kex | key]
[-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] [user@]hostname [command]
========================================================
Deleted comment
In bash, if you cd into a symlink and then cd .., you get back to where you started. But fish will resolve the symlink, and so it will take you to the destination's parent.
The price bash pays is inconsistencies between external commands and builtins. For example, `ls ..` can output something different than `cd .. && ls`. This is because the kernel maintains the cwd as an inode, not a path.
I don't know of anyone who is wedded to the existing behavior. If you feel strongly about it or have ideas for how it ought to work, please comment in the issue! https://github.com/fish-shell/fish-shell/issues/1957
Hey, since you are the lead dev of the fish shell, a serious problem occurred to me weeks ago, I was compiling a QT client in fish, and there is already an environment value called `LD_LIBRARY_PATH` (including other values the compilation needs) defined in /etc/ld.so.conf.d/ and /etc/profile.d/ but fish cannot find them, if I use `set -g ...` to set it in fish shell prompt and then do the compilation, it will work, it took me a lot time to figure it out that this is the problem of fish-shell, the weird thing is, there is already one line `#!/bin/sh` at the beginning of the compilation script (it is a bash script called build.sh), so it should be executed under sh which is bash in my CentOS.
bash only reads the files in /etc/profile.d when launched interactively, so those files won't be read for #!/bin/sh scripts. Of course, if you launch the script from an interactive bash session, the script will inherit the variables that the profile.d files set up.
As an aside, this zoo of configuration files is something that fish tries to avoid. fish reads its config files unconditionally, and leaves it up to the file to branch on whether the session is interactive.
$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 19 17:51 /bin/sh -> dash
I used fish years (2006/7 era) ago as my default shell, and I really appreciated the functionality in helping to make unix easier to use.
fish has a set_color builtin which accepts RGB hex. This makes colored output easy: `set_color 69F; echo 'I am light purple!'`
The shell is what actually handles key presses and produces the output (handling commands, input/output redirection, etc).
They're not the same thing - I bet you could use fish inside cmder or iterm.
That said, there is a long-standing issue regarding inline environment variables.[1] Briefly speaking, fish does not recognize the `NAME=value command` form. So you should use `env` to work around this. This may not be a deal breaker, but I'm a bit annoyed, and migrated to zsh.
I would call zsh the opposite to fish. It has insane defaults, is highly customizable, and has so many features that are initially disabled. After hours of configuring it, I loved it.[2] Since then whenever I set up a new Unix machine zsh has been the first thing to install.
So, I would recommend zsh for the people who are used to Unix. If not, or you don't bother to customize it, there's always fish. There is no place for bash.
[1] https://github.com/fish-shell/fish-shell/issues/438
[2] https://github.com/barosl/baroslized-settings/blob/master/.z...
Ah yes, the Emacs and Vim school of configuration.
The only time when POSIX incompatibility still hurts is if your workflow requires you to be source shell snippets.
The reason I'm having a hard time imagining how a scripting system that relies on bash would fail with fish is because I can't imagine how one would actually write a script that is executed with the user's login shell. There's no #! line that would do that by accident.
It's an easy fix, just add the line, otherwise 0755 scripts with no #! do execute using the current shell.
> cat foo
echo wat
> ./foo
Failed to execute process './foo'. Reason:
exec: Exec format error
The file './foo' is marked as an executable but could not be run by the operating system.
Unless you want to define "bad" as "ignorant of some facet of computing" in which case we all fit.
Just curious, why do you say this? I've used bash for years for basic command line things and now it sounds like I've been missing out on great features that other shells have.
I believe the world could have been a better place if they adopted fish as a default shell.
There are a few things that, while I understand why fish is missing them, I wish would be added:
- vi-mode, obviously
- Control+R. It is annoying to have to guess how much you must type before hitting the up arrow, instead of having it dynamically displayed. Same goes for zsh vi-mode's ? command.
- Well more of a removal, but the backslash in single-quoted strings. I'm used to typing '\', and that's not possible with fish. Additionally, to get one backslash in any sort of regex (sed, grep), you need four backslashes.
- Goes without saying, but bash-completion. Fish's completion is mostly history-based, which is great for repeatedly running the same command, but terrible for discoverability
- "$()" and any non-splitting command substitution. Currently, it is impossible to pass a multi-line string from a command substitution as a single argument. Which, it may be argued, should be done by piping, but sometimes it is useful to have stdin.
- More extensibility in general. I'd like to be able to customize my shell just as much as I can customize my WM. Probably more.
Honestly, it was easier to go back to using bash than I thought it would be -- it was almost a relief. fish just feels more polished and clean, especially with regard to escaping, but it misses some very important features.
Edit: I heard that there is a vi-mode now. Sounds interesting, but I don't really feel like installing it at the moment, and if I ever try another shell it'll probably be zsh.
As you said at the end, Fish does have this. I don't know if it's full-featured enough for you though.
> Control+R. It is annoying to have to guess how much you must type before hitting the up arrow, instead of having it dynamically displayed
When you start typing a command-line in Fish that matches a previously-typed command, it automatically shows the rest of the line as an available completion, and pressing ^F or the right arrow will complete it for you. The lack of this functionality actually really kills my ability to use any other shell.
> Currently, it is impossible to pass a multi-line string from a command substitution as a single argument
Not actually true. If you set IFS to '' then that disables command substitution line splitting. That said, it is not well-known and is rather awkward. This is a known pain point with Fish today.
> More extensibility in general. I'd like to be able to customize my shell just as much as I can customize my WM. Probably more.
It's really hard to know what you're asking for here. What isn't extensible enough for you? What do you wish you could do that you can't?
^R is more powerful, though; it matches at any point in previous commands, not just at the beginning.
> The lack of this functionality actually really kills my ability to use any other shell.
You can achieve that behavior in readline (which is used by bash, python shell, etc.) by changing the up/down arrows from previous-history/next-history to history-search-backward/history-search-forward. In ~/.inputrc:
"\e[A": history-search-backward
"\e[B": history-search-forward
That's how it works in Fish as well.
user@system ~> echo wow
wow
user@system ~> echo something
something
user@system ~> wow█
user@system ~> echo wow█ (reverse-i-search)`w': echo wow
> echo w̲ow
The difference is that typing an additional character after having moved in the history will start editing, appending the character to the line, instead of appending to the criteria.
What I miss in all of them is looking for a fuzzy match instead of a substring match.
In fish you just type 'w' hit the up arrow and then hit enter to execute or any motion keys to edit. The same number of keypresses as well.
Am I misunderstanding?
zsh definitely has this command, which I absolutely adore to be honest. ^R is one of my favourite features of the shell in general.
No you can't. What I specifically described was the autocomplete of the line, not the ability to search history (which is manual complete instead of autocomplete).
It's not anyone's cup of tea, but I'm using percol to get similar functionality:
(taken from oh-my-fish)
* pip install percol
* make a function like this:
function percol_select_history
history|percol|read foo
if [ $foo ]
commandline $foo
else
commandline ''
end
end
function fish_user_key_bindings
bind \cr percol_select_history
end
If you clear out your logfiles by trashing /private/var/log/asl/*.asl, there's a pretty decent speedup.
Do you have any insight as to why this happens? It smells like some kind of log parsing to present messages on login, but I've never received any such messages, and a quick vgrep of the various profile/rc's never turned anything up.
I wrote a framework to help deal with the shell a little bit after getting fed up with OMZ's slowness: https://github.com/tubbo/homer
This is a piece of technology we used to have and then somehow lost. Common Lisp uses ~ as the control character for format strings. C uses \ as the control charcter for raw strings, and % as the control character for format strings. HTML uses &. But regexps use \. JSON uses \. And JSON is a new format! \ was literally the worst possible choice. As soon as you have multiple formats sharing a control character, you start to need huge power-of-two runs of it in order to say what you mean.
Who thought it was a good idea to reuse control characters? \ is used in raw string definitions. It should not be used in any other format, if strings might be used to invoke that format. This is a clear case where every standard doing its own unique thing is the correct approach, but we seem to be moving in the other direction.
E.g. on some patterns involving *. Care to share your setup?
I may switch to zsh eventually, but I just switched shells and I don't really want to do it again very soon.
Fish has both kinds of completion. You can hit tab to get a list of possible completions (command-list based) if there is more than one, if there is only one possible command it will tab-complete. You can also customize this list.
No you didn't. I use vim and fish just fine. Just put this in your .vimrc:
set shell=/bin/bashOnly problem is it's not POSIX so there is some weirdness in command substitution, logical operators and stuff. So you still script in sh.
If I'm motivated enough to download and install a shell, why wouldn't I just clone Prezto and change one config file to turn on syntax highlighting and git support? Especially when it doesn't bring any "weirdness in command substitution" and I get the great zsh expansions and completions?
Anyways, I'll try it out (why not?) but the benefit to me wasn't clear from the page, and even with your direct clarification here I'm seeing more downsides than zsh + Prezto and not a significant upside.
Writing tab completions in fish is really, really simple. It's the thing that initially sold me and it's kept me hooked.
The history is more powerful than bash, too. Although I find it sometimes works against me. E.g., since it tries to guess your command, things you type in lowercase suddenly turn to uppercase until you manage to disambiguate from a previous command.
If you're looking for plugins, there's oh-my-fish [1]. Years back, the term "fish-nuggets" was popular and you'll find repos named that on GitHub with other configuration. I use a couple plugins, but for the most part I don't need them. I think part of that is because fish is featureful out of the box and part of it is because customizing is so easy. I'll usually just add what I need myself rather than trying to find a general purpose plugin.
Anyway, not a direct answer to your question -- apologies for that. Hopefully something in there is of use for you, however.
Loop constructs and defining temporary functions in particular seem much more natural to my brain.
I used it as my main shell for about two years (on OSX even), but had to give it up due to a broken command-not-found handler (long story, but increased my quality of life with non-global bundler so much I went back to zsh).
Yeah some wild-card matching stuff doesn't work, also for example expanding `pkg-config --cflags gobject-2.0` as one would in bash requires calling eval gcc.
On the other-hand it's not like Bash doesn't have weird gotcha's -- for example does anyone remember which of these is a valid conditional?
string='Foo Bar';
if [[ *"Foo"* == $string ]]
if [[ $string == *"Foo"* ]]I created a language called bish that allows you to write your shell scripts in a sane and comfortable syntax. No more remembering which one of those conditionals to use! Bish compiles to bash, so you also get to keep all of the portability that comes with bash scripts. I haven't had much time to work on it recently, and it's still missing some features, but it's ready to use now:
Long ago. IIRC this is the thing that translates something looking sort of like a subset of (Python? Haskell? C? I can't remember which.) into mostly-working Bash. It's a terrible idea.
Bash is a fine tool, but it has a number of flaws that prevent me from using it for certain tasks.
* Functions can only return a status number. Functions are always subshells.
* The hashtable (associative array) syntax is unpalatable, unreadable, and a real abomination. I simply don't use it, because it gives me a headache.
* I can never remember the horrible syntax for most string functions.
* You cannot reasonably store an arbitrary json structure in memory. Embedded lists and hashtables are absolutely unwieldy.
* Bash has no concept of FFI (Foreign-function interface). So, you cannot load an external library and invoke functions it it.
These problems are not particularly impossible to solve, but the Bash authors will probably never do it. Therefore, the final reproach against bash is that they do not publish their source code in an environment similar to github, where users can file their issues and improvement requests. In other words, the bash authors are not in communion with their users.
In what way can the fish shell address these problems?
Actually had to look that one up[1] -- unfortunately you're right, it's not posix (I don't think I would've tried it in a [ed: non-interactive] script, but I agree it is very nice).
I wonder if you could make a function as a work-around, something like:
r() {
#r(first some args <(second other args))
# Use a fifo:
ff=$(mktemp fifo)
# might as well use that for parsing the commands...
echo "$*" > $ff
first=`sed -re 's/\((.*) <\(.*/\1/p' < ${ff}`
echo "$*" > $ff
second=`sed -re 's/\(.* <\((.*)\)/\1/p' < ${ff}`
${second} > $ff &
${first} < $ff
}
I'm not convinced trying to parse shell command lines for macro functionality is a good idea in general...
http://arstechnica.com/information-technology/2005/12/linux-...
I hadn't really thought about that echo'ing the filename might be useful, but this is pretty equivalent to how things work in bash -- with "diff <(some) <(other)", diff gets two temporary file-handles to two fifos -- that are later cleaned up by the shell. As most good ideas, obvious when you think about it :-)
[In Bourne shell] A function can just print to stdout, and the caller can capture it. In this way, a function has two outputs: an exit status, and a (normally text) result.
It's unusual to go any further, but if you really wanted to you could make a function return any number of outputs by writing to different file descriptors and having the caller capture them all separately.
I use zsh with https://github.com/zsh-users/zsh-syntax-highlighting zsh fish like syntax hilighting and am much more happy.
Would you mind elaborating here? I'm very honestly curious how the deal gets broken for you.
To explain my curiosity, I've long since come to the opinion that we're in the midst of a long, somewhat painful split caused by a design dissonance over improving the interactive shell UX versus creating a better environment for scripting.
We've been building alternatives around the scripting problem for ages now, perhaps most notably starting with Perl's ascendance. That legacy continues with Python, Ruby, and now many other tools. I'll still reach for bash/zsh as a scripting tool, but only when the situation absolutely will not admit an extra dependency. In my experience, the pain factor goes up far more quickly with code complexity when it's all just gotta be done in POSIX/bash land.
As for the interactive shell UX, fish is notable for simply putting its foot down and just saying "no" to the scripting side. It pushes out POSIX scripting compatibility as an external feature. Calling bash is now on the same level as calling out to {Perl, et. al.}. Whether or not fish is your cup of tea, it's inspired a bunch of competing work in the traditional interactive shells.
At the current time, the above efforts are simply going in different directions. We have numerous better options for rich automation than POSIX shell scripting. Likewise, shell scripting just gets in the way of creating better, extensible developer/admin CLI environments. It has too many quirks (hi, quoting hell!) and limitations (real data structures, please) to work well for an extensibility platform.
I find Fish to be simpler to use and more powerful by default. You can probably have a zsh or maybe even bash setup which does the same fish does, but I don't want to do that.
Another thing is writing scripts and completions functions with fish, it's a way better experience than zsh. Writing completion stuff using zsh is really painful.
The preview with the autocompletion is really cool, but maybe you can have that with zsh too.
And then there's the speed, it's totally not objective but IIRC my prezto setup was quite a bit slower.
In the end I just really appreciate that I don't have to spend time customizing my shell: now I install fish on my VMs or servers, and everything is like I want it without me doing anything.
If you're happily using prezto you may not have much to gain from using fish, and you may not even like it since there's stuff from prezto you won't find out of the box.
(edit: this was a reply to the post below.. not sure how I messed that up.. gah.. such a noob)
The main issues I have compared to zsh are:
- No bracketed paste mode. If I select multiple lines of text and middle-click-paste into zsh, it adds the whole lot as a multi-line input and lets me review the commands before pressing Return. fish just starts blindly executing them, which can cause accidents.
- Chaining commands is harder. In zsh `foo |& less` pipes stdout and stderr. Also, fish's `foo; and bar` is longer than `foo && bar`.
- Hashes in words start a comment in fish. e.g. `opam pin repo#branch` is treated as `opam pin repo`, pinning the wrong branch. zsh only treats # as a comment at the start of a new word.
- While completion history and `set -U` are really useful, it sometimes forgets everything and I have to start again, which is quite annoying.
On the whole, very happy with it though!
I remember installing and using fish 4 or 5 years ago; it was not a great experience -- but after he "took over", I switched and couldn't be happier with fish.
So if there is such a policy at Apple, I would expect that it doesn't prohibit contributing to already-public projects.
antigen bundle tarruda/zsh-autosuggestions
The positive side of this is that fish is very simple and has a very pleasant experience out of the box. And this is not just about having "good defaults" - its also about having a good design that encourages having one way to do things. That said, an interactive shell is a very personal thing. The only way to really get a good feeling is to install and check it out.
I'd encourage you to check it out. The scripting language in Fish is the best I've ever used for a shell. But it's also incompatible with Bash/zsh.
- not assuming you're using an outdated terminal so doesn't waste a column when using a right-hand prompt?
- lots of async calls, thus really fast.
I actually think that design document could be a good start for a lot of projects.
[0] https://github.com/fish-shell/fish-shell/issues/1549 [1] http://mumak.net/undistract-me/
edit: Just installed the beta and implemented it (status WorksForMe) https://github.com/qznc/dot/commit/8cf55564383ed93af148234d2...
I can already do sane scripting, with Python. I suspect that as soon as I try to to anything slightly complicated, Python leaves fish scripting behind.
When you compare the *nix shells to PowerShell, they feel prehistoric. We all use grep, sed, awk, and the likes, but don't you get tired of having to deal with unstructured data and gross limitations of the shell like basic data structures. Yes, the purpose of the shell is to be quick and dirty, but it doesn't take that much to add some programming sanity and some standards for structured data! There's a port of PowerShell to Mono, Pash [0], but it's so heavy in terms of requirements and has somewhat unclear future. Of course, there's also Xonsh [1] and Xiki [2], but they are pretty new.
[0] https://pash-project.github.io/
[2] http://xiki.org/
P.S. One of my favorite Fish feature is Event Handling [3].
I don't in fact get tired of unstructured data and the limitations of the shell like basic data structures because nine times out of 10 the data I have to work with in a shell is exactly that. Unstructured and basic. Not because of the shell but because the source of that data provides it that way.
Powershell with it's intense focus on fancy datastructures makes something like
sed '/foo/d'
If I want something more powerful for working with structured data I'll use Python or Julia.
The sed command is not a shell. You can use sed in PowerShell.
Fish won't become PowerShell, that's for sure. I like the idea of PowerShell, but it's a bit too ugly in person. I'm happy enough with cmd, cmder, and Python for scripting.
On the other hand, Fish is mostly focused on being a powerful interactive shell. Its all about having good auto completion (fueled by parsing manpages), history search, etc.
I do believe that its very hard to have a shell language thats good at these two domains at the same time and that we are better off having separate languages for each. Trying to solve both these problems at once is what made bash into the mess it is now in the first place.
I know I learned Bash 15 years ago, but it's not just familiarity that's causing the confusion
> fish is a smart and user-friendly command line shell for OS X, Linux, and the rest of the family.
I'd wager majority of OSX users are not going to be changing shells, but by specifically enumerating OSX as the first example use, it feels like the others are mere afterthoughts.
Would be better put:
> fish is a smart and user-friendly command line shell for the entire *nix family.
If this were documentation the change should be made, but it's probably not the right move on a website focused on promotion.
I don't mind the incompatibility to bash, but using "; and" instead of "&&" is a little annoying.
Everything else is great.
It actually auto-completes remote hosts and paths when you type ssh or scp commands! It also fuzzy-completes filenames when you're lazy (or have typos in them) and a bunch of other neat things.
The up-key function after typing in parts of a command and ^F have probably saved me hours of time wasted in bash.
I must say I am not a huge shell wizard and use only a handful of custom functions, but I've found shell to be very pleasant to work with and would recommend it to any web developer who doesn't get "dirty" with shell scripting a lot.
The only problem I had was that I had to explicitly set the shell used by vim in order to make vim plugins / configs work properly by using this line:
set shell=/bin/bash
Filenames are getting very long w/ so many special characters, this is great. I also like the idea of having a web based config. I really won't miss wrestling with bashrc and bashconfig in vi. Definitely will try this.
What I like about fish shell is the same why I use the i3 tiling window manager. It has sane defaults and it clicks with how expect things to work, how I would design them. Sane defaults mean a minimal config file so it's easy to look up problems and change things.
I'd at least try it out if I were you.
In any case, bash -- in one of its many forms, colors, and sizes -- is what I usually find myself in front of.
JS is standard issue in 2015, come on out of the bunker.
Useless frills are buggy and slow.
However, how do you work around the lack of <() and >()? E.g. if I want to do the equivalent of
$ diff <(xzcat foo.xz) <(xzcat bar.xz)
EDIT: nevermind, I see the fish version is
$ diff (xzcat foo.xz|psub) (xzcat bar.xz|psub)
I loved the overall friendliness though, it was a genuine pleasure to use for the most part. I hope to use it as my default shell again some time in the future.
I use something similar: tux instead of frogs and a personal fortunes file. Mine also prints the current date, hostname and uptime.
Yes. urxvt is pretty minimal and will likely be rather ugly by default. However, you can customize pretty much everything via editing your Xresources file.
In terms of advantages over gnome-terminal... it's lighter weight and considerably faster (though tbh, speed isn't that important for most people). It doesn't depend on any Gnome services/libraries, so it integrates better with e.g. a tiling WM. It's stable, in the sense of the developers won't cut <insert feature> out. The configuration is very flexible and it's extensible.
However, to be honest it's not for everybody. I wouldn't even say it's for "power users", it's really mostly for minimalists and the default configuration is incredibly sparse. If you're dissatisfied with gnome-terminal, I'd probably recommend roxterm or lxterminal instead. IMO, urxvt is more one of those "I already know I want it and I know why I want it" kind of things. That said, I've been using it for a few years and I really like it.
* not the only one, but I'm not sure finalterm is really ready to use yet, and it's certainly not lightweight.
Edit: Hmm, it doesn't seem to work properly in 9.20. Well, I should probably be using tmux anyway, which does fix the problem.
As simple as possible, and no simpler.
It does nothing that impresses other terminal authors. Other terminal authors seem to prioritize user experience beneath keeping up with the achievements of other terminal authors. So it is completely incapable of 3-d widget animations, or transparent viewing of 3-d accelerated VDPAU movie rendering via transparency, or any number of things that are extremely technically challenging and "desktoppy" and very impressive to other terminal authors but users primarily see as something that makes it slow and crash alot and complicated and distracting.
To quickly try it with a larger font size, you can do urxvt -fn 'xft:Dejavu Sans Mono:size=10' (but it's usually configured through X resources, see the urxvt man page)
Guake is a dropdown terminal made for the GNOME desktop environment
This because they consider any usage that deviate from their planning a indication that the user is an idiot...
Give it a try at least :-)
It's good, but quite a few things are incompatible from what I remember after trying it a year ago.