Add a command/flag to get active profile #1663
Comments
|
This is what I've used for scripting some basic interactions with Minishift.
Personally, I like the composability of this. |
|
I like to have an option that consistently works on any OS and that's the fastest possible option. |
|
I had originally placed the active profile on the first line for #1592, followed by a sorted list, as this would be easier to extract with other commands without having to check for active per se. However, this was removed in #1633. Adding a flag to force to only return the active profile, or a new command? I am not sure... Maybe, we can review this again, just let us know. |
|
Opening the issue is the way of letting you know. 😁
El 5 nov. 2017 22:05, "Gerard Braad" <notifications@github.com> escribió:
… I had originally placed the active profile on the first line for #1592
<#1592>, followed by a
sorted list, as this would be easier to extract with other commands without
having to check for active per se. However, this was removed in #1633
<#1633>. Adding a flag to
force to only return the active profile, or a new command? I am not sure...
Maybe, we can review this again, just let us know.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1663 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEyDsfGzDhpbWzwtEkdj1I6DvueHhI7ks5szZZfgaJpZM4QSN4K>
.
|
|
We kind of have a solution... but just wondering how to tackle this in a nicer way, as a new flag sounds like overkill, but also understandable for scripting purpose. |
|
I've already gone the route of "adding flags is Overkill”, but there's
things that are a minimum to make features more usable. Asking users to add
additional scripting to something they will commonly do is not an option
IMHO. It all boils down to hire common is that a user could do this.
I think that PS1 enhancement is something we will see shortly as very
common as otherwise it's a mess not to mess it up when you work with
multiple clusters.
|
|
This is why I suggested to implemented the first line to always contain the
active profile... As there us always one active. The other option possible
would be to have a subcommand for profile...
…--
Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]
|
|
I think adding a flag is the best option. Needing to have to work with sed/awk/grep is awkward. I don't think we new command is needed though. |
|
A flag works great.
|
|
Adding a flag |
|
@jorgemoralespou @minishift/minishift-dev The issue is, to keep consistency with But I do not think @jorgemoralespou looking for that. He just need the active profile name. Any suggestion? Here is how it will look like if we just print the profile name for Does it look fine to you? |
Signed-off-by: Lalatendu Mohanty <lmohanty@redhat.com>
|
this is why I do not think the LIST option is the right place to put this.
It is NOT a list action, but asking for the current ACTIVE profile. A flag
will solve this in the wrong way.
maybe `m status --profilename` can be used, as this will allow to do `m
status --diskspace`, `m status --openshiftstate` and so on.
|
|
Also, thing from script use case where one want to get active profile. but will create a problem. May be is the right place.
|
Then the user should also learn this, as we current have several information given there
This sounds not OK either. profile is just a resource (as subcommand), and there is no verb or action given with |
|
m status --profilename works for me.
I understand @gbraad concerns, and he might be right.
Once we've come with this actions, we should stick for consistency.
|
I would like a command to get current active profile, so I can embed that in PS1 indicating me what's the current minishift profile. It's safer when executing actions.
Example:
My prompt then can be easily expanded to show the profile name, and the context name:
The text was updated successfully, but these errors were encountered: