5 ms·

Well, checking when your directories and files change should be a job for some inotify based tool, not periodically launched ls, sadly, inotify based version of

by thingie 16y ago

Well, checking when your directories and files change should be a job for some inotify based tool, not periodically launched ls, sadly, inotify based version of common unix utilities are still very optional and hackish, not found in the base distro.

imurray 16y ago
Thanks! When I first used atchange (detailed in another comment) I saw mention of things like inotify, but didn't have the kernel support on the system I was using. Fast-forwarding to now, having just installed inotify-tools (Debian/Ubuntu package): while true; do inotifywait . &> /dev/null ; ls ; done is a much more responsive version of: atchange . ls I should probably make a wrapper that uses inotify when available and degrades to atchange's brute force approach when necessary.
- dbro 16y ago
  To resemble the atchange script, try this usage of inotifywait: while true; do inotifywait -qq -e modify [filename]; [command]; done or as a shell function, defined in .bashrc to have the same form as the atchange perl script: function atchange(){ while true; do inotifywait -qq -e modify $1; $2; done
  - imurray 16y ago
    Thanks. Below is the version I'm trying. It allows multiple-argument commands, doesn't stomp on atchange if inotifywait isn't installed and I wanted it to fire when touching files as well as modifying them. if which inotifywait > /dev/null ; then function atchange(){ FILE="$1" shift while inotifywait -qq -e modify -e attrib "$FILE"; do "$@"; done;} fi Looking again at atchange it deliberately waits after first noticing the file has been modified, in case something is still modifying it. It fires once writing has stopped for at least a second. I'm not sure if I need that in my use cases, but its authors clearly did so I'm pointing out that the above shell function does not provide a true like-for-like replacement. (Also atchange allows a single argument to be a command_file, functionality I never use.) EDIT changed the "while true" so that the function stops on an error rather than infinitely looping when something goes wrong, like FILE ceasing to exist. A file temporarily disappearing would scupper the script though, whereas the perl script deals quietly with that.

by thingie 16y ago

imurray 16y ago

Thanks! When I first used atchange (detailed in another comment) I saw mention of things like inotify, but didn't have the kernel support on the system I was using. Fast-forwarding to now, having just installed inotify-tools (Debian/Ubuntu package): while true; do inotifywait . &> /dev/null ; ls ; done is a much more responsive version of: atchange . ls I should probably make a wrapper that uses inotify when available and degrades to atchange's brute force approach when necessary.

dbro 16y ago
To resemble the atchange script, try this usage of inotifywait: while true; do inotifywait -qq -e modify [filename]; [command]; done or as a shell function, defined in .bashrc to have the same form as the atchange perl script: function atchange(){ while true; do inotifywait -qq -e modify $1; $2; done
- imurray 16y ago
  Thanks. Below is the version I'm trying. It allows multiple-argument commands, doesn't stomp on atchange if inotifywait isn't installed and I wanted it to fire when touching files as well as modifying them. if which inotifywait > /dev/null ; then function atchange(){ FILE="$1" shift while inotifywait -qq -e modify -e attrib "$FILE"; do "$@"; done;} fi Looking again at atchange it deliberately waits after first noticing the file has been modified, in case something is still modifying it. It fires once writing has stopped for at least a second. I'm not sure if I need that in my use cases, but its authors clearly did so I'm pointing out that the above shell function does not provide a true like-for-like replacement. (Also atchange allows a single argument to be a command_file, functionality I never use.) EDIT changed the "while true" so that the function stops on an error rather than infinitely looping when something goes wrong, like FILE ceasing to exist. A file temporarily disappearing would scupper the script though, whereas the perl script deals quietly with that.