Windows cli gives error about secret name

[wayofthepie]

What version of the credhub server you are using?
2.4.0

What version of the credhub cli you are using?
2.4.0

If you were attempting to accomplish a task, what was it you were attempting to do?
Creating a secret.

What did you expect to happen?
The secret to get created.

What was the actual behavior?
The cli errors out as follows:

> .\credhub.exe set /n '/concourse/team/test' /type value /v test
Credential names may only include alpha, numeric, hyphen, underscore, and forward-slash characters. Please update and retry your request.

Note that this works fine on linux:

$ credhub set -n /concourse/team/test -t value -v test
id: e95eca10-05f6-4e5e-bc05-fc9e72c6e67c
name: /concourse/team/test
type: value
value: <redacted>
version_created_at: "2020-01-24T20:43:36Z"

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

If you are a PCF customer with an Operation Manager (PCF Ops Manager) please direct your questions to support (https://support.pivotal.io/)

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/170906330

The labels on this github issue will be updated when the story is started.

[ankeesler]

@wayofthepie as you may already know, this annoyance is due to Windows flag conventions. The CredHub CLI respects both -- and /-prepended flags on Windows because command line flags commonly start with / as a convention from DOS time. Because of this, when the CredHub CLI sees any argument starting with /, it thinks of it as a flag. Thus, you get the error message that you reported.

There are 3 ways we could have fixed this.

1. Only accept --prepended flags.
2. Add a help message to tell people to not prepend their credential paths with / on Windows.
3. Make a PR into the flag parsing library (github.com/jessevdk/go-flags) that we use to update this behavior.

#1 would have been a breaking change. #3 would have potentially been a breaking change, or at best a cumbersome PR into a very popular library. Thus, we elected to go with #2. The expected behavior is now that when you run the command you provided above on Windows, you should see an error message that should tell you what to do (i.e., remove the leading slash from your credential path).

Please let us know if this is not sufficient.