Why does the Listener terminate immediately (listener.start)?

[Josh Branchaud]

Hi,

I am creating a listener/Directory Monitor to keep an eye on the changes to files in a particular directory using the Guard/Listen gem.

The examples I have been following all look more or less like the following:

# Create a callback
callback = Proc.new do |modified, added, removed|
  # This proc will be called when there are changes.
end

listener = Listen.to('dir')
listener.change(&callback) # convert the callback to a block and register it

listener.start

However, when I invoke my code which follows this exact format, it terminates immediately. I would expect it to sit there and listen for activity, but it doesn't. After looking through the documentation a bit, I discovered that `listener.start!` can be used instead of `listener.start`. Now, when I execute my script, it hangs in the terminal waiting for file system activity. The appropriate puts statements are fired when I modify files in the watched directory and so forth.

My question then, is why does the 'listener.start' not seem to work for me? All the examples use 'start' instead of 'start!'. I may just be completely missing something here, so I'd appreciate any explanation.

[Thibaud Guillaume-Gentil]

Hi,

IMHO in general a ruby method shouldn't block at all, so I think we'll even remove the `start!` method in the Listen 2.0.0 release. If you want a script to block, adding a `sleep` at the end seems the way to go for me. I prefer this way because it lets all the controls to Listen users. WDYT?

> --
> You received this message because you are subscribed to the Google Groups "guard-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to guard-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Josh Branchaud]

I don't think I have made clear the situation.

The problem is that the 'start' function is not working for me at all (however 'start!' does seem to work). I have written multiple scripts that use 'start' verbatim to the example above and they all terminate immediately with no fsevent listener left to monitor the specified directory. I do a 'ps aux | grep ruby' command to check and no process is running after I invoke the script. Am I using Listen incorrectly? Is there any other reason that I could be experiencing this sort of behavior?

[Thibaud Guillaume-Gentil]

Yeah this is normal, `start` doesn't block so the script terminates... call `sleep` after `listener.start` and it should hang properly.

[Josh Branchaud]

Why do none of the examples on the GitHub README document take this approach? If using 'sleep' is the standard approach for getting the fsevent listener to stay around and watch your directory, then I think it would be helpful to have that detailed there.

Also, a coworker uses Listen for a script that watches and recompiles LaTeX files and it works for him without a 'sleep' or any similar thing. See the code here -- https://github.com/jurgns/texwatcher/blob/master/texwatcher

Why does this script work without a 'sleep'?

[Thibaud Guillaume-Gentil]

You're right, I'll update the examples in the README with a sleep when using the `start`.

The `start!` was introduced recently, before it was `start` that blocked. So I think your coworker was using an old release of Listen.

[Thibaud Guillaume-Gentil]

After reading the README again, I think https://github.com/guard/listen#blocking-listening-to-changes is clear enough no? Feel free to send a pull request to improve it. Thanks!

[Josh Branchaud]

So do people using Listen generally create a listener and kick it off on a separate thread? Is this the recommended way of using the gem?

[Thibaud Guillaume-Gentil]

Yeah, it seems reasonable to me.