This prevents cases like `cd /usr/e` from tab-completing to
`cd /usr/` (which is the shared prefix of the tab completions).
Things are still sort of confusing with fuzzy matching, e.g.
with files like this:
foo1bar
foo2bar
Then ba<tab> will replace the token with foo. That's surprising,
but not new to this fix.
Fixes#1727
There is no CTRL-C handler for the default mode in the vi bindings. This makes it difficult to say "never mind" and start a new command line like you can do in bash's vi mode.
There were CTRL-C handlers for insert and visual modes that go back to default mode, but nothing happens in default mode. I copy-pasted the CTRL-C handler from the default key bindings file.
The PROCESS_EXIT event takes 3 args: event name, pid, status. However,
when fish is exiting, the PROCESS_EXIT is instead given the status of
whether the last commandline parsed successfully. Change it to use the
same value that fish itself is going to exit with.
When calculating the version, we don't need to test for the presence of
.git before running `git describe`. This lets us work properly in a
detached work tree if GIT_DIR is set.
(Ideally, the behaviour of git could be implemented: pipe the input
through a pager iff the length is > window size and in interactive
mode).
Closes#1076.
Work on #1073.
fish is not exclusively distributed under the GPL version 2; the
canonical reference is doc_src/license.hdr, so use that as the full
description.
[skip ci]
Prior to this fix, a child process may be reaped in one of two ways:
1. By a call to waitpid() within job_continue
2. By a call to waitpid() within the SIGCHLD signal handler
Only the second call was with the WNOHANG option. Thus if the signal
handler fired first, and then the waitpid call fired, we could get a
deadlock because we'd end up waiting on a long-running process. I have
not been able to reproduce this on fish 1.x, though it seems like it
ought to reproduce there too.
This fix migrates the waitpid() call out of the signal handler; the
second class of calls moves to job_reap. This eliminates the possibility
of a race, because we check for job completion before calling waitpid,
and there is no longer the possibility of the job being marked as
complete asynchronously. It also results in a massive conceptual
simplification, since the signal handler is now very simple and easy to
reason about (no more walking jobs lists, etc).
This partially fixes a bug reported in #1273
