I'm trying to use inotifywait
for monitoring specific folders and recompiling if needed. The problem is that I'm using vim heavily, and when I'm editing in vim any file modified actually triggers some 'redundant' events, something like:
:w
sass/somefolder/ CREATE 4913
sass/somefolder/ CREATE some
sass/somefolder/ MODIFY some
It took me some time to realize that actually everything is OK with inotifywait
- I've tried to use nano
and everything worked just as expected, only "MODIFY" is triggered, and only once.
I've tried to edit (just for test purposes, don't judge me hard) Emacs and there are problems with Emacs as well - each time I'm pressing Ctrl-X + Ctrl+S MODIFY triggers 3 times.
The question is how can I resolve issues with superfluous events in vim?
By the way, directory
and backupdir
in my .vimrc
are not in the folder that is monitored.
UPD: This link explains why actually things happen how they happen, but I still have no idea how to fix this. Well, of course I can ignore 4913 containing string, but this is too kludgy even for one who tries to use inotify to compile SASS)))
UPD: VIM version is 7.3.429
If you're looking to trigger an action (such as recompiling code) after you have edited a file, you usually want to look at the IN_CLOSE_WRITE
event and ignore everything else.
You absolutely do not want to monitor IN_MODIFY
events because, as you have discovered, they may be triggered many times while editing a file.
So:
inotifywait -e close_write ...
The better editors do it that way to enforce atomicity. In other words, you won't end up with a half-written file if power dies at the wrong moment.
One option that may help is to just use autocmd BufWritePost to do your recompile.
However, if you make other changes outside of vim, you probably want to wait on multiple notifications and do the compile after none have happened for a period of time, say a half second. That's going to cover other contingencies like doing a source control pull, for example.
Most editors will use a temporary file to write undo information, or file edits, before you commit and save. Additionally, most editors need to write to a temp file to talk to sub-shells and scripts. I suspect the 4913 file could be a factor of your vim setup, or a function of your numeric user-id, to uniquify the files.
You could strace vim to see when the files gets updated and what happens either side, e.g. a fork + exec, or another file is touched which might hint which macro or facility is causing this.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With