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
The defaults section of the usage string is currently composed by analyzing the return of the String() function of the corresponding Value object. As a result, the usage string generated when the Value is empty can differ from the one generated after the Value is set.
The following two invocations are going to produce different results.
(--customFlag has no default)
./program --help
./program --customFlag=10 --help
This is a real nuisance for us as we use custom flags extensively.
Whenever a user requests --help for a subcommand or makes a mistake in one of the flags, the usage info that they get ends up having some bogus defaults.
I've already submitted a pull request with a test case that demonstrates the problem. #243
The text was updated successfully, but these errors were encountered:
The defaults section of the usage string is currently composed by analyzing the return of the String() function of the corresponding Value object. As a result, the usage string generated when the Value is empty can differ from the one generated after the Value is set.
The following two invocations are going to produce different results.
(--customFlag has no default)
./program --help
./program --customFlag=10 --help
This is a real nuisance for us as we use custom flags extensively.
Whenever a user requests
--help
for a subcommand or makes a mistake in one of the flags, the usage info that they get ends up having some bogus defaults.I've already submitted a pull request with a test case that demonstrates the problem.
#243
The text was updated successfully, but these errors were encountered: