"not bash compliant" really is the main deal-breaker. When you're getting technical support on some issue and somebody tells you to paste a command into your terminal, "bash compliance" (or at least POSIX-shell compliance) is pretty important. When your phone rings at 2AM and somebody asks you to urgently fix a production problem and you can't figure out what's going on because the production server doesn't have your custom shell installed, that's a problem.
It's not a deal-breaker, of course. If you become fluent in POSIX-shell you can translate between it and your custom shell, and things should be fine... but becoming fluent in two shells is a lot more work than becoming fluent in one shell.
If you never need to interact with other people's machines, and other people never have to interact with yours, then sure, go nuts and install whatever shell you want.
If you install fish on your local machine, you'll still be able to run bash and punch those commands right into it—just do
$ bash
And hey presto, back in bash land.
I agree that it makes sense to know the lowest common denominator well before you go after something better—especially as you'll know straight away if and why it's "better".
Slightly OT, but I honestly think that "community best of" projects like oh-my-zss and the Vim ones actually do people a disservice since they are not zsh or Vim, but rather someone's opinionated, non-standard version of them.
All your executable shell scripts should start with a hash-bang indicating the executable that interprets them. If your script runs on your custom shell and it's not installed, it'll let you know instantly.
We found one annoying case[0], and one critical case[1].
The annoying case is vim plugins that use $SHELL to execute some bash/sh code. The workaround is to specify `set shell=sh` in .vimrc. We did not attempt to address this in fish (I didn't check but I would guess that tcsh is affected the same way).
The critical case is, at the login window, OpenSUSE invokes the login shell with a POSIX-ism (specifically 'exec "${@}"'), which was not recognized by fish. So setting fish as your login shell would lock OpenSUSE users out of their machines entirely!
What we did was hack fish to recognize exactly this command in its arguments, and handle it the way OpenSUSE expects, via a new function "fish_xdm_login_hack_hack_hack_hack". Heh.
There are several simplifications of POSIX syntax; the syntax feels a bit like Tcl as a result.
The most annoying differences are the missing/changed special variables: POSIX has special $@/$* to return parameters: you have to use arrays for these in fish. POSIX puts exit status in $? and fish in $status; also $$ becomes %self, and there is no convenient way to expand to the PPID. Also annoying is the absence of "||" and "&&" operators.
That's because the syntax was redesigned to be more orthogonal. So $ is always followed by a word to expand a variable and not an arcane symbol, % is used for a wide variety of ways to get process ID's, and it's easy to set up arrays besides just $argv (plus if you do $argv on its own, it creates one word for every item in the array, without you having to worry about bizarre quoting).
Most of these differences, and why they were made, are explained in the manual.
If 'or' is 'just a command', I would think the shell would evaluate $cmd3 before calling $cmd2. Or are 'and' and 'or' built-ins that are similar to Lisp special forms/Forth immediate words?
I recently tried setting fish as my default default and I encountered some trouble, for example my $PATH was incomplete (there was only /bin, /usr/bin and /usr/local/bin left in it if I recall correctly).
I reverted it back to bash and I get fish as my shell by spawning "urxvt -e fish" instead of "urxvt" (in my window manager configuration). This works well.
You're aware you can configure your PATH trivially from fish, right? The preferred way to do that would be something like
if status --is-interactive
set PATH ~/.local/bin /opt/local/bin $PATH
end
in your ~/.config/fish/config.fish file. Your other shells have the paths you want either because you configured them that way at some point, or because their global configs (e.g. /etc/bashrc) have broader paths. There's nothing magic going on here.
Oh, that explains why I need to run sudo with the -i option sometimes while using fish as my default shell! I'm going to try setting my shell to bash, and configuring my window manager to run fish in terminals. Who knows what other variables I'm missing out on...
I've been using it comfortably for a while as my primary shell with no issues. Pretty much all scripts I've had to run use a shebang line to manually invoke /bin/sh or /bin/bash which still works fine.
This is a feature. See https://github.com/fish-shell/fish-shell/issues/683. It appears to work in bash, but only because globs simply write themselves if they won't find anything. The behavior is misleading. But also having to escape ? is somewhat annoying.
Also, URLs with & don't work in bash anyway. Or rather, they will work, but do something you wouldn't expect - it would ignore & and everything after it, and run command in the background.
Please note that zsh works similarly to fish. Well, mostly. It seems that zsh has special logic that automatically inserts backslash before ? if it detects an URL. Perhaps that could be implemented in fish. But it also feels somewhat magical. Why "\?" would appear when I type "?"? But perhaps it's the best way. In your case, it's possible to break it. But the break looks really contrived, so perhaps zsh behavior would be safe.
[glitchmr@pineapple tmp]$ mkdir -p https://news.ycombinator.com
[glitchmr@pineapple tmp]$ touch https://news.ycombinator.com/itemsid=5723235
[glitchmr@pineapple tmp]$ wget https://news.ycombinator.com/item?id=5723235
--2013-05-17 13:39:09-- https://news.ycombinator.com/itemsid=5723235
Resolving news.ycombinator.com (news.ycombinator.com)... 184.172.10.74
Connecting to news.ycombinator.com (news.ycombinator.com)|184.172.10.74|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-05-17 13:39:10 ERROR 404: Not Found.
Right, makes perfect sense of course as the standard goes.
Sometimes just wish URLs were handled in special way in shells. Fish isn't compatible with bash, couldn't it go step further? Some magic isn't always bad...
You give bash more credit than it deserves. `wget url?a=1&b=2` is parsed as`wget url?a=1 & ; b=2` ie, it runs `wget url?a=1` in the background and sets the shell variable b=2.
I'm going to give it a go regardless but wanted to know if there were pitfalls and what people have done to alleviate them.
[0] https://wiki.archlinux.org/index.php/Fish#Troubleshooting