Passing argument to application beginning with @ gives strange error

[kentonv]

watchexec 1.24.0 on Linux

If I try to pass an argument to the application (after --) which starts with an @ sign, I get this error:

thread 'main' panicked at /home/kenton/.cargo/registry/src/index.crates.io-6f17d22bba15001f/watchexec-cli-1.24.0/src/args.rs:1054:79:
called `Result::unwrap()` on an `Err` value: Custom { kind: NotFound, error: Error { kind: OpenFile, source: Os { code: 2, kind: NotFound, message: "No such file or directory" }, path: "my-application-argument" } }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It looks like this is due to a feature that expands argument lists from a file when prefixed with @. The problem can be solved by prefixing the @ with \\. It would help to provide an explicit error message here explaining this, as it took me a while to understand what was going on.

Even with a better error message, though, this feature feels a bit dangerous. In my case (using bazel), the string after such an @ argument usually isn't a valid path, so I just get an error. But if I were using an application that did expect a path after @, I might inadvertently cause watchexec to read the file and expand it with arbitrary effects. Maybe this feature should not apply after --, or should be enabled by an explicit flag?

Note that many shells have built-in functionality to achieve the same thing. For instance, in bash I can write $(<filename).

[passcod]

Huh, that's annoying. I changed this from a custom implementation to the argfile crate recently, but didn't check it would have the exact same behaviour (it seemed a simple enough crate!). I'll investigate if it's watchexec or argfile, and possibly revert to my implementation if it needs fixing upstream.

Edit: to be clear, this absolutely should not apply after --.

Also, thanks for the detailed error reports!

[kentonv]

FWIW I didn't have any problem passing @-prefixed args to Bazel until recently, but it's possible I simply hadn't updated my watchexec binary in a year or two.

[passcod]

Got a fix up for it at the linked PR; you may want to test it works with your workflow. I'll release later today.

[kentonv]

Can confirm this solves my problem. Thanks!