inspec/docs/resources/command.md.erb

---
title: About the command Resource
---

# command

Use the `command` InSpec audit resource to test an arbitrary command that is run on the system.

## Syntax

A `command` resource block declares a command to be run, one (or more) expected outputs, and the location to which that output is sent:

    describe command('command') do
      it { should exist }
      its('matcher') { should eq 'output' }
    end

where

* `'command'` must specify a command to be run
* `'matcher'` is one of `exit_status`, `stderr`, or `stdout`
* `'output'` tests the output of the command run on the system versus the output value stated in the test


## Matchers

This InSpec audit resource has the following matchers:

### be

<%= partial "/shared/matcher_be" %>

### cmp

<%= partial "/shared/matcher_cmp" %>

### eq

<%= partial "/shared/matcher_eq" %>

### exist

The `exist` matcher tests if a command may be run on the system:

    it { should exist }

### exit_status

The `exit_status` matcher tests the exit status for the command:

    its('exit_status') { should eq 123 }

### include

<%= partial "/shared/matcher_include" %>

### match

<%= partial "/shared/matcher_match" %>

### stderr

The `stderr` matcher tests results of the command as returned in standard error (stderr):

    its('stderr') { should eq 'error' }

### stdout

The `stdout` matcher tests results of the command as returned in standard output (stdout). The following example shows matching output using a regular expression:

    describe command('echo 1') do
       its('stdout') { should match (/[0-9]/) }
    end

## Examples

The following examples show how to use this InSpec audit resource.

### Test for PostgreSQL database running a RC, development, or beta release

    describe command('psql -V') do
      its('stdout') { should eq '/RC/' }
      its('stdout') { should_not eq '/DEVEL/' }
      its('stdout') { should_not eq '/BETA/' }
    end

### Test standard output (stdout)

    describe command('echo hello') do
      its('stdout') { should eq 'hello\n' }
      its('stderr') { should eq '' }
      its('exit_status') { should eq 0 }
    end

### Test standard error (stderr)

    describe command('>&2 echo error') do
      its('stdout') { should eq '' }
      its('stderr') { should eq 'error\n' }
      its('exit_status') { should eq 0 }
    end

### Test an exit status code

    describe command('exit 123') do
      its('stdout') { should eq '' }
      its('stderr') { should eq '' }
      its('exit_status') { should eq 123 }
    end

### Test if the command shell exists

    describe command('/bin/sh').exist? do
      it { should eq true }
    end

### Test for a command that should not exist

    describe command('this is not existing').exist? do
      it { should eq false }
    end

### Verify NTP

The following example shows how to use the `file` audit resource to verify if the `ntp.conf` and `leap-seconds` files are present, and then the `command` resource to verify if NTP is installed and running:

    describe file('/etc/ntp.conf') do
       it { should be_file }
    end

    describe file('/etc/ntp.leapseconds') do
      it { should be_file }
    end

    describe command('pgrep ntp') do
       its('exit_status') { should eq 0 }
    end

### Verify WiX

Wix includes serveral tools -- such as `candle` (preprocesses and compiles source files into object files), `light` (links and binds object files to an installer database), and `heat` (harvests files from various input formats). The following example uses a whitespace array and the `file` audit resource to verify if these three tools are present:

    %w(
      candle.exe
      heat.exe
      light.exe
    ).each do |utility|
      describe file("C:/wix/##{utility}") do
        it { should be_file }
      end
    end