I used fish for a long time, but lost patience with the incompatibility with other shells. It’s nice to be able to just paste and run someone else’s command, and I eventually tired of having to rewrite every command to use fish syntax. For example, replacing FOO= with set - x … The reverse is even worse—if I need to send someone a command to run, I have to rewrite it in a syntax that’s likely to work when they run it. It only takes a few seconds each time but I grew weary of it.

That’s accepted now, and was always available by prepending env.

They have improved compatibility a lot.

Also, you could do what I do: leave bash or something else as the default, and then just run fish manually.

Then if I have a problem pasting or something I run type exit.

But the incompatibilities are a lot less now.

You can just do `bash -c "CMD"`.

occasionally you'll need to run a command which sources or exports… it's no silver bullet in my experience anyway

Check out fish-foreign-env, bass, and babelfish

create a key-binding to invoke your terminal with bash. I have not set fish as my system shell (aka chsh)

I was in a similar situation 2 years ago and I took the plunge. Turns out, the amount I had to rewrite was fairly minimal, and the benefits of Fish are just incredible. I'd say: go for it, you won't regret it!

Personally, I'm a lover of subshells, I often write things like (cd mydir && make), making use of the fact the 'cd mydir' only happens in the subshell.

Fish doesn't have anything like that, there are a few workaround, but none of them are (in my opinion) anywhere near as nice.

You should instead

    pushd /my/path && command && popd

Both in bash AND in fish!

the problem with that is I ended up in the wrong directory if I press ctrl+c, or in the exact examples you give, if command fails.

If it's just make you're doing that for "make -C mydir" does that and puts you back in the original directory when it's done.

I do this too (in zsh), but maybe writing a function callable like this would work:

  with mydir make

Although you'd want to be able to write things like

  with mydir make && ./bin/myprog

and parse everything to the right of `mydir' as a shell pipeline. That might be the sticking point in fish.

I use this a lot in my scripts - handy when you want to capture the output or execute a command in a different directory.

    set output (echo captured)
    echo $output
    > captured

And if you wanna run a command in another dir:

    pushd other_dir
    run_command
    popd

zsh has survived for longer (it's "Lindy") and is therefore more widely available on remote machines. Also, maybe just my problem, but I do get frustrated having to switch back to bash/zsh syntax and semantics in cases where Fish isn't available, or when writing scripts others will use. Easier for me to stick with zsh for my shell and bash for shipping shell scripts.

zsh tends to actually run scripts when you feed them. As long as you can resist the urge to run all of your POSIX scripts in fish, I think I much prefer fish as an interactive shell.

Exactly. Falling back to Bash to run scripts makes life easier. Just add a Bash shebang at the top and you're good to go.

Last time I looked into switching the vim mode in zsh was better by enough of a margin that I didn't switch, but that was years ago. I've been meaning to give fish another shot.

You can 1. Make your scripts executable or 2. Use bash / zsh inside of fish. 3. You can define wrapper functions in fish that just call bash/zsh functions internally. I use fish, although I hate writing scripts in it. It just feels wrong. Better stick to good old bash.

For copying and pasting while preserving environments, you can always use `exec` as an escape hatch.

  exec bash
  <paste some bash>
  exec fish

process substitution?

fish: Invalid redirection target: yq3 r <(kubectl get nodes -o yaml)

You can do process substitution by piping into the psub command ;)

juice is not worth the squeeze

<(blah) vs (blah | psub)