Functional changes for version > 0.0.2 about fswatch HOT 14 CLOSED

I also want the function

from fswatch.

Hi @svenax, @GithubMachineUser, the reason of this change is keeping things simple and flexible and it got into fswatch when it merged with fsw.

The typical use case will be feeding notifications emitted by fswatch to other programs and I believe the current approach is simpler and more flexible than the previous implementation. In fact, you can run any command when a notification is found piping the output of fswatch to the command you want to run:

$ fswatch [opts] [args] | do-something

That's also why the -0 option was implemented: so that fswatch output can be parsed without worrying about file names containing characters such as spaces and new lines.

Probably, the easiest way to get what you want is using fswatch together with xargs this way:

$ fswatch -0 [args] | xargs -0 -n 1 [opts] [args] 

Basically, this is what's going on:

• -0 tells fswatch to end a notification record with a NUL character.
• -0 tells xargs to parse the output accordingly.
• -n 1 tells xargs to execute the specified command every argument is read from the output.

Another approach is using the shell read builtin specifying the delimiter character (check the documentation of the shell you're using):

$ fswatch -0 [opts] [args] | while read -d "" event \
  do \
    [do something with the $event] \
  done

Hope this helps.

Cheers,
-- Enrico

from fswatch.

That helps. Maybe it is obvious, but the examples I've seen for inotifyd and similar all use terribly complex while read ... constructs that I don't want to deal with.

My main use for fswatch is to sync changes to a remote server. For this I call rsync to do the real work. Works great. However, If I do something like

fswatch -0 . | xargs -0 -n1 ./sync-files.sh

my sync script will unnecessarily be called for every file changed, instead of just once for all files in the change batch. I guess I need something that throws away the paths printed by fswatch so I then can call my script. I tried

fswatch . | cat - > /dev/null | ./sync-files.sh

but that hangs after the first invocation. I guess cat does not get an EOF so it knows when to stop reading from stdin.

Any tips on how to do this? Thanks.

from fswatch.

I went ahead and hacked fswatch to have a one-set option that just prints a single throw-away message when a set of changes has been detected. This is probably not useful for any one but me, and I'm sure there are better ways of doing it anyways. But here it is if any one is interested:
https://github.com/svenax/fswatch/compare/alandipert:master...one-set

from fswatch.

Hi @svenax, yeah, I've seen people doing terrible things with while read.

Since xargs knows nothing about fswatch, it can't possibly have a knowledge of a "change batch".

I can only think of one "quick" options at the moment, that is updating sync-files.sh so that:

• It writes a lock file and a sentinel file when it starts.
• It checks whether the lock file exists: if it exists, it touches the sentinel file it and exits, otherwise, it creates both the lock and the sentinel.
• Before exiting, it checks whether the sentinel is newer than the lock file: if it is, it restarts, otherwise it exits.

I recognise that this use case translates to more complex scripting, but since fswatch can already watch multiple directories, I still see drawbacks in giving the option of emitting one fake event every time the FSEvents callback sends a group of changes:

• On the one hand, the use case you propose would "work" out of the box.
• On the other hand the fake event would defy the ability of watching multiple directories.

from fswatch.

@svenax, it seems we were commenting at the same time.

As explained in my previous comment, I thought about the possibility of emitting a "fake" event, but I think it has some drawbacks. I'll have a look at this use case: thanks for the changeset.

from fswatch.

Right, I thought of that too, but my present use-case uses only one directory so that is not a problem. It would of course be possible to emit a single event for each watched directory; the directory name for instance. That is probably reasonably simple to do. I may take a look at that unless you feel like doing it yourself. :)

from fswatch.

That could be a reasonable solution. I'll have a look at the events of the FSEvents API to be sure I'm taking into account all the event flags. Thanks for the offering, I'll have a look myself anyway but if you'd like to contribute, please feel free to do so.

Reopening this issue.

from fswatch.

👍 for an option to only emit some kind of batch change event.

from fswatch.

👍

While I like that you're making it a more flexible tool, running a script / rebooting something in development is probably 90% of the users of this script, and that should be dead simple to do. Thanks!

from fswatch.

👍
Though the change looks good because it's according to UNIX philosophy, I'm pleased if there is the option which allows specifying a command.

from fswatch.

Hi @svenax, @GithubMachineUser, @slindberg, @bwiklund, @nobeans and everybody else.

I've just released v. 1.3.3 where:

• The -o option instructs fswatch to only print one line with the number of the change events received in the last "batch". This way, you can use this event to trigger the execution of another program, as discussed in this issue and in Issue 24.
• The fswatch-run script has been added to ease the transition from v. 0.x to 1.x. This scripts accepts the older fswatch path command syntax and invokes fswatch -o piping its output to xargs for you. Being a one-liner, I still strongly suggest adapting your script to the new behaviour.

Cheers,
-- Enrico

P.S.: @svenax, thanks for your changeset.

from fswatch.

Awesome, thanks!

For some reason it looks like the source code tarball in that release doesn't have the 1.3.3 changes 😕

I'm attempting to upgrade the Homebrew Formula, but before I make a PR, is it safe to use the release version with the configure script already autogen'd?

from fswatch.

Hi @slindberg,

Thanks, you're right, the tag was set but develop was not merged into master. I've updated the tags and the release and now the source code tarball you linked in your comment is correct.

By the way, since you're asking, I use to attach the distribution tarball made by make distcheck in the release and that should be the way to go. Ironically, in this case it was "the" correct one.

Cheers and let me know if everything's ok,
-- Enrico

from fswatch.