Skip to content
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

Escaped backslashes on Windows #1718

Closed
lud0v1c opened this issue Jun 6, 2022 · 1 comment
Closed

Escaped backslashes on Windows #1718

lud0v1c opened this issue Jun 6, 2022 · 1 comment
Labels
area/docs-generation Generation of docs via Cobra kind/bug A bug in cobra; unintended behavior

Comments

@lud0v1c
Copy link

lud0v1c commented Jun 6, 2022

Hey all.
One of my command flags is a string that represents a path, set either in an environment variable or passed using that flag. When in a Linux environment, printing the command usage will show this environment variable in the correct path format:

Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable (default "/tmp/pack-root")

However, declaring this environment variable in Windows and printing the generic usage for this command will show the path in escaped backslashes:

PS Z:\build> $env:CMSIS_PACK_ROOT="Z:\\tmp"
...
Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable (default "Z:\\\\tmp")

The code responsible:

defaultPackRoot := os.Getenv("CMSIS_PACK_ROOT")
rootCmd.PersistentFlags().StringP("pack-root", "R", defaultPackRoot, "Specifies pack root folder. Defaults to CMSIS_PACK_ROOT environment variable")

I've tried things like strings.Replace(path, string(filepath.Separator), "/", -1) or even regex to replace the backslash but the backslashes always get printed twice (I'm guessing they are getting escaped). Tried cmd.exe, Powershell, git-bash and the behaviour is the same.

@johnSchnake johnSchnake added kind/bug A bug in cobra; unintended behavior area/docs-generation Generation of docs via Cobra labels Jun 10, 2022
@johnSchnake
Copy link
Collaborator

The code is specifically branching based on the flag.Value.Type() which in this case is string since you called StringP. If you want it to use the other path (which will use %s and not %q then you could force that by making your own flag type that describes its type as something different.

I had another issue refer to this same issue and I made a PR here: spf13/pflag#347 I don't think that it is going to be picked up as-is (see comment/thread linked below).

Refer to the issue in the pflag repo; but there is an in-depth reply here: spf13/pflag#346 (comment) that you can read/comment on as well.

Closing in preference of continuing the conversation in that thread instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docs-generation Generation of docs via Cobra kind/bug A bug in cobra; unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants