az cli az tag works in VSC powershell, fails in VSC bash

[jccasinger]

Issue Type: Bug

Hello,

The Azure cli tag (az tag) command does not work for me in Windows 10 Visual Studio Code's (VSC) bash shell. I think Git bash and just "bash" in VSC are the same, but I tried in both, just in case - both fail. The exact same commands as shown below work in VSC's Powershell and in the Azure Portal's CloudShell bash. Also all the other az commands I could try work in the VSC bash (az account set/list, az vm list, show, list-ip-addresses, az network vnet show, az disk list, az lock, az resource list).

But az tag create and az tag list fail:

laptop$  az tag create  --resource-id=$resid --tags key1=value1 key2=value2      
?[91m(MissingSubscription) The request did not have a subscription or a valid tenant level resource provider.?[0m

Also tried "az tag list" and "az tag create" with: --subscription $sub, same error message.

List fails too:
laptop$ az tag list --resource-id $resid
?[91m(MissingSubscription) The request did not have a subscription or a valid tenant level resource provider.?[0m

I've manually set the subscription, re-checked the sub and resid, I've used hardcoded values instead of variables, I know the resid and sub values are correct because they work in VSC PowerShell and in Azure CloudShell's bash.

Azure-cli version in VSC (bash and powershell) is 2.26.0, in Azure Portal's CloudShell bash az version is 2.25.0.

I am stumped. All other az commands I could think of work in VSC bash. And az tag works in VSC's powershell, which I thought would be using the same backend az cli.

Any thoughts or suggestions?

Thanks,

Extension version: 0.5.0
VS Code version: Code 1.58.0 (2d23c42a936db1c7b3b06f918cde29561cc47cd6, 2021-07-08T06:54:55.083Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	15.88GB (4.19GB free)
Process Argv	--crash-reporter-id 12e35b22-4a6b-4100-a29c-4d710304a37c
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspyt653:30270858
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255cf:30335482
vscod805cf:30301675
pythonvspyt200cf:30331938
vscextlangct:30333562
binariesv615:30325510
vsccppwtct:30329789
bridge0708:30335490

[jccasinger]

I found the solution. Running az tag with --debug showed the $PATH variable was being prepended to the resource ID. Searching for "azure vsc path appearing in az cli resource-id" turned up the following:

  https://github.com/Azure/azure-cli/issues/14299       "azure cli commands automatically appends git-bash path in the parameter that contains forward slash"

...which in turn pointed me to:

  https://github.com/fengzhou-msft/azure-cli/blob/ea149713de505fa0f8ae6bfa5d998e12fc8ff509/doc/use_cli_with_git_bash.md  -  "Use Azure CLI with Git Bash"

This identified the problem as a known issue and explained how to remediate/mitigate. Here is the pertinent excerpt:

"Auto-translation of Resource IDs
On Git Bash, if you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in. This causes an issue for passing ARM Resource IDs, like:

To disable the path conversion. You can set enviroment variable MSYS_NO_PATHCONV=1 or set it temporarily when a running command:"

MSYS_NO_PATHCONV=1 az vm show --ids "/subscriptions/00.../resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-vm"

I tried prepending and it worked, as does putting export MSYS_NO_PATHCONV=1 in your script.

So it wasn't an Az CLI issue at all, but a Git Bash issue.

Adam

[chrmarti]

Thanks, closing as resolved.