cmd
| plugin-cmd — Served by | plugin-cmd |
| plugin-cmd — Placement | compiled-in (in-process) |
| plugin-cmd — Version | 2026.209.0000 |
| plugin-cmd — Served by | plugin-cmd |
| plugin-cmd — Placement | compiled-in (in-process) |
| plugin-cmd — Version | 2026.209.0000 |
cmd is a command word served by 2 plugin candies — plugin-cmd and plugin-cmd — at different points in the command tree. Both are real invocations; charly --help prints which is which.
About plugin-cmd, which serves it
Section titled “About plugin-cmd, which serves it”COMPILED-IN charly COMMAND-class plugin owning the externalized charly cmd command
(#118 loader+check-tail cone) — run a single command in a running container with an
optional desktop notification on completion.
The plugin owns the command end to end: the kong grammar (CmdCmd), the container resolve
(deploykit.ResolveContainer / ResolveSidecarContainer), and –notify (the venue’s gdbus
session-bus call, driven directly on the deploykit.ContainerChain executor — a plugin
drives gdbus itself, the boundary law’s host-object-is-never-permanence rule). The ONE
thing it cannot do is the interactive exec, which is deploy-lifecycle machinery
(dispatchLifecycleTarget → OpAttach): it dispatches the op=“cmd” pod-lifecycle
action over the reverse channel with INHERITED stdio, so the -i interactive
stream reaches the operator. The former hidden charly __cmd core reentry is
DELETED (K-wave 2) — the op=“cmd” dispatch is plugin-side, so no charly-core symbol
crosses the boundary; the plugin imports the sdk module alone.
cmd is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to drive HostBuild(“cli”). The out-of-process CliMain path has no reverse channel, so it errors. command:cmd is a FLAT command (Box + Command positionals), so NewMeta declares no Subcommands and ships no plugin_input.
About plugin-cmd, which serves it
Section titled “About plugin-cmd, which serves it”COMPILED-IN charly COMMAND-class plugin owning the externalized charly cmd command
(#118 loader+check-tail cone) — run a single command in a running container with an
optional desktop notification on completion.
The plugin owns the command end to end: the kong grammar (CmdCmd), the container resolve
(deploykit.ResolveContainer / ResolveSidecarContainer), and –notify (the venue’s gdbus
session-bus call, driven directly on the deploykit.ContainerChain executor — a plugin
drives gdbus itself, the boundary law’s host-object-is-never-permanence rule). The ONE
thing it cannot do is the interactive exec, which is deploy-lifecycle machinery
(dispatchLifecycleTarget → OpAttach): it dispatches the op=“cmd” pod-lifecycle
action over the reverse channel with INHERITED stdio, so the -i interactive
stream reaches the operator. The former hidden charly __cmd core reentry is
DELETED (K-wave 2) — the op=“cmd” dispatch is plugin-side, so no charly-core symbol
crosses the boundary; the plugin imports the sdk module alone.
cmd is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand — to drive HostBuild(“cli”). The out-of-process CliMain path has no reverse channel, so it errors. command:cmd is a FLAT command (Box + Command positionals), so NewMeta declares no Subcommands and ships no plugin_input.
charly --help prints the command tree, including where each cmd is invoked and under which parent.