gow -g expects script arguments when they are not required

[mike-lerch]

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:

% cat script.sh
#!/bin/bash
echo "hello world"

% gow -g ./script.sh
"gow" is the missing watch mode for the "go" command.
Runs an arbitrary "go" subcommand, watches files, and restarts on changes.

Usage:

    gow <gow_flags> <cmd> <cmd_flags> <cmd_args ...>
...

% gow -g ./script.sh ""
hello world

[mitranim]

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.