#1105 introduced a bug spotted in https://sourcegraph.slack.com/archives/C05MW2TMYAV/p1728932051783959 where commands that can take no arguments wouldn't run:

❯ src login
'src login' helps you authenticate 'src' to access a Sourcegraph instance with your user credentials.

Usage:

    src login SOURCEGRAPH_URL

This was caused by if len(args) == 0 which captured commands that didn't take arguments like login.

Reading through the original PR and discussion, I agree with this logic for choosing when to output to stdout/err.

There was another minor bug in the old code that I've fixed - cmd.flagSet.Parse() will print help to stderr and exit if passed a command that doesn't take subcommands and the --help flag, such as src version --help. This previously ran before the --help detection, so depending on the command some help output would still be written to stderr.

Quick test cases

These make sense to me, following the logic suggested above - use stdout if help was requested, use stderr if help was triggered due to an invalid set of arguments.

src goes to stdout
src help goes to stdout (requesting help)
src --help goes to stderr (it's not a supported flag)

src version goes to stdout (correct usage of a zero-arg command)
src version --help goes to stdout (requesting help)

src sbom goes to stderr (missing args)
src sbom --help should go to stdout (requesting help)
src sbom foobar goes to stderr (invalid subcommand)
src sbom fetch goes to stderr (missing args)
src sbom fetch --help goes to stdout (requesting help)

This is a helpful little wrapper that will print stdout/stderr in front of each line:

(go run ./cmd/src version --help 2>&1 1>&3 | sed 's/^/stderr: /' >&2) 3>&1 | sed 's/^/stdout: /

Test plan

• Manual testing
• CI