vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/other/debugging.html.md

@@ -0,0 +1,70 @@
+---
+layout: "docs"
+page_title: "Debugging and Troubleshooting"
+sidebar_current: "other-debugging"
+description: |-
+  As much as we try to keep Vagrant stable and bug free, it is inevitable
+  that issues will arise and Vagrant will behave in unexpected ways. In
+  these cases, Vagrant has amazing support channels available to assist you.
+---
+
+# Debugging
+
+As much as we try to keep Vagrant stable and bug free, it is inevitable
+that issues will arise and Vagrant will behave in unexpected ways.
+
+When using these support channels, it is generally helpful to include
+debugging logs along with any error reports. These logs can often help you
+troubleshoot any problems you may be having.
+
+!> **Scan for sensitive information!** Vagrant debug logs include information
+about your system including environment variables and user information. If you
+store sensitive information in the environment or in your user account, please
+scan or scrub the debug log of this information before uploading the contents to
+the public Internet.
+
+~> **Submit debug logs using GitHub Gist.** If you plan on submitting a bug
+report or issue that includes debug-level logs, please use a service like
+[Gist](https://gist.github.com). **Do not** paste the raw debug logs into an
+issue as it makes it very difficult to scroll and parse the information.
+
+To enable detailed logging, set the `VAGRANT_LOG` environmental variable
+to the desired log level name, which is one of `debug` (loud), `info` (normal),
+`warn` (quiet), and `error` (very quiet). When asking for support, please
+set this to `debug`. When troubleshooting your own issues, you should start
+with `info`, which is much quieter, but contains important information
+about the behavior of Vagrant.
+
+On Linux and Mac systems, this can be done by prepending the `vagrant`
+command with an environmental variable declaration:
+
+```
+$ VAGRANT_LOG=info vagrant up
+```
+
+On Windows, multiple steps are required:
+
+```
+$ set VAGRANT_LOG=info
+$ vagrant up
+```
+
+You can also get the debug level output using the `--debug` command line
+option. For example:
+
+```
+$ vagrant up --debug
+```
+
+On Linux and Mac, if you are saving the output to a file, you may need to redirect stderr and
+stdout using `&>`:
+
+```
+$ vagrant up --debug &> vagrant.log
+```
+
+On Windows in PowerShell (outputs to log and screen):
+
+```
+$ vagrant up --debug 2>&1 | Tee-Object -FilePath ".\vagrant.log"
+```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/other/environmental-variables.html.md

@@ -0,0 +1,226 @@
+---
+layout: "docs"
+page_title: "Environmental Variables"
+sidebar_current: "other-envvars"
+description: |-
+  Vagrant has a set of environmental variables that can be used to
+  configure and control it in a global way. This page lists those environmental
+  variables.
+---
+
+# Environmental Variables
+
+Vagrant has a set of environmental variables that can be used to
+configure and control it in a global way. This page lists those environmental
+variables.
+
+## `VAGRANT_DEBUG_LAUNCHER`
+
+For performance reasons, especially for Windows users, Vagrant uses a static
+binary to launch the actual Vagrant process. If you have _very_ early issues
+when launching Vagrant from the official installer, you can specify the
+`VAGRANT_DEBUG_LAUNCHER` environment variable to output debugging information
+about the launch process.
+
+## `VAGRANT_DEFAULT_PROVIDER`
+
+This configures the default provider Vagrant will use.
+
+This normally does not need to be set since Vagrant is fairly intelligent
+about how to detect the default provider. By setting this, you will force
+Vagrant to use this provider for any _new_ Vagrant environments. Existing
+Vagrant environments will continue to use the provider they came `up` with.
+Once you `vagrant destroy` existing environments, this will take effect.
+
+## `VAGRANT_PREFERRED_PROVIDERS`
+
+This configures providers that Vagrant should prefer.
+
+Much like the `VAGRANT_DEFAULT_PROVIDER` this environment variable normally
+does not need to be set. By setting this you will instruct Vagrant to
+_prefer_ providers defined in this environment variable for any _new_
+Vagrant environments. Existing Vagrant environments will continue to use
+the provider they came `up` with. Once you `vagrant destroy` existing environments,
+this will take effect. A single provider can be defined within this environment
+variable or a comma delimited list of providers.
+
+## `VAGRANT_BOX_UPDATE_CHECK_DISABLE`
+
+By default, Vagrant will query the metadata API server to see if a newer
+box version is available for download. This optional can be disabled on a
+per-Vagrantfile basis with `config.vm.box_check_update`, but it can also be
+disabled globally setting `VAGRANT_BOX_UPDATE_CHECK_DISABLE` to any non-empty
+value.
+
+This option will not affect global box functions like `vagrant box update`.
+
+## `VAGRANT_CHECKPOINT_DISABLE`
+
+Vagrant does occasional network calls to check whether the version of Vagrant
+that is running locally is up to date. We understand that software making remote
+calls over the internet for any reason can be undesirable. To suppress these
+calls, set the environment variable `VAGRANT_CHECKPOINT_DISABLE` to any
+non-empty value.
+
+If you use other HashiCorp tools like Packer and would prefer to configure this
+setting only once, you can set `CHECKPOINT_DISABLE` instead.
+
+## `VAGRANT_CWD`
+
+`VAGRANT_CWD` can be set to change the working directory of Vagrant. By
+default, Vagrant uses the current directory you are in. The working directory
+is important because it is where Vagrant looks for the Vagrantfile. It
+also defines how relative paths in the Vagrantfile are expanded, since they're
+expanded relative to where the Vagrantfile is found.
+
+This environmental variable is most commonly set when running Vagrant from
+a scripting environment in order to set the directory that Vagrant sees.
+
+## `VAGRANT_DOTFILE_PATH`
+
+`VAGRANT_DOTFILE_PATH` can be set to change the directory where Vagrant stores
+VM-specific state, such as the VirtualBox VM UUID. By default, this is set to
+`.vagrant`. If you keep your Vagrantfile in a Dropbox folder in order to share
+the folder between your desktop and laptop (for example), Vagrant will overwrite
+the files in this directory with the details of the VM on the most recently-used
+host. To avoid this, you could set `VAGRANT_DOTFILE_PATH` to `.vagrant-laptop`
+and `.vagrant-desktop` on the respective machines. (Remember to update your
+`.gitignore`!)
+
+## `VAGRANT_HOME`
+
+`VAGRANT_HOME` can be set to change the directory where Vagrant stores
+global state. By default, this is set to `~/.vagrant.d`. The Vagrant home
+directory is where things such as boxes are stored, so it can actually become
+quite large on disk.
+
+## `VAGRANT_LOG`
+
+`VAGRANT_LOG` specifies the verbosity of log messages from Vagrant.
+By default, Vagrant does not actively show any log messages.
+
+Log messages are very useful when troubleshooting issues, reporting
+bugs, or getting support. At the most verbose level, Vagrant outputs
+basically everything it is doing.
+
+Available log levels are "debug," "info," "warn," and "error." Both
+"warn" and "error" are practically useless since there are very few
+cases of these, and Vagrant generally reports them within the normal
+output.
+
+"info" is a good level to start with if you are having problems, because
+while it is much louder than normal output, it is still very human-readable
+and can help identify certain issues.
+
+"debug" output is _extremely_ verbose and can be difficult to read without
+some knowledge of Vagrant internals. It is the best output to attach to
+a support request or bug report, however.
+
+## `VAGRANT_NO_COLOR`
+
+If this is set to any value, then Vagrant will not use any colorized
+output. This is useful if you are logging the output to a file or
+on a system that does not support colors.
+
+The equivalent behavior can be achieved by using the `--no-color` flag
+on a command-by-command basis. This environmental variable is useful
+for setting this flag globally.
+
+## `VAGRANT_FORCE_COLOR`
+
+If this is set to any value, then Vagrant will force colored output, even
+if it detected that there is no TTY or the current environment does not
+support it.
+
+The equivalent behavior can be achieved by using the `--color` flag on a
+command-by-command basis. This environmental variable is useful for setting
+this flag globally.
+
+## `VAGRANT_NO_PLUGINS`
+
+If this is set to any value, then Vagrant will not load any 3rd party
+plugins. This is useful if you install a plugin and it is introducing
+instability to Vagrant, or if you want a specific Vagrant environment to
+not load plugins.
+
+Note that any `vagrant plugin` commands automatically do not load any
+plugins, so if you do install any unstable plugins, you can always use
+the `vagrant plugin` commands without having to worry.
+
+## `VAGRANT_ALLOW_PLUGIN_SOURCE_ERRORS`
+
+If this is set to any value, then Vagrant will not error when a configured
+plugin source is unavailable. When installing a Vagrant plugin Vagrant
+will error and halt if a plugin source is inaccessible. In some cases it
+may be desirable to ignore inaccessible sources and continue with the
+plugin installation. Enabling this value will cause Vagrant to simply log
+the plugin source error and continue.
+
+## `VAGRANT_NO_PARALLEL`
+
+If this is set, Vagrant will not perform any parallel operations (such as
+parallel box provisioning). All operations will be performed in serial.
+
+## `VAGRANT_DETECTED_OS`
+
+This environment variable may be set by the Vagrant launcher to help determine
+the current runtime platform. In general Vagrant will set this value when running
+on a Windows host using a cygwin or msys based shell. If this value is set, the
+Vagrant launcher will not modify it.
+
+## `VAGRANT_DETECTED_ARCH`
+
+This environment variable may be set by the Vagrant launcher to help determine
+the current runtime architecture in use. In general Vagrant will set this value
+when running on a Windows host using a cygwin or msys based shell. The value
+the Vagrant launcher may set in this environment variable will not always match
+the actual architecture of the platform itself. Instead it signifies the detected
+architecture of the environment it is running within. If this value is set, the
+Vagrant launcher will not modify it.
+
+## `VAGRANT_WINPTY_DISABLE`
+
+If this is set, Vagrant will _not_ wrap interactive processes with winpty where
+required.
+
+## `VAGRANT_PREFER_SYSTEM_BIN`
+
+If this is set, Vagrant will prefer using utility executables (like `ssh` and `rsync`)
+from the local system instead of those vendored within the Vagrant installation.
+This currently only applies to Windows systems.
+
+## `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`
+
+As of Vagrant 1.7.3, Vagrant tries to intelligently detect if it is running in
+the installer or running via Bundler. Although not officially supported, Vagrant
+tries its best to work when executed via Bundler. When Vagrant detects that you
+have spawned a subprocess that lives outside of Vagrant's installer, Vagrant
+will do its best to reset the preserved environment dring the subprocess
+execution.
+
+If Vagrant detects it is running outside of the officially installer, the
+original environment will always be restored. You can disable this automatic
+jailbreak by setting `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`.
+
+## `VAGRANT_VAGRANTFILE`
+
+This specifies the filename of the Vagrantfile that Vagrant searches for.
+By default, this is "Vagrantfile". Note that this is _not_ a file path,
+but just a filename.
+
+This environmental variable is commonly used in scripting environments
+where a single folder may contain multiple Vagrantfiles representing
+different configurations.
+
+## `VAGRANT_DISABLE_VBOXSYMLINKCREATE`
+
+If set, this will disable the ability to create symlinks with all virtualbox
+shared folders. Defaults to true if the option is not set. This can be overriden
+on a per-folder basis within your Vagrantfile config by settings the
+`SharedFoldersEnableSymlinksCreate` option to true.
+
+## `VAGRANT_DISABLE_RESOLV_REPLACE`
+
+Vagrant will automatically load `resolv-replace` to use Ruby's Resolv library
+in place of the libc resolver. This behavior can be disabled by setting this
+environment variable.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/other/index.html.md

@@ -0,0 +1,16 @@
+---
+layout: "docs"
+page_title: "Other"
+sidebar_current: "other"
+description: |-
+  This page covers Vagrant information that does not quite fit under the other
+  categories.
+---
+
+# Other
+
+This section covers other information that does not quite fit under the
+other categories.
+
+- [Debugging](/docs/other/debugging.html)
+- [Environment Variables](/docs/other/environmental-variables.html)

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/other/wsl.html.md

@@ -0,0 +1,132 @@
+---
+layout: "docs"
+page_title: "Vagrant and Windows Subsystem for Linux"
+sidebar_current: "other-wsl"
+description: |-
+  An overview of using Vagrant on Windows within the Windows Subsystem
+  for Linux.
+---
+
+# Vagrant and Windows Subsystem for Linux
+
+Windows has recently introduced a new feature called the Windows Subsystem
+for Linux (WSL). This is a beta feature available in developer mode on recent
+releases of Windows 10. It is important to note that this feature is still
+in _beta_ on Windows, and Vagrant support should be considered _alpha_.
+
+<div class="alert alert-warning">
+  <strong>Warning: Advanced Topic!</strong> Using Vagrant within the Windows
+  Subsystem for Linux is an advanced topic that only experienced Vagrant users
+  who are reasonably comfortable with Windows, WSL, and Linux should approach.
+</div>
+
+
+# Installation
+
+Installation requires WSL, Ubuntu on Windows, and Vagrant. Read on for installation
+instructions for each item.
+
+## Windows Subsystem for Linux and Ubuntu on Windows
+
+First install the Windows Subsystem for Linux, followed by Ubuntu on Windows. This guide
+from Microsoft walks through the process:
+
+* https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
+
+## Vagrant Installation
+
+Vagrant _must_ be installed within Ubuntu on Windows. Even though the `vagrant.exe`
+file can be executed from within the WSL, it will not function as expected. To
+install Vagrant into the WSL, follow these steps:
+
+* Download the 64-bit Debian package from the downloads page.
+* Open a `cmd` or `powershell` window
+* Enter the command: `bash`
+* Install vagrant: `sudo dpkg -i vagrant_VERSION_x86_64.deb`
+
+```
+C:\Users\vagrant> bash
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ sudo dpkg -i vagrant_VERSION_x86_64.deb
+[sudo] password for vagrant:
+(Reading database ... 31885 files and directories currently installed.)
+Preparing to unpack vagrant_VERSION_x86_64.deb ...
+Unpacking vagrant (1:VERSION) ...
+Setting up vagrant (1:VERSION) ...
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ vagrant help
+Usage: vagrant [options] <command> [<args>]
+```
+
+# Vagrant Usage
+
+Vagrant will detect when it is being run within the WSL and adjust how it
+locates and executes third party executables. For example, when using the
+VirtualBox provider Vagrant will interact with VirtualBox installed on
+the Windows system, not within the WSL. It is important to ensure that
+any required Windows executable is available within your `PATH` to allow
+Vagrant to access them.
+
+For example, when using the VirtualBox provider:
+
+```
+export PATH="$PATH:/mnt/c/Program Files/Oracle/VirtualBox"
+```
+
+## Windows Access
+
+Working within the WSL provides a layer of isolation from the actual
+Windows system. In most cases Vagrant will need access to the actual
+Windows system to function correctly. As most Vagrant providers will
+need to be installed on Windows directly (not within the WSL) Vagrant
+will require Windows access. Access to the Windows system is controlled
+via an environment variable: `VAGRANT_WSL_ENABLE_WINDOWS_ACCESS`. If
+this environment variable is set, Vagrant will access the Windows system
+to run executables and enable things like synced folders. When running
+in a bash shell within WSL, the environment variable can be setup like so:
+
+```
+$ export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS="1"
+```
+
+This will enable Vagrant to access the Windows system outside of the
+WSL and properly interact with Windows executables. This will automatically
+modify the `VAGRANT_HOME` environment variable if it is not already defined,
+setting it to be within the user's home directory on Windows.
+
+It is important to note that paths shared with the Windows system will
+not have Linux permissions enforced. For example, when a directory within
+the WSL is synced to a guest using the VirtualBox provider, any local
+permissions defined on that directory (or its contents) will not be
+visible from the guest. Likewise, any files created from the guest within
+the synced folder will be world readable/writeable in WSL.
+
+Other useful WSL related environment variables:
+
+* `VAGRANT_WSL_WINDOWS_ACCESS_USER` - Override current Windows username
+* `VAGRANT_WSL_DISABLE_VAGRANT_HOME` - Do not modify the `VAGRANT_HOME` variable
+* `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` - Custom Windows system home path
+
+If a Vagrant project directory is not within the user's home directory on the
+Windows system, certain actions that include permission checks may fail (like
+`vagrant ssh`). When accessing Vagrant projects outside the WSL Vagrant will
+skip these permission checks when the project path is within the path defined
+in the `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` environment variable. For
+example, if a user wants to run a Vagrant project from the WSL that is located
+at `C:\TestDir\vagrant-project`:
+
+```
+C:\Users\vagrant> cd C:\TestDir\vagrant-project
+C:\TestDir\vagrant-project> bash
+vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/TestDir"
+vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ vagrant ssh
+```
+
+## Using Docker
+
+The docker daemon cannot be run inside the Windows Subsystem for Linux. However,
+the daemon _can_ be run on Windows and accessed by Vagrant while running in the
+WSL. Once docker is installed and running on Windows, export the following
+environment variable to give Vagrant access:
+
+```
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ export DOCKER_HOST=tcp://127.0.0.1:2375
+```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/action-hooks.html.md

@@ -0,0 +1,103 @@
+---
+layout: "docs"
+page_title: "Plugin Development Basics - Action Hooks"
+sidebar_current: "plugins-action-hooks"
+description: |-
+  Action hooks provide ways to interact with Vagrant at a very low level by
+  injecting middleware in various phases of Vagrant's lifecycle. This is an
+  advanced option, even for plugin development.
+---
+
+# Action Hooks
+
+Action hooks provide ways to interact with Vagrant at a very low level by
+injecting middleware in various phases of Vagrant's lifecycle. This is an
+advanced option, even for plugin development.
+
+<div class="alert alert-warning">
+  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
+  advanced topic that only experienced Vagrant users who are reasonably
+  comfortable with Ruby should approach.
+</div>
+
+
+## Public Action Hooks
+
+The following action hooks are available in the core of Vagrant. Please note
+that this list is not exhaustive and additional hooks can be added via plugins.
+
+- `environment_plugins_loaded` - called after the plugins have been loaded,
+  but before the configurations, provisioners, providers, etc. are loaded.
+
+
+- `environment_load` - called after the environment and all configurations are
+  fully loaded.
+
+
+- `environment_unload` - called after the environment is done being used. The
+  environment should not be used in this hook.
+
+
+- `machine_action_boot` - called after the hypervisor has reported the machine
+  was booted.
+
+
+- `machine_action_config_validate` - called after all `Vagrantfile`s have been
+  loaded, merged, and validated.
+
+
+- `machine_action_destroy` - called after the hypervisor has reported the
+  virtual machine is down.
+
+
+- `machine_action_halt` - called after the hypervision has moved the machine
+  into a halted state (usually "stopped" but not "terminated").
+
+
+- `machine_action_package` - called after Vagrant has successfully packaged a
+  new box.
+
+
+- `machine_action_provision` - called after all provisioners have executed.
+
+
+- `machine_action_read_state` - called after Vagrant has loaded state from
+  disk and the hypervisor.
+
+
+- `machine_action_reload` - called after a virtual machine is reloaded (varies
+  by hypervisor).
+
+
+- `machine_action_resume` - called after a virtual machine is moved from the
+  halted to up state.
+
+
+- `machine_action_run_command` - called after a command is executed on the
+  machine.
+
+
+- `machine_action_ssh` - called after an SSH connection has been established.
+
+
+- `machine_action_ssh_run` - called after an SSH command is executed.
+
+
+- `machine_action_start` - called after the machine has been started.
+
+
+- `machine_action_suspend` - called after the machine has been suspended.
+
+
+- `machine_action_sync_folders` - called after synced folders have been set up.
+
+
+- `machine_action_up` - called after the machine has entered the up state.
+
+
+## Private API
+
+You may find additional action hooks if you browse the Vagrant source code, but
+only the list of action hooks here are guaranteed to persist between Vagrant
+releases. Please do not rely on the internal API as it is subject to change
+without notice.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/plugins/commands.html.md

@@ -0,0 +1,135 @@
+---
+layout: "docs"
+page_title: "Command Plugins - Plugin Development"
+sidebar_current: "plugins-commands"
+description: |-
+  This page documents how to add new commands to Vagrant, invokable
+  via "vagrant YOUR-COMMAND". Prior to reading this, you should be familiar
+  with the plugin development basics.
+---
+
+# Plugin Development: Commands
+
+This page documents how to add new commands to Vagrant, invokable
+via `vagrant YOUR-COMMAND`. Prior to reading this, you should be familiar
+with the [plugin development basics](/docs/plugins/development-basics.html).
+
+<div class="alert alert-warning">
+  <strong>Warning: Advanced Topic!</strong> Developing plugins is an
+  advanced topic that only experienced Vagrant users who are reasonably
+  comfortable with Ruby should approach.
+</div>
+
+## Definition Component
+
+Within the context of a plugin definition, new commands can be defined
+like so:
+
+```ruby
+command "foo" do
+  require_relative "command"
+  Command
+end
+```
+
+Commands are defined with the `command` method, which takes as an argument
+the name of the command, in this case "foo." This means the command will be
+invokable via `vagrant foo`. Then the block argument returns a class that
+implements the `Vagrant.plugin(2, "command")` interface.
+
+You can also define _non-primary commands_. These commands do not show
+up in the `vagrant -h` output. They only show up if the user explicitly
+does a `vagrant list-commands` which shows the full listing of available
+commands. This is useful for highly specific commands or plugins that a
+beginner to Vagrant would not be using anyways. Vagrant itself uses non-primary
+commands to expose some internal functions, as well.
+
+To define a non-primary command:
+
+```ruby
+command("foo", primary: false) do
+  require_relative "command"
+  Command
+end
+```
+
+## Implementation
+
+Implementations of commands should subclass `Vagrant.plugin(2, :command)`,
+which is a Vagrant method that will return the proper superclass for
+a version 2 command. The implementation itself is quite simple, since the
+class needs to only implement a single method: `execute`. Example:
+
+```ruby
+class Command < Vagrant.plugin(2, :command)
+  def execute
+    puts "Hello!"
+    0
+  end
+end
+```
+
+The `execute` method is called when the command is invoked, and it should
+return the exit status (0 for success, anything else for error).
+
+This is a command at its simplest form. Of course, the command superclass
+gives you access to the Vagrant environment and provides some helpers to
+do common tasks such as command line parsing.
+
+## Parsing Command-Line Options
+
+The `parse_options` method is available which will parse the command line
+for you. It takes an [OptionParser](http://ruby-doc.org/stdlib-1.9.3/libdoc/optparse/rdoc/OptionParser.html)
+as an argument, and adds some common elements to it such as the `--help` flag,
+automatically showing help if requested. View the API docs directly for more
+information.
+
+This is recommended over raw parsing/manipulation of command line flags.
+The following is an example of parsing command line flags pulled directly
+from the built-in Vagrant `destroy` command:
+
+```ruby
+options = {}
+options[:force] = false
+
+opts = OptionParser.new do |o|
+  o.banner = "Usage: vagrant destroy [vm-name]"
+  o.separator ""
+
+  o.on("-f", "--force", "Destroy without confirmation.") do |f|
+    options[:force] = f
+  end
+end
+
+# Parse the options
+argv = parse_options(opts)
+```
+
+## Using Vagrant Machines
+
+The `with_target_vms` method is a helper that helps you interact with
+the machines that Vagrant manages in a standard Vagrant way. This method
+automatically does the right thing in the case of multi-machine environments,
+handling target machines on the command line (`vagrant foo my-vm`), etc.
+If you need to do any manipulation of a Vagrant machine, including SSH
+access, this helper should be used.
+
+An example of using the helper, again pulled directly from the built-in
+`destroy` command:
+
+```ruby
+with_target_vms(argv, reverse: true) do |machine|
+  machine.action(:destroy)
+end
+```
+
+In this case, it asks for the machines in reverse order and calls the
+destroy action on each of them. If a user says `vagrant destroy foo`, then
+the helper automatically only yields the `foo` machine. If no parameter
+is given and it is a multi-machine environment, every machine in the environment
+is yielded, and so on. It just does the right thing.
+
+## Using the Raw Vagrant Environment
+
+The raw loaded `Vagrant::Environment` object is available with the
+'@env' instance variable.