When the completion list includes the exact typed string with other
candidates, i.e. completion_t.match.type == fuzzy_match_exact,
the other candidates will be removed from the list, as they are not
the "best type". This is inconvenient for the user who wants to
type and complete commands in the other candidates.
The commit is to make the best_type to fuzzy_match_prefix as highest
priority, also, when comparing to best_type, the same or higher
priority completions can both match.
With this change, jobs only track their block-level redirections. Process level redirections are correctly associated with the process, and at exec time we stitch them together (block, pipe, and process redirects).
This fixes the weird issues where redirects bleed across pipelines (like #877), and also allows us to play with the order in which redirections are applied, since the final list is constructed right before it's needed. This lets us put pipes after block level redirections but before process level redirections, so that a 2>&1-type redirection gets picked up after the pipe, i.e. it should fix https://github.com/fish-shell/fish-shell/issues/110
This is a significant change. The tests all pass. Cross your fingers.
It's rather hacky, but it sort of works. (but then, this makes fish
compare to PHP (but PHP doesn't put that newline), so perhaps I
shouldn't do that - http://git.io/GFurbg)
m4_esyscmd_s is a macro only available in Autoconf 2.64, which despite
being released in 2009 is not available on a number of build targets for
the project (specifically CentOS/RHEL 6).
ca8e4c08a7 tries to remove the error produced with m4_pattern_allow,
but that just silences the sanity check.
Instead, replace m4_esyscmd_s with m4_esyscmd + manual removal of
newlines.
I break compatibility with Mac OS X again, that I don't have access
to. Result: Stuff break, and I have to fix it, so it will perhaps
work. At least, I hope it will work.
Yes, it's an awful hack, but IPC support (and fork support as well -
even FAQ mentions that, and suggests "restarting process" to solve the
problem (http://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures),
but let's ignore that for now) is simply broken in Cygwin. Having to try
to do exactly same thing in Cygwin, just so perhaps it will work is a
completely normal thing (not). I love Windows.
