listen 3.2.1 → 3.6.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e9a53907593c7c8390f895d361bce34873381883dbd033e02d1706e2e28c13d1
-  data.tar.gz: 5a8dfdc3c74345e7283b5f5aee13b5ded0f3f44c8fecaf7027551eb2359ecdae
+  metadata.gz: 656e49f1b6eca9a31fd9c09b916aa73ed6d3df255e4859c4b77ebdb7a0f4a6bf
+  data.tar.gz: 98be9697f64242c869fa47211477f84f8b636402fa4e865989e1b54e020a8032
 SHA512:
-  metadata.gz: b5cbabed841e265c54aebfff999d306f5a91590e5e5abe8f9867c5ea9e66caa4d952acc7e7b8be10c2f1ea0a77b0ff4a07d653ec45d3009e149b5faa8331a689
-  data.tar.gz: 76c990e22b861cae3d9c764a290fab1ed90f6547b9c1329c92be797b8d99364ae21cb3367a84e8064e6834c9a3b76ab440a8c597f0dcacae1e06b1991e39c303
+  metadata.gz: af8bfbe37ce9b791f78ebdee29c32781742f3e58e98eae92381c34169bdf389db38f82228b77a56ba13e73646dbb7d2dae9a275be0c5b75e300010adb4382129
+  data.tar.gz: f97c76664f9aa893bd89bcf93484701a6bda473ab9b13e2101cacb4f450f5ca0d116362027368fe561a724fb0c55213bbc6944bd58b0ee4cb6812f588d00feeb

data/CONTRIBUTING.md

@@ -4,7 +4,7 @@ Contribute to Listen
 File an issue
 -------------
 
-If you haven't already, first see [TROUBLESHOOTING](https://github.com/guard/listen/wiki/Troubleshooting) for known issues, solutions and workarounds.
+If you haven't already, first see [TROUBLESHOOTING](https://github.com/guard/listen/blob/master/README.md#Issues-and-Troubleshooting) for known issues, solutions and workarounds.
 
 You can report bugs and feature requests to [GitHub Issues](https://github.com/guard/listen/issues).
 
@@ -16,7 +16,7 @@ Try to figure out where the issue belongs to: Is it an issue with Listen itself
 
 **It's most likely that your bug gets resolved faster if you provide as much information as possible!**
 
-The MOST useful information is debugging output from Listen (`LISTEN_GEM_DEBUGGING=1`) - see [TROUBLESHOOTING](https://github.com/guard/listen/wiki/Troubleshooting) for details.
+The MOST useful information is debugging output from Listen (`LISTEN_GEM_DEBUGGING=1`) - see [TROUBLESHOOTING](https://github.com/guard/listen/blob/master/README.md#Issues-and-Troubleshooting) for details.
 
 
 Development

data/README.md

@@ -1,12 +1,11 @@
-## IMPORTANT: If you cannot install Listen (e.g. on Travis/CI builds), [a workaround is here](https://github.com/guard/listen/wiki/Ruby-version-requirements)
-
-:exclamation: Listen is currently accepting more maintainers. Please [read this](https://github.com/guard/guard/wiki/Maintainers) if you're interested in joining the team.
-
 # Listen
 
-[![Gem Version](https://badge.fury.io/rb/listen.svg)](http://badge.fury.io/rb/listen) [![Build Status](https://travis-ci.org/guard/listen.svg)](https://travis-ci.org/guard/listen) [![Code Climate](https://codeclimate.com/github/guard/listen.svg)](https://codeclimate.com/github/guard/listen) [![Coverage Status](https://coveralls.io/repos/guard/listen/badge.svg?branch=master)](https://coveralls.io/r/guard/listen)
+The `listen` gem listens to file modifications and notifies you about the changes.
 
-The Listen gem listens to file modifications and notifies you about the changes.
+[![Development Status](https://github.com/guard/listen/workflows/Development/badge.svg)](https://github.com/guard/listen/actions?workflow=Development)
+[![Gem Version](https://badge.fury.io/rb/listen.svg)](http://badge.fury.io/rb/listen)
+[![Code Climate](https://codeclimate.com/github/guard/listen.svg)](https://codeclimate.com/github/guard/listen)
+[![Coverage Status](https://coveralls.io/repos/guard/listen/badge.svg?branch=master)](https://coveralls.io/r/guard/listen)
 
 ## Features
 
@@ -15,46 +14,88 @@ The Listen gem listens to file modifications and notifies you about the changes.
 * You can watch multiple directories.
 * Regexp-patterns for ignoring paths for more accuracy and speed
 * Increased change detection accuracy on OS X HFS and VFAT volumes.
-* Tested on selected Ruby environments via [Travis CI](https://travis-ci.org/guard/listen). (See [.travis.yml](https:///github.com/guard/listen/master/.travis.yml) for supported/tested Ruby Versions),
+* Continuous Integration: tested on selected Ruby environments via [Github Workflows](https:///github.com/guard/listen/master/.github/workflows).
 
 ## Issues / limitations
 
 * Limited support for symlinked directories ([#279](https://github.com/guard/listen/issues/279)):
   * Symlinks are always followed ([#25](https://github.com/guard/listen/issues/25)).
-  * Symlinked directories pointing within a watched directory are not supported ([#273](https://github.com/guard/listen/pull/273)- see [Duplicate directory errors](https://github.com/guard/listen/wiki/Duplicate-directory-errors)).
+  * Symlinked directories pointing within a watched directory are not supported ([#273](https://github.com/guard/listen/pull/273).
 * No directory/adapter-specific configuration options.
 * Support for plugins planned for future.
-* TCP functionality was removed in Listen [3.0.0](https://github.com/guard/listen/releases/tag/v3.0.0) ([#319](https://github.com/guard/listen/issues/319), [#218](https://github.com/guard/listen/issues/218)). There are plans to extract this feature to separate gems ([#258](https://github.com/guard/listen/issues/258)), until this is finished, you can use by locking the `listen` gem to version `'~> 2.10'`.
+* TCP functionality was removed in `listen` [3.0.0](https://github.com/guard/listen/releases/tag/v3.0.0) ([#319](https://github.com/guard/listen/issues/319), [#218](https://github.com/guard/listen/issues/218)). There are plans to extract this feature to separate gems ([#258](https://github.com/guard/listen/issues/258)), until this is finished, you can use by locking the `listen` gem to version `'~> 2.10'`.
 * Some filesystems won't work without polling (VM/Vagrant Shared folders, NFS, Samba, sshfs, etc.).
-* Specs suite on JRuby and Rubinius aren't reliable on Travis CI, but should work.
 * Windows and \*BSD adapter aren't continuously and automatically tested.
 * OSX adapter has some performance limitations ([#342](https://github.com/guard/listen/issues/342)).
-* Ruby < 2.2.x is no longer supported - upgrade to Ruby 2.2 or 2.3.
 * Listeners do not notify across forked processes, if you wish for multiple processes to receive change notifications you must [listen inside of each process](https://github.com/guard/listen/issues/398#issuecomment-223957952).
 
 Pull requests or help is very welcome for these.
 
 ## Install
 
-The simplest way to install Listen is to use [Bundler](http://bundler.io).
+The simplest way to install `listen` is to use [Bundler](http://bundler.io).
 
 ```ruby
-gem 'listen', '~> 3.0' # NOTE: for TCP functionality, use '~> 2.10' for now
+gem 'listen'
+```
+
+## Complete Example
+Here is a complete example of using the `listen` gem:
+```ruby
+require 'listen'
+
+listener = Listen.to('/srv/app') do |modified, added, removed|
+  puts(modified: modified, added: added, removed: removed)
+end
+listener.start
+sleep
+```
+Running the above in the background, you can see the callback block being called in response to each command:
+```
+$ cd /srv/app
+$ touch a.txt
+{:modified=>[], :added=>["/srv/app/a.txt"], :removed=>[]}
+
+$ echo more >> a.txt
+{:modified=>["/srv/app/a.txt"], :added=>[], :removed=>[]}
+
+$ mv a.txt b.txt
+{:modified=>[], :added=>["/srv/app/b.txt"], :removed=>["/srv/app/a.txt"]}
+
+$ vi b.txt
+# add a line to this new file and press ZZ to save and exit
+{:modified=>["/srv/app/b.txt"], :added=>[], :removed=>[]}
+
+$ vi c.txt
+# add a line and press ZZ to save and exit
+{:modified=>[], :added=>["/srv/app/c.txt"], :removed=>[]}
+
+$ rm b.txt c.txt
+{:modified=>[], :added=>[], :removed=>["/srv/app/b.txt", "/srv/app/c.txt"]}
 ```
 
 ## Usage
 
-Call `Listen.to` with either a single directory or multiple directories, then define the "changes" callback in a block.
+Call `Listen.to` with one or more directories and the "changes" callback passed as a block.
 
 ``` ruby
 listener = Listen.to('dir/to/listen', 'dir/to/listen2') do |modified, added, removed|
-  puts "modified absolute path: #{modified}"
-  puts "added absolute path: #{added}"
-  puts "removed absolute path: #{removed}"
+  puts "modified absolute path array: #{modified}"
+  puts "added absolute path array: #{added}"
+  puts "removed absolute path array: #{removed}"
 end
-listener.start # not blocking
+listener.start # starts a listener thread--does not block
+
+# do whatever you want here...just don't exit the process :)
+
 sleep
 ```
+## Changes Callback
+
+Changes to the listened-to directories are reported by the listener thread in a callback.
+The callback receives **three** array parameters: `modified`, `added` and `removed`, in that order.
+Each of these three is always an array with 0 or more entries.
+Each array entry is an absolute path.
 
 ### Pause / unpause / stop
 
@@ -75,13 +116,14 @@ listener.unpause # resumes processing changes ("start" would do the same)
 listener.stop    # stop both listening to changes and processing them
 ```
 
-  Note: While paused, Listen keeps on collecting changes in the background - to clear them, call "stop"
+  Note: While paused, `listen` keeps on collecting changes in the background - to clear them, call `stop`.
 
-  Note: You should keep track of all started listeners and stop them properly on finish.
+  Note: You should keep track of all started listeners and `stop` them properly on finish.
 
 ### Ignore / ignore!
 
-Listen ignores some directories and extensions by default (See DEFAULT_IGNORED_DIRECTORIES and DEFAULT_IGNORED_EXTENSIONS in Listen::Silencer), you can add ignoring patterns with the `ignore` option/method or overwrite default with `ignore!` option/method.
+`Listen` ignores some directories and extensions by default (See DEFAULT_IGNORED_DIRECTORIES and DEFAULT_IGNORED_EXTENSIONS in Listen::Silencer).
+You can add ignoring patterns with the `ignore` option/method or overwrite default with `ignore!` option/method.
 
 ``` ruby
 listener = Listen.to('dir/path/to/listen', ignore: /\.txt/) { |modified, added, removed| # ... }
@@ -93,11 +135,11 @@ sleep
 
 Note: `:ignore` regexp patterns are evaluated against relative paths.
 
-Note: Ignoring paths does not improve performance, except when Polling ([#274](https://github.com/guard/listen/issues/274))
+Note: Ignoring paths does not improve performance, except when Polling ([#274](https://github.com/guard/listen/issues/274)).
 
 ### Only
 
-Listen catches all files (less the ignored ones) by default. If you want to only listen to a specific type of file (i.e., just `.rb` extension), you should use the `only` option/method.
+`Listen` watches all files (less the ignored ones) by default. If you want to only listen to a specific type of file (i.e., just `.rb` extension), you should use the `only` option/method.
 
 ``` ruby
 listener = Listen.to('dir/path/to/listen', only: /\.rb$/) { |modified, added, removed| # ... }
@@ -109,35 +151,6 @@ sleep
 Note: `:only` regexp patterns are evaluated only against relative **file** paths.
 
 
-## Changes callback
-
-Changes to the listened-to directories gets reported back to the user in a callback.
-The registered callback gets invoked, when there are changes, with **three** parameters:
-`modified`, `added` and `removed` paths, in that particular order.
-Paths are always returned in their absolute form.
-
-Example:
-
-```ruby
-listener = Listen.to('path/to/app') do |modified, added, removed|
-  # This block will be called when there are changes.
-end
-listener.start
-sleep
-```
-
-or ...
-
-```ruby
-# Create a callback
-callback = Proc.new do |modified, added, removed|
-  # This proc will be called when there are changes.
-end
-listener = Listen.to('dir', &callback)
-listener.start
-sleep
-```
-
 ## Options
 
 All the following options can be set through the `Listen.to` after the directory path(s) params.
@@ -167,16 +180,42 @@ polling_fallback_message: 'custom message'      # Set a custom polling fallback
                                                 # default: "Listen will be polling for changes. Learn more at https://github.com/guard/listen#listen-adapters."
 ```
 
-## Debugging
+## Logging and Debugging
 
-Setting the environment variable `LISTEN_GEM_DEBUGGING=1` sets up the INFO level logger, while `LISTEN_GEM_DEBUGGING=2` sets up the DEBUG level logger.
+`Listen` logs its activity to `Listen.logger`.
+This is the primary method of debugging.
+
+### Custom Logger
+You can call `Listen.logger =` to set a custom `listen` logger for the process. For example:
+```
+Listen.logger = Rails.logger
+```
 
-You can also set `Listen.logger` to a custom logger.
+### Default Logger
+If no custom logger is set, a default `listen` logger which logs to to `STDERR` will be created and assigned to `Listen.logger`.
 
+The default logger defaults to the `error` logging level (severity).
+You can override the logging level by setting the environment variable `LISTEN_GEM_DEBUGGING=<level>`.
+For `<level>`, all standard `::Logger` levels are supported, with any mix of upper-/lower-case:
+```
+export LISTEN_GEM_DEBUGGING=debug # or 2 [deprecated]
+export LISTEN_GEM_DEBUGGING=info  # or 1 or true or yes [deprecated]
+export LISTEN_GEM_DEBUGGING=warn
+export LISTEN_GEM_DEBUGGING=fatal
+export LISTEN_GEM_DEBUGGING=error
+```
+The default of `error` will be used if an unsupported value is set.
 
-## Listen adapters
+Note: The alternate values `1`, `2`, `true` and `yes` shown above are deprecated and will be removed from `listen` v4.0.
 
-The Listen gem has a set of adapters to notify it when there are changes.
+### Disabling Logging
+If you want to disable `listen` logging, set
+```
+Listen.logger = ::Logger.new('/dev/null')
+```
+## Listen Adapters
+
+The `Listen` gem has a set of adapters to notify it when there are changes.
 
 There are 4 OS-specific adapters to support Darwin, Linux, \*BSD and Windows.
 These adapters are fast as they use some system-calls to implement the notifying function.
@@ -184,9 +223,9 @@ These adapters are fast as they use some system-calls to implement the notifying
 There is also a polling adapter - although it's much slower than other adapters,
 it works on every platform/system and scenario (including network filesystems such as VM shared folders).
 
-The Darwin and Linux adapters are dependencies of the Listen gem so they work out of the box. For other adapters a specific gem will have to be added to your Gemfile, please read below.
+The Darwin and Linux adapters are dependencies of the `listen` gem so they work out of the box. For other adapters a specific gem will have to be added to your Gemfile, please read below.
 
-The Listen gem will choose the best adapter automatically, if present. If you
+The `listen` gem will choose the best adapter automatically, if present. If you
 want to force the use of the polling adapter, use the `:force_polling` option
 while initializing the listener.
 
@@ -197,7 +236,7 @@ If you are on Windows, it's recommended to use the [`wdm`](https://github.com/Ma
 Please add the following to your Gemfile:
 
 ```ruby
-gem 'wdm', '>= 0.1.0' if Gem.win_platform?
+gem 'wdm', '>= 0.1.0', platforms: [:mingw, :mswin, :x64_mingw, :jruby]
 ```
 
 ### On \*BSD
@@ -216,35 +255,144 @@ end
 
 ### Getting the [polling fallback message](#options)?
 
-Please visit the [installation section of the Listen WIKI](https://github.com/guard/listen/wiki#installation) for more information and options for potential fixes.
+If you see:
+```
+Listen will be polling for changes.
+```
+
+This means the Listen gem can’t find an optimized adapter. Typically this is caused by:
+
+- You’re on Windows and WDM gem isn’t installed.
+- You’re running the app without Bundler or RubyGems.
+- Using Sass which includes an ancient (the “dinosaur” type of ancient) version of the Listen gem.
+
+Possible solutions:
 
-### Issues and troubleshooting
+1. Suppress the message by using the :force_polling option. Or, you could just ignore the message since it’s harmless.
+2. Windows users: Install the WDM gem.
+3. Upgrade Ruby (use RubyInstaller for Windows or RVM/rbenv for Mac) and RubyGems.
+3. Run your apps using Bundler.
+4. Sass users: Install the latest version of Listen and try again.
+
+#### Simplified Bundler and Sass example
+Create a Gemfile with these lines:
+```
+source 'https://rubygems.org'
+gem 'listen'
+gem 'sass'
+```
+Next, use Bundler to update gems:
+```
+$ bundle update
+$ bundle exec sass --watch # ... or whatever app is using Listen.
+```
 
-*NOTE: without providing the output after setting the `LISTEN_GEM_DEBUGGING=1` environment variable, it can be almost impossible to guess why listen is not working as expected.*
+### Increasing the amount of inotify watchers
 
-See [TROUBLESHOOTING](https://github.com/guard/listen/wiki/Troubleshooting)
+If you are running Debian, RedHat, or another similar Linux distribution, run the following in a terminal:
+```
+$ sudo sh -c "echo fs.inotify.max_user_watches=524288 >> /etc/sysctl.conf"
+$ sudo sysctl -p
+```
+If you are running ArchLinux, search the `/etc/sysctl.d/` directory for config files with the setting:
+```
+$ grep -H -s "fs.inotify.max_user_watches" /etc/sysctl.d/*
+/etc/sysctl.d/40-max_user_watches.conf:fs.inotify.max_user_watches=100000
+```
+Then change the setting in the file you found above to a higher value (see [here](https://www.archlinux.org/news/deprecation-of-etcsysctlconf/) for why):
+```
+$ sudo sh -c "echo fs.inotify.max_user_watches=524288 > /etc/sysctl.d/40-max-user-watches.conf"
+$ sudo sysctl --system
+```
+
+#### The technical details
+Listen uses `inotify` by default on Linux to monitor directories for changes.
+It's not uncommon to encounter a system limit on the number of files you can monitor.
+For example, Ubuntu Lucid's (64bit) `inotify` limit is set to 8192.
+
+You can get your current inotify file watch limit by executing:
+```
+$ cat /proc/sys/fs/inotify/max_user_watches
+```
+When this limit is not enough to monitor all files inside a directory, the limit must be increased for Listen to work properly.
+
+You can set a new limit temporarily with:
+```
+$ sudo sysctl fs.inotify.max_user_watches=524288
+$ sudo sysctl -p
+```
+If you like to make your limit permanent, use:
+```
+$ sudo sh -c "echo fs.inotify.max_user_watches=524288 >> /etc/sysctl.conf"
+$ sudo sysctl -p
+```
+You may also need to pay attention to the values of `max_queued_events` and `max_user_instances` if Listen keeps on complaining.
+
+#### More info
+Man page for [inotify(7)](https://linux.die.net/man/7/inotify).
+Blog post: [limit of inotify](https://blog.sorah.jp/2012/01/24/inotify-limitation).
+
+### Issues and Troubleshooting
+
+If the gem doesn't work as expected, start by setting `LISTEN_GEM_DEBUGGING=debug` or `LISTEN_GEM_DEBUGGING=info` as described above in [Logging and Debugging](#logging-and-debugging).
+
+*NOTE: without providing the output after setting the `LISTEN_GEM_DEBUGGING=debug` environment variable, it is usually impossible to guess why `listen` is not working as expected.*
+
+#### 3 steps before you start diagnosing problems
+These 3 steps will:
+
+- help quickly troubleshoot obscure problems (trust me, most of them are obscure)
+- help quickly identify the area of the problem (a full list is below)
+- help you get familiar with listen's diagnostic mode (it really comes in handy, trust me)
+- help you create relevant output before you submit an issue (so we can respond with answers instead of tons of questions)
+
+Step 1 - The most important option in Listen
+For effective troubleshooting set the `LISTEN_GEM_DEBUGGING=info` variable before starting `listen`.
+
+Step 2 - Verify polling works
+Polling has to work ... or something is really wrong (and we need to know that before anything else).
+
+(see force_polling option).
+
+After starting `listen`, you should see something like:
+```
+INFO -- : Record.build(): 0.06773114204406738 seconds
+```
+Step 3 - Trigger some changes directly without using editors or apps
+Make changes e.g. touch foo or echo "a" >> foo (for troubleshooting, avoid using an editor which could generate too many misleading events).
+
+You should see something like:
+```
+INFO -- : listen: raw changes: [[:added, "/home/me/foo"]]
+INFO -- : listen: final changes: {:modified=>[], :added=>["/home/me/foo"], :removed=>[]}
+```
+"raw changes" contains changes collected during the :wait_for_delay and :latency intervals, while "final changes" is what listen decided are relevant changes (for better editor support).
 
 ## Performance
 
-If Listen seems slow or unresponsive, make sure you're not using the Polling adapter (you should see a warning upon startup if you are).
+If `listen` seems slow or unresponsive, make sure you're not using the Polling adapter (you should see a warning upon startup if you are).
 
 Also, if the directories you're watching contain many files, make sure you're:
 
 * not using Polling (ideally)
 * using `:ignore` and `:only` options to avoid tracking directories you don't care about (important with Polling and on MacOS)
-* running Listen with the `:latency` and `:wait_for_delay` options not too small or too big (depends on needs)
+* running `listen` with the `:latency` and `:wait_for_delay` options not too small or too big (depends on needs)
 * not watching directories with log files, database files or other frequently changing files
-* not using a version of Listen prior to 2.7.7
-* not getting silent crashes within Listen (see LISTEN_GEM_DEBUGGING=2)
-* not running multiple instances of Listen in the background
+* not using a version of `listen` prior to 2.7.7
+* not getting silent crashes within `listen` (see `LISTEN_GEM_DEBUGGING=debug`)
+* not running multiple instances of `listen` in the background
 * using a file system with atime modification disabled (ideally)
 * not using a filesystem with inaccurate file modification times (ideally), e.g. HFS, VFAT
 * not buffering to a slow terminal (e.g. transparency + fancy font + slow gfx card + lots of output)
 * ideally not running a slow encryption stack, e.g. btrfs + ecryptfs
 
-When in doubt, LISTEN_GEM_DEBUGGING=2 can help discover the actual events and time they happened.
+When in doubt, `LISTEN_GEM_DEBUGGING=debug` can help discover the actual events and time they happened.
 
-See also [Tips and Techniques](https://github.com/guard/listen/wiki/Tips-and-Techniques).
+## Tips and Techniques
+- Watch only directories you're interested in.
+- Set your editor to save quickly (e.g. without backup files, without atomic-save)
+- Tweak the `:latency` and `:wait_for_delay` options until you get good results (see [options](#options)).
+- Add `:ignore` rules to silence all events you don't care about (reduces a lot of noise, especially if you use it on directories)
 
 ## Development
 

data/bin/listen

@@ -1,12 +1,11 @@
 #!/usr/bin/env ruby
+# frozen_string_literal: true
 
 require 'listen'
 require 'listen/cli'
 
-unless defined?(JRUBY_VERSION)
-  if Signal.list.keys.include?('INT')
-    Signal.trap('INT') { Thread.new { Listen.stop } }
-  end
+if !defined?(JRUBY_VERSION) && Signal.list.keys.include?('INT')
+  Signal.trap('INT') { Thread.new { Listen.stop } }
 end
 
 Listen::CLI.start