9

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

shabunc
  • 23,119
  • 19
  • 77
  • 102

3 Answers3

11

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 ...
larsks
  • 277,717
  • 41
  • 399
  • 399
  • thank you for this answer. `-e close_write` option is definitely better, but resolves only issue with multiple modifies, but not with mysterious `sass/somefolder/ CLOSE_WRITE,CLOSE 4913` event – shabunc Apr 24 '12 at 15:25
  • You could just ignore events on directories...if you have `inotifywait` wait output the path, you can have your script check if it's a directory (`[ -d ... ]`) and only trigger your actions if files are modified. – larsks Apr 24 '12 at 16:45
  • 3
    By default, when vim saves a file it creates a new one and writes into it, and when it's sure it wrote successfully, it deletes the old file and renames the new one. This might be the cause of some spurious events. You can turn this off with `set nowritebackup`. See `:help backup-table` and friends. – David Pope Apr 25 '12 at 15:46
2

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.

Community
  • 1
  • 1
Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
1

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.

Paul Fox
  • 131
  • 3