cwp config
shipped 1.0.0cwp config [flags]
cwp config groups the commands below and takes no action of its own; run it alone and it prints its help.
| Flag | What it does | Default |
|---|---|---|
--with-agent | with —dry-run on a host with no shell: install and remove the PHP agent so the plan is real | off |
| Subcommand | What it does |
|---|---|
cwp config get | Print one key’s effective value, or list every key |
cwp config set | Set one key, in whichever layer it belongs to |
What it does
cwp config reads and writes both configuration layers without opening
either file.
The layer is not a guess. pull.uploads is project config and
defaults.uploads is machine config. They spell the same idea deliberately:
one is the default the other starts from. cwp knows which file each key lives
in. It refuses an unknown key and names the near misses rather than writing
it to whichever file happened to be open:
✗ unknown config key "uploads"
→ run `cwp config get` to list every key — did you mean `pull.uploads` or `defaults.uploads`?
cwp refuses the keys it maintains for itself, version, environments,
projects and capabilities, and names the command to use instead.
Values. Booleans take true/yes/on/1 or false/no/off/0 and nothing
else. A pull.scrub that quietly read the string "false" as truthy would
leave production data on your laptop. Lists are comma-separated, and an empty
value means the empty list.
Example
cwp config get # every key, its value and where it came from
cwp config get pull.uploads # one value, on stdout
cwp config set pull.uploads sync # project — cwp.yml
cwp config set defaults.uploads sync # machine — ~/.config/cwp/config.yml
What it does not do
It creates no environments, deletes no keys and contacts nothing.
It refuses content.… and points at the file. The content groups are a map
whose keys are yours, and a dotted-path setter has no way to tell a group name
from a typo.