Show the Az segment when using either "az login" an "Connect-AzAccount"

[Ewerton]

Tried to create an issue but the "Save Issue" is always disabled for me, so, here are a discussion...

Description

The AZ segment works fine and show the correct powerline when I log using the Azure CLI and the az login command.
It does NOT work when I log into Azure using the powershell module and the Connect-AzAccount command.

Environment

• Oh my Posh version: 3.116.2
• Theme: custom (created based in the agnoster theme and with the "az" segment added)
• Operating System: Win10 (version 2004)
• Shell: PowerShell 7.1.3
• Terminal: Windows Terminal (1.7.572.0 Preview)

Steps to Reproduce

1. Follow the instructions to install the Az Module for powershell
2. Type Connect-AzAccount to interactively connect to Azure.
3. Check that the powerline isn't showing the Subscription and Guid

Expected behavior: Show the powerline just like when I log using az login

Actual behavior: Powerline does not show informations about Azure Subscription and Guid

Further Investigations

I'am not a Go developer, but looking at the az segment code, right in the line 39 here in github it seems to me that the segment will be shown if the "az" text is present in the console, am I right? if so, it should be easy to add a condition to check if the "az" or "Connect-AzAccount" is present in the console to make it work

[JanDeDobbeleer]

It's not checking for the az text but that the az command is available. We can't query for the availability of Powershell cmdlets, nor execute these from go. Does it set an environment variable or something else after you run that command?

[tradiff]

There is another option that is more flexible for future scenarios, but puts a bit more burden on the user. We could change the Prompt function in the PowerShell init script to look for the presence of a $global:PreOmp script block. If found, execute it before executing OMP.

That would allow the user to do something like this, coupled with an OMP envvar segment:

$global:PreOmp = {
    $env:AZ_SUBSCRIPTION_NAME = Get-AzContext | Select-Object -ExpandProperty "Subscription" | Select-Object -ExpandProperty "Name"
}

Edit: to answer your question, yes Get-AzContext is fast. Seems to be pulling from memory.

[JanDeDobbeleer]

@travistx we already have Set-PoshContext for that no?

[tradiff]

Oh neat. I didn't realize that was a thing. So @Ewerton you could add this to your PowerShell profile (tested on my end):

function Set-EnvVar {
    $env:AZ_SUBSCRIPTION_NAME = Get-AzContext | Select-Object -ExpandProperty "Subscription" | Select-Object -ExpandProperty "Name"
}

New-Alias -Name 'Set-PoshContext' -Value 'Set-EnvVar' -Scope Global

Along with an envvar segment in OMP.

@JanDeDobbeleer you still think we should call Get-AzContext from the PowerShell init script? IMO this feels like a pretty niche feature for something that global.

[JanDeDobbeleer]

I wouldn't add it. Do we want to look for an env var in the AZ segment which people can then populate using this functionality?

[Ewerton]

@travistx I tested as you requested, here are what I done:

• Added the ENVVAR segment to my oh-my-posh-custom.omp.json

• Changed my profile, before everything I put the following:
  function Set-EnvVar { $env:AZ_SUBSCRIPTION_NAME = Get-AzContext | Select-Object -ExpandProperty "Subscription" | Select-Object -ExpandProperty "Name" }

  New-Alias -Name 'Set-PoshContext' -Value 'Set-EnvVar' -Scope Global -Force
  I just added the -Force param to the New-Alias to prevent errors when I reload my profile using . $profile

• Logged to my Azure using Connect-AzAccount and the ENVVAR segment shows the correct subscription name

• Changed the Subscription using Select-AzSubscription -Subscription "MySubscription" -Scope Process and the ENVVAR segment shows the correct subscription name

• Changed the Subscription using Select-AzContext 'MySubscription (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX) - YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY - email@email.com' -Scope Process and the ENVVAR segment shows the correct subscription name

• Disconnected from my account using Disconnect-AzAccount and the ENVVAR segment doesn't shows anymore.

So, for me, everything is working fine.

[tradiff]

Sorry for the wait, I had some stuff come up. I've submitted #587 for review, which will close this issue. @Ewerton once this PR gets completed, you will be able to use the az segment instead of the envvar segment. It won't have any big difference for you, other than being "more official" 😁

[Ewerton]

Thank you man! As soon the new feature be approve I will upgrade and test it.

[Ewerton]

Hey Friends, I've just update to 3.129.0 and did some tests:
Using the Azure CLI

• az-login - OK
• az account -set --subscription <my_subscription> - OK
• az logout - OK

Using the Powershell cmdlets for Azure

• Connect-AzAccount - OK
• Select-AzSubscription -Subscription <my_subscription> - OK
• Disconnect-AzAccount - NOT OK The powerline stills showing my last selected subscription for subsequent commands

Additional Info
My Az Segment is configured as follows:

{
    "type": "az",
    "style": "powerline",
    "powerline_symbol": "\uE0B0",
    "foreground": "#000000",
    "background": "#9ec3f0",
    "properties": {
	"display_id": false,
	"display_name": true,
	"info_separator": " @ ",
	"prefix": " \uFD03 " 
     }
}

Dont know if this can cause any problems but note that I opt to not show the subscription ID (display_id = false) and I put spaces between the "prefix" icon.

[tradiff]

I noticed this edge case too. It's because it's setting an environment variable, and that environment variable still exists. It should eventually clear out (maybe on restarting powershell, if not, then definitely on restarting your computer). It didn't seem worth the extra cycles to clear it, since it's code that runs for every powershell user (regardless of whether they use or have ever used the az powershell module)

[Ewerton]

Yep, I can confirm. The env vars still there after a Disconnect-AzAccount (Get-ChildItem Env:*AZ_*)
I think that if the powerline keeps showing those information after the users logout, the users can think they still connected to Azure when, in fact, they aren't.

[tradiff]

Right. It's an edge case. The fix is a trade-off I didn't find to be worth it, since the the risk is negligible. (You think you're connected to Azure, but you aren't, any Azure commands will just fail).

I can add it if Jan disagrees on the tradeoff. The change would be to change the PowerShell init script to clear those environment variables if they're set and we're not connected to Azure. It's just that it's code running for every PowerShell user, so that's why I opted not to do it.

[JanDeDobbeleer]

@travistx that would be in the catch statement or else, right? Works for me, not a heavyweight thing to do.