can commands¶

the can tool is built from separate commands. The can binary itself should be a thin wrapper which runs another binary in the form can-<command name>. For example, if I run can new, the can binary should search for can-new and run it. This is similar to how the git command works.

This is beneficial for multiple reasons. Development on commands can stay focused and only include what is strictly necessary for that command, while vital shared libraries can still be used across multiple can still be used across multiple commands. Development is also extremely flexible. New commands can experiment and persue different tooling or even different languages without needing older commands to be changed at the same time. And, again similar to git, third parties can supply new commands easily without needing the blessing of the original creator or needing to dive into the deep nitty gritty, even building tooling on the other commands available to end users using the 'plumbing/porcelain' model.

The commands shown here are all commands, including internal commands. Those closer to the top are more likely to be used by the end-user.

command description
can-status report the current state of the writing folder