emcrisostomo
Feature: Option to exit non-zero when interrupted
The man page clearly says
When it receives a SIGABRT, SIGINT or SIGTERM signal, fswatch
closes the notification streams and exits gracefully returning 0 to the calling process.
However a flag to let fswatch exit with non-0 when signaled would make some shell scripting use cases less painful....
Typically when developing, I write a quick loop like this (bash) and leave it running in a background shell:
while fswatch -1 src/... ; do
check_syntax && \
run_tests && \
echo OK || echo FAILED
date "+%Y-%m-%d_%H-%M-%S"
done
BUT when I ^C to kill the loop (waiting at fswatch), fswatch exists with success and the loop immediately continues executing again. So I have to ^C multiple times to get the prompt back and make whatever change.
This kind of change would have to be flag-protected to be sure that we don't break existing users. Some possible flags / suggested implementations:
--abort-on-signal-- error exit on any signal--abort-on-signals=INT,QUIT-- error exit only on specified signals
Hi, I just want to say thanks that your code/program/snippet solves my problem :)
Long story: I was using like this:
fswatch -o0 "$src_path" | while read -d ""; do \
make
for outfile in $( find ./${out_path}/*.${out_expr} ); do \
$outfile;
done
done
and it made my Ctrl-C failed to work (to terminate the child process).
I stubbed my toe on this recently, too...
IMHO, if you're using -1, then ^C should return failure, always.
Returning 0 in "infinite loop" mode makes total sense — killing the process is the "normal" way for it to exit, and you want to know if it died for some OTHER reason — but when I'm asking for "one" event, I'm expecting "one" event; if it was kill(1)-ed beforehand, that's a problem and I want to know about it.
The current behavior violates the Principle of Least Astonishment, IMHO.
Anyway, I've submitted a "Simplest Thing That Can Possibly Work" PR: #313
- https://github.com/emcrisostomo/fswatch/compare/master...DabeDotCom:fswatch:one-event-exit-signal
