# CommandSection

title: INTERACTIVE MODE
content:
For users new to the Azure CLI or for exploring commands, `az interactive` provides an enhanced interactive shell experience with autocompletion, command descriptions, and examples. It greatly aids in discovering and learning `az` commands.


title: HISTORY
content:
The Azure CLI (also known as <I>az CLI</I>) was developed by Microsoft as a modern, cross-platform command-line tool for managing Azure resources. It was introduced around 2016-2017, succeeding the older Node.js-based Azure Service Management (ASM) CLI (often referred to as Azure CLI v1). The primary goal was to provide a consistent, Python-based CLI that runs natively on Windows, macOS, and Linux, offering a more robust and flexible experience.<br><br>Since its inception, `az` has undergone continuous development, with frequent updates to support new Azure services and features, making it the primary and recommended command-line interface for Azure cloud management today. Its design emphasizes automation, scripting, and integration into CI/CD pipelines.


title: SEE ALSO
content:
azure-powershell (PowerShell module for Azure), aws cli (Amazon Web Services CLI), gcloud (Google Cloud CLI), kubectl(1) (Kubernetes command-line tool, often used with Azure Kubernetes Service), jq(1) (Command-line JSON processor, useful for `az` output)


title: SYNOPSIS
content:
<b>az account &lt;SUBCOMMAND&gt; [OPTIONS]</b><br><br><i>Common Subcommands:</i><br><b>az account list</b> [--all]<br><b>az account show</b> [--subscription &lt;SUBSCRIPTION_ID_OR_NAME&gt;]<br><b>az account set</b> --subscription &lt;SUBSCRIPTION_ID_OR_NAME&gt;<br><b>az account clear</b>


title: PARAMETERS
content:
<b><b>--subscription &lt;SUBSCRIPTION_ID_OR_NAME&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the target Azure subscription by its ID or name for the operation. This parameter is commonly used with `az account show` or `az account set`.</i><br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Used with `az account list` to display all subscriptions associated with your account, including those that might be disabled or inactive.</i><br><br><b><b>--output &lt;FORMAT&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the output format for the command's results. Common formats include `json`, `jsonc` (colored JSON), `tsv` (tab-separated values), `table`, `yaml`, `yamlc`, or `none`.</i><br><br><b><b>--query &lt;JMESPATH_QUERY&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>A JMESPath query string that allows you to filter or transform the command's JSON output, enabling extraction of specific data points.</i><br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increases logging verbosity to display all debug logs. This is useful for troubleshooting issues and understanding the underlying operations.</i><br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the command's help message, providing a brief description of its usage, subcommands, and available options, then exits.</i><br><br>


title: DESCRIPTION
content:
The `az account` command group within the Azure CLI is a fundamental tool for interacting with your Azure subscriptions and managing your account context. <br>It allows users to list available subscriptions, view details of the currently active subscription, and most importantly, set a specific subscription as the default for subsequent Azure CLI operations. <br>This functionality is crucial for users working in environments with multiple Azure subscriptions, ensuring that commands are executed against the intended subscription. <br>Beyond managing the active context, `az account` also provides commands to clear stored subscription information and retrieve access tokens for programmatic use. <br>It acts as the central point for navigating your identity and billing boundaries within Azure, providing a clear overview of your access permissions and the scope of your CLI commands.


title: CAVEATS
content:
<i><I>Authentication Required:</I> Before using `az account` commands, you must authenticate to Azure using `az login`. The CLI needs valid credentials to retrieve and manage subscription information.<br><I>Permissions:</I> Your Azure identity must possess the necessary permissions (e.g., Reader role on the subscription) to list, show, or modify subscription settings. Lack of permissions will result in errors.<br><I>Active Context:</I> In multi-subscription environments, always verify the currently active subscription to ensure commands are executed in the desired context, preventing accidental operations on the wrong resources.</i>


title: <B>SETTING THE DEFAULT SUBSCRIPTION</B>
content:
<i>After logging into Azure CLI, you might have access to multiple subscriptions. To avoid specifying the `--subscription` parameter for every command, you can set a default subscription. First, list your available subscriptions using `az account list`. Then, set your desired subscription using: `az account set --subscription "&lt;Subscription Name or ID&gt;"`.</i>


title: <B>VIEWING CURRENT ACCOUNT DETAILS</B>
content:
<i>To quickly confirm which Azure subscription is currently active in your CLI session, along with its details like name, ID, and tenant ID, execute the command: `az account show`. This provides an immediate overview of your current operational context.</i>


title: <B>CLEARING LOCAL SUBSCRIPTION CACHE</B>
content:
<i>If you encounter issues with stale subscription data or wish to remove all locally cached subscription information, you can use `az account clear`. This command effectively logs you out of all subscriptions managed by the CLI without affecting your Azure Active Directory login token.</i>


title: HISTORY
content:
<i>The `az account` command group is a foundational component of the modern Azure CLI, which saw its significant evolution and re-architecture from the earlier cross-platform (Xplat-CLI) to the Python-based version, released around 2016. <br>From its inception, the ability to manage Azure subscriptions was identified as a critical user requirement, especially as cloud adoption grew and organizations began utilizing multiple subscriptions for different environments (e.g., dev, test, prod) or departments. <br>Therefore, `az account` has been a stable and continuously improved command, central to the CLI's functionality in providing a robust interface for subscription and tenant management.</i>


title: SYNOPSIS
content:
<I>az acr</I> <I>command</I> [<I>options</I>]<br><br>Where <I>command</I> is one of the available subcommands for managing Azure Container Registry, such as:<br><b><I>az acr create</I></b> - Create a new registry.<br><b><I>az acr show</I></b> - Get the details of a registry.<br><b><I>az acr delete</I></b> - Delete a registry.<br><b><I>az acr repository</I></b> - Manage repositories within a registry.<br><b><I>az acr build</I></b> - Queue a quick build.<br><br>To view a list of all available subcommands and their options, use:<br><I>az acr --help</I><br><I>az acr command --help</I>


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the 'az acr' command group or a specific subcommand.<br><br><b><b>--name -n</b> <I>registry_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Azure Container Registry. This is a common required parameter for most registry-specific operations like create, show, delete, and update.<br><br><b><b>--resource-group -g</b> <I>resource_group_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Azure resource group in which the registry resides. Required for operations that identify the registry by its resource group.<br><br><b><b>--sku</b> <I>Basic|Standard|Premium</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The SKU of the container registry. Applicable when creating or updating a registry, determining features and pricing tier.<br><br><b><b>--admin-enabled</b> <I>true|false</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicates whether the admin user is enabled for the registry. Used to manage programmatic access via admin credentials.<br><br><b><b>--output -o</b> <I>json|jsonc|table|tsv|yaml|yamlc|none</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for the command result. A global Azure CLI parameter applicable to all 'az acr' commands.<br><br><b><b>--query</b> <I>jmespath_string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter and format the command output. A global Azure CLI parameter.<br><br>


title: DESCRIPTION
content:
<I>az acr</I> is the command group within the Azure CLI dedicated to managing Azure Container Registry instances. Azure Container Registry (ACR) is a fully managed, OCI-compliant container registry service in Azure, designed for storing and managing Docker container images and other OCI artifacts. The <I>az acr</I> command set provides a comprehensive interface for performing various operations on your container registries. These operations include creating, deleting, and updating registry instances; managing authentication credentials and network access; configuring geo-replication for global distribution; and overseeing repositories, images, and Helm charts stored within the registry. It also allows for setting up webhooks for event notifications and managing tasks for automated image builds and patching. This command group is crucial for DevOps workflows, enabling seamless integration with CI/CD pipelines and deployment to services like Azure Kubernetes Service (AKS) or Azure App Service. It empowers users to efficiently manage their private container image repositories directly from the command line, ensuring secure and scalable container artifact management in the cloud.


title: CAVEATS
content:
<I>Caveats and Limitations:</I><br><br><b>Azure CLI Installation and Authentication:</b> The <I>az acr</I> commands require the Azure CLI to be installed and properly authenticated to an Azure account (<I>az login</I>). Without authentication, operations will fail due to insufficient permissions.<br><br><b>Permissions (RBAC):</b> To perform operations, the authenticated user or service principal must have the necessary Azure Role-Based Access Control (RBAC) permissions on the target subscription or resource group. Common roles include <I>AcrContributor</I> for full management, <I>AcrPush</I> for pushing images, and <I>AcrPull</I> for pulling images.<br><br><b>Globally Unique Registry Names:</b> Each Azure Container Registry name must be globally unique across all Azure regions and subscriptions. If a chosen name is already in use, the creation command will fail.<br><br><b>SKU Features:</b> The available features and capabilities of an Azure Container Registry vary significantly based on its SKU (<I>Basic</I>, <I>Standard</I>, <I>Premium</I>). For instance, geo-replication and content trust are exclusive to the Premium SKU. Consider your requirements before choosing an SKU.<br><br><b>Resource Group Dependency:</b> All Azure Container Registries must reside within an Azure Resource Group. Management operations often require specifying both the registry name and its associated resource group.


title: COMMON USE CASES
content:
The <I>az acr</I> command group is widely used for: <br><br><b>Automated Image Builds:</b> Using <I>az acr build</I> to automate the process of building container images directly within Azure, often triggered by code commits.<br><br><b>Image Management:</b> Pushing and pulling container images to and from the private registry using <I>docker push</I> and <I>docker pull</I> commands authenticated via <I>az acr login</I>.<br><br><b>CI/CD Integration:</b> Integrating with Azure DevOps, GitHub Actions, Jenkins, or other CI/CD systems to automate the build, push, and deployment of containerized applications.<br><br><b>Kubernetes Deployment:</b> Providing a secure and reliable source for container images deployed to Azure Kubernetes Service (AKS) clusters or other container orchestration platforms.


title: SECURITY AND NETWORKING
content:
ACR offers robust security features manageable via <I>az acr</I> commands: <br><br><b>Azure Active Directory Integration:</b> Authenticate users and service principals using Azure AD.<br><br><b>Managed Identities:</b> Enable Azure resources to authenticate to ACR securely.<br><br><b>Private Endpoints:</b> Configure network isolation for your registry, allowing access only from a virtual network via a private IP address, enhancing security and compliance.<br><br><b>Content Trust:</b> Support for digitally signing images to ensure their integrity and authenticity, crucial for secure supply chain practices.


title: HISTORY
content:
The <I>az acr</I> command group is an integral part of the Azure CLI, introduced to manage Azure Container Registry (ACR), a service launched by Microsoft to provide a private, managed Docker registry in Azure. Its development has closely tracked the evolution of containerization and Kubernetes within the Azure ecosystem, aiming to offer robust and scalable container image management capabilities. Initially focused on Docker images, <I>az acr</I> commands have expanded significantly over time to support various OCI (Open Container Initiative) artifacts, including Helm charts. Key historical developments include the introduction of features like geo-replication for global image distribution, ACR Tasks for automated image builds and patching, content trust for secure image signing, and network isolation capabilities through private endpoints. The command set continues to evolve, reflecting the ongoing advancements in container technology and Azure's commitment to supporting modern DevOps practices.


title: SYNOPSIS
content:
<I>az advisor <B>recommendation</B> <I>list</I> [options]<br><I>az advisor <B>recommendation</B> <I>show</I> --name &lt;recommendation-name&gt; [options]<br><I>az advisor <B>recommendation</B> <I>disable</I> [--ids &lt;ids&gt; | --name &lt;name&gt;] [options]<br><I>az advisor <B>configuration</B> <I>update</I> --low-cpu-threshold &lt;threshold&gt; [options]


title: PARAMETERS
content:
<b><B>recommendation</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Group of commands for managing Azure Advisor recommendations.<br><br><b><B>recommendation</B> <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Azure Advisor recommendations for the current subscription or specified resource group.<br><br><b><B>recommendation</B> <I>show</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the details of a specific Azure Advisor recommendation by its name or ID.<br><br><b><B>recommendation</B> <I>disable</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables one or more Azure Advisor recommendations. Useful for recommendations that are not applicable or already addressed.<br><br><b><B>recommendation</B> <I>enable</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a previously disabled Azure Advisor recommendation.<br><br><b><B>recommendation</B> <I>update</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the status of an Azure Advisor recommendation (e.g., sets to 'Dismissed' or 'Active').<br><br><b><B>configuration</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Group of commands for managing Azure Advisor configurations.<br><br><b><B>configuration</B> <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists Azure Advisor configurations for a subscription.<br><br><b><B>configuration</B> <I>update</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates Azure Advisor configurations, such as setting the low CPU threshold for VM recommendations.<br><br><b>--name <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the recommendation or resource to act upon.<br><br><b>--ids <ids></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of resource IDs. Used to specify multiple recommendations or resources.<br><br><b>--low-cpu-threshold <threshold></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the CPU utilization threshold for low CPU recommendations (e.g., 5 for 5%). Used with <B>configuration</B> <I>update</I>.<br><br><b>--resource-group <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the resource group to filter recommendations.<br><br><b>--category <category></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters recommendations by category (e.g., 'Cost', 'Security', 'Reliability').<br><br><b>--subscription <id/name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Azure subscription to operate on. Overrides the default active subscription.<br><br><b>--output <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format (e.g., 'json', 'table', 'tsv').<br><br><b>--query <jmespath-string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter and format command output.<br><br>


title: DESCRIPTION
content:
The <I>az-advisor</I> command is a component of the <B>Azure Command-Line Interface (Azure CLI)</B> that facilitates programmatic interaction with <B>Azure Advisor</B>.<br><br>Azure Advisor is a personalized cloud consultant that helps optimize Azure deployments by providing actionable recommendations across five categories: Cost, Security, Reliability, Operational Excellence, and Performance. It analyzes your resource configuration and usage telemetry.<br><br>The <I>az-advisor</I> command allows users to list, show details of, disable, enable, and update the status of these recommendations directly from the command line. It also provides functionality to manage Advisor's configuration settings, such as thresholds for certain recommendation types. This capability is essential for automating cloud governance, integrating Advisor insights into scripts, and managing Azure resources efficiently without needing the Azure portal.


title: CAVEATS
content:
The <I>az-advisor</I> command is part of the <B>Azure CLI</B> and is not a standalone Linux utility. It requires the Azure CLI to be installed and an authenticated Azure account to function. Recommendations are dynamically generated by Azure Advisor and require active Azure resources to be effective. The availability and content of recommendations depend on your Azure resource usage and configuration.


title: HISTORY
content:
Azure Advisor was introduced as a service to help users optimize their cloud deployments by providing proactive, actionable, and personalized recommendations. As the Azure CLI evolved to provide comprehensive management capabilities, the <I>az-advisor</I> command was integrated to allow programmatic access to these recommendations. This integration enables automation, facilitates cloud governance by integrating Advisor insights into scripts, and supports efficient resource management within CI/CD pipelines and custom automation solutions.


title: SYNOPSIS
content:
<b>az aks</b> <I>subcommand</I> [<I>options</I>]<br><br>This command group requires a specific subcommand to perform an action. Common subcommands and their basic syntax include:<br><br><I>az aks create</I> --resource-group <I>RESOURCE_GROUP_NAME</I> --name <I>CLUSTER_NAME</I> --node-count <I>NODE_COUNT</I><br><I>az aks list</I> [--resource-group <I>RESOURCE_GROUP_NAME</I>]<br><I>az aks show</I> --resource-group <I>RESOURCE_GROUP_NAME</I> --name <I>CLUSTER_NAME</I><br><I>az aks get-credentials</I> --resource-group <I>RESOURCE_GROUP_NAME</I> --name <I>CLUSTER_NAME</I><br><I>az aks delete</I> --resource-group <I>RESOURCE_GROUP_NAME</I> --name <I>CLUSTER_NAME</I> [--yes]


title: PARAMETERS
content:
<b>--resource-group <I>RESOURCE_GROUP_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the Azure resource group containing the AKS cluster. Required for most operations that target an existing cluster.<br><br><b>--name <I>CLUSTER_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the AKS cluster. Required for operations targeting a specific cluster, or for creating a new one.<br><br><b>--node-count <I>COUNT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of nodes in the default node pool when creating a new cluster.<br><br><b>--generate-ssh-keys</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically generates SSH public and private key files if not specified for cluster creation, used for SSH access to nodes.<br><br><b>--kubernetes-version <I>VERSION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Kubernetes version to use for the cluster (e.g., '1.27.7') or to upgrade an existing cluster to.<br><br><b>--location <I>LOCATION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure region where the cluster will be created (e.g., 'eastus', 'westeurope').<br><br><b>--yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for confirmation during destructive operations like `delete`.<br><br><b>--file <I>FILE_PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file where cluster credentials should be saved (e.g., for `get-credentials`).<br><br><b>--output <I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for the command (e.g., 'json', 'jsonc', 'table', 'tsv'). Defaults to 'json'.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help message for a command or subcommand, detailing available options and usage examples.<br><br>


title: DESCRIPTION
content:
<b>az aks</b> is a command group within the Azure Command-Line Interface (Azure CLI) that provides a comprehensive set of tools for managing Azure Kubernetes Service (AKS) clusters. AKS is a managed Kubernetes service that simplifies the deployment, management, and operations of Kubernetes. This command group allows users to perform various operations directly from their terminal, such as creating new AKS clusters, listing existing ones, retrieving cluster credentials, upgrading Kubernetes versions, managing node pools, and deleting clusters.<br><br>It serves as a programmatic interface to interact with the Azure control plane for AKS resources, making it essential for automation, scripting, and efficient cloud resource management. Users can integrate <b>az aks</b> commands into scripts to automate complex deployment pipelines, manage infrastructure as code, and respond dynamically to changes in their cloud environment.


title: CAVEATS
content:
<ul><li><b>Dependency on Azure CLI:</b> The <b>az aks</b> command group requires the Azure CLI to be installed and configured on your system.</li><li><b>Authentication:</b> You must be logged into an Azure account (`az login`) with sufficient Role-Based Access Control (RBAC) permissions to manage AKS resources within your subscription.</li><li><b>Network Connectivity:</b> Stable internet connectivity is required to interact with Azure services and manage AKS clusters.</li><li><b>Cost Implications:</b> Creating and running AKS clusters incurs costs on your Azure subscription, so ensure you manage and delete resources when no longer needed to avoid unexpected charges.</li><li><b>Versioning:</b> The behavior and available options of <b>az aks</b> commands can change with updates to the Azure CLI and Azure Kubernetes Service APIs. It's recommended to keep your Azure CLI up-to-date.</li></ul>


title: COMMAND GROUP STRUCTURE
content:
The <b>az aks</b> command is part of a hierarchical structure within the Azure CLI. <b>az</b> is the root command, `aks` is a command group (similar to `az vm` for virtual machines or `az storage` for storage accounts), and further subcommands (e.g., `create`, `list`, `delete`, `upgrade`) are nested within it. This well-organized structure helps in managing the vast number of Azure services and their associated operations efficiently.


title: INTERACTIVE MODE
content:
Azure CLI supports an interactive mode, invoked by running `az interactive`. This mode provides features like command completion, command descriptions, and examples, making it significantly easier to discover and correctly use <b>az aks</b> commands, especially for users new to the CLI or to specific AKS operations.


title: INFRASTRUCTURE AS CODE (IAC)
content:
While <b>az aks</b> commands are excellent for scripting, automation, and quick operations, for production deployments and robust Infrastructure as Code (IaC) practices, they are often used in conjunction with Azure Resource Manager (ARM) templates, Bicep, or Terraform. These tools allow for declarative definition and deployment of AKS clusters and their surrounding infrastructure, ensuring consistency and repeatability.


title: HISTORY
content:
The <b>az aks</b> command group's development is intricately linked with the rapid evolution of cloud computing, containerization, and microservices architectures. As Kubernetes gained widespread adoption as the de-facto standard for container orchestration, cloud providers like Microsoft Azure introduced managed Kubernetes services (AKS) to simplify its deployment and operation.<br><br>The Azure CLI, which began its life as `azure-cli` and later evolved into `az`, was developed to provide a consistent, powerful, and scriptable interface for managing Azure resources. The `aks` command group was specifically added and continuously enhanced within the Azure CLI to keep pace with new AKS features, Kubernetes versions, and evolving best practices. This evolution reflects the growing industry demand for automated, scalable, and resilient container deployment and management in the cloud.


title: SYNOPSIS
content:
<b>az apim</b> <I>command-group</I> <I>subcommand</I> [parameters]<br><br><i>Common command patterns:</i><br><b>az apim create</b> --name <I>service-name</I> --resource-group <I>rg-name</I> --location <I>location</I> --publisher-email <I>email</I> --publisher-name <I>name</I> --sku-name <I>sku</I><br><b>az apim show</b> --name <I>service-name</I> --resource-group <I>rg-name</I><br><b>az apim api create</b> --service-name <I>service-name</I> --resource-group <I>rg-name</I> --display-name <I>name</I> --path <I>path</I> --protocols <I>protocols</I> --url <I>url</I><br><b>az apim api list</b> --service-name <I>service-name</I> --resource-group <I>rg-name</I>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help message for the command or subcommand, detailing available options and usage examples.<br><br><b>--output <<i>format</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Accepted values include: <I>json</I>, <I>jsonc</I> (colorized json), <I>table</I>, <I>tsv</I> (tab-separated values), <I>yaml</I>, <I>none</I>. The default is usually <I>json</I>.<br><br><b>--query <<i>JMESPath</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string for filtering or transforming the command's output. Useful for extracting specific data.<br><br><b>--subscription <<i>id</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of the Azure subscription to operate within. This can be configured as a default.<br><br><b>--resource-group <<i>name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Azure resource group containing the API Management service. Often required for resource-specific operations.<br><br><b>--name <<i>service-name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary name identifier for the API Management service instance. Used in commands like <I>create</I>, <I>show</I>, <I>delete</I>.<br><br><b>--service-name <<i>service-name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Another common parameter, similar to <I>--name</I>, specifying the API Management service instance to target, particularly within nested subcommands (e.g., <I>az apim api list --service-name ...</I>).<br><br><b>--location <<i>location</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure region where the API Management service instance will be deployed (e.g., <I>eastus</I>, <I>westeurope</I>). Required for creation.<br><br><b>--sku-name <<i>sku</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The pricing tier of the API Management service. Common values include <I>Developer</I>, <I>Basic</I>, <I>Standard</I>, <I>Premium</I>, <I>Consumption</I>.<br><br>


title: DESCRIPTION
content:
The <I>az apim</I> command group is part of the Azure Command-Line Interface (CLI), a cross-platform command-line tool for connecting to and managing Azure resources. While the query specified "az-apim", the standard Azure CLI command for API Management is <I>az apim</I> (without the hyphen).<br><br>Azure API Management (APIM) is a fully managed service that enables organizations to publish, secure, transform, maintain, and monitor APIs. The <I>az apim</I> command group provides a comprehensive set of commands for programmatic interaction with this service. Users can create, update, delete, and manage various APIM entities, including:<br><ul><li>APIM service instances</li><li>APIs and API operations</li><li>Products, subscriptions, and users</li><li>Policies (inbound/outbound processing rules)</li><li>Gateways and custom domains</li></ul>This command group is invaluable for automating API Management deployments, integrating with CI/CD pipelines, and scripting complex management tasks, significantly enhancing operational efficiency for organizations utilizing Azure API Management.


title: CAVEATS
content:
<ul><li><b>Azure CLI Installation Required:</b> The <I>az apim</I> command group is part of the Azure CLI. It must be installed on your system to be used.</li><li><b>Authentication:</b> Before executing commands, you must authenticate to Azure using <I>az login</I>.</li><li><b>Internet Connectivity:</b> Commands interact with Azure cloud services and require an active internet connection.</li><li><b>Typographical Note:</b> The prompt specified "az-apim"; however, the correct and commonly used command group in Azure CLI is <I>az apim</I> (without the hyphen).</li><li><b>Extensive Parameters:</b> Azure CLI commands, especially within complex service groups like APIM, can have a very large number of parameters. The list provided here covers common and global parameters; specific subcommands will have their own unique parameters. Refer to <I>az apim <subcommand> --help</I> for detailed options.</li></ul>


title: AUTHENTICATION AND CONTEXT
content:
To use <I>az apim</I> commands, first log in using <I>az login</I>. You can also set a default subscription (<I>az account set -s <subscription-id></I>) and resource group (<I>az configure --defaults group=<resource-group-name></I>) to simplify command execution, avoiding the need to specify them with every command.


title: JSON OUTPUT AND SCRIPTING
content:
The default JSON output format for <I>az apim</I> commands makes them highly suitable for scripting and automation. Tools like <I>jq</I> (a lightweight and flexible command-line JSON processor) can be used in conjunction with <I>az apim</I> to parse and manipulate the command output for advanced automation scenarios.


title: HISTORY
content:
The Azure CLI, initially released in 2014, has evolved significantly as Microsoft's primary command-line tool for managing Azure resources. The <I>az apim</I> command group was introduced to support the growing capabilities of Azure API Management, providing a consistent and scriptable interface for cloud operations. Its development is closely tied to the lifecycle and feature enhancements of the Azure API Management service itself, enabling DevOps practices and automation for API infrastructure management.


title: SYNOPSIS
content:
<br><b><I>az appconfig</I></b> <I>command</I> <I>[parameters]</I><br><br>This command is a group of subcommands for managing Azure App Configuration. To see available subcommands, use <b><I>az appconfig --help</I></b>. To see parameters for a specific subcommand, use <b><I>az appconfig <I>command</I> --help</I></b>.


title: PARAMETERS
content:
<b>--name <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The name of the App Configuration store. Applicable to store-level commands like create, show, delete.</I><br><br><b>--resource-group <GROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Name of the resource group the App Configuration store belongs to.</I><br><br><b>--connection-string <STRING></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Connection string of the App Configuration store. Used for authentication when not relying on Azure Active Directory (AAD).</I><br><br><b>--key <KEY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Key of the key-value pair. Used with `kv` subcommands for managing key-values.</I><br><br><b>--value <VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Value of the key-value pair. Used with `kv` subcommands when setting or updating key-values.</I><br><br><b>--label <LABEL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Label of the key-value or feature flag. Used to create distinct versions of configurations (e.g., 'Dev', 'Prod').</I><br><br><b>--feature-name <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Name of the feature flag. Used with `feature` subcommands for managing feature flags.</I><br><br><b>--yes | -y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not prompt for confirmation. Useful for scripting destructive operations.</I><br><br><b>--output <FORMAT> | -o <FORMAT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Output format (e.g., json, jsonc, table, tsv, yaml, yamlc, none). Specifies how the command's results are displayed.</I><br><br><b>--query <JMESPATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>JMESPath query string for filtering the output. Allows precise extraction of data from JSON output.</I><br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Increase logging verbosity to show all debug logs, aiding in troubleshooting.</I><br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Increase logging verbosity to show more information during command execution.</I><br><br><b>--help | -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show help message for the command or subcommand and exit.</I><br><br>


title: DESCRIPTION
content:
The `az appconfig` command group is an integral part of the Azure Command-Line Interface (Azure CLI), a powerful cross-platform toolset for managing Azure resources. Specifically, `az appconfig` provides comprehensive functionalities for interacting with and managing Azure App Configuration stores.<br><br>Azure App Configuration is a centralized service designed to store and manage application settings and feature flags. It enables developers to externalize configuration data from their code and manage it dynamically, supporting operations such as setting up and tearing down configuration stores, retrieving and updating key-value pairs, managing feature flags, and handling configurations with labels for different environments or versions.<br><br>This command group is essential for automating administrative tasks, integrating configuration management into CI/CD pipelines, and providing a programmatic interface for managing application settings, making it suitable for modern cloud-native applications as well as traditional applications migrating to the cloud.


title: CAVEATS
content:
<br>1. This command is part of the Azure CLI, not a standard Linux utility. It requires the Azure CLI to be installed and configured on your system.<br>2. An active Azure subscription and an authenticated Azure account are necessary to interact with Azure App Configuration resources.<br>3. Specific parameters and their usage can vary significantly depending on the subcommand used (e.g., `kv`, `feature`, `replica`). Always refer to the `--help` output for the specific subcommand you are using for the most accurate and complete list of options.<br>4. Network connectivity to Azure services is required for its operation.


title: KEY CONCEPTS
content:
<br>Azure App Configuration manages two primary types of data: key-value pairs (for general application settings) and feature flags (for dynamically enabling/disabling features). The `az appconfig kv` and `az appconfig feature` subcommands are specifically designed for managing these respective data types.


title: INTEGRATION WITH APPLICATIONS
content:
<br>While `az appconfig` is used for administrative tasks, applications typically consume settings from Azure App Configuration using dedicated client SDKs available for various programming languages (e.g., .NET, Java, Python, JavaScript). These SDKs handle caching, refresh, and connection details, abstracting the underlying configuration store.


title: HISTORY
content:
Azure App Configuration was introduced as a public preview service in 2019, providing a modern, centralized service for managing application settings and feature flags. The `az appconfig` command group was developed as part of the Azure CLI's continuous evolution to support new Azure services and features. Its inclusion allowed developers and operations teams to automate the management of their configuration stores directly from the command line or scripts, aligning with the broader Azure CLI philosophy of providing a consistent and intuitive command-line experience across all Azure services.


title: SEE ALSO
content:
az account (Azure CLI command for managing Azure subscriptions), az group (Azure CLI command for managing Azure resource groups), az login (Azure CLI command for authenticating to Azure)


title: SYNOPSIS
content:
<b>az bicep</b> <<i>subcommand</i>> [<i>options</i>]<br><br>Examples:<br>  <i>Compile a Bicep file:</i><br>  <b>az bicep build --file</b> <i>main.bicep</i><br><br>  <i>Install the Bicep CLI:</i><br>  <b>az bicep install</b>


title: PARAMETERS
content:
<b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles a Bicep file into an Azure Resource Manager (ARM) template.<br><br><b>decompile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompiles an existing ARM template JSON file back into a Bicep file.<br><br><b>generate-params</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a parameter file (e.g., JSON or bicepparam) for a Bicep file based on its declared parameters.<br><br><b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs the Bicep CLI for use with the Azure CLI.<br><br><b>list-versions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available Bicep CLI versions that can be installed.<br><br><b>publish</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes a Bicep module to an Azure container registry or a Bicep private registry for reuse.<br><br><b>restore</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores external modules referenced in a Bicep file by downloading them to a local cache.<br><br><b>uninstall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls the Bicep CLI from your system.<br><br><b>upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades the Bicep CLI to the latest available version.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed Bicep CLI version.<br><br>


title: DESCRIPTION
content:
The <b>az bicep</b> command group is an integral part of the Azure Command-Line Interface (Azure CLI), designed to facilitate interactions with Bicep files. Bicep is a declarative domain-specific language (DSL) developed by Microsoft for deploying Azure resources. It offers a more readable and concise syntax compared to traditional Azure Resource Manager (ARM) templates, simplifying Infrastructure as Code (IaC) practices.<br><br>This command group provides a comprehensive set of functionalities, including compiling Bicep files into deployable ARM templates, decompiling existing ARM templates back into Bicep for easier modification, managing Bicep CLI installations (install, upgrade, uninstall), and publishing Bicep modules to container registries for sharing and reuse. It's an indispensable tool for Azure developers and DevOps professionals, streamlining the entire lifecycle of infrastructure deployment and management through code.


title: CAVEATS
content:
The command syntax is <b>az bicep</b>, where 'bicep' is a subcommand of the main 'az' (Azure CLI) command, not a standalone 'az-bicep' executable. This command group requires the Azure CLI to be installed and configured on your system. Some operations, particularly those involving publishing or deploying resources, may require an active Azure subscription and appropriate permissions.


title: BICEP MODULES
content:
Bicep supports modularity, allowing users to encapsulate reusable infrastructure components into separate Bicep files called modules. These modules can be referenced from other Bicep files, promoting code reuse and simplifying complex deployments. The <b>az bicep publish</b> command is crucial for sharing these modules by publishing them to container registries, making them accessible across teams and projects.


title: HISTORY
content:
Bicep was introduced by Microsoft as an open-source project to address the complexities of ARM templates, offering a more user-friendly syntax. The <b>az bicep</b> commands were integrated into the Azure CLI to provide native support for Bicep development. This integration has evolved significantly since Bicep's initial preview, moving towards general availability and becoming the recommended way to manage Azure infrastructure declaratively through code.


title: SYNOPSIS
content:
<b>az config</b> {<i>show</i> | <i>set</i> | <i>get</i> | <i>unset</i> | <i>param-group</i>} [<i>options</i>]


title: PARAMETERS
content:
<b><b>show</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the entire active Azure CLI configuration, showing settings from all loaded scopes (global, local, environment variables).<br><br><b><b>set</b> <i>&lt;key&gt;=&lt;value&gt; [&lt;key&gt;=&lt;value&gt; ...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets one or more configuration properties. For example, <i>az config set core.output=jsonc</i>. This command can be used to define defaults for output format, subscription, and more.<br><br><b><b>get</b> <i>[&lt;key&gt; [&lt;key&gt; ...]]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the value of one or more specified configuration properties. If no <i>&lt;key&gt;</i> is provided, it displays all currently set values. Example: <i>az config get core.output</i>.<br><br><b><b>unset</b> <i>&lt;key&gt; [&lt;key&gt; ...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more configuration properties from the active configuration. Example: <i>az config unset core.output</i>. Unsetting a local value will revert to the global or system default if one exists.<br><br><b><b>param-group</b> <i>{command} [options]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages parameter groups for CLI commands. This advanced feature allows users to define groups of parameters to be automatically applied to specific Azure CLI commands.<br><br><b><i>--local</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the configuration change to the local project scope, saving it in a <i>.azure/config</i> file within the current working directory. These settings take precedence over global settings for commands run in that directory.<br><br><b><i>--help</i>, <i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <i>az config</i> command or its subcommands.<br><br>


title: DESCRIPTION
content:
The <i>az config</i> command is an essential component of the Azure Command-Line Interface (CLI), a powerful, cross-platform tool used for managing Azure resources. While not a standalone Linux executable, it serves as a crucial subcommand within the Azure CLI. Its primary purpose is to allow users to efficiently view, set, retrieve, and delete configuration settings that control the behavior of the Azure CLI itself. These configurable aspects include, but are not limited to, default output formats, preferred Azure subscriptions, default resource locations, logging verbosity, and confirmation prompts for destructive actions. By leveraging <i>az config</i>, users can personalize their CLI experience, streamline their workflows, and reduce the need to repeatedly specify common parameters in their Azure commands, thereby enhancing productivity and consistency across their cloud operations. It centralizes the management of both global and project-specific CLI configurations.


title: CAVEATS
content:
The <i>az config</i> command is a subcommand of the Azure CLI (<i>az</i>), meaning it must be invoked through <i>az config</i> and requires the Azure CLI to be installed on your system. It is not a standalone Linux executable. Configuration settings are loaded hierarchically, with command-line parameters always taking precedence over configured defaults. Sensitive information, such as credentials, should generally not be stored directly in plain text configuration files; use secure methods like environment variables or Azure Key Vault for such data.


title: CONFIGURATION HIERARCHY
content:
Azure CLI loads configuration settings from multiple locations in a specific order of precedence. Settings from later sources override earlier ones:<br>1. Global configuration file (e.g., <i>~/.azure/config</i> on Linux/macOS, <i>%USERPROFILE%\az.azure\config</i> on Windows)<br>2. Local configuration file (<i>.azure/config</i> in the current working directory)<br>3. Environment variables (e.g., <i>AZURE_CORE_OUTPUT</i>)<br>4. Command-line parameters<br>For example, a setting in a local configuration file will override the same setting defined in the global file.


title: COMMON CONFIGURATION KEYS
content:
Some frequently utilized configuration keys that can be managed with <i>az config</i> include:<br><i><b>core.output</b></i>: Specifies the default output format (e.g., <i>json</i>, <i>jsonc</i>, <i>table</i>, <i>tsv</i>, <i>yaml</i>, <i>none</i>).<br><i><b>core.no_confirm</b></i>: A boolean flag; if <i>True</i>, it disables confirmation prompts for destructive operations.<br><i><b>core.subscription</b></i>: Sets the default Azure subscription ID or name to be used for commands.<br><i><b>core.cloud</b></i>: Defines the default Azure cloud instance (e.g., <i>AzureCloud</i>, <i>AzureUSGovernment</i>).<br><i><b>logging.level</b></i>: Controls the verbosity of logging (e.g., <i>info</i>, <i>debug</i>, <i>warning</i>, <i>error</i>).<br><i><b>telemetry.enable_telemetry</b></i>: A boolean flag that controls whether usage data is sent to Microsoft (default is <i>True</i>).


title: HISTORY
content:
The Azure Command-Line Interface was initially released in 2016. The <i>az config</i> command has been a fundamental part of the Azure CLI since its early versions, providing users with essential capabilities to customize their command-line environment for Azure. Over time, it has evolved to incorporate features such as local configuration scoping and the management of parameter groups, continually enhancing the flexibility and user-friendliness of the Azure CLI experience.


title: SYNOPSIS
content:
<b>Usage:</b><br>az devops <i>&lt;command-group&gt; &lt;subcommand&gt; [options]</i><br><br>This command acts as a root for a large set of subcommands. For example:<br><i>az devops project list</i><br><i>az devops configure --defaults organization=https://dev.azure.com/myorg project=myproject</i><br><i>az devops pipelines build queue --definition-id 123 --branch main</i>


title: PARAMETERS
content:
<b><i>&lt;command-group&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Represents the specific service area within Azure DevOps you wish to manage. Common groups include <b>project</b> (for managing projects), <b>repos</b> (for managing Git repositories), <b>pipelines</b> (for managing build/release pipelines), <b>boards</b> (for managing work items), <b>artifacts</b> (for managing packages), <b>security</b> (for managing permissions), and <b>configure</b> (for setting defaults). Each group has its own set of <i>&lt;subcommands&gt;</i> and <i>[options]</i>.<br><br><b><i>&lt;subcommand&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific action to perform within a <i>&lt;command-group&gt;</i>. For instance, under the <b>project</b> group, you might use <i>create</i>, <i>list</i>, <i>show</i>, or <i>delete</i>. The available <i>&lt;subcommands&gt;</i> and their specific <i>[options]</i> vary widely depending on the chosen <i>&lt;command-group&gt;</i>.<br><br><b>[--help]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed help for the command, a subcommand, or a command group, showing available options and examples.<br><br><b>[--output {json, jsonc, table, tsv, yaml, yamlc, none}]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format of the command results. This is a common global Azure CLI option.<br><br><b>[--query]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A JMESPath query string used to filter or transform the command output, allowing for precise data extraction. This is a common global Azure CLI option.<br><br><b>[--verbose]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show more detailed information, useful for debugging. This is a common global Azure CLI option.<br><br><b>[--debug]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables even higher logging verbosity than <i>--verbose</i>, providing all debug logs for in-depth troubleshooting. This is a common global Azure CLI option.<br><br>


title: DESCRIPTION
content:
The <b>az devops</b> command is an <i>extension</i> to the Azure Command-Line Interface (Azure CLI) specifically designed to interact with and manage Azure DevOps services. It provides a comprehensive set of functionalities for automating tasks related to source control (Azure Repos), continuous integration and continuous delivery (Azure Pipelines), agile planning (Azure Boards), package management (Azure Artifacts), and test management (Azure Test Plans). Users can perform a wide array of operations such as creating and managing projects, configuring complex build and release pipelines, managing work items and sprints, handling Git repositories and pull requests, and administering organization and project-level settings. This direct command-line interface enables powerful scripting, integration with CI/CD workflows, and consistent automation of DevOps practices across various environments.


title: CAVEATS
content:
The <b>az devops</b> command is an <i>extension</i> to the core Azure CLI. It is not installed by default and must be added separately using the command: <i>az extension add --name azure-devops</i>.<br>Users must be authenticated with Azure (e.g., via <i>az login</i>) and possess appropriate permissions within the specific Azure DevOps organization and project to perform desired operations.<br>The command syntax can be quite detailed due to the nested nature of subcommands and numerous service-specific options, often requiring familiarity with both Azure CLI conventions and Azure DevOps concepts.


title: AUTHENTICATION
content:
To utilize <b>az devops</b> commands, you first need to authenticate your Azure CLI session. This is typically done interactively via <i>az login</i>, which prompts you to open a browser for sign-in. Once authenticated, the CLI uses your Azure identity to securely interact with Azure DevOps services, respecting your assigned permissions and access levels.


title: CONFIGURATION DEFAULTS
content:
For convenience, you can set default values for your Azure DevOps organization and project using the command <i>az devops configure --defaults organization=&lt;URL&gt; project=&lt;Name&gt;</i>. This significantly shortens subsequent commands by eliminating the need to specify these common parameters repeatedly, making your scripts cleaner and easier to use.


title: SCRIPTING AND AUTOMATION
content:
The command-line interface makes <b>az devops</b> an invaluable tool for scripting and automating repetitive administrative and operational tasks within Azure DevOps. It is commonly integrated into CI/CD pipelines, pre-commit hooks, or custom management scripts to streamline development, deployment, and operational workflows, fostering consistent and repeatable DevOps practices.


title: HISTORY
content:
Azure DevOps services have a rich history evolving from Microsoft's on-premises offerings like Visual Studio Team System (VSTS) and Team Foundation Server (TFS). The cloud-based counterpart, initially known as Visual Studio Team Services (VSTS), was rebranded to Azure DevOps in 2018, consolidating various developer services. Concurrently, the Azure CLI, Microsoft's cross-platform command-line tool, introduced an extensibility model. The <b>azure-devops</b> extension was subsequently developed to provide a native command-line interface for managing these consolidated services, aligning with the growing emphasis on automation and DevOps practices in cloud environments. Its ongoing development reflects new features and capabilities introduced to the Azure DevOps platform.


title: SEE ALSO
content:
az (1) <br><i>(The main Azure CLI command, providing access to all Azure services)</i>, git (1) <br><i>(Distributed version control system, fundamental for Azure Repos and source control)</i>, terraform (1) <br><i>(Infrastructure as Code tool, frequently integrated with Azure DevOps Pipelines for deployment)</i>, docker (1) <br><i>(Containerization platform, widely used in CI/CD pipelines to build and deploy applications)</i>, kubectl (1) <br><i>(Command-line tool for controlling Kubernetes clusters, often used in conjunction with pipelines for Kubernetes deployments)</i>


title: SYNOPSIS
content:
<b>az disk</b> <<i>SUBCOMMAND</i>> [<i>OPTIONS</i>]<br><br>Common subcommands include:<br><b>az disk create</b>: Create a managed disk.<br><b>az disk delete</b>: Delete a managed disk.<br><b>az disk list</b>: List managed disks.<br><b>az disk show</b>: Get the details of a managed disk.<br><b>az disk update</b>: Update a managed disk.<br><b>az disk grant-access</b>: Grant access to a managed disk or a snapshot for specific operations (e.g., data copy).<br><b>az disk revoke-access</b>: Revoke access to a managed disk or a snapshot.


title: PARAMETERS
content:
<b>--name -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the disk. Used with create, delete, show, update.<br><br><b>--resource-group -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the resource group the disk belongs to or will be created in.<br><br><b>--location -l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Azure region where the disk will be created (e.g., eastus, westus2).<br><br><b>--size-gb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Size of the disk in GiB (Gigabytes).<br><br><b>--sku</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disk SKU or performance tier (e.g., <i>Standard_LRS</i>, <i>Premium_LRS</i>, <i>UltraSSD_LRS</i>).<br><br><b>--os-type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Type of OS the disk is intended for (<i>Linux</i> or <i>Windows</i>).<br><br><b>--source</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resource ID of a snapshot, image, or another disk to create this disk from.<br><br><b>--encryption-type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Type of encryption to apply to the disk (e.g., <i>EncryptionAtRestWithPlatformKey</i>, <i>EncryptionAtRestWithCustomerKey</i>).<br><br><b>--tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated tags in 'key=value' format to apply to the disk.<br><br><b>--output -o</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format of the command (e.g., <i>json</i>, <i>table</i>, <i>tsv</i>, <i>yaml</i>).<br><br><b>--query</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter or transform the command output.<br><br>


title: DESCRIPTION
content:
The command <b>az-disk</b> is not a standard Linux command found in typical distributions. It is highly probable that the intended command is <b>az disk</b>, which is a core subcommand within the <i>Azure Command-Line Interface (Azure CLI)</i>. This analysis focuses on <b>az disk</b>, a powerful tool for managing Azure managed disks. Azure managed disks are block-level storage volumes used with Azure Virtual Machines, fully managed by Azure. The <b>az disk</b> command provides functionalities to create, delete, list, show details, update, and manage various aspects of these disks, including their size, performance tiers (SKUs), encryption settings, and associated snapshots. It facilitates automation and scripting of disk operations within the Azure cloud environment, allowing users to provision and configure storage for their virtual machines and other Azure services programmatically. It's an essential tool for cloud administrators and developers working with Azure infrastructure.


title: CAVEATS
content:
<ul><li>The <b>az disk</b> command requires the <i>Azure CLI</i> to be installed and properly configured on your system.</li><li>An active Azure subscription and authenticated session (using <b>az login</b>) are necessary to perform operations.</li><li>Disk creation and management operations incur costs based on Azure's pricing for managed disks and associated resources.</li><li>Users must have appropriate Azure RBAC (Role-Based Access Control) permissions to manage disks within a given subscription or resource group.</li><li>Operations can be resource-intensive and may take time to complete, especially for large disks or complex tasks.</li></ul>


title: INSTALLATION AND AUTHENTICATION
content:
To use <b>az disk</b>, first install the <i>Azure CLI</i>. Instructions are available on Microsoft's Azure documentation website for various operating systems. After installation, authenticate your session using <b>az login</b>, which will open a browser for Azure credential verification. This step is crucial for the CLI to interact with your Azure subscription.


title: RESOURCE GROUPS
content:
All Azure resources, including disks, are deployed into <i>Resource Groups</i>. It is a best practice to organize related resources into the same resource group for easier management, billing, and lifecycle operations. Many <b>az disk</b> commands require specifying the resource group using the <b>--resource-group</b> or <b>-g</b> option.


title: HISTORY
content:
The <i>Azure CLI</i>, which includes the <b>az disk</b> command set, was first introduced in 2015 as a cross-platform tool for managing Azure resources. Since its inception, the <b>az disk</b> command has continuously evolved to support new features and capabilities of Azure Managed Disks, which became generally available in 2017. Significant developments include support for various disk SKUs (Standard HDD/SSD, Premium SSD, Ultra SSD), encryption options (platform-managed keys, customer-managed keys), disk resizing, and advanced access controls. It has become a foundational component for automating infrastructure-as-code deployments and operational tasks involving persistent storage in Azure.


title: SEE ALSO
content:
<b>az vm</b>: Manages Azure Virtual Machines, which frequently use Azure disks., <b>az snapshot</b>: Manages Azure disk snapshots, often used as sources for new disks or for backup., <b>az group</b>: Manages Azure resource groups, which are logical containers for Azure resources including disks., <b>az network</b>: Manages Azure networking components, related to how VMs (and thus disks) connect within Azure., <br><i>Note: These are Azure CLI commands and do not have traditional Linux manual ('man') sections.</i>


title: DESCRIPTION
content:
<i>az-feedback</i> (or more accurately, <i><b>az feedback</b></i>) is a utility command within the Azure CLI suite designed to facilitate direct user feedback to Microsoft. When invoked, it automatically launches your default web browser and navigates to a designated feedback page on the Azure documentation or support portal.<br>This page typically provides a form or direct links for users to submit suggestions, bug reports, feature requests, or general comments regarding the Azure Command-Line Interface. It serves as a streamlined method for Azure CLI users to contribute to the improvement and development of the tool.<br>Unlike many CLI commands, <i>az-feedback</i> does not process command-line arguments for the feedback content itself but rather acts as a shortcut to the online feedback mechanism. It requires an active internet connection and a configured web browser to function correctly.


title: CAVEATS
content:
<b>az-feedback</b> requires an active internet connection to access the online feedback portal. <br>It also requires a default web browser to be configured on your system, as it will automatically attempt to open the feedback URL in your browser. <br>The command does not accept direct feedback content via command-line arguments; all feedback must be submitted through the web form that opens. <br>While the prompt refers to <b>az-feedback</b>, it's commonly invoked as a sub-command: <b>az feedback</b> within the Azure CLI.


title: USAGE CONTEXT
content:
The command named <b>az-feedback</b> is typically a symbolic link or wrapper for the <b>az feedback</b> sub-command within the Azure Command-Line Interface. This means you would generally type <b>az feedback</b> in your terminal after installing the Azure CLI, rather than <b>az-feedback</b> directly, unless your system has a specific alias or script set up.


title: HISTORY
content:
The <b>az feedback</b> command (which <b>az-feedback</b> typically refers to) has been an integral part of the Azure CLI since its early versions.<br>It was introduced to provide a direct and convenient channel for users to submit feedback, report issues, and suggest improvements for the CLI tool. This mechanism reflects Microsoft's commitment to user-driven development and continuous improvement of its cloud management tools.<br>Its functionality has remained consistent, primarily acting as a launcher for the web-based feedback form.


title: SYNOPSIS
content:
<b>az group</b> <i>&lt;subcommand&gt;</i> [<i>&lt;global-options&gt;</i>]<br><br><i>Subcommands and their common usage:</i><br><b>az group create</b> <i>--name &lt;resource-group-name&gt; --location &lt;region&gt;</i> [<i>--tags &lt;key=value&gt;...</i>]<br><b>az group delete</b> <i>--name &lt;resource-group-name&gt;</i> [<i>--no-wait</i>] [<i>--yes</i>]<br><b>az group list</b> [<i>--tag &lt;key[=value]&gt;</i>]<br><b>az group show</b> <i>--name &lt;resource-group-name&gt;</i>


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or subcommand.<br><br><b><b>--output</b>, <b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., json, jsonc, table, tsv, yaml, yamlc). Default is json.<br><br><b><b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a JMESPath query string to filter or transform the command output.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging, showing all debug logs for troubleshooting.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show more information.<br><br><b><b>--only-show-errors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warnings and only shows error messages.<br><br><b><b>--subscription</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Azure subscription name or ID to operate on. Overrides the default subscription.<br><br><b><b>--name</b>, <b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Subcommand-specific)</i> Specifies the name of the resource group to operate on. Required for most subcommands like create, delete, show, update, and exists.<br><br><b><b>--location</b>, <b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Subcommand-specific, for `create`)</i> Specifies the Azure region (e.g., 'eastus', 'westus2') where the new resource group should be created.<br><br><b><b>--tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Subcommand-specific, for `create`, `update`)</i> Space-separated tags in `key[=value]` format to apply to the resource group. Used for categorization and billing.<br><br><b><b>--no-wait</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Subcommand-specific, for `delete`)</i> Do not wait for the long-running deletion operation to finish; return immediately.<br><br><b><b>--yes</b>, <b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Subcommand-specific, for `delete`)</i> Do not prompt for confirmation before proceeding with the deletion.<br><br>


title: DESCRIPTION
content:
The <b>az group</b> command is a core component of the Azure Command-Line Interface (Azure CLI), designed for comprehensive management of Azure resource groups. Resource groups are logical containers that hold related resources for an Azure solution. This command allows users to perform various operations such as creating new resource groups, deleting existing ones, listing all resource groups within a subscription, retrieving details of a specific group, and updating their properties. It's essential for organizing and managing the lifecycle of Azure resources efficiently. Operations like <i>create</i>, <i>delete</i>, <i>list</i>, <i>show</i>, <i>update</i>, <i>exists</i>, and <i>wait</i> are available to facilitate robust resource group management.


title: CAVEATS
content:
The <b>az group</b> command requires the Azure CLI to be installed and configured on the system. User authentication to an Azure subscription is mandatory to perform any operations. Deleting a resource group is a highly destructive operation as it irrevocably deletes all resources contained within it. Resource group names must be unique within a subscription and adhere to Azure naming conventions, including length and allowed characters.


title: RESOURCE GROUP CONCEPT
content:
In Azure, a resource group is a logical container into which Azure resources (e.g., web apps, databases, storage accounts, virtual machines) are deployed and managed. Resource groups provide a way to organize related resources, manage their lifecycle (e.g., deployment, updates, deletion) as a single unit, and apply access control using Azure Role-Based Access Control (RBAC). This organizational structure is crucial for effective cloud resource management, cost tracking, and security.


title: REQUIRED PERMISSIONS
content:
To effectively manage resource groups using the <b>az group</b> command, the authenticated Azure identity (user or service principal) typically requires specific Azure Role-Based Access Control (RBAC) permissions. Roles such as 'Contributor' or 'Owner' at the subscription level provide broad management capabilities. For more granular control, roles like 'Resource Group Contributor' can be assigned to manage resource groups themselves, while separate permissions might be needed for the resources within those groups depending on inheritance and specific requirements.


title: HISTORY
content:
Azure CLI underwent a significant architectural redesign and re-release as the 'az' CLI in 2017, succeeding the older 'azure' Xplat CLI. The <b>az group</b> command has been a fundamental and indispensable part of the Azure CLI since its modern incarnation, providing essential resource management capabilities. Its functionality has continuously evolved in tandem with Azure's services, incorporating new features like advanced tagging, managed identities integration, and improved resource organization paradigms.


title: SYNOPSIS
content:
az image <I>subcommand</I> [options]<br><br>Example: az image create --resource-group <I>myResourceGroup</I> --name <I>myCustomImage</I> --source <I>mySourceVM</I><br>Example: az image list --output <I>table</I>


title: PARAMETERS
content:
<b>--resource-group | -g <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the Azure resource group. Determines the scope for image creation and management.<br><br><b>--name | -n <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the custom image being created, shown, or deleted.<br><br><b>--source <I>id | name | URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The source from which to create the image. Can be a VM name, VM ID, disk ID, snapshot ID, or blob URI.<br><br><b>--location | -l <I>location</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Location in which to create the image (e.g., 'eastus', 'westus2'). Defaults to the resource group's location.<br><br><b>--os-type <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The operating system type of the image (e.g., 'Linux', 'Windows').<br><br><b>--hyper-v-generation <I>generation</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Hyper-V generation of the image (e.g., 'V1', 'V2').<br><br><b>--gallery-name <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the Azure Compute Gallery to store the image in.<br><br><b>--gallery-image-definition <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the gallery image definition, required when using a gallery.<br><br><b>--tags <I>key=value key=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated tags in 'key[=value]' format to apply to the image resource.<br><br><b>--subscription <I>id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ID or name of the Azure subscription to use. Overrides the default or configured subscription.<br><br><b>--output | -o <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format (e.g., 'json', 'jsonc', 'table', 'tsv', 'yaml', 'none').<br><br><b>--query <I>jmespath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string. See http://jmespath.org/ for more information and examples.<br><br><b>--help | -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the command or subcommand.<br><br>


title: DESCRIPTION
content:
The command <b>az-image</b> is <I>not</I> a standalone Linux command. Instead, it is commonly used as a shorthand reference to the <I>az image</I> command group within the <I>Azure Command-Line Interface (Azure CLI)</I>.<br><br>The <I>az image</I> command group is primarily designed for managing <I>custom virtual machine (VM) images</I> within Microsoft Azure. These images serve as templates for creating multiple VMs with identical configurations, significantly streamlining deployments and ensuring consistency. It supports operations such as creating new images from existing VMs, snapshots, or managed disks; deleting unwanted images; listing available images; and viewing detailed information about specific images. This functionality is crucial for infrastructure-as-code practices, DevOps workflows, and maintaining standardized environments across an organization's Azure infrastructure. <br><br>The <I>az image</I> commands also interact seamlessly with <I>Azure Compute Galleries</I> (formerly Shared Image Galleries), enabling centralized management and sharing of custom images across different subscriptions, regions, and tenants.


title: CAVEATS
content:
The command 'az-image' is <I>not</I> a standalone executable. It refers to the 'az image' command group within the Azure CLI. Therefore, its functionality is dependent on the <I>Azure CLI being installed</I> and <I>properly configured</I> (e.g., logged in to an Azure account with appropriate permissions). <br><br>When creating a custom image from a VM for multi-instance deployment, the source VM <I>must be generalized</I> first (e.g., using Sysprep on Windows or waagent -deprovision+user on Linux) to remove machine-specific identifiers. Failure to do so can lead to deployment issues.


title: IMAGE TYPES DISTINCTION
content:
It's important to distinguish between <I>custom images</I> (managed by `az image`) and <I>marketplace images</I> (managed by `az vm image`). Custom images are user-defined templates, often derived from existing VMs, used for tailored deployments. Marketplace images are pre-built, generalized images provided by Microsoft or third-party vendors, available for direct use from the Azure Marketplace.


title: GENERALIZATION REQUIREMENT
content:
For a custom image to be reusable for creating multiple identical virtual machines, the source VM must be <I>generalized</I> before the image is captured. Generalization removes unique machine-specific information (like SIDs on Windows or SSH host keys on Linux) to prevent conflicts when deploying new VMs from the same image. If a VM is not generalized, the image can only be used to create an exact replica of the original VM, not a new, independent instance.


title: AZURE COMPUTE GALLERY (ACG) INTEGRATION
content:
The `az image` command group strongly integrates with <I>Azure Compute Gallery</I> (ACG). ACG provides a structured way to manage, share, and distribute custom images. It allows for versioning of images, replicating images to different Azure regions, and sharing them with other Azure subscriptions or tenants. Using `az image` with an ACG is the recommended practice for professional image management in Azure.


title: HISTORY
content:
The Azure CLI, providing the `az image` command group, has undergone continuous development since its initial releases. Earlier versions of Azure CLI offered similar capabilities for creating and managing custom VM images. A significant enhancement came with the introduction of <I>Shared Image Galleries</I> (later renamed to <I>Azure Compute Galleries</I>). This feature greatly improved the way images are managed, versioned, and shared across different subscriptions and regions, making the `az image` command group even more powerful and integral to enterprise-scale deployments. Its evolution reflects Azure's commitment to enabling robust and automated infrastructure management through command-line tools.


title: SEE ALSO
content:
az(1): The main Azure CLI command for managing Azure resources., az vm(1): Commands for managing Azure virtual machines, including creation from images., az vm image(1): Used for listing and showing details of marketplace VM images., az disk(1): Commands for managing Azure managed disks, which can serve as sources for custom images.


title: SYNOPSIS
content:
Since `az-lock` is not a standalone command, here are the common synopses for managing Azure locks using the `az` CLI:<br><br><i><b>Creating a lock:</b></i><br>`az lock create --name <<i>lock_name</i>> --resource-group <<i>group_name</i>> --lock-type {<i>CanNotDelete</i>|<i>ReadOnly</i>} [--notes <<i>notes</i>>]`<br>`az lock create --name <<i>lock_name</i>> --resource <<i>resource_name</i>> --resource-group <<i>group_name</i>> --namespace <<i>provider_namespace</i>> --parent <<i>parent_resource_path</i>> --resource-type <<i>resource_type</i>> --lock-type {<i>CanNotDelete</i>|<i>ReadOnly</i>}`<br>`az lock create --name <<i>lock_name</i>> --subscription <<i>subscription_id</i>> --lock-type {<i>CanNotDelete</i>|<i>ReadOnly</i>}`<br><br><i><b>Deleting a lock:</b></i><br>`az lock delete --name <<i>lock_name</i>> [--resource-group <<i>group_name</i>> | --resource <<i>resource_name</i>>]`<br>`az lock delete --ids <<i>lock_id</i>>`<br><br><i><b>Listing locks:</b></i><br>`az lock list [--resource-group <<i>group_name</i>> | --resource <<i>resource_name</i>> | --subscription <<i>subscription_id</i>>]`<br><br><i><b>Showing a lock:</b></i><br>`az lock show [--name <<i>lock_name</i>> --resource-group <<i>group_name</i>>] | --ids <<i>lock_id</i>>`


title: PARAMETERS
content:
<b>--name <<i>lock_name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Name of the lock.</i><br><br><b>--lock-type {CanNotDelete|ReadOnly}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Type of lock. <b>CanNotDelete</b> prevents deletion. <b>ReadOnly</b> prevents deletion and modification.</i><br><br><b>--resource-group <<i>group_name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Name of the resource group to apply the lock to.</i><br><br><b>--resource <<i>resource_name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Name of the specific resource to apply the lock to.</i><br><br><b>--namespace <<i>provider_namespace</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Resource provider namespace (e.g., 'Microsoft.Compute'). Required for resource-level locks.</i><br><br><b>--parent <<i>parent_resource_path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The parent path if the resource is a nested resource (e.g., 'virtualMachines/myVM').</i><br><br><b>--resource-type <<i>resource_type</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Type of the resource (e.g., 'virtualMachines').</i><br><br><b>--subscription <<i>subscription_id</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ID of the subscription to apply the lock to.</i><br><br><b>--notes <<i>notes</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional text notes about the lock.</i><br><br><b>--ids <<i>lock_id</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>One or more resource IDs (space-separated) of the locks to target.</i><br><br>


title: DESCRIPTION
content:
The term <i>az-lock</i> does not refer to a standard, standalone Linux command. Instead, it typically refers to the management of <i>Azure resource locks</i> using the <i>Azure Command-Line Interface (Azure CLI)</i>, which is often installed and used on Linux systems.<br><br>Azure resource locks are a feature within Microsoft Azure that prevents users from accidentally deleting or modifying critical resources (like virtual machines, databases, or resource groups). These locks apply across all users and roles and are enforced at the management plane level, not at the operating system level.<br><br>While `az-lock` itself is not a command, operations to create, delete, list, or show Azure locks are performed using subcommands under the `az lock` umbrella within the Azure CLI. A user might potentially create an alias or a script named `az-lock` on their Linux system to simplify specific Azure locking operations.


title: CAVEATS
content:
`az-lock` is <i>not</i> a native, standalone Linux command. It refers to functionalities primarily provided by the <i>Azure CLI</i> to manage Azure resource locks. To use these functionalities, the Azure CLI must be installed and configured on your Linux system, and you must be authenticated to an Azure subscription. The locks managed by `az lock` commands are Azure-specific management locks, not Linux file system or process locks.


title: TYPES OF AZURE LOCKS
content:
<ul><li><i><b>CanNotDelete</b></i>: Users can still read and modify a resource, but they cannot delete it.</li><li><i><b>ReadOnly</b></i>: Users can only read a resource. They cannot delete or modify it. This lock type is typically applied to critical production environments where accidental changes are to be strictly avoided.</li></ul>


title: SCOPE OF LOCKS
content:
Locks can be applied at different scopes: subscription, resource group, or individual resource. A lock applied at a higher scope (e.g., resource group) is inherited by all resources within that scope.


title: PERMISSIONS
content:
To create or manage locks, you need appropriate permissions, such as `Microsoft.Authorization/locks/*`. Typically, users with "Owner" or "User Access Administrator" roles have these permissions.


title: HISTORY
content:
Azure resource locks were introduced as part of Azure Resource Manager's governance capabilities to enhance control and prevent unintended modifications or deletions of critical cloud resources. Their development has been driven by the need for robust operational safety and compliance within cloud environments, evolving alongside other Azure governance features like policies and blueprints. The `az lock` command set within the Azure CLI provides a programmatic interface for managing these locks, complementing the Azure portal.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help message for the command or subcommand.<br><br><b>--output &lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Accepts <i>json</i>, <i>jsonc</i>, <i>tsv</i>, <i>table</i>, <i>yaml</i>, <i>yamlc</i>, <i>none</i>.<br><br><b>--query &lt;jmespath&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query to filter the results of the command.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show all debug logs.<br><br><b>--only-show-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show errors, suppressing warnings and other output.<br><br><b>--subscription &lt;name-or-id&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of subscription. If not specified, the default subscription is used.<br><br><b>--resource-group -g &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the resource group (required for operations like <b>create</b>, <b>delete</b>, <b>show</b>, <b>update</b>).<br><br><b>--name -n &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the Logic App workflow (required for operations like <b>create</b>, <b>delete</b>, <b>show</b>, <b>update</b>).<br><br><b>--location -l &lt;location&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Location (e.g., <i>eastus</i>, <i>westeurope</i>) for new resources (required for <b>create</b>).<br><br><b>--definition &lt;path-to-json-file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a JSON file containing the workflow definition (required for <b>create</b> and <b>update</b>).<br><br>


title: DESCRIPTION
content:
Azure Logic Apps are a cloud service that helps schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, devices, and systems. The <b>az logicapp</b> command group provides a comprehensive set of functionalities within the Azure CLI to manage these resources. It allows users to <b>create</b>, <b>delete</b>, <b>list</b>, <b>show</b> details, and <b>update</b> Logic App workflows directly from the command line. This command group is essential for automating deployment and management tasks of Logic Apps in a programmatic way, facilitating DevOps practices for cloud-based integrations and orchestrations. It simplifies interactions with the Azure API for Logic Apps, abstracting complex REST calls into straightforward CLI commands, enabling efficient management of serverless integration workflows.


title: CAVEATS
content:
The <b>az logicapp</b> command group requires the Azure CLI to be installed and properly configured, including prior authentication via <b>az login</b>. <br>Internet connectivity is necessary to interact with Azure services. <br>Users must have appropriate Azure RBAC permissions to manage Logic Apps within their subscription. <br>The workflow definition JSON, often provided via the <b>--definition</b> parameter, can be highly complex and demands a thorough understanding of the Logic Apps workflow schema for effective use.


title: SUBCOMMANDS
content:
The <b>az logicapp</b> is not a standalone command but a command <i>group</i>. To perform operations, you must specify a subcommand, such as <b>create</b>, <b>delete</b>, <b>list</b>, <b>show</b>, or <b>update</b>. Each subcommand has its own specific set of parameters and functionalities.


title: WORKFLOW DEFINITION LANGUAGE (WDL)
content:
A core aspect of managing Logic Apps, especially during creation or update, is providing a workflow definition. This definition is typically a JSON file that describes the Logic App's triggers, actions, and control flow using the Workflow Definition Language. Proficiency in WDL is essential for effectively using the <b>--definition</b> parameter.


title: AUTHENTICATION
content:
Before executing any <b>az logicapp</b> command, you must authenticate your Azure CLI session using the <b>az login</b> command. This establishes your credentials and allows the CLI to interact with your Azure subscription.


title: HISTORY
content:
The Azure CLI, developed by Microsoft, has been a primary command-line interface for managing Azure resources since its initial release in 2014. The <b>az logicapp</b> command group was introduced as Azure Logic Apps matured into a key serverless integration service. Its development has closely tracked the evolution of Logic Apps, continuously adding support for new features, including the more recent Logic Apps Standard plan, which allows for stateful and stateless workflows to run on an App Service Plan. This command group is regularly updated to align with Azure service enhancements and to improve the overall command-line management experience.


title: PARAMETERS
content:
<b><I>--service-principal</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a service principal for authentication. Requires <I>--username</I> (App ID) and <I>--password</I> (secret or certificate path).<br><br><b><I>--username -u</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username (email), service principal client ID, or managed identity client ID.<br><br><b><I>--password -p</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;User password, service principal secret, or path to certificate file.<br><br><b><I>--tenant -t</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The tenant ID for login. Useful for organizations with multiple tenants.<br><br><b><I>--allow-no-subscriptions</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow login even if the account has no associated subscriptions.<br><br><b><I>--msi</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use Managed Service Identity for authentication. Typically used on Azure VMs or resources.<br><br><b><I>--federated-token</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a federated token for Workload Identity authentication.<br><br><b><I>--scope</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the OAuth 2.0 permissions scope.<br><br><b><I>--only-show-errors</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress warnings and only display errors.<br><br>


title: DESCRIPTION
content:
While <b>az-login</b> is not a standard standalone Linux command, it is commonly used as an alias or refers to the <b>az login</b> command within the Azure Command-Line Interface (Azure CLI).<br><br>The <b>az login</b> command is the primary method for authenticating your Azure CLI session to interact with Azure resources. It allows you to sign in to Azure, manage your subscriptions, and execute various Azure CLI commands. By default, it initiates an interactive browser-based authentication flow, prompting you to open a URL and enter a device code, or directly redirects you to a browser for sign-in. Once authenticated, the Azure CLI caches your credentials, allowing subsequent commands to run without re-authentication until the token expires or is explicitly logged out. The command supports various authentication methods tailored for different scenarios, including interactive user login, service principals for automation, and managed identities for Azure resources.


title: CAVEATS
content:
Interactive browser login is the default and generally recommended for human users, especially with Multi-Factor Authentication (MFA).<br>For automation (CI/CD pipelines), service principal authentication is preferred over username/password for security.<br>Avoid hardcoding passwords directly in scripts; use environment variables or secure key vaults.<br>Token caching means you don't need to run <b>az login</b> before every command, but re-authentication is required periodically or after token expiration.


title: AUTHENTICATION METHODS
content:
<b>az login</b> supports several authentication flows:<br><i>1. Interactive (Browser)</i>: Default, opens a browser for authentication.<br><i>2. Device Code Flow</i>: Provides a code to enter on a separate device/browser.<br><i>3. Service Principal</i>: For non-interactive scripting, using an application ID and secret/certificate.<br><i>4. Managed Identity (MSI)</i>: For applications running on Azure services.<br><i>5. Workload Identity</i>: Using federated tokens, e.g., in Kubernetes.


title: TOKEN CACHING
content:
Upon successful login, Azure CLI caches an access token and refresh token. This token is used for subsequent Azure CLI commands, eliminating the need to re-authenticate for a set period. The token is stored securely in a local cache directory (e.g., ~/.azure/ in Linux).


title: HISTORY
content:
The Azure CLI, and consequently its <b>login</b> command, has undergone significant evolution. Initially, Azure resources were managed via the Azure Service Management (ASM) CLI (<b>azure login</b>). With the advent of Azure Resource Manager (ARM), the modern cross-platform Azure CLI (<b>az login</b>) was introduced, providing a consistent and powerful interface for managing ARM resources. The command has continuously added support for new authentication methods, such as Managed Identities and Workload Identities, to cater to diverse enterprise and automation needs, reflecting the evolving security landscape of cloud computing.


title: SYNOPSIS
content:
The `az network` command group is invoked as a subcommand of `az`. Its general synopsis is:<br><br><b>az network <I>subcommand</I> [parameters] [--options]</b><br><br>Where:<br><ul><li><b>az</b>: The main Azure CLI command.</li><li><b>network</b>: The command group for networking services.</li><li><I>subcommand</I>: A specific operation within the network group (e.g., `vnet`, `nsg`, `public-ip`, `lb`).</li><li><b>[parameters]</b>: Arguments specific to the chosen `subcommand` (e.g., resource names, IDs).</li><li><b>[--options]</b>: Optional flags to modify behavior or provide additional information (e.g., `--resource-group`, `--location`, `--output`).</li></ul><i>Example usage:</i><br><b>az network vnet create --name MyVNet --resource-group MyResourceGroup --location eastus</b><br><b>az network nsg rule create --nsg-name MyNSG --resource-group MyResourceGroup --name AllowSSH --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 22</b>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help for the command or subcommand.<br><br><b>--output &lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., `json`, `jsonc`, `tsv`, `table`, `yaml`, `none`).<br><br><b>--query &lt;JMESPath query&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter or transform output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show debug logs.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show all debug logs.<br><br><b>--only-show-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show errors, suppressing warnings.<br><br><b>--subscription &lt;name or ID&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the subscription to use for the command.<br><br><b>--resource-group &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the resource group for the command (commonly used).<br><br><b>--location &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Azure region for resource creation (commonly used).<br><br><b>--tags &lt;key=value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated tags: `key[=value] key[=value] ...`<br><br><b>--yes / -y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for confirmation.<br><br>


title: DESCRIPTION
content:
The `az network` command group is a fundamental component of the Azure Command-Line Interface (Azure CLI), designed for comprehensive management of networking services within Microsoft Azure. Unlike traditional standalone Linux utilities, `az network` is invoked as a subcommand of the primary `az` executable, reflecting its role in orchestrating cloud infrastructure.<br><br>It provides a rich set of subcommands for interacting with a wide array of Azure networking constructs, including but not limited to: Virtual Networks (VNet) and subnets, Network Security Groups (NSG) and their rules, Public IP addresses (PIP), Load Balancers, Application Gateways, VPN Gateways, Traffic Managers, Virtual WANs, and Firewall services. This command group is essential for cloud administrators, DevOps engineers, and developers who provision, configure, and troubleshoot network connectivity and security for their applications and services deployed on Azure. Its design allows for scripting and automation of complex networking setups, making it a critical tool for managing cloud infrastructure efficiently and programmatically. Users authenticate to Azure via `az login` before utilizing `az network` to interact with their subscription's resources.


title: CAVEATS
content:
<ul><li><b>Azure CLI Requirement</b>: The `az network` command is part of the Azure CLI. It must be installed and configured on your system to be used. It is not a native Linux utility.</li><li><b>Authentication</b>: Requires prior authentication to an Azure subscription using `az login`. Commands will fail without proper authentication and permissions.</li><li><b>Internet Connectivity</b>: Requires an active internet connection to communicate with Azure services.</li><li><b>Subscription and Permissions</b>: The user's Azure account must have the necessary permissions within the target subscription to perform the requested networking operations.</li><li><b>Resource Group Dependency</b>: Many networking resources are scoped within Azure Resource Groups, and commands often require specifying the `--resource-group` parameter.</li></ul>


title: OUTPUT FORMATS
content:
The Azure CLI, including `az network` commands, supports various output formats (e.g., `json`, `table`). Using `<b>--output table</b>` often provides a human-readable summary, while `<b>--output json</b>` is ideal for scripting and automation.


title: INTERACTIVE MODE AND AUTOCOMPLETION
content:
The Azure CLI offers an interactive mode (`<b>az interactive</b>`) and shell autocompletion for easier command discovery and usage, which greatly assists in navigating the extensive `az network` command tree.


title: MODULE-BASED STRUCTURE
content:
The `az network` command group is effectively a module within the Azure CLI, allowing for focused development and maintenance of networking-specific functionalities.


title: HISTORY
content:
The `az network` command group has evolved alongside the development of the Azure CLI itself, which was first released in 2015. It has undergone continuous updates and expansions to support new Azure networking services and features. As Azure's networking capabilities have grown – from basic virtual networks to complex software-defined networking, hybrid connectivity, and advanced security services – the `az network` command group has been consistently updated to provide comprehensive command-line interfaces for managing these innovations. Its development is driven by the need for programmatic control and automation of Azure infrastructure, reflecting a broader industry shift towards Infrastructure as Code (IaC) principles.


title: SEE ALSO
content:
<b>az(1)</b>: The main Azure CLI command., <b>az login(1)</b>: Used to authenticate to Azure., <b>az group(1)</b>: Manages Azure resource groups., <b>az vm(1)</b>: Manages Azure virtual machines., <b>az storage(1)</b>: Manages Azure storage accounts., <b>az keyvault(1)</b>: Manages Azure Key Vault.


title: SYNOPSIS
content:
<I>az provider <I>subcommand</I> [--options]</I><br><br><I>Common Subcommands:</I><br><br><I><B>az provider register --namespace <I>NAME</I></B></I><br><I><B>az provider unregister --namespace <I>NAME</I></B></I><br><I><B>az provider show --namespace <I>NAME</I> [--expand-registrations | --query-resource-types]</B></I><br><I><B>az provider list [--query-resource-types]</B></I><br><I><B>az provider operation list --namespace <I>NAME</I></B></I>


title: PARAMETERS
content:
<b><I>subcommand</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>One of the available commands: <B>register</B>, <B>unregister</B>, <B>show</B>, <B>list</B>, <B>operation</B> (with <B>list</B>).</I><br><br><b>--namespace <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The namespace of the resource provider (e.g., <B>Microsoft.Compute</B>, <B>Microsoft.Network</B>). Required for <B>register</B>, <B>unregister</B>, <B>show</B>, and <B>operation list</B>.</I><br><br><b>--expand-registrations</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>An optional flag for the <B>show</B> subcommand. When used, it displays detailed registration information for the resource provider.</I><br><br><b>--query-resource-types</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>An optional flag for the <B>show</B> and <B>list</B> subcommands. When used, it includes a list of resource types supported by the provider, along with their locations and API versions.</I><br><br><b>--output <I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the output format (e.g., <B>json</B>, <B>table</B>, <B>tsv</B>, <B>yaml</B>). This is a common Azure CLI global option.</I><br><br><b>--query <I>JMESPATH_EXPRESSION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>JMESPath query string. Use to filter or transform the command output. This is a common Azure CLI global option.</I><br><br>


title: DESCRIPTION
content:
<I>The <B>az provider</B> command is a crucial component of the Azure Command-Line Interface (CLI), designed for managing Azure <I>resource providers</I>. In Azure, a resource provider is a service that supplies specific Azure resources, such as virtual machines (<B>Microsoft.Compute</B>), networking components (<B>Microsoft.Network</B>), or storage accounts (<B>Microsoft.Storage</B>). Before you can deploy a resource of a certain type, its corresponding resource provider must often be registered within your Azure subscription.</I><br><br><I>This command allows you to:</I><br><br><I><b>Register:</b> Enable a resource provider for your subscription, making its resource types available for creation.</I><br><I><b>List:</b> View all available and registered resource providers in your subscription.</I><br><I><b>Show:</b> Get detailed information about a specific resource provider, including its registration status and supported resource types and locations.</I><br><I><b>Unregister:</b> Disable a resource provider for your subscription.</I><br><br><I>Effectively, <B>az provider</B> ensures that your Azure subscription is configured correctly to deploy and manage various cloud resources by enabling the necessary underlying services.</I>


title: CAVEATS
content:
<I>The command <B>az-provider</B> is not a standalone Linux executable. It refers to the <B>provider</B> subcommand within the Azure Command-Line Interface (CLI). Therefore, it requires the Azure CLI to be installed and configured on your system.</I><br><I>To perform operations like registering or unregistering resource providers, your Azure identity must have sufficient permissions (e.g., Contributor or Owner role on the subscription, or specific <B>Microsoft.Authorization/*/write</B> permissions).</I><br><I>Resource provider registration can take several minutes to complete.</I>


title: UNDERSTANDING RESOURCE PROVIDERS
content:
<I>In Azure, a <B>Resource Provider</B> is a service that exposes Azure resources to users and applications. For instance, <B>Microsoft.Compute</B> is the resource provider for Virtual Machines, <B>Microsoft.Storage</B> for storage accounts, and <B>Microsoft.Network</B> for virtual networks and other networking components. When you want to deploy a resource of a specific type (e.g., a Virtual Machine), the corresponding resource provider must be registered within the Azure subscription where you intend to deploy it.</I><br><I>Registration ensures that your subscription is enabled to use the services offered by that provider. While many common resource providers are automatically registered for new subscriptions, some less frequently used ones might require explicit registration via <B>az provider register</B> before their resources can be created. The status of a resource provider (Registered, Unregistered, Registering) indicates its availability for resource deployment within your subscription.</I>


title: HISTORY
content:
<I>The concept of resource providers has been fundamental to the Azure Resource Manager (ARM) deployment model since its inception. The <B>az</B> CLI itself was introduced to provide a more consistent and cross-platform command-line experience for Azure management, replacing the older <B>azure</B> CLI (which was Node.js-based).</I><br><I>The <B>az provider</B> subcommand has been a core part of the <B>az</B> CLI from early versions, evolving alongside the expanding set of Azure services and their corresponding resource providers. Its functionality reflects the underlying API capabilities for managing resource provider registrations, which are critical for any resource deployment in Azure.</I>


title: PARAMETERS
content:
<b><I>create</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Azure Cache for Redis instance.<br>Common options include: <b>--name</b> (name of the cache), <b>--resource-group</b> (resource group name), <b>--location</b> (Azure region), <b>--sku</b> (e.g., Basic, Standard, Premium), and <b>--vm-size</b> (e.g., C0, C1, P1).<br><br><b><I>show</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about an existing Azure Cache for Redis instance.<br>Common options include: <b>--name</b> and <b>--resource-group</b>.<br><br><b><I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Azure Cache for Redis instances within a subscription or a specified resource group.<br>Common option: <b>--resource-group</b> (optional, to filter by resource group).<br><br><b><I>update</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies properties of an existing Azure Cache for Redis instance, such as scaling the SKU, updating firewall rules, or enabling persistence.<br>Common options include: <b>--name</b>, <b>--resource-group</b>, <b>--sku</b>, and <b>--set</b> (for generic property updates).<br><br><b><I>delete</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an Azure Cache for Redis instance.<br>Common options include: <b>--name</b> and <b>--resource-group</b>.<br><br><b><I>regenerate-keys</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Regenerates the primary or secondary access keys for a Redis cache instance.<br>Common options include: <b>--name</b>, <b>--resource-group</b>, and <b>--key-type</b> {Primary,Secondary}.<br><br><b><I>force-reboot</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a force reboot of the Redis cache nodes, useful for maintenance or troubleshooting.<br>Common options include: <b>--name</b>, <b>--resource-group</b>, <b>--shard-id</b> (for Premium tier), and <b>--reboot-type</b> {PrimaryNode,SecondaryNode,AllNodes}.<br><br>


title: DESCRIPTION
content:
The <I>az redis</I> command group, part of the Azure CLI, facilitates comprehensive management of Azure Cache for Redis instances directly from the command line. It allows users to create, configure, scale, monitor, and delete Redis caches deployed within Azure. This powerful tool is crucial for automating deployment pipelines, scripting operational tasks, and managing cloud-based Redis services without relying solely on the Azure portal. It provides a programmatic interface for interacting with the Azure Redis API, making it an essential utility for developers and administrators looking to streamline their cloud resource management workflows for high-performance data caching solutions.


title: CAVEATS
content:
The 'az-redis' command is not a standalone Linux command. It is a command group within the <I>Azure CLI</I>, a cross-platform command-line tool developed by Microsoft for managing Azure resources. Therefore, to use it, you must have the Azure CLI installed on your system and be authenticated to an active Azure subscription (e.g., via <b>az login</b>). Operations performed with this command, particularly creating or scaling Redis caches, will incur costs on your Azure account.


title: INSTALLATION
content:
The Azure CLI, which includes the <I>az redis</I> command group, can be installed on Linux, macOS, and Windows. On Linux, it's typically installed via native package managers (e.g., <b>apt</b> for Debian/Ubuntu, <b>yum</b> for RHEL/CentOS) or a universal install script provided by Microsoft.


title: AUTHENTICATION
content:
Before using any <I>az</I> command, including <I>az redis</I>, you must authenticate to your Azure account. This is most commonly done using the command <b>az login</b>, which will open a browser window for interactive login. For automated scripts, service principals or managed identities can be used for non-interactive authentication.


title: HISTORY
content:
The Azure CLI was developed to provide a unified and consistent command-line experience for managing Azure services across various operating systems. The <I>az redis</I> command group was introduced as part of the Azure CLI's expanding capabilities, allowing users to automate and script the management of Azure Cache for Redis instances. Its development reflects the growing trend towards Infrastructure-as-Code and the need for robust command-line interfaces for cloud resource orchestration, complementing the Azure portal and PowerShell options.


title: SYNOPSIS
content:
az vm serial-console --name <I>VM_NAME</I> --resource-group <I>RESOURCE_GROUP</I><br>az vm serial-console -n <I>VM_NAME</I> -g <I>RESOURCE_GROUP</I><br><I>Note: This command is a sub-command of `az vm` within the Azure CLI, providing access to the serial console functionality.</I>


title: PARAMETERS
content:
<b>--name / -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the virtual machine.<br><br><b>--resource-group / -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the resource group containing the VM.<br><br><b>--subscription</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The name or ID of the subscription to use if not default.<br><br>


title: DESCRIPTION
content:
The `az vm serial-console` command is part of the Azure Command-Line Interface (Azure CLI) and provides a secure, interactive way to connect to the serial console of an Azure Virtual Machine (VM). This out-of-band management capability is invaluable for troubleshooting scenarios where traditional network connectivity (like SSH or RDP) is unavailable or compromised, such as a misconfigured firewall, boot issues, or network stack problems. It allows administrators to interact with the VM's guest operating system directly, similar to connecting a physical console cable to a server. The connection uses HTTPS, ensuring security. To utilize this feature, the VM must have boot diagnostics enabled, which captures serial console output and enables interactive access.


title: CAVEATS
content:
Requires Azure CLI to be installed and configured.<br>User must be logged into Azure with sufficient permissions (e.g., Virtual Machine Contributor role or higher) to access the VM and its boot diagnostics.<br>The target Azure VM must have "Boot diagnostics" enabled in its configuration.<br>The serial console connection is established over HTTPS and is supported for both Linux and Windows VMs (though interactive access might be limited on older Windows versions).<br>No file transfer capabilities are available directly through the serial console.<br>The console session may time out after a period of inactivity.


title: ENABLING BOOT DIAGNOSTICS
content:
For `az vm serial-console` to function, boot diagnostics must be enabled on the target VM. This can be done via the Azure portal, ARM templates, or Azure CLI using `az vm boot-diagnostics enable --name <I>VM_NAME</I> --resource-group <I>RESOURCE_GROUP</I>`. It requires a storage account to store serial logs and screenshots.


title: COMMON USE CASES
content:
The serial console is commonly used for:<br><i>Resetting forgotten VM passwords.</i><br><i>Debugging boot failures or kernel panics.</i><br><i>Modifying network configurations that have locked out remote access.</i><br><i>Accessing the GRUB menu on Linux VMs to change boot options or enter single-user mode.</i><br><i>Running recovery scripts when the OS is unresponsive.</i>


title: HISTORY
content:
The Azure Serial Console feature was introduced by Microsoft Azure to provide an out-of-band management solution for virtual machines, addressing critical troubleshooting scenarios that cannot be resolved via network-based access. The `az vm serial-console` command emerged as part of the evolving Azure CLI, offering a consistent and programmatic way to interact with Azure resources. Its development reflects the increasing need for robust recovery and debugging tools within cloud environments.


title: SYNOPSIS
content:
<b>az sshkey</b> <I>SUBCOMMAND</I> [OPTIONS]<br><br>Common Subcommands:<br><br><b>az sshkey create</b> --name <I>KEY_NAME</I> --resource-group <I>RESOURCE_GROUP</I> [--public-key-file <I>FILE_PATH</I> | --public-key-value <I>KEY_VALUE</I>] [--location <I>LOCATION</I>]<br><b>az sshkey list</b> [--resource-group <I>RESOURCE_GROUP</I>]<br><b>az sshkey show</b> --name <I>KEY_NAME</I> --resource-group <I>RESOURCE_GROUP</I><br><b>az sshkey delete</b> --name <I>KEY_NAME</I> --resource-group <I>RESOURCE_GROUP</I>


title: PARAMETERS
content:
<b>--name <KEY_NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Required.</I> The unique name for the SSH key resource within Azure.<br><br><b>--resource-group <RESOURCE_GROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Required.</I> The name of the resource group where the SSH key resource will be created or managed.<br><br><b>--public-key-file <FILE_PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to an existing public key file (e.g., ~/.ssh/id_rsa.pub) to upload and register as an Azure SSH key resource. Used with 'create'.<br><br><b>--public-key-value <KEY_VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The literal public key value (e.g., 'ssh-rsa AAAAB3Nz... user@host') to upload and register as an Azure SSH key resource. Used with 'create'.<br><br><b>--location <LOCATION></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure region (e.g., 'eastus', 'westus2') where the SSH key resource will be created. If not specified, the resource group's location is used. Used with 'create'.<br><br><b>--tags <KEY=VALUE> ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated tags in key[=value] format to apply to the SSH key resource. Used with 'create'.<br><br>


title: DESCRIPTION
content:
The <b>az sshkey</b> command group within the Azure CLI provides comprehensive tools for managing SSH public and private key pairs specifically designed for use with Azure resources. Although the exact command <I>az-sshkey</I> is not a standalone executable, this command group fulfills the functionality of managing SSH keys within the Azure environment.<br><br>These keys are crucial for secure authentication when connecting to Linux virtual machines (VMs) or other services like Azure VPN Gateways. Instead of needing to manually generate keys with <I>ssh-keygen</I> and then upload the public key, <b>az sshkey</b> allows users to create, list, show, and delete SSH key resources directly within Azure, integrating key management with Azure's identity and access control mechanisms. It streamlines the process of associating SSH keys with newly created VMs or updating existing ones, making cloud resource access more secure and efficient.


title: CAVEATS
content:
This command group manages SSH key <I>resources</I> within Azure. It does <B>not</B> directly manage local SSH keys on your machine (e.g., in <I>~/.ssh</I>), though it can create them locally when generating new keys. Proper management of the private key on your local machine is crucial for security. The command requires the Azure CLI to be installed and configured (e.g., by running <I>az login</I>).


title: RESOURCE MANAGEMENT
content:
Unlike local SSH keys, <b>az sshkey</b> registers your public keys as managed resources within Azure. This allows for centralized management and integration with Azure Policy and Role-Based Access Control (RBAC), enabling finer-grained control over who can use which keys for Azure resources.


title: AUTOMATIC KEY GENERATION
content:
If neither <I>--public-key-file</I> nor <I>--public-key-value</I> is provided during <b>az sshkey create</b>, the Azure CLI will automatically generate a new SSH key pair (both public and private) on your local machine in the <I>~/.ssh</I> directory. It then uploads the public key to Azure as a managed resource. This provides a convenient way to get started without needing pre-existing keys or external tools.


title: HISTORY
content:
The <b>az sshkey</b> command group was introduced to streamline the management of SSH keys specifically within the Azure ecosystem. Before its existence, users typically had to manually generate SSH key pairs locally using <I>ssh-keygen</I>, then copy the public key content or path to Azure CLI commands like <I>az vm create</I> via parameters such as <I>--ssh-key-values</I>. The <b>az sshkey</b> commands simplify this by allowing the creation, registration, and referencing of SSH key <I>resources</I> directly within Azure, making key management more integrated with Azure's resource model and access control. It reflects Microsoft's continuous effort to enhance developer experience and security for cloud deployments.


title: SYNOPSIS
content:
az storage <I>command-group</I> <I>subcommand</I> [options]<br><br>Examples:<br><I>az storage blob upload --container-name mycontainer --file mylocalfile.txt --name myblob.txt</I><br><I>az storage account create --name mystorageaccount --resource-group myresourcegroup --location eastus --sku Standard_LRS</I>


title: PARAMETERS
content:
<b>account</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Azure Storage accounts, including creation, deletion, key management, and property updates.<br><br><b>blob</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Azure Blob Storage objects, such as uploading, downloading, copying, and deleting blobs.<br><br><b>container</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages blob containers, which are logical groupings for blobs, including creation, listing, and access policy management.<br><br><b>file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages individual files within Azure File Shares, including upload, download, and deletion.<br><br><b>directory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages directories within Azure File Shares.<br><br><b>share</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Azure File Shares, which are cloud-based SMB/NFS file shares.<br><br><b>queue</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Azure Storage Queues for robust message queuing between applications.<br><br><b>table</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Azure Storage Tables, a NoSQL key-value store for structured data.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <I>az storage</I> command group or any of its subcommands.<br><br><b>--output <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., json, jsonc, tsv, table, yaml, none).<br><br>


title: DESCRIPTION
content:
The <I>az storage</I> command group within the Azure CLI provides comprehensive functionality for interacting with and managing various Azure Storage services. It allows users to control storage accounts, blob containers, individual blobs, file shares, directories, files, message queues, and NoSQL tables directly from the command line. This powerful tool is essential for automating storage operations, scripting data transfers, and managing storage infrastructure. It abstracts the complexities of the underlying REST APIs, offering a consistent and intuitive interface for common storage tasks like uploading/downloading data, managing access policies, configuring networking, and monitoring usage. As a part of the Azure CLI, it integrates seamlessly with other Azure resource management commands.


title: CAVEATS
content:
The command 'az-storage' as a standalone executable does not exist. It is a command group within the Azure CLI, invoked as <I>az storage</I>. To use it, the Azure CLI must be installed and configured, and you must be logged into an Azure account via <I>az login</I>. Specific storage operations often require the `--account-name`, `--account-key`, or `--connection-string` options, or prior setup of a default storage account.


title: INSTALLATION AND AUTHENTICATION
content:
Before using <I>az storage</I>, ensure the Azure CLI is installed on your system (available for Windows, macOS, and Linux). After installation, you must authenticate to your Azure account using the <I>az login</I> command, typically opening a browser for interactive login.


title: COMMAND STRUCTURE
content:
Commands within <I>az storage</I> follow a hierarchical structure: <B>az storage &lt;service-type&gt; &lt;action&gt; [options]</B>. For example, <I>az storage blob upload</I> manages blobs by uploading them, or <I>az storage account list</I> manages storage accounts by listing them. Each action has its own set of specific options and arguments.


title: HISTORY
content:
The <I>az storage</I> command group is an integral part of the Azure CLI (command-line interface), which was initially released as <I>Azure CLI 2.0</I> to replace the older, Node.js-based cross-platform CLI. Since its inception, the Azure CLI, including its storage capabilities, has been continuously developed by Microsoft. It has seen numerous updates, bug fixes, and feature additions, aligning with the rapid evolution of Azure Storage services. Its design focuses on automation and scripting, making it a primary tool for DevOps and cloud administrators.


title: SYNOPSIS
content:
<b>az storage account</b> <I>subcommand</I> [<I>options</I>]<br><br>Examples:<br><b>az storage account create</b> --name <I>myaccountname</I> --resource-group <I>myresourcegroup</I> --location <I>eastus</I> --sku <I>Standard_LRS</I><br><b>az storage account show</b> --name <I>myaccountname</I> --resource-group <I>myresourcegroup</I><br><b>az storage account list</b> --resource-group <I>myresourcegroup</I><br><b>az storage account delete</b> --name <I>myaccountname</I> --resource-group <I>myresourcegroup</I> --yes


title: PARAMETERS
content:
<b>--name / -n <I>account_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage account. Required for most operations on a specific account.<br><br><b>--resource-group / -g <I>group_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the resource group the storage account belongs to. Required for most operations.<br><br><b>--location / -l <I>location</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure region where the storage account will be created (e.g., 'eastus', 'westus2'). Used with 'create'.<br><br><b>--sku <I>sku_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The storage account SKU (e.g., Standard_LRS, Standard_GRS, Premium_LRS). Used with 'create' or 'update'.<br><br><b>--kind <I>kind_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The kind of storage account to create (e.g., StorageV2, BlobStorage, FileStorage). Used with 'create'.<br><br><b>--output / -o <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for the command result. Common formats include json, jsonc, table, tsv, yaml. Default is json.<br><br><b>--query <I>JMESPath_string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter or transform the command output.<br><br><b>--subscription <I>ID_or_Name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of the Azure subscription to use. You can configure the default subscription using `az account set`.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show all debug logs.<br><br><b>--help / -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help message for the command or subcommand.<br><br>


title: DESCRIPTION
content:
<b>az storage account</b> is a command group within the Azure Command-Line Interface (Azure CLI) that provides tools for managing Azure Storage accounts. Storage accounts are core Azure services that offer highly available, durable, scalable, and redundant storage for data objects like blobs, files, queues, and tables.<br><br>This command group allows users to perform a wide range of operations, including creating new storage accounts, retrieving their properties, listing existing accounts, updating configurations (e.g., SKU, access tiers, network rules), deleting accounts, and managing associated services like blob and file service properties, encryption scopes, and private endpoint connections. It simplifies the automation and scripting of storage account management tasks directly from a command-line environment or CI/CD pipelines.


title: CAVEATS
content:
Using <b>az storage account</b> commands requires that the Azure CLI is correctly installed and authenticated to an Azure subscription. Users must have appropriate Azure Role-Based Access Control (RBAC) permissions on the subscription or resource group to perform storage account operations. <br><br>Storage account names must be globally unique across all of Azure. Deleting a storage account is a destructive operation and will remove all data within it; confirmation is usually required unless `--yes` is specified. Creating or updating storage accounts can incur costs based on the chosen SKU, redundancy options, and data stored.


title: KEY SUBCOMMANDS
content:
The <b>az storage account</b> group includes many subcommands for specific tasks:<br><ul><li><b>create</b>: Provisions a new storage account.</li><li><b>show</b>: Retrieves details of a specific storage account.</li><li><b>list</b>: Lists all storage accounts in a subscription or resource group.</li><li><b>update</b>: Modifies properties of an existing storage account.</li><li><b>delete</b>: Permanently removes a storage account.</li><li><b>network-rule</b>: Manages IP and virtual network rules for network access.</li><li><b>show-connection-string</b>: Displays the connection string for accessing the storage account.</li></ul>


title: SKU AND KIND CONSIDERATIONS
content:
When creating a storage account, the <b>--sku</b> and <b>--kind</b> parameters are critical.<br><ul><li>The <b>SKU</b> determines redundancy (LRS, GRS, ZRS, GZRS), performance tier (Standard, Premium), and replication options.</li><li>The <b>Kind</b> determines the supported features (e.g., StorageV2 for general purpose, BlobStorage for blobs only, FileStorage for premium files). Choosing the right combination impacts cost and capabilities.</li></ul>


title: HISTORY
content:
The Azure CLI, including the <b>az storage account</b> command group, was developed by Microsoft as a cross-platform command-line experience for managing Azure resources. It was designed to be more consistent and user-friendly than previous Azure management tools and has been continuously updated to support new Azure services and features, including various additions to Azure Storage capabilities (e.g., private endpoints, encryption scopes, data lake features) since its initial release. It is open-source and primarily developed in Python.


title: SYNOPSIS
content:
<b>az storage blob</b> &lt;<i>SUBCOMMAND</i>&gt; [<i>OPTIONS</i>]<br>For example: <b>az storage blob upload</b> --container-name &lt;<i>container</i>&gt; --name &lt;<i>blob-name</i>&gt; --file &lt;<i>local-path</i>&gt;<br>Use <b>az storage blob</b> &lt;<i>SUBCOMMAND</i>&gt; <b>--help</b> for specific subcommand options.


title: PARAMETERS
content:
<b>--account-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the storage account. Required if not provided via connection string or environment variables.<br><br><b>--account-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shared access key for the storage account. Required if not provided via connection string, environment variables, or AAD.<br><br><b>--connection-string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connection string for the storage account. Provides all necessary authentication details.<br><br><b>--sas-token</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shared Access Signature (SAS) token for authentication. Can be used instead of account key or connection string for fine-grained access.<br><br><b>--container-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the blob container to operate on. This is a common required parameter for many blob subcommands.<br><br><b>--output {json, jsonc, table, tsv, yaml, yamlc, none}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for command results. Global Azure CLI parameter.<br><br><b>--query</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string. Use to filter and format the output of the command. Global Azure CLI parameter.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show debug logs. Global Azure CLI parameter.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show all debug logs. Global Azure CLI parameter.<br><br><b>--help -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit for the command group or specific subcommand.<br><br>


title: DESCRIPTION
content:
The <b>az storage blob</b> command is a powerful sub-group within the <I>Azure Command-Line Interface (Azure CLI)</I> that provides a comprehensive suite of tools for managing <I>Azure Blob storage</I>. It is not a standalone Linux command but rather a set of operations invoked via the <B>az</B> CLI tool. <br><br>Azure Blob storage is Microsoft's object storage solution for the cloud, optimized for storing massive amounts of unstructured data, such as text or binary data. The <B>az storage blob</B> command group allows users to interact with containers and blobs programmatically, enabling tasks such as uploading and downloading blobs, listing container contents, managing blob properties and metadata, creating snapshots, copying blobs, and deleting blobs or containers.<br><br>It supports various authentication methods, including connection strings, shared access signatures (SAS), and Azure Active Directory (AAD) integration, making it versatile for different operational scenarios. This command group is essential for DevOps practices, scripting automation, and general administration of data stored in Azure Blob Storage.


title: CAVEATS
content:
The <b>az storage blob</b> command group requires the <I>Azure CLI</I> to be installed and configured. It is not a native Linux utility. Authentication to Azure is typically handled globally by <b>az login</b>, but specific storage account credentials (keys, SAS tokens, connection strings) can override or be specified per command. Options vary significantly between subcommands (e.g., <b>upload</b>, <b>download</b>, <b>delete</b>), and users should consult the specific subcommand's help (e.g., <b>az storage blob upload --help</b>) for detailed parameter information.


title: COMMON SUBCOMMANDS
content:
While <b>az storage blob</b> itself is a group, it encompasses many crucial subcommands for interacting with blobs:<br><b><B>az storage blob upload</B></b>: Uploads a local file to a blob.<br><b><B>az storage blob download</B></b>: Downloads a blob to a local file.<br><b><B>az storage blob list</B></b>: Lists blobs in a container.<br><b><B>az storage blob show</B></b>: Gets the properties of a specific blob.<br><b><B>az storage blob delete</B></b>: Deletes a blob.<br><b><B>az storage blob copy start</B></b>: Initiates an asynchronous copy operation from one blob to another.<br><b><B>az storage blob url</B></b>: Generates a URL for a blob.<br><b><B>az storage blob generate-sas</B></b>: Generates a shared access signature for a blob.


title: AUTHENTICATION METHODS
content:
Authentication for <b>az storage blob</b> commands can be handled in several ways:<br><b><I>Azure Active Directory (AAD)</I></b>: Recommended for most scenarios, using the logged-in user's credentials (via <b>az login</b>). Requires assigning appropriate RBAC roles (e.g., Storage Blob Data Contributor).<br><b><I>Storage Account Key</I></b>: Provided directly using <b>--account-key</b>. Grants full access to the storage account.<br><b><I>Connection String</I></b>: Provided directly using <b>--connection-string</b>. Contains all necessary authentication details (account name, key, endpoint).<br><b><I>Shared Access Signature (SAS)</I></b>: Provided using <b>--sas-token</b>. Grants time-limited, restricted permissions to specific resources.


title: HISTORY
content:
The <I>Azure CLI</I> and its storage commands have continuously evolved since their initial release, with significant updates and new features being added regularly to support new Azure Storage capabilities and improve user experience. The `az storage blob` command group specifically matured from earlier versions of the CLI, which might have had different syntax or fewer features (e.g., the legacy Azure PowerShell cmdlets or older Xplat CLI). It represents the modern, cross-platform interface for Azure Blob Storage management, designed for automation and integration into CI/CD pipelines.


title: SYNOPSIS
content:
az storage container <I>SUBCOMMAND</I> [OPTIONS]<br><br>Common Subcommands:<br>az storage container create --name <I>container_name</I> --account-name <I>storage_account_name</I> [options]<br>az storage container delete --name <I>container_name</I> --account-name <I>storage_account_name</I> [options]<br>az storage container list --account-name <I>storage_account_name</I> [options]<br>az storage container show --name <I>container_name</I> --account-name <I>storage_account_name</I> [options]<br>az storage container generate-sas --name <I>container_name</I> --permissions <I>permissions</I> --expiry <I>date_time</I> --account-name <I>storage_account_name</I> [options]


title: PARAMETERS
content:
<b>--name -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage container.<br><br><b>--account-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage account.<br><br><b>--connection-string -c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The connection string for the storage account.<br><br><b>--account-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The storage account key.<br><br><b>--public-access</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the public access level for the container. Possible values are 'blob', 'container', or 'off'.<br><br><b>--expiry</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The UTC datetime (YYYY-MM-DDThh:mmZ) at which the shared access signature becomes invalid. Used with 'generate-sas'.<br><br><b>--permissions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The permissions for the shared access signature (e.g., 'rlwacd' for read, list, write, add, create, delete). Used with 'generate-sas'.<br><br><b>--output -o</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Accepted values: json, jsonc, table, tsv, yaml, yamlc.<br><br><b>--query -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string.<br><br>


title: DESCRIPTION
content:
az storage container is a command group within the Azure Command-Line Interface (Azure CLI) designed for comprehensive management of blob containers within Azure Storage accounts. Blob containers act as a namespace for storing Azure Blobs, which can be any type of file or binary data.<br><br>This command group allows users to perform various operations such as creating new containers, listing existing ones, retrieving detailed information about a specific container, deleting containers, and managing their access policies. It provides a robust interface for interacting with Azure Blob Storage, enabling administrators and developers to programmatically control storage resources, set public access levels for anonymous access, and configure shared access signatures (SAS) for granular, time-limited access. Operations can be authenticated using an Azure storage account name and key, a connection string, or Azure Active Directory (AAD) credentials, ensuring secure and flexible management of storage resources.


title: CAVEATS
content:
This command group requires the Azure CLI to be installed and properly configured, typically by logging in with <b>az login</b>.<br><br>Appropriate Azure RBAC permissions on the storage account are necessary to perform operations. For instance, 'Storage Blob Data Contributor' is needed for data operations, while 'Storage Account Contributor' might be required for account-level settings.<br><br>When using account keys or connection strings, ensure these are handled securely to prevent unauthorized access to your storage resources.<br><br>Public access settings should be configured with caution as they can expose blobs to anonymous internet access.


title: SUBCOMMANDS
content:
The <b>az storage container</b> command group includes several subcommands for specific operations:<br><ul><li><b>az storage container create</b>: Creates a new storage container.</li><li><b>az storage container delete</b>: Deletes a storage container.</li><li><b>az storage container exists</b>: Checks if a storage container exists.</li><li><b>az storage container generate-sas</b>: Generates a shared access signature (SAS) for a container.</li><li><b>az storage container list</b>: Lists storage containers in a storage account.</li><li><b>az storage container set-permission</b>: Sets the permissions for a storage container.</li><li><b>az storage container show</b>: Shows details for a storage container.</li><li><b>az storage container update</b>: Updates the properties of a storage container.</li></ul>


title: AUTHENTICATION METHODS
content:
<b>az storage container</b> commands support several authentication methods:<br><ul><li><b>Azure Active Directory (AAD)</b>: Recommended for most scenarios, leveraging <b>az login</b> and RBAC roles.</li><li><b>Storage Account Name and Key</b>: Providing <b>--account-name</b> and <b>--account-key</b>.</li><li><b>Connection String</b>: Providing <b>--connection-string</b>.</li><li><b>Shared Access Signature (SAS)</b>: When managing resources with a pre-generated SAS token using <b>--sas-token</b>.</li></ul>


title: PUBLIC ACCESS LEVELS
content:
Containers can be configured with different public access levels:<br><ul><li><b>off</b> (default): No public anonymous access. Blobs can only be accessed through authenticated requests.</li><li><b>blob</b>: Allows anonymous public read access to blobs within the container. Container data itself is not accessible.</li><li><b>container</b>: Allows anonymous public read access to blobs and container data (e.g., list of blobs) within the container.</li></ul>


title: SYNOPSIS
content:
The <b>az storage entity</b> command acts as a group for various subcommands. The general form is:<br><br><b>az storage entity</b> <I>&lt;SUBCOMMAND&gt;</I> [<I>OPTIONS</I>]<br><br>Common subcommands include:<br><b>query</b>: Query entities in a table.<br><b>insert</b>: Insert a new entity into a table.<br><b>update</b>: Update an existing entity in a table (replaces entire entity).<br><b>merge</b>: Merge properties into an existing entity in a table.<br><b>delete</b>: Delete an entity from a table.<br><b>show</b>: Alias for <b>query</b> specific entity using partition and row key.<br><br>Example syntax for querying a specific entity:<br><b>az storage entity query --table-name</b> <I>myTable</I> <b>--partition-key</b> <I>myPartition</I> <b>--row-key</b> <I>myRow</I> <b>--connection-string</b> <I>"DefaultEndpointsProtocol=..."</I><br><br>Example syntax for inserting a new entity:<br><b>az storage entity insert --table-name</b> <I>myTable</I> <b>--entity</b> <I>"{'PartitionKey': 'p1', 'RowKey': 'r1', 'Name': 'Item1'}"</I> <b>--account-name</b> <I>myaccount</I> <b>--account-key</b> <I>mykey</I>


title: PARAMETERS
content:
<b><b>--table-name</b> <I>&lt;name&gt;</I> or <b>-t</b> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Mandatory</i>. The name of the table to operate on.<br><br><b><b>--partition-key</b> <I>&lt;key&gt;</I> or <b>-p</b> <I>&lt;key&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The partition key of the entity. Required for operations on specific entities (e.g., <b>query</b>, <b>insert</b>, <b>update</b>, <b>delete</b>).<br><br><b><b>--row-key</b> <I>&lt;key&gt;</I> or <b>-r</b> <I>&lt;key&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The row key of the entity. Required for operations on specific entities.<br><br><b><b>--entity</b> <I>&lt;json&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A JSON string representing the entity's properties. Required for <b>insert</b>, <b>update</b>, or <b>merge</b> operations.<br><br><b><b>--connection-string</b> <I>&lt;string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure Storage connection string. A common method for authentication and specifying the storage account.<br><br><b><b>--account-name</b> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Azure Storage account. Used in conjunction with <b>--account-key</b> or <b>--sas-token</b> for authentication, or relies on default CLI credentials.<br><br><b><b>--account-key</b> <I>&lt;key&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Azure Storage account key. Used with <b>--account-name</b> for authentication.<br><br><b><b>--sas-token</b> <I>&lt;token&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A Shared Access Signature (SAS) token. Used with <b>--account-name</b> for authentication, providing limited permissions.<br><br><b><b>--filter</b> <I>&lt;odata_expression&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An <I>OData</I> filter string to narrow down results for <b>query</b> operations (e.g., <I>'PropertyName eq 'Value''</I>).<br><br><b><b>--select</b> <I>&lt;properties&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of properties to return for <b>query</b> operations, reducing payload size.<br><br><b><b>--num-results</b> <I>&lt;count&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum number of entities to return from a <b>query</b> operation. Defaults to 1000.<br><br>


title: DESCRIPTION
content:
The <b>az storage entity</b> command is a powerful subcommand within the <I>Azure Command-Line Interface (Azure CLI)</I> that enables you to manage individual entities (rows) within Azure Storage tables. It provides comprehensive capabilities for performing <I>Create, Read, Update, and Delete (CRUD)</I> operations on structured data stored in a <I>NoSQL key-value store</I> fashion.<br><br>This command allows you to insert new entities, query existing ones, update or merge properties of entities, and delete them from specific tables. It supports various authentication methods, including connection strings, shared access signatures (SAS), and Azure Active Directory (Azure AD) authentication. <b>az storage entity</b> is essential for scripting and automating data management tasks within Azure Storage tables, providing a command-line alternative to graphical tools or SDKs.


title: CAVEATS
content:
<b>Caveats and limitations:</b><br><br>• Requires the <B>Azure CLI</B> to be installed and configured on your system.<br>• An <B>authenticated Azure session</B> via <I>az login</I> or explicit authentication parameters (<I>--connection-string</I>, <I>--account-name</I>/<I>--account-key</I>/<I>--sas-token</I>) are mandatory.<br>• Proper <B>permissions</B> on the target Azure Storage account and table are necessary for all operations.<br>• Entities within a table are schema-less, but <B>PartitionKey</B> and <B>RowKey</B> are mandatory for every entity and together form its unique identifier.<br>• <B>OData</B> query syntax for <I>--filter</I> and <I>--select</I> can be complex and requires understanding of the <I>OData protocol</I>.<br>• Operations like <B>update</B> perform a full replacement of the entity, while <B>merge</B> updates specific properties. Choose carefully.


title: AUTHENTICATION METHODS
content:
<b>az storage entity</b> supports multiple authentication methods. The most common are providing an Azure Storage <B>connection string</B>, or separately providing the <B>account name</B> and either an <B>account key</B> or a <B>Shared Access Signature (SAS) token</B>. Alternatively, if logged into Azure CLI via <I>az login</I>, it can use <I>Azure Active Directory (Azure AD)</I> for authentication, provided the user or service principal has the necessary <I>RBAC roles</I> (e.g., "Storage Table Data Contributor").


title: KEY DESIGN (PARTITIONKEY & ROWKEY)
content:
Every entity in an Azure Table Storage table must have a <B>PartitionKey</B> and a <B>RowKey</B>. These two properties together form the unique identifier for an entity within a table. <B>PartitionKey</B> helps organize entities into partitions for scalability and query performance, while <B>RowKey</B> uniquely identifies an entity within its specific partition. These keys are crucial for efficient data retrieval and transactional consistency.


title: ERROR HANDLING
content:
The command will output detailed error messages to <I>stderr</I> if operations fail due to reasons such as incorrect table names, invalid keys, permission issues, or malformed JSON entity data. It's important to check the <B>exit code</B> (e.g., <I>$?</I> in bash) for scripting purposes to ensure command success or failure.


title: HISTORY
content:
The <b>az storage entity</b> command is an integral part of the <B>Azure CLI</B>, developed and maintained by <I>Microsoft</I>. It has evolved alongside the <I>Azure Storage Tables</I> service capabilities, with updates typically released as part of broader Azure CLI updates. Its development focus has been on providing robust, scriptable interfaces for managing <I>NoSQL</I> table data, mirroring the functionality available in <I>SDKs</I> and the <I>Azure portal</I>. Continuous integration and improvements are driven by user feedback and the evolution of Azure services.


title: SYNOPSIS
content:
<B>az storage queue</B> <I>&lt;command&gt;</I> [<I>&lt;options&gt;</I>]<br><br>Common commands:<br>  <B>az storage queue create</B> - Create a storage queue.<br>  <B>az storage queue delete</B> - Delete a storage queue.<br>  <B>az storage queue list</B> - List storage queues.<br>  <B>az storage queue message add</B> - Add a message to a queue.<br>  <B>az storage queue message get</B> - Get messages from a queue.<br>  <B>az storage queue message peek</B> - Peek messages from a queue without removing them.<br>  <B>az storage queue message delete</B> - Delete messages from a queue.


title: PARAMETERS
content:
<b><I>--account-name</I> <B>&lt;name&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Azure Storage account. Required if not provided by other means like connection string or environment variables.<br><br><b><I>--account-key</I> <B>&lt;key&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary or secondary key of the Azure Storage account. Used for shared key authentication.<br><br><b><I>--connection-string</I> <B>&lt;string&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The connection string for the Azure Storage account. Provides all necessary authentication details.<br><br><b><I>--sas-token</I> <B>&lt;token&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A Shared Access Signature (SAS) token to authenticate requests.<br><br><b><I>--auth-mode</I> <B>&lt;mode&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The authentication mode. Supported values include <I>key</I> (default), <I>login</I> (Azure AD), and <I>sas</I>.<br><br><b><I>--name</I> <B>&lt;queue_name&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage queue for operations like create, delete, or show. Used by main queue commands.<br><br><b><I>--queue-name</I> <B>&lt;queue_name&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage queue when performing message operations (e.g., <I>message add</I>, <I>message get</I>).<br><br><b><I>--content</I> <B>&lt;message_content&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The content of the message to add to the queue (for <I>message add</I>).<br><br><b><I>--visibility-timeout</I> <B>&lt;seconds&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The time (in seconds) during which a retrieved message will be invisible to other processing requests. Used in <I>message add</I>, <I>message get</I>, <I>message update</I>.<br><br><b><I>--num-messages</I> <B>&lt;count&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of messages to retrieve from the queue (for <I>message get</I>, <I>message peek</I>).<br><br><b><I>--output</I> <B>&lt;format&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Accepted values: <I>json</I>, <I>jsonc</I>, <I>none</I>, <I>table</I>, <I>tsv</I>, <I>yaml</I>, <I>yamlc</I>. Default: <I>json</I>.<br><br><b><I>--query</I> <B>&lt;jmespath_query&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter or transform command output. See <I>http://jmespath.org/</I> for more information.<br><br><b><I>--help</I>, <I>-h</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the command or subcommand.<br><br>


title: DESCRIPTION
content:
The <I>az storage queue</I> command group within the Azure CLI provides comprehensive tools for managing Azure Storage queues and the messages within them.<br><br>Azure Storage queues are a service for storing large numbers of messages that can be accessed from anywhere in the world via authenticated HTTP or HTTPS. They are commonly used to create a backlog of work to process asynchronously. This command group allows users to create, delete, list, and show details of storage queues.<br><br>Furthermore, it enables operations on messages, such as adding messages to a queue, peeking at messages without removing them, getting and deleting messages, and updating existing messages. It supports various authentication methods, including connection strings, shared access signatures (SAS), and Azure Active Directory (AAD) authentication, making it a versatile tool for developers and administrators working with Azure Storage.


title: CAVEATS
content:
The command <B>az-storage-queue</B> is not a standard standalone Linux command. This analysis assumes the user is referring to the Azure CLI command group <B>az storage queue</B>. It requires the Azure CLI to be installed and configured with appropriate Azure credentials. Operations performed by this command group interact with cloud resources, requiring active network connectivity to Azure.


title: QUEUE MESSAGE ENCODING
content:
Azure Storage queue messages are often Base64 encoded, especially when they contain binary data or complex JSON structures. The <B>az storage queue message encode</B> and <B>az storage queue message decode</B> subcommands can be used to handle this encoding and decoding process, ensuring proper handling of message content.


title: AUTHENTICATION METHODS
content:
Multiple authentication methods are supported: <B>Shared Key</B> (using account name and key/connection string), <B>Shared Access Signature (SAS)</B> for limited access, and <B>Azure Active Directory (AAD)</B> via <I>az login</I> for role-based access control. The chosen method impacts the required parameters and permissions.


title: HISTORY
content:
The Azure CLI, developed by Microsoft, provides a command-line interface for managing Azure resources. The <B>az storage queue</B> command group has been a fundamental part of the <B>az storage</B> module since the early iterations of the Azure CLI, reflecting the critical role of message queues in scalable cloud application architectures. It has continuously evolved, incorporating new features and improvements to keep pace with updates to the Azure Storage service and broader Azure ecosystem.


title: SEE ALSO
content:
<I>az(1)</I>, <I>az storage container(1)</I>, <I>az storage blob(1)</I>, <I>az storage table(1)</I>, <I>curl(1)</I>, <I>jq(1)</I>


title: PARAMETERS
content:
<b><I>SUBCOMMANDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One of the available operations on Azure Storage Tables. This is the first argument after <b>az storage table</b> and dictates the action to be performed. Common subcommands include: <br><b>create</b>: Create a new table. <br><b>delete</b>: Delete an existing table. <br><b>exists</b>: Check if a table exists. <br><b>generate-sas</b>: Generate a Shared Access Signature for a table. <br><b>list</b>: List tables within a storage account. <br><b>show</b>: Get properties of a specific table.<br><br><b>--account-name <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage account to operate on. This is typically used in conjunction with <b>--account-key</b>.<br><br><b>--account-key <I>KEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The storage account key to use for authentication. This is an alternative to <b>--connection-string</b> or <b>--sas-token</b>.<br><br><b>--connection-string <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The connection string for the storage account. This provides all necessary authentication details and is an alternative to specifying <b>--account-name</b> and <b>--account-key</b> separately.<br><br><b>--name <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the specific table to operate on. This parameter is required for subcommands that target a single table, such as <b>create</b>, <b>delete</b>, or <b>show</b>.<br><br><b>--sas-token <I>TOKEN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Shared Access Signature token to use for authorization. This offers granular, time-limited access and is an alternative to full account keys or connection strings.<br><br><b>--output <I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for the command result. Common formats include 'json' (default), 'tsv', 'table', 'yaml', or 'none'.<br><br><b>--query <I>JMESPATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A JMESPath query string to filter or transform the output of the command, allowing for custom data extraction.<br><br>


title: DESCRIPTION
content:
The <b>az storage table</b> command group in the Azure CLI provides a comprehensive interface for managing Azure Storage Tables. Azure Table storage is a NoSQL key/attribute data store, offering a highly scalable and cost-effective way to store structured, non-relational data in the cloud. This command group allows users to perform various operations directly on tables, including creating new tables, deleting existing ones, listing tables within a storage account, viewing specific table properties, and generating Shared Access Signatures (SAS) for secure, time-limited access. It interacts with the Azure Storage service to manage the table resource itself, distinct from managing entities (rows) within a table, which is handled by the <b>az storage entity</b> command group. Operations typically require specifying the target storage account, either by name and key, a connection string, or a SAS token, and proper Azure authentication through <b>az login</b>.


title: CAVEATS
content:
Using <b>az storage table</b> commands necessitates the Azure CLI to be installed and properly configured, along with an active authenticated session against Azure (via <I>az login</I>). Appropriate permissions on the storage account are crucial; typically, 'Storage Account Contributor' or more specific data plane roles like 'Storage Table Data Contributor' are required. Table names must adhere to Azure naming conventions, including being unique within a storage account, starting with a letter or number, and containing only alphanumeric characters. All operations performed on Azure Storage services, including table management, incur costs based on usage and stored data.


title: USAGE CONTEXT AND AUTHENTICATION
content:
Before executing <b>az storage table</b> commands, ensure you are logged into Azure using <I>az login</I>. You can specify the target storage account using its name and a key, a full connection string, or a SAS token provided directly within the command. For convenience, you can also set environment variables like <I>AZURE_STORAGE_ACCOUNT</I> and <I>AZURE_STORAGE_KEY</I> to avoid repeatedly typing account credentials for subsequent commands in the same session.


title: EXAMPLE: CREATE AND LIST TABLES
content:
To create a new table named <I>mydata</I> within a storage account called <I>mycliaccount</I>, using its access key:<br><br><code>az storage table create --name mydata --account-name mycliaccount --account-key "&lt;your_storage_account_key&gt;"</code><br><br>To list all tables present in the same storage account, displaying the output as a formatted table:<br><br><code>az storage table list --account-name mycliaccount --account-key "&lt;your_storage_account_key&gt;" --output table</code>


title: HISTORY
content:
The <b>az</b> command is the core of the Azure CLI, designed to provide a unified command-line experience across all Azure services. It emerged as a modern, cross-platform alternative to older Azure management tools. The <b>az storage</b> command group, including <b>az storage table</b>, has been a foundational component of the Azure CLI since its early development, evolving alongside the Azure Storage service itself. Its design emphasizes modularity, allowing new features and service updates to be integrated efficiently. The Azure CLI, including its storage commands, is an open-source project actively maintained by Microsoft and a community of contributors.


title: SEE ALSO
content:
az storage blob, az storage queue, az storage file, az storage account, az storage entity, az login, az group


title: SYNOPSIS
content:
<B>az upgrade</B> [<I>--yes | --no-prompt</I>] [<I>--debug</I>] [<I>--verbose</I>] [<I>--output {json,jsonc,none,table,tsv,yaml,yamlc}</I>] [<I>--query &lt;JMESPath&gt;</I>] [<I>--subscription &lt;ID_or_name&gt;</I>] [<I>--only-show-errors</I>]


title: PARAMETERS
content:
<b><I>--yes</I>, <I>-y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for confirmation. Automatically confirm the upgrade operation, proceeding with the update without user interaction.<br><br><b><I>--no-prompt</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <I>--yes</I>. Specifies to not prompt for confirmation and proceed with the upgrade automatically.<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show all debug logs. Useful for troubleshooting issues during the upgrade process.<br><br><b><I>--verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show more information. Provides additional details about the upgrade steps.<br><br><b><I>--output {json,jsonc,none,table,tsv,yaml,yamlc}</I>, <I>-o {json,jsonc,none,table,tsv,yaml,yamlc}</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Specifies the format in which the command's results are presented (e.g., JSON, table). While less critical for <B>az upgrade</B> itself, it's a standard <I>Azure CLI</I> global argument.<br><br><b><I>--query &lt;JMESPath&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string. Allows for filtering and formatting the output based on a specified query. Another standard global argument for <I>Azure CLI</I> commands.<br><br><b><I>--subscription &lt;ID_or_name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of subscription. Specifies the active Azure subscription for the command. Although <B>az upgrade</B> itself doesn't directly interact with Azure resources, this is a standard global argument for context.<br><br><b><I>--only-show-errors</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show errors, suppressing warnings. Reduces output verbosity by only displaying critical error messages.<br><br>


title: DESCRIPTION
content:
The <I>az upgrade</I> command is an integral part of the <I>Azure CLI</I> (<B>az</B>) toolset, specifically designed to facilitate the self-update of the CLI itself to its newest available version. It provides a streamlined and user-friendly method for maintaining your <I>Azure CLI</I> installation. The command intelligently checks for a newer stable release of the <I>Azure CLI</I> on Microsoft's package repositories, downloads the necessary components, and then upgrades the existing installation by leveraging <B>pip</B> internally.<br>This command significantly simplifies the ongoing maintenance of the <I>Azure CLI</I>, ensuring users can effortlessly keep their command-line interface up-to-date with the latest features, critical bug fixes, and essential security improvements. It eliminates the need for manual intervention using underlying package managers like <B>pip</B> or system-level tools for updates. While primarily designed for <B>pip</B>-based installations, it may require elevated privileges (e.g., <B>sudo</B> on Linux/macOS or Administrator on Windows) depending on how the <I>Azure CLI</I> was originally installed on your system.


title: CAVEATS
content:
<B>Caveats and Limitations:</B><br><B>• Internet Connectivity:</B> Requires an active internet connection to download the latest <I>Azure CLI</I> packages from Microsoft's repositories.<br><B>• Permissions:</B> Depending on the initial installation method, running <B>az upgrade</B> may require elevated privileges (e.g., <B>sudo</B> on Linux/macOS, or Administrator on Windows). Failure to provide sufficient permissions will result in an error.<br><B>• Installation Method Specifics:</B> This command is primarily effective for <I>Azure CLI</I> installations managed by <B>pip</B> or via the official Microsoft installer scripts. If the <I>Azure CLI</I> was installed via a system package manager (<B>apt</B> on Debian/Ubuntu, <B>yum</B>/<B>dnf</B> on RHEL/CentOS/Fedora), it is generally recommended to use the OS-specific update command instead (e.g., <B>sudo apt update && sudo apt upgrade azure-cli</B>). Using <B>az upgrade</B> on system package managed installations may lead to conflicts, an inconsistent state, or an incomplete upgrade.<br><B>• Dependency Management:</B> While <B>az upgrade</B> attempts to manage its Python dependencies, issues can arise in complex Python environments, when using virtual environments, or if the underlying <B>pip</B> installation is corrupted.<br><B>• Beta/Preview Versions:</B> By default, <B>az upgrade</B> targets the latest stable release of the <I>Azure CLI</I>. To install preview or beta versions, specific <B>pip</B> commands or alternative installation methods might be necessary.


title: UNDERLYING MECHANISM
content:
The <B>az upgrade</B> command internally utilizes the <B>pip</B> package installer, the standard package management system used to install and manage software packages written in Python. When <B>az upgrade</B> is executed, it essentially translates to running commands similar to <B>pip install --upgrade azure-cli</B> and potentially performing similar upgrade operations for any installed <I>Azure CLI</I> extensions. This means that factors affecting <B>pip</B> (e.g., network proxy settings, Python environment issues, permissions) can also directly impact the success and behavior of <B>az upgrade</B>.


title: INSTALLATION TYPE CONSIDERATIONS
content:
The necessity and optimal usage of <B>az upgrade</B> are highly dependent on how the <I>Azure CLI</I> was originally installed. If the CLI was installed via the official Microsoft installer script (recommended for most users) or directly via <B>pip</B>, then <B>az upgrade</B> is the correct and recommended method for updating. However, if the <I>Azure CLI</I> was installed through a Linux distribution's native package manager (such as <B>apt</B>, <B>yum</B>, or <B>dnf</B>), it is generally best practice to use that system's package upgrade commands (e.g., <B>sudo apt upgrade azure-cli</B>) rather than <B>az upgrade</B>, to maintain system package consistency and avoid potential conflicts.


title: HISTORY
content:
The <B>az upgrade</B> command was introduced as a significant quality-of-life feature within the <I>Azure CLI</I> to streamline and simplify the process of keeping the tool updated. In earlier versions of the <I>Azure CLI</I>, users were required to manually run <B>pip install --upgrade azure-cli</B> (for <B>pip</B> installations) or rely solely on system package managers for updates. This command encapsulates and automates that underlying mechanism, making the update process more user-friendly, less error-prone, and consistent across different environments. Its development reflects a broader trend in modern command-line tools to provide robust self-updating capabilities, thereby reducing manual maintenance overhead and ensuring users always have access to the latest features and security patches.


title: PARAMETERS
content:
<b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show all debug logs.<br><br><b>--help -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the command or subcommand.<br><br><b>--only-show-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show errors, suppressing warnings.<br><br><b>--output -o {json,jsonc,table,tsv,yaml,yamlc,none}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format. Default is json for az version.<br><br><b>--query</b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string to filter or transform the output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity. Use --debug for full debug logs.<br><br>


title: DESCRIPTION
content:
The <I>az-version</I> command, though not a standalone executable in typical Linux distributions, refers to the common practice of obtaining version information for the <I>Azure Command-Line Interface</I> (Azure CLI). This functionality is primarily provided by the <I>az</I> command itself, specifically through the <I>az version</I> subcommand or by passing the <I>--version</I> global argument to <I>az</I>. It displays a comprehensive summary including the Azure CLI version, versions of installed core modules, extensions, the Python runtime used, and the operating system information. This command is crucial for troubleshooting, verifying environment setup, and ensuring compatibility with Azure services. It helps users quickly identify their CLI environment when reporting issues or checking for updates.<br><br>While <I>az-version</I> might be an alias or a misnomer, the underlying command <I>az version</I> is a fundamental utility for anyone working with Azure services via the command line.


title: CAVEATS
content:
This analysis assumes <I>az-version</I> refers to the functionality of retrieving Azure CLI version information, commonly done via <I>az version</I> or <I>az --version</I>, as <I>az-version</I> is not a standard standalone executable. The command requires the Azure CLI to be installed on the system. The output structure can vary slightly between different Azure CLI versions and installed components. Some component versions might appear as 'unknown' if they are not detected or are not relevant to the current installation.


title: TYPICAL OUTPUT
content:
The output of <I>az version</I> is usually a JSON object (by default), providing structured information. It typically includes the <B>azure-cli</B> version, versions of core modules (e.g., <B>azure-cli-core</B>), installed extensions, the <B>Python</B> version, and basic <B>OS</B> details (name, version). This detailed breakdown is invaluable for diagnosing issues related to specific CLI components or environmental factors.


title: TROUBLESHOOTING AID
content:
The <I>az version</I> command is frequently requested by Microsoft support or community forums when users encounter issues. Providing its output helps in quickly understanding the user's CLI setup, identifying potential version mismatches, or outdated components that might be causing problems.


title: HISTORY
content:
The Azure CLI has evolved significantly since its inception. Initially, the cross-platform CLI (Xplat CLI) was based on Node.js and offered basic Azure management capabilities. With the advent of Azure Resource Manager, a new, Python-based Azure CLI 2.0 (now simply Azure CLI) was developed, offering richer functionality and a more consistent experience. The <I>version</I> command (and <I>--version</I> global option) has been a core part of the Azure CLI's utility, enabling users to easily check their environment. Its importance grew with the increasing complexity of Azure services and the need for clear environment information for support and debugging.


title: SEE ALSO
content:
<I>az</I>(1) - The main Azure Command-Line Interface tool., <I>pip</I>(1) - Python package installer, often used for managing Azure CLI installation., <I>python</I>(1) - The Python interpreter, which Azure CLI is built upon.


title: SYNOPSIS
content:
<B>az vm</B> <I>&lt;SUBCOMMAND&gt;</I> [<I>--help</I>] [<I>--output &lt;FORMAT&gt;</I>] [<I>--query &lt;JMESPATH_QUERY&gt;</I>] [<I>GLOBAL_OPTIONS</I>]


title: PARAMETERS
content:
<b><I>&lt;SUBCOMMAND&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the particular VM operation to perform. <i>az vm</i> offers many subcommands such as <b>create</b> (to deploy a new VM), <b>list</b> (to view existing VMs), <b>show</b> (to get details of a specific VM), <b>delete</b> (to remove a VM), <b>start</b>, <b>stop</b>, <b>restart</b> (to manage VM power state), <b>update</b> (to modify VM properties), <b>resize</b> (to change VM size), <b>disk</b> (to manage attached disks), and many more. Each subcommand has its own specific set of required and optional parameters.<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed help information for the <i>az vm</i> command group or a specific subcommand when used with it (e.g., <i>az vm create --help</i>).<br><br><b><I>--output &lt;FORMAT&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the output format of the command. Common formats include <i>json</i> (the default), <i>jsonc</i> (colorized JSON), <i>table</i> (human-readable), <i>tsv</i> (tab-separated values), and <i>yaml</i>.<br><br><b><I>--query &lt;JMESPATH_QUERY&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a JMESPath query string to filter or transform the JSON output data, allowing users to extract specific information.<br><br><b><I>--verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show additional information, including debug logs.<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all debug logs for troubleshooting purposes.<br><br><b><I>--only-show-errors</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the command to only display errors and suppress warnings, useful for scripting.<br><br><b><I>--subscription &lt;SUBSCRIPTION_ID_OR_NAME&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the currently active Azure subscription for the command execution, allowing management of resources across different subscriptions without switching contexts.<br><br>


title: DESCRIPTION
content:
<i>az vm</i> is a command <b>group</b> within the <B>Azure CLI</b> (Command-Line Interface) tool, specifically designed for comprehensive management of virtual machines (VMs) hosted on Microsoft Azure. It provides a robust and scriptable interface to perform various operations related to Azure VMs, ranging from deployment and configuration to monitoring and deletion. <br><br>Unlike a traditional Linux command that executes a single action, <i>az vm</i> acts as a parent command that encompasses a wide array of subcommands. Each subcommand is dedicated to a specific VM management task, allowing users to precisely control their Azure VM infrastructure without needing to navigate the Azure portal. <br><br>Key functionalities accessible through <i>az vm</i> subcommands include deploying new VMs from various pre-configured images (e.g., Ubuntu, Windows Server), listing existing VMs, viewing detailed properties, starting, stopping, restarting, resizing, and deleting VMs. It also supports more advanced operations like managing VM disks, extensions, and network configurations. The Azure CLI, including the <i>az vm</i> group, is cross-platform, running on Linux, macOS, and Windows, making it an indispensable tool for cloud administrators, DevOps engineers, and developers.


title: CAVEATS
content:
The <i>az vm</i> command group requires the <B>Azure CLI</B> to be installed and properly configured on your system. Users must be <B>authenticated</B> to an Azure subscription (typically via <i>az login</i>) with sufficient permissions to manage virtual machines and associated resources (e.g., resource groups, virtual networks, storage accounts). Operations on Azure VMs can incur <B>costs</B> based on the VM size, uptime, storage, and network usage. Always verify resource group, location, and other parameters to prevent unintended resource creation or deletion. Some operations, particularly VM creation, can take several minutes to complete.


title: AUTHENTICATION REQUIREMENT
content:
Before utilizing any <i>az vm</i> subcommand, you must first authenticate to your Azure subscription. This is typically done using the <B>az login</B> command. This command usually opens a web browser for interactive login, or it can be configured for non-interactive logins suitable for automation using service principals.


title: COMMON WORKFLOW EXAMPLE: CREATE A LINUX VM
content:
A very common use case for <i>az vm</i> is creating a new virtual machine. Here's an example to create an Ubuntu VM:<br><br><i>az vm create \<br>&nbsp;&nbsp;--resource-group MyVmResourceGroup \<br>&nbsp;&nbsp;--name MyUbuntuVM \<br>&nbsp;&nbsp;--image UbuntuLTS \<br>&nbsp;&nbsp;--admin-username azureuser \<br>&nbsp;&nbsp;--generate-ssh-keys \<br>&nbsp;&nbsp;--location eastus \<br>&nbsp;&nbsp;--size Standard_B2s</i><br><br>This command deploys an Ubuntu LTS VM named 'MyUbuntuVM' in the 'eastus' region, within 'MyVmResourceGroup', using a specified username and generating SSH keys for authentication.


title: HISTORY
content:
The Azure CLI, including the <i>az vm</i> command group, has evolved significantly as Microsoft's primary cross-platform command-line tool for Azure resource management. It replaced earlier iterations like the Node.js-based XPlat CLI, offering a more consistent and robust Python-based experience. The <i>az vm</i> command group quickly became a cornerstone of the CLI, providing granular control over Azure's core compute service. Its development has continuously focused on improving usability, adding support for new VM features (e.g., new VM sizes, confidential computing), and integrating seamlessly with other Azure services. It stands today as the go-to command-line tool for VM automation and scripting on Azure.


title: SEE ALSO
content:
az login (authenticate to Azure), az group (manage Azure resource groups), az network (manage virtual networks, NICs, public IPs, and security groups), az storage (manage storage accounts and blobs), az disk (manage Azure managed disks), az aks (manage Azure Kubernetes Service clusters), gcloud compute (Google Cloud CLI for compute instances), aws ec2 (AWS CLI for EC2 instances)


title: SYNOPSIS
content:
<b>az webapp</b> <i>&lt;SUBCOMMAND&gt;</i> [<i>&lt;OPTIONS&gt;</i>]<br><br><i>Common Subcommands:</i><br><b>create</b>: Create an Azure web app.<br><b>list</b>: List web apps.<br><b>deploy</b>: Deploy content or images to a web app.<br><b>config</b>: Manage web app configurations.<br><b>browse</b>: Launch the web app in a browser.


title: PARAMETERS
content:
<b>--help | -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b>--resource-group | -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the resource group containing the web app.<br><br><b>--name | -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the web app.<br><br><b>--plan | -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of the App Service plan associated with the web app.<br><br><b>--runtime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The runtime stack for the web app (e.g., 'NODE|18-lts', 'PYTHON|3.9', 'DOTNETCORE|6.0').<br><br><b>--os-type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The OS type of the web app (e.g., 'Linux'). Usually inferred from the plan or runtime.<br><br><b>--deployment-local-git</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable Git deployment from a local Git repository. Returns the Git repository URL.<br><br><b>--deployment-container-image-name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Container image name for Docker deployments (e.g., 'myacr.azurecr.io/myimage:latest').<br><br><b>--slot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the deployment slot. Defaults to 'production'.<br><br><b>--settings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated application settings in 'KEY=VALUE' format.<br><br><b>--startup-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Command or file to launch the app (for Linux custom containers).<br><br>


title: DESCRIPTION
content:
The `az webapp` command is a core component of the Azure CLI, specifically designed for managing web applications hosted on Azure App Service. While it supports both Windows and Linux, for Linux web apps, it facilitates the creation, deployment, configuration, and scaling of applications built with runtimes like Node.js, Python, Java, PHP, .NET Core, or custom Docker containers. It provides a powerful and scriptable interface, enabling automation of DevOps workflows, continuous integration, and continuous deployment (CI/CD) pipelines. This command group offers granular control over various aspects of your web app, from environment variables and connection strings to scaling rules and deployment slots, making it indispensable for cloud application management.


title: CAVEATS
content:
The `az webapp` command is part of the Azure CLI, a cross-platform command-line tool, and is not a native Linux command like `ls` or `grep`. It requires an active Azure subscription and the Azure CLI to be installed and authenticated. Many parameters are context-sensitive to specific subcommands; always refer to `az webapp <SUBCOMMAND> --help` for detailed options. Linux web apps must be hosted on an Azure App Service Plan configured for Linux. Specific runtime versions must be supported by App Service; use `az webapp list-runtimes --linux` to see available options.


title: DEPLOYMENT METHODS
content:
<code>az webapp</code> supports various deployment strategies, including Git deployment (local or remote), Zip deploy, WebDeploy, and direct container image deployments from Docker Hub or Azure Container Registry, offering flexibility for different development workflows.


title: SCALING AND MONITORING
content:
Beyond deployment, the command facilitates scaling operations (manual or auto-scale) and integrates with Azure Monitor for comprehensive logging, metrics collection, and alerting, essential for maintaining application health and performance.


title: CUSTOM DOMAINS AND SSL
content:
Users can easily configure custom domain names and bind SSL/TLS certificates to their web apps directly through `az webapp` commands, ensuring secure and professional web presence.


title: HISTORY
content:
The `az` command is the successor to the deprecated 'azure' CLI. `az webapp` was introduced as part of the modular, Python-based Azure CLI, designed for improved consistency, scriptability, and better integration with cloud-native practices. Its capabilities have steadily expanded to encompass new features of Azure App Service, with particular emphasis on enhanced support for Linux-based applications, custom containers, and various language runtimes, aligning with modern DevOps and containerization trends.


title: SEE ALSO
content:
az group(1): Manage Azure resource groups., az appservice plan(1): Manage Azure App Service plans., az functionapp(1): Manage Azure Function Apps., az containerapp(1): Manage Azure Container Apps., az acr(1): Manage Azure Container Registry.


title: SYNOPSIS
content:
<b>az</b> [<i>global options</i>] <i><group> <command></i> [<i>command options</i>] [<i>arguments</i>]<br><br>Examples:<br><i>az login</i><br><i>az vm create --name myVM --resource-group myResourceGroup --image UbuntuLTS --admin-username azureuser</i><br><i>az group list --output table</i>


title: PARAMETERS
content:
<b><i>--help</i>, <i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for a command or command group. Use <i>az <command> --help</i> to get details on a specific command's arguments and options.<br><br><b><i>--output</i>, <i>-o</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format for the command. Common formats include <i>json</i> (default), <i>jsonc</i> (colorized JSON), <i>table</i>, <i>tsv</i> (tab-separated values), <i>yaml</i>, and <i>none</i>. This is crucial for scripting.<br><br><b><i>--query</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a JMESPath query string to filter or transform the JSON output of a command. This is powerful for extracting specific data points from complex responses.<br><br><b><i>--debug</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show all debug logs, including HTTP requests and responses. Extremely useful for troubleshooting command execution issues.<br><br><b><i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases logging verbosity to show more information during command execution, such as warnings and informational messages, but less than <i>--debug</i>.<br><br><b><i>--only-show-errors</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warnings and informational messages, showing only errors in the output. Ideal for ensuring clean output in automated scripts.<br><br><b><i>--subscription</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Azure subscription ID or name to operate on, overriding the default active subscription. This is useful when managing resources across multiple subscriptions.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the Azure CLI currently installed on your system.<br><br>


title: DESCRIPTION
content:
The <b>Azure CLI</b> is a powerful, cross-platform command-line tool that allows you to connect to Azure and execute administrative commands on Azure resources. It provides a comprehensive set of commands used to create, manage, and delete resources across the entire Azure cloud platform, encompassing services from virtual machines, storage accounts, and networking to more advanced offerings like Azure Kubernetes Service, Azure Functions, and Azure Cosmos DB.<br><br>Written in Python, the Azure CLI is designed for automation and scripting, making it an essential tool for developers, DevOps engineers, and cloud administrators. It supports various authentication methods, including interactive login, service principals, and managed identities, ensuring secure and flexible access to your Azure subscriptions. Commands are logically grouped by service and resource type, providing a consistent and intuitive interface for interacting with Azure resources programmatically.


title: CAVEATS
content:
The Azure CLI requires a Python environment for installation and execution on Linux. All operations performed through the CLI interact with your Azure subscription and can potentially incur costs, depending on the resources created, modified, or consumed. Users must be authenticated to Azure (e.g., via <i>az login</i>) to perform any operations on resources. Furthermore, stable network connectivity to Azure services is essential for the CLI to function correctly.


title: AUTHENTICATION
content:
Before interacting with Azure resources, you must authenticate your Azure CLI session. The most common method is <i>az login</i>, which typically opens a browser for interactive authentication. For automated or non-interactive scenarios, authentication via service principals (using <i>az login --service-principal</i>) or managed identities is supported.


title: MODULAR DESIGN AND EXTENSIONS
content:
The Azure CLI boasts a modular design, meaning core functionalities are kept lean, and commands for specific Azure services or advanced features are often delivered as extensions. This allows users to install only the components they need, enhancing performance and flexibility. Extensions can be installed using <i>az extension add</i>.


title: HISTORY
content:
The Azure CLI has undergone significant evolution since its initial release. The first version, often referred to as CLI 1.0, was built on Node.js. In 2017, Microsoft introduced CLI 2.0, a major rewrite in Python, which became the standard. This transition aimed to enhance cross-platform compatibility, improve modularity, and streamline the developer experience. Since then, it has seen continuous active development with frequent updates and releases, providing new features and supporting the latest Azure services. It is open-source and actively maintained by Microsoft on GitHub, fostering community contributions and transparency.


title: PARAMETERS
content:
<b><b>--blobHost</b> &lt;host&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the host address for the Blob service. Default is 0.0.0.0.<br><br><b><b>--queueHost</b> &lt;host&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the host address for the Queue service. Default is 0.0.0.0.<br><br><b><b>--tableHost</b> &lt;host&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the host address for the Table service. Default is 0.0.0.0.<br><br><b><b>--host</b> &lt;host&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the host address for all services if not specified individually. Default is 0.0.0.0.<br><br><b><b>--blobPort</b> &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port for the Blob service. Default is 10000.<br><br><b><b>--queuePort</b> &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port for the Queue service. Default is 10001.<br><br><b><b>--tablePort</b> &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port for the Table service. Default is 10002.<br><br><b><b>--port</b> &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port for all services if not specified individually.<br><br><b><b>--location</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the workspace path for data persistence. If not set, data is ephemeral.<br><br><b><b>--debug</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging to a specified file path.<br><br><b><b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables startup and request logs, showing only error logs.<br><br><b><b>--loose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables loose mode, handling unsupported headers or parameters more leniently.<br><br><b><b>--cert</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a PEM-encoded TLS certificate file for HTTPS.<br><br><b><b>--key</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a PEM-encoded TLS private key file for HTTPS.<br><br><b><b>--oauth</b> &lt;level&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets OAuth authentication level (<i>basic</i>, <i>proxy</i>, or <i>metadata</i>).<br><br><b><b>--skipApiVersionCheck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the API version compatibility check, allowing older client SDKs to connect.<br><br><b><b>--disableProductStyleUrl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables product style URL for blob service.<br><br><b><b>--connectionString</b> &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a full connection string to configure Azurite.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Azurite version number.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and usage details.<br><br>


title: DESCRIPTION
content:
<b>Azurite</b> is an open-source, cross-platform storage emulator that mimics the Azure Blob, Queue, and Table storage services. It allows developers to test their applications locally without incurring Azure costs or requiring an internet connection.<br><br>Built with Node.js, Azurite is a crucial tool for development workflows involving Azure storage, providing a consistent environment for testing various storage operations like uploading blobs, sending queue messages, or managing table entities. It supports features such as CORS (Cross-Origin Resource Sharing), Shared Access Signatures (SAS), and various authentication methods, making it highly versatile for modern application development.


title: CAVEATS
content:
<b>Azurite</b> is not a standard, pre-installed Linux command; it requires Node.js and npm (or Docker) for installation. As an emulator, it does not support all advanced features or edge cases of the actual Azure Storage services. It is intended for local development and testing, not for production deployments. Data stored by Azurite is local and ephemeral by default, requiring the <i>--location</i> option for persistence.


title: INSTALLATION
content:
The most common way to install <b>Azurite</b> on Linux is via Node Package Manager (npm):<br><i>npm install -g azurite</i><br>Alternatively, it can be run using Docker: <br><i>docker run -p 10000:10000 -p 10001:10001 -p 10002:10002 mcr.microsoft.com/azure-storage/azurite</i>


title: DATA PERSISTENCE
content:
By default, <b>Azurite</b> stores data in memory or a temporary directory, meaning data is lost when the command exits. To persist data across sessions, use the <i>--location</i> option to specify a local directory where Azurite will store its data files.


title: HISTORY
content:
Prior to <b>Azurite</b>, Microsoft offered the Azure Storage Emulator, which was primarily a Windows-only .NET-based application. With the increasing adoption of cross-platform development, <b>Azurite</b> was developed as its open-source, Node.js-based successor to provide a consistent storage emulation experience across Windows, macOS, and Linux. Its development has focused on mimicking Azure storage APIs accurately to streamline local testing workflows.


title: SYNOPSIS
content:
<b>b2</b> [<i>global-options</i>] &lt;<i>command</i>&gt; [<i>command-options</i>] [<i>arguments</i>]<br><br>Examples:<br>  <b>b2</b> <i>ls</i> --buckets<br>  <b>b2</b> <i>upload_file</i> <i>my-bucket</i> <i>local-file.txt</i> <i>remote-path/file.txt</i><br>  <b>b2</b> <i>sync</i> --delete <i>local-dir/</i> <i>b2://my-bucket/remote-dir/</i>


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the <b>b2</b> command or a specific subcommand, detailing its usage and available options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits, useful for verifying the installed version.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, which can be very helpful for troubleshooting issues or understanding internal operations.<br><br><b>--info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints informative messages about the command's execution, providing a higher level of detail than default output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages, often providing more progress or action details.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages, making it suitable for scripting where only errors or final results are desired.<br><br><b>--color {always,auto,never}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the use of colored output in the terminal for enhanced readability of different message types.<br><br><b>--non-interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables interactive prompts, ensuring the command can run without user input, which is essential for automation.<br><br><b>--profile &lt;profile_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a named profile from the configuration file to use for authentication and settings, allowing management of multiple B2 accounts.<br><br><b>&lt;command&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A specific operation to perform on B2, such as <i>authorize_account</i>, <i>ls</i> (list files/buckets), <i>upload_file</i>, <i>download_file</i>, <i>sync</i>, and many others. Each subcommand has its own unique set of specific options and arguments.<br><br>


title: DESCRIPTION
content:
The <b>b2-tools</b> utility provides a comprehensive command-line interface for interacting with Backblaze B2 Cloud Storage. It enables users to perform a wide range of operations, including managing buckets, uploading and downloading files, listing file versions, and handling large file operations. Designed for automation and scripting, <b>b2-tools</b> offers robust functionality for integrating Backblaze B2 into various workflows and scripts. It supports multiple authentication methods, such as environment variables and configuration files, and efficiently manages B2's unique file versioning and large file architecture. Its design makes it an essential tool for developers and system administrators looking to programmatically interact with their B2 data, offering capabilities from simple file transfers to complex synchronization tasks.


title: CAVEATS
content:
Authentication is critical: <b>b2-tools</b> requires valid Backblaze B2 Application Key IDs and Application Keys for access. These are typically set as environment variables (e.g., <i>B2_APPLICATION_KEY_ID</i> and <i>B2_APPLICATION_KEY</i>) or configured persistently via the <i>b2 authorize_account</i> command. Performance for large file operations is highly dependent on network stability and available bandwidth. Users should also be aware that all operations on Backblaze B2, including storage, downloads, and certain API calls, incur costs. The tool itself is written in Python and requires a compatible Python environment to be installed.


title: SUBCOMMAND-BASED OPERATION
content:
The core functionality of <b>b2-tools</b> is structured around a rich set of subcommands, where <b>b2</b> acts as a dispatcher. This modular design allows for clear, distinct operations. For instance, to upload a file, you use <i>b2 upload_file</i>; to list buckets, you use <i>b2 ls --buckets</i>. Each subcommand is self-contained with its own specific options and arguments, which can be easily discovered by appending <i>--help</i> to the subcommand (e.g., <i>b2 upload_file --help</i>).


title: CONFIGURATION AND PROFILES
content:
Authorization credentials and other persistent settings for <b>b2-tools</b> are typically stored in a configuration file, often located at <i>~/.b2_account_info</i>. This file facilitates persistent sessions, meaning you don't need to re-authorize for every command. Furthermore, it supports the management of multiple Backblaze B2 accounts or profiles, which can be conveniently switched using the <i>--profile</i> global option, making it ideal for users managing data across different accounts.


title: POWERFUL SYNC COMMAND
content:
One of the most frequently used and powerful features of <b>b2-tools</b> is the <i>b2 sync</i> subcommand. This command provides highly efficient synchronization of local directories with B2 buckets, functioning similarly to tools like <i>rsync</i> or <i>aws s3 sync</i>. It intelligently detects changes, handles deletions (with the <i>--delete</i> option), and manages large file uploads and downloads incrementally, making it an indispensable tool for backup, disaster recovery, and data migration tasks.


title: HISTORY
content:
<b>b2-tools</b> was developed by Backblaze, Inc. as the official command-line interface for their B2 Cloud Storage service. It was created to provide a robust programmatic way for users and applications to interact with B2, complementing the web UI and direct API. Written in Python, it is maintained as an open-source project, allowing for community contributions and transparent development. Its evolution has focused on expanding functionality (e.g., the powerful <i>sync</i> command), improving performance, and ensuring seamless compatibility with new B2 features and services, establishing itself as a key tool for data management on the platform.


title: PARAMETERS
content:
<b>-b, --binary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read files in binary mode. This is often the default, but ensures consistent handling across platforms.<br><br><b>-t, --text</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read files in text mode, where carriage returns are ignored for compatibility.<br><br><b>-c, --check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read BLAKE2b checksums from the specified FILEs and verify them. The input format is typically 'checksum filename'.<br><br><b>--tag</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a BSD-style checksum. This includes a label like "BLAKE2b (filename) = checksum".<br><br><b>-l, --length=BITS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the digest length in bits. The value must be between 1 and 512. Default is 512 bits.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress messages about successful checks when using <i>--check</i>.<br><br><b>-s, --status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't output anything; the exit status indicates success or failure.<br><br>


title: DESCRIPTION
content:
The <b>b2sum</b> command is a utility for computing and verifying <br>BLAKE2b cryptographic checksums (or message digests) of files or standard input.<br><br>Developed as a modern alternative to older hash functions like MD5 or SHA-1, <br>BLAKE2b offers a superior balance of speed and security. It is significantly faster <br>than SHA-3, often comparable to MD5 or SHA-1 in speed, while providing a <br>much higher level of cryptographic strength and collision resistance. <br><br><b>b2sum</b> is commonly used to ensure data integrity and authenticity. By generating <br>a unique checksum for a file, users can later verify that the file has not <br>been altered or corrupted during transmission or storage. If a single bit <br>in the file changes, the resulting BLAKE2b checksum will be drastically different. <br>When used with the <i>--check</i> option, it can read a list of checksums <br>from a file and verify them against the actual files.


title: CAVEATS
content:
1. <i>One-Way Function:</i> Cryptographic hash functions like BLAKE2b are designed to be one-way; it is computationally infeasible to reverse the hash to obtain the original data.<br>2. <i>Collision Resistance:</i> While BLAKE2b is highly resistant to collisions (two different inputs producing the same hash), no hash function is perfectly collision-free in theory. However, for practical purposes, BLAKE2b is considered extremely secure.<br>3. <i>Digest Length:</i> Using the <i>--length</i> option to produce a shorter digest (e.g., less than 512 bits) reduces the collision resistance and cryptographic strength of the hash. This should only be done if the specific application warrants a smaller digest and accepts the reduced security margin.


title: BLAKE2B VS. BLAKE2S
content:
BLAKE2 is actually a family of two hash functions: BLAKE2b and BLAKE2s. <b>b2sum</b> specifically implements BLAKE2b, which is optimized for 64-bit platforms and produces digests up to 512 bits. BLAKE2s is optimized for 32-bit platforms and produces digests up to 256 bits. The "b" in <b>b2sum</b> signifies its use of the BLAKE2b algorithm, making it ideal for general-purpose high-security and high-speed hashing on modern systems.


title: HISTORY
content:
The BLAKE2 hash function, upon which <b>b2sum</b> is based, was published in 2012 by A. Biryukov, D. Dinu, and J. M. S. Neves. It was designed to improve upon BLAKE and offer a compelling alternative to SHA-3 by focusing on speed and security. Its inclusion in GNU Coreutils, which provides fundamental command-line utilities for Linux and other Unix-like operating systems, followed its widespread adoption and recognition as a high-performance and secure cryptographic hash function. <b>b2sum</b> provides users with a modern, fast, and robust tool for data integrity verification, complementing the existing suite of <i>*sum</i> commands.


title: PARAMETERS
content:
<b>--check, -c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read BLAKE3 sums from the <i>FILE</i>s and check them against computed sums.<br><br><b>--ignore-missing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking, don't report or exit with non-zero status for missing files.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking, don't print <i>OK</i> for each successfully verified file.<br><br><b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking, don't output anything, exit status shows success.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking, exit non-zero for any improperly formatted checksum line.<br><br><b>--tag</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a BSD style checksum (e.g., <br><i>BLAKE3 (file) = hash</i>).<br><br><b>--text</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat input as text (handling line endings for cross-platform compatibility).<br><br><b>--binary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat input as binary (often the default for exact byte-for-byte hashing).<br><br><b>-w, --warn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When checking, warn about improperly formatted checksum lines.<br><br><b>--zero</b><br>&nbsp;&nbsp;&nbsp;&nbsp;End each output line with NUL, not newline (for use with <br><i>xargs -0</i>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>b3sum</i> is a command-line utility used to compute and verify BLAKE3 (BLAKE3-256) cryptographic checksums or hashes of files. Like other "sum" utilities (e.g., <i>md5sum</i>, <i>sha256sum</i>), its primary purpose is to ensure data integrity. BLAKE3 is a modern, fast, and cryptographically secure hash function designed for high performance, especially on multi-core processors, making it suitable for hashing very large files or directories efficiently. <br><br> When invoked, <i>b3sum</i> reads input from the specified <i>FILE</i>s or from standard input if no files are given. For each input, it computes a unique BLAKE3 hash and prints it to standard output, typically followed by the filename. The generated hash can then be stored and later used to verify if the file has been altered or corrupted. The command also provides an option to check sums against a list of hashes provided in a file, confirming the integrity of multiple files at once.


title: CAVEATS
content:
While BLAKE3 is highly optimized and secure, it is a relatively new hash function (developed in 2019). Therefore, its adoption and native support in all tools and systems might not be as widespread as older algorithms like SHA-256 or MD5. Users should ensure that the recipient or target system also has <i>b3sum</i> or BLAKE3 support if sharing checksums for verification.


title: COMMON USAGE
content:
To compute the hash of a single file: <br><i>b3sum myfile.txt</i><br><br>To compute hashes of multiple files:<br><i>b3sum file1.txt file2.zip</i><br><br>To read from standard input:<br><i>echo "hello" | b3sum</i><br><br>To save a checksum to a file:<br><i>b3sum largefile.iso > largefile.iso.b3sum</i>


title: VERIFYING CHECKSUMS
content:
To verify a checksum file:<br><i>b3sum -c largefile.iso.b3sum</i><br><br>If all files match, <i>b3sum</i> will report "<i>OK</i>" for each. If a file does not match, it will report "<i>FAILED</i>". The exit status will be non-zero if any check fails.


title: HISTORY
content:
BLAKE3 is a cryptographic hash function developed by a team of cryptographers and software engineers (Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn, and others) in 2019. It was designed to be significantly faster than previous hash functions like SHA-2 and SHA-3, while maintaining strong security properties and supporting parallelism. The <i>b3sum</i> utility is an implementation of this algorithm, often provided as part of GNU Core Utilities or as a standalone package, allowing Linux users to leverage BLAKE3 for data integrity checks. Its development reflects the ongoing need for faster and more efficient cryptographic primitives in modern computing environments, especially with increasing data sizes and multi-core processor architectures.


title: SYNOPSIS
content:
<b>babel</b> [<i>input_options</i>] <i>input_file</i> [<i>output_options</i>] <i>output_file</i> [<i>conversion_options</i>]<br>Example: <b>babel</b> <b>-isdf</b> <i>input.sdf</i> <b>-osmi</b> <i>output.smi</i> <b>-c</b>


title: PARAMETERS
content:
<b><b>-i</b><i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file format (e.g., <I>smi</I> for SMILES, <I>mol</I> for Molfile).<br><br><b><b>-o</b><i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file format (e.g., <I>sdf</I> for SDF, <I>inchi</I> for InChI).<br><br><b><b>-O</b><i><outfile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output filename. If omitted, output goes to standard output.<br><br><b><b>-f</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start reading from the N-th molecule in a multi-molecule file.<br><br><b><b>-l</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop reading after the N-th molecule.<br><br><b><b>-s</b> <i><SMARTS></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select molecules that match the provided <I>SMARTS</I> pattern.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add hydrogens to the molecule(s).<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete hydrogens from the molecule(s).<br><br><b><b>-p</b> <i><pH></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add hydrogens appropriate for a given pH (protonation).<br><br><b><b>-gen3d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate 3D coordinates for the molecule(s).<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Canonicalize <I>SMILES</I> string (typically used with <I>SMILES</I> output).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output, showing progress and details during conversion.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a comprehensive help message with all available options.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information for the <I>Open Babel</I> library and program.<br><br>


title: DESCRIPTION
content:
<b>babel</b> is a command-line utility from the <I>Open Babel</I> project, a comprehensive chemical informatics software package. It serves as a versatile tool for converting between a vast array of chemical file formats, manipulating chemical data, and performing various operations such as calculating molecular properties, generating 3D coordinates, or adding/removing hydrogens. Supporting over 100 file formats, <b>babel</b> is indispensable for chemists, cheminformaticians, and materials scientists needing to interoperate between different chemical software environments. While <I>obabel</I> is the more modern and primary command-line interface, <b>babel</b> often acts as a legacy interface or alias, providing similar powerful capabilities.


title: CAVEATS
content:
The <b>babel</b> command is largely superseded by <b>obabel</b>, which is the primary and more actively developed command-line interface for <I>Open Babel</I>. Users are generally advised to use <b>obabel</b> for new scripts and workflows to ensure access to the latest features and bug fixes. The sheer number of supported file formats and options can make the command line interface complex for new users.


title: EXTENSIVE FILE FORMAT SUPPORT
content:
<b>babel</b> supports over 100 chemical file formats, including common ones like SMILES, SDF, Mol2, CML, PDB, XYZ, and InChI. A full list of supported formats and their specific options can typically be obtained by running <b>babel --list-formats</b> or <b>obabel --list-formats</b>.


title: SCRIPTING AND AUTOMATION
content:
Due to its command-line nature and extensive capabilities, <b>babel</b> (or <b>obabel</b>) is widely used in shell scripts and automated workflows for high-throughput chemical data processing, integration with computational chemistry pipelines, and database population.


title: HISTORY
content:
The <I>Open Babel</I> project, including the <b>babel</b> command, originated in 2000 as a fork of the original <I>Babel</I> program developed by Peter Murray-Rust and others. The initial <b>babel</b> command served as the primary command-line tool for chemical file format conversions. Over time, as the <I>Open Babel</I> library evolved, a more consistent and feature-rich interface named <b>obabel</b> was introduced. While <b>obabel</b> is now the recommended tool, <b>babel</b> is often retained for backward compatibility, sometimes as a symbolic link to <b>obabel</b> or an older wrapper around the library.


title: PARAMETERS
content:
<b>-I <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads configuration directives from <i>filename</i>.<br><br><b>-S <i>&lt;state-file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <i>state-file</i> for storing persistent state across restarts.<br><br><b>-H <i>&lt;interval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default hello interval in centiseconds for interfaces.<br><br><b>-g <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an interface to be managed by <i>babeld</i>. Can be specified multiple times.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redistributes routes from other routing tables into Babel.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables split horizon on interfaces, preventing routing loops on point-to-point links.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not daemonize; run in the foreground (useful for debugging).<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not manipulate the kernel routing table (primarily for testing and debugging).<br><br><b>-m <i>&lt;metric&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default metric for routes learned via Babel.<br><br><b>-A <i>&lt;address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a local address to be advertised by Babel.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output to stderr or log file.<br><br><b>-L <i>&lt;log-file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs output to the specified <i>log-file</i> instead of syslog.<br><br><b>-P <i>&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the UDP port number for Babel communication (default 6696).<br><br><b>-W <i>&lt;pid-file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the daemon's PID to the specified <i>pid-file</i>.<br><br><b>-C <i>&lt;config-option&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a configuration option directly, e.g., '<i>-C 'ipv6-prefix 2001:db8::/32'</i>'.<br><br><b>-U <i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops privileges to the specified user after initial setup.<br><br><b>-c <i>&lt;ipv4-prefix&gt;</i>/<i>&lt;len&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advertises the specified IPv4 prefix into the Babel network.<br><br><b>-w <i>&lt;ipv6-prefix&gt;</i>/<i>&lt;len&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advertises the specified IPv6 prefix into the Babel network.<br><br><b>-G</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the global metric feature for better path selection.<br><br><b>-T</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds timestamps to log messages.<br><br>


title: DESCRIPTION
content:
<i>babeld</i> is a daemon that implements the Babel routing protocol, a loop-avoiding distance-vector routing protocol operating over both IPv4 and IPv6. It's particularly well-suited for dynamic and mobile ad-hoc networks (MANETs), but also functions efficiently in wired networks. <i>babeld</i> discovers and maintains routes to destinations within a network, adapting quickly to topology changes, link failures, and new nodes. It uses sequence numbers to avoid routing loops and relies on metrics (like hop count and bandwidth estimation) to choose optimal paths. This protocol provides a lightweight yet robust routing solution, making it ideal for smaller to medium-sized networks, especially those with frequently changing topologies where more complex protocols like OSPF or BGP might be overkill.


title: CAVEATS
content:
<i>babeld</i> does not inherently provide authentication for routing updates, making it susceptible to malicious injection in unsecured environments. It is primarily designed as an Interior Gateway Protocol (IGP) and is not intended for inter-domain routing like BGP. Advanced configurations may require a deep understanding of network routing principles and Babel's specific metrics.


title: CONFIGURATION FILES
content:
<i>babeld</i> commonly uses <i>/etc/babeld.conf</i> as its default configuration file. This file can contain many of the options that can be passed via command-line arguments, allowing for persistent and complex setups without lengthy command-line invocations.


title: DAEMONIZATION AND PRIVILEGES
content:
By default, <i>babeld</i> operates as a background daemon. It typically starts with root privileges to configure network interfaces and routing tables, but it is strongly recommended to use the <i>-U</i> option to drop privileges to a less privileged user after initial setup for security reasons.


title: HISTORY
content:
The Babel routing protocol was first formally described in RFC 6126 in 2011, later updated by RFC 8966 in 2021. It was designed as a robust and efficient routing protocol for dynamic and mobile ad-hoc networks (MANETs), aiming to provide quick convergence and loop avoidance with low overhead. <i>babeld</i> is a widely used open-source implementation of this protocol, developed to bring the benefits of Babel to Linux and other Unix-like systems, addressing challenges that traditional routing protocols often face in rapidly changing network topologies.


title: PARAMETERS
content:
<b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game in automatic mode, potentially skipping initial prompts or accelerating certain game phases.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging mode, providing verbose output that can assist in understanding game logic or troubleshooting issues.<br><br><b><i>-p program</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate backgammon playing program to be used as the opponent's AI, instead of the default internal logic.<br><br>


title: DESCRIPTION
content:
The <b>backgammon</b> command provides a classic, text-based interface for playing the traditional board game of backgammon against a computer opponent. It is typically found as part of the <i>bsd-games</i> package on Unix-like operating systems. The game board, checkers, and dice rolls are represented using ASCII characters in the terminal, offering a minimalist yet functional gameplay experience. Players take turns rolling dice and moving their checkers according to standard backgammon rules, with the objective of bearing off all their checkers before the opponent. This utility serves as a historical example of early interactive computing entertainment, suitable for environments without graphical capabilities.


title: CAVEATS
content:
This command is a very old, text-based implementation, which lacks modern graphical interfaces and advanced AI found in contemporary backgammon applications. Its display relies purely on ASCII characters, and its appearance and functionality can be dependent on the terminal's capabilities and font settings.


title: IN-GAME COMMANDS
content:
Once the game starts, users interact with the <b>backgammon</b> command using specific text-based commands. Common commands include:<br><i>roll</i>: Rolls the dice to determine valid moves.<br><i>move from to</i>: Moves a checker from a specified point to another.<br><i>double</i>: Offers a double to the opponent, raising the stakes.<br><i>save [file]</i>: Saves the current game state to a specified file.<br><i>restore [file]</i>: Restores a previously saved game from a file.<br><i>quit</i>: Exits the game.<br><i>print</i>: Redraws the board display on the terminal.<br><i>t</i>: Displays information about the current game rules and settings.


title: HISTORY
content:
The <b>backgammon</b> command is a venerable component of the Unix/Linux ecosystem, tracing its origins back to early Berkeley Software Distribution (BSD) releases, where it was a staple of the <i>bsd-games</i> package. It reflects an era when text-based games were a common form of interactive computing on operating systems. Its continued presence across various Unix-like distributions for decades underscores its status as a classic piece of computing history, offering simple entertainment without demanding graphical resources.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--set</b> <i>VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display brightness to a specified <i>VALUE</i>. The <i>VALUE</i> typically represents a percentage (e.g., 50 for 50%) or an absolute brightness level, depending on implementation.<br><br><b><b>-g</b>, <b>--get</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves and displays the current brightness level of the display.<br><br><b><b>-u</b>, <b>--up</b> [<i>INCREMENT</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the display brightness. An optional <i>INCREMENT</i> value (e.g., 5 or 10) specifies by how much to increase it; if omitted, a default increment is often used.<br><br><b><b>-d</b>, <b>--down</b> [<i>DECREMENT</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decreases the display brightness. An optional <i>DECREMENT</i> value specifies by how much to decrease it; if omitted, a default decrement is often used.<br><br><b><b>--max</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display brightness to its maximum possible level.<br><br><b><b>--min</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display brightness to its minimum possible level.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and available options.<br><br>


title: DESCRIPTION
content:
The command <i>backlight_control</i> is <b>not a standard Linux command</b>. It is typically a custom user-defined script, an alias, or a function provided by a specific distribution, desktop environment, or personal configuration to simplify the process of adjusting screen brightness. <br><br>Its primary purpose would be to act as a convenient wrapper around lower-level backlight control mechanisms available in Linux. These underlying mechanisms commonly include: <br>- The <b>/sys/class/backlight/</b> kernel interface, which exposes brightness control directly to userspace.<br>- Utilities like <b>xbacklight</b> or <b>brightnessctl</b>, which are more common command-line tools for backlight management.<br>- The <b>xrandr</b> utility for Xorg, which can control brightness on certain display outputs.<br><br>The specific functionality and options of <i>backlight_control</i> would entirely depend on how it is implemented on a given system.


title: CAVEATS
content:
As <i>backlight_control</i> is not a standard Linux command, its presence and functionality depend entirely on custom scripting or specific system configurations. <br><br>Users should be aware of the following:<br>- <b>Non-Standard:</b> It is not universally available across all Linux distributions or setups.<br>- <b>Implementation Dependent:</b> Its behavior, options, and underlying method of brightness control (e.g., <b>/sys/class/backlight</b>, <b>xrandr</b>, <b>brightnessctl</b>) are determined by its creator.<br>- <b>Permissions:</b> Controlling backlight often requires appropriate permissions, typically involving root access or membership in specific groups (e.g., video, input) to interact with kernel interfaces.<br>- <b>Hardware and Driver Specifics:</b> Backlight control can vary significantly between different hardware (e.g., Intel, AMD, NVIDIA GPUs) and their respective drivers.<br>


title: <B>/SYS/CLASS/BACKLIGHT/ INTERFACE</B>
content:
The primary and most robust method for controlling display backlight on Linux at a low level is through the <b>/sys/class/backlight/</b> pseudo-filesystem. This interface is exposed by the kernel and provides a standardized way to interact with backlight devices. <br><br>Inside this directory, you'll typically find subdirectories corresponding to detected backlight devices (e.g., <i>intel_backlight</i>, <i>acpi_video0</i>, <i>amdgpu_bl0</i>). Within each device directory, important files include:<br>- <b>brightness:</b> A file whose integer value represents the current brightness level.<br>- <b>max_brightness:</b> An integer value indicating the maximum possible brightness level for the device.<br>- <b>actual_brightness:</b> The actual current brightness as reported by the hardware.<br><br>To change brightness, a user (with appropriate permissions) would write a new integer value to the <b>brightness</b> file, typically after scaling it based on <b>max_brightness</b>.


title: HISTORY
content:
There is no official history for a generic <i>backlight_control</i> command, as it is not a part of standard Linux utilities. Such commands typically emerge from individual users or community projects aiming to provide a simpler, more intuitive interface for a common system task (like brightness control) that otherwise might require more complex or less user-friendly commands (e.g., writing directly to <b>/sys/class/backlight</b> files). These scripts often become part of personal dotfiles, smaller utility packages, or distribution-specific enhancements.


title: PARAMETERS
content:
<b>-n &lt;count&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>number</i> of times 'bacon' should be outputted. If omitted, it typically outputs once.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a 'sizzling' effect or related text to the output, for extra culinary flair.<br><br><b>-f &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Redirects</i> the output of 'bacon' into the specified file instead of standard output.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief <i>help message</i> detailing the command's usage and available options.<br><br>


title: DESCRIPTION
content:
The 'bacon' command is <i>not a standard or widely recognized utility</i> found in most Linux distributions. Unlike core system commands, it does not ship with the operating system and is not part of the GNU Core Utilities or other common software packages. Instead, it is primarily encountered as a <br>custom script or alias created by users for humorous purposes, a simple programming exercise, or a demonstration of basic shell scripting capabilities. <br><br>If it were to exist as a commonly adopted command, a typical 'bacon' implementation would simply output the word 'bacon' to the standard output, often with additional options. These might include controlling the quantity of 'bacon' output or adding simulated 'sizzling' effects. It serves no critical system function but can be a lighthearted and personalized addition to a user's shell environment.


title: CAVEATS
content:
The 'bacon' command is <i>not pre-installed</i> on Linux systems and must be manually created by the user. Its functionality and options are entirely dependent on how the user implements it, meaning its behavior can vary widely or it might not exist at all on a given system.


title: HISTORY
content:
The 'bacon' command lacks a formal development history as a standard Unix or Linux utility. Its prevalence stems from its use as a common example in introductory scripting tutorials or as a personal, humorous addition to shell environments. It embodies the flexibility of the Linux command line, where users can easily define their own commands for specific, often whimsical, purposes. Its 'development' is decentralized, occurring whenever a user decides to create a simple script by that name.


title: PARAMETERS
content:
<b>-b <i>block_size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the block size in bytes for the scan. Default is 1024 bytes.<br><br><b>-c <i>num_blocks</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of blocks to test at a time during the scan.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the check, even if the device is mounted. Use with extreme caution.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a non-destructive read-write test. This mode writes a test pattern, verifies, then restores the original data.<br><br><b>-o <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the list of found bad blocks to the specified file, one block number per line.<br><br><b>-p <i>num_passes</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of passes over the device. Default is 1 pass.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the progress of the scan by printing percentages.<br><br><b>-t <i>test_pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a test pattern. Can be a numeric pattern (e.g., 0xaa, 0x55, 0xff, 0x00) or 'random' for a random pattern.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose mode, providing more detailed information during the scan.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a destructive write-test mode. This writes test patterns to every block and verifies. <br><b><I>WARNING: This will destroy ALL data on the device.</I></b><br><br><b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device or partition to be scanned (e.g., /dev/sda1, /dev/sdb).<br><br><b><i>block_count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of blocks to check, starting from <i>start_block</i>. If omitted, checks to the end of the device.<br><br><b><i>start_block</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The starting block number from which to begin the scan. If omitted, starts from block 0.<br><br>


title: DESCRIPTION
content:
<b>badblocks</b> is a utility program for testing block devices (like hard drives, SSDs, or partitions) for bad blocks. It performs a comprehensive scan, identifying sectors that cannot be reliably read or written due to physical damage or corruption. The primary use case is to locate these faulty blocks <i>before</i> creating a filesystem with <b>mkfs</b> or <i>after</i> a filesystem has been created using <b>e2fsck</b>. By marking these bad blocks, the filesystem avoids writing data to them, thereby preventing data loss and ensuring the integrity of stored information. It supports both non-destructive read-only or read-write tests and a more thorough, but destructive, write-test mode. It is an integral part of the <b>e2fsprogs</b> suite of utilities, commonly used with ext2, ext3, and ext4 filesystems.


title: CAVEATS
content:
<ul><li><b><I>Data Loss:</I></b> The <b>-w</b> (write-test) option is destructive and will erase all data on the target device. Always double-check the device name before running this mode.</li><li><b><I>Unmounted Device:</I></b> It is highly recommended to run <b>badblocks</b> on an unmounted device or partition to avoid data corruption and ensure accurate results. If the device is mounted, use the <b>-f</b> option with extreme caution.</li><li><b><I>Time Consuming:</I></b> Scanning large drives, especially with multiple passes or in write-test mode, can take a very long time (hours to days) to complete.</li><li><b><I>Permissions:</I></b> Running <b>badblocks</b> typically requires root privileges.</li></ul>


title: TYPICAL WORKFLOW
content:
The most common workflow involves running <b>badblocks</b> on a new or problematic drive (preferably unmounted) and directing its output to a file using the <b>-o</b> option. For example: <br><b><pre>sudo badblocks -svw -o bad_blocks.txt /dev/sdb</pre></b><br>(<i>destructive scan, output to file</i>) <br>or <br><b><pre>sudo badblocks -svno bad_blocks.txt /dev/sdb</pre></b><br>(<i>non-destructive scan, output to file</i>). <br><br>This <b>bad_blocks.txt</b> file, containing the list of bad block numbers, can then be passed to <b>mkfs</b> when creating a filesystem, or to <b>e2fsck</b> to mark existing bad blocks within an already created filesystem. For instance: <br><b><pre>sudo mkfs.ext4 -l bad_blocks.txt /dev/sdb1</pre></b><br>or <br><b><pre>sudo e2fsck -l bad_blocks.txt /dev/sdb1</pre></b><br>This ensures that the filesystem avoids using the damaged sectors, preventing data corruption.


title: HISTORY
content:
The <b>badblocks</b> utility has been a long-standing component of the <b>e2fsprogs</b> package, which provides essential utilities for the ext2, ext3, and ext4 filesystems in Linux. Its development has closely tracked the evolution of these filesystems, providing a foundational tool for ensuring the reliability and data integrity of storage media before or after filesystem creation. It has been a standard part of most Linux distributions for many years, serving as a critical diagnostic and preparatory tool for disk management.


title: SYNOPSIS
content:
<br><b>balena</b> [<I>GLOBAL_OPTIONS</I>] <I>COMMAND</I> [<I>SUBCOMMAND</I>] [<I>OPTIONS</I>] [<I>ARGS</I>...]<br><br>The <b>balena</b> command operates with a command-subcommand structure. Global options apply to the entire CLI invocation, while specific options and arguments are relevant to the chosen command and its subcommand. Common top-level commands include <b>login</b>, <b>logout</b>, <b>push</b>, <b>deploy</b>, <b>devices</b>, <b>apps</b>, <b>help</b>, <b>config</b>, and <b>os</b>.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the specific command or subcommand.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the balena CLI.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output for troubleshooting.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats command output as JSON, useful for scripting.<br><br><b>--visual</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a visual progress display for operations like <b>balena push</b>.<br><br><b>--pipe</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strips extra formatting from output, suitable for piping to other commands.<br><br><b>--token <I>token</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>balena login</b> to authenticate using an API token instead of interactive login.<br><br><b>--source <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>balena push</b> to specify the project directory of the application to be deployed.<br><br><b>--build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>balena push</b> to force a complete rebuild of application images on the balenaCloud builders, even if not strictly necessary.<br><br><b>--dont-start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>balena push</b> to prevent services from starting immediately after deployment, useful for staged rollouts.<br><br><b>--app <I>name_or_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with commands like <b>balena devices</b> or <b>balena logs</b> to filter results by a specific application.<br><br>


title: DESCRIPTION
content:
The <b>balena</b> command-line interface (CLI) is the primary tool for interacting with the balenaCloud platform, a comprehensive ecosystem designed for developing, deploying, and managing fleets of internet-connected embedded devices. It provides a robust set of functionalities for the entire IoT device lifecycle, from initial provisioning and setup to continuous deployment and remote management. Users can leverage <b>balena</b> to push applications to specific devices or entire fleets, monitor device status and logs, SSH into running containers or the host OS, and perform various administrative tasks like creating new applications or adding devices. It abstracts complex device management operations, enabling developers and operators to efficiently build, deploy, and scale IoT solutions across diverse hardware. The CLI supports local development workflows and seamless integration with balenaCloud's over-the-air update capabilities, making it indispensable for modern IoT development.


title: CAVEATS
content:
The <b>balena</b> CLI requires an active balenaCloud account and internet connectivity to operate effectively, as it primarily interacts with the remote balenaCloud platform. It is not a standard, pre-installed Linux utility and must be installed separately, typically via npm or a standalone installer. Users should be aware that large application pushes or OS downloads can consume significant network bandwidth and may take considerable time depending on internet speed and project size. Development on cross-architecture devices might require careful management of build environments or reliance on balenaCloud builders.


title: SUBCOMMAND MODULARITY
content:
The <b>balena</b> CLI is highly modular, organized into numerous subcommands (e.g., <b>balena login</b>, <b>balena push</b>, <b>balena devices</b>, <b>balena help</b>). Each subcommand manages specific aspects of the balena ecosystem, offering a focused set of options and arguments. Users can explore available commands and their usage via <b>balena help</b> or <b>balena help <I>command</I></b>.


title: INTEGRATION WITH BALENACLOUD
content:
While runnable locally, the <b>balena</b> CLI is primarily designed to interact with the balenaCloud platform. Most of its functionalities, such as deploying applications, managing devices, and accessing logs, rely on authenticated communication with balenaCloud services. This integration enables powerful remote management and over-the-air updates for vast fleets of devices.


title: LOCAL MODE DEVELOPMENT
content:
A significant feature of <b>balena</b> is its support for 'local mode' development. By pushing code directly to a local device's IP address (e.g., <b>balena push <I>192.168.1.100</I></b>), developers can rapidly iterate on their applications without involving the cloud builders. This speeds up the development cycle considerably for individual devices.


title: HISTORY
content:
The <b>balena</b> CLI has its roots in <i>resin.io</i>, the predecessor platform founded around 2013-2014, which aimed to simplify embedded Linux development and device management. The CLI evolved alongside the platform, initially providing basic deployment and device interaction capabilities. In 2018, resin.io rebranded to balena, signifying an expansion beyond just Linux containers to encompass the entire IoT device lifecycle, including operating system management (balenaOS) and fleet orchestration. The CLI has consistently been updated to reflect these platform advancements, adding comprehensive features for local development, robust fleet management, advanced device diagnostics, and seamless over-the-air updates, establishing itself as a cornerstone tool for modern IoT application development and deployment.


title: PARAMETERS
content:
<b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current status of the Baloo indexing service.<br><br><b>start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the Baloo file indexing daemon.<br><br><b>stop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop the Baloo file indexing daemon.<br><br><b>suspend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Temporarily suspend Baloo file indexing without stopping the daemon.<br><br><b>resume</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resume Baloo file indexing after it has been suspended.<br><br><b>disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permanently disable Baloo file indexing.<br><br><b>enable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-enable Baloo file indexing if it was previously disabled.<br><br><b>purge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the entire Baloo index. This will require a full re-indexing.<br><br><b>check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check the integrity of the Baloo index for errors.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure various Baloo settings, such as excluded folders or indexing levels.<br><br><b>monitor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display real-time indexing activity, showing files being processed.<br><br><b>query <term></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search the Baloo index for files matching the specified <I>term</I>.<br><br><b>index <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force re-indexing of a specific file or directory at <I>path</I>.<br><br><b>exclude</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all folders that are currently excluded from indexing.<br><br><b>add-exclude <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a specific <I>path</I> to the list of folders to be excluded from indexing.<br><br><b>remove-exclude <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove a specific <I>path</I> from the list of excluded folders.<br><br><b>indexing-level [level]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show or set the indexing level. <I>level</I> can be 'basic' (filenames only) or 'full-text' (filenames and content).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of <I>balooctl</I>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available commands and options.<br><br>


title: DESCRIPTION
content:
<i>balooctl</i> is a command-line utility designed to interact with and manage the Baloo file indexing and search framework, which is an integral part of the KDE Plasma desktop environment. Baloo provides a robust, real-time file indexing service that allows users to quickly search for files based on filenames, content, and metadata. This command-line tool offers comprehensive control over the Baloo daemon, enabling users to perform various administrative tasks. These tasks include starting, stopping, suspending, or resuming the indexing process, purging the entire index, checking its integrity, and configuring indexing options like excluded folders or indexing levels. Furthermore, <i>balooctl</i> allows users to query the indexed files directly from the terminal, making it a powerful tool for both system administrators and advanced users who prefer command-line interactions or need to script Baloo operations.


title: CAVEATS
content:
Baloo indexing can be resource-intensive, especially during initial setup or after significant file changes, consuming CPU and disk I/O. Users might need to manage its resource usage via suspension or exclusion settings. While Baloo indexes content locally, privacy-conscious users should be aware that full-text indexing stores file contents on disk. Additionally, the effectiveness of searches depends entirely on the completeness and integrity of the index.


title: COMMON USAGE SCENARIOS
content:
<i>balooctl</i> is frequently used for troubleshooting Baloo indexing issues, such as when searches aren't returning expected results (e.g., <i>balooctl check</i>, <i>balooctl purge</i>), or when Baloo is consuming too many resources (e.g., <i>balooctl suspend</i>, <i>balooctl stop</i>). It's also invaluable for scripting maintenance tasks, like regularly purging the index or ensuring indexing is enabled on system startup.


title: HISTORY
content:
<i>balooctl</i> is the command-line interface for Baloo, the file indexing and search framework that was introduced in KDE Plasma as a successor to the Nepomuk semantic desktop framework. Baloo was designed to be more efficient and performant than its predecessor, focusing primarily on fast file indexing and search capabilities. Its development has been driven by the KDE community to provide a robust, modern, and privacy-respecting local search solution for the Plasma desktop environment. The <i>balooctl</i> utility has evolved alongside Baloo to provide comprehensive control over its operations from the terminal.


title: PARAMETERS
content:
<b>-i, --interface <INTERFACE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to monitor (e.g., 'eth0', 'wlan0'). By default, it attempts to detect the primary interface.<br><br><b>-r, --no-resolve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to resolve IP addresses to hostnames. This can reduce CPU usage and may be useful in environments where DNS resolution is slow or undesirable.<br><br><b>-s, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw byte counts (bytes per second) instead of human-readable units (e.g., KB/s, MB/s). Allows for more precise readings.<br><br><b>-l, --rlimit <RLIMIT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of rows to display in the main traffic view. Useful for limiting screen output on smaller terminals or focusing on top consumers.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version information and exit.<br><br>


title: DESCRIPTION
content:
<i>bandwhich</i> is a <b>cross-platform</b> terminal-based utility designed for visualizing <b>current network utilization</b> in real time. It provides an intuitive, interactive curses-like interface that displays network traffic information broken down by process, connection, and remote IP/domain.<br><br>It's particularly useful for quickly identifying which applications or remote hosts are consuming bandwidth, troubleshooting network performance issues, or detecting unusual network activity. <i>bandwhich</i> resolves IP addresses to hostnames, shows process names responsible for connections, and provides total traffic statistics. Written in Rust, it offers a modern and responsive user experience.


title: CAVEATS
content:
<ul><li><i>bandwhich</i> typically requires <b>root privileges</b> (e.g., running with <code>sudo</code>) to access packet capture capabilities.</li><li>It relies on underlying packet capture libraries (like <i>libpcap</i> or <i>npcap</i> on Windows), which must be correctly installed and configured.</li><li>Performance can vary depending on network traffic volume and system resources. High traffic volumes might lead to increased CPU usage.</li><li>Some specific network setups (e.g., certain VPN configurations or virtual interfaces) might require explicit interface specification with the <code>-i</code> option.</li></ul>


title: INTERACTIVE KEYBINDINGS
content:
While running, <i>bandwhich</i> provides several interactive keyboard shortcuts for navigation and control:<br><ul><li><b>q</b>: Quit the application.</li><li><b>j</b> / <b>k</b>: Scroll up/down the list of connections.</li><li><b>f</b>: Enter filter mode to search for specific connections or processes.</li><li><b>d</b>: Toggle display between domain names and raw IP addresses for remote hosts.</li><li><b>p</b>: Toggle display between process names and process IDs.</li></ul>


title: HISTORY
content:
<i>bandwhich</i> is a relatively modern tool, written in <b>Rust</b>, a language known for its performance and safety. It was developed to provide a modern, interactive terminal user interface (TUI) experience for network monitoring, addressing some of the limitations or less user-friendly aspects of older command-line network utilities. Its development focuses on real-time data presentation and user interactivity, contributing to its growing popularity in the Linux system administration toolkit.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help options for the command.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display Banshee's version information.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose debug output for troubleshooting.<br><br><b>--no-splash</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent the display of the splash screen on startup.<br><br><b>--play</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start playback of media from the current queue (if Banshee is already running).<br><br><b>--pause</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pause currently playing media (if Banshee is already running).<br><br><b>--next</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip to the next track in the queue (if Banshee is already running).<br><br><b>--previous</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Go back to the previous track in the queue (if Banshee is already running).<br><br><b>--open=<I>FILE|URI</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a specified file or URI for playback.<br><br><b>--queue=<I>FILE|URI</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a specified file or URI to the playback queue.<br><br><b>--hide</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hide the main Banshee window (if Banshee is already running).<br><br><b>--show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the main Banshee window (if Banshee is already running).<br><br><b>--set-volume=<I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set playback volume (0-100).<br><br><b>--query-playback-state</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the current playback state (e.g., playing, paused, stopped) to the console.<br><br>


title: DESCRIPTION
content:
Banshee is a cross-platform, open-source media player designed primarily for Linux, though it also had limited support for Windows and macOS. Developed as part of the GNOME project and built using Mono and GTK#, it offered a comprehensive solution for managing and playing digital music and videos. Key features included importing audio CDs, syncing with portable devices like iPods and Android phones, fetching album art and metadata from online sources, podcast management, and integration with various online music services such as Last.fm and Amazon MP3 Store. Banshee aimed to be an all-in-one media solution, enabling users to create playlists, listen to internet radio, and explore new music. While it was once the default media player for several popular Linux distributions, including Ubuntu for a period, its development officially ceased around 2014-2016. Despite its discontinuation, Banshee remains available in the repositories of many older Linux distributions, allowing users to still install and use this functional, albeit no longer actively maintained, media application.


title: CAVEATS
content:
Banshee's development has been officially discontinued since around 2014-2016. This means it no longer receives updates for bug fixes, security vulnerabilities, or new features.<br>As a result, it may exhibit compatibility issues with newer audio/video formats, operating system versions, or online services.<br>Its reliance on the Mono framework might also be a consideration for users who prefer applications built solely on GTK/Gnome or other native Linux toolkits.<br>While functional for basic media playback and organization, its lack of ongoing maintenance makes it less suitable for users requiring cutting-edge features or guaranteed long-term support.


title: EXTENSIBILITY THROUGH PLUGINS
content:
Banshee featured a powerful plugin system that allowed users to extend its functionality significantly. Plugins enabled features like cover art fetching, podcast support, CD burning, Last.fm scrobbling, device syncing, and integration with various online services, greatly enhancing its versatility beyond basic playback.


title: DESKTOP ENVIRONMENT INTEGRATION
content:
As a GNOME-centric application, Banshee was designed to integrate seamlessly with the GNOME desktop environment. This included support for GNOME's media keys, notification system, and sound menu integration, providing a cohesive user experience within the desktop.


title: HISTORY
content:
Banshee was first released in 2005. It quickly gained popularity as a feature-rich alternative to other Linux media players.<br>A significant milestone in its development was its adoption as the default music player for Ubuntu in versions 11.04 (Natty Narwhal) and 11.10 (Oneiric Ocelot), briefly replacing Rhythmbox. This period saw increased visibility and usage.<br>It was known for its extensibility through a plugin system and its deep integration with the GNOME desktop environment. However, the project's activity significantly declined after 2012, and official development and maintenance ceased entirely around 2014-2016, with its website and forums becoming inactive.<br>Despite its discontinuation, its legacy as a robust open-source media management tool persists.


title: PARAMETERS
content:
<b><code>-h</code>, <code>--help</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays</i> a help message and <b>exits</b>.<br><br><br><b><code>--version</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows</i> the application's <b>version information</b> and exits.<br><br><br><b><code>--scan-folder=<I>FOLDER</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initiates</i> a scan of the <b>specified local folder</b>. If not provided, it typically scans the user's home directory or the specified path.<br><br><br><b><code>--scan-remote=<I>HOST</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Scans</i> a remote host via <b>SSH</b>. The host should be specified in the format <code>user@host</code> or <code>host</code>.<br><br><br><b><code>--hide-hidden</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Excludes</i> <b>hidden files and directories</b> (those starting with a dot) from the scan results.<br><br><br><b><code>--do-not-follow-symlinks</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents</i> the scanner from <b>following symbolic links</b>, treating them as files themselves rather than traversing their targets.<br><br><br><b><code>--display=<I>DISPLAY</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies</i> the <b>X display</b> to use for the graphical interface, relevant in multi-display or remote X environments.<br><br><br>


title: DESCRIPTION
content:
The <b>baobab</b> command, commonly known as the <i>GNOME Disk Usage Analyzer</i>, is a powerful graphical utility designed to help users understand and manage their disk space effectively. It provides an intuitive visual representation of disk usage, making it easy to identify large files, directories, and other data consuming significant storage.<br><br>Users can leverage <b>baobab</b> to scan local file systems, specific folders, or even remote servers via SSH, offering a comprehensive overview of storage allocation. The application displays data in various interactive formats, including a hierarchical tree map and a sunburst chart (ring chart), allowing for quick navigation and drill-down into specific directories. This visual approach greatly simplifies the process of freeing up disk space by highlighting areas where clutter has accumulated. Its integration with the GNOME desktop environment makes it a standard and accessible tool for disk management on Linux systems.


title: CAVEATS
content:
<ul><li><b>GUI Dependency:</b> <i>Baobab</i> is a graphical application and requires a running X server or Wayland compositor to function.<br></li><li><b>Scan Time:</b> Scanning very large file systems or slow remote connections can take a considerable amount of time.<br></li><li><b>Permissions:</b> The command needs appropriate read permissions for the directories and files it attempts to scan. Lack of permissions will result in incomplete or erroneous results.<br></li><li><b>Remote Access:</b> For remote scanning, SSH access must be properly configured, and the necessary SSH agent or password prompt might be required.</li></ul>


title: GRAPHICAL VIEWS
content:
<i>Baobab</i> offers multiple interactive views to represent disk usage: a <b>tree map</b> (also known as a rectangle map or squarified treemap) where file sizes are proportional to rectangle areas, and a <b>sunburst chart</b> (or ring chart) which visually organizes directories as rings, with subdirectories as segments of those rings. Both views allow users to click and navigate deeper into the file structure.<br>


title: REMOTE SCANNING CAPABILITIES
content:
A key feature of <i>Baobab</i> is its ability to scan disk usage on <b>remote hosts via SSH</b>. This allows administrators or users to analyze storage on servers or other networked machines without needing to be physically present or having a graphical environment running on the remote system, streamlining remote disk management tasks.<br>


title: HISTORY
content:
<b>Baobab</b> originated as part of the <i>GNOME project</i>, initially known as `GnomeVFS Disk Usage Analyzer`. It has been a standard utility within the GNOME desktop environment since its early versions, providing users with an accessible and intuitive way to manage disk space. Over its development, it has evolved with improvements in scanning performance, interface design, and support for modern file systems and remote access protocols, solidifying its role as a key tool for system maintenance.


title: SYNOPSIS
content:
<b>base32</b> [<i>OPTION</i>]... [<i>FILE</i>]<br><i>FILE</i> can be omitted or specified as '<b>-</b>' to read from <i>standard input</i>.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--decode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decode data rather than encode.<br><br><b><b>-i</b>, <b>--ignore-garbage</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When decoding, ignore non-<i>Base32</i> alphabet characters from the input.<br><br><b><b>-w</b>, <b>--wrap</b>=<i>COLS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wrap encoded output lines after <i>COLS</i> characters. Use 0 to disable wrapping.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>base32</b> command is a utility for encoding and decoding data using the <i>Base32</i> algorithm, as specified in <i>RFC 4648</i>. It reads binary or textual input from <i>standard input</i> or a specified <i>FILE</i>, processes it, and writes the resulting <i>Base32</i> encoded or decoded data to <i>standard output</i>.<br><br>While similar in purpose to <b>base64</b>, <i>Base32</i> uses a 32-character alphabet (typically A-Z and 2-7), resulting in a more verbose output (5 bits per character) compared to <i>Base64</i> (6 bits per character). This verbosity can sometimes be advantageous for human readability, ease of transcription, or compatibility with systems that have case-insensitivity or restrictive character sets. It is particularly useful for transmitting binary data over channels that may not handle raw binary safely, or when a less ambiguous encoding than <i>Base64</i> is desired.


title: CAVEATS
content:
<i>Base32</i> encoding is less space-efficient than <i>Base64</i> encoding, as it represents 5 bits of data per character compared to <i>Base64</i>'s 6 bits.<br>Default output wrapping (76 characters) might need to be explicitly disabled (<b>-w 0</b>) when piping output to other commands or storing binary data where line breaks are undesirable.


title: <I>RFC 4648</I> COMPLIANCE
content:
The command strictly follows the <i>Base32</i> encoding scheme defined in <i>RFC 4648</i>, using an alphabet of uppercase letters (A-Z) and digits (2-7), excluding '0', '1', '8', '9' to avoid common ambiguities.


title: INPUT/OUTPUT BEHAVIOR
content:
By default, <b>base32</b> reads from <i>standard input</i> and writes to <i>standard output</i>. This makes it highly versatile for use in shell pipelines to process data from various sources and direct output to files or other commands.


title: HISTORY
content:
The <b>base32</b> command is part of the <i>GNU Coreutils</i> package, which provides fundamental utilities for the <i>GNU</i> operating system. Its implementation adheres to the <i>Base32</i> encoding specification outlined in <i>RFC 4648</i>, "The Base16, Base32, and Base64 Data Encodings", published in 2006. While <i>Base64</i> gained widespread adoption earlier, <i>Base32</i> found its niche in specific applications requiring a more restricted character set or improved human readability, such as <i>DNSSEC</i> records or certain software distribution checksums.


title: SYNOPSIS
content:
<b>base64</b> [<I>OPTION</I>]... [<I>FILE</I>]<br>If <I>FILE</I> is not specified or is '-', <b>base64</b> reads from standard input.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--decode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes the input data from Base64 to binary.<br><br><b><b>-i</b>, <b>--ignore-garbage</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When decoding, ignores non-alphabet characters, which can be useful for malformed input or data mixed with other text.<br><br><b><b>-w</b>, <b>--wrap=COLS</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wraps encoded output lines after COLS characters. A value of 0 disables line wrapping entirely.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>base64</b> command is a fundamental utility used for encoding and decoding data using the Base64 encoding scheme. Base64 is a binary-to-text encoding method that represents binary data (such as images, executable files, or encrypted data) in an ASCII string format. This conversion is crucial for safely transmitting data over mediums that are designed to handle text, such as email systems, URLs, or when embedding binary data directly into source code or configuration files without corruption. The <b>base64</b> command typically reads input from standard input or a specified file, performs the encoding or decoding operation, and then writes the result to standard output. It is often piped with other commands for data manipulation, for instance, encoding an image file before embedding it in a JSON payload, or decoding a Base64 string received from a network stream. As part of the GNU Coreutils package, it is widely available and a standard tool on Linux systems.


title: CAVEATS
content:
Base64 encoding increases the size of the data by approximately 33%, which can impact storage and transmission efficiency. It is an encoding scheme, not an encryption method, meaning the encoded data is not secure and can be easily decoded by anyone with access to the `base64` utility. When handling text files, ensure character encoding (e.g., UTF-8) is consistent to avoid unexpected results, though `base64` primarily operates on raw bytes.


title: USAGE EXAMPLES
content:
Here are some common usage scenarios for the <b>base64</b> command:<br><br><b>Encoding a string:</b><br><code>echo "My secret data" | base64</code><br><br><b>Decoding a Base64 string:</b><br><code>echo "TXkgc2VjcmV0IGRhdGEK" | base64 -d</code><br><br><b>Encoding a binary file:</b><br><code>base64 photo.png > photo.b64</code><br><br><b>Decoding a Base64 file:</b><br><code>base64 -d photo.b64 > photo_decoded.png</code><br><br><b>Encoding with no line wrapping (useful for URLs or single-line output):</b><br><code>base64 -w 0 binary_blob.bin</code>


title: HISTORY
content:
The Base64 encoding scheme itself has roots in earlier binary-to-text encoding methods. The <b>base64</b> command, as part of the GNU Coreutils package, provides a standardized and widely available implementation conforming to RFC 4648 (which defines 'Base64 Data Encodings'). Its widespread adoption on Linux systems makes it a de-facto standard for shell-based Base64 operations, largely replacing older utilities like <b>uuencode</b> for general-purpose binary data encoding/decoding tasks due to its simplicity and adherence to modern standards.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
<b>basename</b> is a command-line utility designed to extract the non-directory portion of a pathname, effectively providing just the filename or the last component of a path. It's an indispensable tool in shell scripting for manipulating file paths, isolating filenames for processing, or displaying in logs. The command can optionally remove a specified <i>SUFFIX</i> from the extracted filename if it matches the trailing part. For example, '<b>basename</b> /usr/local/bin/program.sh' will output 'program.sh', and '<b>basename</b> /usr/local/bin/program.sh .sh' will yield 'program'. This utility is often used in conjunction with its counterpart, <b>dirname</b>, to separate a full path into its directory and file components, providing robust path manipulation capabilities within scripts and command-line operations.


title: CAVEATS
content:
When <i>NAME</i> consists solely of directory separators (e.g., '/', '//', '///'), <b>basename</b> will print a single '/'. If <i>SUFFIX</i> is identical to the extracted base <i>NAME</i> (e.g., '<b>basename</b> .bashrc .bashrc'), the result will be a single period ('.') signifying the current directory.


title: MULTIPLE ARGUMENTS PROCESSING
content:
When <b>basename</b> is invoked with multiple <i>NAME</i> arguments (e.g., '<b>basename</b> file1 file2 file3'), it processes each argument independently. The base name for each argument is then printed on a new line. This mode does not support the optional <i>SUFFIX</i> argument, as it would apply to all files universally.


title: SUFFIX REMOVAL LOGIC
content:
The optional <i>SUFFIX</i> argument is removed only if it matches the end of the <i>NAME</i> string <i>after</i> any leading directory components have been stripped. The suffix must be an exact match to the trailing characters. If the <i>NAME</i> ends with a directory separator, the suffix is not considered (e.g., '<b>basename</b> /foo/bar/ .bar' still outputs 'bar').


title: HISTORY
content:
The <b>basename</b> utility has been a standard part of Unix and Unix-like operating systems for many years. It is typically included in the GNU Core Utilities package on Linux systems, reflecting its fundamental role in shell scripting and file path manipulation. Its design is simple and effective, remaining consistent across various Unix implementations over decades.


title: SYNOPSIS
content:
<b>basenc</b> [<I>OPTION</I>]... [<I>FILE</I>]<br><b>basenc</b> <I>--base16</I> [<I>OPTION</I>]... [<I>FILE</I>]<br><b>basenc</b> <I>--base32</I> [<I>OPTION</I>]... [<I>FILE</I>]<br><b>basenc</b> <I>--base64</I> [<I>OPTION</I>]... [<I>FILE</I>]<br><b>basenc</b> <I>--base85</I> [<I>OPTION</I>]... [<I>FILE</I>]<br><b>basenc</b> <I>--z85</I> [<I>OPTION</I>]... [<I>FILE</I>]


title: PARAMETERS
content:
<b>--base16, -A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects base16 encoding/decoding. Base16 uses hexadecimal digits (0-9, A-F).<br><br><b>--base32, -b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects base32 encoding/decoding. Base32 uses a 32-character alphabet, commonly for case-insensitive names.<br><br><b>--base64, -c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects base64 encoding/decoding. This is the <I>default</I> encoding if no other base option is specified.<br><br><b>--base85, -Z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects base85 encoding/decoding, also known as Ascii85. More compact than base64 for arbitrary binary data.<br><br><b>--z85, -z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects Z85 encoding/decoding, a specific variant of base85 with a different alphabet and checksum property.<br><br><b>-d, --decode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes data. By default, <b>basenc</b> encodes. The input is assumed to be encoded in the specified base format.<br><br><b>-i, --ignore-garbage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When decoding, ignores non-alphabet characters. This is useful for handling input that may contain formatting or extraneous characters.<br><br><b>-w, --wrap=<I>COLS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wrap encoded output lines after <I>COLS</I> characters. Use 0 to disable wrapping. The default for base64 is 76 characters.<br><br><b>-u, --url</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use URL-safe alphabet for base64 encoding/decoding. This replaces '+' with '-' and '/' with '_', and omits trailing '=' padding for compactness and URL compatibility.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs version information and exits.<br><br><b><I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The input file to process. If omitted or specified as <I>-</I>, <b>basenc</b> reads from standard input.<br><br>


title: DESCRIPTION
content:
<b>basenc</b> is a versatile utility for encoding and decoding binary data into a printable ASCII string format, and vice-versa. Unlike its predecessor <b>base64</b>, <b>basenc</b> offers robust support for multiple base encodings, including base16, base32, base64 (the default), base85, and Z85. This makes it an invaluable tool for tasks such as transmitting binary data over mediums that primarily handle text (like email or URLs), embedding data in configuration files, or simply converting data formats for interoperability. It can read input from standard input or specified files and write to standard output. When decoding, it can optionally ignore non-alphabet characters, which is useful for handling corrupted or formatted input. Its flexibility in choosing encoding schemes makes it a powerful addition to the standard Linux command-line toolkit.


title: CAVEATS
content:
<b>basenc</b> is a GNU Coreutils extension and might not be available on all Unix-like operating systems (e.g., some BSD variants), although <b>base64</b> is more widely available. The default wrapping for base64 (76 characters) may need to be adjusted with <I>--wrap=0</I> for specific applications (e.g., embedding in JSON or XML where newlines are problematic). Different base encodings have varying overheads and character sets; choose the appropriate one based on your specific requirements (e.g., base16 is human-readable but has high overhead, base64 is common, base85/Z85 are more compact for certain binary data).


title: ENCODING EXAMPLES
content:
To encode a file 'data.bin' using base64:<br><code>basenc --base64 data.bin > data.b64</code><br><br>To encode a string using base32:<br><code>echo 'hello world' | basenc --base32</code><br><br>To decode base64 data from a file:<br><code>basenc --decode --base64 data.b64 > data.bin</code>


title: USE CASES
content:
<b>basenc</b> is ideal for embedding binary data in text-based formats like JSON, XML, or configuration files where direct binary content is not allowed. It is also useful for transmitting data over channels that may corrupt binary information (e.g., some legacy email systems or HTTP headers). The <I>--url</I> option is specifically designed for passing binary data within URLs without requiring additional URL encoding for reserved characters.


title: HISTORY
content:
<b>basenc</b> was introduced as part of GNU Coreutils to provide a more unified and flexible tool for various base encodings. It effectively extends the functionality previously found only in <b>base64</b> (which was also part of Coreutils) by consolidating support for other common base formats like base16, base32, base85, and Z85 into a single command. Its development aimed to simplify data encoding/decoding workflows and reduce the need for external, less standardized tools for these specific tasks, making it a more comprehensive solution within the standard Linux environment.


title: SYNOPSIS
content:
<i>Bash-it</i> is not a single executable command in the traditional sense, but rather a framework managed by a main script. <br>After installation, you typically interact with it via the <i>bash-it</i> helper script found in your `~/.bash_it` directory (or linked to your PATH).<br><br>Installation (first time):<br><i>`git clone --depth=1 https://github.com/Bash-it/bash-it.git ~/.bash_it`<br>`~/.bash_it/install.sh --auto`</i> (or <i>`--no-modify-config`</i> for manual configuration)<br><br>General Usage:<br><b>`bash-it`</b> <i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>]


title: PARAMETERS
content:
<b><b>enable</b> <i>&lt;type&gt; &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables</i> a specific component (e.g., `plugin`, `alias`, `completion`) by its `name`.<br><br><b><b>disable</b> <i>&lt;type&gt; &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables</i> an enabled component.<br><br><b><b>list</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists</i> available and currently enabled components of a given `type`.<br><br><b><b>reload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reloads</i> your shell's <i>Bash-it</i> configuration without restarting the terminal.<br><br><b><b>update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Updates</i> <i>Bash-it</i> to the latest version by pulling changes from its Git repository.<br><br><b><b>themes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists</i> all available themes that can be set in your `~/.bashrc` (e.g., `export BASH_IT_THEME="powerline"`).<br><br><b><b>clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Removes</i> disabled plugins, aliases, and completions from the loaded environment.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays</i> detailed help information for <i>Bash-it</i> commands.<br><br>


title: DESCRIPTION
content:
<i>Bash-it</i> is a powerful, community-driven framework designed to <b>enhance and customize your Bash shell experience</b>. <br>It provides a structured and easy-to-manage collection of Bash scripts, including themes, aliases, custom functions, and completion scripts. <br>The primary goal of <i>Bash-it</i> is to make the Bash terminal more user-friendly, productive, and aesthetically pleasing for developers, system administrators, and power users. <br>Instead of manually managing numerous shell configurations, <i>Bash-it</i> offers a modular system that allows users to enable or disable components with simple commands. <br>Key features include a variety of <i>colorful themes</i> for visual customization, time-saving <i>aliases</i> for frequently used commands, intelligent <i>tab-completion scripts</i> for various tools (like Git, Docker, Kubernetes), and a repository of useful <i>functions</i> that extend Bash's capabilities. <br>Its straightforward installation and update process, primarily through Git, make it a popular choice for those looking to significantly upgrade their command-line environment without deep manual configuration.


title: CAVEATS
content:
<ul><li><b>Dependency on Bash</b>: <i>Bash-it</i> is specifically designed for the Bash shell and will not work with other shells like Zsh or Fish.</li><li><b>Configuration Conflicts</b>: Existing custom configurations in your `~/.bashrc` or `~/.profile` might conflict with <i>Bash-it</i>'s settings, especially for aliases or functions. It's recommended to review your configuration after installation.</li><li><b>Shell Startup Time</b>: Enabling a large number of plugins, aliases, or completions can slightly increase the shell's startup time due to the additional scripts being sourced.</li><li><b>Manual Sourcing Required</b>: For <i>Bash-it</i> to function, the main `bash_it.sh` script must be sourced in your Bash configuration file (e.g., `~/.bashrc`). The installer usually handles this, but manual intervention might be needed.</li></ul>


title: CUSTOMIZATION AND EXTENSIBILITY
content:
Users can easily extend <i>Bash-it</i> by creating their own custom plugins, aliases, or completions. <br>These can be placed in the `custom` directory within the `~/.bash_it` installation, ensuring they are loaded and persist across <i>Bash-it</i> updates.


title: COMMUNITY-DRIVEN DEVELOPMENT
content:
<i>Bash-it</i> thrives on community contributions. <br>This collaborative model means a wide variety of tools and preferences are supported through its plugin ecosystem, and development is responsive to user needs and new technologies.


title: HISTORY
content:
<i>Bash-it</i> originated as an open-source project by its initial creator, <i>Matt Gruskin</i>, around 2011. <br>It was inspired by the success of <i>Oh My Zsh</i> and aimed to bring similar modularity and ease of customization to the Bash shell, which lacked such a comprehensive framework at the time. <br>Over the years, it has grown into a vibrant, community-driven project with contributions from numerous developers worldwide. <br>Its development is focused on providing a stable, extensible platform for Bash users, continuously adding new themes, plugins, aliases, and completions to keep pace with modern command-line tool usage and user demands.


title: PARAMETERS
content:
<b><i>-V</i> or <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of <i>bashbug</i> and exits.<br><br><b><i>-x</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the default email address where Bash bug reports are sent, then exits.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the generated bug report to standard output (<i>stdout</i>) instead of attempting to send it via email. Useful for review or saving.<br><br><b><i>-n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the attempt to send the email, often used in conjunction with <i>-r</i> to preview the report without sending.<br><br><b><i>email-address</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative email address to send the bug report to, overriding the compiled-in default destination.<br><br>


title: DESCRIPTION
content:
<i>bashbug</i> is a utility distributed with the GNU Bash shell, designed to simplify the process of reporting bugs. It automates the collection of essential system and Bash version information, which is crucial for developers to diagnose issues. The command then formats this data into a structured report, typically preparing it for submission via email to the official Bash bug reporting address. This ensures that bug reports are comprehensive and contain the necessary context, making the reporting process more efficient and effective for both users and maintainers of the shell.


title: CAVEATS
content:
<i>bashbug</i> typically requires a functional email client (like <i>mailx</i>) configured on the system to send reports directly. If an email client is not available or configured, the <i>-r</i> option must be used to print the report to <i>stdout</i>. The generated report includes system information which might be considered sensitive in certain environments.<br>It is solely for reporting issues with the <i>bash</i> shell itself, not other commands or system components.


title: REPORT CONTENT
content:
The bug report generated by <i>bashbug</i> typically includes the Bash version, system type (e.g., architecture, operating system), current locale settings, and any environment variables or shell options relevant to the bug. It also provides a template for the user to describe the bug, steps to reproduce it, and the expected versus actual behavior.


title: PURPOSE AND EFFICIENCY
content:
The primary purpose of <i>bashbug</i> is to streamline the bug reporting process. By automating the collection of essential diagnostic information, it ensures that developers receive consistent and necessary details upfront. This significantly reduces the back-and-forth communication often required for incomplete or ambiguous bug reports, making the debugging process more efficient for the Bash development team.


title: HISTORY
content:
<i>bashbug</i> has been an integral part of the GNU Bash distribution since its early development. Its inclusion highlights the GNU project's strong emphasis on user feedback and continuous improvement through organized bug reporting. It provides a standardized mechanism for users to contribute directly to the stability and evolution of the shell, by ensuring that crucial version and system environment details are consistently captured, which is vital for effective debugging across diverse user setups.


title: SYNOPSIS
content:
<I>bashmarks</I> is not a single executable but a collection of shell functions sourced into your environment. Its functions are typically invoked as:<br><br><b>s</b> <i>&lt;bookmark_name&gt;</i><br><b>g</b> <i>&lt;bookmark_name&gt;</i><br><b>p</b> <i>&lt;bookmark_name&gt;</i><br><b>d</b> <i>&lt;bookmark_name&gt;</i><br><b>l</b><br><b>_b</b><br><b>_bm</b>


title: PARAMETERS
content:
<b><b>s</b> <i>&lt;bookmark_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current working directory with the specified <i>&lt;bookmark_name&gt;</i> as a bookmark.<br><br><b><b>g</b> <i>&lt;bookmark_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the current directory to the location saved under <i>&lt;bookmark_name&gt;</i>.<br><br><b><b>p</b> <i>&lt;bookmark_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the full path associated with <i>&lt;bookmark_name&gt;</i> to standard output without changing directory.<br><br><b><b>d</b> <i>&lt;bookmark_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the bookmark named <i>&lt;bookmark_name&gt;</i>.<br><br><b><b>l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently saved bookmarks along with their corresponding directory paths.<br><br><b><b>_b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Jumps to the last used bookmark. This is an optional feature that might need to be enabled during <I>bashmarks</I> setup.<br><br><b><b>_bm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an interactive menu to select and jump to a bookmark. Useful when you don't remember specific names.<br><br>


title: DESCRIPTION
content:
<I>bashmarks</I> is a simple yet powerful shell script designed to enhance command-line navigation by allowing users to bookmark frequently accessed directories. Instead of typing lengthy paths or using <I>cd ../../</I>, users can save a directory with a short, memorable name. Once bookmarked, jumping to that directory is as simple as typing <B>g &lt;bookmark_name&gt;</B>. This utility significantly improves productivity for developers, system administrators, and anyone who spends a lot of time in the terminal.<br><br>It stores bookmarks in a persistent file, usually in the user's home directory, ensuring they are available across shell sessions. <I>bashmarks</I> integrates seamlessly with <I>bash</I> and other compatible shells, offering a lightweight and efficient way to manage directory shortcuts. It provides functions for saving, navigating, listing, and deleting bookmarks, making directory management intuitive and fast.


title: CAVEATS
content:
<I>bashmarks</I> is not a standard Linux utility and must be installed manually, typically by sourcing its script into your shell's configuration file (e.g., <I>.bashrc</I>). Its functions are active only in shell sessions where <I>bashmarks</I> has been sourced. Conflicts might arise if bookmark names clash with existing shell aliases or functions. It primarily supports <I>bash</I> and compatible shells like <I>zsh</I>, but may not work out-of-the-box with other shells without modifications or adapters.


title: INSTALLATION
content:
<I>bashmarks</I> is typically installed by cloning its GitHub repository and then sourcing the <I>bashmarks.sh</I> script in your shell's startup file (e.g., <I>~/.bashrc</I> or <I>~/.zshrc</I>). This ensures its functions are available in every new shell session.


title: BOOKMARK FILE
content:
By default, <I>bashmarks</I> stores all saved directory bookmarks in a plain text file, commonly located at <I>~/.bashmarks</I>. This file can be manually inspected or edited if needed, though using the <B>s</B> and <B>d</B> commands is recommended for consistency and to avoid corrupting the file format.


title: HISTORY
content:
<I>bashmarks</I> was created by Huy Nguyen and is primarily maintained as an open-source project on GitHub. It emerged as a solution for simplifying directory navigation in <I>bash</I> environments, addressing the common pain point of repeatedly typing long paths. Its development has been community-driven, with contributions from various users improving its features and compatibility over time. It has gained popularity due to its simplicity, lightweight nature, and effectiveness in boosting command-line productivity. It is not part of the GNU core utilities or a standard Linux distribution package by default but is widely adopted as a personal utility.


title: SYNOPSIS
content:
<i>bastet</i> [<b>-c</b> <i>columns</i>] [<b>-d</b>] [<b>-l</b> <i>level</i>] [<b>-r</b> <i>rows</i>] [<b>-s</b>] [<b>-v</b>] [<b>--classic</b>] [<b>--help</b>]


title: PARAMETERS
content:
<b><b>-c</b> <i>columns</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the width of the game board in columns.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, typically for developer insight.<br><br><b><b>-l</b> <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game at the specified difficulty level.<br><br><b><b>-r</b> <i>rows</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the height of the game board in rows.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the high scores recorded by the game.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>bastet</i> command.<br><br><b><b>--classic</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables <i>bastet</i>'s unique 'badly adjusted' piece selection algorithm, providing a traditional random Tetris experience.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>--help</b>, displaying usage information.<br><br>


title: DESCRIPTION
content:
<i>bastet</i> (short for <b>B</b>adly <b>A</b>djusted <b>S</b>cores <b>Tet</b>ris) is a unique and challenging console-based puzzle game inspired by the classic Tetris. Unlike traditional Tetris implementations that aim for random piece generation, <i>bastet</i> employs an algorithm designed to give the player the worst possible next piece, making gameplay significantly more difficult and requiring strategic thinking under pressure. This innovative twist transforms a familiar game into a relentless test of skill and adaptability.<br><br>The game operates entirely within the terminal, utilizing the <i>ncurses</i> library to render its graphical interface. It's often included in the official package repositories of many Linux distributions, making it easy to install and play. While fundamentally a game, its unconventional approach to piece generation makes it a fascinating study for those interested in algorithmic design or simply looking for an exceptionally challenging variant of a beloved classic. Despite its 'unfair' nature, it remains a popular choice for users seeking a quick, engaging, and frustratingly addictive terminal experience.


title: CAVEATS
content:
<i>bastet</i> is designed to be an exceptionally challenging game; its core mechanic of supplying 'worst' pieces can be frustrating for players expecting a traditional Tetris experience. As a terminal-based application, its display relies on the <i>ncurses</i> library, meaning its visual presentation might vary slightly across different terminal emulators or could encounter rendering issues on highly minimalistic terminal setups without proper <i>ncurses</i> support. It is primarily for entertainment and not a system utility.


title: <B>GAMEPLAY CONTROLS</B>
content:
<i>bastet</i> utilizes common keyboard inputs for gameplay. Typically, arrow keys are used for moving pieces left, right, and down, while the up arrow or 'x' key rotates pieces. The spacebar usually hard drops a piece, and 'p' can pause the game. Specific keybindings are generally displayed in-game or can be found in the program's manual page.


title: HISTORY
content:
<i>bastet</i> was originally developed by Kyle Smith and first released around 2003. Its creation was motivated by the desire to explore a unique twist on the classic Tetris formula, specifically by implementing an algorithm that actively attempts to give the player the 'worst' possible next piece. This fundamental design choice immediately distinguished it from other Tetris clones and established its identity as a challenging, 'anti-Tetris' game. Being open-source, <i>bastet</i> has been maintained and packaged by various Linux distributions, ensuring its continued availability and popularity within the terminal gaming community.


title: SYNOPSIS
content:
<b>bat</b> [<i>OPTIONS</i>] [<i>FILE</i>...] <br> <b>bat</b> [<i>OPTIONS</i>] <i>--highlight-line</i> <<i>N</i>>[:<<i>N</i>>] [...] [<i>FILE</i>...] <br> <b>bat</b> [<i>OPTIONS</i>] <i>--list-themes</i> <br> <b>bat</b> [<i>OPTIONS</i>] <i>--list-languages</i> <br> <i>command</i> | <b>bat</b> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><i>-A</i>, <i>--show-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show non-printable characters (tabs, spaces, newlines).<br><br><b><i>--diff</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show Git diff markers (added, modified, removed lines).<br><br><b><i>-p</i>, <i>--plain</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show Git modifications, line numbers, or automatic paging. Useful for scripting.<br><br><b><i>-P</i>, <i>--no-paging</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output to a pager, even if content exceeds terminal height. Useful when output needs to be directly captured.<br><br><b><i>--language</i> <<i>LANG</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly set the language for syntax highlighting (e.g., 'Python', 'JSON').<br><br><b><i>--theme</i> <<i>THEME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the syntax highlighting theme (e.g., 'TwoDark', 'ansi'). Use <i>--list-themes</i> to see available options.<br><br><b><i>--list-themes</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available syntax highlighting themes.<br><br><b><i>--list-languages</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all supported programming languages and file formats.<br><br><b><i>--style</i> <<i>COMPONENTS</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which elements to display (e.g., 'numbers,changes,header').<br><br><b><i>--wrap</i> <<i>MODE</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify text wrapping mode: 'auto', 'never', or 'character'.<br><br><b><i>--line-range</i> <<i>N</i>>[:<<i>M</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show a specific range of lines from the input file(s).<br><br><b><i>--highlight-line</i> <<i>N</i>>[:<<i>M</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Highlight specific line numbers or ranges within the output.<br><br>


title: DESCRIPTION
content:
<b>bat</b> is a modern, feature-rich alternative to the standard <b>cat</b> command on Linux and Unix-like systems. Written in <i>Rust</i>, it enhances file viewing by providing significant improvements, primarily focusing on readability and developer experience. <br><br> Key features include: <b>Syntax Highlighting:</b> Automatically highlights code based on file type, supporting a vast array of programming languages and markup formats. <br> <b>Git Integration:</b> Shows Git modifications (added, modified, removed lines) directly within the output, similar to <b>git diff</b>. <br> <b>Line Numbers:</b> Displays line numbers by default, making navigation and referencing easier. <br> <b>Automatic Paging:</b> Pipes output to a pager like <b>less</b> automatically when content exceeds terminal height, allowing scrolling. <br> <b>Configurability:</b> Supports custom themes, aliases, and extensions through a configuration file. <br> <b>Concise Output:</b> Aims to provide a clean, readable output for various text files. <br><br> <b>bat</b> is designed to be a drop-in replacement for everyday <b>cat</b> usage, offering a more pleasant and informative viewing experience, especially for source code and structured text files.


title: CAVEATS
content:
While <b>bat</b> is a powerful tool, it's not always a drop-in replacement for all <b>cat</b> use cases. <br> <b>Scripting:</b> For shell scripts where raw, unformatted text is strictly required (e.g., piping to <b>grep</b> for exact matches, or binary files), <b>cat</b> or <b>bat --plain</b> might be more suitable. <b>bat</b>'s added formatting can interfere with automated parsing. <br> <b>Performance:</b> For extremely large files (gigabytes), <b>bat</b> might be slightly slower than <b>cat</b> due to the overhead of syntax parsing and formatting. <br> <b>Dependencies:</b> Relies on an external pager (like <b>less</b>) for automatic paging, which might not be available in minimal environments.


title: CONFIGURATION
content:
<b>bat</b> can be extensively configured via a configuration file, typically located at <i>$HOME/.config/bat/config</i> or <i>$XDG_CONFIG_HOME/bat/config</i>. This file allows setting default options (e.g., preferred theme, paging behavior, line wrapping) and defining custom aliases or commands.


title: ENVIRONMENT VARIABLES
content:
Several environment variables can influence <b>bat</b>'s behavior, such as <i>BAT_CONFIG_PATH</i> to specify a custom configuration file location, <i>BAT_PAGER</i> to override the default pager (e.g., `more`), or <i>BAT_THEME</i> to set a default theme.


title: HISTORY
content:
<b>bat</b> was created by <i>sharkdp</i> (Daniel Kehl) and first released around 2018. It is written entirely in <i>Rust</i>, a programming language known for its performance and memory safety. The project quickly gained significant traction within the developer community as a modern, user-friendly alternative to the traditional <b>cat</b> utility, addressing common pain points like lack of syntax highlighting and difficult navigation in large files. Its emphasis on a clean, readable output and integration with version control systems cemented its popularity as a go-to tool for viewing code and text files.


title: SYNOPSIS
content:
<b>bat</b> [<i>options</i>] [<i>file...</i>]<br><b>bat</b> &lt; <i>stdin</i><br><i>command</i> | <b>bat</b>


title: PARAMETERS
content:
<b>-A, --show-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show non-printable characters.<br><br><b>-l, --language &lt;LANGUAGE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly set the language for syntax highlighting (e.g., <i>-l rust</i>).<br><br><b>-p, --plain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable Git integration, line numbers, and decorations. Useful for raw output or scripting.<br><br><b>-n, --no-numbers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print line numbers.<br><br><b>-H, --highlight-line &lt;LINES&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Highlight specific lines (e.g., <i>-H 10-20,35</i>).<br><br><b>-r, --line-range &lt;RANGES&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print only a specific range of lines (e.g., <i>-r 1:10</i>, <i>-r :20</i>, <i>-r 30:</i>).<br><br><b>--theme &lt;THEME&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the color theme to use. Use <i>--list-themes</i> to see available options.<br><br><b>--list-themes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available color themes.<br><br><b>--style &lt;COMPONENTS&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set which elements of the output to display (e.g., <i>numbers,changes,header,grid</i>). Options: <i>auto,full,plain,numbers,changes,header,grid,snip</i>.<br><br><b>--wrap &lt;MODE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set line wrapping mode. Options: <i>auto,always,never</i>.<br><br><b>-P, --no-paging</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable automatic paging. Output will go directly to standard output.<br><br><b>--pager &lt;COMMAND&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an external pager command (e.g., <i>--pager 'less -RFX'</i>).<br><br><b>--tabs &lt;N&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the tab width to <i>N</i> spaces.<br><br><b>--map-syntax &lt;GLOB:SYNTAX&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Map a glob pattern to a specific syntax (e.g., <i>--map-syntax '*.vue:html'</i>).<br><br><b>--config-file &lt;FILE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file.<br><br><b>--diagnostic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show diagnostic information (version, configuration, loaded syntaxes, themes).<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print help information.<br><br>


title: DESCRIPTION
content:
<i>bat</i>, often informally referred to as <i>batcat</i>, is a feature-rich command-line utility designed to display file contents. It serves as a modern, user-friendly alternative to the traditional <i>cat</i> command, enhancing its capabilities with several key features. Written in Rust, <i>bat</i> automatically provides syntax highlighting for a vast array of programming languages and markup formats, making code and configuration files significantly more readable. It also integrates seamlessly with Git, displaying inline modifications (additions, deletions, changes) directly in the output, similar to <i>diff</i>. Other notable features include automatic paging (piping output to a pager like <i>less</i> when content exceeds screen height), line numbering, and the ability to customize themes and styles. It's an essential tool for developers and system administrators who frequently inspect file contents in the terminal.


title: CAVEATS
content:
The term <i>batcat</i> is an informal alias; the actual command name is <i>bat</i>. <i>bat</i> is not installed by default on most Linux distributions and needs to be installed separately. While highly useful for viewing, it's generally not recommended for scripting where raw, unformatted file content is strictly required, as its output includes syntax highlighting and other decorations. For such cases, use <i>cat</i> or <i>bat --plain</i>.


title: CONFIGURATION FILE
content:
<i>bat</i> can be extensively configured via a configuration file, typically located at <i>~/.config/bat/config</i> or specified via the <i>--config-file</i> option. This file allows setting default options, aliases, and custom syntax mappings, enabling a personalized viewing experience.


title: ENVIRONMENT VARIABLES
content:
Several environment variables can influence <i>bat</i>'s behavior, including <i>BAT_THEME</i> (to set the default theme), <i>BAT_PAGER</i> (to specify the pager command, overriding the default), and <i>PAGER</i> (fallback pager). These provide flexible ways to customize its operation without command-line arguments.


title: EXTENSIBILITY
content:
<i>bat</i> supports adding custom syntaxes and themes, which can be useful for niche languages or specific aesthetic preferences. These can be placed in the <i>~/.config/bat/syntaxes</i> and <i>~/.config/bat/themes</i> directories, respectively, allowing users to extend <i>bat</i>'s capabilities beyond its built-in set.


title: HISTORY
content:
<i>bat</i> was created by Pascal Hertrich (<i>@sharkdp</i>) and first released in 2018. Developed in Rust, it quickly gained traction in the developer community as a powerful and aesthetically pleasing replacement for the traditional <i>cat</i> utility. Its rapid adoption stems from its out-of-the-box syntax highlighting, Git integration, and smart paging capabilities, addressing common pain points when viewing code and text files in the terminal.


title: PARAMETERS
content:
<b><i>(no direct command-line options)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>batch</b> command itself does not accept command-line options. It expects the commands to be executed to be provided via standard input (e.g., piped from another command or typed directly) or redirected from a file.<br><br>


title: DESCRIPTION
content:
<i>batch</i> is a utility within the <i>at</i> job scheduling system used to execute commands when the system's load average falls below a specific threshold, typically 0.8. Unlike <i>at</i>, which schedules jobs for a precise future time, <i>batch</i> prioritizes system resource availability, making it ideal for non-time-critical but resource-intensive tasks. Commands are read from standard input or a redirected file. When a <i>batch</i> job is submitted, the current working directory, environment variables (except TERM, TERMCAP, DISPLAY, and _), and umask are preserved. The job is then executed by the <i>atd</i> daemon using the user's login shell or <i>/bin/sh</i>. Any output (stdout and stderr) is mailed to the user by default, unless explicitly redirected to a file or <i>/dev/null</i>. This command ensures that heavy tasks do not negatively impact foreground interactive sessions or critical system services.


title: CAVEATS
content:
Execution is not guaranteed at a specific time; it depends entirely on the system's fluctuating load average.<br>The default load threshold (often 0.8) for job execution is configurable via the <i>atd</i> daemon's settings and may vary by system.<br>The environment (PATH, variables, umask) captured at the time of job submission is used, not at the time of execution. Ensure your job script is self-contained or relies on a robust environment.<br>By default, command output is mailed to the user, which can lead to email clutter if not handled by explicit redirection.


title: SUBMITTING A JOB
content:
Commands can be submitted to <b>batch</b> in a few ways:<br>1. Type commands directly:<br><b>batch</b><br><i>command1</i><br><i>command2</i><br>...<br><i>Ctrl+D</i> (to signal end of input)<br>2. Pipe commands:<br><i>echo 'ls -l /tmp' | <b>batch</b></i><br>3. Redirect from a script file:<br><i><b>batch</b> < /path/to/script.sh</i>


title: LOAD THRESHOLD
content:
The system load average threshold at which <b>batch</b> jobs are executed is typically 0.8. This value is configurable within the <i>atd</i> daemon's settings, often in a configuration file like <i>/etc/at.conf</i> or determined by compile-time options. The <i>atd</i> daemon constantly monitors the system load and executes pending <i>batch</i> jobs as soon as the load drops below this configured threshold.


title: HISTORY
content:
The <i>batch</i> command is an integral part of the <i>at</i> utility suite, which has been a fundamental component of Unix and Unix-like operating systems for many decades. Its core functionality for scheduling one-off tasks dates back to early Unix versions, providing a simple yet effective mechanism for deferred execution. <i>batch</i> specifically addresses the need for opportunistic execution, allowing tasks to run when system resources are ample, thus avoiding performance degradation during peak load. This focus distinguishes it from <i>at</i>'s time-specific scheduling and has kept it relevant for system administrators managing resource-sensitive operations.


title: SYNOPSIS
content:
<i>bats</i> [<i>options</i>] [<i>test_paths...</i>]<br>
<i>bats</i> [<i>options</i>] [--] [<i>arguments_to_script...</i>]<br>
<br>
<b>Common Usage:</b><br>
<i>bats</i> my_script.bats<br>
<i>bats</i> --recursive my_tests_dir


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current Bats version and exits.<br><br><b>--recursive, -r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively searches for and runs all .bats files within specified directories.<br><br><b>--filter <regex>, -f <regex></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only runs tests whose descriptions match the provided extended regular expression.<br><br><b>--formatter <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output formatter to use, such as <i>tap</i>, <i>pretty</i>, or <i>junit</i>.<br><br><b>--pretty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for --formatter pretty, providing human-readable output.<br><br><b>--tap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for --formatter tap, producing raw TAP output.<br><br><b>--jobs <n>, -j <n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs test files in parallel using up to <i>n</i> concurrent jobs.<br><br><b>--fail-fast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits immediately after the first test failure is encountered.<br><br><b>--summary-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only the summary of the test run, suppressing detailed test results.<br><br><b>--gather-test-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures and displays stdout and stderr for all tests, not just failed ones.<br><br><b>--skip-formatter</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables all formatters, outputting only raw TAP.<br><br><b>--load <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads an external shell script into the test environment before running tests.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of Bats options, allowing subsequent arguments to be passed directly to the test script being tested.<br><br>


title: DESCRIPTION
content:
<i>Bats</i> is a TAP-compliant testing framework for Bash and other shell scripts. It provides a simple yet powerful way to verify that your command-line tools and scripts behave as expected. Tests are written directly in Bash, allowing for seamless integration into existing shell-based projects. Each test file is a shell script containing one or more test cases, typically defined within a 'run' block followed by assertion functions. <i>Bats</i> executes each test case in a separate subshell, capturing its standard output, standard error, and exit status. These captured values are then compared against expected outcomes using a rich set of built-in assertion helpers like 'assert_output', 'assert_success', and 'assert_failure'. The framework's output conforms to the standard Test Anything Protocol (TAP), making it easily parsable by continuous integration (CI) systems and other automated test runners. This makes <i>Bats</i> an ideal choice for ensuring the reliability and correctness of shell scripts within automated build pipelines, enabling robust development practices for command-line utilities.


title: CAVEATS
content:
Tests within <i>Bats</i> run in a separate subshell, meaning that environment variable changes or directory changes made during a test case do not persist across different test cases. This isolation, while beneficial for reliability, can sometimes make debugging complex multi-step interactions challenging. While primarily designed for Bash, the test logic itself must be written in Bash, even if the script being tested is in another shell. Performance might be a consideration for extremely large test suites without utilizing parallel execution (--jobs).


title: TEST FILE STRUCTURE
content:
<i>Bats</i> test files typically end with the <i>.bats</i> extension. They are standard Bash scripts where test cases are defined using a descriptive string followed by a <i>{ ... }</i> block containing a <i>run</i> command and one or more assertion calls. Common setup/teardown hooks like <i>setup_file()</i>, <i>teardown_file()</i>, <i>setup()</i>, and <i>teardown()</i> can be defined to manage test state before and after individual tests or entire test files.


title: ASSERTIONS
content:
<i>Bats</i> provides a comprehensive set of assertion functions to verify test outcomes. Key assertions include <i>assert_output</i> (to check the standard output against an expected string), <i>assert_success</i> (to verify a zero exit status), <i>assert_failure</i> (to verify a non-zero exit status), <i>assert_line</i> (to check specific lines in output), <i>assert_equal</i>, <i>assert_dir_exists</i>, and more. These simplify the process of writing robust tests without external dependencies.


title: HISTORY
content:
<i>Bats</i> was initially developed by Sam Stephenson at GitHub as a lightweight solution for testing command-line utilities written in shell. Its simplicity and native Bash syntax quickly led to its adoption in various projects. Over time, the project transitioned to community maintenance under the <i>bats-core</i> organization, ensuring its continued development, feature enhancements, and bug fixes, solidifying its position as a leading tool for shell script testing.


title: PARAMETERS
content:
<b>--engage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a full sequence of Battlestar Galactica-themed effects, which might include sound, text, and ASCII art.<br><br><b>--theme</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays the main theme song or other relevant audio from the series.<br><br><b>--quotes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a random quote from a character or a notable line from the show.<br><br><b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a bridge console or ship status display, often with dynamic updates.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief usage message and available custom options for the specific script implementation.<br><br>


title: DESCRIPTION
content:
The "<b>battlestar</b>" command is <I>not</I> a standard, pre-installed Linux utility. Instead, it typically refers to a user-created shell script or alias, often developed by fans of the "Battlestar Galactica" science fiction series. Its primary purpose is usually for entertainment, novelty, or a personalized touch to the command-line experience.<br><br>While its exact functionality varies widely depending on how an individual user implements it, common manifestations include playing the iconic theme song, displaying random quotes from the show, showing ASCII art representations of ships or characters, or simulating a ship's status interface. It serves as a fun, interactive way to bring elements of the fictional universe into the terminal environment, rather than performing any core system task.


title: CAVEATS
content:
The "<b>battlestar</b>" command is <I>entirely user-defined</I> and not part of any standard Linux distribution or package. Its existence, syntax, and functionality are completely dependent on whether a user has personally created and installed such a script or alias on their system. Therefore, it is not universally available, and attempting to run it on a typical system without prior setup will result in a "command not found" error. It is often a playful addition to a shell's `~/.bashrc` or `~/.zshrc` file.


title: CONCEPTUAL NATURE
content:
It's important to reiterate that "<b>battlestar</b>" is a conceptual command, representing a class of personalized, entertainment-focused scripts rather than a single, universally recognized executable. Its implementation can range from a simple alias to a complex shell script integrating various system utilities.


title: TYPICAL IMPLEMENTATION TOOLS
content:
A user creating a "<b>battlestar</b>" script might utilize a variety of standard Linux commands. For playing audio, `aplay` or `mpg123` might be used. For displaying text and ASCII art, `echo`, `cat`, `cowsay`, or `figlet` are common. Random quotes might be pulled from a custom text file or integrated with `fortune`.


title: HISTORY
content:
As a non-standard command, "<b>battlestar</b>" has no official development history. Its 'history' is anecdotal, stemming from individual Linux and Unix users who, out of fandom for the "Battlestar Galactica" series, craft personalized shell scripts or aliases to add a touch of whimsy and fan-service to their daily command-line interactions. It represents a creative use of shell scripting to extend the terminal experience beyond purely functional tasks, often shared within programming and fan communities as an example of shell customization.


title: PARAMETERS
content:
<b>-d <i>&lt;delay&gt;</i>, --delay <i>&lt;delay&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify the delay in seconds between screen updates. The default update interval is 1 second.</I><br><br><b>-n <i>&lt;count&gt;</i>, --count <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Exit <b>battop</b> after the specified number of updates have occurred.</I><br><br><b>-b <i>&lt;power_supply_id&gt;</i>, --battery <i>&lt;power_supply_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Monitor a specific battery by its ID (e.g., BAT0, BAT1). If this option is not specified, <b>battop</b> will display information for all detected batteries.</I><br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display the version information of <b>battop</b> and then exit.</I><br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display a concise help message detailing command usage and available options, then exit.</I><br><br>


title: DESCRIPTION
content:
<b>battop</b> is a command-line utility for monitoring battery status in real-time on Linux systems. It provides an interactive interface, conceptually similar to <b>top</b> or <b>htop</b>, but specifically designed to display comprehensive battery information. This includes current charge percentage, full capacity, charge/discharge rates, voltage, temperature (if available), health status, and estimated time remaining.<br><br>The tool aggregates data from the <i>/sys/class/power_supply</i> subsystem, offering a dynamic and easy-to-read view of all detected power supply devices. <b>battop</b> is particularly useful for laptop and mobile device users, allowing them to quickly assess battery health, monitor power consumption, and understand charging/discharging behavior without needing to manually parse raw system files. It can aid in diagnosing power-related issues or simply keeping an eye on battery performance during mobile operation. Its intuitive design makes it a valuable addition to a system administrator's or power user's toolkit.


title: CAVEATS
content:
<b>battop</b> is a Linux-specific utility as it relies directly on the <i>/sys/class/power_supply</i> filesystem for battery data. It may not work correctly or display complete information on all hardware configurations, especially if ACPI or power supply drivers are not standard or fully supported by the kernel. For typical usage, it requires appropriate permissions to read power supply information, which is generally accessible to normal users. It is primarily intended for devices with exposed battery information, such as laptops; desktop systems without a UPS or integrated battery might not show any relevant data.


title: INTERACTIVE KEYS
content:
<I>When <b>battop</b> is running in its interactive display mode, users can press 'q' to immediately quit the application. Additionally, pressing 'r' will force an immediate refresh of the displayed battery data, overriding the configured update delay.</I>


title: UNDERLYING DATA SOURCE
content:
<I>The information presented by <b>battop</b> is directly sourced from the Linux kernel's power supply subsystem. This subsystem exposes various power-related details through a structured hierarchy of files within the <i>/sys/class/power_supply</i> directory. Each power supply device (e.g., a specific battery like BAT0, or an AC adapter identified as AC) has its own subdirectory containing files like <i>capacity</i>, <i>energy_now</i>, <i>voltage_now</i>, <i>status</i>, and <i>charge_now</i>. <b>battop</b> reads and interprets these files to present its real-time data to the user.</I>


title: HISTORY
content:
<b>battop</b> is a relatively modern command-line utility, often implemented using memory-safe languages like Rust to provide a robust and efficient real-time experience. Its development likely emerged in response to the growing need for a more user-friendly, interactive battery monitoring tool, offering a visual alternative to manually parsing raw system files or using less dynamic commands like <b>acpi</b>. It aims to provide a <b>top</b>-like interface for battery status, making it easier for users to track power statistics. While its exact initial release date can vary depending on specific open-source projects with similar names or goals, the general concept of a `top`-style battery monitor gained traction in the late 2010s within the Linux community.


title: SYNOPSIS
content:
<b>bazel</b> <<i>command</i>> [<<i>options</i>>] [<<i>targets</i>>]<br><br>Common commands include:<br><b>bazel build</b> <<i>targets</i>> [<<i>build_options</i>>]<br><b>bazel test</b> <<i>targets</i>> [<<i>test_options</i>>]<br><b>bazel run</b> <<i>target</i>> [<<i>run_options</i>>]<br><b>bazel clean</b><br><b>bazel shutdown</b><br><b>bazel query</b> <<i>expression</i>> [<<i>query_options</i>>]<br><b>bazel help</b> [<<i>command</i>>]


title: PARAMETERS
content:
<b><b>--output_base=</b><<i>path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory for Bazel's output files and internal caches.<br><br><b><b>--workspace=</b><<i>path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path to the workspace root directory. Defaults to the current directory.<br><br><b><b>--bazelrc=</b><<i>file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative Bazel configuration file to use.<br><br><b><b>--config=</b><<i>name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a predefined configuration specified in the .bazelrc file.<br><br><b><b>--jobs=</b><<i>N</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of concurrent jobs (build processes).<br><br><b><b>--verbose_failures</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the command line and environment of failed actions.<br><br><b><b>--remote_cache=</b><<i>url</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables remote caching of build artifacts, specifying the cache server URL.<br><br><b><b>--remote_executor=</b><<i>url</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables remote execution of build actions, specifying the executor server URL.<br><br><b><b>--test_output=</b><<i>summary|errors|all|streamed</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls how test output is displayed after execution.<br><br><b><b>--host_javabase=</b><<i>path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Java runtime to be used by Bazel itself.<br><br>


title: DESCRIPTION
content:
<i>Bazel</i> is an open-source build and test automation tool developed by Google. It's designed to handle large, multi-language software projects with speed and accuracy. Key features include <i>hermetic builds</i>, meaning builds are isolated from the host system's environment, ensuring reproducible results regardless of the build machine. It achieves high performance through aggressive caching of build steps and parallel execution. Bazel uses a <i>WORKSPACE</i> file to define the project root and external dependencies, and <i>BUILD</i> files, written in a Starlark-based language, to describe how to build specific targets (executables, libraries, tests). It supports a wide range of languages and platforms, including Java, C++, Go, Python, Android, iOS, and more, often extensible through community-contributed rule sets. Its capabilities for remote caching and execution allow large teams to share build artifacts and distribute compilation tasks, significantly speeding up development cycles and continuous integration pipelines.


title: CAVEATS
content:
<b>Complexity:</b> Bazel has a significant learning curve due to its unique build model and configuration language (Starlark).<br><b>Resource Usage:</b> Can consume considerable disk space and RAM, especially for large projects, due to extensive caching.<br><b>Setup Overhead:</b> Initial setup and configuration for a project, including writing <i>BUILD</i> files and defining dependencies, can be time-consuming.<br><b>Strictness:</b> Its hermeticity and strict dependency enforcement can sometimes feel restrictive, requiring explicit declarations for all inputs.


title: <B>WORKSPACE CONCEPT</B>
content:
A Bazel project is defined by a <i>workspace</i>, typically containing a <i>WORKSPACE</i> file at its root. This file declares the project's external dependencies and global settings. Build rules are then defined in <i>BUILD</i> files within the workspace, organizing code into packages and targets. Bazel constructs a precise dependency graph of all sources, tools, and outputs.


title: <B>HERMETICITY</B>
content:
One of Bazel's core tenets is <i>hermetic builds</i>. This means that build outputs are strictly determined by their inputs, and are isolated from non-declared dependencies like environment variables, installed tools, or user-specific configurations. This ensures that a build will produce the exact same output every time, on any machine, greatly improving reproducibility and debugging.


title: <B>BUILD RULES AND STARLARK</B>
content:
Bazel uses <i>build rules</i> to define how different types of software components are built. These rules are specified in <i>BUILD</i> files using Starlark, a restricted dialect of Python. Starlark is intentionally non-Turing complete and deterministic, which helps ensure that build configurations are predictable and evaluable by Bazel to construct the precise dependency graph necessary for hermeticity and parallelism.


title: HISTORY
content:
Bazel originated as an internal build tool at Google, named <i>Blaze</i>, designed to manage Google's massive monorepo and complex software projects. It was open-sourced in 2015, bringing its powerful capabilities for reproducible, scalable, and fast builds to the wider developer community. Since then, it has seen continuous development and adoption by various companies and open-source projects.


title: PARAMETERS
content:
<b><b>-c</b> <I>task</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specific task for the target recipe(s), e.g., 'do_compile', 'do_install', 'do_clean'.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue building as much as possible after encountering an error, rather than stopping immediately.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available recipes in the current build configuration.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the entire global environment and configuration, useful for debugging.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform all parsing and dependency resolution but do not actually execute any build tasks.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a dependency graph of the build tasks, often in dot format.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the debug level for more verbose output during the build process.<br><br><b><b>--runall=</b><I>PN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute all defined tasks for a specified package name (PN).<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information and exit.<br><br>


title: DESCRIPTION
content:
The command 'bb' is <i>not</i> a standard, standalone Linux utility found in most general-purpose distributions. However, it is an extremely common alias for <I>bitbake</I>, the core build automation tool of the Yocto Project and OpenEmbedded. <br><br><i>Bitbake</i> is a sophisticated, make-like build system designed for cross-compilation and the creation of complete Linux distributions for embedded devices. It manages complex dependencies, parses 'recipes' (typically '.bb' files) that define how software components are fetched, configured, compiled, and packaged. It can build in parallel, leverage shared state caching for incremental builds, and generate entire root filesystems, bootloaders, kernels, and toolchains for various target architectures. Its primary goal is to provide a reproducible and customizable build environment for embedded Linux development.


title: CAVEATS
content:
The command 'bb' is almost exclusively used as an alias for 'bitbake' within the context of embedded Linux development, particularly with the Yocto Project and OpenEmbedded. If you're not working with these projects, 'bb' is unlikely to be a pre-existing command on your system. <br><br><i>Bitbake</i> itself has a steep learning curve and requires a significant understanding of its recipe format, layers, and configuration files (like 'local.conf' and 'bblayers.conf'). It is not a general-purpose build tool for typical application development but is highly specialized for creating custom Linux distributions and SDKs.


title: HISTORY
content:
<i>Bitbake</i> was originally developed by Chris Larson for the OpenEmbedded project, which aimed to provide a comprehensive build framework for embedded Linux. It later became the central build engine for the Yocto Project, an open-source collaboration project that helps developers create custom Linux-based systems for embedded products. Its development has focused on handling the complexities of cross-compilation, managing vast numbers of software packages, and ensuring build reproducibility for diverse embedded hardware architectures.


title: SYNOPSIS
content:
<b>bc</b> [<i>OPTIONS</i>] [<i>FILE...</i>]<br><br><i>Examples:</i><br><b>bc</b><br><b>bc</b> <i>-l</i><br><b>bc</b> <i>myfile.bc</i><br><b>echo</b> <i>"scale=4; 10/3"</i> | <b>bc</b>


title: PARAMETERS
content:
<b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the standard math library, which provides functions like sine, cosine, arctangent, natural logarithm, exponential, and square root.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the POSIX <b>bc</b> syntax and disables GNU <b>bc</b> extensions. This ensures strict POSIX compliance.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the normal GNU <b>bc</b> welcome message and copyright notice upon startup.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints warnings for GNU <b>bc</b> extensions when used with POSIX <b>bc</b> syntax.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for <b>bc</b> and then exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and then exits.<br><br><b>[file ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more files containing <b>bc</b> commands to be executed. <b>bc</b> processes these files in order, then reads from standard input if no <i>-q</i> option is used and standard input is not a terminal.<br><br>


title: DESCRIPTION
content:
<b>bc</b> stands for "basic calculator" and is a command-line utility and a programming language for arbitrary precision arithmetic. It can be used interactively or to execute scripts from files. It supports basic arithmetic operations (addition, subtraction, multiplication, division, modulo, exponentiation), variables, arrays, control flow statements (if, while, for), and user-defined functions.<br><br>Unlike typical shell arithmetic, <b>bc</b> automatically handles numbers of virtually any size and precision, limited only by available memory. This makes it invaluable for financial calculations, cryptographic operations, or scientific computations where floating-point inaccuracies are unacceptable. Input is typically read from standard input or specified files, and results are printed to standard output. Its behavior can be extended via the built-in math library or custom functions. It's often used in shell scripts for complex calculations that require higher precision than standard shell built-ins provide.


title: CAVEATS
content:
<i>Precision Control:</i> The default precision (number of digits after the decimal point) is 0. Users must explicitly set the <b>scale</b> variable (e.g., <b>scale=20</b>) to achieve desired precision for division and square root operations.<br><i>GNU vs. POSIX:</i> There are differences between GNU <b>bc</b> (commonly found on Linux) and POSIX <b>bc</b>. GNU <b>bc</b> includes extensions like the <b>read</b> function and a specific format for the <b>for</b> statement that are not present in POSIX <b>bc</b>.<br><i>Input Limitations:</i> While <b>bc</b> handles large numbers, very complex or extremely long calculations might consume significant memory and processing time.


title: THE 'SCALE' VARIABLE
content:
The <b>scale</b> variable is crucial for controlling the number of digits after the decimal point used in calculations. Its default value is 0. For example, to get '3.333' from '10/3', you must set <b>scale=3</b> before the division. This variable affects division, square root, and other functions from the math library.


title: MATH LIBRARY (-L)
content:
When invoked with the <b>-l</b> option, <b>bc</b> loads a standard math library. This library provides common mathematical functions such as <b>s(x)</b> for sine, <b>c(x)</b> for cosine, <b>a(x)</b> for arctangent, <b>l(x)</b> for natural logarithm, <b>e(x)</b> for exponential, and <b>j(n,x)</b> for Bessel functions. These functions operate on angles in radians.


title: HISTORY
content:
<b>bc</b> originated in the early days of Unix at Bell Labs, developed by Robert Morris. It was designed as a front-end processor to the arbitrary precision reverse Polish notation calculator <b>dc(1)</b>. While <b>dc</b> provided the core arbitrary precision capabilities, its RPN syntax was less intuitive for many users. <b>bc</b> was created to provide a more traditional infix notation interface, making arbitrary precision calculations more accessible.<br>The GNU project later developed its own version of <b>bc</b>, which is the most commonly encountered version on modern Linux systems. GNU <b>bc</b> extended the original POSIX specification with additional features and functions, providing more robust programming capabilities.


title: PARAMETERS
content:
<b><b>format</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new bcachefs filesystem on one or more devices.<br><i>Example:</i> <code>bcachefs format /dev/sda1 /dev/sdb1</code><br><br><b><b>fs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage general filesystem properties and internal components.<br><i>Example:</i> <code>bcachefs fs set /mnt/myfs compression=zstd</code><br><br><b><b>device</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage individual devices within a bcachefs filesystem (e.g., add, remove, resize).<br><i>Example:</i> <code>bcachefs device add /mnt/myfs /dev/sdc1</code><br><br><b><b>snapshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create, list, or delete snapshots of a bcachefs filesystem.<br><i>Example:</i> <code>bcachefs snapshot create /mnt/myfs /mnt/myfs/.snapshots/today</code><br><br><b><b>quota</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manage and display disk usage quotas for users or groups.<br><i>Example:</i> <code>bcachefs quota enable /mnt/myfs</code><br><br><b><b>repair</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to repair a damaged bcachefs filesystem, often used after unclean shutdowns.<br><i>Example:</i> <code>bcachefs repair /dev/sdd1</code><br><br><b><b>scrub</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiate a background scrub (checksum validation and repair) of the filesystem data.<br><i>Example:</i> <code>bcachefs scrub start /mnt/myfs</code><br><br><b><b>balance</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebalance data across devices in a bcachefs filesystem, useful after adding or removing devices.<br><i>Example:</i> <code>bcachefs balance start /mnt/myfs</code><br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information and status of bcachefs filesystems, including device health and usage.<br><i>Example:</i> <code>bcachefs status</code><br><br><b><b>mount</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount a bcachefs filesystem.<br><i>Note:</i> Typically, the standard <code>mount(8)</code> command is used for this, but `bcachefs mount` can also be used for convenience.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help for `bcachefs` or a specific subcommand.<br><i>Example:</i> <code>bcachefs help format</code><br><br>


title: DESCRIPTION
content:
bcachefs is a modern, copy-on-write (COW) Linux filesystem that aims to combine the best features of <b>btrfs</b> and <b>ZFS</b> with high performance. It's built on the bcache block layer caching technology, expanding it into a full-fledged filesystem. It supports advanced features such as snapshots, data integrity (checksumming), data replication/erasure coding, caching (multiple tiers of storage), and online resizing. bcachefs is designed to be highly scalable and robust, suitable for various workloads from desktop to server environments, offering both flexibility and resilience.<br><br>The `bcachefs` command-line utility serves as the primary interface for managing and interacting with bcachefs filesystems. It provides a comprehensive set of subcommands to perform tasks like filesystem creation, device management (adding/removing devices), snapshot administration, setting filesystem properties (e.g., compression, caching policies), initiating data scrubs, balancing data, and checking the overall status of bcachefs pools. This integrated command simplifies the administration of complex bcachefs setups.


title: CAVEATS
content:
bcachefs, while robust and feature-rich, is a relatively new filesystem in the Linux kernel mainline (merged in 6.7). Its development is ongoing, and while generally stable, it might still have bugs or design changes. Users should exercise caution and ensure proper backups for critical data, especially in early adoption scenarios. Recovery tools and extensive long-term stability data may be less mature compared to older, more established filesystems like Ext4 or XFS.


title: KEY FEATURES
content:
bcachefs boasts a comprehensive set of features including:<br><ul><li>Copy-on-Write (COW) architecture for data integrity and snapshots.</li><li>Multiple device support, allowing creation of filesystems spanning multiple disks.</li><li>Data checksumming (CRC64) for detecting corruption.</li><li>Flexible caching tiers for performance optimization (e.g., SSD for cache, HDD for bulk storage).</li><li>Data replication and erasure coding for redundancy.</li><li>Compression support (zstd, lz4).</li><li>Snapshots and subvolumes.</li><li>Online resizing and rebalancing.</li><li>Quotas for users and groups.</li></ul>


title: PERFORMANCE CHARACTERISTICS
content:
Designed from the ground up for performance, bcachefs leverages its underlying `bcache` technology for efficient metadata and data handling. It aims to offer high I/O throughput and low latency, making it suitable for demanding workloads. Its multi-tier caching capabilities allow users to optimize performance by utilizing faster storage devices for hot data.


title: HISTORY
content:
bcachefs was developed by Kent Overstreet, the creator of the original `bcache` block layer caching system. Development began around 2012, aiming to build a full-fledged filesystem on top of the efficient `bcache` B+tree implementation. It represents a significant effort to combine the advanced features of copy-on-write filesystems like <b>btrfs</b> and <b>ZFS</b> with high performance and scalability. After years of development and testing, bcachefs was officially merged into the Linux kernel mainline in version 6.7 in late 2023 / early 2024, marking its readiness for wider adoption.


title: SYNOPSIS
content:
<I><b>bcachefs-device</b> &lt;subcommand&gt; [options] &lt;device-path|uuid|id&gt; [...other_arguments]</I><br><I><b>bcachefs-device</b> list [options] [device-path|uuid|id...]</I><br><I><b>bcachefs-device</b> rescan</I>


title: PARAMETERS
content:
<b>add <device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Adds a new block device to an existing bcachefs filesystem. This typically involves specifying the path to the unformatted device.</I><br><br><b>remove <device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Removes a device from the filesystem. Data on the removed device is migrated to other devices if necessary, unless --discard-data is used.</I><br><br><b>set <device> <key>=<value>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Modifies specific properties or options for an existing device within the filesystem, such as its writeback status or allocation groups.</I><br><br><b>list [device...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays detailed information about all or specified devices within bcachefs filesystems, including their UUIDs, sizes, and states.</I><br><br><b>clear <device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Erases all bcachefs metadata from a specified block device, preparing it for reuse outside of bcachefs or for re-addition.</I><br><br><b>uuid <device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prints the bcachefs UUID of a specified device.</I><br><br><b>rescan</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Scans for new or changed bcachefs devices across the system.</I><br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Used with some subcommands (e.g., <b>remove</b>, <b>clear</b>) to override safety checks and proceed with the operation.</I><br><br><b>--background</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Used with operations like <b>remove</b> to perform the data migration in the background, allowing the command to return immediately.</I><br><br><b>--discard-data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Used with <b>remove</b> to quickly remove a device without migrating its data, resulting in data loss for data exclusively on that device.</I><br><br>


title: DESCRIPTION
content:
<I>The <b>bcachefs-device</b> command is a crucial utility within the bcachefs filesystem suite, designed for managing the physical storage devices that comprise a bcachefs filesystem. Bcachefs is a modern, high-performance Linux filesystem known for its advanced features like snapshots, data integrity, and caching capabilities, often built upon multiple underlying devices. This command allows administrators to add new storage devices to an existing bcachefs filesystem, expand its capacity, or remove devices as needed. It also facilitates querying detailed information about currently integrated devices, clearing bcachefs metadata from a device, or modifying device-specific properties. Effective use of <b>bcachefs-device</b> is essential for dynamically managing the storage layout and ensuring the health and scalability of bcachefs deployments. It typically operates on block devices such as disks or partitions, identified by their path (e.g., /dev/sdb), UUID, or internal bcachefs device ID.</I>


title: CAVEATS
content:
<I>Incorrect usage of <b>bcachefs-device</b>, especially subcommands like <b>remove</b> or <b>clear</b>, can lead to severe data loss. Always ensure you have a current backup before performing device-level modifications on a live filesystem. The command often requires root privileges for execution. As bcachefs is a relatively new filesystem to be mainline, its tools and functionalities are still evolving, and users should be aware of potential changes or edge cases. Performance implications should also be considered when adding or removing devices from an active filesystem.</I>


title: <I>DEVICE IDENTIFICATION</I>
content:
<I>Devices managed by <b>bcachefs-device</b> can be referred to by their kernel path (e.g., <i>/dev/sdb</i>), their bcachefs-specific UUID, or an internal device ID. Using UUIDs or internal IDs is often preferred for scripting and stability, as kernel paths can change upon reboot or device reordering.</I>


title: <I>DATA MIGRATION DURING REMOVAL</I>
content:
<I>When a device is removed from a bcachefs filesystem using <b>bcachefs-device remove</b>, the data stored on that device is typically migrated to other available devices in the filesystem. This process can be time-consuming depending on the amount of data and device speed. The <i>--discard-data</i> option can bypass this migration, but it will result in data loss for data exclusively on the removed device.</I>


title: HISTORY
content:
<I>The <b>bcachefs-device</b> command is an integral part of the bcachefs filesystem utilities, developed primarily by Kent Overstreet. Bcachefs itself evolved from the `bcache` project, aiming to create a robust, feature-rich, and high-performance copy-on-write filesystem for Linux. Development has been ongoing for over a decade, with <b>bcachefs-device</b> appearing as part of the `bcachefs-tools` userspace package necessary to manage the filesystem. Bcachefs achieved mainline Linux kernel inclusion with version 6.7 in late 2023 / early 2024, bringing its advanced storage management capabilities, including device manipulation via commands like <b>bcachefs-device</b>, to a wider audience.</I>


title: SYNOPSIS
content:
Given that <b>bccmd</b> is a hardware-specific utility and not a standard Linux command, its exact syntax can vary significantly depending on the Broadcom chipset and the version of the utility. However, a common pattern involves subcommands and options for device selection.<br><br><b><I>bccmd [options] &lt;subcommand&gt; [subcommand_arguments]</I></b><br><br>Common subcommand examples include:<br><b><I>bccmd update &lt;firmware_file&gt;</I></b><br><b><I>bccmd diag &lt;test_type&gt;</I></b><br><b><I>bccmd status</I></b><br><b><I>bccmd -d &lt;device_index&gt; &lt;command&gt;</I></b>


title: PARAMETERS
content:
<b>-d <device_index></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network device to operate on, usually by its numerical index (e.g., 0, 1).<br><br><b>-f <file_path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with subcommands like `update` to provide the path to a firmware or configuration file.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the operation.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, detailing available commands and options for that specific `bccmd` version.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A common subcommand to flash or update the device's firmware.<br><br><b>diag</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A common subcommand to run diagnostic tests on the hardware.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A common subcommand to query the operational status or hardware information of the device.<br><br>


title: DESCRIPTION
content:
The <b>bccmd</b> command is <I>not</I> a standard, universally available Linux utility. Instead, it typically refers to a specialized tool provided by Broadcom, or by device driver packages (like `tg3`, `bnx2`) for managing and diagnosing Broadcom network interface cards (NICs).<br><br>Its primary function revolves around hardware-level operations on these Broadcom NICs. Common uses include updating network adapter firmware, reading or writing to the device's EEPROM or NVRAM, dumping internal registers for diagnostic purposes, and retrieving hardware status information. Because it interacts directly with hardware, its exact functionality, syntax, and availability depend heavily on the specific Broadcom chipset it's designed for, and the version of the utility provided by the manufacturer or driver package. It's often found within `bcm_utils` packages or as part of a kernel module's helper tools. Misuse can lead to irreversible hardware damage.


title: CAVEATS
content:
<b>bccmd</b> is <I>not</I> part of the standard Linux distribution. Its availability is tied to systems with Broadcom network adapters and the installation of specific utility packages or drivers. <br><br>Using <b>bccmd</b> often requires root privileges due to its direct hardware interaction. <br><br>Improper use, especially with firmware updates, can lead to irreversible damage to the network adapter, rendering it unusable (bricking). <br><br>The exact options and subcommands can differ significantly between different Broadcom chipsets and utility versions, requiring users to consult specific hardware documentation or the utility's built-in help (`-h`).


title: AVAILABILITY
content:
Because <b>bccmd</b> is not standard, it typically needs to be obtained from Broadcom's official driver packages, system vendor support sites (e.g., Dell, HP for server NICs), or sometimes it's bundled within the kernel module source for specific Broadcom drivers. It is not usually found in standard distribution repositories.


title: DRIVER CONTEXT
content:
On Linux systems, <b>bccmd</b> often works in conjunction with Broadcom kernel modules like `tg3` (for Broadcom Tigon3 Gigabit Ethernet controllers) or `bnx2` (for Broadcom NetXtreme II 10/100/1000/10000 Mbit Ethernet controllers). These modules provide the necessary interface for <b>bccmd</b> to interact with the underlying hardware.


title: HISTORY
content:
The development and usage of `bccmd` are inextricably linked to Broadcom Corporation's long history in producing Ethernet controllers and other networking silicon. As Broadcom NICs became prevalent in servers and workstations, specialized tools were developed to manage their hardware-specific features, including firmware updates and diagnostics, which are not covered by generic network utilities like `ethtool`. Thus, `bccmd` evolved as an internal or driver-bundled utility to support these specific Broadcom hardware functionalities, often provided by kernel modules such as `tg3` or `bnx2` or through dedicated Broadcom utility packages.


title: SYNOPSIS
content:
As <b>bcd</b> is not a standard Linux command, there is <I>no universal synopsis</I> for its usage. If it were a custom script or alias, its synopsis would depend entirely on its creator's implementation.


title: DESCRIPTION
content:
The command <b>bcd</b> is <I>not a standard or commonly recognized utility</I> in typical Linux distributions. Users searching for <b>bcd</b> often encounter information related to:<br><br>1. <b>Windows Boot Configuration Data (BCD):</b> This refers to a firmware-independent database used by Microsoft's new Boot Manager (BOOTMGR) in Windows Vista and later versions, replacing the <b>boot.ini</b> file. Tools like <b>bcdedit.exe</b> are used to manage it on Windows.<br>2. <b>Binary-Coded Decimal (BCD):</b> This is a numerical encoding scheme where each decimal digit is represented by its own binary sequence. It's often encountered in low-level programming, embedded systems, or hardware, but not as a standalone user-facing Linux command.<br><br>Therefore, if you are looking for a Linux command to perform a specific task, it is highly likely that <b>bcd</b> is a <I>misconception, a typo</I> (e.g., for <b>cd</b>, <b>bc</b>, <b>bootctl</b>), or refers to a <I>highly specialized, non-standard, or custom script/alias</I> not part of general Linux system administration or usage.


title: CAVEATS
content:
The most significant caveat is that <b>bcd</b> is <I>not a recognized command</I> on standard Linux systems. Attempting to execute <b>bcd</b> will likely result in a 'command not found' error. Any reference to <b>bcd</b> in a Linux context should be treated with skepticism unless it refers to a very specific, niche, or custom environment.


title: BINARY-CODED DECIMAL (BCD)
content:
<I>Binary-Coded Decimal</I> is a class of binary encodings of decimal numbers where each decimal digit is represented by a fixed number of bits, usually four (a nibble). For example, the decimal number 123 would be represented in BCD as 0001 0010 0011. This encoding is often used in situations where precise decimal representation is crucial, such as in financial calculations or digital displays, avoiding floating-point inaccuracies. However, BCD is an encoding method, not a Linux command itself.


title: WINDOWS BOOT CONFIGURATION DATA (BCD)
content:
In the context of Microsoft Windows operating systems (Vista and later), <I>Boot Configuration Data (BCD)</I> is a database that contains boot-time configuration data and provides information about boot applications and their settings. It is a critical component for the Windows Boot Manager (BOOTMGR) to start the operating system. Users interact with BCD on Windows via the <b>bcdedit.exe</b> command-line utility. This concept is entirely specific to Windows and has <I>no direct equivalent or command</I> named <b>bcd</b> in Linux.


title: HISTORY
content:
There is <I>no documented history</I> of a command named <b>bcd</b> in the official development or usage of standard Linux distributions. Its name is not associated with any core Linux utility, package, or widely adopted third-party tool. Any specific use of 'bcd' would be outside the standard Linux ecosystem, likely as a custom script or alias by an individual user or organization.


title: PARAMETERS
content:
<b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force</I> overwrite. If the output file already exists, <I>bchunk</I> will overwrite it without prompting.<br><br><b><i>prefix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The common filename prefix of the split <I>.bz2</I> files. For example, if input files are <I>archive.bz2s_001.bz2</I>, <I>archive.bz2s_002.bz2</I>, then the prefix is <I>archive.bz2s_</I>. If this argument is not provided, <I>bchunk</I> defaults to looking for files with the prefix <I>bzip2s_</I>.<br><br>


title: DESCRIPTION
content:
<I>bchunk</I> is a utility designed to concatenate a series of <I>.bz2</I> files that were previously split by <I>bzip2split(1)</I> back into a single, complete <I>.bz2</I> archive. This is particularly useful for handling very large <I>bzip2</I> archives that needed to be broken into smaller, more manageable pieces, perhaps for storage on multiple removable media, transmission over networks with size limits, or simply for easier partial processing.<br><br><I>bchunk</I> reads the individual <I>.bz2</I> chunks, which typically have a common prefix and a sequential numeric suffix, and writes them contiguously to standard output or a specified output file. The process effectively reverses the splitting operation, restoring the original compressed file.


title: CAVEATS
content:
<I>bchunk</I> expects the input files to be valid <I>.bz2</I> chunks, typically generated by <I>bzip2split</I> using its standard numbering scheme (e.g., <I>001, 002, 003</I>). It is specifically designed for and only handles <I>.bz2</I> compressed files, not other archive formats.


title: TYPICAL USAGE
content:
To reassemble a file that was previously split using <I>bzip2split</I>, you would use <I>bchunk</I> and redirect its output to a new file.<br><br>Example:<br><I>bzip2split largefile.bz2</I>  <I># This creates files like largefile.bz2s_001.bz2, largefile.bz2s_002.bz2, etc.</I><br><I>bchunk largefile.bz2s_ > recreated.bz2</I>


title: OUTPUT DESTINATION
content:
By default, <I>bchunk</I> writes the reassembled content to standard output (<I>stdout</I>). To save the result to a file, you must explicitly use shell redirection (e.g., <I>> output.bz2</I>) as shown in the example above, as <I>bchunk</I> does not accept an output filename as a direct argument.


title: HISTORY
content:
<I>bzip2split</I> and <I>bchunk</I> are integral parts of the <I>bzip2</I> project, initially developed by Julian Seward. They were introduced to provide a practical solution for managing and manipulating extremely large <I>bzip2</I> compressed files by enabling them to be reliably split into smaller segments and subsequently recombined. Their inclusion enhanced the utility of <I>bzip2</I> for handling large datasets.


title: PARAMETERS
content:
<b><b>-c</b> <i>config_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Bacula configuration file to use. If not provided, <b>bcomps</b> will try to locate a default configuration file, typically 'bconsole.conf'.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output, showing only a brief summary of the comparison results. Useful for scripting or quick checks.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information during the comparison process, such as each file being compared.<br><br><b><i>volume1</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the first Bacula volume to be compared.<br><br><b><i>volume2</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the second Bacula volume to be compared.<br><br>


title: DESCRIPTION
content:
<b>bcomps</b> is a utility program provided as part of the <i>Bacula</i> backup system. Its primary function is to compare the contents of two specified Bacula volumes. This comparison is done at the file level, identifying whether files on both volumes match, differ, or exist on one volume but not the other.<br><br>This command is particularly useful for verifying the integrity of copied volumes (e.g., from disk to tape or between different storage locations), for auditing purposes, or for ensuring that a disaster recovery replica is identical to its source. It helps administrators quickly pinpoint discrepancies between two backup sets.<br><br>It operates by reading the file metadata and data on both volumes and reporting any inconsistencies. It's a non-destructive operation, meaning it only reads the volumes and does not modify their contents. The output typically lists files that are identical, different, or unique to one of the volumes.


title: CAVEATS
content:
The <b>bcomps</b> utility is specific to <i>Bacula</i> volumes and cannot be used to compare arbitrary files or other backup formats. It requires access to the Bacula catalog database or appropriate configuration to interpret volume data correctly.<br><br>The comparison can be resource-intensive for very large volumes, requiring significant I/O operations. Ensure that the Bacula Storage Daemon has access to both volumes.


title: TYPICAL USE CASES
content:
<b>bcomps</b> is frequently used in scenarios where data integrity and verification are paramount:<br><ul><li><i>Verification of Volume Copies</i>: After copying a Bacula volume (e.g., tape to tape, disk to disk), <b>bcomps</b> can confirm that the copy is bit-for-bit identical to the original.</li><li><i>Auditing and Compliance</i>: For regulatory compliance, it can provide proof that two backup sets contain the same data at a specific point in time.</li><li><i>Disaster Recovery Testing</i>: Helps ensure that a restored dataset from one volume matches the original data from another volume, verifying the recovery process.</li></ul>


title: HOW IT WORKS
content:
<b>bcomps</b> interacts with the <i>Bacula Storage Daemon</i> and potentially the <i>Bacula Catalog</i> (database) to access and interpret the data on the specified volumes. It reads the file records from each volume, comparing attributes like filename, size, checksums, and modification times. For a thorough comparison, it might also read and compare file data blocks directly. Discrepancies are reported to the standard output.


title: HISTORY
content:
The <b>bcomps</b> command is an integral part of the <i>Bacula</i> backup system, an open-source enterprise-ready backup solution. Bacula was originally developed by Kern Sibbald, with the first public release in 2002. Utilities like <b>bcomps</b> were developed alongside the core system to provide essential functionalities for managing and verifying backup data, evolving with the Bacula project over the years to improve efficiency and feature sets for robust data management.


title: SYNOPSIS
content:
As <i>bdfr</i> is not a standard command, a universal synopsis cannot be provided. If it exists as a custom script or program on a specific system, its syntax would be defined by that script's or program's implementation.


title: DESCRIPTION
content:
The command <i>bdfr</i> does not appear to be a standard Linux utility or a widely recognized open-source project. Its functionality, if any, is not documented in common Linux distributions' man pages or package repositories. Therefore, a detailed analysis, including its synopsis, parameters, and related information, cannot be provided based on general Linux knowledge. Users encountering <i>bdfr</i> should investigate its origin within their specific environment, as it is likely a custom script, an internal alias, or part of a very niche application.


title: CAVEATS
content:
This command is not part of standard Linux installations. Its existence and functionality would depend on custom scripts or specific niche applications not generally available. It is advisable to exercise caution if you encounter an unknown executable named <i>bdfr</i>, as its purpose is undefined without context.


title: <B>NON-STANDARD COMMAND IDENTIFICATION</B>
content:
It is highly probable that <i>bdfr</i> is either a custom script specific to a particular system, a typo for another command, or a command from a very specialized and non-mainstream software package. It is not part of the GNU core utilities, busybox, or common system management tools. <br>To understand its purpose, one would need to inspect its source code (if available) or consult the system administrator who deployed it.


title: HISTORY
content:
There is <b>no known history or development</b> for a standard Linux command named <i>bdfr</i>. Its presence would indicate a specific, non-mainstream origin.


title: PARAMETERS
content:
<b><b>-o</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output PCF file. If omitted, output goes to standard output.<br><br><b><b>-p</b> <i>padding</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bitmap padding (0, 1, 2, or 4 bytes). Default is 4.<br><br><b><b>-u</b> <i>unit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bitmap scanline unit (1, 2, or 4 bytes). Default is 1.<br><br><b><b>-m</b> <i>metric</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bitmap scanline endianness (0 for little-endian, 1 for big-endian). Default is architecture-dependent.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force all glyphs to be left-padded (default for PCF).<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force all glyphs to be right-padded.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force all glyphs to be padded with the natural scanline unit.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate the <i>Ink_Metrics</i> property.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate the <i>Terminal_Font</i> property.<br><br><b><b>-T</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Truncate all character properties that exceed 255 bytes.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing progress and information.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the program version and exit.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only convert characters that explicitly exist in the font's encoding. Unencoded characters are skipped.<br><br><b><b>-d</b> <i>DPI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set default <i>DPI</i> values (e.g., 75, 100) if missing from the BDF font properties.<br><br><b><b>-B</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force output PCF to be big-endian. Overrides <b>-m</b>.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force output PCF to be little-endian. Overrides <b>-m</b>.<br><br>


title: DESCRIPTION
content:
<i>bdftopcf</i> is a utility designed to convert font files from the Glyph Bitmap Distribution Format (BDF) into the Portable Compiled Format (PCF). BDF files are human-readable, ASCII-based descriptions of fonts, including glyph bitmaps, metrics, and properties. While BDF is excellent for font creation and editing, its text-based nature makes it inefficient for direct use by graphical systems. <br><br>PCF, on the other hand, is a compact, binary font format optimized for fast loading and rendering by X servers and font utilities within the X Window System. <i>bdftopcf</i> processes the BDF input, performing necessary optimizations and reorganizations of the font data (e.g., bit packing, byte ordering) to produce an efficient PCF file. This conversion is crucial for making custom or non-standard bitmap fonts available to X applications, ensuring they can be quickly loaded and displayed.


title: CAVEATS
content:
While still functional, <i>bdftopcf</i> is part of an older X Window System font rendering stack. Modern Linux desktops heavily rely on Fontconfig and FreeType for font management, which support scalable font formats (TrueType, OpenType) and provide advanced rendering features. <i>bdftopcf</i> remains relevant for managing legacy bitmap fonts or in specific embedded/minimal X environments where scalable fonts are not desired or feasible. It does not handle font scaling or anti-aliasing; it merely converts bitmap font data.


title: BDF VS. PCF FONT FORMATS
content:
<b>BDF (Glyph Bitmap Distribution Format)</b> is a simple, human-readable ASCII format for bitmap fonts, commonly used for creating and editing fonts. It describes each glyph pixel by pixel, along with font properties like character set, dimensions, and spacing.<br><br><b>PCF (Portable Compiled Format)</b> is a binary format designed for efficient storage and fast loading by X servers. It compiles the bitmap data and properties from BDF into an optimized structure, making it the preferred format for X Window System font distribution.


title: INTEGRATION WITH X WINDOW SYSTEM FONTS
content:
For PCF fonts to be used by an X server, they typically need to be placed in a directory configured in the server's font path. After conversion with <i>bdftopcf</i>, tools like <b>mkfontdir</b> are used to create the <i>fonts.dir</i> index file in the font directory. The X server (or a font server like <b>xfs</b>) reads these index files to locate and load the available PCF fonts for display by applications.


title: HISTORY
content:
<i>bdftopcf</i> has been a fundamental utility within the X Window System font distribution for decades, originating from the XFree86 project and now maintained by the X.Org Foundation. Its development has focused on reliably converting the human-readable BDF format into the efficient, binary PCF format for optimal use by X servers. While its central role in font management has diminished with the rise of scalable font technologies and libraries like Fontconfig and FreeType, it continues to serve as the standard tool for incorporating fixed-size bitmap fonts into the X environment, particularly for older applications or specific display requirements.


title: SYNOPSIS
content:
<b>bdftruncate</b> [ <i>-t</i> | <i>-u</i> ] [ <i>-s</i> | <i>-c</i> ] [ <i>-f</i> <i>font_file</i> ] [ <i>-o</i> <i>output_file</i> ]


title: PARAMETERS
content:
<b><i>-t</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Truncate unused Unicode encoding ranges. When specified, only Unicode ranges that contain actual characters in the font are kept. This is mutually exclusive with <i>-u</i>.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not truncate unused Unicode encoding ranges. All possible Unicode ranges are kept. This is the default behavior and mutually exclusive with <i>-t</i>.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Unicode encoding ranges for a subset font. This means the output font will only declare ranges for characters that are present in the font. This is mutually exclusive with <i>-c</i>.<br><br><b><i>-c</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Unicode encoding ranges for a full font. This means the output font will declare all possible Unicode encoding ranges, even if characters are not present in all parts of the range. This is the default behavior and mutually exclusive with <i>-s</i>.<br><br><b><i>-f</i> <i>font_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input BDF font file. If this option is omitted, <b>bdftruncate</b> reads from standard input.<br><br><b><i>-o</i> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output BDF font file. If this option is omitted, <b>bdftruncate</b> writes to standard output.<br><br>


title: DESCRIPTION
content:
The <b>bdftruncate</b> command is a utility designed for modifying Bitmap Distribution Format (BDF) font files, specifically concerning their Unicode encoding ranges. Its primary purpose is to either truncate unused Unicode encoding ranges or to generate specific ranges for font subsets. This is particularly useful for handling large CJK (Chinese, Japanese, Korean) fonts, where a full Unicode range might be excessively large. By truncating or defining specific ranges, <b>bdftruncate</b> helps in creating smaller, more efficient font files or subsets that contain only the necessary characters. It reads BDF font data from an input file (or standard input) and writes the processed data to an output file (or standard output). This tool is a component of the X.Org font utilities, playing a role in the broader ecosystem of font management and rendering on Unix-like systems, often preceding conversion to other formats like PCF using <b>bdftopcf</b>.


title: CAVEATS
content:
This command specifically modifies the internal Unicode encoding directives within BDF font files, not the actual glyph data. Improper use can lead to malformed font metadata, which might cause issues with character mapping or font rendering in applications. It is a specialized tool within the X.Org font utility ecosystem, primarily for managing font metadata rather than graphical content.


title: HISTORY
content:
<b>bdftruncate</b> is a component of the X.Org project's font utilities, which are essential for managing and optimizing fonts within the X Window System environment. Its development stems from the need to efficiently handle large character sets, particularly those found in CJK (Chinese, Japanese, Korean) fonts, by allowing for the precise control and truncation of Unicode encoding ranges. This utility contributes to the broader goal of providing robust font management tools for developers and system administrators on Unix-like operating systems.


title: PARAMETERS
content:
<b><b>-b</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory for the binlog. If specified, <i>beanstalkd</i> will write all jobs to disk for persistence. Jobs are loaded from this directory on startup. Without this option, data is in-memory only.<br><br><b><b>-f</b> <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the fsync period. The binlog is fsync'd every <i>N</i> seconds. A value of 0 disables fsync (use with caution as it increases data loss risk on crashes). Default is 0.<br><br><b><b>-l</b> <i>ADDR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the address to listen on. This can be an IP address (e.g., 127.0.0.1) or 0.0.0.0 to listen on all available network interfaces. Default is 0.0.0.0.<br><br><b><b>-p</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the TCP port to listen on. The default port is 11300.<br><br><b><b>-u</b> <i>USER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drop privileges and run as the specified <i>USER</i> and its primary group after binding to the port. Recommended for security.<br><br><b><b>-z</b> <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum job size in bytes. Jobs larger than this limit will be rejected. Default is 65535 bytes (64KB).<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version string of <i>beanstalkd</i> and exit.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a help message with available command-line options and exit.<br><br>


title: DESCRIPTION
content:
<i>beanstalkd</i> is a lightweight, high-performance, in-memory work queue designed for fast, low-latency, and persistent job processing. It serves as a reliable backbone for handling asynchronous tasks in various applications, particularly web services.<br><br>It allows applications to quickly offload time-consuming operations (e.g., sending emails, processing images, generating reports) to background workers, thereby keeping the main application responsive. Jobs can be prioritized, delayed, and are handled with a robust lifecycle (put, reserve, delete, release, bury, kick) to ensure successful processing and recovery from failures. <i>beanstalkd</i> communicates via a simple, text-based protocol, making it easy to integrate with almost any programming language.


title: CAVEATS
content:
By default, <i>beanstalkd</i> runs purely in memory; all data will be lost if the daemon is stopped or crashes. To ensure persistence, the <b>-b</b> (binlog directory) option must be used.<br><i>beanstalkd</i> itself is a single-server solution; it does not offer built-in clustering, replication, or high-availability features. For redundancy, external mechanisms (e.g., shared storage, active-passive setups with failover) are required.<br>While efficient, it's not designed for extremely high-throughput, guaranteed-delivery scenarios that complex message brokers like Apache Kafka or RabbitMQ address, but rather for its simplicity and speed in typical web application use cases.


title: JOB LIFECYCLE AND PROTOCOL
content:
<i>beanstalkd</i> operates using a simple, text-based protocol over TCP. The core job lifecycle involves several commands:<br><b>PUT</b>: Client creates a new job.<br><b>RESERVE</b>: Worker fetches a job, making it invisible to other workers for a timeout duration.<br><b>DELETE</b>: Worker successfully processes and deletes the job.<br><b>RELEASE</b>: Worker fails to process the job and returns it to the ready queue, potentially with a delay.<br><b>BURY</b>: Worker fails, moves the job to a 'buried' state, making it inaccessible until explicitly 'kicked'.<br><b>TOUCH</b>: Worker signals it's still processing a job, extending its timeout to prevent it from being released.<br><b>KICK</b>: Returns buried or delayed jobs to the ready queue, making them available for processing.


title: TUBES
content:
Jobs are organized into 'tubes'. Tubes are independent queues that allow for logical separation of different types of jobs (e.g., 'email-sending', 'image-processing', 'report-generation'). Clients can 'put' jobs into specific tubes, and workers can 'watch' one or more tubes, enabling flexible routing and processing of jobs by different worker types.


title: HISTORY
content:
<i>beanstalkd</i> was originally developed by <i>Chris Dickinson</i> and <i>Phil Jacob</i> at <i>Percona</i> in 2008 as a lightweight, persistent work queue for their internal needs. Its design emphasizes speed and simplicity, aiming to be a 'fast, simple, work queue'. It quickly gained popularity within the Ruby on Rails and PHP communities for handling background jobs due to its ease of use and small footprint, offering a more streamlined alternative to larger message brokers for many common use cases. It has since become a mature and widely adopted open-source project, maintained by a community of contributors.


title: SEE ALSO
content:
<b>supervisord</b>(1) - A process control system, often used to manage <i>beanstalkd</i> daemon as a background service., <b>systemctl</b>(1) - The control utility for the systemd system and service manager, used for managing <i>beanstalkd</i> as a service., <b>netstat</b>(8) - A command-line network utility for displaying network connections, routing tables, interface statistics, etc., useful for verifying <i>beanstalkd</i>'s listening port., <b>ss</b>(8) - Another utility to investigate sockets, similar to <i>netstat</i> but often faster.


title: SYNOPSIS
content:
<b>bear</b> [<i>options</i>] -- <i>&lt;build command&gt;</i> [<i>&lt;build command arguments&gt;</i>]


title: PARAMETERS
content:
<b>-o <i>&lt;file&gt;</i>, --output <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output path for the <i>compile_commands.json</i> file.<br><br><b>-a, --append</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends new commands to an existing <i>compile_commands.json</i> file instead of overwriting it.<br><br><b>-i <i>&lt;method&gt;</i>, --interception <i>&lt;method&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the interception method: '<b>preload</b>' (default) or '<b>ptrace</b>'.<br><br><b>-f <i>&lt;file&gt;</i>, --config <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a configuration file to load options from.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>bear</b>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with available options.<br><br>


title: DESCRIPTION
content:
<b>bear</b> is a command-line tool designed to generate a <i>compile_commands.json</i> database. This file is crucial for tools like <b>clangd</b> (a language server for C/C++/Objective-C) and other static analysis tools to understand the compilation flags and include paths used during a project's build process. Without this information, these tools cannot provide accurate code completion, navigation, refactoring, and diagnostic capabilities.<br><br><b>bear</b> works by intercepting the <b>execve</b> system calls made by your build system (e.g., <b>make</b>, <b>ninja</b>, <b>cmake --build</b>). It records the compiler invocations (compiler path, source files, include paths, defines, etc.) and writes them into the <i>compile_commands.json</i> file in the build directory. It supports different interception methods, including <b>LD_PRELOAD</b> (the default and generally preferred method) and <b>ptrace</b>. The <b>LD_PRELOAD</b> method is faster and less intrusive, while <b>ptrace</b> can be used when <b>LD_PRELOAD</b> is not an option or for debugging purposes. <b>bear</b> is widely used in modern C++ development workflows to enhance developer productivity with intelligent IDE features.


title: CAVEATS
content:
Requires a functional build system executing compiler commands; it won't capture commands from generator-only builds (e.g., bare <b>cmake</b>). The default <b>LD_PRELOAD</b> interception method may not work in restricted environments; <b>ptrace</b> might require elevated privileges. For a complete database, a clean build (e.g., <b>make clean && bear -- make</b>) is often recommended, as incremental builds may miss commands for already compiled files.


title: THE <I>COMPILE_COMMANDS.JSON</I> FORMAT
content:
The output file, <i>compile_commands.json</i>, is a JSON array of command objects. Each object represents a single compilation command and contains fields like <b>directory</b> (the current working directory of the compilation), <b>command</b> (the complete command-line invocation), and <b>file</b> (the primary source file being compiled). This standardized format allows various development tools to consistently understand build parameters.


title: INTEGRATION WITH <I>CLANGD</I> AND IDES
content:
<i>bear</i> is most commonly used in conjunction with <i>clangd</i>, the Clang C/C++/Objective-C language server. By placing the generated <i>compile_commands.json</i> file in the project's root directory or build directory, <i>clangd</i> can automatically pick it up. This enables powerful IDE features such as accurate code completion, intelligent refactoring, semantic highlighting, and precise diagnostics directly within editors like VS Code, Neovim, and Emacs, significantly enhancing developer experience.


title: HISTORY
content:
<b>bear</b> was developed to address the need for a robust and reliable way to generate <i>compile_commands.json</i> files, especially as language servers like <b>clangd</b> gained popularity. Before <b>bear</b>, users often relied on tools like <b>cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON</b> (which works only for CMake projects) or manual parsing/scripting, which were less general or error-prone. <b>bear</b> provided a generic solution by observing system calls, making it compatible with virtually any build system that invokes standard compilers. Its development focused on stability, performance, and compatibility across various Linux distributions. It has become a de-facto standard tool in the C/C++ ecosystem for integrating build systems with modern IDE features.


title: SYNOPSIS
content:
<b>beef</b> [<i>options</i>]<br><br>The <b>beef</b> command typically launches the BeEF Browser Exploitation Framework. Without options, it attempts to start the framework with default configurations, including the web server and the administration user interface. Options are used to customize its behavior, such as specifying network bindings, database actions, or debug modes.


title: PARAMETERS
content:
<b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output for troubleshooting and development.<br><br><b>--reset-db</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the BeEF database, deleting all hooked browsers and configurations. Use with caution as this action is irreversible.<br><br><b>--no-ui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the BeEF framework without launching the graphical web user interface.<br><br><b>--admin-user &lt;user&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom username for the BeEF administration interface.<br><br><b>--admin-pass &lt;pass&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom password for the BeEF administration interface.<br><br><b>--port &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number for the BeEF web server (default is 3000 for the UI).<br><br><b>--host &lt;host&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the host address to bind the BeEF web server to (default is 0.0.0.0, binding to all interfaces).<br><br><b>--dir &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the working directory for BeEF configuration files and modules.<br><br><b>--config &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default.<br><br><b>--skip-install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the initial installation and dependency checks during startup.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output messages during execution.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the BeEF framework version information and exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and available command-line options.<br><br>


title: DESCRIPTION
content:
BeEF (Browser Exploitation Framework) is a professional open-source penetration testing tool that focuses on the web browser. Unlike other security frameworks that target network or system vulnerabilities, BeEF targets the client-side attack surface. It utilizes a variety of attack vectors to hook vulnerable browsers, allowing an attacker to launch command modules against the hooked browser. BeEF's primary focus is leveraging <i>Cross-Site Scripting (XSS)</i> vulnerabilities to gain control over a user's browser, turning it into a proxy for further attacks. It provides a comprehensive command-and-control interface, enabling testers to execute client-side attacks, perform social engineering, and gather information from the hooked browsers. It's widely used by ethical hackers and security researchers to demonstrate the risks associated with browser-based vulnerabilities.


title: CAVEATS
content:
The <b>beef</b> command, as part of the BeEF framework, is a powerful tool designed for penetration testing and educational purposes. <br><b>Misuse of this tool against systems or individuals without explicit prior consent is illegal and unethical.</b> <br>Users are solely responsible for their actions and must ensure they comply with all applicable laws and regulations. <br>Running BeEF may require specific system dependencies (e.g., Ruby, specific gems) which need to be installed beforehand. <br>The framework primarily targets client-side vulnerabilities, especially XSS, and its effectiveness depends on the presence of such vulnerabilities.


title: TARGET FOCUS
content:
BeEF fundamentally shifts the focus of penetration testing from server-side infrastructure to the client-side browser. <br>It exploits the trust users place in web applications to compromise their browsing session, enabling a wide range of post-exploitation activities directly from the browser.


title: HOOKING MECHANISM
content:
The core functionality of BeEF relies on 'hooking' a browser. <br>This is typically achieved by injecting a JavaScript hook into a vulnerable web page (e.g., via XSS). <br>Once hooked, the browser maintains a persistent connection to the BeEF control panel, allowing the tester to execute command modules and gather information silently.


title: HISTORY
content:
BeEF, an acronym for <i>Browser Exploitation Framework</i>, originated as an open-source project aimed at demonstrating the severe security implications of client-side web vulnerabilities, particularly <i>Cross-Site Scripting (XSS)</i>. <br>It was initially developed by a team of security researchers, with early versions emerging around 2006-2007. <br>Its development gained momentum as web applications became more complex and browser vulnerabilities became a significant attack vector. <br>BeEF quickly established itself as a go-to tool in the penetration testing community for its unique focus on the browser as a target. <br>It has seen continuous updates and improvements, adapting to new browser technologies and evolving attack techniques, solidifying its position as a leading client-side exploitation framework.


title: PARAMETERS
content:
<b><b>-c</b> <i>FILE</i>, <b>--config</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file to use for <i>BeEF</i>, overriding the default <i>config.yaml</i>.<br><br><b><b>-p</b> <i>PORT</i>, <b>--port</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the listen port for the <i>BeEF</i> web interface and API, overriding the value set in the configuration file.<br><br><b><b>-i</b> <i>INTERFACE</i>, <b>--interface</b> <i>INTERFACE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface for <i>BeEF</i> to bind to for incoming connections.<br><br><b><b>-x</b>, <b>--no-browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>BeEF</i> from automatically launching the web user interface in a browser upon startup.<br><br><b><b>-q</b>, <b>--no-logfile</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the creation of a log file during <i>BeEF</i> operation.<br><br><b><b>-e</b>, <b>--auto-migrate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically runs database migrations on startup, ensuring the database schema is up-to-date.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>BeEF</i> version information and then exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message for the <i>beef-xss</i> command and then exits.<br><br>


title: DESCRIPTION
content:
<i>BeEF-XSS</i>, which stands for <b>B</b>rowser <b>E</b>xploitation <b>F</b>ramework, is an open-source penetration testing tool that uniquely focuses on the client-side attack surface. Unlike traditional network-based exploitation tools, <i>BeEF</i> targets vulnerabilities within web browsers themselves to gain control over them. It operates by injecting JavaScript 'hooks' into vulnerable web pages. Once a browser is 'hooked', <i>BeEF</i> provides security professionals with a powerful platform to launch a variety of command modules against it.<br><br>These modules enable tasks ranging from simple information gathering, such as retrieving browser and system details, to more advanced attacks like social engineering, phishing, port scanning from the client's internal network, and exploiting local vulnerabilities via the compromised browser. <i>BeEF-XSS</i> is an invaluable asset for ethical hackers and red teams to assess the security posture of web applications, client-side defenses, and user susceptibility to browser-based attacks. Its primary application is in authorized security audits to demonstrate the profound risks associated with Cross-Site Scripting (XSS) and other client-side vulnerabilities.


title: CAVEATS
content:
<i>BeEF-XSS</i> is a highly potent tool intended exclusively for authorized penetration testing and ethical hacking. Its use without explicit, written permission from the owner of the target system or network is illegal and unethical, potentially leading to severe legal consequences. The effectiveness of <i>BeEF</i> modules can vary significantly based on the target browser's type, version, installed plugins, and the user's security settings. Continuous updates are often necessary to maintain efficacy against rapidly evolving browser security features and patched vulnerabilities.


title: CORE FUNCTIONALITY: HOOKING AND MODULES
content:
At its essence, <i>BeEF</i> operates by 'hooking' web browsers. This process involves tricking a target browser into loading a small JavaScript file, known as the hook, which is hosted on the <i>BeEF</i> server. Once successfully hooked, the browser establishes and maintains a persistent connection to the <i>BeEF</i> control panel. From this intuitive web-based interface, security testers can browse and execute a diverse array of pre-built modules directly against the hooked browser, enabling everything from simple reconnaissance to complex network and social engineering attacks.


title: WEB USER INTERFACE (UI)
content:
The primary interaction with <i>BeEF-XSS</i> occurs through its user-friendly web-based interface, which is typically accessible via a web browser at <i>http://127.0.0.1:3000/ui/panel</i> by default. This UI provides a centralized dashboard for managing and monitoring hooked browsers, categorizing them by their online or offline status. It facilitates the execution of modules, management of social engineering campaigns, logging of events, and configuration of various framework settings, making it the central hub for all <i>BeEF</i> operations.


title: CONFIGURATION FILE
content:
While <i>beef-xss</i> can be started with command-line options, its persistent and extensive settings are primarily managed through a YAML-formatted configuration file, commonly named <i>config.yaml</i> and located within the <i>BeEF</i> installation directory. This crucial file dictates various operational parameters such as the default listening port, network interface, authentication credentials for the UI, database settings, and numerous module-specific configurations. Modifying this file is essential for tailoring <i>BeEF</i> to specific testing environments and customizing its behavior.


title: HISTORY
content:
<i>BeEF</i> originated as a pioneering research project aimed at shedding light on the often-underestimated client-side attack surface. It was developed to demonstrate the significant security risks posed by browser-based vulnerabilities, particularly Cross-Site Scripting (XSS). Over time, it evolved into a comprehensive, open-source framework, rapidly gaining adoption within the cybersecurity community. Its integration into popular penetration testing distributions like Kali Linux significantly expanded its accessibility and widespread usage among security professionals for ethical hacking and red teaming exercises. Development remains active, with ongoing contributions focused on adding new modules and improving evasion techniques.


title: PARAMETERS
content:
<b><b>-f</b>, <b>--frequency</b> <i>&lt;Hz&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the frequency of the beep in Hertz (Hz). Default is 440 Hz (A4 note).<br><br><b><b>-l</b>, <b>--length</b> <i>&lt;ms&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the duration of the beep in milliseconds (ms). Default is 100 ms.<br><br><b><b>-r</b>, <b>--repetitions</b> <i>&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines how many times the beep should repeat. Default is 1.<br><br><b><b>-d</b>, <b>--delay</b> <i>&lt;ms&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the delay in milliseconds (ms) between repetitions of the beep. Default is 100 ms.<br><br><b><b>-n</b>, <b>--no-beep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the beep from sounding, only printing the calculated parameters to standard output. Useful for testing scripts.<br><br><b><b>-s</b>, <b>--stdin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads parameters from standard input, allowing complex sequences of beeps to be piped to the command.<br><br><b><b>-c</b>, <b>--continuous</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables continuous beep mode, ignoring length and delay parameters until interrupted by a signal.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the execution and parameters.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>beep</b> command allows users to generate audible signals through the computer's internal PC speaker. Unlike modern audio playback utilities that rely on sound cards and complex audio drivers, <b>beep</b> directly interacts with the rudimentary PC speaker, producing simple square wave tones. It's often used in shell scripts for basic notifications or alerts in environments where a graphical user interface is not present or desired, such as servers or embedded systems. Users can control the frequency, duration, number of repetitions, and delays between beeps, offering a surprising degree of customization for such a basic output device. Despite its simplicity, <b>beep</b> remains a useful tool for system administrators and scripters needing a straightforward, audible cue without external dependencies on complex audio setups.<br><br>Historically, the PC speaker was the only built-in audio output on many early computers, making <b>beep</b> a standard way to provide auditory feedback. While less common on modern laptops and desktops that often lack a physical PC speaker or have it disabled, its functionality persists via kernel modules like `pcspkr` that emulate or provide access to this legacy hardware.


title: CAVEATS
content:
The <b>beep</b> command relies on the presence and accessibility of a PC speaker. Many modern computers, especially laptops, do not have a physical PC speaker installed, or it might be disabled in the BIOS. Furthermore, <b>beep</b> typically requires access to specific kernel modules (like `pcspkr`) and device files (e.g., `/dev/console` or `/dev/input/by-path/platform-pcspkr-event`), which may necessitate root privileges or specific `udev` rules for non-root users. The sound quality is rudimentary (a simple square wave) and not suitable for complex audio playback.


title: KERNEL MODULE AND PERMISSIONS
content:
For <b>beep</b> to function, the `pcspkr` kernel module must typically be loaded. You can check its status with `lsmod | grep pcspkr`. If it's not loaded, you might need `sudo modprobe pcspkr`. Permissions can also be an issue; ensure the user has write access to the relevant device file (often `/dev/console` or an event device under `/dev/input`). On some systems, `sudo beep` might be required due to these access restrictions.


title: DISABLING THE PC SPEAKER
content:
If unwanted beeps occur, you can often disable the PC speaker. This can be done in your system's BIOS settings or by blacklisting the `pcspkr` kernel module. To blacklist, create or edit a file like `/etc/modprobe.d/blacklist.conf` and add `blacklist pcspkr`.


title: HISTORY
content:
The <b>beep</b> command's lineage traces back to early Unix and DOS systems, where the internal PC speaker was often the sole audio output device. It provided a simple, universal mechanism for system alerts and user feedback. Its design reflects the minimalist approach common in command-line utilities: direct interaction with hardware for a specific, straightforward task. As graphical user interfaces and advanced sound cards became standard, <b>beep</b>'s prominence waned, but it has maintained its niche for system administration, scripting, and accessibility in console-only environments. Modern implementations often rely on the Linux kernel's `pcspkr` module, which virtualizes or accesses the speaker device, allowing compatibility even on systems where direct hardware access is restricted or managed differently.


title: SYNOPSIS
content:
<b>behat</b> [<i>options</i>] [<i>paths</i>]<br>Examples:<br><b>behat</b><br><b>behat</b> <i>features/user_registration.feature</i><br><b>behat</b> <i>--strict --format progress</i>


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Behat version.<br><br><b><b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes the command to fail if undefined or ambiguous steps are encountered.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command without actually executing step definitions, useful for seeing proposed output.<br><br><b><b>--format</b> <<i>format</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., <I>pretty</I>, <I>progress</I>, <I>json</I>).<br><br><b><b>--profile</b> <<i>name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs Behat with a specific configuration profile defined in <I>behat.yml</I>.<br><br><b><b>--init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a basic Behat directory structure (<i>features/</i> and <i>behat.yml</i>).<br><br><b><b>[paths]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional paths to feature files or directories to run (e.g., <i>features/user_auth.feature</i> or <i>features/</i>).<br><br>


title: DESCRIPTION
content:
<b>Behat</b> is a PHP framework for <I>Behavior-Driven Development (BDD)</I>, inspired by <I>Cucumber</I>. It allows developers and business stakeholders to collaboratively define software behavior in human-readable language, known as <I>Gherkin</I> syntax. These specifications are written in plain text <I>.feature</I> files, describing scenarios with Given/When/Then steps. <br><br><b>Behat</b> translates these scenarios into executable tests by mapping <I>Gherkin</I> steps to PHP code, called <I>step definitions</I>. This approach promotes clear communication, ensures that the software meets user expectations, and serves as living documentation. It is commonly used for acceptance testing and end-to-end testing of PHP applications.


title: CAVEATS
content:
<b>Behat</b> is not a standard, pre-installed Linux utility. It is a PHP-based framework typically installed within a PHP project using <I>Composer</I>. Therefore, it requires a functioning PHP environment and the <I>Composer</I> dependency manager to be available on the system. Its execution is usually project-specific, relying on configuration files like <I>behat.yml</I> and the presence of <I>.feature</I> files.


title: CONFIGURATION
content:
<b>Behat</b>'s behavior is highly configurable via the <I>behat.yml</I> (or <I>behat.yml.dist</I>) file located at the project root. This file specifies paths to features, step definitions, formatters, and profiles.


title: FEATURE FILES
content:
Scenarios are written in <I>Gherkin</I> syntax within <I>.feature</I> files, typically located in a <I>features/</I> directory. Each file describes a specific feature with one or more scenarios.


title: STEP DEFINITIONS
content:
The logic that connects <I>Gherkin</I> steps to actual PHP code is contained in <I>step definitions</I>. These are PHP methods, often within context classes, that execute actions or assert states based on the scenario steps.


title: HISTORY
content:
The concept of <I>Behavior-Driven Development (BDD)</I> emerged from <I>Test-Driven Development (TDD)</I> and Agile methodologies, emphasizing collaboration between developers, QA, and business analysts. The <I>Gherkin</I> language, used by <b>Behat</b>, was popularized by the <I>Cucumber</I> framework (originally in Ruby). <b>Behat</b> was created by <I>Konstantin Kudryashov</I> as a PHP implementation of BDD, bringing these powerful practices to the PHP ecosystem. It has evolved significantly since its initial release, becoming a widely adopted tool for acceptance testing in PHP.


title: SYNOPSIS
content:
<B>berks</B> <I>command</I> [<I>options</I>]<br><br>Common commands include:<br>  <B>berks install</B> - Installs cookbook dependencies.<br>  <B>berks upload</B> - Uploads cookbooks to a Chef Infra Server.<br>  <B>berks package</B> - Packages cookbooks into a tarball.<br>  <B>berks vendor</B> - Vendors cookbooks to a specific directory.<br>  <B>berks update</B> - Updates cookbook dependencies.<br>  <B>berks outdated</B> - Lists outdated cookbook dependencies.


title: PARAMETERS
content:
<b>-b, --berksfile <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative path to the Berksfile.<br><br><b>-e, --except <GROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude cookbooks belonging to a specified group from the operation.<br><br><b>-o, --only <GROUP></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include only cookbooks belonging to a specified group for the operation.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, e.g., overwrite existing files or upload unconditionally.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug logging output for more verbose information.<br><br><b>-c, --config <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative path to the Berkshelf configuration file.<br><br><b>--path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'install' or 'vendor' commands, specify the target directory for cookbooks.<br><br><b>--no-sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'install' command, prevent syncing cookbooks to the vendor directory.<br><br>


title: DESCRIPTION
content:
Berkshelf, commonly invoked as <B>berks</B>, is a powerful dependency management tool designed specifically for Chef cookbooks. It allows developers to declare, resolve, and install cookbook dependencies by reading a <I>Berksfile</I>. Similar in concept to tools like Bundler for Ruby gems or npm for Node.js packages, <B>berks</B> ensures that all required cookbooks and their specified versions are available for a Chef-client run, local development, or testing environment.<br><br>It fetches cookbooks from various sources, including the Chef Supermarket, Git repositories, or local paths, and stores them in a local cache for offline use. This systematic approach simplifies the entire Chef cookbook development lifecycle, providing a consistent and reproducible method for managing complex inter-cookbook dependencies, thus enhancing collaboration and deployment reliability.


title: CAVEATS
content:
Berkshelf requires a Ruby environment with RubyGems installed. While still widely used, newer Chef Infra Client versions (12.18+) offer <I>Policyfiles</I> as an alternative, built-in dependency management system, which can simplify some workflows. Network connectivity is typically required to fetch external cookbook dependencies from sources like Chef Supermarket or Git repositories.


title: BERKSFILE
content:
The primary configuration file for <B>berks</B>. It is a Ruby DSL file that declares the required cookbooks, their versions, and their sources (e.g., Supermarket, Git, path). It's analogous to a <I>Gemfile</I> in Bundler or <I>package.json</I> in Node.js.


title: CHEF SUPERMARKET
content:
The default public repository for Chef cookbooks. <B>berks</B> primarily resolves cookbook dependencies by fetching them from the Chef Supermarket unless other sources are explicitly defined in the <I>Berksfile</I>.


title: HISTORY
content:
Berkshelf was developed by Jamie Winsor as a crucial tool to address the challenge of managing dependencies within the Chef ecosystem. Before its advent, managing cookbook dependencies was often manual and error-prone, relying on techniques like Git submodules or simple copying. <B>berks</B> introduced a declarative approach via the <I>Berksfile</I>, making dependency resolution and installation consistent and reproducible. Its creation significantly streamlined Chef cookbook development and deployment. While it remains a fundamental tool, its development has seen some shift since the introduction of <I>Policyfiles</I> in later Chef Infra Client versions, which offer an alternative, integrated dependency management approach.


title: PARAMETERS
content:
<b>-b <bssid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target a specific <i>BSSID</i> (AP MAC address).<br><br><b>-a <station></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target a specific station <i>MAC</i> address.<br><br><b>-c <channel></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lock on a specific <i>channel</i>.<br><br><b>-E <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write <i>EAPOL</i> (WPA handshakes) and <i>IVs</i> (WEP) to the specified <i>pcap file</i>.<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a random <i>MAC</i> address for the interface.<br><br><b>-W</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target <i>WPA</i> networks only, ignore <i>WEP</i> networks.<br><br><b>-K</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Kill any existing <i>WEP</i> cracking process (useful when focusing on WPA).<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt <i>WEP</i> cracking. Only capture <i>IVs</i> and <i>WPA</i> handshakes.<br><br><b>-p <power></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the power level in <i>dBm</i> (requires card support).<br><br><b>-s <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for <i>seconds</i> on each <i>AP</i> before moving to the next (default: 5 seconds).<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable quiet output.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message.<br><br>


title: DESCRIPTION
content:
<b>besside-ng</b> is a powerful tool within the <b>Aircrack-ng</b> suite designed for automated wireless network security auditing, specifically for <b>WEP</b> and <b>WPA/WPA2 PSK</b> networks. It works by passively sniffing wireless traffic, collecting initialization vectors (<i>IVs</i>) for <b>WEP</b> cracking, and <b>WPA/WPA2</b> 4-way handshakes. Its primary advantage is its automation; once started, it attempts to capture data from all reachable access points and associated clients, saving collected handshakes and <i>IVs</i>.<br><br>For <b>WEP</b>, it can automatically crack the key once enough <i>IVs</i> are gathered. For <b>WPA/WPA2</b>, it captures handshakes which can then be cracked offline using tools like <b>aircrack-ng</b> with a wordlist. It's often referred to as a "set it and forget it" tool due to its autonomous operation and focus on efficiency by prioritizing active networks.


title: CAVEATS
content:
Requires a wireless adapter capable of <i>monitor mode</i> and <i>packet injection</i>. Legal implications: Using <b>besside-ng</b> on networks you do not own or have explicit permission to test is illegal in most jurisdictions. Performance depends on network activity: <b>WEP</b> cracking relies on <i>IVs</i>, <b>WPA</b> on handshakes; both require active traffic or client associations. <b>WEP</b> cracking can be slow or impossible on inactive networks. <b>WPA</b> cracking requires a dictionary attack on the captured handshake, which can be computationally intensive and may not succeed without a strong wordlist. May be detected by network intrusion detection systems.


title: PREREQUISITES
content:
A wireless adapter that supports <i>monitor mode</i> and <i>packet injection</i> is essential. Before running <b>besside-ng</b>, the wireless interface typically needs to be put into monitor mode using <b>airmon-ng</b> (e.g., <code>airmon-ng start wlan0</code>).


title: OUTPUT FILES
content:
<b>besside-ng</b> often creates output files (e.g., <code>besside.cap</code> by default or specified by <code>-E</code>) containing captured <i>IVs</i> and <i>WPA</i> handshakes. These <i>pcap</i> files are crucial for offline cracking with <b>aircrack-ng</b> using a dictionary or brute-force attack.


title: TARGETING BEHAVIOR
content:
While <b>besside-ng</b> can operate broadly across all visible networks, it can also be directed to specific <i>BSSIDs</i> or <i>channels</i> for focused attacks. Without specific targeting, it will cycle through channels and target all discovered compatible access points.


title: HISTORY
content:
<b>besside-ng</b> is part of the <i>Aircrack-ng</i> suite, a comprehensive set of tools for auditing wireless networks. It emerged as a more automated and user-friendly alternative for <b>WEP</b> and <b>WPA/WPA2</b> cracking compared to running individual tools like <b>airodump-ng</b> and <b>aireplay-ng</b> manually. Its design aims to simplify the process of capturing necessary data (<i>IVs</i> for <b>WEP</b>, <i>EAPOL</i> handshakes for <b>WPA</b>) by passively monitoring and interacting with networks, making it a "set it and forget it" solution. Its development has focused on improving efficiency and automation within the <i>Aircrack-ng</i> project.


title: SEE ALSO
content:
airmon-ng(8), aircrack-ng(1), airodump-ng(1), aireplay-ng(1), airbase-ng(1), iwconfig(8), ifconfig(8), ip(8)


title: SYNOPSIS
content:
<b>bettercap</b> [<i>options</i>]<br><br>Common Usage Examples:<br><b>sudo bettercap -iface <i><interface></i></b><br><b>sudo bettercap -caplet <i><file.cap></i></b><br><b>sudo bettercap -eval "<i><command>; <command></i>"</b>


title: PARAMETERS
content:
<b>-iface <i><interface></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to use (e.g., <i>eth0</i>, <i>wlan0</i>).<br><br><b>-caplet <i><file.cap></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load and execute a caplet script file on startup.<br><br><b>-eval "<i><commands></i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute one or more commands directly on startup, separated by semicolons.<br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose debugging output for diagnostics.<br><br><b>-no-colors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output in the console.<br><br><b>-no-session</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not save the session data to disk (useful for ephemeral operations).<br><br><b>-gateway</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically detect and use the network gateway for spoofing/proxying.<br><br><b>-target <i><IP/range></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify one or more target IP addresses or CIDR ranges (e.g., <i>192.168.1.10</i>, <i>192.168.1.0/24</i>).<br><br><b>-http.addr <i><IP:port></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the address and port for the built-in HTTP/HTTPS web UI server (default: <i>127.0.0.1:8081</i>).<br><br><b>-proxy.port <i><port></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the port for the HTTP/HTTPS proxy module (default: <i>8080</i>).<br><br><b>-arp.spoof <i><true|false></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable ARP spoofing (default: <i>false</i>). Required for MITM attacks.<br><br><b>-dns.spoof <i><true|false></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable DNS spoofing (default: <i>false</i>).<br><br><b>-mac.changer.interface <i><iface></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an interface to automatically change its MAC address upon startup.<br><br><b>-wifi.recon <i><true|false></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable WiFi reconnaissance mode for discovering nearby networks and clients.<br><br><b>-wifi.deauth <i><true|false></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable WiFi deauthentication attacks (default: <i>false</i>).<br><br>


title: DESCRIPTION
content:
<b>bettercap</b> is a powerful, modular, and portable framework designed for various network-related tasks, including <i>man-in-the-middle (MITM) attacks</i>, network discovery, host reconnaissance, and WiFi auditing. It offers a comprehensive set of capabilities such as ARP spoofing, DNS spoofing, HTTP/HTTPS proxying, packet sniffing, credential harvesting, and WiFi deauthentication attacks. <br><br>Developed with modern security challenges in mind, bettercap aims to be easily extensible through <i>modules</i> and <i>caplets</i> (scriptable attack flows). It provides a powerful interactive console and a built-in web UI for ease of use, making it an essential tool for penetration testers, security researchers, and anyone involved in network security assessments. Its modular design allows users to combine different functionalities to create complex attack scenarios, while its portability ensures it can run on various operating systems, including Linux, macOS, and Windows.


title: CAVEATS
content:
<b>bettercap</b> requires <i>root privileges</i> (sudo) for most of its functionalities, especially for network manipulation, raw packet operations, and interface management. <br><br>Due to its powerful capabilities, it can be used for malicious purposes. Always ensure you have <i>explicit permission</i> and are operating within legal and ethical boundaries before using it on any network or system you do not own or manage. Improper or irresponsible use can lead to network instability, data loss, or severe legal consequences. It is primarily a penetration testing and security research tool; use it responsibly.


title: INTERACTIVE CONSOLE
content:
<b>bettercap</b> provides a powerful interactive console environment where users can dynamically load and unload modules, set parameters, start and stop attacks, and view real-time logs and statistics. This allows for flexible and on-the-fly adjustments to the attack strategy, making it highly adaptable during live engagements.


title: CAPLETS
content:
<i>Caplets</i> are executable scripts, written in a JavaScript-like syntax, that allow users to automate complex sequences of commands and module configurations. They enable the creation of custom attack workflows and provide a high degree of extensibility, simplifying repetitive tasks or intricate attack scenarios. Caplets enhance the framework's versatility, allowing for rapid deployment of sophisticated attacks.


title: WEB USER INTERFACE (WEB UI)
content:
A built-in web UI provides a graphical interface to control and monitor <b>bettercap</b>. This offers a more visual and intuitive way to manage network attacks, view discovered hosts, inspect captured data, and configure various modules without relying solely on the command-line console. The web UI enhances usability, especially for those who prefer a visual dashboard for network security operations.


title: HISTORY
content:
<b>bettercap</b> was originally developed by Simone Margaritelli (evilsocket). Its initial versions, released around 2016, were written in <i>Ruby</i> and aimed to be a more modern and interactive alternative to tools like <b>ettercap</b>. However, to address performance limitations, improve portability, and enhance its overall architecture, the project underwent a significant rewrite in <i>Go</i>, starting with version 2.x. This rewrite transformed it into a more robust, faster, and cross-platform tool, solidifying its position as a leading open-source network attack framework. Development is active, with continuous updates and new features being added by its maintainers and community.


title: SYNOPSIS
content:
<b>betterdiscordctl</b> <I>command</I> [<I>options</I>]<br><br>Common Commands:<br> <I>install</I><br> <I>uninstall</I><br> <I>rebuild</I><br> <I>info</I><br> <I>version</I>


title: PARAMETERS
content:
<b><I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary action to be performed by <b>betterdiscordctl</b>.<br><br><b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Patches the Discord client to integrate BetterDiscord. Requires specifying a Discord flavor or path.<br><br><b>uninstall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all BetterDiscord patches and associated files from the Discord client.<br><br><b>rebuild</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reapplies BetterDiscord patches to the Discord client. This is often necessary after a Discord client update, which can revert modifications and break BetterDiscord functionality.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about the detected Discord clients and their BetterDiscord installation status.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the <b>betterdiscordctl</b> utility itself.<br><br><b>--flavor <stable|canary|development></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target Discord client flavor (e.g., <I>stable</I>, <I>canary</I>, or <I>development</I>) for the command to operate on.<br><br><b>--path <path/to/discord/directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a custom path to the Discord installation directory. Useful if <b>betterdiscordctl</b> cannot automatically locate your Discord client.<br><br>


title: DESCRIPTION
content:
BetterDiscord is a popular client modification for Discord that allows users to customize their experience with themes, plugins, and custom CSS. The <b>betterdiscordctl</b> command is a dedicated Linux utility designed to simplify the installation, uninstallation, and management of BetterDiscord on various Discord client flavors (stable, canary, development). It automates the complex process of patching Discord's Electron application files, which would otherwise require manual intervention and specific knowledge of the client's internal structure. By providing a command-line interface, <b>betterdiscordctl</b> ensures a consistent and user-friendly way for Linux users to integrate BetterDiscord, offering functionalities like re-patching after Discord updates (which often break modifications) and providing status information about the BetterDiscord installation.


