4 ms·

Another approach would be to use the Linux kernel's fantastic inotify() feature, which does not require running tools designed for other purposes... https://li

Another approach would be to use the Linux kernel's fantastic inotify() feature, which does not require running tools designed for other purposes... https://linux.die.net/man/7/inotify https://linux.die.net/man/7/inotify https://en.wikipedia.org/wiki/Inotify https://en.wikipedia.org/wiki/Inotify There is also a less well utilized fsnotify feature for filesystem-wide notifications. Here is a cross-platform go implementation which also supports OSX: https://github.com/fsnotify/fsnotify https://github.com/fsnotify/fsnotify

detaro 10y ago
The program discussed in the submission uses inotify
- contingencies 10y ago
  Err, not as far as I can see.
  - detaro 10y ago
    It has a header file that on Linux emulates kqueue using inotify: https://bitbucket.org/eradman/entr/src/1dc74ab543e2bced2994db4e2d1a250620e992a2/missing/kqueue_inotify.c?at=default https://bitbucket.org/eradman/entr/src/1dc74ab543e2bced2994d...
    - contingencies 10y ago
      Aha. Be that as it may, using inotify directly from the shell is still a fair approach which is worth putting out there.
jsnathan 10y ago
Hey! OP here. I submitted this exactly because I kept running into problems with inotify-tools, and other naive inotify wrappers, where tests would execute multiple times in quick succession, or stop executing on file changes, or other odd behavior. Entr on the other hand works like a charm. You can see on the website that it details a number of edge cases with inotify that it works around. I'm not even sure it's an exhaustive list.
lloeki 10y ago
I myself quite enjoy using the very nice fswatch[0]. https://github.com/emcrisostomo/fswatch https://github.com/emcrisostomo/fswatch
- mmjaa 10y ago
  Indeed, I live by this one-liner which makes life so smooth: $ fswatch -0 -event ./main.lua | xargs -0 -n 1 -I {} lua ./main.lua
oever 10y ago
inofity is no fantastic. Memory use scales with the number of directories watched. The program that uses the inotify system call has to keep a mapping of file descriptors to paths. Inotify is slow, inefficient and error-prone for recursively watching file systems. fanotify is not an alternative because it cannot monitor file deletion or renames and it requires root permission. http://www.lanedo.com/filesystem-monitoring-linux-kernel/ http://www.lanedo.com/filesystem-monitoring-linux-kernel/
- problems 10y ago
  > The program that uses the inotify system call has to keep a mapping of file descriptors to paths If it doesn't care what file is modified and just wants to run a command on any change, why would it need to do this?
  - oever 10y ago
    In that case it's not needed. One could imagine that one would like to start a specific command. That is what 'tup monitor' does. Another use-case is a desktop search tool. http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html
jfindley 10y ago
Note that that particular go implementation is prone to deadlocks. Also, inotify is suboptimal for this use case. inotify has no recursion support, which means that the user must keep a watch on all files individually. There is also a limit to the number of inotify watches that can be in place at any one time. A more modern, and more suitable interface for this use case is fanotify[0]. It doesn't provide all the functions that inotify does, but importantly it supports recursion, which alone would seem to make it a more obvious choice for this task. 0: http://man7.org/linux/man-pages/man7/fanotify.7.html http://man7.org/linux/man-pages/man7/fanotify.7.html
- eatonphil 10y ago
  > Note that that particular go implementation is prone to deadlocks. Any more information on this? I'm curious to read why.
pjc50 10y ago
Windows counterpart: FindFirstChangeNotification or SHChangeNotifyRegister().
spelufo 10y ago
I made something similar with fsnotify recently: https://github.com/spelufo/on-change https://github.com/spelufo/on-change

detaro 10y ago

The program discussed in the submission uses inotify

contingencies 10y ago
Err, not as far as I can see.
- detaro 10y ago
  It has a header file that on Linux emulates kqueue using inotify: https://bitbucket.org/eradman/entr/src/1dc74ab543e2bced2994db4e2d1a250620e992a2/missing/kqueue_inotify.c?at=default https://bitbucket.org/eradman/entr/src/1dc74ab543e2bced2994d...
  - contingencies 10y ago
    Aha. Be that as it may, using inotify directly from the shell is still a fair approach which is worth putting out there.

jsnathan 10y ago

Hey! OP here. I submitted this exactly because I kept running into problems with inotify-tools, and other naive inotify wrappers, where tests would execute multiple times in quick succession, or stop executing on file changes, or other odd behavior. Entr on the other hand works like a charm. You can see on the website that it details a number of edge cases with inotify that it works around. I'm not even sure it's an exhaustive list.

lloeki 10y ago

I myself quite enjoy using the very nice fswatch[0]. https://github.com/emcrisostomo/fswatch https://github.com/emcrisostomo/fswatch

mmjaa 10y ago
Indeed, I live by this one-liner which makes life so smooth: $ fswatch -0 -event ./main.lua | xargs -0 -n 1 -I {} lua ./main.lua

oever 10y ago

inofity is no fantastic. Memory use scales with the number of directories watched. The program that uses the inotify system call has to keep a mapping of file descriptors to paths. Inotify is slow, inefficient and error-prone for recursively watching file systems. fanotify is not an alternative because it cannot monitor file deletion or renames and it requires root permission. http://www.lanedo.com/filesystem-monitoring-linux-kernel/ http://www.lanedo.com/filesystem-monitoring-linux-kernel/

problems 10y ago
> The program that uses the inotify system call has to keep a mapping of file descriptors to paths If it doesn't care what file is modified and just wants to run a command on any change, why would it need to do this?
- oever 10y ago
  In that case it's not needed. One could imagine that one would like to start a specific command. That is what 'tup monitor' does. Another use-case is a desktop search tool. http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html

jfindley 10y ago

Note that that particular go implementation is prone to deadlocks. Also, inotify is suboptimal for this use case. inotify has no recursion support, which means that the user must keep a watch on all files individually. There is also a limit to the number of inotify watches that can be in place at any one time. A more modern, and more suitable interface for this use case is fanotify[0]. It doesn't provide all the functions that inotify does, but importantly it supports recursion, which alone would seem to make it a more obvious choice for this task. 0: http://man7.org/linux/man-pages/man7/fanotify.7.html http://man7.org/linux/man-pages/man7/fanotify.7.html

eatonphil 10y ago
> Note that that particular go implementation is prone to deadlocks. Any more information on this? I'm curious to read why.

pjc50 10y ago

Windows counterpart: FindFirstChangeNotification or SHChangeNotifyRegister().

spelufo 10y ago

I made something similar with fsnotify recently: https://github.com/spelufo/on-change https://github.com/spelufo/on-change