Files which do not finish executing are not re-executed

[who]

If trigger watches a file which contains some sort of loop or long-running task, and the watched file changes, trigger does not re-execute. It would be nice to have an option where trigger would abort all previous executions of a script, even if they are still running, when it detects changes to one or more of the watched files.

Here's a repro:

1) Create index.js:

setInterval(function(){
  console.log('The time is: '+(new Date()).getTime())
}, 1000);

2) Start watching index.js with a trigger:

$ tg node index.js
The time is: 1468882653074
The time is: 1468882654075
...
...
...

3) Execute a touch on index.js

$ touch index.js

4) Note that trigger does not re-launch node index.js

[sharkdp]

Thank you for the report. The current behavior is indeed intentional, but I agree that it would be nice to have an option (--force? --interrupt?) with the described behavior.

The child process would probably have to be run in the background and inotifywait would then trigger the termination & re-execution of the child process.

I'd certainly be interested in a PR, if you have a concrete idea on how to implement this. Otherwise, I can also take a look.

[who]

The trouble with adding options to the existing command is that the trigger script consumes 1...n parameters as file names to monitor. If you added an option for --interrupt, and you also wanted trigger to monitor a silly file named --interrupt, there would be a conflict in file/option processing.

I guess it would work to require parameters to come immediately after trigger:

Good: trigger --interrupt nodejs index.js

Bad: trigger nodejs index.js --interrupt

[sharkdp]

If you added an option for --interrupt, and you also wanted trigger to monitor a silly file named --interrupt, there would be a conflict in file/option processing.

I think this kind of problem is usually solved by passing -- to separate options from arguments, like so:

trigger nodejs --interrupt -- index.js --silly-file

On the other hand...

I guess it would work to require parameters to come immediately after trigger:

Good: trigger --interrupt nodejs index.js

... I think this would be a very good solution for trigger :+1:

[sharkdp]

Resolved in the newest version