Cross platform (Linux/OS X) file system watcher (run command when file changes)
I'm looking for a cross-platform (Linux and OS X) file system watcher that doesn't poll the disk for changes (or is very efficient in doing so).
This will be the core piece of a continuous integration server, and handle things such as compiling LESS/SCSS, running javascript tests, and running custom scripts. I'd like to specify a list of files and directories, and commands to execute when a file or folder changes.
I'd like something node.js, python, shell script, or ruby based.
Some of the tools I'开发者_StackOverflow社区ve looked at so far...
https://github.com/tafa/node-watch-tree
https://github.com/mikeal/watch/blob/master/main.js
doc.qt.nokia.com/latest/qfilesystemwatcher.html
buildr.apache.org/building.html#continuous-compilation
www.javascriptkata.com/2010/10/28/ready-js-prepare-your-javascript-for-production/
Any recommendations appreciated.
Other than being written in C, entr looks like what you want.
Cross-platform? It's very hard. I do not know any effective cross-platform implementation but, perhaps, I can suggest a starting point.
Linux has iNotify API, a kernel feature that monitors file systems and immediately alerts an attentive application to relevant events. The BSD/Mac-OS equivalent is kqueue. The two APIs seem very similar each other.
I found on CPAN, some perl wrapper for each one of them. I have no experience in python but I googled some wrapper of these APIs also in phyton. You have "only" to write your own wrapper around them to obtain your cross-platform library.
fswatch seems to be the way to go, especially if you want to also monitor new files.
It's efficiency & stability depends on the underlying OS API. Here's the relevant snippet from the project's README:
The limitations of fswatch depend largely on the monitor being used:
- The FSEvents monitor, available only on OS X, has no known limitations, and scales very well with the number of files being observed.
- The kqueue monitor, available on any *BSD system featuring kqueue, requires a file descriptor to be opened for every file being watched. As a result, this monitor scales badly with the number of files being observed, and may begin to misbehave as soon as the fswatch process runs out of file descriptors. In this case, fswatch dumps one error on standard error for every file that cannot be opened.
- The inotify monitor, available on Linux since kernel 2.6.13, may suffer a queue overflow if events are generated faster than they are read from the queue. In any case, the application is guaranteed to receive an overflow notification which can be handled to gracefully recover. fswatch currently throws an exception if a queue overflow occurs. Future versions will handle the overflow by emitting proper notifications.
Their's a collectd plugin that tails a file for a regex pattern. You can tie thresholds and alert scripts to be triggered.
is a shell script sufficient? should be cross platform for *nix's
for FILE in $LIST ; do #caveat if files may contain spaces, set IFS to be a \n
touch -r "$FILE" "/tmp/$FILE.timestamp" #use /dev/shm if available vs. /tmp
done
#...
while :; do
sleep 1 #you need some sleep value to prevent eating CPU
for FILE in $LIST ; do
[ "$FILE" -nt "/tmp/$FILE.timestamp" ] && modified_action "$FILE"
done
done
Great question, and good for you for wanting to automate your build and test procedures. Continuous integration is the way to go.
If you're using git, isn't there some way to install a trigger in a git repository? You could have your trigger (running on your local repository) push your changes and then activate a build/test cycle on a build server. Other version control system might have similar facilities if you are not using git.
Guard supports file change detection in OS X via FSEvent and Linux via Inotify, according to their Features list. We're using it at work for continuous integration, and it works very well.
精彩评论