anchor.diff:      --broker-password $BROKER_PASSWORD
   ```
   
  -### Example of errand manifest
  +### Example of an Manifest
   
   ```
   jobs:
  
positive.code: export PATH=$PATH:/var/vcap/packages/ruby/bin
  cd /var/vcap/packages/broker-registrar
  
  CF_API_URL='<%= p("cf.api_url") %>'
  CF_ADMIN_USERNAME='<%= p("cf.admin_username") %>'
  CF_ADMIN_PASSWORD='<%= p("cf.admin_password") %>'
  BROKER_NAME='<%= p("broker.name") %>'
  BROKER_URL='http://<%= p("broker.host") %>:<%= p("broker.port") %>'
  BROKER_USERNAME='<%= p("broker.username") %>'
  BROKER_PASSWORD='<%= p("broker.password") %>'
  
  # partially-redacted command for debugging
  echo "
  
negative.code: 
  `bosh cancel task <task_name>`
  
  This will terminate the errand process, release the deployment lock, and refill the resource pool.
  
  ### Handling Errand Output
  
  In addition to stdout and stderror, the need exists to handle errand output.  When output is less than 1MB, it  is streamed to the screen. When output is larger than 1MB, it needs to be handle more specifically. By default, output is sent to a log file. These options exist:
  
  run errand <errand_name> [--download-logs] [--logs-dir  destination_directory]
      Run specified errand
      --download-logs                                    download logs
      --logs-dir destination_directory                   logs download directory
  
  Soon, the user will have the option to not save output to a log file and instead stream output > 1MB to the screen. (https://www.pivotaltracker.com/story/show/70384252)
  
  ### Listing Errands
  
  Coming soon: the directive that will allow to list all errands in a deployment.
  
  ### Warnings and Important Tips
  
  * Errands do not have a notion of persistence. The persistent disk migration for errands is not supported.
  
  * As part of `run errand` the BOSH deployment executes the drain script. If the drain script is exercising dynamic drain it might result in unpredicted behavior.
  
  * While an errand is running the director will hold a deployment lock which will prevent all other deploys. Additionally, `cloud check` CLI command will be unavailable and the health monitor will not scan and fix current deployments during the duration of the errand.