<!-- @generated by usage-cli from usage spec -->

# `usage explain`

- **Usage**: `usage explain [FLAGS] [ARGV]…`
- **Effect**: read-only
- **Source code**: [`cli/src/cli/explain.rs`](https://github.com/jdx/usage/blob/main/cli/src/cli/explain.rs)

Explain what a command line binds to

Prints a row per argv token saying what it became, then the values that came from
somewhere other than argv, then anything that went wrong. Exits 0 even when the explained
command line does not parse: the report succeeded, and that is the case worth a report.

## Arguments

### `[ARGV]…`

The command line to explain, starting with the program name

`usage`'s own flags come before it, and flag parsing ends at the program name, so both `explain -f f.kdl mycli --env=prod` and `explain -f f.kdl -- mycli --env=prod` work. Separate with `--` when the explained line carries its own: the first `--` is still `usage`'s separator, so `explain -f f.kdl mycli a -- b` loses one.

## Flags

### `-f --file <FILE>`

A usage spec file or script with a usage shebang, use "-" to read from stdin

### `-s --spec <SPEC>`

Raw string spec input

### `--format <FORMAT>`

Output format

**Choices:**

- `text`
- `json`

**Default:** `text`

### `--view <VIEW>`

A spec-declared executable view to explain

### `-e --env… <ENV>`

Environment to explain against, as KEY=VALUE, repeatable

Given at all, these are the _whole_ environment: an explanation pasted into a bug report has to mean the same thing on the machine that reads it. Omitted, the process environment is used, which is what an execution would see.
