Skip to content

Command line options for Guard

Jump to bottom Edit New page
Rémy Coutable edited this page Mar 3, 2018 · 8 revisions

You can use additional command line options to enhance Guard. These can be appended to the command line:

$ bundle exec guard <option>

UI options

Config options

Listen Options

-c/--clear option

The shell can be cleared after each change:

$ bundle exec guard --clear
$ bundle exec guard -c # shortcut

You may prefer to enable clearing in all projects by addin the clearing statement (described below) in you ~/.guard.rb instead:

clearing :on

-n/--notify option

System notifications can be disabled:

$ bundle exec guard --notify false
$ bundle exec guard -n f # shortcut

Notifications can also be disabled globally by setting a GUARD_NOTIFY environment variable to false.

-g/--group option

Scope Guard to certain plugin groups on start:

$ bundle exec guard --group group_name another_group_name
$ bundle exec guard -g group_name another_group_name # shortcut

See the Guardfile DSL below for creating groups.

-P/--plugin option

Scope Guard to certain plugins on start:

$ bundle exec guard --plugin plugin_name another_plugin_name
$ bundle exec guard -P plugin_name another_plugin_name # shortcut

-d/--debug option

Guard can display debug information (useful for plugin developers) with:

$ bundle exec guard --debug
$ bundle exec guard -d # shortcut

-w/--watchdir option

Guard by default watches the current directory recursively, but you can tell Guard to watch only the directories you want:

$ bundle exec guard --watchdir source/files # watch a subdirectory of your project
$ bundle exec guard -w source/files # shortcut
$ bundle exec guard -w sources/foo assets/foo ./config # multiple directories

$ bundle exec guard -w /fancy/project # path outside project - watch out! (see below)

NOTE: this option is only meant for ignoring subdirectories in the CURRENT directory - by selecting which ones to actually track.

If your watched directories are outside the current one, or if --watchdir isn't working as you expect, be sure to read: Correctly using --watchdir

You may find it more convenient to use the directories statement (described below) in your Guardfile.

-G/--guardfile option

Guard can use a Guardfile not located in the current directory:

$ bundle exec guard --guardfile ~/.your_global_guardfile
$ bundle exec guard -G ~/.your_global_guardfile # shortcut

TIP: set BUNDLER_GEMFILE environment variable to point to your Gemfile if it isn't in the current directory or the current Gemfile doesn't include all your favorite plugins

-i/--no-interactions option

Turn off completely any Guard terminal interactions with:

$ bundle exec guard start -i
$ bundle exec guard start --no-interactions

-B/--no-bundler-warning option

Skip Bundler warning when a Gemfile exists in the project directory but Guard is not run with Bundler.

$ bundle exec guard start -B
$ bundle exec guard start --no-bundler-warning

-l/--latency option

Overwrite Listen's default latency, useful when your hard-drive / system is slow.

$ bundle exec guard start -l 1.5
$ bundle exec guard start --latency 1.5

NOTE: this option is OS specific: while higher values may reduce CPU usage (and lower values may increase responsiveness) when in polling mode , it has no effect for optimized backends (except on Mac OS). If guard is not behaving as you want, you'll likely instead want to tweak the --wait-for-delay option below or use the --watchdirs option.

-p/--force-polling option

Force Listen polling listener usage.

$ bundle exec guard start -p
$ bundle exec guard start --force-polling

-y/--wait-for-delay option

Overwrite Listen's default wait_for_delay, useful for kate-like editors through ssh access or when guard is annoyingly running tasks multiple times.

$ bundle exec guard start -y 1
$ bundle exec guard start --wait-for-delay 1

-T option

You can show the structure of the groups and their plugins with the show task:

$ bundle exec guard show
+---------+--------+-----------------+----------------------------+
| Group   | Plugin | Option          | Value                      |
+---------+--------+-----------------+----------------------------+
| Specs   | Rspec  | all_after_pass  | true                       |
|         |        | all_on_start    | true                       |
|         |        | cli             | "--fail-fast --format doc" |
|         |        | focus_on_failed | false                      |
|         |        | keep_failed     | true                       |
|         |        | run_all         | {}                         |
|         |        | spec_paths      | ["spec"]                   |
+---------+--------+-----------------+----------------------------+
| Docs    | Ronn   |                 |                            |
+---------+--------+-----------------+----------------------------+

This shows the internal structure of the evaluated Guardfile or .Guardfile, with the .guard.rb file. You can read more about these files in the shared configuration section.

-b/--bare option

You can generate an empty Guardfile by running the init task with the bare option:

$ bundle exec guard init --bare
$ bundle exec guard init -b # shortcut

Running Guard in a VM

-o/--listen-on option (Listen < 3.0 only)

If you're using Listen >= 3.0, this option doesn't work anymore as TCP support was removed from Listen 3.0. There is a workaround that you can use if you want to listen for events in a VM and forward them to Guard that is running on your native OS: https://github.com/guard/listen/issues/258#issuecomment-222924196

Use Listen's network functionality to receive file change events from the network. This is most useful for virtual machines (e.g. Vagrant) which have problems firing native filesystem events on the guest OS.

Suggested use:

On the host OS, you need to listen to filesystem events and forward them to your VM using the listen script:

$ listen -f 127.0.0.1:4000

Remember to configure your VM to forward the appropriate ports, e.g. in Vagrantfile:

config.vm.network :forwarded_port, guest: 4000, host: 4000

Then, on your guest OS, listen to the network events but ensure you specify the host path

$ bundle exec guard -o '10.0.2.2:4000' -w '/projects/myproject'

This wiki and the Guard README document contain a lot of information, please take your time and read these instructions carefully.

If you run into any trouble, you may start by understanding how Guard works.

We provide detailed changes for each Guard release.

Be sure to read the CONTRIBUTING guidelines before reporting a new Guard issue or open a pull request.

If you have any questions about the Guard usage or want to share some information with the Guard community, please go to one of the following places:

Add a custom sidebar
Clone this wiki locally