doccmd

A command line tool for running commands against code blocks in documentation files. This allows you to run linters, formatters, and other tools against the code blocks in your documentation files.

Installation

With pip

Requires Python 3.11+.

$ pip install doccmd

With Homebrew (macOS, Linux, WSL)

Requires Homebrew.

$ brew tap adamtheturtle/doccmd
$ brew install doccmd

With winget (Windows)

Requires winget.

$ winget install --id adamtheturtle.doccmd --source winget --exact

The winget package may not be the latest version.

Pre-built Linux (x86) binaries

$ curl --fail -L "https://github.com/adamtheturtle/doccmd/releases/download/2026.03.02/doccmd-linux" -o /usr/local/bin/doccmd &&
    chmod +x /usr/local/bin/doccmd

Pre-built macOS (ARM) binaries

$ curl --fail -L "https://github.com/adamtheturtle/doccmd/releases/download/2026.03.02/doccmd-macos" -o /usr/local/bin/doccmd &&
    chmod +x /usr/local/bin/doccmd

You may need to remove the quarantine attribute to run the binary:

$ xattr -d com.apple.quarantine /usr/local/bin/doccmd

Pre-built Windows binaries

Download the Windows executable from the latest release and place it in a directory on your PATH.

With Docker

$ docker run --rm -v "$(pwd):/workdir" -w /workdir "ghcr.io/adamtheturtle/doccmd" --help

With Nix

Requires Nix.

$ nix --extra-experimental-features 'nix-command flakes' run "github:adamtheturtle/doccmd/2026.03.02" -- --help

To avoid passing --extra-experimental-features every time, enable flakes permanently.

Or add to your flake inputs:

{
  inputs.doccmd.url = "github:adamtheturtle/doccmd";
}

Using doccmd as a pre-commit hook

To run doccmd with pre-commit, add hooks like the following to your .pre-commit-config.yaml:

-   repo: https://github.com/adamtheturtle/doccmd-pre-commit
    rev: v2026.03.02
    hooks:
    -   id: doccmd
        args: ["--language", "shell", "--command", "shellcheck --shell=bash"]
        additional_dependencies: ["shellcheck-py"]

Usage example

# Run mypy against the Python code blocks in README.md and CHANGELOG.rst
$ doccmd --language=python --command="mypy" README.md CHANGELOG.rst

# Run gofmt against the Go code blocks in README.md
# This will modify the README.md file in place
$ doccmd --language=go --command="gofmt -w" README.md

# or type less... and search for files in the docs directory
$ doccmd -l python -c mypy README.md docs/

# Run ruff format against the code blocks in a Markdown file
# Don't "pad" the code blocks with newlines - the formatter wouldn't like that.
# See the documentation about groups for more information.
$ doccmd --language=python --no-pad-file --no-pad-groups --command="ruff format" README.md

# Run j2lint against the sphinx-jinja2 code blocks in a MyST file
$ doccmd --sphinx-jinja2 --no-pad-file --no-pad-groups --command="j2lint" README.md

# Run ruff format against the pycon (Python interactive console) code blocks in README.rst
# doccmd strips the >>> prompts before running the formatter and restores them afterward
$ doccmd --language=pycon --no-pad-file --command="ruff format" README.rst

# Run ruff format against python blocks, auto-detecting which ones are pycon
# (use this if your existing docs label interactive sessions as "python" rather than "pycon")
$ doccmd --language=python --no-pad-file --command="ruff format" README.rst

What does it work on?

  • reStructuredText (.rst)

.. code-block:: shell

   echo "Hello, world!"

  • Markdown (.md)

Note

By default, .md files are treated as MyST files. To treat them as Markdown, set doccmd --myst-extension to "."" and doccmd --markdown-extension to ".md".

```shell
echo "Hello, world!"
```

  • MyST (.md with MyST syntax)

```{code-block} shell
echo "Hello, world!"
```

```{code-cell} shell
echo "Or this code-cell!"
```

  • MDX (.mdx)

Note

.mdx files are treated as MDX by default. Use doccmd --mdx-extension to add more suffixes if needed.

```javascript
console.log("Hello, MDX!")
```

  • Want more? Open an issue!

Formatters and padding

Running linters with doccmd gives you errors and warnings with line numbers that match the documentation file. It does this by adding padding to the code blocks before running the command.

Some tools do not work well with this padding, and you can choose to obscure the line numbers in order to give the tool the original code block’s content without padding, by using the doccmd --no-pad-file and doccmd --no-pad-groups flags. See Using groups with formatters for more information.

For example, to run ruff format against the code blocks in a Markdown file, use the following command:

$ doccmd --language=python --no-pad-file --no-pad-groups --command="ruff format"

pycon code blocks

When doccmd --language is set to pycon, doccmd strips >>> and ... prompts before passing the code to the tool, and restores them afterward, preserving output lines. This allows linters and formatters that expect plain Python source to work on pycon blocks.

The recommended approach is to label interactive Python sessions in your documentation as pycon, keeping them clearly distinct from plain python blocks.

If your existing documentation already uses python as the language for both plain code and interactive sessions, use doccmd --detect-pycon-language (which defaults to python) together with --language=python. doccmd will automatically detect which python blocks are interactive (by checking whether the first non-empty line starts with >>>), and apply pycon stripping only to those. Plain python blocks are processed without stripping.

File names and linter ignores

doccmd creates temporary files for each code block in the documentation file. These files are created in the same directory as the documentation file.

By default, files are named using the pattern {prefix}_{source}_l{line}__{unique}_{suffix}, where:

  • {prefix} is set via doccmd --temporary-file-name-prefix (default doccmd)

  • {source} is the sanitized source filename (dots and dashes replaced with underscores)

  • {line} is the line number of the code block

  • {unique} is a short unique identifier

  • {suffix} is the file extension (inferred from the language, or set via doccmd --temporary-file-extension)

For example, a Python code block on line 99 of README.rst would create a file named doccmd_README_rst_l99__a1b2_.py.

You can customize the file name format using the doccmd --temporary-file-name-template option. This is useful for creating simpler patterns for linter per-file-ignores.

For example, to create simpler file names like doccmd_a1b2.py:

doccmd --temporary-file-name-template="{prefix}_{unique}{suffix}" ...

You can use this information to ignore files in your linter configuration.

For example, to ignore a rule in all files created by doccmd in a ruff configuration in pyproject.toml:

[tool.ruff]

lint.per-file-ignores."*doccmd_*.py" = [
   # Allow hardcoded secrets in documentation.
   "S105",
]

To ignore a rule in files created by doccmd when using pylint, use pylint-per-file-ignores, and a configuration like the following (if using pyproject.toml):

[tool.pylint.'MESSAGES CONTROL']

per-file-ignores = [
   "*doccmd_*.py:invalid-name",
]

Running commands in parallel

When doccmd is not writing formatter output back into your documentation files (i.e. you are using --no-write-to-file), you can speed things up by parallelizing both within a document and across documents.

Set either option to 0 to auto-detect a worker count based on the number of CPUs on your machine.

For example, doccmd --no-write-to-file --example-workers 4 --document-workers 2 spreads work across two documents, with up to four blocks active per document. This is handy for CPU-bound linters that only emit diagnostics.

Parallel execution is intentionally disabled whenever doccmd --write-to-file is in effect, since doccmd cannot safely merge formatter changes into the original documents out of order. Command output might interleave between example workers and document workers, so stick to the default sequential mode when deterministic stdout / stderr ordering is important.

Reference