{Docs} Updated references in documentation, misc fixes (#28594)

* Updated references in documentation

* Updated references in documentation

* Updated references in documentation

* Updated references in documentation

doc/authoring_help.md

@@ -174,7 +174,7 @@ Examples
 
 The help that you author above will be available online as reference documentation.
 
-https://docs.microsoft.com/cli/azure/reference-index
+https://learn.microsoft.com/cli/azure/reference-index
 
 If you are not satisfied with the heading that is automatically provided, please create a PR to update the following file:
 

doc/authoring_tests.md

@@ -10,7 +10,7 @@ For integration tests, we provide the `ScenarioTest` and `LiveScenarioTest` clas
 
 ### About replayable tests
 
-Azure CLI translates user inputs into Azure Python SDK calls which communicate with [Azure REST API](https://docs.microsoft.com/rest/api/). These HTTP communications are captured and recorded so the integration tests can be replayed in an automation environment without making actual HTTP calls. This ensures that the commands actually work against the service when they are recorded (and then can be re-run live to verify) and provides protection against regressions or breaking changes when they are played back.
+Azure CLI translates user inputs into Azure Python SDK calls which communicate with [Azure REST API](https://learn.microsoft.com/rest/api/). These HTTP communications are captured and recorded so the integration tests can be replayed in an automation environment without making actual HTTP calls. This ensures that the commands actually work against the service when they are recorded (and then can be re-run live to verify) and provides protection against regressions or breaking changes when they are played back.
 
 ### Nightly live test run
 

doc/breaking_change_detection_guidelines.md

@@ -2,13 +2,13 @@
 
 ## Overview
 
-Azure cli provides command line tool to help users and developers check cli changes: [command-change](https://github.com/Azure/azure-cli-extensions/blob/main/src/command-change/README.md) 
+Azure CLI provides command line tool to help users and developers check CLI changes: [command-change](https://github.com/Azure/azure-cli-extensions/blob/main/src/command-change/README.md) 
 
 There are two categories of breaking change detection users can check for Azure CLI: [version-diff](https://github.com/Azure/azure-cli-extensions/blob/main/src/command-change/README.md#version-diff) and [meta-diff](https://github.com/Azure/azure-cli-extensions/blob/main/src/command-change/README.md#meta-diff) .
 
 #### Prerequisite
 
-Install cli extension `command-change`
+Install CLI extension `command-change`
 
 ```
 az extension add --name command-change
@@ -16,7 +16,7 @@ az extension add --name command-change
 
 ### version-diff
 
-Users can check the differences between two cli releases, like `2.47.0` and `2.49.0`, by typing following command:
+Users can check the differences between two CLI releases, like `2.47.0` and `2.49.0`, by typing following command:
 ```
 az command-change version-diff --base-version 2.47.0 --diff-version 2.49.0
 ```
@@ -31,7 +31,7 @@ Normally, the pulled list of version diffs is quite long, so a better usage way
 az command-change version-diff --base-version 2.47.0 --diff-version 2.49.0 --target-module monitor --output-type csv --version-diff-file filename-a
 ```
 
-When `version-diff` command runs, it will download the corresponding metadata files of all modules for chosen cli versions and store them in current working directory, one module a file called `az_module_meta.json`, which can be used in the following `meta-diff` command
+When `version-diff` command runs, it will download the corresponding metadata files of all modules for chosen CLI versions and store them in current working directory, one module a file called `az_module_meta.json`, which can be used in the following `meta-diff` command
 
 
 ### meta-diff
@@ -68,5 +68,5 @@ The diff result will be organized as a combination of following basic structure:
 - `rule_link_url`: corresponding change rule docs. For full rule doc, please refer to [this link](https://github.com/Azure/azure-cli/tree/dev/doc/breaking_change_rules)
 - `rule_message`: detailed change info message
 - `rule_name`: abbreviation of rules
-- `suggest_message`: it's used for developers of CI when a pull request is made to cli code repo.
+- `suggest_message`: it's used for developers of CI when a pull request is made to CLI code repo.
 

doc/classic_cli_migration.md

@@ -42,7 +42,7 @@ using NPM, upgrade with `npm upgrade -g azure-cli`.  If you used an installer,
 we recommend downloading the latest installer to upgrade.
 
 To install the latest Azure CLI, follow the steps for your preferred platform or
-environment in our [Installation Guide](https://docs.microsoft.com/cli/azure/install-azure-cli).
+environment in our [Installation Guide](https://learn.microsoft.com/cli/azure/install-azure-cli).
 
 Once installed, you run `az configure` and follow the steps to setup your default output format.  
 

doc/command_guidelines.md

@@ -28,7 +28,7 @@ If in doubt, ask!
 
 - Be consistent with POSIX tools (support piping, work with grep, awk, jq, etc.)
 - Support tab completion for parameter names and values (e.g. resource names)
-- Commands must support all output types (json, tsv, table)
+- Commands must support all output types (JSON, TSV, table)
 - Provide custom table outputs for commands that don't provide table output automatically
 - Commands must return an object, dictionary or `None` (do not string, Boolean, etc. types)
 - Command output must go to `stdout`, everything else to `stderr` (log/status/errors).

doc/debug/debug_in_vs_code.md

@@ -3,7 +3,7 @@
 ## Prerequisite
 
 * Visual Studio Code [Link](http://code.visualstudio.com/)
-* Visual Studio Code Python Extension [Link](https://marketplace.visualstudio.com/items?itemName=donjayamanne.python)
+* Visual Studio Code Python Extension [Link](https://marketplace.visualstudio.com/items?itemName=ms-python.python)
 * Python 3.8+
 * Set up development environment [Link](https://github.com/Azure/azure-cli/blob/master/doc/configuring_your_machine.md)
 

doc/error_handling_guidelines.md

@@ -101,13 +101,13 @@ Below are the specific DOs and DON'Ts when writing the error messages. PRs viola
 
 __DOs__
 - Use the capital letter ahead of an error message.
-- Provide actionable message with argument suggestion. (e.g, Instead of using `resource group is missing, please provide a resource group name`, use `resource group is missing, please provide a resource group name by --resource-group`)
+- Provide actionable message with argument suggestion. (e.g., Instead of using `resource group is missing, please provide a resource group name`, use `resource group is missing, please provide a resource group name by --resource-group`)
 
 __DON'Ts__
-- Do not control the style of an error message. (e.g, the unnecessary `'\n'` and the colorization.)
-- Do not include the error type info in an error message. (e.g, `usage error: --ids | --name [--resource-group]`)
-- Do not use a formula-like or a programming expression in the error message. (e.g, `Parameter 'resource_group_name' must conform to the following pattern: '^[-\\w\\._\\(\\)]+$'`)
-- Do not use ambiguous expressions which mean nothing to users. (e.g, `Something unexpected happens.`)
+- Do not control the style of an error message. (e.g., the unnecessary `'\n'` and the colorization.)
+- Do not include the error type info in an error message. (e.g., `usage error: --ids | --name [--resource-group]`)
+- Do not use a formula-like or a programming expression in the error message. (e.g., `Parameter 'resource_group_name' must conform to the following pattern: '^[-\\w\\._\\(\\)]+$'`)
+- Do not use ambiguous expressions which mean nothing to users. (e.g., `Something unexpected happens.`)
 
 
 ## Error Recommendation

doc/extensions/README.md

@@ -30,7 +30,7 @@ How to find and install an Extension
 
 - Install an extension: `az extension install --name <extension-name>`
 
-More details on usage in [Extensions for Azure CLI 2.0](https://docs.microsoft.com/cli/azure/azure-cli-extensions-overview#install-extensions)
+More details on usage in [Extensions for Azure CLI 2.0](https://learn.microsoft.com/cli/azure/azure-cli-extensions-overview#install-extensions)
 
 
 Doc Sections

doc/extensions/authoring.md

@@ -53,7 +53,7 @@ The storage fields can be stored in your config file or as environment variables
 
 Once your extension is published, you can view it via `az extension list-available -o table`.
 
-However, if you want your extension to be listed in [Official Available Extensions for Azure CLI](https://docs.microsoft.com/cli/azure/azure-cli-extensions-list), you have to wait until the next [Azure CLI release](https://github.com/Azure/azure-cli/milestones). We update that document every time Azure CLI is released. Alternatively, you could file a PR to update it manually if it's urgent.
+However, if you want your extension to be listed in [Official Available Extensions for Azure CLI](https://learn.microsoft.com/cli/azure/azure-cli-extensions-list), you have to wait until the next [Azure CLI release](https://github.com/Azure/azure-cli/milestones). We update that document every time Azure CLI is released. Alternatively, you could file a PR to update it manually if it's urgent.
 
 ## Uncommon Flows
 
@@ -73,7 +73,7 @@ Normally, you will have you extension installed in dev mode and your code change
 
 **(Step 1)** Build the extension to generate a WHL file.
 
-`azdev extension build myexampleextesion`
+`azdev extension build myexampleextension`
 
 **(Step 2)** Uninstall the dev extension.
 

doc/extensions/extension_summary_guidelines.md

@@ -6,7 +6,7 @@ on the documentation site:
 1. Summaries must contain complete sentences.
 2. Summaries must not be more than 3 sentences. Single sentences are preferred, 120-140 character max.
 3. Summaries must use correct spelling and English grammar, including definite and indefinite articles for nouns ('the', 'a', or 'an')
-4. Extension names are not proper nouns  (i.e. should be 'alias extension', not 'Alias Extension')
+4. Extension names are not proper nouns  (i.e., should be 'alias extension', not 'Alias Extension')
  
     BAD: Azure CLI Alias Extension  
     IMPROVED: The Azure CLI alias extension.

doc/extensions/versioning_guidelines.md

@@ -1,10 +1,10 @@
 # Versioning of Azure CLI Extension
 
-To keep a unified versioning strategy across azure cli extension modules, azure cli set up a simple list of rules and requirements on how cli extension version numbers are assigned and incremented, based on [Semantic Versioning](https://semver.org/#semantic-versioning-200) 
+To keep a unified versioning strategy across Azure CLI extension modules, Azure CLI set up a simple list of rules and requirements on how CLI extension version numbers are assigned and incremented, based on [Semantic Versioning](https://semver.org/#semantic-versioning-200) 
 
 ## Versioning Scheme
 
-The published cli extension modules MUST comply with the following version scheme:
+The published CLI extension modules MUST comply with the following version scheme:
 
 ```
 MAJOR.MINOR.PATCH[pre]
@@ -17,7 +17,7 @@ Extension version identifiers are separated into up to four segments:
 - pre: preview (or pre-release) indicator, `b[1-9][0-9]*`, started with `b` and ended with numeric identifier, positive integers, no leading zeroes
 
 #### Notes
-- Azure cli extension only holds two kinds of public releases: stable and preview
+- Azure CLI extension only holds two kinds of public releases: stable and preview
 - Each segment MUST increase numerically. If MAJOR number is incremented, MINOR and PATCH number should be reset to 0. And PATCH number should be reset to 0 if MINOR number is incremented
 - Precedence is determined by the first difference when comparing each of these segments from left to right as follows: Major, minor, and patch versions numerically. And, preview-release version is smaller than corresponding stable-release version. For instance: 1.9.0 < 2.0.0b1 < 2.0.0b2 < 2.0.0 < 2.1.0
 
@@ -141,9 +141,9 @@ Considering version increment rules above, version transition table can be summa
 
 Current extension module has a combination of semantic scheme and extra metadata tags (`azext.isExperimental` and `azext.isPreview`) to mark module release version. To keep backward compatibility:
 - `azext.isPreview` is reserved for all preview extension releases.
-- `azext.isExperimental` is deprecated and will be replaced by `azext.isPreview` for version tag simplicity, since cli extension only supports two types of public releases now: stable and preview
+- `azext.isExperimental` is deprecated and will be replaced by `azext.isPreview` for version tag simplicity, since CLI extension only supports two types of public releases now: stable and preview
 - For all stable extension releases, neither `azext.isPreview` nor `azext.isExperimental` can be added into module metadata.
 
 ## Extension Installation Upgrade
 
-To distinguish `stable-only` extension installation with `preview-included` extension installation, `--allow-preview` is added into `az extension add/update` and `az upgrade` and the `stable/preview` justification is made based on this extension versioning specification from cli version `2.56.0`. Default value for `--allow-preview` is `True` for user compatibility and will be reset to `False` in next breaking change window (by May 2024).
+To distinguish `stable-only` extension installation with `preview-included` extension installation, `--allow-preview` is added into `az extension add/update` and `az upgrade` and the `stable/preview` justification is made based on this extension versioning specification from CLI version `2.56.0`. Default value for `--allow-preview` is `True` for user compatibility and will be reset to `False` in next breaking change window (by May 2024).

doc/how_to_bump_SDK_version_in_cli.md

@@ -8,7 +8,7 @@ Developers need to do several things for bumping version:
 1. Upgrade CLI dependency
     - Upgrade the SDK version in [setup.py](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/setup.py), [requirements.py3.windows.txt](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/requirements.py3.windows.txt), [requirements.py3.Linux.txt](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/requirements.py3.Linux.txt) and [requirements.py3.Darwin.txt](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/requirements.py3.Darwin.txt)
 2. Update the used API version
-    - If it's not multi-api SDK, then nothing needed in this step
+    - If it's not multi-API SDK, then nothing needed in this step
     - If the SDK contains multiple APIs, the specified API version needs to be updated in CLI Core [AZURE_API_PROFILES](https://github.com/Azure/azure-cli/blob/ce74ae358b51aedfdfb6c32042b515d949618e33/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L147) for 'latest' profile
 3. Regression test to check if it breaks existing features
     - Run `azdev test --no-exitfirst` to figure out all test failures in all modules after bumping version
@@ -44,13 +44,13 @@ Developers can a) update code in your own repo&branch and then leverage this pip
 
 For scenario a, variables `CUSTOM_REPO`, `CUSTOM_BRANCH`, `CUSTOM_GITHUB_TOKEN` and `CUSTOM_WHL_URL` are used.
 For scenario b, variables `PACKAGE`, `TARGET_PACKAGE_VERSION`, `RESOURCE_TYPE` and `TARGET_API_VERSION` are used.
-- CUSTOM_REPO: The forked repo name: `https://github.com/{CUSTOM_REPO}/azure-cli/`, eg. `azclibot`, `evelyn-ys`, etc. **Required for scenario a**. Leave it as empty for scenario b.
-- CUSTOM_BRANCH: The branch you used in your forked repo to develop features, eg. `dev`, `fix_XXX`, etc. **Required for scenario a**. Leave it as empty for scenario b.
+- CUSTOM_REPO: The forked repo name: `https://github.com/{CUSTOM_REPO}/azure-cli/`, e.g., `azclibot`, `evelyn-ys`, etc. **Required for scenario a**. Leave it as empty for scenario b.
+- CUSTOM_BRANCH: The branch you used in your forked repo to develop features, e.g., `dev`, `fix_XXX`, etc. **Required for scenario a**. Leave it as empty for scenario b.
 - CUSTOM_GITHUB_TOKEN: Github personal access token which allows commit changes to your repo and branch. See [creating a personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). **Required for scenario a**. Leave it as empty for scenario b.
 - CUSTOM_WHL_URL: A download url for SDK whl file if you want to test based on private package
-- PACKAGE: The SDK package name, eg. `azure-mgmt-network`. **Required for scenario b**. Leave it as empty for scenario a.
-- TARGET_PACKAGE_VERSION: The SDK new version, eg. `19.3.0`. **Required for scenario b**. Leave it as empty for scenario a.
-- RESOURCE_TYPE: The resource type enum name define in [CLI Core](https://github.com/Azure/azure-cli/blob/ce74ae358b51aedfdfb6c32042b515d949618e33/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L38), eg. `MGMT_NETWORK`. Required if you want to update the API version definition in CLI Core. Usually used for multi-api SDKs. Leave it as empty for scenario a.
+- PACKAGE: The SDK package name, e.g., `azure-mgmt-network`. **Required for scenario b**. Leave it as empty for scenario a.
+- TARGET_PACKAGE_VERSION: The SDK new version, e.g., `19.3.0`. **Required for scenario b**. Leave it as empty for scenario a.
+- RESOURCE_TYPE: The resource type enum name define in [CLI Core](https://github.com/Azure/azure-cli/blob/ce74ae358b51aedfdfb6c32042b515d949618e33/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L38), e.g., `MGMT_NETWORK`. Required if you want to update the API version definition in CLI Core. Usually used for multi-API SDKs. Leave it as empty for scenario a.
 - TARGET_API_VERSION: The new API version(s):
     - If the AZURE_API_PROFILES['latest'][RESOURCE_TYPE] definition is `str` type, then just fulfill this variable with new API version. For example, to update API version for [ResourceType.MGMT_NETWORK](https://github.com/Azure/azure-cli/blob/ce74ae358b51aedfdfb6c32042b515d949618e33/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L150), use `2021-10-01` as variable value.
     - If the  AZURE_API_PROFILES['latest'][RESOURCE_TYPE] definition is `SDKProfile` type, then fulfill this variable with 'operation=version' pairs separated by space. For example, to update API version for [ResourceType.MGMT_COMPUTE](https://github.com/Azure/azure-cli/blob/ce74ae358b51aedfdfb6c32042b515d949618e33/src/azure-cli-core/azure/cli/core/profiles/_shared.py#L151-L164), use `default=2022-05-01 snapshots=2022-03-01 gallery_images=2021-12-01` as variable value. `default` means other operations except for explicitly listed ones.

doc/install_troubleshooting.md

@@ -9,7 +9,7 @@ These are issues we have closed because we cannot address them within the CLI du
 lsb_release does not return the correct base distribution version
 -----------------------------------------------------------------
 
-Some Ubuntu- or Debian-derived distributions such as Linux Mint may not return the correct version name from `lsb_release`. This value is used in the install process to determine the package to install. If you know the code name of the Ubuntu or Debian version your distribution is derived from, you can set the `AZ_REPO` value manually when [adding the repository](https://docs.microsoft.com/cli/azure/install-azure-cli-apt#set-release). Otherwise, look up information for your distribution on how to determine the base distribution code name and set `AZ_REPO` to the correct value.
+Some Ubuntu- or Debian-derived distributions such as Linux Mint may not return the correct version name from `lsb_release`. This value is used in the install process to determine the package to install. If you know the code name of the Ubuntu or Debian version your distribution is derived from, you can set the `AZ_REPO` value manually when [adding the repository](https://learn.microsoft.com/cli/azure/install-azure-cli-linux?pivots=apt#lsb_release-doesnt-return-the-correct-base-distribution-version). Otherwise, look up information for your distribution on how to determine the base distribution code name and set `AZ_REPO` to the correct value.
 
 
 No package for your Debian-based distribution
@@ -17,14 +17,14 @@ No package for your Debian-based distribution
 
 Sometimes it may be a while after a distribution is released before there's an Azure CLI package available for it. The Azure CLI is designed to be resilient with regards to future versions of dependencies and rely on as few of them as possible. If there's no package available for your base distribution, try a package for an earlier distribution.
 
-To do this, set the value of `AZ_REPO` manually when [adding the repository](https://docs.microsoft.com/cli/azure/install-azure-cli-apt#set-release). For Ubuntu distributions use the `bionic` repository, and for Debian distributions
+To do this, set the value of `AZ_REPO` manually when [adding the repository](https://learn.microsoft.com/cli/azure/install-azure-cli-linux?pivots=apt#no-package-for-your-distribution). For Ubuntu distributions use the `bionic` repository, and for Debian distributions
 use `stretch`. Distributions released before Ubuntu Trusty and Debian Wheezy are not supported.
 
 
 Install on RHEL 7.6 or other YUM-managed systems without Python 3
 -----------------------------------------------------------------
 
-If you can, please upgrade your system to a version with official support for `python3` package. Otherwise, you need to first install a `python3` package, either [build from source](https://github.com/linux-on-ibm-z/docs/wiki/Building-Python-3.6.x) or install through some [additional repo](https://developers.redhat.com/blog/2018/08/13/install-python3-rhel/). Then you can download the package and install it without dependency.
+If you can, please upgrade your system to a version with official support for `python3` package. Otherwise, you need to first install a `python3` package, either [build from source](https://github.com/linux-on-ibm-z/docs/wiki/Building-Python-3.6.x) or install through some [additional repo](https://developers.redhat.com/blog/install-python3-rhel). Then you can download the package and install it without dependency.
 ```bash
 $ sudo yum install yum-utils
 $ sudo yumdownloader azure-cli

doc/microsoft_graph_client.md

@@ -18,7 +18,7 @@ graph_client = GraphClient(cli_ctx)
 
 ## Request
 
-The underlying Microsoft Graph API is exposed as `GraphClient` methods. For example, [Create application](https://docs.microsoft.com/en-us/graph/api/application-post-applications) API corresponds to `application_create`.
+The underlying Microsoft Graph API is exposed as `GraphClient` methods. For example, [Create application](https://learn.microsoft.com/graph/api/application-post-applications) API corresponds to `application_create`.
 
 The order of the verb ("create") and the noun ("application") is inverted to keep alignment with Azure CLI commands like `az ad app create` and old Python SDK `azure-graphrbac` methods like `graph_client.applications.create`. This makes it easier to find a method/API from the new `GraphClient` and migrate to it:
 
@@ -27,7 +27,7 @@ The order of the verb ("create") and the noun ("application") is inverted to kee
 + graph_client.application_create(body)
 ```
 
-The `body` argument for the request should be a `dict` object as defined by the underlying API. For example, [Create application](https://docs.microsoft.com/en-us/graph/api/application-post-applications) takes a `dict` object defined by [application resource type](https://docs.microsoft.com/en-us/graph/api/resources/application).
+The `body` argument for the request should be a `dict` object as defined by the underlying API. For example, [Create application](https://learn.microsoft.com/graph/api/application-post-applications) takes a `dict` object defined by [application resource type](https://learn.microsoft.com/graph/api/resources/application).
 
 For example, to create an application with certain `displayName`:
 

doc/parampersist_localcontext_guidelines.md

@@ -1,4 +1,4 @@
-The document provides instructions and guidelines on how to board param persist feature, prevoius name local context. The public feature name to end user is param persist. The usage is at [here](https://docs.microsoft.com/cli/azure/param-persist-howto). In implementation, it's referenced as local context. The 2 terms are equivalent in this doc.
+The document provides instructions and guidelines on how to board param persist feature, previous name local context. The public feature name to end user is param persist. The usage is at [here](https://learn.microsoft.com/cli/azure/azure-cli-configuration). In implementation, it's referenced as local context. The 2 terms are equivalent in this doc.
 
 ## Local context attribute
 

doc/private_endpoint_connection_command_guideline.md

@@ -123,7 +123,7 @@ del namespace.connection_id
 In order to transform the output of the `list` command, we provide a transform function `gen_dict_to_list_transform`. The key's value depends on each service's response.
 ```
 from azure.cli.core.commands.transform import gen_dict_to_list_transform
-g.command('list', transform=gen_dict_to_list_transform(key='values')) #  defalut key is `value`
+g.command('list', transform=gen_dict_to_list_transform(key='values')) #  default key is `value`
 ```
 
 #### Test

doc/quoting-issues-with-powershell.md

@@ -6,7 +6,7 @@ These issues are being tracked at [#15529](https://github.com/Azure/azure-cli/is
 
 On Windows, there is a known issue of PowerShell when calling native `.exe` executables or `.bat`, `.cmd` Command Prompt scripts: https://github.com/PowerShell/PowerShell/issues/1995.
 
-In short, **Windows native command invoked from PowerShell will be parsed by Command Prompt again**. This behavior contradicts the doc [About Quoting Rules](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_quoting_rules).
+In short, **Windows native command invoked from PowerShell will be parsed by Command Prompt again**. This behavior contradicts the doc [About Quoting Rules](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_quoting_rules).
 
 As `az` is a Command Prompt script (at `C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd`), it will have issues when invoked from PowerShell. These issues don't happen when invoking a PowerShell cmdlet:
 
@@ -23,7 +23,7 @@ some quoted text
 In order for a symbol to be received by Azure CLI, you will have to take both PowerShell and Command Prompt's parsing into consideration. If a symbol still exists after 2 rounds of parsing, Azure CLI will receive it.
 
 ## Workaround: the stop-parsing symbol
-To prevent this, you may use [stop-parsing symbol](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_parsing) `--%` between `az` and arguments.
+To prevent this, you may use [stop-parsing symbol](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_parsing) `--%` between `az` and arguments.
 
 > The stop-parsing symbol (--%), introduced in PowerShell 3.0, directs PowerShell to refrain from interpreting input as PowerShell commands or expressions.
 > When it encounters a stop-parsing symbol, PowerShell treats the remaining characters in the line as a literal.
@@ -59,7 +59,7 @@ operable program or batch file.
 In general, when running `az "a&b"` in PowerShell,
 
 1. Since there is no whitespace in the argument, PowerShell will strip the quotes and pass the argument to Command Prompt
-2. The ampersand `&` is parsed again by Command Prompt as a [command separator](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb490954(v=technet.10)#using-multiple-commands-and-conditional-processing-symbols)
+2. The ampersand `&` is parsed again by Command Prompt as a [command separator](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-xp/bb490954(v=technet.10)#using-multiple-commands-and-conditional-processing-symbols)
 3. `b` is treated as a separate command by Command Prompt, instead of part of the argument
 
 ```powershell
@@ -173,7 +173,7 @@ Command arguments: ['{"key": "value"}', '--debug']
 
 For complex arguments like JSON string, the best practice is to use Azure CLI's `@<file>` convention to load from a file to bypass the shell's interpretation.
 
-Note that At symbol (`@`) is [splatting operator](https://docs.microsoft.com/powershell/module/microsoft.powershell.core/about/about_splatting) in PowerShell, so it should be quoted.
+Note that At symbol (`@`) is [splatting operator](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_splatting) in PowerShell, so it should be quoted.
 
 ```powershell
 az ad app create ... --required-resource-accesses "@manifest.json"

doc/shorthand_syntax.md

@@ -1,10 +1,10 @@
 Azure CLI Shorthand Syntax (Preview)
 ======
 
-Azure cli shorthand syntax can help cli users to pass complicated argument values.
+Azure CLI Shorthand Syntax can help CLI users to pass complicated argument values.
  Only the arguments of AAZ(Atomic Azure CLI) commands generated by aaz-dev tool support shorthand syntax.
 
-The command lines written in shorthand syntax can run in both _Powershell_ and _Bash_ terminals without any change in must situations.
+The command lines written in shorthand syntax can run in both _PowerShell_ and _Bash_ terminals without any change in must situations.
 
 [1. Shorthand syntax formats](#shorthand-syntax-formats)
 

doc/storage_data_plane_commands_auth.md

@@ -42,17 +42,17 @@ az storage blob show --name $blobName --container-name $containerName --connecti
 
 By specifying `--sas-token $sasToken` or `--connection-string $connectionString` configured using shared access signature (SAS), CLI can get a signed URI including a token that indicates how the resources may be accessed by the client.
 
-Here's an example of getting properties of a blob in a storage account with sas token:
+Here's an example of getting properties of a blob in a storage account with SAS token:
 ```
-# Generate a sas (Shared access signature) token
+# Generate a SAS (Shared access signature) token
 az storage account/container/blob/share/fs/queue/table generate-sas
 # Get blob properties with sas token
 az storage blob show --name $blobName --container-name $containerName --account-name $accountName --sas-token $sasToken
 ```
 
-Here's an example of getting properties of a blob in a storage account with connection string configured using sas:
+Here's an example of getting properties of a blob in a storage account with connection string configured using SAS:
 ```
-# Generate a sas (Shared access signature) token
+# Generate a SAS (Shared access signature) token
 az storage account/container/blob/share/fs/queue/table generate-sas
 # Configure a connection string(Each service endpoint is optional, although the connection string must contain at least one.)
 connectionString="BlobEndpoint=${blobEndpoint};QueueEndpoint=${queueEndpoint};TableEndpoint=${tableEndpoint};FileEndpoint=${fileEndpoint};SharedAccessSignature=${sasToken}"
@@ -69,6 +69,6 @@ If no `--auth-mode` or `--account-key` or `--sas-token` or `--connection-string`
 Then CLI will proceed the data plane requests with the account key queried before.
 
 ## See More
-* [Azure control plane and data plane](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/control-plane-and-data-plane)
-* [Authorize access to data in Azure Storage](https://docs.microsoft.com/en-us/azure/storage/common/authorize-data-access)
-* [Configure Azure Storage connection strings](https://docs.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
+* [Azure control plane and data plane](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/control-plane-and-data-plane)
+* [Authorize access to data in Azure Storage](https://learn.microsoft.com/en-us/azure/storage/common/authorize-data-access)
+* [Configure Azure Storage connection strings](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)

doc/telemetry/README.md

@@ -13,7 +13,7 @@ ARM telemetry tracks all HTTP requests and responses through ARM endpoint. As fa
 
 ## CLI Client Telemetry
 
-Client side telemetry is sent at the end of Azure CLI command execution. It covers all commands, no matter if it has http requests or just has local operations.
+Client side telemetry is sent at the end of Azure CLI command execution. It covers all commands, no matter if it has HTTP requests or just has local operations.
 Sanitized data is stored in Kusto cluster which is managed by DevDiv Data team.
 
 All Azure CLI data is stored in a large json named `Properties` in table `RawEventsAzCli`. Some properties are flatten, some are not. Here are some useful fields:
@@ -34,8 +34,8 @@ All Azure CLI data is stored in a large json named `Properties` in table `RawEve
 - `ProductVersion`: CLI core version in the format of `azurecli@{version}`
 - `CoreVersion`: CLI core version
 - `ExeVersion`: `{cli_core_version}@{module_version}`. In the new schema (CLI version > 2.0.28), all module versions are `none`. Hence this field is `{cli_core_version}@none`
-- `OsType`: OS system, eg. linux, windows
-- `OsVersion`: OS platform version, eg. 10.0.14942
+- `OsType`: OS system, e.g., linux, windows
+- `OsVersion`: OS platform version, e.g., 10.0.14942
 - `PythonVersion`: platform python version
 - `ShellType`: cmd/bash/ksh/zsh/cloud-shell/... Note: may not be accurate.
 - `MacAddressHash`: SHA256 hashed MAC address
@@ -59,7 +59,7 @@ All Azure CLI data is stored in a large json named `Properties` in table `RawEve
     - `reserved.datamodel.fault.typestring`: Additional field when `EventName == 'azurecli/fault'`. It logs the exception class.
     - `reserved.datamodel.fault.description`: Additional field when `EventName == 'azurecli/fault'`. It logs exception description or fault type.
     - `context.default.vs.core.os.platform`: OS platform
-    - `context.default.azurecli.source`: `az`/`completer`. It's `completer` if we found argument auto complete settings in os environment variable.
+    - `context.default.azurecli.source`: `az`/`completer`. It's `completer` if we found argument auto complete settings in OS environment variable.
     - `context.default.azurecli.environmentvariables`: It logs customer's environment variables starting with `AZURE_CLI`
     - `context.default.azurecli.extensionname`: It logs the extension name and version in the format of `{extension_name}@{extension_version}` if the command is from CLI extension.
     - `context.default.azurecli.installer`: value of os environment variable `AZ_INSTALLER`
@@ -71,4 +71,4 @@ All Azure CLI data is stored in a large json named `Properties` in table `RawEve
 
 - [Kusto Examples](kusto_examples.md) - Samples for kusto query
 
-- [FAQ](faq.md) - Commonly asked questions
+- [FAQ](faq.md) - Frequently Asked Questions

doc/telemetry/faq.md

@@ -2,8 +2,8 @@
 
 ## What's the relationship of CLI telemetry and ARM telemetry?
 
-- CLI telemetry is client telemetry. It logs os, platform, command, parameter, result and other client info.
-- ARM telemetry is server telemetry. It tracks all HTTP requests and responses through ARM endpoint from different clients, including CLI, Powershell, SDK...
+- CLI telemetry is client telemetry. It logs OS, platform, command, parameter, result and other client info.
+- ARM telemetry is server telemetry. It tracks all HTTP requests and responses through ARM endpoint from different clients, including CLI, PowerShell, SDK...
 - They share the same `clientRequestId` which you can leverage to join `HttpIncomingRequests` (ARM telemetry table) with `RawEventsAzCli` (CLI telemetry table)
 
 

doc/telemetry/kusto_examples.md

@@ -30,7 +30,7 @@ RawEventsAzCli
 | take 10
 ```
 
-## Query for specific command with specific cli version
+## Query for specific command with specific CLI version
 e.g. `az account show` command with CLI version `2.35.0`
 
 ```
@@ -41,7 +41,7 @@ RawEventsAzCli
 | take 10
 ```
 
-## Query for specific command with specific cli extension version
+## Query for specific command with specific CLI extension version
 e.g. `az connectedk8s connect` command with version `1.2.8` of extension `connectedk8s`
 
 ```

doc/track_2_migration_roadmap.md

@@ -3,7 +3,7 @@ This document provides the roadmap for Track 2 SDK migration in Azure CLI. When
 
 ## Why do we need migrate Track 1 SDK to Track 2 SDK in Azure CLI?
 - Track 1 SDK will be eventually deprecated sometime in the future. 
-- Some new features will only be in track2 SDK in the future.
+- Some new features will only be in Track 2 SDK in the future.
 
 ## Here are criteria to determine the priority of migration:
 - On-demand for Track 2 SDK from CLI customers (such as CAE support from LinkedIn) has higher priority.
@@ -11,9 +11,9 @@ This document provides the roadmap for Track 2 SDK migration in Azure CLI. When
 - The smaller the gap between Track 1 SDK version and Track 2 SDK version, the higher priority.
 - The more frequent release, the higher priority.
 - If Track 1 SDK is in preview (0.x.x or x.x.xrc), the lower priority.
-- Extenison has lower priority.
+- Extension has lower priority.
 
-## Here is the proposed roadmap for managment plane migration. (Total 60 CLI modules and 78 extensions)
+## Here is the proposed roadmap for management plane migration. (Total 60 CLI modules and 78 extensions)
 
 - To meet CAE requirements (`CAE support` column is `Yes` in the table below), 
   - 12 services need to be migrated by the end of 0/30/2021.

doc/use_cli_effectively.md

@@ -1,3 +1,3 @@
 # Tips for using Azure CLI effectively
 
-The content of this article has been moved to Microsoft Docs [Tips for using Azure CLI effectively](https://docs.microsoft.com/en-us/cli/azure/use-cli-effectively).
+The content of this article has been moved to Microsoft Learn [Tips for using the Azure CLI effectively](https://learn.microsoft.com/cli/azure/use-azure-cli-successfully).

doc/use_cli_in_airgapped_clouds.md

@@ -62,15 +62,15 @@ on Linux shells or
 ```powershell
 $Env:ARM_CLOUD_METADATA_URL = "https://example.url.com/metadata/endpoints?api-version=2019-05-01"
 ```
-on Windows Powershell.
+on Windows PowerShell.
 The content of the metadata URL should be similar to that of the public cloud metadata URL: https://management.azure.com/metadata/endpoints?api-version=2019-05-01.
 
 Then CLI will load the available clouds and the corresponding cloud endpoints from the URL. The first cloud in the available cloud list will be set as the active cloud by default if the public `AzureCloud` is (most likely) not available.
 
-If you are working with multiple clouds, you can learn more in [Work with multiple clouds](https://docs.microsoft.com/cli/azure/manage-clouds-azure-cli).
+If you are working with multiple clouds, you can learn more in [Work with multiple clouds](https://learn.microsoft.com/cli/azure/manage-clouds-azure-cli).
 
 ## Set CA bundle certificate
-Please follow the first solution in [Work behind a proxy](https://docs.microsoft.com/cli/azure/use-cli-effectively#work-behind-a-proxy) to set up the certificate in your airgapped cloud environment. For more details, you can also refer to the steps in the [guide](https://docs.microsoft.com/azure-stack/user/azure-stack-version-profiles-azurecli2) to set up CLI for Azure Stack Hub.
+Please follow the first solution in [Work behind a proxy](https://learn.microsoft.com/cli/azure/use-cli-effectively#work-behind-a-proxy) to set up the certificate in your airgapped cloud environment. For more details, you can also refer to the steps in the [guide](https://learn.microsoft.com/azure-stack/user/azure-stack-version-profiles-azurecli2) to set up CLI for Azure Stack Hub.
 
 ## Login with service principal
 Use the service principal that was granted permission to access a subscription in the airgapped cloud to login.

doc/use_cli_with_git_bash.md

@@ -49,7 +49,7 @@ $ Command arguments: ['find', 'vm create', '--debug']
 #### Entry script exits before command finishes
 The [entry script](https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/az) exits once `os.execl()` is called. It does not wait for the actual command to finish.
 
-According to [_exec, _wexec Functions](https://docs.microsoft.com/en-us/cpp/c-runtime-library/exec-wexec-functions?view=vs-2019), `os.exec` internally uses [CreateProcess](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) which doesn't wait for the sub-process.
+According to [_exec, _wexec Functions](https://learn.microsoft.com/cpp/c-runtime-library/exec-wexec-functions?view=vs-2019), `os.exec` internally uses [CreateProcess](https://learn.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) which doesn't wait for the sub-process.
 
 #### Exit Code is 0 even when the command fails
 Related to the above issue, Windows creates a new process and exits the current one with `os.exec`. Hence the calling program only sees that the script has terminated without an issue (See [Issue9148: os.execve puts process to background on windows](https://bugs.python.org/issue9148#msg109179)). The exit code does not reflect the actual result of the command execution in the new process.

doc/version_management.md

@@ -11,6 +11,6 @@ Starting from version 2.1.0, Azure CLI updates:
 * PATCH version for bug fixes.
 
 ## Backward Compatibility
-Considering Azure CLI is a command line tool for Azure Services, we tend to just bump the MINOR version for breaking changes in a service command module. All breaking changes for commands will be marked as **BREAKING CHANGE** in [release notes](https://docs.microsoft.com/cli/azure/release-notes-azure-cli).
+Considering Azure CLI is a command line tool for Azure Services, we tend to just bump the MINOR version for breaking changes in a service command module. All breaking changes for commands will be marked as **BREAKING CHANGE** in [release notes](https://learn.microsoft.com/cli/azure/release-notes-azure-cli).
 
 At command level, packages only upgrading the PATCH version guarantee backward compatibility.