From the tutorial: "fish has excellent help and man pages. Run help to open help in a web browser, and man to open it in a man page."

I haven't installed it yet, but it sounds like the same information is in both places. Given its dependency on doxygen, I think it's very likely.

You can see help pages on command line with 'man commandname' or with 'commandname --help'

Regarding customizing your prompt, try running 'fish_config' and check list of already available prompts from prompts tab.

The built-in web browser is a cute feature, but all the prompts waste space with <username>@<hostname>.

Autocompletion - a feature I generally don't use in other contexts - and reduced functionality seem to be its main USPs. With readline, process substitution and subshells (for ad-hoc fork/join jobs started from the command line) it might be competitive with other shells.

For example, a reasonably common pattern for me, on the command line, is:

    $ for d in *; do 
    test -d "$d" || continue
    (
    cd "$d"
    time-consuming-task-1
    time-consuming-task-2
    ) &
    done

I don't think I could do this in fish today without writing a script, as it doesn't have subshells and can't run functions in the background.

There's also a big advantage in having the shell be the same (or highly similar) to your preferred ad-hoc scripting language. It means you can retrieve complex commands from your history and paste them into the script, with only a slight cleanup to parameterize them. A whole complex operation can be spiked and tested interactively before being put together into something reusable - possibly without foreknowledge that the task is going to be that tedious, or needs to be encapsulated. Zsh looks like a better alternative to bash for these reasons.

This should be the translation:

    for d in *
        test -d $d
        or continue
        begin
            cd $d
            time-consuming-task-1
            time-consuming-task-2
        end &
    end

However it errors; seems you can't do `end &`. Probably a bug; I'll report it. When fixed, I imagine we could actually do it even better with fish:

    for d in *
        if test -d $d
            cd $d
            time-consuming-task-1
            time-consuming-task-2
        end &
    end

Fish currently does not support executing shell functions or commands in the background with &, only external programs. This is a known omission, but the best way to fix it is to make the shell interpreter code thread safe so we can actually write multithreaded shell code. Currently fish only uses threads for potentially blocking i/o operations. But implementing this is quite a bit of work and has not been done yet.

Having said that, `enc &` erroring is indeed a bug, expected behavior would be to run the `begin ... end &` block in the foreground anyway.

the documentation is in a local file, so it works on the plane.

to edit the default prompt (or any function):

    funced fish_prompt

will launch your editor. then:

    funcsave fish_prompt

to persist a copy in your user's configuration.

all shell instances will pick it up right away, no need to close, relaunch or source anything.

Do you know the equivalent to Alt+. in readline?

And how to incrementally search the history (i.e. anywhere in the command, not just the start of the line like the autocomplete)?

And does fish really need to separate out its subshell from text substitution? E.g. I'd write 'echo "my host is $(hostname)."' in bash, but in fish I seem to need to use 'echo "my host is " (hostname) "."', which is a lot more fiddly, noisy, ugly etc.

And do you know the equivalent of <() in bash? I use that with fgrep -f a lot. And (<todo.txt)? That's another one I use in workflows, though (cat todo.txt) would be a verbose alternative.

(I actually don't use fish full time, been experimenting once in a while)

I believe Alt+. (or any kind of history substitution) hasn't been implemented by design. I don't have references handy but they should be easy to find.

Incremental history search is just type something and then up arrow.

The rest of your questions I don't know the answers but it wouldn't surprise me if there were none. Fish prefers to have a simple and coherent syntax to a concise one (though I agree the text substitution is annoying – it seems they usually put the subshell result in a variable and expand that in the string).

This helps understanding their design goals http://ridiculousfish.com/shell/user_doc/html/design.html

Updated design documentation can be found at http://fishshell.com/docs/2.0/design.html

Thanks for your answers.

Incremental search isn't too bad once I found out about bind and the other key bindings, as the arrow keys are some distance from the home keys.

Lack of Alt+. quickly became annoying. It's so useful; meanwhile, prefix search isn't a significant improvement over incremental search, and I usually know ahead of time whether my command is in the history or not, so being prompted an irrelevance is more annoying than having to type Ctrl+R in readline. I disable auto-completion in browsers, Google etc. for similar reasons.

You're right about not much else. Command substitution is the only thing implemented, not subshells or process substitution. I probably exercise my shell more than average, so I don't think fish is feature-rich enough yet for me.

It's a good thing the design goals have been updated to remove "a large performance decrease [...] is acceptable in order to improve [modularity]". That would have been a total killer. Process forking is often a performance limitation for me in the shell, so I strive, wherever possible, to use the builtins that fish so proudly spurned.

<($cmd) is called "process substitution." The fish equivalent is

($cmd | psub)

I miss incremental history search myself -- that's probably my most used bash feature. Typing a few letters and then hitting C-P or up arrow works, but there's no way to refine the search if you don't get the result you're looking for.

     echo my host is (hostname).

Doesn't need quotes.