The system primarily is there to execute a type of command somewhere in the hierarchy of a CLI tools sub commands.
Lets say we have an app called
demo that has commands
demo say and
demo think the
think bits are commands. In this example these are commands of type
exec - they run a shell command.
If we had a command
demo deploy status and
demo deploy upgrade then generally the
deploy would not perform any action, it’s there mainly to achor sub commands and show help information. Here the
deploy command would be of type
Generally I would suggest nested commands are structured as
root -> parent -> parent -> exec and never
root -> parent -> exec -> exec. If you do decide to do that I strongly suggest the first exec is a read only action like showing some status. User should feel safe to execute parents without unintended side effects.
Flags and Arguments
Often we need to pass some parameters to commands, for example if we have one to upgrade some software it might be
demo upgrade 1.2.3. Here the
1.2.3 is an argument, you can have a number of arguments and they can be set to be required or optional. If you have multiple arguments an optional one can not be before a required one.
Flags are generally kept for optional items like
demo upgrade 1.2.3 --channel=nightly, here we pass a flag
--channel. At present we only support flags with string values. We intend to support enums of valid values and boolean flags.