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.
| 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
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
being the default the other starts from. cwp knows which file each key lives in,
and an unknown key is refused with the near misses rather than written 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`?
Keys cwp maintains for itself — version, environments, projects,
capabilities — are refused with 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.
content.… is refused 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.