ONE definition of "a strictly ordered batch of commands", shared by the two
tools that run one: shell and git.
Both tools had grown their own copy of the same four ideas — the commands
input property, the ordered-collection check, the serial reduce that keeps a
failed command's slot, and the expandable result card that numbers each
command — with the copies drifting apart in name (cmd vs commands), in
shape and in wording. They are defined here exactly once:
commands-property — the commands JSON-Schema property; the ITEM shape
stays with the tool (a shell line is a string, a git command is argv).ordered — the caller's value as a vector: a bare string is coerced into
the batch of one it means, while a non-collection, an empty batch and
(deliberately) a SET are refused — an unordered collection cannot
describe a strictly ordered batch.run-serial — run in input order, every result at its input position.result — the {"commands" [...]} key both tools answer with: git
returns it alone, shell merges it onto its own total result shape.card — one expandable op-card, ### n. <summary> per command.The wire key is commands for BOTH tools, so a batch reads the same whether
it ran through bash or through git.
ONE definition of "a strictly ordered batch of commands", shared by the two
tools that run one: `shell` and `git`.
Both tools had grown their own copy of the same four ideas — the `commands`
input property, the ordered-collection check, the serial reduce that keeps a
failed command's slot, and the expandable result card that numbers each
command — with the copies drifting apart in name (`cmd` vs `commands`), in
shape and in wording. They are defined here exactly once:
- [[commands-property]] — the `commands` JSON-Schema property; the ITEM shape
stays with the tool (a shell line is a string, a git command is argv).
- [[ordered]] — the caller's value as a vector: a bare string is coerced into
the batch of one it means, while a non-collection, an empty batch and
(deliberately) a SET are refused — an unordered collection cannot
describe a strictly ordered batch.
- [[run-serial]] — run in input order, every result at its input position.
- [[result]] — the `{"commands" [...]}` key both tools answer with: `git`
returns it alone, `shell` merges it onto its own total result shape.
- [[card]] — one expandable op-card, `### n. <summary>` per command.
The wire key is `commands` for BOTH tools, so a batch reads the same whether
it ran through bash or through git.(batch? r)Did r actually run commands — does it carry entries? Emptiness, not absence,
is the test: both tools carry commands on EVERY result, so a stage that ran
no command of its own (a shell lifecycle op) leaves it empty instead of
answering with a second envelope.
Did `r` actually run commands — does it carry entries? Emptiness, not absence, is the test: both tools carry `commands` on EVERY result, so a stage that ran no command of its own (a shell lifecycle op) leaves it empty instead of answering with a second envelope.
(card {:keys [icon noun results render-one tally-fn]})One expandable op-card for a serial batch: each command rendered by
render-one into {:summary :body}, numbered and divided, under a headline
of icon, the command count, noun, and the outcome from tally-fn
(default tally).
One expandable op-card for a serial batch: each command rendered by
`render-one` into `{:summary :body}`, numbered and divided, under a headline
of `icon`, the command count, `noun`, and the outcome from `tally-fn`
(default [[tally]]).The ONE wire key for an ordered batch — input property AND result key.
The ONE wire key for an ordered batch — input property AND result key.
(commands-property {:keys [items description]})The shared commands array property for a tool's JSON Schema. items is the
tool's own item shape and description its own prose; everything structural
(array, non-empty, ordered) is fixed here.
The shared `commands` array property for a tool's JSON Schema. `items` is the tool's own item shape and `description` its own prose; everything structural (array, non-empty, ordered) is fixed here.
(failed? entry)Did one command entry fail — a timeout, or a non-zero exit?
Did one command entry fail — a timeout, or a non-zero exit?
(ordered tool commands)commands as a vector, in input order. A batch is an ARRAY — one command is a
batch of ONE (["ls"]) — but a bare string is COERCED into exactly that
batch of one rather than failing the call: the shape written, read back and
rendered stays the array, while the obvious one-command spelling never costs a
turn. Throws for tool only when there is no ordered batch to be had: an
unordered collection (a set or a map has no input order and must never be
silently sequenced), a value that is neither, or an empty batch.
`commands` as a vector, in input order. A batch is an ARRAY — one command is a batch of ONE (`["ls"]`) — but a bare string is COERCED into exactly that batch of one rather than failing the call: the shape written, read back and rendered stays the array, while the obvious one-command spelling never costs a turn. Throws for `tool` only when there is no ordered batch to be had: an unordered collection (a set or a map has no input order and must never be silently sequenced), a value that is neither, or an empty batch.
(result results)The batch's own key: {"commands" [per-command result …]}, in input order.
git returns exactly this; shell MERGES it onto its one total result shape.
NEITHER tool has a lone-command shape: one command is a batch
of one, so commands is where a command's own output always is.
The batch's own key: `{"commands" [per-command result …]}`, in input order.
`git` returns exactly this; `shell` MERGES it onto its one total result shape.
NEITHER tool has a lone-command shape: one command is a batch
of one, so `commands` is where a command's own output always is.(run-serial commands run-one)(run-serial commands run-one on-error)Run commands strictly in input order — (run-one command) finishes before
the next begins — and return the results in that same order.
With on-error, a thrown command becomes (on-error command throwable) at
its own input position, so one launch failure neither erases the completed
entries nor shifts the later ones. Without it the throw propagates and the
whole call fails. An InterruptedException is turn CANCELLATION, never a
per-command failure: it always propagates so the tool call stops promptly.
Run `commands` strictly in input order — `(run-one command)` finishes before the next begins — and return the results in that same order. With `on-error`, a thrown command becomes `(on-error command throwable)` at its own input position, so one launch failure neither erases the completed entries nor shifts the later ones. Without it the throw propagates and the whole call fails. An InterruptedException is turn CANCELLATION, never a per-command failure: it always propagates so the tool call stops promptly.
(tally results)Default headline tail: S succeeded, F failed.
Default headline tail: `S succeeded, F failed`.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |