Open mike-lerch opened 8 months ago
This happens when the user passes only gow
flags, without subsequent arguments and flags for the underlying executable such as go
(in other words, without a subcommand for the subprocess). This isn't specific to -g
. This behavior assumes that the subprocess always requires a subcommand, and the motivation is to help the user learn the tool.
We do also have gow -h
and gow help
, as well as the repository readme. This could be changed to print help only if the user provided no CLI arguments, but I think it's logically inconsistent. It might be more logical to drop this behavior, so that simply running gow
runs the subprocess with default gow
settings and no CLI arguments.
The one thing that stops me is: the parsing of CLI arguments depends on the assumption that the subcommand is required. All flags before the first non-flag are taken for gow
. Everything starting at the first non-flag (the subcommand) is passed to the subprocess. If we no longer assume a subcommand, then separating gow
flags from subprocess flags requires a different approach, which could also leak into the normal usage. I could add support for --
but it's not a one-liner and complicates the interface. Thoughts are welcome.
gow -g
is requiring that a command argument be passed, even if the script being called does not need them. Passing an empty argument seems to work around this, but it is not intuitive.Example: