Remove "Getting OAuth token...\nOK" from cf oauth-token command

[youngm]

The oauth-token command is awesome. However, I cannot use it for inline command executions because it outputs some non token content which means I cannot use it inline with something like curl:

curl -H "Authorization: $(cf oauth-token)" https://api.cf.com/v2/apps

I'd be happy to submit a PR that either removes the "OK" output or add a parameter that when specified removes the "OK" output. Which would you prefer?

Mike

[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/113018007.

[dkoper]

Hi @youngm,

I assume you're aware of cf curl to make this particular example easy.
Is the issue just the OK, not also Getting OAuth token... and the newline?
Would tail address this?

curl -H "Authorization: $(cf oauth-token | tail -n -1)" https://api.cf.com/v2/apps 

I'm concerned what a mess we'd get if we singled out certain commands and limit their output, or add a flag, and addressing this for all commands with a global flag would take a long time to design and implement.

On the other hand, thinking of the purpose of this command, and comparing it with cf ssh-code's output, looks like we should only output the bearer line.

Regards,
Dies Koper
CF CLI PM

[youngm]

@dkoper Yes, I"m aware of cf curl I'm wanting to grab the bearer token for other purposes and just chose curl as an example.

Yes both lines are a problem.

Yes, tail will work but since this will go into scripts that my users will be making I think it would be simpler and better for them if the scripts included as little odd hacks like that as possible. I think it would be best if I could run the command and know that I will always only get the bearer like cf ssh-code and like cf app someapp --guid which I also use in these scripts.

I see your concern about having some commands seemingly randomly output preludes like that and some commands not. However, I think this can be rationalized with a general rule. Something to the effect that if a command outputs data that is not really human readable/consumable the command should not include status output that is human consumable/readable.

What do you think? Perhaps we missed our chance to do things right with oauth-token?

[dkoper]

I like the rule. Please let me know if you find any similar cases with other commands.

cf oauth-token | tail -n -1 should still work after we cull the output, so the impact on existing users should be minimal.
I have prioritised the issue, the team will get to it soon and it should get included in the upcoming release.

Thanks!
Dies Koper
CF CLI PM

[youngm]

@dkoper Thanks. If I get to it first I'll submit a PR.

[dkoper]

We got to it first, check it out in our edge binaries.

[youngm]

Works great! Thanks @dkoper

[dkoper]

FYI, this has been included in cf CLI v6.16.0.
https://github.com/cloudfoundry/cli#downloads

Regards,
Dies Koper
CF CLI PM