Closed nestor-custodio closed 1 year ago
Thank you for the fix!
Indeed, thank you for the fix. Apologies for being silent about it. I am excited to check it out and merge...
Also: I have recently had some exciting ideas around the concept of 'rerun2', and maybe if you are interested in this repo, you might be interested. At the very least, they might result in 'rerun2' gaining some new cmdline options to exercise more control over which files are watched or ignored (and then using rerun2 from some other closely related scripts, which are useful both from the command-line, and from a GUI). I'll post a description as a new issue.
Thanks again, this is brilliant.
Fixes #13.
This also eliminates a lot of string manipulation by defining the cooldown in seconds and doing all comparisons on nanosecond timestamps. It does introduce one
printf
call and onesed
invocation, but these happen outside of the inotify/wait loop, so are only called once.Worth noting:
-n
/-z
checks instead of== "true"
/== "false"
.If/when this PR is approved and merged, I'll have a follow-up PR for several issues I've identified relating to
--verbose
behaviour (and$changes
management) being broken:--verbose
is not in play, the$changes
variable is (unnecessarily) written to and never cleared. This results in runaway memory usage on (very long running)rerun2
instances.--verbose
is in play, the$changes
variable is never actually cleared within theexecute
function due to it being run from within a subshell. I've spent hours researching a fix for this, and the only solution I've landed on is that the$changes
data should actually reside within a temp file* so that it is accessible and manipulatable both within the inotify/wait loop and within theexecute
function.$cooldown_s
seconds elapse between when the subshell is spawned and when theexecute
function runs, any inotify events that happen in the meantime (i.e. during the cooldown/wait period) are not known toexecute
when it reports what changes have been seen. (The version of$changes
in the inotify/wait loop is being updated during this time, but the shell doesn't see these changes as it was spawned in the past.) These will then be reported during the nextexecute
call, which won't happen until an indeterminate time in the future. Again, storing the$changes
data in a temp file* instead will correct this issue as well.* Note that by "temp file" I mean an actual temp file or possibly a shared memory location that is accessible across the two shells. Again, this will be implemented in a forthcoming PR and I'll be sure to document how/why I landed on one option vs the other.