ref. https://github.com/passcod/cargo-watch/issues/127
This adds support for a dedicated ignore file by the name of `.ignore` a
la `fd`, `ripgrep`, et. al.
This purely just mimics what `Gitignore` is doing except it doesn't
ignore `.git` directories. There might be more I need to tweak and the
interface might be too obtuse, but this is a first pass.
I've also added a `--no-ignore` flag which ignores both `.gitignore` and
the dedicated `.ignore`. It might make sense to add a specific flag that
ignores `.ignore` but respects `.gitignore` to support the old
behaviour, but I wasn't sure what to name it.
The options were out of date (e.g. `-d` was debug). This updates them to
match the help text.
This also adds some documentation about separating the command with --
so that clap doesn't eat the flags intended for the command.
A client may pass non-canonicalized paths into `watch`, and these are therefore not matched against the filters correctly. Thus, some events could call a Handler's `on_update` method even when an ignored file was changed.
See repro: https://github.com/SpiralP/rust-cargo-watch-test
This bug was introduced in aae5a216b0.
Instead of special-casing the callback, which is the path least-taken,
switch the internals to a Handler model, where the default behaviour is
an implementation of a Handler, and external callers can implement their
own Handlers and pass them in.
While doing so, change all unwraps in run::run to returning Errs, and
expand the watchexec Error enum to accommodate. That should make it
easier to use as a library.
Also, differentiate between "manual" and "on update" runs. For now the
only manual run is the initial run, but this paves the way for e.g.
keyboard- or signal- triggered runs.
This makes it possible to run commands that allocates TTYs and still
capture their output and reap the process on completion.
> setpgid — set process group ID for job control
> setsid — create session and set process group ID
With this in place, the `waitpid` call detects that the process has
exited even if the process allocated a TTY, and is able to unblock the
runner and continue.
Further, the output of the command is also shown in the controlling
terminal.
