Azure-cli: Add unqouted/raw strings to the JMESPath query

[asasine]

Problem
I've been using the --query parameter recently to automatically retrieve access keys and other information for my cache instances. I find it better then using a package like jq or python as it requires less dependencies. I load those into a variable to easily pass to other commands e.g. redis-cli.

adam@adam-dev:~$ key=$(az redis list-keys --resource-group $rg --name $name --query primaryKey)
adam@adam-dev:~$ echo $key
"fakeAcessKey123"
adam@adam-dev:~$ 

Unfortunately, the query parameter prints quoted strings and doesn't have an option for raw strings (no quotes).

Possible solution
JMESPath's CLI supports unquoted output. I'd like to see this supported in the Azure CLI's query parameter.

Alternatives attempted
I've accomplished the same effect using other dependencies to format the JSON like query+sed, however this is tied to unix and is harder to mentally parse.

adam@adam-dev:~$ az redis list-keys --resource-group $rg --name $name --query primaryKey | sed -e 's/^"//' -e 's/"$//'
fakeAccessKey123
adam@adam-dev:~$ 

Also accomplished with Python, a more cross-platform friendly version, but requires the python CLI to be installed.

adam@adam-dev:~$ az redis list-keys --resource-group $rg --name $name | python3 -c "import sys, json; print(json.load(sys.stdin)['primaryKey'])"
fakeAccessKey123
adam@adam-dev:~$ 

I also discovered where outputting as tsv strips the quotes away. This feels unintentional, hacky, and has a potential to change in future versions.

adam@adam-dev:~$ az redis list-keys --resource-group $rg --name $name --query primaryKey --output tsv
fakeAccessKey123
adam@adam-dev:~$ 

Additionally, it does not work with multilevel data such as querying for cache name and sku. The first command doesn't print anything related to sku.

adam@adam-dev:~$ az redis list --query "[].{sku: sku, name: name}" --output tsv
        adam-cache-0
        adam-cache-1
        adam-cache-2
adam@adam-dev:~$ az redis list --query "[].{sku: sku, name: name}"
[
  {
    "name": "adam-cache-0",
    "sku": {
      "capacity": 1,
      "family": "C",
      "name": "Standard"
    }
  },
  {
    "name": "adam-cache-1",
    "sku": {
      "capacity": 2,
      "family": "C",
      "name": "Basic"
    }
  },
  {
    "name": "adam-cache-2",
    "sku": {
      "capacity": 1,
      "family": "P",
      "name": "Premium"
    }
  }
]
adam@adam-dev:~$ 

[tjprescott]

Thanks for the feedback @asasine! We'll consider this for future enhancement. @williexu this might be an interesting one for Tosin to look at.

[williexu]

@adewaleo please take a look

[adewaleo]

I'll look into this. Just to confirm, @asasine you would like:

1. Support for query outputs to be printed as raw strings.
2. A fix of / look into the tsv bug where tsv outputs seem to be dropping data?

[asasine]

1. This is correct. Raw, unquoted string output is my priority. jp (the JMESPath CLI) only supports raw, unquoted string when the output is a string (and not JSON). This seems like a fair constraint as more complex JSON could otherwise become ambiguous without the quotes around strings.
2. Not my priority, just noticed the bug while investigating workaround for raw strings. I presume it drops data when multilevel because TSV can't adequately express arrays that aren't top-level.

[adewaleo]

Answer:
@asasine regarding the main issue you have raised, after speaking to some members of the team, -o tsv supports the functionality you want.

Other comments:
Concerning the other issue / bug you raised, it isn't a bug but a decision made because there isn't a clear way to represent an object as a tsv value. As a result, we do not currently handle including json object values in the resulting tsv file.

So for example if you run:

az group list --query "[].{n:name, l:location}" -o tsv

You will get a list of your resource groups as a tsv file with names in the first column and locations in the second column.

However if you run:

az group list --query "[].{n:name, l:location, p: properties}" -o tsv

Your output will look exactly the same as before. The properties field, which is a json object, will not be included in the tsv output.

The team might eventually update -o tsv to support json object values by simply adding a new column with a flattened version of the object as a value, but for now we will leave it as it is. If you have any thoughts on how to represent json objects as tsv values, feel free to let us know.

I will be closing this issue. I hope this helps. Please let us know if you have any questions or thoughts.