Félix Saparelli
Félix Saparelli
@oclyke Sorry for the late answer, but if you could run with `--print-events` (in watchexec), and then show the events that are triggering your loop, that would help!
Right, I see what you mean. I _think_ that's an inherent limitation of fsevents (something like "a modify event happened that concerned this file, but i'm not telling you if...
Thanks @tekacs! I think that @oclyke's issue is a subtly different one; in any case I'll keep this bug open until I get cargo watch updated to the latest watchexec.
noting #562 as variant of this
With the (new, in-development) "filter programs" feature, this is (will be) possible fairly easily: https://github.com/watchexec/watchexec/discussions/592#discussioncomment-5896857
Filter programs have landed in 2.0.0, [this program](https://github.com/watchexec/watchexec/discussions/592#discussioncomment-5896857) implements checking hashes. Closing this issue; I may still implement this "natively" but at a latter point.
Hmm, annoying. I'll put that on the pile but don't have a quick fix nor time at the moment sorry.
Confirming this is still an issue on PostgreSQL 12, 13, 14, and 16 (tested all versions I could just in case). I'm going to give fixing it a go.
Hmm, maybe just having a way to expose the process ID of the running expression, so Duct-users can still get its abstractions but also call OS functions directly? I'm actually...
That… could work, yes. Especially combined with an externalised `sh` from the other issue, so I could build commands whether they be straight calls or shell calls, attach the control...