az <resource> show has inconsistent exit status

Following template scripts generated from the Portal’s Automation Script section, the CLI script uses checks for existing resources such as

az group show $resourceGroupName 1> /dev/null

if [ $? != 0 ]; then
	echo "Resource group with name" $resourceGroupName "could not be found. Creating new resource group.."
	set -e
	(
		set -x
		az group create --name $resourceGroupName --location $resourceGroupLocation 1> /dev/null
	)
	else
	echo "Using existing resource group..."
fi

az group show and az storage account show both return non-zero when the resource is missing and so the above pattern works. If being consistent across resources throughout my scripts, examples such as az storage share show and az vm show return zero regardless of the resource existing or not. Thus cannot be used to determine missing resources.

The issue is that the ‘show’ action doesn’t always return a non-zero code for missing resources when used on other resource types. For consistency and approachability to new commands, I would thing these would behave the same across resources?

Environment summary

az --version 2.0.21 Python (Darwin) 3.6.3 Installed via homebrew

[colemickens]

@williexu Thank you for cross-linking. I’m also quite happy with the decision. Cheers!

[yugangw-msft]

I read this and associated #6298, in short, 2 assumptions were involved leading to this change:

1. show is supposed to be used as the existence check before create.
2. all services could have consistencies on PUT, say, no error, fast, and support create if not exists, etc.

Both assumptions didn’t end up well. The first one is not always true as existence check can be used for other purposes. The second one has never happened. Also some commands fell through the crack that still throw. Lining up this inconsistency with the unconventional behavior thus causes the confusion on end users. In hindsight, we should not have done this change, or at least wait till the 2 assumptions got confirmed.

For how to address this issue, because the change has already been made and we have way more commands with this new behavior which makes the revert not a feasible option. So, let us just fix the rest commands to at least have the consistency. It sucks though to have to tweak such popular commands like az storage account show in a breaking change manner.