bitbucket/overview | download 2.8
$ find . -name '*.c' | entr make
$ ls *.md | entr +notify & $ while read F; do > markdown2html $F > done < notify
Interactive SQL: OGG (47.0M, theora-vorbis) | WEBM (14.2M, vp8-vorbis)
The Event Notify Test Runner is a general-purpose UNIX utility intended to make rapid feedback and automated testing natural and completely ordinary.
$ ls *.css *.html | entr xombrero -e "reload"
It's not uncommon for modern web frameworks to continuously hunt for file system changes and refreshes the page when run in single threaded or standalone mode. Contrast this with common daemons which simply respond to signals. The following will reload nginx every time it's configuration is modified
$ ls /etc/nginx/nginx.conf | entr pkill -HUP nginx
In general, entr avoids special purpose options that can easily emulated using inline commands, for example one-shot mode can be emulated by running sh -c 'kill $PPID'. However, the need to kill and restart a process is a very common development task, so an auto-reload feature was added in the 1.9 release, and is enabled using the -r flag
$ ls *.rb | entr -r ruby main.rb
Unlike guard, entr is a zero-configuration tool with no external build or runtime dependencies. The interface to entr is not only minimal, it aims to be simple enough to create a new category of ad hoc automation. These micro-tests reduce keystrokes, but more importantly they emphasize the utility of automated checks.
Tightening the edit-debug feedback loop requires a tool that is tuned for one task. inotifywait is lightweight, but it only works on Linux, and it's general feature set doesn't provide a direct means of saying “run this command if any of these files change”. This could be scripted, but there are a number of significant conditions to contend with:
Finally, FIFO mode provides a means creating more sophisticated scripts by relaying the names of altered filenames through a named pipe. The watch script is a nice example of this use case.
entr adheres to the principle of separation of concerns, yet the reload (-r) option was added to solve a common use case that would otherwise require some careful scripting. Other special-purpose flags were added because they reduce highly repetitive actions or reduce friction.
One of the most repetitive actions was to clear the screen before running tests; hence the -c flag:
$ find src/ | entr -c ./test.sh
The special /_ argument (somewhat analogous to $_ in Perl) provides a quick way to refer to the first file that changed. When a single file is listed this is a handy way to avoid typing a pathname twice:
$ echo /path/to/my.sql | entr psql -f /_
I've been writing as if incorporating automated responses can be accomplished without special demands on the UNIX development environment, but in practice the ability to split a window into multiple panes is the key to making this workflow sing. If your window manager doesn't give you this capability a terminal multiplexer such as tmux(1) enables you to quickly spit the screen so that you can see the results as you work.
tmux steps automation up to the next level by enabling you to control applications in other panes via keystrokes. This combination can be wired up in any number of ways to create some very interesting auto-responders. Consider the following
With this mechanism in place we can fetch and compare headers using any tool that's capable of printing output or writing to a file—no plugins or specialized functionality required.