You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to be able to list and document subcommands from the main ab launch program:
$ ab
Commands
ab run <abx>
ab help [<topic>]
ab wasm [<subcommand>]
ab version
The problem is, ab commands are implemented as executables on the user's path. To find a command, ab will find the exe named ab-<command> in the user's PATH. We could just list every program that starts with "ab-", but this won't work nicely with nested command trees. For example, ab wasm has it's own external subcommand executables (mangled as ab-wasm-<command>), which we don't want to list by default.
One potential strategy: rather than finding subcommands through the user's PATH environment variable, we can group plugins under a directory in libexec. Then, identifying the top-level commands becomes a matter of walking the libexec directory. Subcommands can be grouped using subdirectories.
Help strings and other metadata about each command could be pulled in a corresponding tree under usr/share/ab/, or even just as mangled man pages. Or, we could standardize on a CLI options, such as --help=short, and allow each subcommand to produce it's own script. The method to define help documentation should be simple and obvious, and this is starting to make installing commands a little complicated.
We want to allow commands to be implemented as scripts with shebangs, so we can't standardize on a binary format for plugins--commands should be plain old executables.
The text was updated successfully, but these errors were encountered:
We want to be able to list and document subcommands from the main ab launch program:
The problem is, ab commands are implemented as executables on the user's path. To find a command, ab will find the exe named
ab-<command>
in the user's PATH. We could just list every program that starts with "ab-", but this won't work nicely with nested command trees. For example,ab wasm
has it's own external subcommand executables (mangled asab-wasm-<command>
), which we don't want to list by default.One potential strategy: rather than finding subcommands through the user's PATH environment variable, we can group plugins under a directory in libexec. Then, identifying the top-level commands becomes a matter of walking the libexec directory. Subcommands can be grouped using subdirectories.
Help strings and other metadata about each command could be pulled in a corresponding tree under usr/share/ab/, or even just as mangled man pages. Or, we could standardize on a CLI options, such as --help=short, and allow each subcommand to produce it's own script. The method to define help documentation should be simple and obvious, and this is starting to make installing commands a little complicated.
We want to allow commands to be implemented as scripts with shebangs, so we can't standardize on a binary format for plugins--commands should be plain old executables.
The text was updated successfully, but these errors were encountered: