Noir::CLI::ConfigCommand
noir config <show|edit|init|path>
Managed resource: the user-level YAML configuration file.
Constants
Class methods
home: true for the same reason Noir::Home.path uses it: a leading
~ only gets expanded by an interactive shell, and --config-file
values routinely arrive from places that never do — the = form
(--config-file=~/x.yaml) is not tilde-expanded by most shells, and
Docker/systemd/CI wrappers don't expand at all. Without it the path
resolved to a literal ~ directory under the cwd.
Pure helper — given a config file's body, returns the v0 keys
present in it as {old_key => v1_key}. Pulled out so the
detection rule can be exercised without going through STDERR.
Runs editor on path; returns nil on success or the one-line error to
die with. Split out of edit (which needs a TTY) so specs can reach it.
The editor string is split into argv WITHOUT a shell so a poisoned
$EDITOR/$VISUAL can't inject commands: EDITOR="rm -rf /; vi" used to
run under shell: true and execute rm -rf /. Parsing to argv means
metacharacters (;, |, $()) are passed literally, never evaluated,
while still supporting editors carrying flags (e.g. code --wait).
Resolution order: $VISUAL, $EDITOR, then a platform default.
Empty/whitespace values are treated as unset so a stray empty
EDITOR= doesn't trap edit into running an empty command.
Public for unit-test reach.
Emit a stderr hint when v0 deliver/probe keys are present in the
config file. The keys keep working (the migration runs at scan
time), but a user running noir config show to verify their
settings would otherwise see the raw v0 names and wonder why the
v1 documentation doesn't match what's on disk.