4 ms·

Entr and many other similar alternatives do not satisfy my needs. The main fault is that they take list of files instead of root directory and possibly include/

Entr and many other similar alternatives do not satisfy my needs. The main fault is that they take list of files instead of root directory and possibly include/exclude patterns. So when I create or rename files, these tools either don't register new files, or they just fail on missing files. I'm rather reusing existing stuff but seeing how every scriptable filesystem watcher misses the point, I'm inclined to write my own inotifywait/inotifywatch wrapper.

pull_my_finger 6y ago
Have you tried Tup[1]? [1] - http://gittup.org/tup/ http://gittup.org/tup/
- codefined 6y ago
  Nodemon[1] is also good, normally Node centric but all parameters can be configured. [1] https://nodemon.io/ https://nodemon.io/
  - inshadows 6y ago
    > To install, get node.js, then from your terminal run: There's no way I'm going to invoke node.js and associated `node_modules` with 1:10 code to junk ratio, for a any CLI scripting.
deleted 6y ago
[deleted]
akx 6y ago
That's literally in the article; `entr -d`. The manpage also has an entry. http://eradman.com/entrproject/entr.1.html#d http://eradman.com/entrproject/entr.1.html#d
- inshadows 6y ago
  Terminal 1: mkdir /tmp/project cd /tmp/project touch file{1,2} ls | entr -d echo "a change" Terminal 2: rm file2 Terminal 1: entr: cannot open 'file2': No child processes Regarding `-d`: > Track the directories of regular files provided as input and exit if a new file is added. This option also enables directories to be specified explicitly. Files with names beginning with ‘.’ are ignored. So first, it doesn't track NEW directories, and second, it exits if new file is added. Exactly how is this useful? EDIT: All I want from filesystem watcher is to track files by pattern and just re-run the command, however complex that may be to implement via OS interfaces. When I'm working on a Python project that has packages (directories), I may also refactor (rename files), and this simplistic behavior does not catch that.
  - coder543 6y ago
    > All I want from filesystem watcher is to track files by pattern and just re-run the command, however complex that may be to implement via OS interfaces. I've had good luck with modd: https://github.com/cortesi/modd/ https://github.com/cortesi/modd/ I just tested exactly what you described, did not see any errors, and it ran my commands exactly the way I wanted.
    - natrys 6y ago
      I can attest to modd too, it uses a (per project) configuration file to define include/exclude (recursive) globs, along with respective blocks of commands. I would also like to extol virtues of its sister project devd[0] from same author which makes web development palatable to me. It's a little websocker server that injects a tiny script into HTML to reload the page in browser once modd detects file change, rebuilds front-end and sends devd a SIGHUP. [0] https://github.com/cortesi/devd https://github.com/cortesi/devd
  - jdxcode 6y ago
    I think the interface for `-d` is clunky, but here is the way it is intended to be used: $ while true; do > ls -d src/*.py | entr -d ./setup.py > done that way when a file/dir is added/removed it restarts
hnlmorg 6y ago
I've ran into this issue myself and it's not filesystem watchers missing the point, it's actually something not supported in a number of operating systems. Thus you then either have to resort to nasty user-space hacks (which will be comparatively slow and resource hungry) or accept that you can't watch nested directories. A more technical description is mentioned here: https://github.com/fsnotify/fsnotify/issues/18 https://github.com/fsnotify/fsnotify/issues/18
- inshadows 6y ago
  inotifywait can do this just fine. Here's an emulation of `entr` with an `include pattern`: inotifywait -rq -m -e close_write --format %f . | grep '\.rules$' Sure, there may races due to limitations of underlying OS interfaces, but no such races really matter when you edit with mammal speed, so it's perfectly sufficient, and so it is perfectly possible to make good file system watcher, without any user-space power-hungry hacks.
  - hnlmorg 6y ago
    inotifywait is a user-space program that borrows it's name from inotify (because it uses inotify) and when using the -r (recursive) flag it sets up multiple inotify watches to work around the very problem I just described. In fact it's man page comes with a big fat warning about using -r: > Warning: If you use this option while watching the root directory of a large tree, it may take quite a while until all inotify watches are established, and events will not be received in this time. Also, since one inotify watch will be established per subdirectory, it is possible that the maximum amount of inotify watches per user will be reached. The default maximum is 8192; it can be increased by writing to /proc/sys/fs/inotify/max_user_watches. (ref: https://linux.die.net/man/1/inotifywait https://linux.die.net/man/1/inotifywait) Really what would be nice would be for Linux to support this natively so we don't have to resort to dirty hacks.
    - inshadows 6y ago
      > inotifywait is a user-space program that borrows it's name from inotify (because it uses inotify) and when using the -r (recursive) flag it sets up multiple inotify watches to work around the very problem I just described. What problem? What you quoted is totally irrelevant for my workflow. On my crappy laptop and all projects in my work directory, the watches are established almost instantly, without any spike in CPU. There are 4677 directories in Linux kernel and you can just put a knob change in /etc/sysctl.d/ if your code base is bigger than kernel. You're just inventing OS limitations to justify limitations of lazy user-space programming. EDIT: Setting up watches on kernel tree including directories in .git: ~/src/linux % inotifywait -r -m -e close_write --format %f . |& ts Jul 01 16:03:10 Setting up watches. Beware: since -r was given, this may take a while! Jul 01 16:03:10 Watches established. Less than 1 second. Big deal!
deleted 6y ago
[deleted]
pnathan 6y ago
here you go: it looks at everything in a specific directory. `while inotifywait -q -q -r -e modify -e move -e create -e delete --exclude '[*~#]' $(mapi $wd $@); do` wd is the working directory. and mapi my $prefix=shift; foreach my $s (@ARGV) { print "$prefix/$s "; } Adjust to taste. it is _hax_, as it were. but it has worked well for me.

pull_my_finger 6y ago

Have you tried Tup[1]? [1] - http://gittup.org/tup/ http://gittup.org/tup/

codefined 6y ago
Nodemon[1] is also good, normally Node centric but all parameters can be configured. [1] https://nodemon.io/ https://nodemon.io/
- inshadows 6y ago
  > To install, get node.js, then from your terminal run: There's no way I'm going to invoke node.js and associated `node_modules` with 1:10 code to junk ratio, for a any CLI scripting.

deleted 6y ago

[deleted]

akx 6y ago

That's literally in the article; `entr -d`. The manpage also has an entry. http://eradman.com/entrproject/entr.1.html#d http://eradman.com/entrproject/entr.1.html#d

inshadows 6y ago
Terminal 1: mkdir /tmp/project cd /tmp/project touch file{1,2} ls | entr -d echo "a change" Terminal 2: rm file2 Terminal 1: entr: cannot open 'file2': No child processes Regarding `-d`: > Track the directories of regular files provided as input and exit if a new file is added. This option also enables directories to be specified explicitly. Files with names beginning with ‘.’ are ignored. So first, it doesn't track NEW directories, and second, it exits if new file is added. Exactly how is this useful? EDIT: All I want from filesystem watcher is to track files by pattern and just re-run the command, however complex that may be to implement via OS interfaces. When I'm working on a Python project that has packages (directories), I may also refactor (rename files), and this simplistic behavior does not catch that.
- coder543 6y ago
  > All I want from filesystem watcher is to track files by pattern and just re-run the command, however complex that may be to implement via OS interfaces. I've had good luck with modd: https://github.com/cortesi/modd/ https://github.com/cortesi/modd/ I just tested exactly what you described, did not see any errors, and it ran my commands exactly the way I wanted.
  - natrys 6y ago
    I can attest to modd too, it uses a (per project) configuration file to define include/exclude (recursive) globs, along with respective blocks of commands. I would also like to extol virtues of its sister project devd[0] from same author which makes web development palatable to me. It's a little websocker server that injects a tiny script into HTML to reload the page in browser once modd detects file change, rebuilds front-end and sends devd a SIGHUP. [0] https://github.com/cortesi/devd https://github.com/cortesi/devd
- jdxcode 6y ago
  I think the interface for `-d` is clunky, but here is the way it is intended to be used: $ while true; do > ls -d src/*.py | entr -d ./setup.py > done that way when a file/dir is added/removed it restarts

hnlmorg 6y ago

I've ran into this issue myself and it's not filesystem watchers missing the point, it's actually something not supported in a number of operating systems. Thus you then either have to resort to nasty user-space hacks (which will be comparatively slow and resource hungry) or accept that you can't watch nested directories. A more technical description is mentioned here: https://github.com/fsnotify/fsnotify/issues/18 https://github.com/fsnotify/fsnotify/issues/18

inshadows 6y ago
inotifywait can do this just fine. Here's an emulation of `entr` with an `include pattern`: inotifywait -rq -m -e close_write --format %f . | grep '\.rules$' Sure, there may races due to limitations of underlying OS interfaces, but no such races really matter when you edit with mammal speed, so it's perfectly sufficient, and so it is perfectly possible to make good file system watcher, without any user-space power-hungry hacks.
- hnlmorg 6y ago
  inotifywait is a user-space program that borrows it's name from inotify (because it uses inotify) and when using the -r (recursive) flag it sets up multiple inotify watches to work around the very problem I just described. In fact it's man page comes with a big fat warning about using -r: > Warning: If you use this option while watching the root directory of a large tree, it may take quite a while until all inotify watches are established, and events will not be received in this time. Also, since one inotify watch will be established per subdirectory, it is possible that the maximum amount of inotify watches per user will be reached. The default maximum is 8192; it can be increased by writing to /proc/sys/fs/inotify/max_user_watches. (ref: https://linux.die.net/man/1/inotifywait https://linux.die.net/man/1/inotifywait) Really what would be nice would be for Linux to support this natively so we don't have to resort to dirty hacks.
  - inshadows 6y ago
    > inotifywait is a user-space program that borrows it's name from inotify (because it uses inotify) and when using the -r (recursive) flag it sets up multiple inotify watches to work around the very problem I just described. What problem? What you quoted is totally irrelevant for my workflow. On my crappy laptop and all projects in my work directory, the watches are established almost instantly, without any spike in CPU. There are 4677 directories in Linux kernel and you can just put a knob change in /etc/sysctl.d/ if your code base is bigger than kernel. You're just inventing OS limitations to justify limitations of lazy user-space programming. EDIT: Setting up watches on kernel tree including directories in .git: ~/src/linux % inotifywait -r -m -e close_write --format %f . |& ts Jul 01 16:03:10 Setting up watches. Beware: since -r was given, this may take a while! Jul 01 16:03:10 Watches established. Less than 1 second. Big deal!

deleted 6y ago

[deleted]

pnathan 6y ago

here you go: it looks at everything in a specific directory. `while inotifywait -q -q -r -e modify -e move -e create -e delete --exclude '[*~#]' $(mapi $wd $@); do` wd is the working directory. and mapi my $prefix=shift; foreach my $s (@ARGV) { print "$prefix/$s "; } Adjust to taste. it is _hax_, as it were. but it has worked well for me.