Use true for Successful No-Op Checks in Shell Scripts

true does one thing: it succeeds, silently, every time. This guide shows where that earns its keep in a script, and how to tell the shell builtin from GNU true when the difference matters. The examples use GNU coreutils 9.4, installed here as package version 9.4-3ubuntu6.3.

Allow about five minutes. You need a shell. No elevated privileges are required, and this guide only runs read-only or harmless commands. Nothing changes on disk, in the environment or in a service.

1. Run true as a successful no-op

Run the command on its own:

$ true
$ printf 'exit status: %s\n' "$?"
exit status: 0

true exits with status 0 and normally writes nothing. In shell syntax, that makes it useful as the final command in a branch that has handled a condition successfully, or as a temporary command while you are building a pipeline.

The second command is a checkpoint. Shells store the exit status of the command that ran immediately before it, so print $? straight away. Running printf, echo or another diagnostic command first will replace the status you meant to inspect.

2. Pass arguments without expecting them to be acted on

GNU true accepts ordinary command-line arguments and still succeeds:

$ /usr/bin/true ignored-value another-value
$ printf 'exit status: %s\n' "$?"
exit status: 0

The arguments are ignored. They are not a filename, expression or condition, and true does not print them. This can be useful when a command slot requires an executable but the operation is deliberately empty.

Do not use ignored arguments as a hidden configuration channel. A later reader may reasonably assume that the values matter. If the arguments are meant to document why a branch is empty, a shell comment is more honest:

if [ "$MODE" = 'dry-run' ]; then
    # No state-changing command belongs in this branch.
    true
fi

Checkpoint: the following should print 0, even though the arguments are present:

$ /usr/bin/true --anything
$ printf '%s\n' "$?"
0

3. Separate true from a test that can fail

true does not answer a question. It always reports success, apart from an execution failure outside its normal contract. For a condition, use a test command that can return both outcomes:

if [ -r /etc/hosts ]; then
    printf '%s\n' 'hosts file is readable'
else
    printf '%s\n' 'hosts file is not readable' >&2
    exit 1
fi

Here [ performs the check. The true command would make the if body appear successful regardless of the file state, which would hide the failure you meant to detect.

A common distraction is reading true as if it were a boolean expression. In a shell, it is an executable command with an exit status. Use true or false when you intentionally need a fixed status; use [, test or another purpose-built command when you need evidence.

4. Check which implementation your shell selects

Your shell may provide a builtin named true, which usually takes precedence over the external GNU program. Check the resolution without changing anything:

$ command -V true
true is a shell builtin
$ command -v true
true

The exact output varies by shell. The important point is that command -V identifies the selected command, while command -v prints a path only when the selected implementation is external. Bash, dash and other shells can have their own builtin behaviour and supported options.

When you specifically need the installed GNU program, use its absolute path:

$ /usr/bin/true
$ printf 'GNU true status: %s\n' "$?"
GNU true status: 0

This distinction matters for the two informational options documented by GNU true. It does not usually matter for the ordinary no-op, but it matters when you are checking help or version output.

5. Inspect help and version information

Ask the external program for its supported options:

$ /usr/bin/true --help
Usage: /usr/bin/true [ignored command line arguments]
  or:  /usr/bin/true OPTION
Exit with a status code indicating success.

      --help        display this help and exit
      --version     output version information and exit
$ /usr/bin/true --version
true (GNU coreutils) 9.4

Both options print information and exit successfully. They are exceptions to the usual silent no-op behaviour. Treat the displayed version as host-specific: package updates can change it. To record the package version on a Debian or Ubuntu system, run:

$ dpkg-query -W -f='${Package} ${Version}\n' coreutils
coreutils 9.4-3ubuntu6.3

If a script requires GNU-specific option behaviour, call the known external path or check the command implementation before relying on it. Do not assume that a shell builtin accepts every GNU option.

6. Avoid the false-success trap in pipelines

Adding true at the end of a pipeline can make the pipeline look successful, depending on the shell's pipeline-status rules. For example, this command prints status 0 even though the first command fails:

$ sh -c 'printf "%s\n" failure >&2; exit 7' | true
$ printf 'pipeline status: %s\n' "$?"
pipeline status: 0

That is only safe when you deliberately want to discard the upstream failure. If the failure matters, keep the real command as the status-bearing operation and use your shell's documented pipeline error handling. In Bash, set -o pipefail is a policy choice for the script, not something that true enables.

Done means