Inconsistent treatment of JSON based CLI parameters

[sykesm]

Some commands allow the user to specify keys and then be prompted for the values
Some commands allow the user to specify the JSON inline as an argument
Some commands allow the user to specify the JSON by pointing to a file

The treatment of JSON parameters on CLI commands should be consistent across the code base. Ideally we get to the point where all commands support the interactive prompt style, the inline argument style, and the ability to reference a file containing JSON (or YAML).

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/106738722.

[nicw]

@sykesm thanks for the nudge - we're looking into this at a high level. The commands have evolved over the last three years.

If you were to vote for top use case, what is your preferred way to pass parameters?

[sykesm]

I think they all have their purpose. Right now I'm most focused on my current problem of placing PEM encoded certificate chains in the credentials associated with a user provided service. Since cups doesn't support files and prompted values terminate at the first new line, I'm stuck doing some shell magic to generate a JSON map with newline escapes on the command line.

But, in all honesty, I'd just like to see all of the commands that accept user provided JSON to support all of the methods that currently exist. Seems like an excellent opportunity to create a flag type in the custom parser that was recently written for the cli which honors all of those formats.

[goehmen]

Makes sense. rather than choose one, apply all patterns to all.

On Tuesday, October 27, 2015, Matthew Sykes notifications@github.com
wrote:

I think they all have their purpose. Right now I'm most focused on my
current problem of placing PEM encoded certificate chains in the
credentials associated with a user provided service. Since cups doesn't
support files and prompted values terminate at the first new line, I'm
stuck doing some shell magic to generate a JSON map with newline escapes on
the command line.

But, in all honesty, I'd just like to see all of the commands that accept
user provided JSON to support all of the methods that currently exist.
Seems like an excellent opportunity to create a flag type in the custom
parser that was recently written for the cli which honors all of those
formats.

—
Reply to this email directly or view it on GitHub
#650 (comment).

Greg Oehmen
Cloud Foundry Product Manager

[dkoper]

Closing this as feature request accepted. We manage its priority in the tracker (link above) and appreciate a pull request.

[nicw]

@sykesm I'm poring over this now - I'm assuming you're referring to create/update commands, but are there any other commands you're seeing?

[sykesm]

@nicw I was referring to create and update commands. I think my cf-dev note pointed to some of the explicit examples.

[xverges]

This would be specially welcomed for Windows users, since JSON that includes blank spaces breaks cf cups and cf uups, and double quotes need to be escaped.

I can use bypass these to issues using git bash, but then I am not able to have multiple lines joined with \

[dkoper]

Hi Xavier,

Thanks for chiming in!
What would be especially welcomed? Allowing to pass a path to a (JSON) file to cf cups and cf uups, or YAML support?

Cheers,
Dies Koper
CF CLI PM

[xverges]

@dkoper, allowing to pass a path to a JSON file to cf cups and cf uups would be really helpful

[dkoper]

Matthew's email to CF dev mentioned above can be found here: https://lists.cloudfoundry.org/archives/list/cf-dev@lists.cloudfoundry.org/message/BGTASSOBR4GNTS6VEZPQ3DPKRB2CL7Y2/

He called out:

• create-service/update-service
• bind-service
• create-service-keys
• create-security-group/update-security-group

There is also cf curl (#629) and cf set-env (#734).

[dkoper]

Current status (cf CLI v6.15.0):

• create-service/update-service/bind-service/create-service-key: -c myfile.json or -c '{"field":"value"}' <- both already supported
• cups/uups: -p '{"field":"value"}' <- no file support
• create-security-group/update-: file passed in as argument <- no inline
• curl: -d DATA <- no file support
• env: value passed in as argument <- no file support