New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default strings in help shouldn't be Go escaped #346
Comments
When creating the help text for a flag, the default value shouldn't be be excaped. It isn't clear to an end user that we would be escaping those values. Instead we should be printing the actual value and letting the users decide when/how to add escaping based on how they're utilzing it. Fixes spf13#346 Signed-off-by: John Schnake <jschnake@vmware.com>
This behavior comes from Go's standard flag package. I imagine it looks bad for people with path names as default values on Windows or with default values of some flag providing regexp functionality: Playground demo The duplicate backslashes and escaped quote marks will not happen with a custom Value type whose Or you can use an empty string as the default value so pflag will not print a default value. That way, you can add the "(default ...)" string to your usage message manually and check whether the flag value was changed to determine if a user passed an empty string as the argument or if you got the default value, and there is no need to strip quotes; you simply set the default value yourself after flag parsing has completed if a user did not already set the flag value.
One solution that would not break compatibility with goflag and is not terribly intrusive is introducing something like a |
Add my vote for this. Getting complaints that the default values print out with doubled backslashes in our tool that uses pflag. |
From spf13/cobra#1396:
Just spent another minute looking at this and that I think it is caused from the pflag library here
pflag/flag.go
Line 733 in 85dd5c8
The %q is what causes it to be a go-escaped string rather than just using
"%v"
; go fmt package states that %q for strings as:So I think we need to put a PR up for that. I'll create an issue there to track it.
Originally posted by @johnSchnake in spf13/cobra#1396 (comment)
The text was updated successfully, but these errors were encountered: