Watches over your Cargo project's source.

Last update: Dec 30, 2022

Overview

$ cargo watch

Cargo Watch watches over your project's source for changes, and runs Cargo commands when they occur.

If you've used nodemon, guard, or entr, it will probably feel familiar.

In the public domain / licensed with CC0.
Uses Caretaker Maintainership.
Website and more documentation: watchexec.github.io.
Minimum Supported Rust Version: 1.51.0.

Install

Pre-built binaries are available from the website or alternatively on the Github Releases tab. Since 7.8.0, checksums and signatures are also provided; see download documentation for details.

$ cargo install cargo-watch

With cargo-binstall:

$ cargo binstall cargo-watch

Or clone and build with $ cargo build then place in your $PATH.

This repository contains a manual page and Zsh completions that you may want to install.

Usage

By default, it runs check. You can easily override this, though:

$ cargo watch [-x command]...

A few examples:

# Run tests only
$ cargo watch -x test

# Run check then tests
$ cargo watch -x check -x test

# Run run with arguments
$ cargo watch -x 'run -- --some-arg'

# Run an arbitrary command
$ cargo watch -- echo Hello world

# Run with features passed to cargo
$ cargo watch --features "foo,bar"

There's a lot more you can do! Here's a copy of the help:

USAGE:
    cargo watch [FLAGS] [OPTIONS]

FLAGS:
    -c, --clear              Clear the screen before each run
    -h, --help               Display this message
        --ignore-nothing     Ignore nothing, not even target/ and .git/
        --debug              Show debug output
        --why                Show paths that changed
    -q, --quiet              Suppress output from cargo-watch itself
        --no-gitignore       Don’t use .gitignore files
        --no-ignore          Don’t use .ignore files
        --no-restart         Don’t restart command while it’s still running
        --poll               Force use of polling for file changes
        --postpone           Postpone first run until a file changes
    -V, --version            Display version information
        --watch-when-idle    Ignore events emitted while the commands run.
                             Will become default behaviour in 8.0.

OPTIONS:
    -x, --exec <cmd>...
            Cargo command(s) to execute on changes [default: check]

    -s, --shell <cmd>...           Shell command(s) to execute on changes

    -d, --delay <delay>
            File updates debounce delay in seconds [default: 0.5]

        --features <features>
            List of features passed to cargo invocations

    -i, --ignore <pattern>...      Ignore a glob/gitignore-style pattern

    -B <rust-backtrace>
            Inject RUST_BACKTRACE=VALUE (generally you want to set it to 1)
            into the environment

        --use-shell <use-shell>
            Use a different shell. E.g. --use-shell=bash. On Windows, try
            --use-shell=powershell, which will become the default in 8.0.

    -w, --watch <watch>...
            Watch specific file(s) or folder(s) [default: .]

    -C, --workdir <workdir>
            Change working directory before running command [default: crate root]

ARGS:
    <cmd:trail>...    Full command to run. -x and -s will be ignored!

Cargo commands (-x) are always executed before shell commands (-s). You can use
the `-- command` style instead, note you'll need to use full commands, it won't
prefix `cargo` for you.

By default, your entire project is watched, except for the target/ and .git/
folders, and your .ignore and .gitignore files are used to filter paths.

On Windows, patterns given to -i have forward slashes (/) automatically
converted to backward ones (\) to ease command portability.

Ignore files

.gitignore files are used by default to ignore paths to watch and trigger runs. To stop honouring them, pass --no-gitignore.

.ignore files in the same syntax are also used by default. This file can be used to specify files that should be ignored by cargo watch but checked into git, without constantly adding --ignore abc options on the command-line. Do note that .ignore files may also be used by other programs, like ripgrep. To stop honouring these, pass --no-ignore.

Cargo watch also has an internal list of default ignores on top of those specified in files, like target/ and .git/ and various other common types (logs, editor swap files, lockfiles, etc).

To skip absolutely all ignores, use the --ignore-nothing flag.

.git/info/exclude and the global $HOME/.gitignore and similar ignore files are not supported yet.

Ignore syntax

See the Glob patterns page for a description of how they work in the context of this tool. That’s the syntax used for the --ignore option.

Additionally, some specific quirks and behaviours:

On Windows, patterns should be specified with Windows-style (\\) separators. Unix-style separators (/) would not match Windows paths, which could be confusing and give the appearance of commandline ignores not working.
From Cargo Watch 7.0.0, / in commandline ignores are automatically translated to \\ when running on Windows, but one should still try to write the correct patterns for the platform, as there may be more subtle differences.
From Cargo Watch 7.3.0, --ignore patterns were fixed to provide better experience with directory matching. Previously, ignoring a folder would need unyieldy -i folder/** patterns; now that is handled internally, and only -i folder is needed for the same effect.

Reloading servers seamlessly

Cargo Watch pairs very well with systemfd/Catflap, tools for Unixy platforms that lets one spawn a socket before the watcher runs that Rust servers can then bind to, avoiding request-dropping and the infamous ADDRINUSE error. For example:

$ systemfd --no-pid -s http::5000 -- cargo watch -x run

Of course, if you don't need to guard against these issues or don't want to modify your program to grab sockets instead of ports, you can use Cargo Watch as-is: it will happily just restart your server normally.

Restarting an application only if the build/check succeeds

Brought up by @LeDominik, here's a pattern that may be very useful: you're working on a server or app, but want it to keep running while you're writing a new feature or fixing a bug, potentially causing the code not to compile anymore in the meantime.

In this case, you can use this strategy: run a first cargo watch with check, build, test, or whatever you want, and append -s 'touch .trigger (or equivalent for your platform). Then, run a second cargo watch simultaneously that only watches that .trigger file. For example:

$ cargo watch -x check -s 'touch .trigger'

and

$ cargo watch --no-gitignore -w .trigger -x run

The --no-gitignore flag ensures that you can safely add .trigger to your .gitignore file to avoid mistakenly committing it.

Troubleshooting

In all cases, start by checking your version with cargo watch --version and, if necessary, upgrading to the latest one.

RLS is slow while using cargo watch, or vice versa, or it's waiting for the project lock a lot

Cargo builds (and checks, and clippy, and tests because the tests have to be built) take out a lock on the project so two cargo instances don't run at the same time.

However, Rust Analyzer is much better at this, so use that instead of RLS.

On Windows 7 (or lower): "failed to add to job object: Access denied (OS Error 5)"

Cargo Watch versions 5.0.0 and up (and Watchexec versions 1.3.0 and up) do not support Windows 7 or lower. Support will not be added. Issues for Windows <=7 will be closed. If it works, lucky you, but that is not intentional.

I want to run cargo-watch directly, without going through cargo

You can! But you'll have to specify the watch subcommand as the first argument, like so:

$ /path/to/cargo-watch watch -x build

I want to run cargo-watch outside of a Cargo project

That's not supported. If you have a good reason to use a Cargo-specific tool outside a Cargo project, please open an issue! Otherwise, you'll probably be best served with using Watchexec.

If file updates seems to never trigger

Try using --poll to force the polling fallback.

If that still doesn't work, and you're using an editor that does "safe saving", like IntelliJ / PyCharm, you may have to disable "safe saving" as that may prevent file notifications from being generated properly.

Also try using the --why option to see if the paths you expect are changing.

Linux: If it fails to watch some deep directories but not others / "No space left on device"

You may have hit the inotify watch limit. Here's a summary of what this means and how to increase it.

If you want to only recompile one Cargo workspace member crate

Watching one or more specific workspace member is not natively supported yet, although you can use -w folder to approximate it.

Watching the entire workspace and running a command in one member is done via the usual -p option on the child command:

$ cargo watch -x 'build -p subcrate'

If it runs repeatedly without touching anything

That can happen when watching files that are modified by the command you're running.

If you're only running compiles or checks (i.e. any command that only affects the target/ folder) and you're using -w, you might be confusing the target-folder-ignorer. Check your options and paths.

You can also use the --watch-when-idle flag to ignore any event that happens while the command is running. This will become the default in 8.0.

If it runs repeatedly only touching ignored files

Make sure the files you ignored are the only ones being touched. Use the --why option to see exactly which files were modified and triggered the restart. Some programs and libraries create temporary files that may not match a simple ignore pattern.

As above, you can also use the --watch-when-idle flag to help.

I don't have colour in my cargo output / for cargo test

This sometimes happens on some terminal configurations or for test harnesses. A quick workaround (instead of going down the rabbit hole of debugging your console settings) is to pass --color=always to the command. E.g.

$ cargo watch -x 'check --color=always'

For test (and bench) commands, you'll need to pass the flag to the underlying program instead of cargo:

$ cargo watch -x 'test -- --color=always'

I want to compile my build with additional features

$ cargo watch --features foo,bar

will run cargo check --features foo,bar on every watched change.

The --features will be passed to every supported cargo subcommand.

$ cargo watch --features foo,bar -x build -x doc

will run both build and doc with the foo and bar features.

Something not covered above / I have a feature request

Please open an issue, or look through the existing ones. You may also want to look through issues for the Notify library this tool depends on, or the issues for the Watchexec tool that we use under the covers (where I am also a maintainer).

If you want more verbose output, try running with the --debug flag. Note that this will also enable debug mode for watchexec. When filing an issue, make sure to include a log with --debug enabled so problems can be diagnosed.

If your issue is a watchexec issue, open it there directly. If you're not sure, feel free to open it here, but if it is a watchexec issue, it will get closed in favour of the upstream issue.

I want to embed Cargo Watch in my own (Rust) tool

It is not recommended to do that directly. You may of course call cargo-watch as any other program, and technically it exposes an (undocumented) library that could be directly / statically embedded. If you have no other option, that may be your best bet.

However, for most cases, consider building on top of Watchexec instead. That is itself built on Notify, and both of these can be used as Rust libraries.

If you want to build a tool that runs, restarts, and otherwise manages commands in response to file changes, you'll most probably want to use Watchexec.
If you want to build a tool that responds to file changes, but does not need to run commands, or does so in a way that is not well-supported by Watchexec, then Notify is your ticket.

Wait, is this just a wrapper on top of watchexec?

Kind of! Watchexec does a really good job of watching files and running commands and all the details that go with this. Cargo Watch uses the Watchexec library interface and calls it with its own custom options, defaults, and particularities, so you can just run cargo-watch in your project and be in business.

When asking questions and/or filing bugs, keep in mind that Cargo Watch and Watchexec share the same maintainer at the moment (but Notify does not, anymore)!

About

Created by Félix Saparelli and awesome contributors.

Comments

workflow for server development

when building a server (eg: a webserver that listen on port 3000), it could be useful to automatically kill the already running server (after successful re-compilation) before starting the new one. otherwise, the server cannot start again because the old one still listen to the same port.

here is a log of what is going, if the server is not killed:

# run rshello cargo watch run
$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`

$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 98, message: "Address already in use" } })', ../src/libcore/result.rs:738
Process didn't exit successfully: `target/debug/hello_world` (exit code: 101)
-> exit code: 101

$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 98, message: "Address already in use" } })', ../src/libcore/result.rs:738
Process didn't exit successfully: `target/debug/hello_world` (exit code: 101)

enhancement upstream

opened by mathroc 64

Cargo watch never triggers on OS X El Capitan
I'm new to Rust, so I'm probably doing something stupid. I installed by running cargo install cargo-watch.

When I run cargo watch and edit a file, tests don't seem to run. It just says Waiting for changes... Hit Ctrl-C to stop. and nothing seems to happen after that.

paul ~/projects/iron master $ ls src/ && cargo watch & main.rs [1]+ running: cargo watch & & (2635) paul ~/projects/iron master $ echo "" >> src/main.rs paul ~/projects/iron master $ fg [1]+ running: cargo watch & (2635) Waiting for changes... Hit Ctrl-C to stop. ^C
bug
opened by paulkernfeld 25
-i has confusing semantics
Cargo watch doesn't ignore app.db even though I have it in .gitignore and even when I pass it to the command like: cargo watch -i app.db -x "run -p mybin" (I'm running this in a workspace where mybin is the binary I want to run.)

My .gitignore looks like this:

target .env app.db

I'm on Windows 8.1. When my exe writes to app.db, it triggers cargo watch to restart the exe, why?
help wanted upstream needs-fix
opened by Boscop 22
Feature Suggestion: conditional run
I really like the practice of keeping cargo check running continuously in the background thanks to this awesome tool. But recently I really wish the following would be possible: Do something like cargo watch -x check -x run with a twist:

If a file changes run check without terminating the application (in my case a rocket application)

If check succeeds, then terminate the application and do the run...

This would be really nice, as it would only restart the server if it's actually safe to do so. Hence I can keep hacking around and trying the current (running) version safely until the code compiles again. Maybe that's something that only seems useful to me, but I really believe this would be super-handy...
opened by LeDominik 18
Add option to only display the amount of lines a terminal has for each run

I'm always finding myself scrolling to the top of the last ran cargo run to start working on errors. I prefer working on first errors first. It would be nice if cargo-watch could just stop outputing once it hits the end of my terminal so I don't have to scroll up.

I would be willing to work on a fork for this if you could give me some guidance on where to start
upstream feature

opened by twiclo 14

Failing tests: tests/snapshots out of date

It looks like the latest few releases have broken tests caused by a change in loggin output. Not sure when it happened, but it's causing tests to fail. Here's the output from running cargo test locally on my machine:

     Running target/debug/deps/echo-7079832437b58e65

running 4 tests
test with_poll ... FAILED
test with_announce ... FAILED
test without_announce ... FAILED
test with_error ... FAILED

failures:

---- with_poll stdout ----
thread 'with_poll' panicked at 'Unexpected failure.
code=<interrupted>
stderr=```"WARN - Polling for changes every 500ms ms\n"```
code=<interrupted>
stdout=```""```
stderr=```"WARN - Polling for changes every 500ms ms\n"```
', /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-1.0.3/src/assert.rs:149:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- with_announce stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Differences ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: tests/snapshots/echo__with_announce.stderr.snap
Snapshot: with_announce.stderr
Source: tests/echo.rs:132
-old snapshot
+new results
───────────────────────────────────────────────────────────────────────────────────
std_to_string(&mut main.stderr)
────────────┬──────────────────────────────────────────────────────────────────────
    1       │-WARN - Polling for changes every 500 ms
    2       │-
          1 │+WARN - Polling for changes every 500ms ms
          2 │+
────────────┴──────────────────────────────────────────────────────────────────────
stored new snapshot /Users/david/Developer/src/cargo-watch/tests/snapshots/echo__with_announce.stderr.snap.new
To update snapshots run `cargo insta review`
thread 'with_announce' panicked at 'snapshot assertion for 'with_announce.stderr' failed in line 132', /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/insta-0.16.1/src/runtime.rs:995:9

---- without_announce stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Differences ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: tests/snapshots/echo__without_announce.stdout.snap
Snapshot: without_announce.stdout
Source: tests/echo.rs:167
-old snapshot
+new results
───────────────────────────────────────────────────────────────────────────────────
std_to_string(&mut main.stdout)
────────────┬──────────────────────────────────────────────────────────────────────
    1       │-without announce
    2       │-
────────────┴──────────────────────────────────────────────────────────────────────
stored new snapshot /Users/david/Developer/src/cargo-watch/tests/snapshots/echo__without_announce.stdout.snap.new
To update snapshots run `cargo insta review`
thread 'without_announce' panicked at 'snapshot assertion for 'without_announce.stdout' failed in line 167', /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/insta-0.16.1/src/runtime.rs:995:9

---- with_error stdout ----
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Snapshot Differences ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Snapshot file: tests/snapshots/echo__with_error.stderr.snap
Snapshot: with_error.stderr
Source: tests/echo.rs:202
-old snapshot
+new results
───────────────────────────────────────────────────────────────────────────────────
std_to_string(&mut main.stderr)
────────────┬──────────────────────────────────────────────────────────────────────
    1       │-WARN - Polling for changes every 500 ms
    2       │-
          1 │+WARN - Polling for changes every 500ms ms
          2 │+
────────────┴──────────────────────────────────────────────────────────────────────
stored new snapshot /Users/david/Developer/src/cargo-watch/tests/snapshots/echo__with_error.stderr.snap.new
To update snapshots run `cargo insta review`
thread 'with_error' panicked at 'snapshot assertion for 'with_error.stderr' failed in line 202', /Users/david/.cargo/registry/src/github.com-1ecc6299db9ec823/insta-0.16.1/src/runtime.rs:995:9


failures:
    with_announce
    with_error
    with_poll
    without_announce

test result: FAILED. 0 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out; finished in 30.19s

I think this might be related to Jenkins not having been run during the last few releases.

opened by davidarmstronglewis 13

Error when containing a non accessable directory

I've tried to use cargo-watch in my project. As I'm using docker-compose for my database, there is a folder which is only accessible by root with my configuration which is also in .gitignore. I also tried to exclude this directory with the ignore-argument.

However, when executing cargo-watch I'm getting this error:

Error: I/O error: Permission denied (os error 13)

I think that the tool should also run with such files/folders inside my project. I've fixed it temporarly with chmod -R 777 but I don't think that is the way to go.

If this issue is accepted to be fixed I would be happy to contribute that part :+1:

debug output:

$ cargo watch --debug -x run
>>> Load Git/VCS ignores: true
>>> Default ignores: ["*/.DS_Store", "*.sw?", "*.sw?x", "#*#", ".#*", ".*.kate-swp", "*/.hg/**", "*/.git/**", "*/.svn/**", "*.db", "*.db-*", "*/*.db-journal/**", "*/target/**"]
>>> All ignores: ["*/.DS_Store", "*.sw?", "*.sw?x", "#*#", ".#*", ".*.kate-swp", "*/.hg/**", "*/.git/**", "*/.svn/**", "*.db", "*.db-*", "*/*.db-journal/**", "*/target/**"]
>>> File updates debounce: 0.5 seconds
>>> Commands: ["cargo run"]
>>> Watches: ["."]
>>> Watchexec arguments: Args { cmd: ["cargo run"], paths: ["."], filters: [], ignores: ["*/.DS_Store", "*.sw?", "*.sw?x", "#*#", ".#*", ".*.kate-swp", "*/.hg/**", "*/.git/**", "*/.svn/**", "*.db", "*.db-*", "*/*.db-journal/**", "*/target/**"], clear_screen: false, signal: None, restart: true, debounce: 500, debug: true, run_initially: true, no_shell: false, no_vcs_ignore: false, no_ignore: false, once: false, poll: false, poll_interval: 500 }
*** glob converted to regex: Glob { glob: "target/**", re: "(?-u)^target(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([Literal('t'), Literal('a'), Literal('r'), Literal('g'), Literal('e'), Literal('t'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "**/*.rs.bk/**", re: "(?-u)^(?:/?|.*/)[^/]*\\.rs\\.bk(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([RecursivePrefix, ZeroOrMore, Literal('.'), Literal('r'), Literal('s'), Literal('.'), Literal('b'), Literal('k'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "**/db/**", re: "(?-u)^(?:/?|.*/)db(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('d'), Literal('b'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "**/world.txt/**", re: "(?-u)^(?:/?|.*/)world\\.txt(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('w'), Literal('o'), Literal('r'), Literal('l'), Literal('d'), Literal('.'), Literal('t'), Literal('x'), Literal('t'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "**/.env/**", re: "(?-u)^(?:/?|.*/)\\.env(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('.'), Literal('e'), Literal('n'), Literal('v'), RecursiveSuffix]) }
*** built glob set; 0 literals, 0 basenames, 0 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 5 regexes
*** Loaded "/home/maex/projects/own/cronjob-as-a-service/.gitignore"
*** Adding ignore: "*/.DS_Store"
*** Adding ignore: "*.sw?"
*** Adding ignore: "*.sw?x"
*** Adding ignore: "**/#*#"
*** Adding ignore: "**/.#*"
*** Adding ignore: "**/.*.kate-swp"
*** Adding ignore: "*/.hg/**"
*** Adding ignore: "*/.git/**"
*** Adding ignore: "*/.svn/**"
*** Adding ignore: "*.db"
*** Adding ignore: "*.db-*"
*** Adding ignore: "*/*.db-journal/**"
*** Adding ignore: "*/target/**"
*** glob converted to regex: Glob { glob: "*.sw?", re: "(?-u)^.*\\.sw.$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('.'), Literal('s'), Literal('w'), Any]) }
*** glob converted to regex: Glob { glob: "*.sw?x", re: "(?-u)^.*\\.sw.x$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('.'), Literal('s'), Literal('w'), Any, Literal('x')]) }
*** glob converted to regex: Glob { glob: "**/#*#", re: "(?-u)^(?:/?|.*/)\\#.*\\#$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('#'), ZeroOrMore, Literal('#')]) }
*** glob converted to regex: Glob { glob: "**/.#*", re: "(?-u)^(?:/?|.*/)\\.\\#.*$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([RecursivePrefix, Literal('.'), Literal('#'), ZeroOrMore]) }
*** glob converted to regex: Glob { glob: "*/.hg/**", re: "(?-u)^.*/\\.hg(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('/'), Literal('.'), Literal('h'), Literal('g'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "*/.git/**", re: "(?-u)^.*/\\.git(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('/'), Literal('.'), Literal('g'), Literal('i'), Literal('t'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "*/.svn/**", re: "(?-u)^.*/\\.svn(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('/'), Literal('.'), Literal('s'), Literal('v'), Literal('n'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "*.db-*", re: "(?-u)^.*\\.db\\-.*$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('.'), Literal('d'), Literal('b'), Literal('-'), ZeroOrMore]) }
*** glob converted to regex: Glob { glob: "*/*.db-journal/**", re: "(?-u)^.*/.*\\.db\\-journal(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('/'), ZeroOrMore, Literal('.'), Literal('d'), Literal('b'), Literal('-'), Literal('j'), Literal('o'), Literal('u'), Literal('r'), Literal('n'), Literal('a'), Literal('l'), RecursiveSuffix]) }
*** glob converted to regex: Glob { glob: "*/target/**", re: "(?-u)^.*/target(?:/?|/.*)$", opts: GlobOptions { case_insensitive: false, literal_separator: false, backslash_escape: true }, tokens: Tokens([ZeroOrMore, Literal('/'), Literal('t'), Literal('a'), Literal('r'), Literal('g'), Literal('e'), Literal('t'), RecursiveSuffix]) }
*** built glob set; 0 literals, 0 basenames, 1 extensions, 0 prefixes, 1 suffixes, 1 required extensions, 10 regexes
Error: I/O error: Permission denied (os error 13)

bug enhancement upstream

opened by mstruebing 13

Not compiling when module is saved

When I'm editing files in a module and click save my intentions are to compile, however rust-watch is not compiling. I have to go into lib.rs or a bin file and save before it compiles.

Is this intended functionality or a bug?

opened by GTB3NW 13

`cargo watch -x run -- --data-dir ./data` doesn't work

> cargo watch -x run -- --data-dir ./data
error: Found argument '--data-dir' which wasn't expected, or isn't valid in this context

USAGE:
    cargo watch [FLAGS] [OPTIONS]

For more information try --help

What works is cargo watch -x "run -- --data-dir ./data", but I don't believe it should be necessary.

enhancement

opened by dpc 12

Multiple commands broken in Powershell
At work I do my programming on a Windows 10 machine and have cargo watch running in the background to recompile everything, generate docs, and run the test suite. If you pass multiple --exec commands the last one always fails with a message like:

$ cargo watch --exec test --exec doc [Running 'cargo test error: no such subcommand: `doc']` Did you mean `doc`?

It looks like cargo watch injects a trailing ' or some other character which breaks the command. I've attached the output when passing in the --debug flag. output.txt

Just out of curiosity, why do you use the local shell instead of executing the commands as a subprocess (using std::process::Command) directly? Wouldn't that give more consistent behaviour?
opened by Michael-F-Bryan 12
Should it run the command upon start up, before any files are modified?

Proposal: When cargo watch starts, run the command, even if no file has changed.

I've often started cargo watch when started working on a project, and it clearly doesn't do anything until a file has changed. Sometimes I can't remember if all the tests passed (or if the code compiles), and I'd like to see the output of cargo test. So I need to make a simple change to something so that it'll run and I can see. But if cargo watch ran the command as soon as it was started, this would be easier.

But maybe that's my workflow, does this sound useful to other people?

opened by amandasaurus 12
Support --stdin-quit functionality
The core behaviour has been added to the watchexec lib so we update to the latest watchexec and add the flag & hook into the runtime to get the desired behaviour.

This follows the same pattern as the implementation for the watchexec binary. I hope it is satisfactory.

No rush on this. I realise it involves releasing watchexec and updating this reference which may or may not be something you plan to do soon.

Checklist

[ ] Switch to explicit version of watchexec when published (rather than a git sha ref)
opened by michaeljones 1
Ability to modify signal used to terminate process and/or wait for shutdown?

I love cargo watch, and use it all the time. I'm hitting an issue now though where I need to perform some cleanup/teardown prior to shutting down the watched process (I need some syscalls to complete in order to be able to re-run the process).

Unless I'm missing something, there's no ability to add a delay or customize the shutdown signal sent to the process, is that correct? I think in a perfect world, I'd be able to send a SIGINT, wait some number of seconds, and then follow it up with a SIGKILL if the process still hadn't exited.

Apologies if I'm missing some combination of features that make this already possible. I'm also open to contributing, if this is a feature that doesn't exist but you're interested in. Thanks!

opened by brownjohnf 1

Compilation failed while installing cargo-watch on Docker

Hello, I'm trying to install using cargo install cargo-watch in a fresh Docker image linux/amd64 based. No success due to compilation error on the termcolor crate.

Environment

Docker 20.10
Macbook Pro M1, macOS Monterey 12.1
Docker Hub image official image, rust:latest linux:amd64
rustc 1.62.1 (e092d0b6b 2022-07-16)
cargo 1.62.1 (a748cf5a3 2022-06-08)

Steps

$ cargo install cargo-watch

Updating crates.io index      
Installing cargo-watch v8.1.2   
...

Output

Compiling termcolor v1.1.3

/usr/local/rustup/toolchains/1.62.1-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-1bde28880ea8bde8.so(+0x4e54e3)[0x40021864e3]
...
/usr/local/rustup/toolchains/1.62.1-x86_64-unknown-linux-gnu/bin/../lib/libstd-69edc9ac8de4d39c.so(rust_metadata_std_8996aeeb2a45fe64+0xab3c3)[0x4005ccb3c3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7)[0x4005fb2ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x40060d4def]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
error: could not compile `strsim`

Caused by:
  process didn't exit successfully: `rustc --crate-name strsim /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/strsim-0.8.0/src/lib.rs --error-format=json --json=d
iagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C panic=abort -C linker-plugin-lto -C codegen-units=1 -C met
adata=7c4474c11a45725d -C extra-filename=-7c4474c11a45725d --out-dir /tmp/cargo-installJwbEQY/release/deps -L dependency=/tmp/cargo-installJwbEQY/release/deps --cap-lints al
low` (signal: 11, SIGSEGV: invalid memory reference)

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
error: could not compile `termcolor`

Caused by:
  process didn't exit successfully: `rustc --crate-name termcolor --edition=2018 /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/termcolor-1.1.3/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C panic=abort -C linker-plugin-lto -C codegen-units=1 -C metadata=9ea925993c53af48 -C extra-filename=-9ea925993c53af48 --out-dir /tmp/cargo-installJwbEQY/release/deps -L dependency=/tmp/cargo-installJwbEQY/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference)

Conclusion

It seems like it's getting a segmentation fault while compiling strsim on emulated environments?

Anyway, I appreciate any help in case anyone already faced the same issue. Thanks in advance.

bug upstream needs-repro

opened by leandronsp 1

Print the duration
I like to know how much time it takes to run the compilation and test tasks.

It would be nice if cargo-watch could include the duration in the finish statement. Maybe something like:

[Finished running. Exit status: 0. Duration: 20s]
feature-accepted
opened by jcornaz 0
Magic support for cargo xtask

One annoyance with cargo xtask patterns is that in many cases, the xtask command only works from the root of the workspace. Cargo Watch could solve this, though, because things running inside Cargo Watch are already wrapped by nature of running processes from other processes, so we can do magic as part of that wrapping.

For example, we could parse cargo config and figure out if an xtask alias is defined, and if it is, we could replace it in the command environment (with CARGO_ALIAS_XTASK=...) with something that always works from the particular working directory we're invoking the command from.

[This issue is not a confirmed feature, and may not be implemented.]
feature

opened by passcod 0
Ignore only the target-dir or target-dirs that are in use

The default is currently just **/target/ (*/target/** before 9.0), which ignores all folders named target. This can be undesirable, so we could figure out where the target-dir is, and only ignore that. In the case of super workspaces (#205), there could be multiple target-dirs in play. Also, the Cargo config may affect their location.
enhancement

opened by passcod 0