# CommandSection

title: CAVEATS
content:
Aliases created with <I>glab-alias</I> are specific to the <I>glab</I> CLI and are not recognized by the system shell (e.g., bash, zsh) directly. When using the <I>--shell</I> flag, ensure the aliased command is valid and accessible within the shell environment where <I>glab</I> is executed. Aliases are stored in the user's <I>glab</I> configuration file, typically located at <I>~/.config/glab-cli/config.yml</I>.


title: ALIAS STORAGE
content:
All defined <I>glab</I> aliases are persisted in the <I>glab</I> configuration file, typically found at <I>~/.config/glab-cli/config.yml</I> under the <I>aliases</I> section. This allows aliases to persist across shell sessions and system reboots, ensuring a consistent CLI experience.


title: ALIAS PRECEDENCE
content:
When an alias is defined, it takes precedence over built-in <I>glab</I> commands with the same name. For example, if you create an alias named <I>glab mr</I> that points to <I>glab merge request create</I>, typing <I>glab mr</I> will execute your alias instead of the standard <I>glab merge request</I> command group.


title: HISTORY
content:
<I>glab</I>, the GitLab CLI, was first publicly released around 2020. The alias management feature (<I>glab-alias</I>) was included early in its development lifecycle, recognizing the importance of user customization and efficiency for a command-line tool. It has since been a stable and integral part of the <I>glab</I> experience, evolving with the CLI's capabilities to offer robust alias definition and management.


title: SYNOPSIS
content:
<b>glab auth</b> <I>command</I> [flags]<br><br><b>Available Commands:</b><br>&nbsp;&nbsp;<b>login</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Log in to GitLab<br>&nbsp;&nbsp;<b>logout</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Log out of GitLab<br>&nbsp;&nbsp;<b>status</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;View authentication status<br>&nbsp;&nbsp;<b>refresh</b>&nbsp;&nbsp;&nbsp;&nbsp;Refresh stored authentication token<br>&nbsp;&nbsp;<b>git-credential</b> Use glab as a Git credential helper


title: PARAMETERS
content:
<b>--hostname <hostname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab instance hostname to authenticate against or manage credentials for. Defaults to gitlab.com.<br><br><b>--web</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a web browser for interactive OAuth authentication (primarily used with <b>login</b>).<br><br><b>--token <token></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a GitLab Personal Access Token (PAT) directly for non-interactive login (used with <b>login</b>).<br><br><b>--scopes <scope1,scope2,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the OAuth scopes or token permissions required for the authentication session (used with <b>login</b>). Common scopes include <I>api</I>, <I>sudo</I>, <I>read_repository</I>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help for the command or subcommand.<br><br>


title: DESCRIPTION
content:
The <b>glab auth</b> command is a crucial component of the <I>glab</I> command-line interface, the official CLI for GitLab. It provides a comprehensive set of tools for managing user authentication with GitLab instances. This includes logging in using various methods (interactive web flow, personal access tokens), logging out, checking the current authentication status, and refreshing existing tokens.<br><br>It simplifies interaction with GitLab APIs for developers, administrators, and CI/CD pipelines by securely storing and managing authentication credentials. The <b>glab auth</b> subcommands streamline common authentication tasks, eliminating the need to manually handle tokens or browser-based logins for every operation, thus enhancing productivity and scripting capabilities.


title: CAVEATS
content:
Authentication tokens, especially Personal Access Tokens (PATs), grant significant access to your GitLab account. Ensure they are handled securely and their scopes are limited to the minimum necessary permissions to prevent unauthorized access.<br><br>The <b>--web</b> authentication method requires a functional web browser and network connectivity to the specified GitLab instance for the OAuth flow to complete successfully.<br><br><b>glab auth</b> primarily manages credentials stored by <I>glab</I> itself; it does not directly manage SSH keys or other system-wide Git authentication methods unless configured as a Git credential helper.


title: AUTHENTICATION METHODS
content:
<b>glab auth</b> supports multiple ways to authenticate with your GitLab instance:<br><ul><li><b>Web Flow (OAuth):</b> This is the recommended interactive method, opening a browser to complete the authentication process securely using GitLab's OAuth 2.0.</li><li><b>Personal Access Token (PAT):</b> Allows direct login using a pre-generated PAT, suitable for scripting, CI/CD environments, or when a web browser is unavailable.</li><li><b>Git Credential Helper:</b> The <b>glab auth git-credential</b> subcommand integrates <I>glab</I> with Git's credential helper mechanism. This enables Git commands (like <I>git push</I> or <I>git pull</I>) to automatically use your <I>glab</I>-managed GitLab credentials without requiring separate authentication for Git operations.</li></ul>


title: CONFIGURATION STORAGE
content:
Authentication tokens and configuration settings for <I>glab</I> are typically stored in a YAML file, commonly located at <I>~/.config/glab-cli/config.yml</I> or <I>~/.config/glab/config.yml</I>, depending on the version and installation. This file securely stores hostnames, tokens, and other preferences for quick access by <I>glab</I> commands, ensuring persistence across sessions.


title: HISTORY
content:
The <b>glab</b> CLI, including its <b>auth</b> subcommand, is an official open-source project developed and maintained by GitLab Inc. It was created to provide a native, efficient, and user-friendly command-line experience for interacting with GitLab. The <b>auth</b> functionality has been a core part of <I>glab</I> since its early releases, continually evolving to support modern authentication flows like OAuth and integrating seamlessly with Git's credential helper mechanism to enhance the developer workflow and simplify CI/CD scripting.


title: SYNOPSIS
content:
<b>glab issue</b> <I>command</I> [<I>flags</I>]<br><br>Common commands include:<br>  <b>create</b><I> [flags]</I>      Create a new issue<br>  <b>list</b><I> [flags]</I>        List issues<br>  <b>view</b><I> [<id>]</I>         View an issue<br>  <b>close</b><I> [<id>]</I>        Close an issue<br>  <b>reopen</b><I> [<id>]</I>       Reopen an issue<br>  <b>update</b><I> [<id>]</I>       Update an issue properties


title: PARAMETERS
content:
<b><b>-R, --repo</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab repository to operate on (e.g., <i>owner/repo</i> or a local path).<br><br><b><b>-p, --project</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <b>--repo</b>.<br><br><b><b>--web</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the issue (or list of issues) in the default web browser after an action.<br><br><b><b>-t, --title</b> <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used with <b>create</b>, <b>update</b>)</i> Sets the title of the issue.<br><br><b><b>-d, --description</b> <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used with <b>create</b>, <b>update</b>)</i> Sets the description or body of the issue.<br><br><b><b>-l, --label</b> <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used with <b>create</b>, <b>update</b>, <b>list</b>)</i> Add, remove, or filter issues by comma-separated labels.<br><br><b><b>-a, --assignee</b> <I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used with <b>create</b>, <b>update</b>, <b>list</b>)</i> Assign the issue to a user or filter by assignee's username.<br><br><b><b>-s, --state</b> <I>state</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used with <b>list</b>)</i> Filter issues by state: 'opened' or 'closed'.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for <b>glab issue</b> or its specific subcommands.<br><br>


title: DESCRIPTION
content:
The <b>glab issue</b> command is a powerful subcommand of <b>glab</b>, the official GitLab command-line interface. It allows users to interact with GitLab's issue tracking system directly from their terminal, eliminating the need to switch to a web browser for common tasks. <br><br>With <b>glab issue</b>, developers and project managers can seamlessly perform actions such as creating new issues, listing existing ones, viewing detailed information for specific issues, closing, reopening, updating, and adding notes. This integration streamlines workflows, enabling users to manage their development tasks and collaborate on projects efficiently within their command-line environment. It leverages the GitLab API to provide a native and intuitive experience.


title: CAVEATS
content:
<b>glab issue</b> requires <b>glab</b> to be installed and properly configured with a GitLab personal access token or OAuth token. This token must have sufficient scopes (e.g., <i>api</i> or specific <i>read_api</i>/<i>write_repository</i> scopes) to perform the desired operations. Operations are subject to GitLab API rate limits, which can affect very heavy automated usage. Ensure you are authenticated to the correct GitLab instance and have permissions for the target project.


title: AUTHENTICATION
content:
Before using <b>glab issue</b>, you must authenticate <b>glab</b> with your GitLab instance. This is typically done via the <b>glab auth login</b> command, which guides you through setting up a personal access token or OAuth authentication.


title: COMMON USE CASES
content:
<b>glab issue</b> is ideal for developers who prefer to stay within the command line: <br> - Quickly creating issues for bugs or new features identified during coding. <br> - Listing assigned issues to prioritize daily work. <br> - Updating issue statuses, adding comments, or reassigning without context switching to a web browser. <br> - Scripting issue creation or updates for automation in CI/CD pipelines or local development workflows.


title: HISTORY
content:
<b>glab</b>, the official GitLab CLI, emerged from a community-driven effort to provide a native command-line experience for GitLab users, similar to GitHub's 'gh' CLI. The <b>issue</b> subcommand has been a fundamental component since its early development, addressing the critical need for efficient issue management without leaving the terminal. Its evolution reflects the growing demand for robust, integrated command-line tools in modern developer workflows, aiming to replicate and enhance common web UI functionalities through the GitLab API.


title: SYNOPSIS
content:
<b>glab mr</b> <i>&lt;command&gt;</i> [<i>flags</i>]<br><br>Common commands include:<br>  <b>glab mr create</b> [<i>branch</i>] [<i>flags</i>]<br>  <b>glab mr list</b> [<i>flags</i>]<br>  <b>glab mr view</b> <i>&lt;id&gt;</i> [<i>flags</i>]<br>  <b>glab mr merge</b> <i>&lt;id&gt;</i> [<i>flags</i>]<br>  <b>glab mr close</b> <i>&lt;id&gt;</i> [<i>flags</i>]


title: PARAMETERS
content:
<b><i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific operation to perform on a merge request. Common commands include <b>create</b>, <b>list</b>, <b>view</b>, <b>merge</b>, <b>close</b>, <b>approve</b>, <b>diff</b>, <b>rebase</b>, and <b>checkout</b>.<br><br><b>create [<i>branch</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new merge request. If <i>branch</i> is not specified, it typically defaults to the current branch.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists merge requests based on various filters (e.g., state, assignee, author).<br><br><b>view <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Views detailed information about a specific merge request identified by its <i>&lt;id&gt;</i> (IID or URL).<br><br><b>merge <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merges a specified merge request.<br><br><b>close <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes a specified merge request.<br><br><b>approve <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Approves a specified merge request.<br><br><b>diff <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the diff of a specified merge request.<br><br><b>rebase <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebases a specified merge request onto its target branch.<br><br><b>checkout <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks out the source branch of a specified merge request locally.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help for <b>glab mr</b> or any of its subcommands.<br><br><b>--repo <i>&lt;repository&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab repository (e.g., <i>owner/repo_name</i>) to operate on, overriding the default detected from the current Git directory.<br><br><b>--hostname <i>&lt;hostname&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab instance hostname to use, overriding the default or configured hostname.<br><br>


title: DESCRIPTION
content:
<i>glab mr</i> is a powerful subcommand of <b>glab</b>, the official GitLab Command Line Interface. It provides a comprehensive set of functionalities to interact with GitLab Merge Requests directly from your terminal. Users can <b>create</b>, <b>list</b>, <b>view</b>, <b>merge</b>, <b>close</b>, <b>approve</b>, and perform various other operations on merge requests without needing to access the GitLab web interface.<br><br>This command-line tool streamlines development workflows, especially for developers who prefer working in a terminal environment. It leverages the GitLab API to communicate with your GitLab instance, requiring proper authentication, typically via a Personal Access Token or OAuth.


title: CAVEATS
content:
Using <b>glab mr</b> requires a properly configured <b>glab</b> CLI installation. This includes setting up authentication, typically via a GitLab Personal Access Token with appropriate scopes, or OAuth.<br><br>Commands rely on network connectivity to the GitLab instance. Permissions on the GitLab project are respected, so users can only perform actions they are authorized for in the web interface.


title: AUTHENTICATION
content:
<b>glab mr</b> commands authenticate using a GitLab Personal Access Token or OAuth. This token can be configured via <b>glab auth login</b>, an environment variable (e.g., <i>GITLAB_TOKEN</i>), or in the <b>glab</b> configuration file (typically <i>~/.config/glab-cli/config.yml</i>).


title: DEFAULT REPOSITORY
content:
By default, <b>glab mr</b> operates on the GitLab repository associated with the current Git working directory's remote. If no remote points to a GitLab instance, or if operating outside a Git repository, the <b>--repo</b> flag must be used to specify the target project.


title: HISTORY
content:
<b>glab</b> was developed to provide a native command-line interface for GitLab, similar to how <b>gh</b> serves GitHub. The <b>glab mr</b> subcommand is a core component, offering comprehensive merge request management directly from the terminal. It has been continuously developed and maintained by the GitLab community and open-source contributors, evolving with new GitLab features and user demands.


title: SYNOPSIS
content:
<I>glab mr create</I> [<I>source-branch</I>] [<I>target-branch</I>] [<I>flags</I>]<br><I>glab mr create</I> <I>--title</I> <I>"MR Title"</I> [<I>flags</I>]


title: PARAMETERS
content:
<b>--title, -t <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the title of the merge request. This is often a required field.<br><br><b>--description, -d <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a detailed description for the merge request. Can accept Markdown.<br><br><b>--assignee, -a <usernames|IDs></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assign one or more users to the merge request by username or ID.<br><br><b>--reviewer, -r <usernames|IDs></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Request review from one or more users.<br><br><b>--label, -l <labels></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attach one or more labels to the merge request, comma-separated.<br><br><b>--milestone, -m <milestone-title|ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associate the merge request with a specific milestone.<br><br><b>--target-branch, -b <branch-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target branch for the merge request. Defaults to the project's default branch.<br><br><b>--source-branch, -s <branch-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the source branch for the merge request. Defaults to the current Git branch.<br><br><b>--remove-source-branch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically remove the source branch upon merge.<br><br><b>--squash-before-merge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable squash commits when merging the merge request.<br><br><b>--draft, --wip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create the merge request as a draft (work in progress).<br><br><b>--allow-collaboration</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow commits from members who can merge to the target branch.<br><br><b>--web</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the newly created merge request in the default web browser.<br><br><b>--push, -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Push current branch to remote before creating merge request.<br><br><b>--fill</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fill MR fields (title, description) from Git commit message, if not provided.<br><br><b>--yes, -y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Confirm creation without prompting for confirmation.<br><br><b>--output-format, -o <json|text|yaml></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set output format for the merge request details after creation.<br><br><b>--project <project-ID|path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab project (ID or path) to operate on.<br><br>


title: DESCRIPTION
content:
The <b>glab mr create</b> command provides a powerful and convenient way to initiate new merge requests directly from your command-line interface. It eliminates the need to navigate to the GitLab web UI, streamlining the development workflow, especially for developers who prefer staying in the terminal. This command intelligently infers the source and target branches if not explicitly specified, often defaulting to your current branch as the source and the project's default branch (e.g., 'main' or 'master') as the target. Users can specify a title, description, assignees, reviewers, labels, milestones, and more, all via command-line flags. It supports various options for pre-populating information, opening the merge request in a web browser, or even pushing changes to the remote repository before creation. This tool is an essential part of the <I>glab</I> CLI, enhancing productivity for GitLab users.


title: CAVEATS
content:
Requires prior authentication with GitLab via <I>glab auth login</I>. <br>The command must be run within a Git repository that is linked to a GitLab project. <br>Permissions are inherited from your GitLab user account; you must have sufficient permissions to create merge requests in the target project. <br>If a title or description is not provided, <I>glab</I> might prompt you or try to infer from Git commit messages, depending on flags like <I>--fill</I>.


title: CONFIGURATION
content:
<I>glab</I> respects environment variables like <I>GITLAB_TOKEN</I> and configuration files (e.g., <I>~/.config/glab-cli/config.yml</I>) for project defaults, host, and authentication.


title: INTERACTIVE MODE
content:
When required fields like title or description are not provided via flags, <I>glab</I> can enter an interactive mode, prompting the user for input. This behavior can be controlled by options like <I>--yes</I> or <I>--fill</I>.


title: HISTORY
content:
<I>glab</I> is the official GitLab command-line tool, developed by GitLab Inc. and the open-source community. It was designed to bring the GitLab experience closer to the developer's terminal, similar to GitHub's <I>gh</I> CLI. The <I>glab mr create</I> command is a core functionality, present since early versions of <I>glab</I>, reflecting the importance of merge requests in the GitLab workflow. Its continuous development focuses on improving user experience, adding more options, and aligning with new GitLab features.


title: SYNOPSIS
content:
<I>glab pipeline</I> &lt;<I>command</I>&gt; [<I>flags</I>]<br><br>Common commands:<br><I>glab pipeline ci</I> [<I>flags</I>]<br><I>glab pipeline list</I> [<I>flags</I>]<br><I>glab pipeline view</I> &lt;<I>pipeline-id</I>&gt; [<I>flags</I>]<br><I>glab pipeline retry</I> &lt;<I>pipeline-id</I>&gt; [<I>flags</I>]<br><I>glab pipeline cancel</I> &lt;<I>pipeline-id</I>&gt; [<I>flags</I>]<br><I>glab pipeline delete</I> &lt;<I>pipeline-id</I>&gt; [<I>flags</I>]


title: PARAMETERS
content:
<b><I>ci</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trigger a custom CI job with specific variables and a Git ref (branch or tag).<br><br><b><I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all pipelines for a project, with options to filter by branch or status.<br><br><b><I>view <pipeline-id></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about a specific pipeline by its ID, including its jobs and their statuses.<br><br><b><I>retry <pipeline-id></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retry a previously failed or canceled pipeline by its ID.<br><br><b><I>cancel <pipeline-id></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cancel a currently running or pending pipeline by its ID.<br><br><b><I>delete <pipeline-id></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete a specific pipeline by its ID. This action is irreversible and should be used with caution.<br><br><b><I>-R, --repo <owner/repo></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab repository by its 'owner/repo' path. This overrides the repository inferred from the current working directory.<br><br><b><I>-P, --project <project-id></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab project by its numerical ID. This is useful when not in a Git repository or for ambiguous project names.<br><br><b><I>--host <hostname></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab host (e.g., <I>gitlab.com</I> or your self-hosted instance). This overrides any configured default host.<br><br><b><I>--token <token></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a GitLab personal access token or OAuth token directly for authentication. This overrides any token configured via <I>glab auth login</I>.<br><br><b><I>--all</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>list</I> command) List all pipelines, not just the default paginated number of results. Useful for comprehensive overviews.<br><br><b><I>--branch <branch-name></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>list</I> or <I>ci</I> command) Filter pipelines by a specific branch name, or specify the branch for a new CI job trigger.<br><br><b><I>--status <status></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>list</I> command) Filter pipelines by their current status, such as <I>success</I>, <I>failed</I>, <I>running</I>, <I>pending</I>, etc.<br><br><b><I>--ref <ref-name></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>ci</I> command) Specify a specific Git reference (branch name or tag) against which the CI job should be executed.<br><br><b><I>--variables <key=value,...></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <I>ci</I> command) Pass custom CI/CD variables as a comma-separated list of <I>key=value</I> pairs to the triggered pipeline.<br><br>


title: DESCRIPTION
content:
The <I>glab-pipeline</I> command is a powerful subcommand of the <I>glab</I> official GitLab CLI tool, designed to streamline interaction with GitLab's Continuous Integration/Continuous Delivery (CI/CD) pipelines directly from your terminal. It allows users to programmatically manage, monitor, and troubleshoot CI/CD workflows without needing to navigate the GitLab web interface. This command provides functionalities to list all pipelines for a project, view detailed information about a specific pipeline (including its jobs and status), retry failed or canceled pipelines, cancel running pipelines, and delete old or unnecessary pipelines. By integrating <I>glab-pipeline</I> into development workflows, scripts, or automation tools, developers and operations teams can significantly improve efficiency, enforce CI/CD best practices, and facilitate rapid iteration on software delivery. It leverages the GitLab API, offering a consistent and authenticated way to control your project's build and deployment processes.


title: CAVEATS
content:
Requires the <I>glab</I> CLI tool to be installed and accessible in your system's PATH. Proper authentication with GitLab is essential; <I>glab-pipeline</I> operates under the permissions of the authenticated user or token. Insufficient permissions will result in errors. Network connectivity to the specified GitLab host is required for all operations. While powerful for management, understanding complex CI/CD logic might still require reviewing the <I>.gitlab-ci.yml</I> configuration file or the GitLab web UI for full context.


title: AUTHENTICATION AND CONFIGURATION
content:
To use <I>glab-pipeline</I>, you must first authenticate with your GitLab instance. This is typically done via <I>glab auth login</I>, which guides you through setting up a Personal Access Token or OAuth. Once authenticated, <I>glab</I> stores your credentials, allowing subsequent commands to operate without manual authentication. You can also configure the default GitLab host and project.


title: PROJECT CONTEXT
content:
<I>glab-pipeline</I> commands usually infer the GitLab project from your current working directory (if it's a Git repository connected to GitLab). If not, or if you wish to target a different project, you must explicitly specify the project using the <I>--repo</I> or <I>--project</I> flags.


title: OUTPUT FORMATTING
content:
Many <I>glab pipeline</I> commands, especially <I>list</I> and <I>view</I>, support various output formats (e.g., JSON, YAML, or custom templates) using global <I>glab</I> flags like <I>--json</I>, <I>--yaml</I>, or <I>--template</I>. This feature is highly useful for scripting and integration with other automation tools.


title: HISTORY
content:
The <I>glab</I> CLI tool, including its <I>pipeline</I> subcommand, emerged as the official command-line interface for GitLab, inspired by the success of similar tools like GitHub's <I>gh</I> CLI. Its development aimed to provide a first-class, intuitive, and efficient way for developers and DevOps engineers to interact with GitLab from their terminal, reducing context switching and enabling advanced automation. The <I>pipeline</I> subcommand, in particular, was a critical addition, reflecting GitLab's strong emphasis on CI/CD as a core feature. Its evolution tracks GitLab's own CI/CD capabilities, offering programmatic control over a wide array of pipeline operations since its inception.


title: SEE ALSO
content:
<I>glab(1)</I>: The main GitLab CLI tool, of which `pipeline` is a subcommand., <I>git(1)</I>: The distributed version control system, fundamental to managing project repositories on GitLab., <I>curl(1)</I>: A command-line tool for transferring data with URLs, often used for direct GitLab API interaction when `glab` functionality is insufficient., <I>gitlab-ci.yml</I>: The configuration file for GitLab CI/CD pipelines, defining the jobs and stages managed by `glab pipeline` (conceptual relation, not a command).


title: SYNOPSIS
content:
`glab release <subcommand> [flags]`<br><br>Common Subcommands:<br><br><i>Create a new release:</i><br>`glab release create <tag_name> [flags]`<br><br><i>List all releases:</i><br>`glab release list [flags]`<br><br><i>View a specific release:</i><br>`glab release view <tag_name> [flags]`<br><br><i>Upload assets to an existing release:</i><br>`glab release upload <tag_name> <filepath> [flags]`<br><br><i>Delete a release:</i><br>`glab release delete <tag_name> [flags]`


title: PARAMETERS
content:
<b><subcommand></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the action to perform on releases, such as 'create', 'list', 'view', 'delete', or 'upload'.<br><br><b><tag_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required for 'create', 'view', 'delete', and 'upload' subcommands. It specifies the Git tag associated with the release.<br><br><b>-D, --description <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' subcommand)</i> Sets the description for the new release.<br><br><b>-F, --notes-file <filepath></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' subcommand)</i> Reads release notes from the specified file. Markdown supported.<br><br><b>--name <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' subcommand)</i> Provides a user-friendly name for the release.<br><br><b>-r, --ref <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' subcommand)</i> Specifies the Git reference (commit SHA, branch, or another tag) from which the release is created.<br><br><b>-a, --asset <filepath></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' or 'upload' subcommand)</i> Path to a release asset file to be attached. Can be used multiple times for multiple assets.<br><br><b>--asset-url <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'create' or 'upload' subcommand)</i> Specifies a URL for an external release asset. Only used when a single asset is specified.<br><br><b>--host <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default GitLab host (e.g., 'gitlab.com') for the operation.<br><br><b>--repo <group>/<repo> or <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative repository to operate on, if not the current directory's.<br><br>


title: DESCRIPTION
content:
The `glab release` command is a powerful subcommand of the official GitLab CLI (`glab`) designed to streamline the management of GitLab project releases. It provides a command-line interface to interact with the GitLab Releases API, enabling users to perform various operations directly from their terminal or within automated scripts. <br><br>With `glab release`, you can <b>create new releases</b>, associating them with specific Git tags and attaching release assets such as binaries or documentation. It also allows for <b>viewing details</b> of a particular release, <b>listing all releases</b> for a project, and <b>deleting</b> unwanted releases. Furthermore, it supports <b>uploading additional assets</b> to existing releases. This command significantly simplifies the release process, especially when integrated into CI/CD pipelines, by abstracting direct API calls and providing a user-friendly interface.


title: CAVEATS
content:
Operating with `glab release` requires an authenticated `glab` session, typically established via `glab auth login`. The user must have sufficient permissions within the GitLab project (usually <b>Developer role or higher</b>) to create, update, or delete releases. All release operations are fundamentally tied to <b>Git tags</b>, meaning a corresponding Git tag must exist or be created for a release to be managed. Asset handling, especially with multiple files or specific types, requires careful attention to the command flags.


title: INTEGRATION WITH GITLAB CI/CD
content:
`glab release` is frequently used within GitLab CI/CD pipelines to automate the release process. After building and testing artifacts, the CI/CD job can use `glab release create` to publish a new release, attach generated binaries as assets, and even automatically generate release notes from commit messages. This ensures consistent and automated release deployments.


title: KEY CONSIDERATIONS FOR ASSETS
content:
When attaching assets using `-a, --asset`, `glab` automatically infers asset name, type, and URL. For more control, especially when uploading a single asset, flags like `--asset-name`, `--asset-type`, and `--asset-url` can be used to specify these details explicitly. For multiple assets, `-a` can be provided multiple times.


title: HISTORY
content:
The `glab` CLI tool was developed by GitLab to provide a robust command-line interface for its platform. The `release` subcommand was introduced to offer direct terminal access to GitLab's powerful <b>Releases API</b>, which manages software releases and their associated assets. Its development mirrors the growing importance of structured release management and automation, particularly within <b>CI/CD pipelines</b>, allowing developers to manage releases efficiently without leaving the command line or relying solely on the web UI.


title: PARAMETERS
content:
<b><b>--header</b> <i>strings</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a header to the request. Can be used multiple times.<br><br><b><b>--host</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GitLab host. Defaults to 'gitlab.com'.<br><br><b><b>--no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable color output in the console.<br><br><b><b>--skip-prompt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip prompts and use default values or non-interactive mode.<br><br><b><b>--token</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Your GitLab access token. Overrides token from configuration.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose output, including HTTP requests and responses.<br><br>


title: DESCRIPTION
content:
The <b>glab repo</b> command acts as a comprehensive suite for managing GitLab repositories. It provides various subcommands to perform common repository operations directly from the command line, such as creating, cloning, listing, forking, archiving, deleting, and viewing projects. This eliminates the need to navigate the GitLab web interface for many daily tasks, streamlining developer workflows and enabling scripting. It leverages the GitLab API and requires authentication via a GitLab access token configured either through <b>glab auth login</b> or the <b>--token</b> flag, ensuring secure and direct interaction with your GitLab instance.


title: CAVEATS
content:
The <b>glab repo</b> command itself is a <i>command group</i> and cannot be executed without a subcommand (e.g., <b>glab repo create</b>).<br>Most operations require a valid GitLab access token with appropriate permissions for the actions being performed (e.g., 'maintainer' role for deletion).<br>Network connectivity to the specified GitLab host is essential for all operations.


title: AVAILABLE SUBCOMMANDS
content:
The <b>glab repo</b> group provides a rich set of subcommands for various repository operations:<br><br><b>archive</b>: Archive a repository<br><b>clone</b>: Clone a GitLab repository<br><b>create</b>: Create a new GitLab repository<br><b>delete</b>: Delete a GitLab repository<br><b>fork</b>: Fork a GitLab repository<br><b>list</b>: List GitLab repositories<br><b>mirror-create</b>: Create a new mirrored GitLab repository<br><b>mirror-update</b>: Update a mirrored GitLab repository<br><b>rename</b>: Rename a GitLab repository<br><b>search</b>: Search for a GitLab repository<br><b>transfer</b>: Transfer a GitLab repository<br><b>unarchive</b>: Unarchive a repository<br><b>view</b>: View a GitLab repository<br><br>Each subcommand has its own specific set of flags and arguments, which can be viewed using <b>glab repo <i>&lt;subcommand&gt;</i> --help</b>.


title: HISTORY
content:
<b>glab</b>, the GitLab CLI, emerged to provide a powerful command-line interface for interacting with GitLab. The <b>repo</b> command group has been a fundamental part of <b>glab</b> since its early development, offering core functionality for project management. Its evolution mirrors the active development of the GitLab platform, continually expanding its capabilities to cover more GitLab API features and improve the developer experience.


title: SYNOPSIS
content:
<b>glances</b> [<i>OPTIONS</i>]<br><b>glances</b> <b>-s</b> [<i>OPTIONS</i>] <i>(Server mode)</i><br><b>glances</b> <b>-c</b> <i>@client_ip</i> [<i>OPTIONS</i>] <i>(Client mode)</i><br><b>glances</b> <b>-w</b> [<i>OPTIONS</i>] <i>(Web server mode)</i>


title: PARAMETERS
content:
<b><b>-b</b>, <b>--byte</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays network I/O in bytes per second, rather than bits per second.<br><br><b><b>-c</b> <i><client></i>, <b>--client</b> <i><client></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects <i>Glances</i> to a remote <i>Glances</i> server. The client can be an IP address or a hostname.<br><br><b><b>-s</b>, <b>--server</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <i>Glances</i> in server mode, allowing other <i>Glances</i> instances to connect and retrieve system information.<br><br><b><b>-w</b>, <b>--webserver</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Glances</i> with a built-in web server, allowing monitoring through a web browser.<br><br><b><b>-p</b> <i><port></i>, <b>--port</b> <i><port></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the listening port for server, client, or web server modes. Default is 61209.<br><br><b><b>-t</b> <i><time></i>, <b>--time</b> <i><time></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the refresh time interval in seconds for updating the displayed information. Default is 2 seconds.<br><br><b><b>-1</b>, <b>--percpu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays CPU statistics for each individual core, rather than aggregated CPU usage.<br><br><b><b>-C</b> <i><file></i>, <b>--config</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to load instead of the default.<br><br><b><b>-P</b> <i><password></i>, <b>--password</b> <i><password></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a password for client/server mode to secure remote connections.<br><br><b><b>--disable-process</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the process monitoring module, useful for reducing resource usage or focusing on other metrics.<br><br><b><b>--export</b> <i><output></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports stats to a specified output destination, e.g., <i>influxdb</i>, <i>json</i>, <i>csv</i>, <i>prometheus</i>.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>Glances</i> version information and exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and exits.<br><br>


title: DESCRIPTION
content:
<i>Glances</i> is a free, open-source, cross-platform system monitoring tool written in Python. It provides a real-time, comprehensive overview of system resources through a curses-based terminal interface. The information displayed dynamically adapts to the terminal size, ensuring optimal readability.<br><br>It monitors key metrics such as CPU usage, memory consumption, load average, disk I/O, network activity, process lists, file systems, sensors, Docker containers, system uptime, and more. <i>Glances</i> supports various operational modes, including standalone, client/server for remote monitoring, and a built-in web interface. Additionally, it offers robust data export capabilities to external services like InfluxDB, Prometheus, Graphite, and can output data in formats like CSV and JSON.


title: CAVEATS
content:
<i>Glances</i> requires Python and the <i>psutil</i> library (and other optional libraries for specific features) to function. While comprehensive, its resource usage might be higher than lighter tools like <i>top</i> or <i>htop</i> due to its Python foundation and extensive feature set. When running in server or web server mode, it's crucial to implement proper security measures (e.g., firewalls, strong passwords) to prevent unauthorized access.


title: INTERACTIVE COMMANDS
content:
Within the <i>Glances</i> TUI, users can press various keys for interactive control. For example, '<i>m</i>' sorts processes by memory usage, '<i>p</i>' by CPU usage, '<i>d</i>' by disk I/O, '<i>f</i>' by filesystem usage, '<i>l</i>' toggles the process list, and '<i>q</i>' quits the application.


title: CONFIGURATION
content:
<i>Glances</i> is highly configurable through a configuration file, typically located at <i>/etc/glances/glances.conf</i> or <i>~/.config/glances/glances.conf</i>. This file allows users to customize thresholds for alerts, define modules to enable/disable, and set other preferences.


title: HISTORY
content:
<i>Glances</i> was created by Nicolas Hennion (nicolargo) and first released around 2011. It was developed to provide a more visually appealing and comprehensive system monitoring experience compared to traditional command-line tools. Leveraging Python and the <i>psutil</i> library, it achieved cross-platform compatibility from its early stages. Over the years, <i>Glances</i> has seen continuous development, expanding its feature set to include client/server modes, a web interface, and numerous data export options, establishing itself as a popular and versatile monitoring solution.


title: SYNOPSIS
content:
<b>gleam</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><b>gleam</b> <i>--version</i><br><b>gleam</b> <i>help</i> [<i>&lt;subcommand&gt;</i>]


title: PARAMETERS
content:
<b>new &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Gleam project with a default structure.<br><br><b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles the current Gleam project into executable artifacts.<br><br><b>run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the main entry point of the compiled Gleam project.<br><br><b>test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs all unit and integration tests defined in the project.<br><br><b>format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically reformats Gleam source code according to official guidelines.<br><br><b>add &lt;package&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new dependency to the project's configuration file.<br><br><b>remove &lt;package&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an existing dependency from the project.<br><br><b>deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages project dependencies, with subcommands like <i>download</i>, <i>clean</i>, and <i>list</i>.<br><br><b>shell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts an interactive Gleam shell (REPL) for experimentation.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes compiled artifacts, build outputs, and downloaded dependencies.<br><br><b>docs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates HTML documentation for the project's public API.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates project dependencies to their latest compatible versions.<br><br><b>publish</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes the current project as a package to a package registry.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed Gleam CLI version.<br><br><b>help [subcommand]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help message for the CLI or a specific subcommand.<br><br>


title: DESCRIPTION
content:
The <b>gleam</b> command-line interface (CLI) is the primary tool for developing applications using the Gleam programming language. It serves as a comprehensive build tool, package manager, and development utility. Developers use it to create new projects, compile source code, run tests, format code, manage dependencies, and interact with the Gleam ecosystem. Built to streamline the development workflow, <b>gleam</b> integrates seamlessly with Erlang's BEAM virtual machine and can also compile to JavaScript, offering versatility for various application types, from web services to frontend applications. It abstracts away many complexities of project setup and dependency management, allowing developers to focus on writing application logic in a type-safe and concurrent environment. Its subcommands provide fine-grained control over the development lifecycle, making it an indispensable part of the Gleam development experience.


title: CAVEATS
content:
The <b>gleam</b> command is specific to the Gleam programming language ecosystem. It is not a general-purpose Linux utility but rather a language-specific build tool. Its functionality is entirely dependent on having the Gleam compiler and runtime installed and configured correctly. It requires a Gleam project structure to operate effectively on project-specific tasks.


title: INSTALLATION
content:
Gleam CLI is typically installed via a language version manager like `asdf`, a system package manager like `Homebrew` on macOS, or by downloading pre-compiled binaries from the official Gleam website. It is generally not pre-installed on standard Linux distributions.


title: PROJECT STRUCTURE
content:
Gleam projects generally follow a standard directory structure. Key components include a `src/` directory for source code, a `test/` directory for tests, and a `gleam.toml` file for project configuration and dependency management.


title: HISTORY
content:
The <b>gleam</b> command-line tool is an integral part of the Gleam programming language, which was created by Louis Pilfold and first publicly released in 2019. Developed from the outset to be a developer-friendly experience, the <b>gleam</b> CLI was designed to provide a unified interface for all common development tasks. Its design principles emphasize ease of use, clear error messages, and a smooth workflow, contributing significantly to Gleam's growing adoption in the functional programming community, particularly for building robust, scalable applications on the Erlang BEAM virtual machine.


title: PARAMETERS
content:
<b>--targetdir=<I>DIRECTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where the compiled <I>gschemas.compiled</I> file should be placed. If not specified, the output is written to the first directory passed as an argument.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with an error if any warnings are encountered during compilation (e.g., malformed schemas).<br><br><b>--no-clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not remove temporary files created during the compilation process. Useful for debugging.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform all checks and validations but do not actually write any files to disk. Useful for testing.<br><br><b>--validate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only validate the schema files for correctness and well-formedness, without actually compiling them into a binary cache.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of the <b>glib-compile-schemas</b> utility.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message with available command-line options.<br><br>


title: DESCRIPTION
content:
The <b>glib-compile-schemas</b> command is a crucial utility within the <I>GLib</I> library, designed to optimize the performance of the <I>GSettings</I> configuration system.<br><br>GSettings uses XML schema files to define application settings, including their types, default values, and descriptions. While these XML files are human-readable and easy to manage, directly parsing them at runtime for every application could be inefficient. To address this, <b>glib-compile-schemas</b> takes one or more directories containing these XML schema files and compiles them into a single, compact, and efficient binary cache file named <I>gschemas.compiled</I>.<br><br>This compiled binary file allows GSettings to load and access schema information much faster, significantly improving application startup times and overall responsiveness when dealing with configurations. It is typically run during the installation of software packages that use GSettings, ensuring that the schemas are pre-compiled and ready for use by the system's applications.


title: CAVEATS
content:
For optimal performance, ensure <b>glib-compile-schemas</b> is run whenever new GSettings schema files are added or existing ones are updated in a system directory. <br><br>The command requires write permissions to the target directory. If run in a system-wide path like <I>/usr/share/glib-2.0/schemas/</I>, it typically needs root privileges or to be executed as part of a package manager's installation script.


title: TYPICAL USAGE CONTEXT
content:
This command is primarily invoked by package managers or build systems when installing or updating applications that use GSettings. End-users generally do not need to run it manually. After installing or updating an application with new GSettings schemas, the package manager often triggers a system-wide schema recompilation to ensure all applications have access to the latest configuration definitions. Common schema directories include <I>/usr/share/glib-2.0/schemas/</I> or application-specific <I>share/glib-20/schemas/</I> paths within their installation prefix.


title: SCHEMA FILE LOCATION
content:
GSettings schema files are typically found in the <I>share/glib-2.0/schemas/</I> subdirectory of an application's installation prefix. For system-wide schemas, this is often <I>/usr/share/glib-2.0/schemas/</I>. When <b>glib-compile-schemas</b> is run, it looks for <I>.gschema.xml</I> files in the specified directory and compiles them into a single <I>gschemas.compiled</I> file in the same or target directory. This compiled file is then used by GSettings applications to load configuration information.


title: HISTORY
content:
<b>glib-compile-schemas</b> is an integral part of the <I>GLib</I> library, which is a fundamental building block for <I>GTK+</I> and the <I>GNOME</I> desktop environment. Its development aligns with the evolution of <I>GSettings</I>, which superseded <I>GConf</I> as the preferred configuration system for modern <I>GNOME</I> applications and other software leveraging GLib.<br><br>The need for schema compilation arose to improve the efficiency of reading configuration data, moving from runtime XML parsing to a pre-compiled binary format. This shift was part of a broader effort to enhance application performance and consistency across the <I>Linux</I> desktop.


title: PARAMETERS
content:
<b>-s, --style <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the rendering style or theme to use (e.g., <i>dark</i>, <i>light</i>, <i>auto</i>, <i>dracula</i>).<br>Defaults to <i>auto</i> based on terminal background.<br><br><b>-p, --pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pipe the output through an external pager command, typically <i>less</i>, allowing scrolling for long documents.<br><br><b>-l, --local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Render local files only; ignore remote content, even if a URL is provided as an argument.<br><br><b>-w, --width <int></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific rendering width for the output, overriding auto-detection based on terminal size.<br><br><b>--hd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Render soft-wrapped text with 'hard breaks', treating each line as a distinct paragraph line rather than allowing soft line wrapping.<br><br><b>--show-local-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the local file path of the Markdown document being rendered above its content.<br><br><b>--copy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy the rendered Markdown content to the system clipboard instead of displaying it in the terminal.<br><br><b>--config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file path for <i>glow</i> settings.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information of <i>glow</i> and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a comprehensive help message with all available options and their usage.<br><br>


title: DESCRIPTION
content:
<i>glow</i> is a powerful and aesthetic command-line utility designed to render Markdown files directly within your terminal emulator. Developed by <b>Charm</b> (creators of many popular CLI tools like Bubble Tea and Gum), <i>glow</i> transforms raw Markdown text into a beautifully formatted, syntax-highlighted, and easily readable output. It supports local files, including automatic detection and rendering of <code>README.md</code> in the current directory or parent directories. Additionally, <i>glow</i> can fetch and display Markdown content from URLs, making it useful for reading GitHub <code>README</code>s or other online documentation without leaving the terminal. Its features include pagination for longer documents, customizable themes (styles), and the ability to linkify URLs. <i>glow</i> aims to enhance the terminal experience for developers and users who frequently interact with Markdown-formatted content.


title: CAVEATS
content:
<i>glow</i> is primarily a viewer and does not provide editing capabilities. Complex Markdown features, such as highly customized embedded HTML or certain diagram syntaxes, may not render perfectly or at all. Rendering remote URLs requires an active internet connection. The visual appearance is highly dependent on your terminal emulator's font and color scheme capabilities.


title: DEFAULT BEHAVIOR
content:
When <i>glow</i> is executed without any specific file or URL arguments in a directory, it automatically searches for and renders common Markdown files like <code>README.md</code>, <code>README.markdown</code>, etc., within the current directory or its parent directories.


title: CONFIGURATION
content:
<i>glow</i> supports a persistent configuration file, typically located at <code>~/.config/glow/glow.yml</code>. Users can define default rendering styles, preferred pager settings, and other customization options within this file, ensuring consistent behavior across sessions.


title: HISTORY
content:
<i>glow</i> was developed by <b>Charm</b>, a company renowned for creating elegant and robust open-source command-line tools, predominantly using the Go programming language. It was initially released around late 2019 / early 2020. It rapidly gained popularity among developers for its polished Markdown rendering capabilities and user-friendly interface, quickly becoming a go-to tool for viewing <code>README.md</code> files and other Markdown-formatted documentation directly in the terminal.


title: SYNOPSIS
content:
<I>gluster</I> <I>[global-options]</I> <I><subcommand></I> <I>[subcommand-options]</I> <I>[arguments]</I><br>
<br>
Common top-level subcommands include:<br>
<I>gluster peer</I> <I>...<br>
gluster volume</I> <I>...<br>
gluster system</I> <I>...<br>
gluster help</I> <I>[subcommand]</I><br>
<br>
Example:<br>
<I>gluster volume create my_volume replica 2 server1:/data/brick1 server2:/data/brick1 --force</I><br>
<I>gluster volume start my_volume</I>


title: PARAMETERS
content:
<b><I><subcommand></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the primary command to execute. Common subcommands include <I>peer</I> (for cluster node management), <I>volume</I> (for managing GlusterFS volumes), <I>system</I> (for system-level tasks), and <I>vfs</I> (for VFS operations).</I><br><br><b><I>[subcommand-options]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Options specific to the chosen <I>subcommand</I>. These vary widely depending on the subcommand's functionality.</I><br><br><b><I>[arguments]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Additional arguments required by the <I>subcommand</I> and its options, such as volume names, server hostnames, or brick paths.</I><br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enables verbose debugging output for the command execution.</I><br><br><b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Formats the command's output in JSON, useful for programmatic parsing.</I><br><br><b><I>--xml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Formats the command's output in XML, also useful for programmatic parsing.</I><br><br><b><I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays the <I>gluster</I> command's version information.</I><br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays usage information for the <I>gluster</I> command or a specific <I>subcommand</I>.</I><br><br>


title: DESCRIPTION
content:
The <I>gluster</I> command is the primary command-line interface (<I>CLI</I>) for managing <I>GlusterFS</I> deployments.<br>
<I>GlusterFS</I> is a free and open-source scalable network filesystem, often used for cloud storage and big data. It aggregates disparate storage servers into a single, large parallel network filesystem.<br>
The <I>gluster</I> command allows administrators to perform a wide range of tasks, including:<br>
<br>
<I>• Creating, starting, stopping, and deleting GlusterFS volumes.</I><br>
<I>• Managing storage server peers within a GlusterFS cluster.</I><br>
<I>• Adding or removing bricks (storage units) from volumes.</I><br>
<I>• Checking the status and health of the GlusterFS cluster and individual volumes.</I><br>
<I>• Performing maintenance operations like healing and rebalancing.</I><br>
<br>
It serves as the central control point for all GlusterFS administrative operations, making it an indispensable tool for anyone managing a GlusterFS environment.


title: CAVEATS
content:
<I>• <B>Root Privileges:</B> Most <I>gluster</I> commands require root privileges or <I>sudo</I> access to execute successfully, as they perform system-wide administrative tasks.<br>
• <B>Network Connectivity:</B> Proper network configuration and connectivity between all GlusterFS nodes are essential for the command to function correctly and for the cluster to operate.<br>
• <B>Stateful Operations:</B> Many operations modify the cluster's state. Care must be taken, especially with commands like <I>volume delete</I>, which are destructive.<br>
• <B>Output Consistency:</B> While <I>--json</I> and <I>--xml</I> aim for consistency, the human-readable output format might vary slightly across different <I>GlusterFS</I> versions and subcommands.</I>


title: <B>SUBCOMMAND-ORIENTED DESIGN</B>
content:
<I>The <I>gluster</I> command is designed around a subcommand model. Most operations are performed by invoking <I>gluster</I> followed by a specific subcommand (e.g., <I>volume</I>, <I>peer</I>, <I>system</I>), which then accepts its own set of options and arguments. This modular design helps organize the extensive functionality available.</I>


title: <B>PROGRAMMATIC OUTPUT</B>
content:
<I>For scripting and integration with other tools, the <I>gluster</I> command offers <I>--json</I> and <I>--xml</I> global options. These ensure a stable, machine-readable output format, making it easier to parse command results programmatically compared to the default human-readable text output.</I>


title: HISTORY
content:
<I>GlusterFS</I> was originally developed by <I>Gluster Inc.</I>, founded in 2005. The `gluster` command-line tool has been central to managing the filesystem since its early days.<br>
In 2011, <I>Red Hat</I> acquired Gluster Inc., leading to GlusterFS becoming a prominent open-source storage solution within the Red Hat ecosystem, particularly for products like <I>Red Hat Storage</I>.<br>
The `gluster` command has continuously evolved with the filesystem, incorporating new features, volume types, and management capabilities, solidifying its role as the primary administrative interface for <I>GlusterFS</I> clusters.<br>
Its development continues as part of the broader GlusterFS open-source project, with contributions from a global community.


title: SEE ALSO
content:
<I>mount(8)</I>, <I>fstab(5)</I>, <I>df(1)</I>, <I>ls(1)</I>, <I>firewalld(8)</I>, <I>iptables(8)</I>


title: SYNOPSIS
content:
<b>glxdemo</b><br><br>The <b>glxdemo</b> command usually does not take any specific command-line arguments and is simply executed to launch the demonstration window. It relies on the system's X Window configuration to determine the display and visual settings.


title: DESCRIPTION
content:
glxdemo is a utility program designed to provide a basic visual demonstration of <I>OpenGL</I> rendering capabilities within the <I>X Window System</I> using <I>GLX</I> (OpenGL Extension to the X Window System). When executed, it typically opens a new window and displays a simple, animated 3D scene, most commonly a rotating gear or a similar geometric object.<br><br>This serves as a quick and effective way to verify that your system's 3D graphics acceleration is functioning correctly and that the <I>GLX</I> drivers are properly installed and configured. It is frequently employed by system administrators, developers, and end-users as a diagnostic tool after driver installations, system updates, or when troubleshooting display issues.<br><br>While glxdemo is not a performance benchmark, it provides an immediate visual confirmation of basic 3D rendering pipeline integrity. It's a minimal example of an <I>OpenGL</I> application running on an <I>X</I> server, demonstrating the interaction between the application, <I>GLX</I>, and the underlying graphics hardware. The command is usually part of the <I>mesa-demos</I> package, which bundles various simple <I>OpenGL</I> demonstration programs.


title: CAVEATS
content:
The <b>glxdemo</b> command requires an active <b>X Window System</b> session and correctly installed <b>GLX</b> and <b>OpenGL</b> drivers to function. It will typically open a new window for the demonstration. Its successful execution only confirms basic 3D graphics functionality and is not a comprehensive benchmark for performance or advanced feature support. If the window appears blank, flickers, or an error message is displayed, it indicates a potential issue with your graphics driver installation or <b>X</b> server configuration.


title: PURPOSE OF DEMONSTRATION
content:
Unlike commands that provide textual output, <b>glxdemo</b> offers a visual demonstration. Its primary purpose is to confirm the presence and basic operation of <b>GLX</b> and <b>OpenGL</b> acceleration. A successful run, displaying the rotating object smoothly, signifies that the graphics stack from the application to the hardware is fundamentally working.


title: DEPENDENCIES
content:
<b>glxdemo</b> relies heavily on the <b>X Window System</b> to manage display and windowing, and on the underlying <b>GLX</b> and <b>OpenGL</b> libraries and drivers for 3D rendering. It will not work in a purely console environment without an <b>X</b> server.


title: HISTORY
content:
The <b>glxdemo</b> program is part of the <b>Mesa Demos</b> collection, which has a long history intertwined with the development of <b>OpenGL</b> and the <b>X Window System</b>. These demos were created to showcase and test the functionalities provided by the <b>Mesa 3D Graphics Library</b>, an open-source implementation of the <b>OpenGL</b> specification. While its exact origin date is not strictly documented, it has been a staple diagnostic and demonstration tool for many years, evolving with graphics driver technology. Its consistent role has been to provide a quick visual verification of <b>GLX</b> and <b>OpenGL</b> setup.


title: DESCRIPTION
content:
<i><b>glxgears</b></i> is a classic OpenGL demo program that displays three spinning gears in a window. It serves primarily as a basic visual test to confirm that a system's OpenGL and GLX (OpenGL Extension to the X Window System) rendering capabilities are functioning correctly. It's often used by Linux users to quickly verify that their graphics drivers are properly installed and that 3D acceleration is enabled.<br><br>While it provides a frames-per-second (FPS) counter, <i><b>glxgears</b></i> is <b>not</b> considered a reliable benchmark for modern GPU performance due to its simplicity and limited workload. Its main value lies in its role as a diagnostic tool for rudimentary 3D graphics setup. It is typically part of the <i>mesa-demos</i> or <i>mesa-utils</i> package.


title: CAVEATS
content:
<ul><li><b>Not a true benchmark:</b> The FPS reported by <i><b>glxgears</b></i> is often very high (thousands or tens of thousands) and does not reflect real-world gaming or demanding 3D application performance. It's a very simple scene with minimal computational load.</li><li><b>VSync influence:</b> The reported FPS can be capped by your monitor's refresh rate (VSync), making it appear lower than the GPU's actual capability, or it might run unlocked and show artificially high numbers.</li><li><b>Limited diagnostic depth:</b> It only confirms basic GLX/OpenGL functionality, not advanced features or specific driver optimizations.</li></ul>


title: PURPOSE BEYOND PERFORMANCE
content:
While often misinterpreted as a performance benchmark, <i><b>glxgears</b></i> is fundamentally a diagnostic tool. Its primary purpose is to confirm that the OpenGL rendering pipeline, from the application through GLX to the underlying graphics driver and hardware, is operational. A smoothly spinning set of gears indicates that the necessary components for 3D acceleration are present and configured correctly.


title: INSTALLATION
content:
On most Linux distributions, <i><b>glxgears</b></i> is included in a package typically named <i>mesa-demos</i> or <i>mesa-utils</i>. It can be installed using the system's package manager, e.g., <i><b>sudo apt install mesa-utils</b></i> on Debian/Ubuntu or <i><b>sudo dnf install mesa-demos</b></i> on Fedora.


title: HISTORY
content:
<i><b>glxgears</b></i> originated as part of the GLX (OpenGL Extension to the X Window System) distribution, which was initially developed by Silicon Graphics, Inc. (SGI) to bring OpenGL 3D rendering to the X Window System environment. It has been a staple utility in Unix-like operating systems with X11 for decades, particularly as part of the Mesa 3D Graphics Library project. Its consistent presence makes it a well-recognized, albeit simple, indicator of basic 3D acceleration functionality.


title: PARAMETERS
content:
<b>display_name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an X display to connect to and render on. This can be a display number like <I>:0</I>, a screen number like <I>:0.1</I>, or a full display specification like <I>localhost:0</I> or <I>remotehost:0</I>. If no <I>display_name</I> is provided, <I>glxheads</I> defaults to the display specified by the <I>DISPLAY</I> environment variable (e.g., <I>:0</I>).<br><br>


title: DESCRIPTION
content:
<I>glxheads</I> is a lightweight diagnostic utility from the Mesa 3D Graphics Library project, designed to verify basic OpenGL (GLX) rendering functionality across multiple X Window System displays or screens simultaneously. When invoked, it attempts to open an OpenGL rendering window on each specified X display, rendering a simple 3D animation (often a spinning gear or triangle). This tool is particularly useful for debugging multi-monitor setups, verifying GLX acceleration on remote X displays, or confirming that OpenGL contexts can be successfully created and rendered on different display outputs. It provides immediate visual feedback and outputs basic GLX version and renderer information for each display, aiding in the diagnosis of graphics driver and display configuration issues in complex environments.


title: CAVEATS
content:
<I>glxheads</I> is a very basic test; it doesn't stress the GPU extensively or test advanced OpenGL features. It primarily verifies GLX context creation and basic rendering. While useful for initial setup validation, it's not a comprehensive benchmark. It requires an X server with GLX support.


title: PURPOSE
content:
The primary purpose of <I>glxheads</I> is to test and confirm basic GLX (OpenGL Extension to the X Window System) functionality and multi-head display configurations. It ensures that OpenGL contexts can be successfully created and rendered across multiple X screens or displays simultaneously, providing visual confirmation and diagnostic output for each.


title: OUTPUT
content:
For each display it connects to, <I>glxheads</I> typically outputs diagnostic information including the GLX version, OpenGL vendor string, renderer string, and OpenGL version string. This information is crucial for verifying the active OpenGL driver and its capabilities on each specific display.


title: HISTORY
content:
<I>glxheads</I> is part of the <I>mesa-demos</I> (or <I>mesa-utils</I> on some distributions) package, which bundles various OpenGL demonstration and testing programs. It has been a long-standing utility in the Linux graphics ecosystem, providing a fundamental tool for developers and users to quickly ascertain GLX and multi-display functionality within the X Window System. Its core purpose and usage have remained consistent over time, serving as a reliable first-line diagnostic for OpenGL display issues.


title: PARAMETERS
content:
<b><b>-?</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays a brief help message explaining the command's usage and available options, then exits.</I><br><br><b><b>-o</b> <I>outfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the path to the output file where the converted <B>DOT</B> graph will be written. If this option is omitted, <B>gml2gv</B> will print the generated <B>DOT</B> output to standard output (<I>stdout</I>).</I><br><br><b><I>files...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>One or more paths to the input <B>GML</B> files that <B>gml2gv</B> should convert. If no input files are provided, the command will read <B>GML</B> data from standard input (<I>stdin</I>).</I><br><br>


title: DESCRIPTION
content:
<b>gml2gv</b> is a command-line utility within the <b>Graphviz</b> software package designed to translate graph descriptions from the <b>Graph Modeling Language (GML)</b> format into the <b>Graphviz DOT</b> language. This conversion is crucial for enabling <b>Graphviz</b> layout and rendering engines, such as <b>dot</b>, <b>neato</b>, or <b>fdp</b>, to process and visualize graphs originally defined in <b>GML</b>.<br><br>The tool reads <b>GML</b> graph data from specified input files or, by default, from standard input. It then converts this data into the <b>DOT</b> format, writing the output to a specified file or, by default, to standard output. <b>gml2gv</b> correctly handles both directed and undirected graphs, along with their nodes, edges, and a subset of their attributes. It intelligently maps relevant <b>GML</b> attributes to their <b>DOT</b> equivalents, providing a bridge between these two popular graph representation standards.


title: CAVEATS
content:
<b><I>Limited Attribute Support:</I></b> <I>gml2gv</I> only recognizes and processes a specific subset of <I>GML</I> attributes, including <I>label</I>, <I>color</I>, <I>fontcolor</I>, <I>fontsize</I>, <I>style</I>, <I>fillcolor</I>, <I>id</I>, <I>name</I>, and <I>weight</I>. While other <I>GML</I> attributes might be mapped to <I>GV</I> attributes with the same name, they are not guaranteed to be utilized or interpreted by <I>Graphviz</I> layout programs.<br><b><I>Ignored Graphics Attributes:</I></b> Attributes related to explicit graphical representation, such as <I>graphics</I>, <I>LabelGraphics</I>, <I>nodeGraphics</I>, <I>edgeGraphics</I>, and <I>GraphGraphics</I>, are intentionally ignored during the conversion process. This is because <I>Graphviz</I> is designed to handle layout and rendering automatically based on its own algorithms and styling.<br><b><I>GML Standard Variations:</I></b> The <I>GML</I> specification can be complex, and <I>gml2gv</I> may not support all possible syntax variations or extensions. Highly complex or non-standard <I>GML</I> files might result in incomplete or incorrect conversions.


title: INPUT/OUTPUT STREAMS
content:
<I>gml2gv</I> is designed for flexibility in shell pipelines. By default, it reads <I>GML</I> input from standard input (<I>stdin</I>) if no input files are specified. Similarly, if the <I>-o</I> option is not used, the converted <I>DOT</I> output is written to standard output (<I>stdout</I>). This behavior allows for easy chaining with other command-line tools.


title: GRAPH TYPE HANDLING
content:
The converter automatically determines whether the output <I>GV</I> graph should be directed or undirected. If the input <I>GML</I> file explicitly specifies an undirected graph, <I>gml2gv</I> generates an undirected <I>GV</I> graph accordingly. Otherwise, if not specified as undirected, a directed <I>GV</I> graph is produced by default.


title: HISTORY
content:
<I>gml2gv</I> is an integral component of the <I>Graphviz</I> open-source graph visualization software suite, which originated at <I>AT&T Labs Research</I>. Its development was driven by the need to facilitate interoperability between the older yet widely used <I>Graph Modeling Language (GML)</I> format and <I>Graphviz's</I> native <I>DOT</I> language. This utility bridges the gap between different graph representation standards, allowing users to leverage <I>Graphviz's</I> powerful layout and rendering capabilities on graph data originally defined in <I>GML</I>.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message showing all available options and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of <b>gmondump</b> and exits.<br><br><b><b>-d</b> <I>RRD_DIR</I>, <b>--dir=</b><I>RRD_DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory where <I>Ganglia</I> RRD (Round Robin Database) files are stored. This is typically the directory managed by <I>gmetad</I>.<br><br><b><b>-o</b> <I>OUTPUT_FILE</I>, <b>--output=</b><I>OUTPUT_FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the XML output to the specified file. If this option is not provided, <b>gmondump</b> writes the output to standard output (<I>stdout</I>).<br><br><b><b>-c</b> <I>CLUSTER_NAME</I>, <b>--cluster=</b><I>CLUSTER_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to include data only from the specified <I>Ganglia</I> cluster. This is useful in environments with multiple monitored clusters.<br><br><b><b>-H</b> <I>HOST_NAME</I>, <b>--host=</b><I>HOST_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to include data only from the specified host. This allows targeting specific machine data within a cluster.<br><br><b><b>-m</b> <I>METRIC_NAME</I>, <b>--metric=</b><I>METRIC_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to include data only for the specified metric name (e.g., 'cpu_idle', 'mem_free').<br><br><b><b>-a</b>, <b>--all-data</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps all historical data points available in the RRD files for the selected metrics, rather than just the latest recorded value. Using this option can lead to very large output files.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the dumping process, including which files are being processed.<br><br>


title: DESCRIPTION
content:
<b>gmondump</b> is a utility included with the <I>Ganglia</I> distributed monitoring system. Its primary function is to extract historical performance metrics stored in <I>Ganglia's</I> RRD (Round Robin Database) files. The command reads these highly efficient time-series databases, which contain collected data from various hosts and clusters, and typically outputs the information in a structured XML format.<br><br>This tool is invaluable for a variety of tasks, including migrating <I>Ganglia</I> data to new servers, performing offline analysis of historical performance trends, debugging issues with RRD files, or integrating <I>Ganglia</I> data with external systems. By default, <b>gmondump</b> outputs only the latest recorded value for each metric. However, it can be instructed to dump all historical data points, which can generate very large output files depending on the scale of the monitoring environment.


title: CAVEATS
content:
<ul><li><b>Requires Ganglia RRD Files:</b> <b>gmondump</b> relies on the RRD file structure created by <I>gmetad</I> or <I>gmond</I>. It will not function correctly without a valid and accessible <I>Ganglia</I> RRD directory.</li><li><b>Large Output with --all-data:</b> When using the <b>--all-data</b> (<b>-a</b>) option, the generated XML output can be extremely large, especially in large-scale deployments or with long data retention periods. This can consume significant disk space and may require substantial time to process.</li><li><b>XML Parsing Required:</b> The primary output format is XML, which necessitates appropriate XML parsers or scripting tools for further processing, analysis, or integration into other systems.</li><li><b>Resource Intensive:</b> Dumping large datasets can be I/O intensive on the host system, potentially impacting disk performance during the operation.</li></ul>


title: TYPICAL USE CASES
content:
<ul><li><b>Data Migration:</b> Facilitates moving existing <I>Ganglia</I> RRD data from one server to another, or upgrading <I>Ganglia</I> installations while preserving historical metrics.</li><li><b>Offline Analysis:</b> Enables exporting comprehensive historical data for detailed post-mortem analysis using external analytical tools, custom scripts, or data visualization platforms.</li><li><b>Debugging and Troubleshooting:</b> Provides a way to inspect the raw content of RRD files and verify data integrity, which is invaluable when diagnosing data collection or storage issues within <I>Ganglia</I>.</li><li><b>Integration with Other Systems:</b> Offers a structured data source (XML) for integrating <I>Ganglia</I> metrics into other monitoring dashboards, data warehouses, custom reporting tools, or third-party applications.</li></ul>


title: OUTPUT FORMAT
content:
The XML output generated by <b>gmondump</b> follows a hierarchical structure, typically rooted by a <I>&lt;GANGLIA_RRD&gt;</I> element. Within this, data is organized into <I>&lt;CLUSTER&gt;</I>, <I>&lt;HOST&gt;</I>, and <I>&lt;METRIC&gt;</I> tags, mirroring <I>Ganglia's</I> internal data model. Each metric entry usually includes attributes such as 'name', 'val' (for the current value), and, if the <b>--all-data</b> option is used, time-series data points with their corresponding timestamps. Users intending to process this output should have familiarity with XML parsing techniques.


title: HISTORY
content:
<b>gmondump</b> emerged as a vital utility within the <I>Ganglia</I> distributed monitoring system, an open-source project initiated at the University of California, Berkeley, in the early 2000s. From its inception, <I>Ganglia</I> leveraged <I>RRDtool</I> for the efficient storage and retrieval of time-series performance data. As the adoption and complexity of <I>Ganglia</I> deployments grew, so did the need for robust mechanisms to extract this valuable historical data for purposes such as migration, in-depth analysis, or integration with external systems.<br><br><b>gmondump</b> was developed to meet this demand, providing a structured, typically XML, export of the collected performance metrics. It has remained a stable and essential component of the <I>Ganglia</I> distribution, underscoring the project's commitment to data accessibility and interoperability. Its core functionality of exporting RRD data has largely remained consistent throughout its development history.


title: SYNOPSIS
content:
<b>gmssl</b> <i>&lt;subcommand&gt;</i> [<i>&lt;options&gt;</i>] [<i>&lt;arguments&gt;</i>]<br><br>The <b>gmssl</b> command operates by invoking various <i>subcommands</i>, each dedicated to a specific cryptographic task. Options and arguments are specific to the chosen subcommand. To list available subcommands, use <b>gmssl</b> <i>help</i>.


title: PARAMETERS
content:
<b><i>&lt;subcommand&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the cryptographic operation to perform (e.g., <i>sm2</i>, <i>sm3</i>, <i>sm4</i>, <i>req</i>, <i>x509</i>, <i>rand</i>, <i>speed</i>, <i>version</i>, <i>help</i>).<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays usage information for the specified subcommand or general help if no subcommand is given.<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, providing more detailed information about the operation.<br><br><b>-engine <i>&lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a cryptographic engine to use for hardware acceleration or specialized operations.<br><br><b>-in <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file for the operation (e.g., data to be encrypted, a certificate, or a key).<br><br><b>-out <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file where the result of the operation will be written (e.g., encrypted data, a generated key, or a hash).<br><br><b>-passin <i>&lt;arg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source for a password to decrypt input data or a key (e.g., <i>pass:&lt;password&gt;</i>, <i>env:&lt;varname&gt;</i>, <i>file:&lt;filepath&gt;</i>, <i>fd:&lt;number&gt;</i>, <i>stdin</i>).<br><br><b>-passout <i>&lt;arg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination for a password to encrypt output data or a key (same formats as <i>-passin</i>).<br><br><b>-encrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with certain subcommands (e.g., <i>sm4</i>) to perform encryption.<br><br><b>-decrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with certain subcommands (e.g., <i>sm4</i>) to perform decryption.<br><br><b>-digenst <i>&lt;alg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the digest (hash) algorithm to use, such as <i>SM3</i>.<br><br>


title: DESCRIPTION
content:
The <b>gmssl</b> command is a versatile command-line utility that provides access to the cryptographic functions of the GMSSL library. It serves a similar purpose to the widely known <i>openssl</i> command, but its primary focus is on implementing and utilizing <br>Chinese national cryptographic algorithms, including but not limited to <br>SM2 (elliptic curve public-key cryptography), SM3 (cryptographic hash function), and SM4 (block cipher).<br><br><b>gmssl</b> is used for a wide range of cryptographic operations such as generating keys, encrypting and decrypting data, signing and verifying digital signatures, managing X.509 certificates, and performing cryptographic hash calculations. It is an essential tool for developers and security professionals working with systems that require adherence to Chinese cryptographic standards, often found in government, financial, and critical infrastructure sectors within China.


title: CAVEATS
content:
<b>gmssl</b>'s primary focus on Chinese national cryptographic algorithms (SM2, SM3, SM4, etc.) means it may not be directly interoperable with cryptographic systems relying solely on Western standards (e.g., RSA, SHA-256, AES) without explicit bridging or conversion. Its adoption is more prevalent in environments that specifically require compliance with Chinese cryptographic regulations and standards. Users should be aware of the specific algorithm choices and their implications for cross-platform compatibility.


title: KEY SUBCOMMANDS
content:
The <b>gmssl</b> command functions as a multiplexer for numerous cryptographic operations. Some of the most frequently used subcommands include:<br><i>sm2</i>: For SM2 elliptic curve operations like key generation, encryption/decryption, and digital signatures.<br><i>sm3</i>: For generating SM3 hash digests.<br><i>sm4</i>: For symmetric encryption and decryption using the SM4 block cipher.<br><i>req</i>: For creating and managing Certificate Signing Requests (CSRs) based on SM2 keys.<br><i>x509</i>: For managing X.509 certificates, including displaying, verifying, and converting formats.<br><i>rand</i>: For generating cryptographically secure pseudo-random bytes.


title: ALGORITHM FOCUS
content:
Unlike <i>openssl</i>, which supports a vast array of international cryptographic algorithms, <b>gmssl</b> is specialized. Its core strength lies in providing native and optimized implementations of Chinese national algorithms. This specialization makes it the go-to tool for developers and organizations that must comply with specific Chinese cryptographic requirements.


title: HISTORY
content:
The development of GMSSL (and consequently the <b>gmssl</b> command-line tool) stems from China's increasing emphasis on national cryptographic standards to secure its digital infrastructure. As the Chinese cryptographic algorithms (SM series) gained official recognition and became mandatory for certain applications within China, an open-source implementation was needed. GMSSL fills this role, providing a robust library and command-line utility for these standards, paralleling the evolution of <i>OpenSSL</i> for international standards. Its usage has grown with the broader adoption of SM algorithms in various sectors.


title: SYNOPSIS
content:
<b>gnatmake</b> [<i>options</i>] <i>main_source_file</i> [<i>project_file</i>]<br>or<br><b>gnatmake</b> [<i>options</i>] <b>-P</b><i>project_file</i> [<i>main_source_file</i>]


title: PARAMETERS
content:
<b><b>-P</b><i>project_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GNAT project file (e.g., <i>my_project.gpr</i>) to be used for the build.<br><br><b><b>-gnatL</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the linker options that would be used without actually performing the link.<br><br><b><b>-gnatO</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the executable output file produced by the link stage.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles only, without performing the final linking step to create an executable.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Links only, assuming all necessary compilation units are already compiled and up-to-date.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces unconditional recompilation of all source files, ignoring timestamps.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in quiet mode, suppressing most informational messages during the build.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in verbose mode, showing detailed progress and commands executed.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues as much as possible after encountering compilation or linking errors.<br><br><b><b>-j</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles and links in parallel, utilizing up to N jobs/threads.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds debugging information to the compiled executables, enabling source-level debugging.<br><br><b><b>-O</b><i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the optimization level for the compiler (e.g., 0 for no optimization, 1, 2, 3 for increasing optimization, s for size optimization).<br><br><b><b>-X</b><i>name=value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines or overrides an external variable within the project file context.<br><br><b><b>-a</b><i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a source directory to the list of paths searched for source files.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates object files even if only the source file's date is newer, overriding other checks.<br><br><b><b>--RTS</b>=<i>runtime</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Ada runtime library to use for linking (e.g., <i>light-tasking</i>, <i>ravenscar-sfp</i>).<br><br>


title: DESCRIPTION
content:
<b>gnatmake</b> is the primary build utility for Ada projects within the GNAT (GNU Ada Toolset) environment. Similar to the traditional <b>make</b> command, it automates the compilation and linking process by analyzing dependencies between source files. It intelligently recompiles only those files that have changed or whose dependencies have been updated, ensuring efficient builds and reducing compilation times.<br><br>It integrates seamlessly with GNAT's compiler and linker, supporting various compilation modes, optimization levels, and debugging options. <b>gnatmake</b> can operate on individual source files or, more commonly, utilize GNAT Project Files (<b>.gpr</b> files) to manage complex multi-directory, multi-language projects. This streamlines the entire build workflow for Ada applications, making it an essential tool for developers working with the Ada programming language.


title: CAVEATS
content:
<b>gnatmake</b> is specifically designed for Ada projects and requires the GNAT toolchain to be installed and correctly configured. While powerful, particularly with GNAT Project Files (<b>.gpr</b>), complex project setups might require a deep understanding of <b>.gpr</b> file syntax and inter-project dependencies. It primarily focuses on Ada, though project files can integrate other languages (like C/C++), their compilation might still rely on external tools. Debugging build issues often involves examining verbose output or thoroughly checking <b>.gpr</b> file definitions.


title: PROJECT FILE INTEGRATION
content:
<b>gnatmake</b> heavily leverages GNAT Project Files (<b>.gpr</b>) for managing complex, multi-language, and multi-directory projects. These files serve as a central definition for sources, object directories, executable names, external tool chains, and dependencies, significantly simplifying the build process compared to manual makefiles.


title: AUTOMATIC DEPENDENCY MANAGEMENT
content:
One of <b>gnatmake</b>'s core strengths is its automatic dependency analysis. It intelligently parses Ada's <b>with</b> clauses and <b>separate</b> compilation units to determine the precise order of compilation and to only recompile units that are truly out of date. This saves considerable build time and reduces the chance of erroneous builds due to overlooked dependencies.


title: HISTORY
content:
<b>gnatmake</b> emerged as part of the GNAT (GNU Ada Toolset) project, which began in the early 1990s at New York University. Its development aimed to provide a robust, open-source Ada compiler and a complete development environment, including a sophisticated build system. <b>gnatmake</b> was designed to leverage Ada's strong typing and module system to automatically manage dependencies, making builds more reliable and efficient than traditional <b>make</b> setups for Ada.<br><br>While <b>gprbuild</b> later introduced more generalized and advanced project management capabilities, <b>gnatmake</b> remains a core utility for building Ada applications, especially for simpler projects or when explicit control over compilation and linking is desired.


title: PARAMETERS
content:
<b><b>-c</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a configuration <i>file</i> that contains characteristic definitions to be used by <b>gnatprep</b>.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents case conversion of identifiers found within the input Ada source code.<br><br><b><b>-D</b><i>characteristic</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a specific <i>characteristic</i> as true, enabling conditional compilation branches dependent on this characteristic.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables processing of non-Ada files, treating them line by line for conditional compilation directives.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates dependency information, which is useful for build systems like <b>gprbuild</b> to track preprocessor dependencies.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information about the command and its options, then exits.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps any intermediate files that are generated during the preprocessing operation.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all defined characteristics and their current values, providing insight into the preprocessing environment.<br><br><b><b>-o</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>file</i> where the preprocessed output will be written. If this option is omitted, output is directed to standard output.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a template for a configuration file, outputting it to standard output, which can be useful for setting up new projects.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for characteristics in standard system configuration files in addition to user-specified ones.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables case conversion during processing (similar to <b>-C</b>).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing detailed progress and information about the preprocessing steps.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>gnatprep</b> and then exits.<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warning messages that might otherwise be issued during the preprocessing phase.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats any undefined characteristics as false, rather than assuming them to be true by default.<br><br>


title: DESCRIPTION
content:
<b>gnatprep</b> is a utility from the GNAT toolchain designed to preprocess Ada source files. Its primary function is to handle conditional compilation based on "characteristics" defined by the system, specific configurations, or explicitly provided parameters. It interprets special pragmas like <b>pragma System_Specific</b> and <b>pragma Configuration_Specific</b>, allowing different sections of code to be included or excluded during compilation based on the target environment or build settings. This mechanism is crucial for developing portable Ada code that adapts seamlessly to various platforms or custom configurations, significantly enhancing code reuse and maintainability across diverse projects. The preprocessor can read input from standard source files and direct its processed output to a specified file or to standard output.


title: CAVEATS
content:
<b>gnatprep</b> is primarily designed for Ada source files. While the <b>-e</b> option allows processing of other file types, unexpected behavior may occur if conditional compilation pragmas are not formatted in a way that <b>gnatprep</b> can interpret correctly.<br>The effectiveness of conditional compilation heavily relies on the accurate definition of characteristics through configuration files or command-line arguments; incorrect definitions can lead to unintended code segments being included or excluded.<br>Over-reliance on conditional compilation can sometimes complicate code readability and debugging, making it essential to use this feature judiciously.


title: HISTORY
content:
<b>gnatprep</b> is an integral component of the GNAT (GNU Ada Translator) toolchain, which was initially developed by AdaCore (formerly ACT-Europe) and is now part of the GNU Project. Its development has consistently paralleled the evolution of the Ada language and the GNAT compiler itself, providing a crucial mechanism for handling platform-specific code and configuration management within Ada projects. It has remained a stable and essential utility within the GNAT ecosystem for many years, adapting to new Ada standards and evolving build system requirements.


title: SYNOPSIS
content:
<B>gnmic</B> [<I>global-options</I>] <I>command</I> [<I>command-options</I>] [<I>arguments</I>]<br><br><b>Common Commands:</b><br>&nbsp;&nbsp;<B>capabilities</B>&nbsp;&nbsp;Discover device capabilities and supported models.<br>&nbsp;&nbsp;<B>get</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Retrieve configuration and state from a device.<br>&nbsp;&nbsp;<B>set</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Modify configuration on a device.<br>&nbsp;&nbsp;<B>subscribe</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subscribe to telemetry streams from a device.<br>&nbsp;&nbsp;<B>diff</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Compare configurations or states.<br>&nbsp;&nbsp;<B>generate</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Generate gNMI paths or configuration payloads.<br>&nbsp;&nbsp;<B>register</B>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Register for event notifications.


title: PARAMETERS
content:
<b><B>--address, -a</B> <I>&lt;addr&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the gNMI target address(es) to connect to (e.g., <I>localhost:50051</I>).<br><br><b><B>--username, -u</B> <I>&lt;user&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the username for gNMI authentication.<br><br><b><B>--password, -p</B> <I>&lt;pass&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for gNMI authentication.<br><br><b><B>--insecure</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables TLS certificate verification, allowing connections to servers with untrusted certificates.<br><br><b><B>--tls-ca</B> <I>&lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the CA certificate file for TLS authentication.<br><br><b><B>--encoding</B> <I>&lt;type&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the gNMI encoding type for data (e.g., <I>JSON</I>, <I>PROTO</I>, <I>JSON_IETF</I>).<br><br><b><B>--format</B> <I>&lt;fmt&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output format for responses (e.g., <I>JSON</I>, <I>YAML</I>, <I>TEXT</I>, <I>PROTO</I>).<br><br><b><B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging output for troubleshooting.<br><br><b><B>--config</B> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a path to a <I>gnmic</I> configuration file (typically <I>gnmic.yaml</I>).<br><br>


title: DESCRIPTION
content:
<I>gnmic</I> is a powerful, open-source CLI client for the <B>gRPC Network Management Interface (gNMI)</B> protocol. It enables network operators and engineers to interact with network devices that support gNMI, offering a modern alternative to traditional protocols like SNMP and NETCONF.<br><br>With <I>gnmic</I>, users can perform various operations such as <B>subscribing to telemetry data</B>, <B>retrieving configuration and operational state</B>, <B>setting configuration</B>, and <B>discovering device capabilities</B>. Its design emphasizes flexibility and scriptability, supporting multiple output formats like JSON, YAML, and text, making it highly suitable for integration into automation workflows. <I>gnmic</I> simplifies network automation by providing a unified, high-performance way to manage heterogeneous network infrastructure using a standardized protocol. It supports essential features including TLS, authentication, and all gNMI RPCs (Capabilities, Get, Set, Subscribe, Diff), making it an indispensable tool for modern network operations and programmability.


title: CAVEATS
content:
<li>Requires network devices to support and be configured for gNMI.<br></li><li>Correct TLS setup (certificates, CA) can be complex for secure deployments.<br></li><li>Understanding gNMI paths and models (e.g., OpenConfig) is crucial for effective use.</li>


title: SUPPORTED RPCS
content:
<I>gnmic</I> fully supports all core gNMI RPCs: <B>Capabilities</B> (to discover device features), <B>Get</B> (for one-time data retrieval), <B>Set</B> (for configuration changes), and <B>Subscribe</B> (for continuous telemetry streams).


title: CONFIGURATION FILES
content:
<I>gnmic</I> can be configured using a <B>YAML file</B> (defaulting to <I>~/.gnmic.yaml</I> or <I>gnmic.yaml</I> in the current directory). This allows users to define target connections, TLS settings, default encodings, and more, avoiding repetitive command-line arguments.


title: HISTORY
content:
The <I>gnmic</I> CLI client was developed by members of the <B>OpenConfig</B> community, notably by SNC, as a modern, high-performance tool to interact with network devices using the <B>gRPC Network Management Interface (gNMI)</B> protocol. It emerged to address the limitations of traditional network management protocols like SNMP and NETCONF, offering a streaming-capable, RPC-based alternative. Its development focused on providing a robust, flexible, and automation-friendly interface, quickly gaining traction within the network automation and programmable networking communities. It is now widely used across various network operating systems and vendor platforms supporting gNMI.


title: SEE ALSO
content:
<I>snmpget(1)</I>: A traditional CLI for SNMP network management., <I>netconf-console(1)</I>: A CLI for NETCONF protocol interactions., <I>grpc(7)</I>: General information about the gRPC framework used by gNMI.


title: SYNOPSIS
content:
<b>gnmic</b> [<i>GLOBAL_FLAGS</i>] <b>get</b> [<i>GET_FLAGS</i>] [--path <i>&lt;gNMI_PATH&gt;</i>...]


title: PARAMETERS
content:
<b>-a, --address</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies one or more <b>gNMI target addresses</b> (e.g., <i>host:port</i>). Can be specified multiple times.<br><br><b>-u, --username</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Sets the <b>username</b> for gNMI authentication.<br><br><b>-p, --password</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Sets the <b>password</b> for gNMI authentication.<br><br><b>--insecure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Disables <b>TLS certificate verification</b>, useful for testing with self-signed certificates.<br><br><b>--tls-ca, --tls-cert, --tls-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Paths to <b>TLS CA, client certificate, and client key</b> files for mutual TLS authentication.<br><br><b>-P, --path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>One or more <b>gNMI paths</b> to retrieve data from. This option can be specified multiple times.<br><br><b>--prefix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>A <b>gNMI path prefix</b> that is applied to all specified <i>--path</i> arguments.<br><br><b>-t, --type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies the <b>data type</b> to retrieve: <i>ALL, CONFIG, STATE, OPERATIONAL</i>. Defaults to <i>ALL</i>.<br><br><b>--model</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>One or more <b>OpenConfig or custom data models</b> to include in the gNMI capabilities request, aiding path resolution.<br><br><b>--encoding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies the <b>gNMI encoding</b> for the request message: <i>JSON, JSON_IETF, ASCII, PROTO</i>.<br><br><b>--format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies the <b>output format</b> for the received data: <i>JSON, YAML, TEXT</i>. Affects client-side rendering.<br><br><b>--target</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>The <b>target name</b> used when connecting to a gNMI proxy that manages multiple targets.<br><br><b>--timeout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Sets the <b>gRPC timeout</b> for the request (e.g., <i>5s, 1m</i>). If exceeded, the command will abort.<br><br>


title: DESCRIPTION
content:
<b>gnmic-get</b> is a core subcommand of the <b>gnmic</b> command-line interface client, designed to interact with network devices implementing the <b>gNMI</b> (<i>gRPC Network Management Interface</i>) protocol.<br><br>It enables users to retrieve <i>configuration</i> and <i>state</i> information from a gNMI target, which is typically a network device or a network function. This command is crucial for various network automation tasks, including monitoring device operational parameters, fetching specific configuration elements, validating device state programmatically, and debugging.<br><br><b>gnmic-get</b> supports fetching data based on precise gNMI paths, allowing for granular control over the retrieved information. It can interact with different data models, such as <i>OpenConfig</i>, and handle various data encodings (e.g., <i>JSON, JSON_IETF</i>). The command provides flexibility in specifying target addresses, authentication credentials, and TLS settings for secure and authenticated communication with network infrastructure. Its output can be formatted in different ways, making it suitable for scripting and integration with other automation tools.


title: CAVEATS
content:
<b>gnmic-get</b> requires a gNMI-enabled network device or service to connect to.<br>Understanding of <b>gNMI path syntax</b> and relevant <b>data models</b> (e.g., OpenConfig) is essential for effective use.<br>Authentication and TLS configuration can be complex and must be correctly set up for secure communication.<br>Retrieving large data sets might consume significant network bandwidth and device resources, potentially impacting performance.


title: GNMI PATH SYNTAX
content:
gNMI paths specify data elements in a tree-like structure. They are typically absolute and can include keys for list entries. For example: <i>/interfaces/interface[name=ethernet0/1]/state/admin-status</i> retrieves the administrative status of a specific interface. Paths can point to configurations (<i>config</i>), operational states (<i>state</i>), or a combination.


title: DATA TYPES
content:
The <i>--type</i> flag allows filtering the data returned by the target:<br><b>CONFIG</b>: retrieves user-configured data.<br><b>STATE</b>: retrieves operational state data, which is typically read-only.<br><b>OPERATIONAL</b>: often a superset of STATE, including dynamically generated data.<br><b>ALL</b>: retrieves all available data (both CONFIG and STATE/OPERATIONAL).


title: HISTORY
content:
<b>gnmic</b> emerged as a critical tool in the growing ecosystem of network automation, driven by the adoption of <b>gNMI</b> as an open standard for network management. Developed by the open-source community, it provides a flexible and powerful command-line interface for interacting with gNMI targets, complementing existing tools and enabling modern, intent-driven network operations. Its development is closely tied to advancements in network operating systems supporting gNMI and the proliferation of network automation practices.


title: PARAMETERS
content:
<b>--encoding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the encoding format for the data values received, e.g., <br><b>JSON_IETF</b>, <b>PROTO</b>, <b>ASCII</b>.</i><br><br><b>-f, --file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reads gNMI paths to subscribe to from a specified file.</i><br><br><b>--format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines the output format of the received notifications, e.g., <br><b>Event</b>, <b>JSON</b>, <b>ProtobufText</b>.</i><br><br><b>-i, --interval</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the sample interval for <br><b>SAMPLE</b> stream subscriptions.</i><br><br><b>-m, --mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The overall subscription mode: <br><b>ONCE</b> (single snapshot), <br><b>STREAM</b> (continuous updates), or <br><b>POLL</b> (client-driven pull).</i><br><br><b>--sub-mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>For <br><b>STREAM</b> subscriptions, specifies the streaming mode: <br><b>SAMPLE</b> (periodic updates), <br><b>ON_CHANGE</b> (event-driven updates), or <br><b>TARGET_DEFINED</b>.</i><br><br><b>-o, --output-file</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Directs the output of received telemetry to a specified file instead of stdout.</i><br><br><b>-p, --prefix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Applies a common gNMI path prefix to all specified paths.</i><br><br><b>--target</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the target name for the gNMI connection.</i><br><br><b>--target-address</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The gRPC endpoint address of the gNMI target <br>(e.g., <b>localhost:57400</b>).</i><br><br><b>--username, --password</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Credentials for authenticating with the gNMI target.</i><br><br><b>--tls-ca, --tls-cert, --tls-key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Paths to CA, client certificate, and client key files for secure TLS communication.</i><br><br><b>--tls-insecure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables TLS certificate validation (use with caution).</i><br><br><b>[paths...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>One or more gNMI paths to subscribe to <br>(e.g., <b>/interfaces/interface[name=eth0]/state/counters</b>).</i><br><br>


title: DESCRIPTION
content:
The <b>gnmic-sub</b> command is a core component of the <b>gnmic</b> CLI client, designed for subscribing to and receiving telemetry data and state information from gNMI (gRPC Network Management Interface) enabled network devices. It allows users to establish continuous streaming sessions, request one-time snapshots, or poll for specific data points from device sensors and configuration state.<br><br><b>gnmic-sub</b> supports various subscription modes (e.g., <i>STREAM</i>, <i>ONCE</i>, <i>POLL</i>), different value encodings (e.g., <i>JSON_IETF</i>, <i>PROTO</i>), and flexible output formats, making it an indispensable tool for network monitoring, automation, and integration with data collection pipelines. It provides a powerful way to observe real-time network behavior and changes.


title: CAVEATS
content:
<i><b>gnmic-sub</b> relies on a gNMI-capable server on the network device. The behavior and available data depend entirely on the device's gNMI agent implementation. Users must ensure network connectivity and proper firewall rules. Understanding gNMI path syntax and data models (YANG) is crucial for effective use. Some devices might not support all subscription modes, encodings, or specific paths, leading to errors or incomplete data.</i>


title: SUBSCRIPTION MODES
content:
<i><b>gnmic-sub</b> supports different subscription modes as defined by the gNMI specification:<br><b>ONCE</b>: Requests a single snapshot of the specified paths. The subscription terminates after receiving the data.<br><b>STREAM</b>: Establishes a continuous stream of updates. This mode further divides into:<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>SAMPLE</b>: Periodic updates at a specified interval, even if the data hasn't changed.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>ON_CHANGE</b>: Updates only when the data changes, providing event-driven notifications.<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>TARGET_DEFINED</b>: Allows the target device to define the streaming behavior, often a combination of sample and on-change.<br><b>POLL</b>: The client explicitly sends poll requests at chosen intervals to receive current updates.</i>


title: DATA ENCODINGS
content:
<i>gNMI supports various data encodings for the values in telemetry updates, affecting how data is serialized and transmitted. Common encodings supported by <b>gnmic-sub</b> include:<br><b>JSON_IETF</b>: JSON format adhering to RFC 7951 (IETF JSON), commonly used for YANG data.<br><b>PROTO</b>: Google Protocol Buffer encoded data, efficient for machine-to-machine communication.<br><b>ASCII</b>: Simple ASCII text encoding.<br><b>BYTES</b>: Raw byte representation.<br><b>JSON</b>: Generic JSON format (non-IETF standard).<br><b>GOPROTO</b>: Go-specific Protocol Buffer encoding.</i>


title: OUTPUT FORMATS
content:
<i>The command can format the received gNMI notifications for better readability or integration with other tools:<br><b>Event</b>: A human-readable, structured event-based output, showing path, value, and metadata.<br><b>JSON</b>: Raw JSON output of the gNMI notification message.<br><b>ProtobufText</b>: Text-formatted Protocol Buffer output, useful for debugging.<br><b>flat</b>: A flattened, simpler JSON output format, often preferred for easy parsing.<br><b>Protobuf</b>: Raw binary Protocol Buffer output.</i>


title: HISTORY
content:
<i>The <b>gnmic</b> project was initiated to provide a robust, open-source command-line interface for interacting with network devices using the gNMI protocol. Its development aimed to simplify operations such as telemetry subscription, configuration retrieval, and modification, which are fundamental to modern network automation and observability practices. <b>gnmic-sub</b> emerged as a primary feature to leverage gNMI's powerful streaming capabilities for real-time network state monitoring, playing a key role in making gNMI accessible to network engineers and developers.</i>


title: SYNOPSIS
content:
<B>gnmic subscribe</B> [<I>options</I>] [<I>paths</I>...]<br><br>Examples:<br><B>gnmic subscribe</B> <I>--target router1:50051</I> <I>--path /interfaces/interface/state/oper-status</I> <I>--mode stream</I> <I>--stream-mode on-change</I><br><B>gnmic subscribe</B> <I>--target router2:50051</I> <I>--path /system/cpu</I> <I>--mode poll</I> <I>--interval 10s</I><br><B>gnmic subscribe</B> <I>--target router3:50051</I> <I>--path /</I> <I>--mode once</I>


title: PARAMETERS
content:
<b><I>--mode</I> <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the subscription mode. Common modes include <B>ONCE</B> (single snapshot), <B>POLL</B> (periodic snapshots), and <B>STREAM</B> (continuous updates).<br><br><b><I>--stream-mode</I> <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the streaming mode for <B>STREAM</B> subscriptions. Options are <B>ON_CHANGE</B> (updates only when data changes) or <B>SAMPLE</B> (updates at a specified interval).<br><br><b><I>--path</I> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more gNMI paths to subscribe to. Can be specified multiple times for different paths.<br><br><b><I>--target</I> <I>target</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The gNMI target (device address:port) to connect to. Can be specified multiple times for subscribing to multiple targets concurrently.<br><br><b><I>--model</I> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the OpenConfig or custom YANG model(s) to be used for the subscription. Can be specified multiple times.<br><br><b><I>--interval</I> <I>duration</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sampling interval for <B>POLL</B> or <B>STREAM</B> (<B>SAMPLE</B> sub-mode) subscriptions (e.g., '10s', '5m').<br><br><b><I>--encoding</I> <I>encoding</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired encoding for the received data. Common values include <B>JSON</B>, <B>JSON_IETF</B>, <B>PROTO</B>, <B>ASCII</B>, <B>BYTES</B>.<br><br><b><I>--output</I> <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the format of the output messages. Examples: <B>json</B>, <B>event</B>, <B>flat</B>, <B>proto</B>.<br><br><b><I>--tls-ca</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the CA certificate file for TLS authentication.<br><br><b><I>--tls-cert</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the client certificate file for TLS authentication.<br><br><b><I>--tls-key</I> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the client private key file for TLS authentication.<br><br><b><I>--tls-skip-verify</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips TLS certificate and host verification (use with caution).<br><br>


title: DESCRIPTION
content:
The <I>gnmic-subscribe</I> command is a core function of the <I>gnmic</I> gNMI client, designed to initiate and manage gNMI subscription streams. It allows users to receive real-time updates from network devices conforming to the gNMI (gRPC Network Management Interface) specification. Unlike one-off <I>get</I> requests, subscriptions provide continuous data delivery based on specified paths and modes. This command supports various subscription modes, including <B>ONCE</B> (a single snapshot), <B>POLL</B> (periodic snapshots), and <B>STREAM</B> (continuous updates). For <B>STREAM</B> mode, further sub-modes like <B>ON_CHANGE</B> (updates only when data changes) and <B>SAMPLE</B> (updates at regular intervals) are available. It's crucial for monitoring network state, collecting telemetry, and integrating with data analytics platforms. Users can specify target devices, data paths, desired encoding, and output formats, making it a versatile tool for network observability.


title: CAVEATS
content:
Long-running subscriptions can consume significant network bandwidth and device resources, especially with frequent updates or large data sets. Ensure network stability and device capacity to avoid connection drops or performance degradation. Misconfigured paths or models may lead to no data being received or errors. Security considerations, such as proper TLS setup, are paramount when connecting to production devices.


title: SUBSCRIPTION MODES
content:
<B>ONCE</B>: Fetches the current state of the subscribed paths once, then terminates.<br><B>POLL</B>: Periodically fetches the current state of the subscribed paths at a specified interval.<br><B>STREAM</B>: Maintains an open connection and continuously streams updates. This mode has further sub-modes:


title: STREAM SUB-MODES (FOR STREAM MODE)
content:
<B>ON_CHANGE</B>: Sends updates only when the value of a subscribed path changes.<br><B>SAMPLE</B>: Sends updates at a regular, specified interval, regardless of whether the data has changed. Often used for performance metrics.<br><B>TARGET_DEFINED</B>: The target device decides how to send updates for a path, typically a mix of ON_CHANGE and SAMPLE behavior.


title: GNMI PATHS
content:
gNMI paths identify specific data nodes within a device's YANG data model. They can be absolute (starting with '/') or relative. Wildcards ('*') are often supported by devices for subscribing to multiple elements or sub-trees.


title: HISTORY
content:
<I>gnmic</I> itself is a relatively modern tool, developed to provide a robust and easy-to-use command-line interface for the gNMI protocol. The <I>subscribe</I> command has been a fundamental part of <I>gnmic</I> since its early versions, reflecting gNMI's primary use case for streaming telemetry and real-time network monitoring. Its evolution has focused on improving stability, expanding supported gNMI features (like history, qos), and enhancing usability with various output formats and connection options.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show general help options for the command.<br><br><b>--help-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all help options, including GTK-specific and application-specific ones.<br><br><b>--help-gtk</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show GTK-specific options, related to the graphical toolkit.<br><br><b>-s, --scientific</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the calculator in scientific mode, providing advanced mathematical functions.<br><br><b>-p, --programming</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the calculator in programming mode, allowing calculations in various number bases and bitwise operations.<br><br><b>-f, --financial</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the calculator in financial mode, useful for financial computations like loan payments.<br><br><b>-b, --basic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the calculator in basic mode, the default mode for simple arithmetic.<br><br><b>-e, --equation=EXPRESSION</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the calculator with a predefined equation or expression. The result will be displayed. For example, <i>gnome-calculator -e "sqrt(16)"</i>.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the application's version information and exits.<br><br><b>--display=DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for launching the graphical interface.<br><br>


title: DESCRIPTION
content:
<i>gnome-calculator</i> is the official and default calculator application for the GNOME desktop environment. It provides a user-friendly graphical interface for performing a wide range of calculations. Beyond basic arithmetic, it offers advanced functionalities including scientific calculations (trigonometry, logarithms, exponentiation), programming modes (binary, octal, hexadecimal operations, bitwise operations), and financial calculations (loan payments, compound interest). The application is designed to be intuitive for everyday use while powerful enough for more complex mathematical, scientific, and engineering tasks. It can also handle unit conversions and a history of previous calculations.


title: CAVEATS
content:
The <i>gnome-calculator</i> command primarily serves to launch the graphical user interface. While it supports passing an initial <i>EXPRESSION</i> using the <i>--equation</i> option, it does not provide a robust command-line interface for complex computations or scripting without launching the GUI. For purely command-line calculations or scripting, utilities like <i>bc(1)</i> or <i>dc(1)</i> are generally more suitable.


title: MODES OF OPERATION
content:
<i>gnome-calculator</i> offers several distinct modes tailored for different calculation needs. The <b>Basic</b> mode handles standard arithmetic. The <b>Scientific</b> mode provides advanced mathematical functions including trigonometry, logarithms, and constants. The <b>Programming</b> mode allows for calculations in various number bases (binary, octal, decimal, hexadecimal) and bitwise operations. The <b>Financial</b> mode assists with common financial calculations like loan payments and interest. Users can switch between these modes easily from the graphical interface or by using command-line options upon launch.


title: HISTORY
content:
<i>gnome-calculator</i> has been a fundamental component of the GNOME desktop environment since its early versions, providing a standard and accessible calculator utility for millions of users. Its development has focused on integrating seamlessly with the GNOME user experience, evolving with GTK+ toolkit updates and incorporating new features like scientific, financial, and programming modes to meet a broader range of user needs. It continues to be actively maintained as part of the GNOME Core Applications.


title: PARAMETERS
content:
<b><i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The path to the directory where a new <i>.desktop</i> item should be saved. If omitted, it often defaults to the user's desktop directory.<br><br><b><b>--create-new</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Explicitly indicates that a new desktop item should be created. When used, it's typically followed by a <i>DIRECTORY</i>.<br><br><b><b>--file=</b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the path to an existing <i>.desktop</i> file that should be opened for editing instead of creating a new one.<br><br>


title: DESCRIPTION
content:
<i>gnome-desktop-item-edit</i> is a graphical utility within the GNOME desktop environment designed for creating and modifying <i>.desktop</i> files. These files serve as shortcuts or launchers for applications, documents, or URLs, allowing them to appear in application menus, on the desktop, or in panels.<br><br>When invoked, it typically opens a dialog box that allows users to define an application's name, command, icon, category, and other properties without manually editing the plain-text <i>.desktop</i> file. It simplifies the process of making applications accessible and discoverable within the GNOME shell.<br><br>While widely used in older GNOME versions, its direct command-line invocation for users might be less common or replaced by integrated desktop features in newer releases, such as contextual menus in file managers or dedicated configuration tools.


title: CAVEATS
content:
This command is primarily a GUI tool and requires a running X server and a GNOME desktop environment. Its functionality has evolved, and in modern GNOME versions, its direct command-line invocation might be deprecated or superseded by <b>gnome-panel-desktop-item-edit</b> or integrated functionalities within the desktop environment itself.


title: USES OF .DESKTOP FILES
content:
<i>.desktop</i> files are a core component of the FreeDesktop.org Desktop Entry Specification, used across various Linux desktop environments (GNOME, KDE, XFCE, etc.) to define application shortcuts. They contain metadata such as the application's name, command to execute, icon path, categories, and whether it should run in a terminal. They are crucial for populating application menus, desktop launchers, and enabling file associations.


title: HISTORY
content:
Part of the <i>gnome-panel</i> package, this tool was common in older GNOME 2.x and early GNOME 3.x series for user-friendly desktop file management. With the transition to GNOME Shell and greater integration of functionality into the file manager (Nautilus) and other system components, its direct command-line usage has become less prominent, and its specific function might be superseded by other tools or direct GUI interactions.


title: SEE ALSO
content:
desktop-file-install(1), update-desktop-database(1), xdg-open(1), gio(1), gnome-panel-desktop-item-edit(1)


title: PARAMETERS
content:
<b><I>image_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the disk image file that <b>gnome-disk-image-mounter</b> should open and prompt to mount. This can be an ISO, a raw disk image (.img, .bin), or other supported virtual disk formats.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits. This is a common option for many GTK/GLib applications, though not always explicitly detailed in manual pages for helper binaries.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information of the <b>gnome-disk-image-mounter</b> utility and exits. Also a common option for GTK/GLib applications.<br><br>


title: DESCRIPTION
content:
<b>gnome-disk-image-mounter</b> is a helper application for the GNOME desktop environment, specifically designed to facilitate the mounting of various disk image formats. It acts as an intermediary, allowing users to easily open and mount images like ISO files, raw disk images (.img, .bin), or other virtual disk formats directly from the file manager or by invoking the command. When an image file is opened with this utility, it typically launches a GNOME Disks dialog, prompting the user for the desired action, such as mounting the image, often read-only, to a temporary location. This utility leverages the <i>udisks2</i> framework for underlying disk management operations, providing a user-friendly graphical interface on top of powerful command-line tools. It simplifies the process of accessing content within disk images without needing to manually use low-level `mount` or `losetup` commands.


title: CAVEATS
content:
<b>gnome-disk-image-mounter</b> is primarily a graphical user interface helper. It has limited command-line functionality beyond specifying the image file. All interactive choices and actual mounting operations are handled by the <i>gnome-disks</i> application and the underlying <i>udisks2</i> service, which it relies upon heavily. Direct control over mount options (like filesystem type, read-write access, specific mount points) is typically done through the graphical dialog presented by <i>gnome-disks</i>.


title: HISTORY
content:
<b>gnome-disk-image-mounter</b> is an integral part of the <i>gnome-disk-utility</i> project, which has evolved over time to provide comprehensive disk management capabilities within the GNOME desktop environment. Its development is closely tied to the broader GNOME ecosystem's commitment to user-friendly system administration tools. The utility emerged as a dedicated helper for handling disk images, providing seamless integration with the file manager and the <i>gnome-disks</i> application, leveraging the <i>udisks2</i> backend for modern disk management, especially since the GNOME 3 era. Its core purpose is to abstract the complexities of manual loop device setup and mounting commands, simplifying the process for end-users.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with available command-line options.<br><br><b><b>--help-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all available help options, including GTK-specific ones.<br><br><b><b>--help-gtk</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help specifically for GTK (Graphical Toolkit) options.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for the graphical interface.<br><br><b><b>--block-device=</b><i>BLOCK_DEVICE_PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the graphical interface and navigates directly to the specified block device (e.g., <i>/dev/sda</i> or <i>/dev/nvme0n1</i>).<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the `gnome-disks` utility.<br><br><b><b>--restore-and-exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Internal option used to restore a backup and then exit. This typically requires root privileges and is not for general user interaction.<br><br>


title: DESCRIPTION
content:
`gnome-disks` (also known as <i>Disks</i>) is the default disk utility for the GNOME desktop environment. It provides a user-friendly graphical interface for managing storage devices, including hard drives, SSDs, and removable media. Users can perform various operations such as creating, deleting, and resizing partitions; formatting disks with different file systems (e.g., ext4, NTFS, FAT32); and checking disk health using SMART (Self-Monitoring, Analysis, and Reporting Technology) data.<br><br>The utility also allows for mounting and unmounting file systems, creating and restoring disk images, and performing read/write benchmarks to assess disk performance. While `gnome-disks` offers powerful capabilities, operations like partitioning and formatting require administrative privileges and should be exercised with caution to prevent data loss. It simplifies complex disk management tasks that would otherwise require using multiple command-line tools.


title: CAVEATS
content:
`gnome-disks` is primarily a graphical application; its command-line usage is limited to basic invocations and specifying a target device.<br>Operations involving disk partitioning, formatting, or filesystem creation can lead to irrevocable data loss if not performed carefully. Always back up critical data before making changes to disk layouts.<br>Many powerful features require administrative (root) privileges.


title: <I>GRAPHICAL USER INTERFACE (GUI)</I>
content:
`gnome-disks` provides a user-friendly graphical interface, making complex disk management tasks accessible to users without extensive command-line knowledge. Its visual representation of disk layouts simplifies partitioning and formatting operations.


title: <I>SMART MONITORING</I>
content:
The utility integrates SMART (Self-Monitoring, Analysis, and Reporting Technology) capabilities, allowing users to monitor the health and reliability status of their hard drives and SSDs, detecting potential issues before data loss occurs.


title: <I>DISK BENCHMARKING</I>
content:
Users can perform read and write benchmarks on their storage devices directly within `gnome-disks` to measure performance, helping to diagnose slow drives or compare different storage solutions.


title: <I>DISK IMAGE MANAGEMENT</I>
content:
`gnome-disks` offers features to create exact disk images (backups) of partitions or entire drives and restore them, providing a convenient way to clone disks or recover systems.


title: HISTORY
content:
`gnome-disks` is the successor to <i>Palimpsest</i>, which was also known as `gnome-disk-utility`. It has been a core part of the GNOME desktop environment's system tools, continuously developed to provide an intuitive and powerful graphical interface for managing storage devices, evolving with the GNOME project's design principles.


title: SYNOPSIS
content:
<I>gnome-extensions</I> &lt;command&gt; [arguments...] <br><I>gnome-extensions</I> [--version] [--help]


title: PARAMETERS
content:
<b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed GNOME Shell extensions, showing their names, UUIDs, and current status (enabled/disabled).<br><br><b>info <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific extension identified by its <I>UUID</I> (Universally Unique Identifier).<br><br><b>show <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for the <I>info</I> subcommand, providing detailed information about an extension.<br><br><b>enable <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a specified extension. The extension must be installed and identified by its <I>UUID</I>.<br><br><b>disable <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables a specified extension. The extension must be installed and identified by its <I>UUID</I>.<br><br><b>install <FILE|URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a new extension from a local ZIP <I>FILE</I> path or a direct <I>URL</I> to an extension package.<br><br><b>uninstall <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed extension from the system, identified by its <I>UUID</I>.<br><br><b>prefs <UUID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the graphical preferences dialog for the specified extension, if it provides one. This command typically launches a new window.<br><br><b>reset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the state of all GNOME Shell extensions, typically disabling them or reverting to default settings.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <I>gnome-extensions</I> command-line tool.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message with available commands and options.<br><br>


title: DESCRIPTION
content:
`gnome-extensions` is a powerful command-line utility designed for managing <I>GNOME Shell extensions</I>. It provides a comprehensive interface for users to interact with their installed extensions without needing the graphical "Extensions" application or `gnome-tweaks`. This tool is indispensable for system administrators, developers, and users who prefer terminal-based workflows or wish to script extension management tasks.<br><br>It allows operations such as listing all installed extensions, enabling or disabling specific ones, viewing detailed information, and even installing new extensions from local files or URLs. Furthermore, it supports uninstalling extensions and opening their preferences dialogs directly. Its capabilities make it crucial for automating desktop setup, troubleshooting extension conflicts, or integrating extension control into larger system management scripts. It directly interfaces with the GNOME Shell's extension system, providing a robust and efficient way to control the behavior and appearance of the desktop environment.


title: CAVEATS
content:
<B>Session Requirement</B>: Most operations like enabling, disabling, or opening preferences require a running GNOME Shell session. Changes might not take effect immediately without a Shell restart or log out/in.<br><br><B>Compatibility</B>: Extensions are tied to specific GNOME Shell versions. An extension designed for one version might not work correctly or at all on a different version.<br><br><B>Security Risk</B>: Installing extensions from untrusted sources via the <I>install</I> subcommand can pose a security risk, as extensions run with user permissions and can potentially access user data or modify the system.<br><br><B>UUID Volatility</B>: While UUIDs are stable for officially published extensions, locally developed or unofficial extensions might have varying UUIDs or conflicts if not managed carefully.


title: <B>EXTENSION UUIDS</B>
content:
Each GNOME Shell extension is uniquely identified by a <I>UUID</I> (Universally Unique Identifier). This identifier is typically found in the extension's `metadata.json` file. Commands like <I>info</I>, <I>enable</I>, <I>disable</I>, and <I>uninstall</I> require this UUID to target the correct extension.


title: <B>OFFICIAL EXTENSIONS WEBSITE</B>
content:
The primary official source for GNOME Shell extensions is <I>extensions.gnome.org</I>. This website allows users to browse, install, and manage extensions directly through a web browser, often complementing the <I>gnome-extensions</I> command for graphical interaction.


title: HISTORY
content:
The `gnome-extensions` command-line tool emerged as a dedicated interface for managing <I>GNOME Shell</I> extensions, reflecting the growing importance and complexity of the extension ecosystem. Initially, users primarily managed extensions through the official <I>GNOME Extensions</I> website or the graphical <I>GNOME Tweaks</I> application. As the need for more programmatic and automated control grew, `gnome-extensions` was developed, providing a consistent command-line API. It became an integral part of the <I>gnome-shell</I> package or its related utilities, evolving to support new features and address the nuances of extension management across different GNOME Shell versions. Its development underscored the shift towards providing robust CLI tools for desktop environment configuration.


title: SYNOPSIS
content:
<b>gnome-keyring-daemon</b> [<i>OPTIONS</i>]<br><b>gnome-keyring-daemon</b> [<b>--start</b> | <b>--replace</b> | <b>--foreground</b> | <b>--daemonize</b>]<br><b>gnome-keyring-daemon</b> <b>--components</b>=<i>COMPONENTS</i>


title: PARAMETERS
content:
<b>--start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes and starts the daemon instance.<br><br><b>--replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops any running daemon instance and starts a new one.<br><br><b>--foreground</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the daemon in the foreground; useful for debugging, as it won't fork to the background.<br><br><b>--daemonize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forks the daemon process into the background (this is often the default behavior if no other mode is specified).<br><br><b>--components=COMPONENTS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which internal keyring components or services the daemon should activate (e.g., 'secrets,ssh,gpg,pkcs11').<br><br><b>--unlock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used internally to trigger the unlocking of a keyring. Not typically invoked directly by users.<br><br><b>--display=DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to connect to, usually determined automatically by the session manager.<br><br><b>--login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special internal option used during initial user login setup.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the daemon and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message with available options and exits.<br><br>


title: DESCRIPTION
content:
<i>gnome-keyring-daemon</i> is a crucial background service within the GNOME desktop environment, acting as the central component of the GNOME Keyring system.<br><br>Its primary function is to securely store and manage various security credentials for the user, including passwords, cryptographic keys (like SSH keys), certificates, and other sensitive information. By encrypting these secrets, typically with the user's login password, it provides a secure vault that applications can access.<br><br>The daemon aims to offer a single point of authentication for multiple applications. Instead of each application prompting for its own password, they can retrieve credentials from the keyring after the user has unlocked it (usually during login). This greatly enhances usability and and security.<br><br>It integrates seamlessly with PAM (Pluggable Authentication Modules) to automatically unlock the user's default keyring upon successful session login. Furthermore, it often incorporates functionality similar to <i>ssh-agent</i> and <i>gpg-agent</i>, allowing applications to use SSH and GnuPG keys without manual passphrase entry each time.


title: CAVEATS
content:
While <i>gnome-keyring-daemon</i> significantly improves security and usability by centralizing credential management, it has some considerations:<br><br><I>Security Risk</I>: If the user's master password (often synchronized with their login password) is weak, or if the system itself is compromised, the entire keyring contents could be vulnerable.<br><I>Integration Issues</I>: Its proper functioning relies on correct integration with PAM (Pluggable Authentication Modules) and the desktop session manager. Misconfigurations can lead to repeated password prompts or a non-functional keyring.<br><I>Single Point of Failure</I>: If the daemon fails, or if it's unable to unlock, many applications might lose access to their stored credentials, leading to usability issues across the desktop environment.


title: KEYRING COMPONENTS
content:
The <b>--components</b> option allows specifying which internal services the daemon should provide, optimizing resource usage and functionality:<br><I>secrets</I>: Manages generic passwords and secret data for applications (e.g., Wi-Fi passwords, email account passwords).<br><I>ssh</I>: Provides SSH agent functionality, allowing applications to use SSH private keys without repeatedly prompting for passphrases.<br><I>gpg</I>: Provides GnuPG agent functionality, enabling applications to use GnuPG private keys for signing and decryption.<br><I>pkcs11</I>: Provides PKCS#11 integration, allowing the daemon to interface with smart cards and hardware security modules.


title: SECURITY MODEL
content:
The daemon encrypts keyrings stored on disk using strong symmetric encryption algorithms. For the default 'Login' keyring, the encryption key is typically derived from the user's login password, often facilitated by a PAM module. This allows for automatic unlocking of the keyring upon successful graphical session login. Applications interact with the daemon via D-Bus, requesting access to specific secrets. The daemon only provides access to these secrets if it is currently unlocked and the requesting application has appropriate permissions, ensuring a secure communication channel for sensitive data.


title: HISTORY
content:
<i>gnome-keyring-daemon</i> has been an integral part of the GNOME desktop environment since its early versions, evolving to provide a robust and unified security credential management system. Initially, its primary focus was on basic password storage. Over time, its functionality expanded significantly to integrate and often replace standalone agents like <i>ssh-agent</i> and <i>gpg-agent</i>. This development aimed to offer a more seamless and integrated experience for managing various types of cryptographic keys and secrets under a single, user-friendly system, thereby reducing complexity for end-users by centralizing credential management and authentication prompts.


title: PARAMETERS
content:
<b><i>FILE|URL</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files, directories, or URLs to be opened by their associated applications. Multiple items can be specified, separated by spaces.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message about the command and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>gnome-open</b> utility and exits.<br><br>


title: DESCRIPTION
content:
The <b>gnome-open</b> command was a utility designed for the GNOME desktop environment to open files, directories, or URLs with their associated default applications. It functioned by identifying the MIME type of a given file or the protocol of a URL, then launching the corresponding preferred application, much like double-clicking an item in a file manager. For instance, a text file would open in a text editor, an image in an image viewer, and a web address in a browser. While functional and widely used in older GNOME versions (e.g., GNOME 2.x), it has largely been superseded. Modern Linux distributions and desktop environments now primarily use <b>xdg-open</b>, which offers a standardized, cross-desktop method for handling file and URI associations based on XDG (X Desktop Group) specifications. Therefore, <b>gnome-open</b> is considered deprecated, with <b>xdg-open</b> being the recommended replacement.


title: CAVEATS
content:
The <b>gnome-open</b> command is largely deprecated in modern Linux distributions and GNOME versions. It is not always available or might simply be a symbolic link to <b>xdg-open</b>. Users are strongly advised to use <b>xdg-open</b> instead, which provides a more robust, cross-desktop, and standardized way of opening files and URIs. Using <b>gnome-open</b> on systems where it's still present might lead to unexpected behavior or fail to open items correctly if its underlying dependencies have changed or been removed.


title: USAGE EXAMPLES
content:
Here are some common ways to use <b>gnome-open</b> (or its modern equivalent <b>xdg-open</b>):<br><br><i>Open a PDF document:</i><br><b>gnome-open</b> <i>report.pdf</i><br><br><i>Open a website in the default web browser:</i><br><b>gnome-open</b> <i>https://www.example.com</i><br><br><i>Open multiple files simultaneously:</i><br><b>gnome-open</b> <i>~/Photos/vacation.jpg</i> <i>document.txt</i>


title: HISTORY
content:
Originating as a core component of the GNOME desktop environment, <b>gnome-open</b> provided a command-line interface to GNOME's system for associating MIME types with applications. It was widely used during the GNOME 2.x era. As the Linux desktop landscape evolved, the need for cross-desktop compatibility became paramount. This led to the development of XDG (X Desktop Group) specifications, which included a standard for opening files and URIs, implemented by <b>xdg-open</b>. Consequently, <b>gnome-open</b> became obsolete and was gradually phased out or replaced by <b>xdg-open</b> in newer distributions, establishing <b>xdg-open</b> as the de facto standard for this functionality across various desktop environments.


title: PARAMETERS
content:
<b>--replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces any currently running instance of the panel with a new one.<br><br><b>--display=<I>DISPLAY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the specified X display, allowing the panel to be run on a different display.<br><br><b>--disable-force-quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the 'Force Quit' option from the panel's context menu, preventing users from force-quitting applications via the panel's interface.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <b>gnome-panel</b> and then exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message summarizing command usage and options, then exits.<br><br>


title: DESCRIPTION
content:
The <b>gnome-panel</b> command launches the classic GNOME 2 desktop panel, a highly configurable bar that provides essential desktop functionalities. It typically runs at the top or bottom of the screen (or both), serving as a central hub for launching applications, managing windows, monitoring system status, and accessing various applets.<br><br>Features include a main menu (like 'Applications', 'Places', 'System'), a taskbar for open windows, a notification area, and the ability to add custom application launchers and dynamic applets (e.g., clock, weather, system monitors). While largely superseded by <i>GNOME Shell</i> in modern GNOME versions, <b>gnome-panel</b> remains a core component of desktop environments like <i>MATE Desktop</i>, which continues the GNOME 2 paradigm, offering a familiar and efficient user interface for many Linux users.


title: CAVEATS
content:
<b>gnome-panel</b> is primarily associated with the legacy GNOME 2 desktop environment. Modern GNOME versions (GNOME 3 and later) use <i>GNOME Shell</i> as their primary user interface, which integrates the panel functionality differently. While the command may still exist in some distributions for compatibility or specific fallback modes, its direct usage is more common in desktop environments like <i>MATE</i>, which are direct continuations of GNOME 2.


title: USAGE CONTEXT
content:
Typically, <b>gnome-panel</b> is started automatically by the desktop session manager upon user login and is not usually invoked directly by users from the command line for everyday use. It forms the core visual interface of the GNOME 2 (and MATE) desktop, handling desktop-level interactions.


title: GRAPHICAL CONFIGURATION
content:
Configuration of the <b>gnome-panel</b> (e.g., adding/removing applets, changing panel position, creating custom application launchers) is primarily done through its graphical context menus and dedicated configuration dialogs, rather than via command-line arguments. Users interact directly with the panel to customize its appearance and functionality.


title: HISTORY
content:
The <b>gnome-panel</b> was a foundational component of the GNOME 2 desktop, which was the standard GNOME interface from 2002 to 2011. It provided the traditional desktop experience with panels, menus, and applets that many users found intuitive and efficient. With the transition to GNOME 3 and the introduction of <i>GNOME Shell</i> in 2011, the original <b>gnome-panel</b> was phased out in favor of the new design philosophy. However, a significant part of the GNOME 2 codebase, including the panel, was forked to create the <i>MATE Desktop Environment</i>, ensuring its continued development and usage for users who prefer the classic desktop metaphor.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command-line options specific to this application, or general GTK/GNOME options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information for <i>gnome-power-statistics</i>.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the X display to use. This is a common option for graphical GTK/GNOME applications.<br><br>


title: DESCRIPTION
content:
<i>gnome-power-statistics</i> is a graphical utility within the GNOME desktop environment designed to help users monitor and understand their system's power consumption and battery usage. It provides a comprehensive overview of power events and historical data, allowing users to track current power usage trends, visualize discharge rates, and gain insights into which applications or hardware components might be consuming the most power.<br><br>The tool leverages the <i>UPower</i> service as its backend data source, offering a user-friendly interface to inspect battery health, estimated remaining time, and detailed power consumption graphs over various periods, which is crucial for effective power management on laptops and other portable devices, aiding in optimizing settings and extending battery life.


title: CAVEATS
content:
<i>gnome-power-statistics</i> is primarily a graphical user interface (GUI) application; its command-line functionality is limited to launching the application with a few generic options. It requires a running GNOME desktop environment or a compatible desktop that actively uses the <i>UPower</i> service for accurate and up-to-date power data collection. The reliability and detail of the displayed power statistics are directly dependent on the underlying hardware's reporting capabilities and the proper functioning of the <i>UPower</i> service.


title: DATA SOURCE (UPOWER)
content:
All power-related information displayed by <i>gnome-power-statistics</i> is dynamically retrieved from the system's <i>UPower</i> service. <i>UPower</i> functions as a central hub for all power-related data and events, including battery status, device power consumption, and lid states. This standardized interface allows applications like <i>gnome-power-statistics</i> to present accurate and consistent power information to the user.


title: GRAPHICAL INTERFACE AND VISUALIZATION
content:
Unlike many command-line utilities, <i>gnome-power-statistics</i> offers a rich graphical interface featuring interactive charts and graphs. This visual approach significantly enhances user experience, making it intuitive to analyze power consumption trends over time, pinpoint power-hungry components or periods, and understand historical power usage patterns without the need to interpret raw data or complex logs.


title: HISTORY
content:
<i>gnome-power-statistics</i> emerged as a dedicated component for power consumption monitoring within the GNOME ecosystem, having separated this specific functionality from the broader <i>gnome-power-manager</i>. This modularization, coupled with its reliance on the <i>UPower</i> service, enabled a more focused and detailed statistical view of power usage. Its development is intricately linked with the evolution of GNOME's power management stack, moving towards robust, D-Bus based services for comprehensive power control and reporting across the system.


title: PARAMETERS
content:
<b>-a, --activate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Activates the screensaver immediately.</i><br><br><b>-d, --deactivate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Deactivates the screensaver, preventing it from activating.</i><br><br><b>-p, --poke</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>"Pokes" the screensaver, resetting its idle timer to prevent activation for a short period without fully deactivating it.</i><br><br><b>-q, --query</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Queries the screensaver's current state (active or inactive, locked or unlocked) and prints it to standard output.</i><br><br><b>-l, --lock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Locks the screen immediately, regardless of the screensaver's idle status.</i><br><br><b>-w, --wait</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Waits until the screensaver is active before exiting. Useful for scripting.</i><br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the command's version information.</i><br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows a help message and exits.</i><br><br>


title: DESCRIPTION
content:
<b>gnome-screensaver-command</b> is a command-line utility designed to interact with and control the <i>GNOME Screensaver</i> daemon. It provides a programmatic interface to manage the screensaver's state, enabling users to activate, deactivate, or query its status. Furthermore, it allows for immediate screen locking. This tool is particularly valuable in scripting environments, allowing for automated screen locking before leaving a workstation, preventing screensaver activation during presentations, or simply checking if the screen is currently locked. It relies on the <i>gnome-screensaver</i> process running in the background for its operations. While it was a core component of older GNOME desktop environments, its functionality has largely been integrated into <i>gnome-shell</i> and <i>systemd-logind</i> in more recent GNOME versions.


title: CAVEATS
content:
<i>This command requires the <I>gnome-screensaver</I> daemon to be running. In modern GNOME environments (GNOME 3 and later), screen locking and screensaver management are often handled by <I>gnome-shell</I> itself or <I>systemd-logind</I>, potentially rendering <B>gnome-screensaver-command</B> less relevant or even non-functional depending on the specific system configuration and installed components.</i>


title: <B>D-BUS COMMUNICATION</B>
content:
<i><B>gnome-screensaver-command</B> operates by communicating with the <I>gnome-screensaver</I> daemon using D-Bus, a message bus system. This allows it to send requests and receive status updates from the running daemon.</i>


title: <B>MODERN GNOME INTEGRATION</B>
content:
<i>For users of contemporary GNOME desktops, <I>gnome-shell</I> provides native screen locking and idle management. The <B>loginctl</B> command from <I>systemd</I> (e.g., <I>loginctl lock-session</I>) is often the preferred command-line method for session locking, interacting with the underlying <I>systemd-logind</I> service.</i>


title: HISTORY
content:
<i>The <I>gnome-screensaver</I> project, including <B>gnome-screensaver-command</B>, was a standard feature of the GNOME 2 desktop environment, providing integrated screen locking and screensaver capabilities. With the advent of GNOME 3 and the <I>gnome-shell</I>, much of this functionality was absorbed directly into the shell's codebase and integrated with <I>systemd</I>'s <I>logind</I> service. Consequently, while <B>gnome-screensaver-command</B> might still exist for backward compatibility on some systems, its direct role has diminished, with newer methods often preferred for screen management.</i>


title: PARAMETERS
content:
<b>--window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures a screenshot of the currently focused <i>window</i>.<br><br><b>--area</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the user to select a rectangular <i>area</i> of the screen to capture.<br><br><b>--full-screen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Captures a screenshot of the entire <i>screen</i> (default behavior if no capture type is specified).<br><br><b>--delay=SECONDS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a <i>delay</i> in seconds before the screenshot is taken, allowing time to set up the screen.<br><br><b>--clipboard</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies the screenshot directly to the system <i>clipboard</i> instead of saving to a file.<br><br><b>--file=FILENAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the screenshot to the specified <i>FILENAME</i>. If not provided, a default name will be used (e.g., 'Screenshot from YYYY-MM-DD.png').<br><br><b>--no-border</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the <i>border</i> of a window when capturing a window screenshot. Only applicable with <i>--window</i>.<br><br><b>--no-shadow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the <i>shadow</i> effect around a window when capturing a window screenshot. Only applicable with <i>--window</i>.<br><br><b>--no-cursor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides the mouse <i>cursor</i> from the captured screenshot.<br><br><b>--interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the graphical user interface to <i>interactively</i> choose screenshot options and settings.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>version</i> information of the <i>gnome-screenshot</i> command.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a <i>help</i> message with available command options.<br><br>


title: DESCRIPTION
content:
<i>gnome-screenshot</i> is a command-line utility designed for taking screenshots within the <b>GNOME</b> desktop environment.<br><br>It offers various options for capturing the entire <b>screen</b>, a specific <b>window</b>, or a selected <b>area</b>. Users can specify a <b>delay</b> before the screenshot is taken, include or exclude the mouse <b>pointer</b>, and apply visual <b>effects</b> like borders or shadows. The captured image can be saved directly to a <b>file</b>, copied to the system <b>clipboard</b>, or even initiated via an <b>interactive</b> graphical interface. It serves as the primary backend for the 'Print Screen' key functionality in <b>GNOME</b>.


title: CAVEATS
content:
<i>gnome-screenshot</i> is tightly integrated with the <b>GNOME</b> desktop environment. While it might function on other X11-based desktops, its full capabilities and optimal performance are guaranteed within <b>GNOME</b>. It requires an active X session and does not provide advanced image editing functionalities.


title: DESKTOP ENVIRONMENT INTEGRATION
content:
<i>gnome-screenshot</i> is commonly bound to the 'Print Screen' key on <b>GNOME</b> desktops for quick access. Combinations like <b>Alt</b> + 'Print Screen' typically capture the active window, and <b>Shift</b> + 'Print Screen' often allows for interactive area selection.


title: DEFAULT SAVING BEHAVIOR
content:
By default, screenshots are saved to the user's 'Pictures' directory (or a similar user-specific image folder). The default filename format usually includes the date and time, for example: 'Screenshot from <i>YYYY-MM-DD HH-MM-SS.png</i>'.


title: HISTORY
content:
<i>gnome-screenshot</i> has been a core utility of the <b>GNOME</b> desktop environment for many years, evolving to offer a user-friendly and integrated approach to screen capturing. Its development is aligned with the <b>GNOME</b> project's philosophy of simplicity and seamless desktop integration, serving as the modern replacement for older, less integrated screenshot methods within the <b>GNOME</b> ecosystem.


title: SEE ALSO
content:
scrot(1): A simple command-line screenshot utility., import(1): From ImageMagick, a powerful utility for capturing and manipulating images from the X server., xwd(1): An X Window System window dump utility, providing basic screen capture.


title: PARAMETERS
content:
<b><b>--session</b>=<I>SESSION_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which GNOME session to load. Session names correspond to <I>.session</I> files, e.g., <I>gnome</I> or <I>gnome-classic</I>.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output to assist with troubleshooting session startup issues.<br><br><b><b>--systemd-session</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <I>gnome-session</I> to use <I>systemd</I> for managing the user session services, which is the default and recommended method in modern GNOME.<br><br><b><b>--disable-acceleration-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses the check for 3D acceleration. Useful for testing or environments where acceleration is unavailable or problematic.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>gnome-session</I> package and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message with available command-line options and exits.<br><br>


title: DESCRIPTION
content:
The <b>gnome-session</b> command is the core session manager for the GNOME desktop environment. Its primary function is to launch and manage the essential components that constitute a GNOME user session, including the window manager (Mutter), the GNOME Shell, various background services, and autostart applications. It typically gets invoked automatically by a display manager like GDM upon successful user login. <br><br><b>gnome-session</b> is responsible for reading session configuration from files such as those in <I>/usr/share/gnome-session/sessions</I>, <I>/etc/xdg/autostart</I>, and <I>~/.config/autostart</I>, ensuring that the correct desktop experience is initialized. It also oversees the proper shutdown and logout sequence, attempting to gracefully terminate applications and services. In modern GNOME, it heavily leverages <I>systemd</I> for user session management and <I>D-Bus</I> for inter-process communication, making it a critical component for both X11 and Wayland-based GNOME sessions.


title: CAVEATS
content:
<b>gnome-session</b> is primarily invoked by display managers like GDM and is not typically run manually by users. Direct invocation can lead to unexpected behavior if the environment is not properly set up. It relies heavily on <I>systemd</I> user units and <I>D-Bus</I> for its functionality, and issues with these underlying components can prevent a successful session startup. Custom <I>.xsessionrc</I> files or environment variables can also impact its behavior, sometimes unintentionally.


title: SESSION CONFIGURATION FILES
content:
<b>gnome-session</b> determines which applications and services to start by reading configuration files from several locations. These include <I>/usr/share/gnome-session/sessions/</I> (defining session types), <I>/usr/share/xsessions/</I> (for X session definitions), and particularly <I>/etc/xdg/autostart/</I> and <I>~/.config/autostart/</I>, which contain <I>.desktop</I> files specifying applications to launch automatically at session startup. Administrators and users can customize their sessions by modifying or adding files in these directories.


title: ENVIRONMENT VARIABLES
content:
The behavior of <I>gnome-session</I> and the applications it launches can be influenced by various environment variables. For instance, <I>DISPLAY</I> is crucial for X11 sessions, while variables like <I>XDG_CURRENT_DESKTOP</I> provide hints to applications about the current desktop environment. Users can set these variables in files like <I>~/.xsessionrc</I> or through display manager configuration to affect the session's startup environment.


title: HISTORY
content:
The <I>gnome-session</I> command has been a fundamental part of the GNOME project since its early days in the late 1990s, evolving from a simple X session manager into a sophisticated desktop session orchestrator. Its development has closely mirrored the progression of the GNOME desktop itself. Significant milestones include deeper integration with <I>D-Bus</I> for application communication, and more recently, a pivotal shift to using <I>systemd</I> for managing user session services. This latter change was crucial for streamlining startup, shutdown, and resource management, especially with the advent of Wayland as the default display protocol.


title: SYNOPSIS
content:
gnome-session-inhibit [OPTIONS] COMMAND [ARGUMENTS...]<br><br>gnome-session-inhibit [OPTIONS] --inhibit-only


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--app-id=ID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the application ID associated with the inhibition request. This can be used by session managers or other tools to identify the source of the inhibition.<br><br><b>--reason=REASON</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a human-readable reason for the inhibition. This message might be displayed to the user if a session action is prevented.<br><br><b>--inhibit=FLAGS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a colon-separated list of session actions to inhibit. Available flags include:<br><I>logout</I>: Prevent user logout.<br><I>idle</I>: Prevent automatic idle actions (e.g., screen blanking, locking).<br><I>suspend</I>: Prevent system suspension.<br><I>switch</I>: Prevent user switching.<br><I>reboot</I>: Prevent system reboot.<br><I>shutdown</I>: Prevent system shutdown.<br><br><b>--inhibit-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <I>gnome-session-inhibit</I> to inhibit the specified actions indefinitely (or until interrupted, e.g., by Ctrl+C), without running an external command.<br><br>


title: DESCRIPTION
content:
<I>gnome-session-inhibit</I> is a command-line utility used to prevent specific actions from occurring in the GNOME desktop session while a command is running. These actions can include suspending the system, locking the screen due to idle activity, logging out, or switching users. It's particularly useful for applications that require uninterrupted operation, such as playing videos, burning optical discs, or performing long-running computations. The command works by running a specified program; as long as this program is active, the requested session inhibitions remain in effect. Once the program exits, the inhibitions are automatically released, and the GNOME session can resume its normal behavior. This mechanism ensures that critical tasks are not interrupted by automatic power-saving features or user-initiated session changes.


title: CAVEATS
content:
<I>gnome-session-inhibit</I> requires a running GNOME session and relies on the GNOME session manager (and underlying systemd-logind or similar services) to honor the inhibition requests.<br><br>Inhibitions are advisory. A privileged user or system service can override these requests, for example, through direct D-Bus calls or system-level power management commands.<br><br>The inhibition is typically released automatically when the <B>COMMAND</B> executed by <I>gnome-session-inhibit</I> exits. If the command crashes or is forcefully terminated without proper cleanup, the inhibition might persist briefly or require manual intervention.


title: COMMON USE CASES
content:
This command is frequently used by applications such as media players (to prevent screen blanking or suspend during playback), burning software (to ensure uninterrupted writing processes), and long-running backup or conversion tools. Users can also manually use it to prevent idle-related actions during a long download or compilation.


title: INHIBITION FLAGS EXPLAINED
content:
The `--inhibit` flag accepts a colon-separated list of specific session actions to prevent. Understanding these flags is key to effective use:<br><br><I>idle</I>: Stops the session manager from taking actions due to user inactivity (e.g., screen blanking, locking, dimming).<br><I>suspend</I>: Prevents the system from entering a suspend (sleep) state due to inactivity or automatic power management policies.<br><I>logout</I>: Blocks the user from logging out of the session.<br><I>switch</I>: Prevents switching to another user session.<br><I>reboot</I>: Prevents the system from rebooting (relevant in some integrated desktop scenarios).<br><I>shutdown</I>: Prevents the system from shutting down.


title: HISTORY
content:
<I>gnome-session-inhibit</I> has been a crucial part of the GNOME desktop environment's session management toolkit for many years. Its development is tied to the evolution of desktop environments needing robust ways for applications to signal critical states, preventing interruptions from automatic session management features. It serves as a user-friendly command-line wrapper for the underlying D-Bus interfaces provided by the GNOME session manager and systemd-logind, simplifying the process of requesting temporary session inhibitions for developers and advanced users alike. It ensures a smoother user experience by allowing applications to declare their need for uninterrupted operation.


title: SYNOPSIS
content:
<b><br>gnome-session-properties<br></b><br>This command is primarily a graphical utility and is invoked without additional command-line arguments to launch its user interface.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>gnome-session-properties</i> is designed as a graphical application and typically does not accept command-line parameters to modify its behavior. It launches a user interface for managing startup applications.<br><br>


title: DESCRIPTION
content:
<br><i>gnome-session-properties</i> is a graphical utility within the GNOME desktop environment used to manage applications that start automatically when a user logs in. It provides a user-friendly interface for adding, removing, and editing startup programs, scripts, or commands. Users can easily control which applications launch with their GNOME session, helping to optimize system performance and customize their desktop experience. This tool primarily interacts with the <i>.desktop</i> files located in the user's <i>~/.config/autostart/</i> directory, adhering to the FreeDesktop.org Autostart specification. It is an essential component for personalizing the GNOME startup process.


title: CAVEATS
content:
This utility is specific to the <i>GNOME</i> desktop environment and may not be available or function correctly on other Linux desktop environments (e.g., KDE Plasma, XFCE, MATE).<br>It manages user-specific autostart entries, not system-wide applications or services configured via tools like <i>systemd</i>.


title: CONFIGURATION FILES LOCATION
content:
<i>gnome-session-properties</i> manages startup entries by creating, modifying, or deleting <i>.desktop</i> files in the user's configuration directory. These files are typically located at: <i>~/.config/autostart/</i><br>Each <i>.desktop</i> file represents an application or command that will be launched automatically during the GNOME session startup.


title: HISTORY
content:
<i>gnome-session-properties</i> has been a staple utility within the GNOME desktop environment for many years, dating back to GNOME 2. Its function has remained consistent: providing a user-friendly graphical interface to manage per-user startup applications. While the underlying GNOME technologies and appearance have evolved significantly through GNOME 3 and subsequent versions, the role of this command has persisted as a key tool for customizing the session startup.


title: SYNOPSIS
content:
gnome-session-quit [OPTIONS]<br><br><I>Common options:</I><br>&nbsp;&nbsp;&nbsp;&nbsp;--logout<br>&nbsp;&nbsp;&nbsp;&nbsp;--power-off<br>&nbsp;&nbsp;&nbsp;&nbsp;--reboot<br>&nbsp;&nbsp;&nbsp;&nbsp;--shutdown<br>&nbsp;&nbsp;&nbsp;&nbsp;--suspend<br>&nbsp;&nbsp;&nbsp;&nbsp;--force<br>&nbsp;&nbsp;&nbsp;&nbsp;--no-prompt


title: PARAMETERS
content:
<b>--logout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a logout of the current GNOME user session. This is the default action if no other action is specified.<br><br><b>--power-off</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Commands the system to power off completely.<br><br><b>--reboot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Commands the system to restart.<br><br><b>--shutdown</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for the <I>--power-off</I> option, also commanding the system to power off.<br><br><b>--suspend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the system to enter a suspend (sleep) state.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the specified action immediately, bypassing any blocking applications and the confirmation dialog.<br><br><b>--no-prompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the display of the graphical confirmation dialog, proceeding directly with the action.<br><br>


title: DESCRIPTION
content:
gnome-session-quit is a command-line utility used within the <I>GNOME desktop environment</I> to initiate various session termination actions. It allows users to <B>log out</B> of their current session, <B>shut down</B> the computer, <B>reboot</B> it, or <B>suspend</B> it. Unlike direct system commands (e.g., <I>shutdown</I>, <I>reboot</I>), <I>gnome-session-quit</I> interacts with the <I>GNOME session manager</I> and <I>PolicyKit</I> to gracefully handle application closures and ensure proper system state transitions. It typically presents a graphical confirmation dialog, giving applications a chance to save unsaved work. Options are available to bypass this prompt or forcefully terminate applications. This command is an integral part of the user experience, providing a consistent and user-friendly way to manage the session lifecycle.


title: CAVEATS
content:
This command is designed for the <I>GNOME desktop environment</I> and relies on its session manager. It may not function correctly or at all in other desktop environments or if GNOME components are not running.<br>It uses <I>D-Bus</I> for communication with the session manager and underlying system services. If D-Bus is not operational, the command will fail.<br>System-wide actions like power-off, reboot, and suspend require appropriate privileges, typically handled by <I>PolicyKit</I> and <I>systemd-logind</I>. If these services are misconfigured or unavailable, these actions might fail or require root privileges.<br>Applications can potentially block the quit action until they are closed or the <I>--force</I> option is used.


title: INTERACTION WITH D-BUS AND POLICYKIT
content:
<I>gnome-session-quit</I> does not directly execute power commands like <I>shutdown</I> or <I>reboot</I>. Instead, it communicates with the GNOME session manager (often <I>gnome-session</I>) via <I>D-Bus</I>. The session manager then, in turn, interacts with underlying system services like <I>systemd-logind</I> (using <I>PolicyKit</I> for privilege escalation if needed) to perform the actual system-wide power operations. This indirect method ensures proper authorization, integration with system services, and graceful handling of active sessions.


title: GRAPHICAL USER INTERFACE (GUI) VS. COMMAND LINE
content:
While <I>gnome-session-quit</I> is a command-line tool, its primary design intent is often to back the graphical "Log Out", "Shut Down", or "Restart" options found in the GNOME desktop's user menu. When invoked without <I>--no-prompt</I> or <I>--force</I>, it typically displays the same graphical dialog box seen when initiating a quit action through the GUI. This consistency ensures a unified user experience regardless of the invocation method.


title: HISTORY
content:
The <I>gnome-session-quit</I> command has been a staple of the <I>GNOME desktop environment</I> since its early versions, evolving alongside the desktop itself. Initially, its functionality might have been more directly tied to X-server termination. Over time, as Linux systems adopted <I>systemd</I> and its <I>logind</I> component, the command's role shifted to primarily interact with the GNOME session manager, which then delegates the actual system-level power operations to <I>logind</I> via <I>D-Bus</I> and <I>PolicyKit</I>. This layered approach ensures consistency, proper privilege management, and integration with modern Linux system architecture, providing a robust and secure way to manage the user's session lifecycle.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of available command-line options and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output, useful for troubleshooting issues.<br><br><b>--no-daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the daemon from forking into the background, keeping it in the foreground for interactive debugging.<br><br>


title: DESCRIPTION
content:
gnome-settings-daemon is a fundamental background process within the GNOME desktop environment. Its primary role is to manage and apply various system and user-specific settings, ensuring the desktop behaves according to the user's preferences. It acts as a central hub, listening for D-Bus signals from applications like gnome-control-center or gsettings, and then translating these requests into actual system configurations. This includes handling display settings (resolution, multi-monitor setups), power management, keyboard layouts and shortcuts, mouse sensitivity, network proxy configurations, sound output, media keys, and much more. By consolidating these functions, gnome-settings-daemon provides a cohesive and responsive user experience, allowing dynamic changes to desktop behavior without requiring a session restart. It utilizes a modular plugin architecture, with each plugin responsible for a specific set of settings, making it extensible and efficient.


title: CAVEATS
content:
gnome-settings-daemon is designed to run automatically as part of the GNOME session startup and is generally not intended for direct manual invocation by end-users. Incorrect manual invocation or termination can lead to an unresponsive or improperly configured GNOME desktop. It relies heavily on the D-Bus message bus system for inter-process communication, so issues with D-Bus can significantly affect its functionality.


title: CORE FUNCTIONALITY
content:
The daemon manages a diverse set of desktop behaviors through its various plugins, including display configuration (resolution, orientation), power management policies, input device settings (keyboard layouts, mouse acceleration), sound output and input, network proxy settings, and desktop theme elements.


title: D-BUS INTEGRATION
content:
gnome-settings-daemon communicates extensively via the D-Bus system. Applications and components wanting to change settings (e.g., gnome-control-center) send requests over D-Bus, which the daemon then interprets and applies. Conversely, the daemon can emit signals over D-Bus to notify other applications of settings changes.


title: HISTORY
content:
gnome-settings-daemon evolved as a core component of the GNOME desktop environment, addressing the need for a centralized and dynamic settings management system. Its development paralleled the maturation of GNOME itself, moving towards a more integrated and user-friendly experience. Over time, it adopted a modular plugin architecture and leveraged the D-Bus system to provide robust and responsive handling of a wide array of desktop configurations, becoming indispensable for the modern GNOME session.


title: SYNOPSIS
content:
<b>gnome-software</b> <i>[OPTIONS...]</i> <i>[URI...]</i><br><br><i>Common usage:</i><br><b>gnome-software</b><br><br><i>Less common for CLI package management:</i><br><b>gnome-software</b> <i>--install</i> &lt;package-name&gt;<br><b>gnome-software</b> <i>--uninstall</i> &lt;package-name&gt;<br><b>gnome-software</b> <i>--update</i>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help options and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>--install <package-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the GUI to install the specified package. This action usually requires user confirmation within the graphical interface.<br><br><b>--uninstall <package-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the GUI to uninstall the specified package. This action usually requires user confirmation within the graphical interface.<br><br><b>--details <package-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the GUI to show detailed information for the specified package.<br><br><b>--update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the GUI to check for and apply system and application updates.<br><br><b>--quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quit a running instance of <b>gnome-software</b>.<br><br><b>--url <URI></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a specific AppStream URI or other supported URI within the software center (e.g., <i>appstream:///application/firefox.desktop</i>).<br><br>


title: DESCRIPTION
content:
<b>gnome-software</b> is the official software center for the GNOME desktop environment. It provides a user-friendly graphical interface for managing all aspects of software on a Linux system.<br><br>Users can browse, search for, install, and remove applications from various sources including traditional distribution packages (like APT/RPM), Flatpak, Snap, and AppImage. Beyond applications, it also handles system updates, firmware updates, GNOME Shell extensions, and fonts.<br><br>It aims to simplify software management, making it accessible to users without requiring command-line knowledge, while also integrating with system update notifications.


title: CAVEATS
content:
The command-line interface for <b>gnome-software</b> is primarily designed to launch the graphical application or direct it to a specific action, which often still involves opening the GUI and requiring user interaction. For automated or script-based package management, it is generally recommended to use the native package manager for your distribution (e.g., <b>apt</b>, <b>dnf</b>, <b>zypper</b>), or dedicated commands for Flatpak (<b>flatpak</b>) and Snap (<b>snap</b>).


title: INTEGRATION WITH APPSTREAM
content:
<b>gnome-software</b> heavily relies on the AppStream metadata project, which provides rich, standardized application metadata (descriptions, screenshots, categories) for software available across Linux distributions. This allows for a much richer browsing and discovery experience within the software center.


title: BACKEND INDEPENDENCE
content:
While it presents a unified front-end, <b>gnome-software</b> utilizes various backends (e.g., PackageKit, Flatpak, Snapd, fwupd) to interact with different packaging systems and update mechanisms. This modular design allows it to support a wide range of software sources seamlessly.


title: HISTORY
content:
<b>gnome-software</b> was introduced to unify and simplify software management within the GNOME desktop environment, replacing older, more fragmented tools like 'Add/Remove Programs' or basic update managers. Its development is closely tied to the evolution of the GNOME desktop, aiming to provide a modern, integrated experience for discovering and managing software from various sources, including newer packaging technologies like Flatpak and Snap, which it adopted early on.


title: SYNOPSIS
content:
<b>gnome-ssh-askpass</b> [<i>options</i>]<br><i>Note: Typically invoked automatically by SSH clients when the <b>SSH_ASKPASS</b> environment variable is set, often without explicit arguments. Standard GTK options are supported but rarely used in practice.</i>


title: DESCRIPTION
content:
<b>gnome-ssh-askpass</b> is a graphical utility designed to securely prompt the user for an SSH passphrase in environments where a terminal (TTY) is not available, such as within a graphical desktop session. It serves as a visual alternative to the standard command-line passphrase prompts.<br><br>This tool is typically invoked automatically by SSH clients (like <b>ssh</b> or <b>ssh-add</b>) when they require a passphrase for a key but detect that the <b>DISPLAY</b> environment variable is set (indicating a graphical environment) and the <b>SSH_ASKPASS</b> environment variable points to <b>gnome-ssh-askpass</b>.<br><br>When executed, it displays a modal dialog box asking the user to enter the passphrase for their SSH key. This ensures that sensitive passphrase information is entered directly into a secure GUI prompt rather than being echoed on a potentially compromised terminal or script. It is an integral component of the GNOME desktop's integration with SSH, providing a seamless user experience for managing SSH keys.


title: CAVEATS
content:
<ul><li><b>Graphical Environment Required:</b> <b>gnome-ssh-askpass</b> relies on a graphical display. It will not function in a purely command-line or TTY environment, as it requires the <b>DISPLAY</b> environment variable to be set.</li><li><b>Environment Variable Dependency:</b> Its automatic invocation by <b>ssh</b> or <b>ssh-add</b> depends on the <b>SSH_ASKPASS</b> environment variable being correctly set to the full path of the executable.</li><li><b>Security Context:</b> While providing a secure graphical prompt, users should ensure the desktop environment itself is secure. Always verify the authenticity of the prompt before entering sensitive information.</li></ul>


title: HOW IT WORKS
content:
When <b>ssh</b> or <b>ssh-add</b> needs a passphrase and a TTY is unavailable (e.g., in a background script or a GUI application), it checks the <b>SSH_ASKPASS</b> environment variable. If set, it executes the program specified by this variable, piping the prompt message to its standard input. <b>gnome-ssh-askpass</b> then reads this message, displays a graphical dialog, and returns the entered passphrase to standard output.


title: STANDARD GTK OPTIONS
content:
Like most GNOME applications, <b>gnome-ssh-askpass</b> supports standard GTK toolkit options (e.g., <i>--display</i>, <i>--no-gtkrc</i>, <i>--g-fatal-warnings</i>) which can affect its appearance or behavior, though these are rarely used in its typical automated invocation.


title: HISTORY
content:
<b>gnome-ssh-askpass</b> emerged as part of the GNOME desktop environment's efforts to provide a more integrated and user-friendly experience for common system tasks, including SSH key management. It was developed to offer a graphical alternative to the default terminal-based passphrase prompts, making the process of adding keys to <b>ssh-agent</b> or connecting via SSH more intuitive for users within a desktop session. Its development has mirrored the evolution of the GNOME project itself, ensuring compatibility and aesthetic consistency with the wider desktop environment.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows basic help options for the command.<br><br><b>--help-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available help options, including GTK-specific ones.<br><br><b>--help-gtk</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows standard GTK toolkit options.<br><br><b>-s, --show-processes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the application with the Processes tab active.<br><br><b>-m, --show-memory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts with the Resources tab active and displays the Memory chart.<br><br><b>-c, --show-cpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts with the Resources tab active and displays the CPU chart.<br><br><b>-n, --show-network</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts with the Resources tab active and displays the Network chart.<br><br><b>-f, --show-file-systems</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the application with the File Systems tab active.<br><br><b>--maximize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the <b>gnome-system-monitor</b> window in a maximized state.<br><br><b>--display=DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for running the graphical application.<br><br>


title: DESCRIPTION
content:
<b>gnome-system-monitor</b> is the default system monitoring utility for the GNOME desktop environment. It provides a comprehensive <i>graphical overview</i> of a system's running processes, resource utilization (CPU, memory, network, disk I/O), and mounted file systems.<br><br>Users can view process details, sort processes by various criteria, terminate or suspend processes, and monitor historical resource usage through graphical charts. It's an essential tool for troubleshooting performance issues, identifying rogue applications, and understanding how system resources are being consumed. It offers a user-friendly interface divided into tabs for <i>Processes</i>, <i>Resources</i>, and <i>File Systems</i>, making it accessible to both new and experienced Linux users.


title: CAVEATS
content:
As a graphical application, <b>gnome-system-monitor</b> requires a running X server or Wayland compositor and cannot be used directly from a pure terminal console.<br><br>While highly functional, its own resource consumption might be noticeable on extremely low-resource systems. For deeply granular or scriptable monitoring, command-line tools often provide more flexibility.


title: GRAPHICAL INTERFACE
content:
Offers an intuitive point-and-click interface, simplifying complex system monitoring tasks compared to command-line alternatives.


title: PROCESS CONTROL
content:
Enables users to perform actions directly on processes, such as killing, stopping, or changing their priority, directly from the GUI.


title: HISTORICAL CHARTS
content:
Provides valuable graphical charts for CPU, memory, and network usage over time, helping users identify trends and performance bottlenecks.


title: HISTORY
content:
<b>gnome-system-monitor</b> has been a core component of the GNOME desktop environment since its early versions, providing a user-friendly graphical interface for system statistics. Its development has consistently evolved with the GNOME project, leveraging standard Linux APIs and the <i>/proc</i> filesystem to present real-time system data.


title: SEE ALSO
content:
<i>top(1)</i>, <i>htop(1)</i>, <i>ps(1)</i>, <i>free(1)</i>, <i>df(1)</i>, <i>iotop(8)</i>, <i>ss(8)</i>


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;Display version information and exit.<br><br><b>--window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a new terminal window.<br><br><b>--tab</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a new tab in the last-used window.<br><br><b>--command=<I>COMMAND</I> or --execute=<I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the specified command instead of a shell in the new terminal.<br><br><b>--profile=<I>PROFILE_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the profile to use for the new terminal session.<br><br><b>--geometry=<I>GEOMETRY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the window size and position (e.g., '80x24+100+200').<br><br><b>--zoom=<I>ZOOM_LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial zoom level (e.g., '1.0' for normal, '2.0' for double size).<br><br><b>--working-directory=<I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial working directory for the new terminal.<br><br>


title: DESCRIPTION
content:
<b>gnome-terminal</b> is the default terminal emulator for the <b>GNOME</b> desktop environment, providing a graphical interface to interact with the system's command-line shell. It offers a robust and user-friendly way to execute commands, run scripts, and manage files directly from the desktop.<br><br>Key features include support for multiple tabs within a single window, allowing users to manage several command-line sessions concurrently. It also provides highly customizable profiles, enabling users to define distinct settings for font, color schemes, background, and scrolling behavior. These profiles can be easily switched to suit different tasks or preferences. The terminal supports various standard features like copy/paste, text selection, and search, alongside more advanced capabilities such as URL detection and automatic resizing. It integrates seamlessly with the <b>GNOME</b> environment, making it a powerful and essential tool for developers, system administrators, and regular users alike.


title: CAVEATS
content:
<b>gnome-terminal</b> primarily operates within the <b>GNOME</b> desktop environment. While it can be run standalone, its full feature set, especially regarding profiles and seamless window/tab management, is best experienced within a graphical session. Long-running background processes started directly in <b>gnome-terminal</b> will terminate when the terminal window is closed, unless specifically detached (e.g., using `nohup` or `disown`).


title: PROFILES AND CUSTOMIZATION
content:
<b>gnome-terminal</b>'s strength lies in its customizable profiles. Users can create multiple profiles, each with unique settings for colors (foreground, background, palette), fonts, cursor style, scrollback lines, and even custom commands to run on startup. This allows for tailored environments for different tasks, such as a dark theme for coding or a high-contrast theme for log monitoring. Profiles significantly enhance productivity and user experience.


title: KEYBOARD SHORTCUTS
content:
It supports a wide range of keyboard shortcuts for efficient navigation and control, including creating new tabs (<i>Ctrl+Shift+T</i>), closing tabs (<i>Ctrl+Shift+W</i>), switching between tabs (<i>Ctrl+PgUp</i>/<i>PgDown</i> or <i>Alt+number</i>), and zooming (<i>Ctrl++</i>/<i>-</i>). These shortcuts allow users to perform common actions quickly without relying on mouse input.


title: HISTORY
content:
<b>gnome-terminal</b> has been an integral part of the <b>GNOME</b> desktop environment since its early versions, providing the standard command-line interface for <b>GNOME</b> users. It was developed to offer a more feature-rich and integrated alternative to basic X terminals like `xterm`, aligning with <b>GNOME</b>'s goal of a user-friendly and modern desktop experience. Over the years, it has evolved with the <b>GNOME</b> project, adding features like tabs, profiles, and improved Unicode support, reflecting changes in user needs and underlying system capabilities. Its design prioritizes ease of use and customization, making it a reliable and widely adopted terminal emulator in the Linux ecosystem.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--real-time</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display real (wall-clock) time instead of elapsed time from when <b>gnomon</b> started.<br><br><b><b>-f</b> <i>&lt;FORMAT&gt;</i>, <b>--format</b> <i>&lt;FORMAT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the timestamp format using <i>strftime</i>-like directives. For example, <b>%H:%M:%S</b> for hour:minute:second.<br><br><b><b>-T</b>, <b>--no-time-display</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the display of timestamps, effectively acting as a pass-through filter without any modifications.<br><br><b><b>-c</b> <i>&lt;WHEN&gt;</i>, <b>--color</b> <i>&lt;WHEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control color output. <i>&lt;WHEN&gt;</i> can be <b>always</b>, <b>auto</b>, or <b>never</b>. Defaults to <b>auto</b> based on terminal capabilities.<br><br><b><b>-t</b> <i>&lt;WIDTH&gt;</i>, <b>--term</b> <i>&lt;WIDTH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the terminal width for formatting output. Useful when output is redirected or piped to other tools with specific width requirements.<br><br><b><b>-r</b>, <b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output raw lines without any formatting or timestamping. This is similar to <b>-T</b> but might imply other formatting suppression.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<b>gnomon</b> is a command-line utility designed to prefix timestamps to lines of standard input, then print them to standard output. It is particularly useful for monitoring long-running processes, scripts, or continuous logs where understanding the time elapsed between events or when specific lines appear is crucial.<br><br>By default, <b>gnomon</b> shows the elapsed time since the command started, but it can also display real (wall-clock) time. It supports customizable time formats, colored output, and is often used in pipelines (e.g., <i>make | gnomon</i> or <i>tail -f logfile | gnomon</i>). This helps in debugging, performance analysis, and simply keeping track of progress during lengthy operations, providing a clear chronological context to raw output.


title: CAVEATS
content:
<b>gnomon</b> operates by processing its standard input line by line. This means it is most effective when used in a pipe with another command that generates output continuously or in discrete lines. Very long lines without newlines might be buffered and not timestamped until a newline character is encountered or the process finishes. Its primary role is output adornment and monitoring, not input manipulation or controlling the piped command.


title: COMMON USE CASES
content:
<b>gnomon</b> is frequently used when running build processes (e.g., <i>make | gnomon</i>), long-running tests, or lengthy scripts to observe the time taken for each step, aiding in performance analysis and debugging. It's also invaluable for tailing log files: <i>tail -f /var/log/syslog | gnomon -s</i> will display new log entries with real wall-clock timestamps, providing immediate chronological context.


title: INSTALLATION
content:
While not a core GNU utility, <b>gnomon</b> is widely available through the package managers of most modern Linux distributions (e.g., <i>sudo apt install gnomon</i> on Debian/Ubuntu, <i>sudo dnf install gnomon</i> on Fedora, <i>brew install gnomon</i> on macOS). It can also be installed directly via Rust's package manager with <i>cargo install gnomon</i>, provided Rust and Cargo are set up on the system.


title: HISTORY
content:
<b>gnomon</b> is a relatively modern utility, primarily written in Rust, which aims to provide a fast, robust, and user-friendly way to add timestamps to command output. It emerged as a popular alternative to similar tools like <b>ts</b> from `moreutils`, leveraging Rust's performance and safety features. Its development started gaining traction around 2017-2018, and it has since been included in the package repositories of many popular Linux distributions, becoming a staple for developers and system administrators for its simplicity and effectiveness in monitoring long-running processes.


title: SYNOPSIS
content:
<b>`gnucash`</b> [<i>`OPTIONS`</i>] [<i>`FILE`</i>...]<br><br><i>Common invocation:</i> <b>`gnucash`</b> <i>`my_finances.gnucash`</i><br><br><i>For advanced operations:</i> <b>`gnucash`</b> [<i>`--add-account account_name`</i>] [<i>`--set-value value`</i>] [<i>`--import file`</i>] [<i>`--export file`</i>] [<i>`--update-prices`</i>] [<i>`--update-currency-exchange-rates`</i>] [<i>`--version`</i>] [<i>`--help`</i>]


title: PARAMETERS
content:
<b><i>`FILE`</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens one or more GnuCash data files. If no file is specified, GnuCash typically opens the last used file or presents a new file dialog.<br><br><b><b>`-h`</b>, <b>`--help`</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options and exits.<br><br><b><b>`-v`</b>, <b>`--version`</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the GnuCash version information and exits.<br><br><b><b>`--add-account`</b> <i>`ACCOUNT_NAME`</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches GnuCash and attempts to add a new account with the specified name. This option is primarily intended for scripting or automated tasks.<br><br><b><b>`--set-value`</b> <i>`VALUE`</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used in conjunction with other options (e.g., <b>`--add-account`</b>) to set an initial value. This is part of GnuCash's scripting interface.<br><br><b><b>`--import`</b> <i>`FILE`</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports financial data from the specified file. GnuCash supports various import formats such as QIF, OFX, and CSV.<br><br><b><b>`--export`</b> <i>`FILE`</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports GnuCash data to the specified file. This is generally for advanced or programmatic use, as most export functions are managed within the GUI.<br><br><b><b>`--update-prices`</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to online sources to update stock and mutual fund prices for securities configured in your GnuCash accounts.<br><br><b><b>`--update-currency-exchange-rates`</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to online sources to update currency exchange rates for all configured currencies.<br><br>


title: DESCRIPTION
content:
GnuCash is <i>free</i> and <i>open-source</i> accounting software that helps users manage their finances, track bank accounts, stocks, income, and expenses. It's designed to be easy to use yet powerful, employing professional accounting principles like <b>double-entry bookkeeping</b>. GnuCash can import financial data, generate reports, and schedule transactions, making it suitable for both personal finance management and small business accounting. Its cross-platform nature and robust features make it a popular alternative to commercial financial software.<br><br>The <b>`gnucash`</b> command typically launches the graphical user interface (GUI) of the application, allowing users to interact with their financial data through a rich graphical interface. While primarily a GUI application, it supports command-line arguments for opening specific files, importing data, or triggering updates.


title: CAVEATS
content:
<b>`gnucash`</b> is primarily a <i>graphical application</i>; most of its functionality is accessed through its GUI. The command-line options are mainly for launching the application, opening specific files, or triggering automated updates (like prices/rates).<br><br>For advanced scripting or unattended operations, direct command-line interaction can be complex and may require a deep understanding of GnuCash's internal mechanisms or the use of companion tools or scripts designed for automation.


title: <B><U>DATA STORAGE</U></B>
content:
GnuCash typically stores its financial data in an <i>XML-based format</i> (compressed <b>`.gnucash`</b> files) by default. For more robust data management, especially for larger files or in environments where database features are desired, GnuCash can be configured to use <i>SQLite3</i>, <i>PostgreSQL</i>, or <i>MySQL</i> databases.


title: <B><U>DOUBLE-ENTRY BOOKKEEPING</U></B>
content:
A core principle of GnuCash is its strict adherence to <b>double-entry bookkeeping</b>. Every transaction involves at least two accounts – a source and a destination – ensuring that your books always balance. This fundamental accounting method provides a robust and accurate financial record, making GnuCash suitable for professional accounting needs.


title: <B><U>ONLINE SERVICES INTEGRATION</U></B>
content:
GnuCash can connect to various online services to fetch current stock and mutual fund prices, as well as up-to-date currency exchange rates. This feature enhances the accuracy of portfolio tracking and multi-currency accounting. These updates can be triggered directly from the command line using options like <b>`--update-prices`</b> and <b>`--update-currency-exchange-rates`</b>.


title: HISTORY
content:
GnuCash development began in 1997, with its first stable release in 1998. It was conceived as an open-source alternative to commercial financial software like Intuit's Quicken. From its inception, GnuCash has emphasized adherence to <i>professional accounting principles</i>, notably <b>double-entry bookkeeping</b>, distinguishing it from simpler personal finance managers.<br><br>Over the years, it has continuously evolved, adding features such as stock/mutual fund tracking, QIF/OFX/CSV import, HBCI support, scheduled transactions, and a robust reporting engine. Its commitment to free software principles and robust financial management has fostered a dedicated community and ensured its ongoing development and widespread usage on Linux, macOS, and Windows.


title: SYNOPSIS
content:
<b>gnucash-cli</b> [<i>OPTIONS</i>] <i>COMMAND</i> [<i>ARGUMENTS...</i>]<br>Example: <b>gnucash-cli --file</b> <i>mydata.gnucash</i> <b>report</b> <i>IncomeStatement</i> <b>--output</b> <i>report.html</i>


title: PARAMETERS
content:
<b>--file <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GnuCash data file (e.g., <i>.gnucash</i>) to operate on. This option is almost always required.<br><br><b>--output <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs the output of commands (e.g., reports) to the specified <i>FILE</i> instead of standard output.<br><br><b>--report <i>REPORT_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates the specified GnuCash report by <i>REPORT_NAME</i>. Often used with `<i>--file</i>` and `<i>--output</i>`.<br><br><b>--report-option <i>KEY=VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes specific options to a generated report. Can be used multiple times for different options.<br><br><b>--import <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports transactions from <i>FILE</i>. Supports formats like QIF, OFX, or CSV.<br><br><b>--export <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports data from the GnuCash file in the specified <i>TYPE</i> (e.g., QIF, CSV).<br><br><b>--no-gui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures no GnuCash graphical user interface is launched. This is the default behavior but can be explicitly set.<br><br><b>--log-to-stderr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends log messages to the standard error stream.<br><br><b>--log-level <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity of log messages. <i>LEVEL</i> can be `error`, `warning`, `info`, `debug`, or `trace`.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>gnucash-cli</b> version information and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b><i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific action to perform. Common commands include `<b>report</b>`, `<b>validate</b>`, `<b>check-prices</b>`, `<b>import</b>`, `<b>export</b>`.<br><br><b><i>ARGUMENTS...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional arguments specific to the chosen <i>COMMAND</i>. For example, `<b>report</b>` takes a <i>REPORT_NAME</i> as an argument.<br><br>


title: DESCRIPTION
content:
The <b>gnucash-cli</b> command provides a non-graphical, command-line interface to <b>GnuCash</b>, the popular personal and small-business financial accounting software. It is designed for scripting and automating common tasks without launching the full GnuCash graphical user interface. This includes generating reports, importing and exporting data in various formats (like QIF, OFX, CSV), validating data integrity, and performing other batch operations on your GnuCash financial files. It's particularly useful for users who need to automate financial reporting, integrate GnuCash into other systems, or perform maintenance tasks on their data files via scripts or cron jobs. Unlike the main <b>gnucash</b> application, <b>gnucash-cli</b> is geared towards non-interactive processing, making it an essential tool for advanced users and system administrators.


title: CAVEATS
content:
<b>gnucash-cli</b> operates directly on your GnuCash data file. Always back up your file before performing write operations (e.g., `<b>import</b>` that modifies the file).<br>While powerful, not all GnuCash GUI functionalities are available via the CLI. Complex operations, such as reconciling accounts or setting up new accounts, typically require the graphical interface. Error messages can sometimes be verbose or cryptic, requiring familiarity with GnuCash's internal structure.


title: COMMON CLI COMMANDS
content:
While the <b>synopsis</b> covers the general structure, <b>gnucash-cli</b> relies heavily on specific commands. Some frequently used ones are:<br><b>report</b> <i>&lt;report-name&gt;</i>: Generates a specified GnuCash report (e.g., BalanceSheet, IncomeStatement).<br><b>validate</b>: Checks the integrity of the GnuCash data file for potential errors.<br><b>check-prices</b>: Updates security prices from configured online sources.<br><b>import</b> <i>&lt;file&gt;</i>: Imports data from an external file into the GnuCash book.<br><b>export</b> <i>&lt;type&gt;</i>: Exports data from the GnuCash book in a specified format.


title: HISTORY
content:
The <b>gnucash-cli</b> utility was developed as part of the GnuCash project to address the growing need for batch processing and scripting capabilities. Prior to its introduction, automating tasks within GnuCash often required more complex workarounds or direct interaction with the GUI. Its development aimed to provide a stable and reliable command-line interface, making GnuCash more amenable to integration into larger financial management systems or automated reporting pipelines. It has evolved alongside the main GnuCash application, with new commands and options being added to support expanding functionalities and user requirements for non-interactive financial data management.


title: SYNOPSIS
content:
<I>gnuplot</I> [<B>-p</B>] [<B>-d</B>] [<B>-s</B>] [<B>-V</B>] [<B>-c</B> <I>scriptfile</I> [<I>arg1</I> ...]] [<B>-r</B> <I>scriptfile</I> [<I>arg1</I> ...]] [<B>-e</B> <I>"command list"</I>] [<I>file ...</I>]


title: PARAMETERS
content:
<b>-p, --persist</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Leaves plot windows open after gnuplot exits.<br><br><b>-d, --dump-options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Dumps all current options to stdout.<br><br><b>-e, --execute "command list"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Executes specified gnuplot commands before loading any script files or entering interactive mode. Useful for quick plots or settings.<br><br><b>-s, --synchronous</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Runs gnuplot synchronously, useful when used from shell scripts.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Prints the gnuplot version and exits.<br><br><b>-c, --call <scriptfile> [arg1 ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Executes the specified script file, passing subsequent arguments to it.<br><br><b>-r, --replot-only <scriptfile> [arg1 ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Similar to -c, but primarily for replotting on an existing terminal, often used in conjunction with interactive sessions.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Starts in quiet mode, suppressing startup messages.<br><br>


title: DESCRIPTION
content:
Gnuplot is a portable, command-line driven graphing utility for Linux and other operating systems. It is widely used in scientific and engineering fields to visualize mathematical functions and data interactively or from scripts. Gnuplot supports numerous plot types, including 2D (lines, points, impulses, boxes, error bars, etc.) and 3D (surfaces, contours, splot). It can read data from files, pipe input, or plot functions defined directly. A key feature is its support for a vast array of output terminals, allowing plots to be saved in various formats like PNG, JPEG, SVG, PDF, PostScript, LaTeX, and more, making it suitable for both on-screen viewing and publication-quality graphics. Its scripting capabilities enable complex plot automation, data analysis, and highly customized visualizations.


title: CAVEATS
content:
<B>Steep Learning Curve:</B><br>While powerful, gnuplot's command-line interface and extensive options can be daunting for beginners.<br><B>No Native GUI:</B><br>Gnuplot is not a typical click-and-drag GUI application. All interactions are via commands, though it can open interactive plot windows.<br><B>Data Formatting:</B><br>Requires data to be well-structured (e.g., columns of numbers) or necessitates preprocessing using other tools like <I>awk</I> or <I>sed</I>.


title: SCRIPTING AND AUTOMATION
content:
Gnuplot excels at creating complex, publication-quality plots from scripts. This allows for reproducible analysis, batch processing of data, and highly customized visualizations without manual intervention.


title: OUTPUT TERMINALS
content:
It supports a vast range of output formats ("terminals"), including interactive window systems (x11, wxt, qt), bitmap images (png, jpeg, gif), vector graphics (svg, postscript, pdf, eps), and specialized formats for LaTeX/TeX integration. This flexibility ensures plots can be used in almost any context.


title: INTERACTIVE VS. BATCH MODE
content:
Gnuplot can be used interactively, allowing users to type commands and see plots update in real-time. Alternatively, it can run in batch mode by executing a script file, making it ideal for automated report generation or data processing pipelines.


title: HISTORY
content:
Gnuplot was originally developed in 1986 by Colin Kelley and Thomas Williams. Its name, "gnuplot", was a compromise to avoid conflicts with "newplot" and to acknowledge the GNU Project (though it is not part of the GNU Project itself, nor does it use the GNU General Public License, but rather its own permissive license). It quickly gained popularity in academic and research communities due to its flexibility, portability, and high-quality output capabilities, becoming a de-facto standard for scientific data visualization on Unix-like systems. Development has been continuous, with new features, plot styles, and output terminals added over decades.


title: SEE ALSO
content:
<I>R</I>(1), <I>matplotlib</I> (Python plotting library), <I>awk</I>(1), <I>sed</I>(1), <I>graph</I>(1)


title: PARAMETERS
content:
<b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles packages and dependencies. Creates an executable binary by default.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes object files and cached files from the build cache.<br><br><b>env</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints Go environment information, such as GOPATH, GOROOT, and architecture details.<br><br><b>fmt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats Go source code according to the official Go style guide (gofmt).<br><br><b>get</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a dependency to the current module and installs it. Fetches and installs packages and their dependencies.<br><br><b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles and installs packages and their dependencies. Places compiled binaries in a standard location (e.g., $GOPATH/bin or $GOBIN).<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists packages or modules, including their properties, dependencies, and build contexts.<br><br><b>mod</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides subcommands for managing Go modules, including 'tidy', 'init', 'vendor', and 'graph'.<br><br><b>run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles and runs the main package specified by the arguments. Useful for quick execution of Go programs.<br><br><b>test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs tests for the packages named by the import paths. Supports various options for verbose output, coverage, and specific test execution.<br><br><b>tool</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the Go tool specified by name. Accesses low-level tools like 'compile', 'link', 'asm'.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Go version information, including the release number and build details.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for a given command or for the <b>go</b> command itself.<br><br>


title: DESCRIPTION
content:
The <b>go</b> command is the central utility for managing and interacting with Go source code. It provides a comprehensive suite of subcommands that cover the entire development lifecycle, including building, running, testing, formatting, dependency management, and more. <br><br>Developed as an integral part of the Go programming language, this tool simplifies complex tasks such as compiling projects, fetching external modules, and ensuring code quality. It abstracts away much of the underlying complexity of compilation and linking, allowing developers to focus on writing code. The <b>go</b> command is designed to be highly efficient and provides consistent behavior across different operating systems, making it an indispensable tool for Go programmers.


title: CAVEATS
content:
The behavior of some <b>go</b> subcommands, particularly those related to dependency management (like <b>go get</b> and <b>go mod</b>), has evolved significantly with the introduction and maturation of Go Modules (Go 1.11+). Older Go versions rely more heavily on the <b>GOPATH</b> environment variable. Ensure your Go environment variables (e.g., <b>GOPATH</b>, <b>GOROOT</b>, <b>GOBIN</b>) are correctly configured for optimal use. Network access is frequently required for fetching module dependencies.


title: GO MODULES
content:
Introduced in Go 1.11 and becoming the default in Go 1.13, Go Modules provide a robust system for dependency management. They eliminate the need for projects to reside within the <b>GOPATH</b>, allowing Go projects to be located anywhere. The <b>go mod</b> subcommand group (e.g., <b>go mod init</b>, <b>go mod tidy</b>, <b>go mod vendor</b>) is central to managing module dependencies, versioning, and vendoring.


title: ENVIRONMENT VARIABLES
content:
Several environment variables influence the behavior of the <b>go</b> command:<br><b>GOPATH</b>: Historically, the workspace for Go projects and dependencies. Now primarily used for tools and binaries.<br><b>GOROOT</b>: Specifies the root of the Go SDK installation.<br><b>GOBIN</b>: The directory where installed Go programs (executables) are placed.<br><b>GOOS</b> and <b>GOARCH</b>: Used for cross-compilation, specifying the target operating system and architecture respectively (e.g., <b>GOOS=linux GOARCH=arm64 go build</b>).


title: HISTORY
content:
The Go programming language was conceived at Google in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson, with its public announcement in November 2009. From its inception, the <b>go</b> command-line tool has been the primary interface for Go development. Initially, it managed dependencies primarily through the <b>GOPATH</b> workspace model. A significant evolution occurred with Go 1.11 (released in August 2018) and Go 1.13 (defaulting modules), which introduced and solidified the Go Modules system, fundamentally changing how dependencies are managed and how the <b>go</b> command interacts with projects, making it more resilient and explicit.


title: DESCRIPTION
content:
The "go-bug" command as a standalone executable does not exist on Linux systems. It is highly probable that the query refers to the <br> <b>`go bug`</b> subcommand of the Go programming language's main tool (`go`). <br><br> The `go bug` command provides a convenient way for users to report issues and bugs directly to the Go project's issue tracker. When executed, it automatically opens your default web browser to the designated Go issue reporting page (typically <br><i>`go.dev/issue`</i>). Crucially, it pre-populates the bug report template with essential system information, including: the current Go version (as reported by <br><i>`go version`</i>), the operating system (`GOOS`), the architecture (`GOARCH`), and relevant Go environment variables (similar to output from <br><i>`go env`</i>). This automation streamlines the bug reporting process, ensuring that developers receive comprehensive diagnostic data, which is vital for efficient issue resolution. It simplifies the contribution process, making it easier for the community to report problems and improve the Go toolchain.


title: CAVEATS
content:
The command "go-bug" is not a standard standalone Linux command. This analysis assumes the user is referring to the <br> <b>`go bug`</b> subcommand of the Go programming language tool. <br><br> To use `go bug`, the Go toolchain must be installed on your system and accessible via your system's PATH environment variable. <br><br> A default web browser must be configured on your system for the command to open the issue tracker URL. <br><br> Internet connectivity is required to access and submit the bug report to the Go project's issue tracker.


title: AUTOMATIC INFORMATION COLLECTION
content:
The primary strength of <br><b>`go bug`</b> lies in its ability to automatically gather and pre-populate the bug report with crucial system and Go toolchain information. This includes details like the Go version, operating system, and architecture, which are essential for diagnosing issues effectively. This feature saves users time and ensures that all necessary context is provided for Go developers.


title: HISTORY
content:
The <br> <b>`go bug`</b> subcommand has been an integral part of the Go programming language's standard distribution since its early versions. It was introduced to provide a consistent and streamlined method for users to report bugs and issues directly to the Go project maintainers. Its design reflects Go's commitment to fostering community contributions and providing robust tools that simplify developer workflows, ensuring that critical diagnostic information is automatically collected for effective issue resolution.


title: SYNOPSIS
content:
<b>go clean</b> [flags] [packages]<br><i>Removes object files and cached build artifacts from Go workspaces.</i>


title: PARAMETERS
content:
<b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the corresponding installed archive or binary created by <b>go install</b>.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the commands that <b>go clean</b> would execute, but does not run them.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the commands that <b>go clean</b> executes as it runs.<br><br><b><b>-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the entire Go build cache, located at <i>GOCACHE</i>. This can significantly free up disk space but may slow down subsequent builds as everything needs to be recompiled.<br><br><b><b>-testcache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Expires all test results in the Go build cache. Subsequent <b>go test</b> commands will re-run tests.<br><br><b><b>-modcache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the entire Go module download cache, located at <i>GOMODCACHE</i>. This forces modules to be re-downloaded upon demand.<br><br><b><b>-fuzzcache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the entire Go fuzzing cache, located at <i>GOFUZZCACHE</i>. (Introduced in Go 1.18).<br><br>


title: DESCRIPTION
content:
<b>go clean</b> is a crucial command within the Go programming language toolchain, designed to remove object files, executable binaries, and cached test results from a Go workspace. Its primary purpose is to help developers manage disk space, ensure fresh builds by clearing potentially stale or corrupted artifacts, and troubleshoot build issues. By default, it operates on the current module or specified packages, deleting files created by <b>go build</b>, <b>go install</b>, and <b>go test -c</b>. The command can also target the global Go build cache (<i>GOCACHE</i>), module download cache (<i>GOMODCACHE</i>), and fuzzing cache (<i>GOFUZZCACHE</i>), providing a comprehensive way to reset the build environment. This flexibility makes <b>go clean</b> an essential utility for maintaining a clean and efficient Go development workflow.


title: CAVEATS
content:
<ul><li><b>go clean</b> only removes files specifically created by the Go toolchain (<b>go build</b>, <b>go install</b>, <b>go test -c</b>). It does not clean up arbitrary project output directories or files not managed by Go.</li><li>Using flags like <b>-cache</b> or <b>-modcache</b> can delete a substantial amount of data. While this frees disk space, it will cause subsequent builds and module resolutions to be slower as they must re-download or rebuild everything.</li><li>The command operates on the current working directory and its subdirectories by default, or on specified packages. Be mindful of the context when executing <b>go clean</b>.</li></ul>


title: ENVIRONMENT VARIABLES
content:
The behavior of <b>go clean</b> is influenced by several environment variables that define the locations of caches it manages:<br><i>GOCACHE</i>: Specifies the location of the Go build cache.<br><i>GOMODCACHE</i>: Specifies the location of the Go module download cache.<br><i>GOFUZZCACHE</i>: Specifies the location of the Go fuzzing cache.


title: USAGE SCENARIOS
content:
<b>go clean</b> is typically used for:<br>1. Freeing up disk space by removing compiled binaries and caches.<br>2. Ensuring a fresh build by clearing stale artifacts before recompilation.<br>3. Troubleshooting build or dependency resolution issues that might be caused by corrupted cache entries.


title: HISTORY
content:
<b>go clean</b> has been an integral part of the Go programming language toolchain since its inception, serving as a fundamental utility for managing build artifacts. As Go evolved, particularly with the introduction of the build cache in Go 1.8 and modules in Go 1.11, the command gained new functionalities to manage these additions. Flags like <b>-cache</b> and <b>-modcache</b> were introduced to specifically clear these new caching mechanisms, adapting <b>go clean</b> to the changing landscape of Go's dependency management and build optimization. The <b>-fuzzcache</b> flag was added in Go 1.18 to support the new fuzzing capabilities. Its core function of removing object files remains consistent, evolving to address new challenges in the Go ecosystem.


title: PARAMETERS
content:
<b>-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show documentation for all exported and unexported symbols. By default, only exported symbols are shown.<br><br><b>-cmd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat <I>main</I> packages as commands, displaying their documentation. Useful for documenting command-line tools.<br><br><b>-short</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only the first sentence of the package documentation.<br><br><b>-src</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the actual Go source code alongside the documentation comments.<br><br><b><I>package</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The import path of the Go package to document (e.g., <I>fmt</I>, <I>net/http</I>).<br><br><b><I>symbol</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A specific identifier within a package (e.g., <I>Println</I>, <I>File</I>). Can be a function, type, variable, constant, or method. Used in conjunction with a package.<br><br><b><I>package.symbol</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A combined form to specify a symbol within a particular package directly (e.g., <I>fmt.Println</I>, <I>os.File</I>).<br><br>


title: DESCRIPTION
content:
<I>go doc</I> is a powerful command-line utility provided as part of the Go toolchain. It allows developers to quickly access and display the documentation for Go packages, functions, types, variables, and constants directly from the terminal. The documentation is extracted from the Go source code itself, relying on well-formatted comments associated with declarations. This makes Go self-documenting to a high degree.<br><br>When invoked, <I>go doc</I> parses the specified Go package or symbol, renders its associated documentation comments, and prints them to standard output. It's an indispensable tool for understanding Go's standard library APIs, third-party libraries, and even one's own code without needing to consult external websites or IDEs. It can show detailed documentation for an entire package, or narrow down to a specific function or method within a package, making it highly versatile for quick lookups and API exploration.


title: CAVEATS
content:
Requires a functional Go installation and a properly configured Go environment (<I>GOPATH</I> or Go modules) to resolve package paths. The quality and completeness of the displayed documentation are entirely dependent on the comments present in the Go source code. <I>go doc</I> primarily focuses on documentation from source code; it does not fetch documentation from external web sources unless those are generated from the local source.


title: FINDING PACKAGES
content:
<I>go doc</I> leverages Go's module system (if enabled) or <I>GOPATH</I> to locate and resolve package import paths. This means it can find both standard library packages and third-party modules or local packages, provided they are correctly configured in your Go environment.


title: <I>GO DOC</I> VS. <I>GODOC</I>
content:
Historically, <I>godoc</I> referred to a standalone executable that could serve documentation via a web interface or print it to the console. With Go modules, the <I>godoc</I> web server functionality is now typically invoked via <B>go doc -http</B> or by installing <I>golang.org/x/tools/cmd/godoc</I>. <I>go doc</I> is the modern, integrated command-line tool within the main <I>go</I> binary for printing documentation to the terminal.


title: HISTORY
content:
<I>go doc</I> has been an integral part of the Go programming language's standard toolchain since its early days. It emerged from the philosophy that Go code should be self-documenting, with rich comments directly embedded in the source files. The command was designed to provide developers with immediate, command-line access to this embedded documentation, complementing the <I>godoc</I> web server (which serves similar content over HTTP). Its development has closely tracked the evolution of the Go language itself, including adaptations for Go modules, ensuring it remains a relevant and essential utility for exploring Go APIs.


title: SYNOPSIS
content:
go env [<i>-json</i>] [<i>var ...</i>]<br>go env <i>-u</i> [<i>var ...</i>]<br>go env <i>-w</i> [<i>var=value ...</i>]<br>go env <i>-w -json</i> [<i>var=value ...</i>]


title: PARAMETERS
content:
<b><i>-json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays</i> the environment as a JSON object. When combined with <i>-w</i>, outputs JSON suitable for programmatic configuration.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Unsets</i> the default setting for the specified environment variables in Go's configuration file. This does not affect the current shell's environment.<br><br><b><i>-w</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes</i> the default setting for the specified environment variables to Go's configuration file. These settings will apply to all subsequent Go commands.<br><br>


title: DESCRIPTION
content:
The <b>go env</b> command is an integral part of the Go programming language toolchain, used to <i>display</i> and <i>manage</i> Go environment variables. <br> <br>These variables dictate how Go tools behave, including locations for source code (e.g., <i>GOPATH</i>), compiled binaries (<i>GOBIN</i>), and the target operating system (<i>GOOS</i>) and architecture (<i>GOARCH</i>) for builds. It can list all known Go-specific environment variables or specific ones by name. <br> <br>Beyond just displaying, <b>go env</b> also provides functionality to <i>persistently set or unset</i> these variables for all subsequent Go commands, making it a crucial utility for configuring a Go development workspace. Understanding <b>go env</b> is fundamental for debugging build issues, managing multiple Go projects, or cross-compiling Go applications.


title: CAVEATS
content:
The term "go-env" typically refers to the <b>go env</b> subcommand of the main Go toolchain. It is invoked as <code>go env</code>, not as a standalone `go-env` command. <br> <br><b>go env</b> operates on Go's internal environment configuration, which may differ from the shell's active environment variables. Changes made with <i>-w</i> are persistent for Go commands but do not alter system-wide or shell-specific environment settings.


title: ARGUMENTS
content:
When invoked without flags, <b>go env</b> accepts optional arguments in the format <i><var></i> to display the value of specific environment variables (e.g., <code>go env GOPATH</code>). <br> <br>When used with the <i>-w</i> flag, arguments are in the format <i><var>=<value></i> to set the default value of the specified variable (e.g., <code>go env -w GOPATH=/home/user/go_projects</code>). <br> <br>With the <i>-u</i> flag, arguments are simply <i><var></i> to unset a specific variable (e.g., <code>go env -u GOPATH</code>).


title: CONFIGURATION FILE
content:
Settings modified using <b>go env -w</b> are stored in a user-specific configuration file, typically located at <code>$GOENV</code> if set, or <code>$XDG_CONFIG_HOME/go/env</code> on Unix-like systems, or a similar location on Windows. This centralized configuration ensures consistency across different shell sessions and Go commands.


title: HISTORY
content:
The <b>go env</b> command has been a fundamental part of the Go toolchain since its early releases, evolving with the language's development. <br> <br>The <i>-json</i> flag was introduced in Go 1.12 to facilitate programmatic interaction with Go environment settings. <br> <br>The <i>-w</i> flag, allowing persistent setting of environment variables, was added in Go 1.13, simplifying Go workspace configuration without needing to manually modify shell startup scripts.


title: DESCRIPTION
content:
The command <i>"go-fish"</i> is <b>not a recognized or standard utility</b> found in typical Linux distributions. It does not appear in common system packages, official documentation, or widely used repositories. It is highly probable that this refers to:<br><br>1. A <b>custom script or alias</b> created by a user or administrator for a specific purpose.<br>2. A <b>misremembered or hypothetical command</b>.<br>3. A very <b>niche or specialized tool</b> not widely adopted.<br><br>Without a specific implementation or context, a detailed analysis of its syntax, parameters, and functionality cannot be provided.


title: CAVEATS
content:
As <i>"go-fish"</i> is not a standard Linux command, attempting to execute it on a typical system will likely result in a <b>"command not found" error</b>. Any functionality associated with this name would be entirely dependent on a custom script or program that has been installed or defined on a specific system environment.


title: HYPOTHETICAL USAGE
content:
If <i>"go-fish"</i> were a command, its name might imply a utility for <b>searching, retrieving, or discovering</b> information or resources, possibly across networks or within file systems. For example, a custom script named <i>"go-fish"</i> could be designed to query a database for specific records, search for particular log entries, or explore network services for open ports or specific banners.


title: HISTORY
content:
There is <b>no documented history</b> of a standard Linux command named <i>"go-fish"</i> in the evolution of the Linux operating system or its common utilities. The name itself is strongly associated with the popular card game, rather than a computational tool.


title: SEE ALSO
content:
find(1) - Search for files in a directory hierarchy, grep(1) - Print lines matching a pattern, nmap(1) - Network exploration tool and security scanner, dig(1) - DNS lookup utility, nc(1) - Arbitrary TCP and UDP connections and listens


title: SYNOPSIS
content:
<b>go fix</b> <i>[packages]</i> <br> <br> For more control: <br> <b>go tool fix</b> <i>[flags] [packages]</i>


title: PARAMETERS
content:
<b><b>-diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> Show a diff of the changes that would be applied to the files, rather than modifying the files in place. This is useful for reviewing the proposed changes before committing them.<br><br><b><b>-r</b> <i>rule</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> Apply only the specific rewrite <i>rule</i> named. If <i>rule</i> is `all` (the default when `-r` is not specified), all applicable rules are applied. This allows for targeted application of fixes.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> Verbose output. Print the names of packages as they are processed, providing feedback on the command's progress.<br><br><b><b>-list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> List all available fix rules. When this flag is used, no files are processed, and the command simply outputs a list of the built-in fix transformations that `go fix` can perform.<br><br><b><b>-cpuprofile</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> Write a CPU profile to the specified <i>file</i>. This is primarily for debugging or performance analysis of the `go tool fix` command itself.<br><br><b><b>-memprofile</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br> Write a memory profile to the specified <i>file</i>. Similar to `-cpuprofile`, this is for profiling the `go tool fix` command's memory usage.<br><br>


title: DESCRIPTION
content:
The <b>go fix</b> command is a powerful utility within the Go programming language toolchain, primarily used for automatically updating Go source code to adapt to changes in the language or standard library APIs. As the Go language evolves, certain constructs, functions, or package behaviors might be modified or deprecated. <b>go fix</b> applies a predefined set of rewrite rules (often referred to as 'fixups') to your code, bringing it in line with the expectations of a newer Go version. <br><br>While `go fix` itself is a simple wrapper, the underlying tool `go tool fix` provides the core functionality and more granular control. This command is invaluable for developers migrating older Go codebases to newer Go releases, significantly reducing the manual effort required for refactoring due to syntactic or API-level changes. It parses the Go source files, applies the relevant transformations, and overwrites the original files. It is important to note that `go fix` addresses only known syntactic patterns and API changes, not semantic or logical issues in your code.


title: CAVEATS
content:
While `go fix` automates many common code updates, it has limitations:<br> <br> <b>•</b> It handles known syntactic and API changes but does not understand semantic or logical implications of code. Manual review after running `go fix` is strongly recommended.<br> <b>•</b> By default, it modifies files in place, so using version control (like Git) before running the command is crucial for easy rollback.<br> <b>•</b> It may not cover all possible deprecations or idiomatic changes; some manual refactoring might still be necessary.<br> <b>•</b> It only works on valid Go source code that can be parsed; syntax errors will prevent it from running effectively.


title: REWRITE RULES
content:
At its heart, `go fix` operates by applying a series of predefined 'rewrite rules'. Each rule targets a specific change, such as renaming a function (e.g., `os.Error` to `error`), updating a type signature (e.g., `http.ResponseWriter` changes), or modernizing syntax. Developers can inspect these rules using the `<b>go tool fix -list</b>` command.


title: IDEMPOTENCY
content:
`go fix` is designed to be idempotent. Running the command multiple times on the same codebase will typically produce the same result once all applicable fixes have been applied. It will not endlessly modify files, assuming no new fixes are introduced or code is changed externally.


title: TYPICAL USAGE
content:
The most common use case for `go fix` is after updating your Go toolchain to a newer major or minor version, especially if the release notes mention breaking changes that `go fix` can handle. You would typically navigate to your module root and run `<b>go fix ./...</b>` to process all packages in your module, or `<b>go fix .</b>` for the current directory.


title: HISTORY
content:
The `fix` tool, which forms the core of `go fix`, was introduced early in the Go project's development, predating the stable Go 1.0 release. Its primary purpose was to facilitate the evolution of the Go language and its standard library by providing an automated way to update existing codebases to new APIs and syntax. This mechanism has been crucial for Go's philosophy of backward compatibility, allowing the language to evolve without imposing an unbearable burden of manual refactoring on its users. Initially, it was accessed more commonly via `go tool fix`, but the `go fix` subcommand later provided a more user-friendly interface for common operations.


title: SYNOPSIS
content:
<b>go fmt</b> [<i>flags</i>] [<i>packages</i> or <i>files</i>]<br><br>Examples:<br><i>go fmt</i> .<br><i>go fmt</i> ./...<br><i>go fmt</i> main.go another.go


title: PARAMETERS
content:
<b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files whose formatting would change. This flag prints the names of the files that <i>go fmt</i> would modify to standard output, without actually changing them.<br><br><b><b>-r</b> <i>rule</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a rewrite rule to the source before formatting. The rule is specified in the form "pattern -> replacement". This is an advanced feature primarily used for code transformations, not just style.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simplify code before formatting. This applies basic AST simplifications, such as replacing `x[a:len(x)]` with `x[a:]`. This option is often used in conjunction with other `go tool` commands.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print commands executed. This flag is useful for debugging as it shows the underlying commands <i>go fmt</i> invokes internally (e.g., `go tool fmt`).<br><br>


title: DESCRIPTION
content:
<i>go fmt</i> is a command-line utility that automatically reformats Go program source code according to the official Go programming language style guide. It's an essential part of the Go toolchain, ensuring code consistency across projects and developers. The tool parses the Go source file into an abstract syntax tree (AST) and then prints it back out in a standardized, canonical format. This deterministic process eliminates stylistic debates and promotes readability.<br><br>Unlike many formatters, <i>go fmt</i> is highly opinionated and offers very few configurable options. This design choice is fundamental to Go's philosophy of reducing bikeshedding over code style. When run without arguments, it processes the Go source files in the current directory. It can also accept specific files or package paths as arguments. By default, it modifies files in place, but options are available to preview changes or list affected files. Many Go development environments integrate <i>go fmt</i> (or its superset, <i>goimports</i>) to automatically format code upon saving.


title: CAVEATS
content:
<i>go fmt</i> is intentionally opinionated and provides almost no configuration options for code style. This means developers cannot customize spacing, line breaks, or brace styles. Its primary purpose is to enforce a single, canonical Go style. By default, it modifies files in place, so it's advisable to use version control or the <b>-l</b> flag to preview changes before applying them.


title: IDEMPOTENCY
content:
<i>go fmt</i> is idempotent. Running the command multiple times on the same source code will produce the identical output after the first run, assuming no manual changes were made in between.


title: IDE/EDITOR INTEGRATION
content:
Most modern Go IDEs and text editors (like VS Code, GoLand, Vim, and Emacs) have built-in support or plugins to automatically run <i>go fmt</i> (or <i>goimports</i>) upon saving a Go file, ensuring continuous adherence to the standard style.


title: HISTORY
content:
The concept of an automatic, opinionated code formatter like <i>gofmt</i> (the underlying tool) was central to the design philosophy of the Go language from its inception. It was developed by Rob Pike as part of the initial Go project at Google. Its aim was to eliminate arguments over code style, foster consistency, and improve code readability across all Go projects. <i>go fmt</i>, as part of the broader <i>go</i> toolchain, became available with early Go releases, solidifying its role as an indispensable tool for Go developers.


title: SEE ALSO
content:
go(1): The primary Go command-line tool, used for building, testing, and managing Go projects., goimports(1): A tool similar to <i>go fmt</i> that also adds and removes Go package imports as necessary, making it a commonly used superset of <i>go fmt</i>., gofmt(1): The underlying, lower-level formatting command that <i>go fmt</i> typically invokes., go tool vet(1): A command that inspects Go source code and reports suspicious constructs, such as unused variables or unreachable code.


title: SYNOPSIS
content:
<b>go generate</b> [<i>build flags</i>] [<i>packages</i>]<br><br><i>Examples:</i><br><i><b>go generate</b></i> <br><i><b>go generate</b> ./...</i> <br><i><b>go generate</b> -run "stringer" ./pkg/mytypes</i> <br><i><b>go generate</b> -v -x</i>


title: PARAMETERS
content:
<b>-run regexp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only commands whose directives match the provided regular expression are executed. Useful for running specific generation steps, particularly in projects with many <i>//go:generate</i> lines.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the names of packages as they are processed by <b>go generate</b>, providing verbose output about the progress.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run; it prints the commands that would be executed but does not actually run them. This is useful for debugging or previewing the generation process without making changes.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the commands as they are executed, showing the exact command lines being run, including any environment variables expanded.<br><br><b>[packages]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which Go packages to generate. If omitted, <b>go generate</b> operates on the package in the current working directory. This can be a package path (e.g., <i>./...</i> to generate all packages in the current directory and its subdirectories, or <i>github.com/my/project</i> for a specific remote package).<br><br>


title: DESCRIPTION
content:
The <b>go generate</b> command is a powerful tool part of the Go ecosystem, designed to automate the execution of external commands defined within Go source files. It scans Go files (ending in <i>.go</i>) for lines containing the special directive <i>//go:generate</i>, followed by a command string. When found, <b>go generate</b> executes these commands in the context of the package containing the directive. This mechanism is crucial for tasks like <br>generating boilerplate code, embedding static assets, creating mock interfaces, processing protocol buffers, or any other pre-build steps that are not natively handled by the Go compiler. It standardizes and makes explicit the external dependencies and build-time transformations required for a Go project, ensuring reproducibility across different development environments. By integrating these steps directly into the source code, <b>go generate</b> simplifies the build process, making projects easier to maintain and share.


title: CAVEATS
content:
<b>Security Risk:</b> <b>go generate</b> executes arbitrary commands found in source files. Exercise caution when running it on untrusted code, as it could lead to arbitrary code execution on your system.<br><b>External Dependencies:</b> The commands specified in <i>//go:generate</i> directives must be installed and accessible in the system's PATH. <b>go generate</b> does not manage the installation or versioning of these external tools.<br><b>Performance:</b> For large projects with numerous generation steps or complex commands, <b>go generate</b> can be time-consuming, as it executes commands sequentially per directive within a package.<br><b>Environment Variables:</b> The special environment variables (<i>$GOFILE</i>, <i>$GOLINE</i>, etc.) are only available within the command executed by <b>go generate</b>. These are not general shell variables and are reset for each directive.


title: DIRECTIVE FORMAT AND ENVIRONMENT VARIABLES
content:
The <i>//go:generate</i> directive must appear as a full line comment in a Go source file, typically at the top or immediately after the package clause. The command string following the directive is executed as if by a shell. Before executing the command, <b>go generate</b> sets several useful environment variables specific to the current context: <br><i>$GOARCH</i> (target architecture), <i>$GOOS</i> (target operating system), <i>$GOFILE</i> (name of the current Go file), <i>$GOLINE</i> (line number of the directive), <i>$GOPACKAGE</i> (name of the Go package), <i>$GOROOT</i> (Go installation root), and <i>$GOPATH</i> (Go workspace). These variables enable the generation command to be context-aware and flexible, for instance, by operating on the specific file it was found in.


title: COMMON USE CASES
content:
<b>go generate</b> is widely adopted for automating various development tasks: <br>• <i>Stringer</i>: Automatically generating <i>String()</i> methods for <i>iota</i>-defined constants or custom types, improving readability and debugging. <br>• <i>Mocking Frameworks</i>: Creating mock implementations of interfaces for robust unit testing (e.g., using <i>mockgen</i> or <i>go.mock</i>). <br>• <i>Asset Embedding</i>: Bundling static assets (like HTML templates, CSS, JavaScript, images) directly into Go binaries, making them self-contained and easy to deploy. <br>• <i>Protocol Buffers/gRPC</i>: Generating Go code from <i>.proto</i> definitions for data serialization and RPC service definitions. <br>• <i>Schema/Model Generation</i>: Automatically creating Go structs from database schemas, API definitions (e.g., OpenAPI), or JSON/YAML files.


title: HISTORY
content:
The <b>go generate</b> command was introduced with <b>Go 1.4</b>, released in December 2014. Its inception addressed a long-standing need within the Go community for a standardized way to automate pre-processing and code generation steps that are integral to a project's build but fall outside the scope of the Go compiler itself. Prior to its introduction, developers often relied on custom shell scripts, Makefiles, or other build automation tools, which introduced inconsistencies and portability issues across different development environments. <b>go generate</b> provided a Go-native, declarative mechanism to embed these automation instructions directly within the source code, thereby simplifying project setup and ensuring that necessary code generation steps are always performed as part of a Go project's build lifecycle.


title: PARAMETERS
content:
<b><br><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Instructs <br><b>go get</b><br> to download the source code of the packages and their dependencies, but not to build or install them.<br><br><b><br><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>When used with <br><b>-u</b><br>, considers modules needed for testing (i.e., listed in <br><i>require</i><br> directives of the <br><i>go.mod</i><br> file with a <br><i>// indirect</i><br> comment or in <br><i>go.mod</i><br>'s <br><i>require</i><br> blocks that are only used for tests).<br><br><b><br><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Updates packages to use newer minor or patch versions when available. Without this flag, <br><b>go get</b><br> prefers existing versions that satisfy the module's requirements.<br><br><b><br><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Enables verbose output, showing details about the download and resolution process.<br><br><b><br><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Prints the commands being executed, which is useful for debugging.<br><br><b><br><b>[build flags]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Various build-related flags can be passed through, such as <br><b>-mod=readonly</b><br> (to prevent modifications to <br><i>go.mod</i><br>), or flags controlling compilation behavior.<br><br><b><br><b>[packages]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>One or more package paths (e.g., <br><i>github.com/some/module</i><br>), or <br><i>.</i><br> to refer to the current module. Specifies which packages/modules to operate on.<br><br>


title: DESCRIPTION
content:
The <br><b>go get</b><br> command is a crucial subcommand of the Go programming language toolchain, responsible for downloading and managing Go packages and modules. Its primary function is to fetch source code from remote repositories, such as GitHub or other version control systems, and resolve their dependencies. <br><br>Historically, <br><b>go get</b><br> downloaded packages directly into the user's <br><i>GOPATH</i><br> workspace. However, with the introduction of Go Modules in Go 1.11 (and becoming the default in Go 1.13), its behavior significantly evolved. In a module-aware environment, <br><b>go get</b><br> is primarily used to add, update, or remove module dependencies recorded in the <br><i>go.mod</i><br> file. When run without arguments inside a module, it updates all dependencies. When given a package path, it adds or updates that specific dependency. <br><br>While it can still be used to download source code or install executable commands, its role for installing executables has largely been superseded by <br><b>go install</b><br> since Go 1.16, which provides more explicit control over versioning and installation paths. <br><b>go get</b><br> now focuses more on managing the dependency graph for your project, ensuring that your <br><i>go.mod</i><br> and <br><i>go.sum</i><br> files accurately reflect the required modules and their checksums. It handles transitive dependencies, ensuring your project has all necessary components to build and run.


title: CAVEATS
content:
The <br><b>go get</b><br> command requires a properly installed Go toolchain. Its behavior significantly changed with the introduction of Go Modules (Go 1.11+), making it crucial to understand the context (GOPATH vs. Modules) in which it's being used. In a module-aware project, it will modify your <br><i>go.mod</i><br> and <br><i>go.sum</i><br> files to reflect dependency changes. An active internet connection is typically required to fetch remote modules.


title: MODULE-AWARE MODE
content:
In projects using Go Modules (indicated by a <br><i>go.mod</i><br> file), <br><b>go get</b><br> acts as a dependency manager. It resolves and downloads necessary module versions, updating the <br><i>go.mod</i><br> and <br><i>go.sum</i><br> files. When run without arguments in a module root, it updates all direct and indirect dependencies to their latest compatible versions.


title: INSTALLING EXECUTABLES
content:
While <br><b>go get</b><br> historically installed executables (e.g., <br><i>go get github.com/user/tool</i><br>), its role for this purpose has largely been deprecated since Go 1.16. The recommended command for installing Go programs into your <br><i>GOBIN</i><br> (or <br><i>GOPATH/bin</i><br>) is now <br><b>go install</b><br>, which offers more explicit control over versions and ensures correct binary placement, for example, <br><i>go install github.com/user/tool@latest</i><br>.


title: HISTORY
content:
The <br><b>go get</b><br> command has been a fundamental part of the Go toolchain since its early days. Initially, its primary role was to fetch and install packages into the user's <br><i>GOPATH</i><br> workspace, often building and caching them. <br><br>A significant evolution occurred with Go 1.11 and the advent of Go Modules, becoming the default in Go 1.13. In the module system, <br><b>go get</b><br> transformed from a general-purpose package installer to a focused dependency manager. Its main function became updating the <br><i>go.mod</i><br> file to reflect required module versions. <br><br>Further refinement in Go 1.16 saw the <br><b>go install</b><br> command become the preferred method for installing executable Go programs, separating that concern from <br><b>go get</b><br>'s primary role of managing module dependencies.


title: SYNOPSIS
content:
<b>go install</b> [<i>build flags</i>] [<i>packages</i>]<br><b>go install</b> [<i>build flags</i>] <i>path@version</i>


title: PARAMETERS
content:
<b><b>-o <i>output</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output file or directory name. For <b>go install</b>, this is less common as it typically places output in <i>$GOBIN</i>.<br><br><b><b>-ldflags '<i>flags</i>'</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to pass to the linker during compilation.<br><br><b><b>-tags '<i>tag,tag</i>'</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of build tags to satisfy during the build process, influencing conditional compilation.<br><br><b><b>-race</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable data race detection for the compiled program. This adds runtime overhead but helps find concurrency issues.<br><br><b><b>-trimpath</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all file system paths from the compiled executable, making it more portable and reproducible.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the names of packages as they are compiled and installed, providing verbose output.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the commands as they are executed by the Go toolchain, showing underlying system calls.<br><br><b><b>-mod={readonly|vendor|mod}</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls module downloading and vendoring behavior. 'readonly' (default) ensures the <i>go.mod</i> file is not modified.<br><br><b><b>-gcflags '<i>flags</i>'</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to pass to the Go compiler during compilation.<br><br>


title: DESCRIPTION
content:
The <b>go install</b> command is a fundamental tool in the Go ecosystem, primarily used to compile and install Go packages or commands. When invoked, it compiles the specified package(s) and places the resulting executable(s) into the directory specified by the <i>$GOBIN</i> environment variable. If <i>$GOBIN</i> is not set, it defaults to <i>$GOPATH/bin</i>. For non-executable packages (libraries), it caches their compiled forms in <i>$GOCACHE</i>, making subsequent builds faster.<br><br>Unlike <b>go build</b>, which typically compiles an executable in the current working directory, <b>go install</b> focuses on placing the compiled output into a standardized, executable path, making it readily available for use. Since Go 1.16, <b>go install</b> has become the official and recommended way to install arbitrary Go commands from remote modules, using the syntax <i>path@version</i> (e.g., <i>go install example.com/cmd@latest</i>). This allows developers to easily fetch, build, and install specific versions of tools without needing to clone repositories or manage local module dependencies manually.


title: CAVEATS
content:
*   <b>Executable Requirement:</b> For <b>go install</b> to produce an executable, the target package must be a <i>main</i> package (i.e., contain a <i>main()</i> function).<br>*   <b>Environment Variables:</b> Its behavior heavily relies on environment variables like <i>$GOBIN</i> and <i>$GOPATH</i> for determining installation locations.<br>*   <b>Module Awareness (Go 1.16+):</b> The <i>path@version</i> syntax requires Go modules to be enabled and typically an internet connection to fetch remote modules.<br>*   <b>Permissions:</b> Installing to system-wide paths (e.g., if <i>$GOBIN</i> is set to a protected directory like <i>/usr/local/bin</i>) may require elevated privileges (e.g., using <i>sudo</i>).<br>*   <b>Tooling vs. Libraries:</b> While it compiles all packages, its primary user-facing function is to install command-line tools. Libraries are generally consumed via <b>go get</b> or module dependencies directly within projects.


title: ENVIRONMENT VARIABLES
content:
Important environment variables that influence <b>go install</b>'s behavior:<br><ul><li><b><i>$GOBIN</i></b>: Specifies the absolute path where compiled executables are placed. If not set, it defaults to <i>$GOPATH/bin</i>.</li><li><b><i>$GOPATH</i></b>: Defines the Go workspace root. Its <i>bin</i> subdirectory is the default target for installations if <i>$GOBIN</i> is not set.</li><li><b><i>$GOCACHE</i></b>: The directory where Go caches build artifacts. <b>go install</b> leverages this for faster subsequent builds and package compilation.</li><li><b><i>$GOROOT</i></b>: Specifies the location of the Go SDK installation itself.</li></ul>


title: MODULE-AWARE INSTALLATION
content:
Since Go 1.16, <b>go install</b> supports installing specific versions of tools directly from module paths, regardless of the current working directory's module. The syntax <i>path@version</i> (e.g., <i>go install github.com/spf13/cobra-cli@latest</i> or <i>go install golang.org/x/tools/cmd/goimports@v0.1.0</i>) allows fetching, building, and installing a command without adding it as a dependency to your current module. This is particularly useful for managing globally installed command-line tools.


title: HISTORY
content:
The <b>go install</b> command has been a core part of the Go toolchain since its early days, initially used primarily to install Go programs from within the <i>$GOPATH</i> workspace. With the introduction of Go modules in Go 1.11 and especially with Go 1.16, its role expanded significantly. Go 1.16 officially deprecated <b>go get</b> for installing commands and designated <b>go install</b> (with the <i>path@version</i> syntax) as the preferred and modern way to install executables from remote Go modules directly, without modifying the current module's <i>go.mod</i> file.


title: PARAMETERS
content:
<b>-f format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Custom output format.</i> Uses a Go template string to specify the desired output fields from a package or module struct.<br><br><b>-json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>JSON output.</i> Prints a JSON object for each package or module found.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List modules.</i> If specified, arguments are module patterns (or paths), and the command lists modules instead of packages.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Update network and module cache.</i> Causes <b>go list</b> to check for newer versions of modules.<br><br><b>-deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List all transitive dependencies.</i> Includes not just the specified packages but also all their dependencies.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Continue on errors.</i> Does not stop on package loading errors, reporting them as warnings.<br><br><b>-test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Include test packages.</i> Considers `_test.go` files when determining package properties and dependencies.<br><br><b>[build flags]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Standard Go build flags.</i> Options like <b>-tags</b>, <b>-mod</b>, or <b>-modfile</b> that affect how packages are built and resolved.<br><br><b>[packages]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Package patterns or module paths.</i> Specifies which packages or modules to list. Examples: <b>.</b> (current), <b>./...</b> (current and subdirectories), <b>all</b> (all known), <b>github.com/foo/bar</b>.<br><br>


title: DESCRIPTION
content:
The <b>go list</b> command is a powerful utility within the Go toolchain used to display information about Go packages and modules. It can enumerate packages, their source directories, import paths, build context, and dependencies. <br><br>When run without arguments, it lists the current package. When given package patterns, it expands them to matching packages. A key feature is its ability to output data in various formats, including simple names, paths, or detailed structured JSON, making it indispensable for scripting and programmatic analysis of Go projects. It's often used to understand project structure, inspect module dependencies, or gather data for custom build systems and IDEs.


title: CAVEATS
content:
Performance can degrade for very large projects or when resolving extensive transitive dependencies, especially with network updates (<b>-u</b>). <br><br>The exact fields available for templating (<b>-f</b>) or JSON output depend on the Go version and whether packages or modules are being listed. Refer to Go documentation for the full struct definitions.


title: TEMPLATING OUTPUT WITH -F
content:
The <b>-f</b> flag allows for highly customizable output using Go template syntax. Common fields include <i>.Dir</i> (directory), <i>.ImportPath</i> (import path), <i>.Deps</i> (direct dependencies), <i>.GoFiles</i> (Go source files), and <i>.Module.Path</i> (module path). This enables extracting specific data points for automation and scripting.


title: MODULE VS. PACKAGE LISTING
content:
By default, <b>go list</b> lists packages. Using the <b>-m</b> flag changes its behavior to list modules instead. When listing modules, the output fields available change to reflect module-specific properties like <i>.Version</i>, <i>.Path</i>, and <i>.Main</i>. Understanding this distinction is crucial for accurate querying of Go projects.


title: HISTORY
content:
The <b>go list</b> command has been an integral part of the standard Go toolchain since its early versions, providing a foundational way to query information about Go source code. Its functionality significantly expanded with the introduction of Go modules in Go 1.11, adding the <b>-m</b> flag and module-specific fields to support the new dependency management system. This evolution made <b>go list</b> an essential tool for understanding and managing Go projects in the module era.


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new module in the current directory, creating a <i>go.mod</i> file.<br><br><b>tidy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds any missing module requirements and removes unused ones, ensuring <i>go.mod</i> and <i>go.sum</i> are accurate.<br><br><b>download</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads the specified modules (or all dependencies if none are specified) into the local module cache.<br><br><b>vendor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies all dependencies into the <i>vendor/</i> directory within the current module, isolating them from the Go module cache.<br><br><b>graph</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the module dependency graph in text form, showing direct and indirect dependencies.<br><br><b>verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies that dependencies in the module cache have not been tampered with by checking their checksums against <i>go.sum</i>.<br><br><b>edit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides command-line editing of <i>go.mod</i>, allowing for adding or removing requirements, or changing the module path.<br><br><b>why</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explains why specific packages or modules are included in the module graph.<br><br>


title: DESCRIPTION
content:
The <b>go mod</b> command is the primary tool for managing dependencies in Go projects, introduced to provide a more robust and reproducible way to handle external libraries compared to the traditional <i>GOPATH</i> model.<br><br>It operates around two core files: <i>go.mod</i>, which defines the module's path, required Go version, and its direct dependencies with specific versions; and <i>go.sum</i>, which contains cryptographic checksums for all direct and indirect module dependencies, ensuring integrity and security.<br><br><b>go mod</b> facilitates various dependency management tasks such as initializing a new module, adding or removing dependencies, downloading modules to a local cache, vendoring dependencies, and inspecting the module graph. Its adoption has significantly improved the Go ecosystem's dependency management, making builds more consistent and versioning clearer.


title: CAVEATS
content:
Requires Go version 1.11 or higher; Go 1.14+ made modules the default.<br>Proper configuration of <i>GOPRIVATE</i> and <i>GONOPROXY</i> environment variables is crucial for managing private or internal modules.<br>The <i>go.sum</i> file must be committed to version control to ensure reproducible builds and integrity checks.<br>While <i>go mod vendor</i> can be used, it's generally not required for most Go module workflows as the Go toolchain prioritizes the module cache.


title: MODULE FILES: <I>GO.MOD</I> AND <I>GO.SUM</I>
content:
The <i>go.mod</i> file defines the module's identity, Go version, and declared dependencies (with minimum versions or specific versions). The <i>go.sum</i> file provides cryptographic checksums for all direct and indirect dependencies, ensuring their integrity and preventing tampering.


title: MODULE PROXIES
content:
Go modules can utilize module proxies (e.g., <i>proxy.golang.org</i> via <i>GOPROXY</i> environment variable) to fetch modules, offering increased build reliability, security, and speed by serving immutable module versions.


title: HISTORY
content:
Go modules were introduced as an experimental feature in <b>Go 1.11</b> (August 2018) to address shortcomings in the traditional <i>GOPATH</i> dependency management system. They became the default and recommended way to manage dependencies starting from <b>Go 1.14</b> (February 2020). This shift aimed to provide reproducible builds, better dependency versioning, and improved dependency resolution, leading to a more robust and predictable build environment for Go projects.


title: SYNOPSIS
content:
<pre>go run [build flags] [packages | .go files] [arguments...]</pre><br><br><I><b>build flags</b></I>: Optional flags that control the compilation process, similar to those used with <b><I>go build</I></b>.<br><I><b>packages | .go files</b></I>: Specifies the Go source code to run. This can be a package path (e.g., ".") or a list of individual Go source files (e.g., "main.go other.go").<br><I><b>arguments...</b></I>: Any arguments that follow the package or file specification are passed directly to the executed Go program, not to the <b><I>go run</I></b> command itself.


title: PARAMETERS
content:
<b><I>packages | .go files</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Go source code to compile and run. This can be a package path (e.g., `.` for the current directory) or a list of `.go` files (e.g., `main.go`). It specifies <b>what</b> to run.<br><br><b><I>arguments...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any arguments that follow the package or file specification are passed directly to the Go program being executed, not to the <b><I>go run</I></b> command itself. These are your program's command-line arguments.<br><br><b>-race</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable data race detection during compilation and runtime. This flag helps identify concurrent access issues.<br><br><b>-tags <I>'tag,list'</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of build tags to consider satisfied during the build. Used for conditional compilation.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the names of packages as they are compiled and linked. Useful for verbose output during the build process.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the commands `go run` executes (e.g., the underlying `go tool compile`, `go tool link`, and the final execution command). Highly useful for debugging build issues.<br><br><b>-ldflags <I>'flags'</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to pass to the linker. Often used to embed build information (e.g., version strings, commit hashes) into the final executable.<br><br><b>-gcflags <I>'flags'</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to pass to the Go compiler. Allows fine-tuning compiler behavior for specific needs.<br><br><b>-mod <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the module download mode. Accepted modes include `readonly` (default), `vendor` (use modules in `vendor` directory), or `mod` (allow network operations to fetch modules).<br><br><b>-trimpath</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all file system paths from the compiled executable. This helps create reproducible builds and smaller binaries.<br><br>


title: DESCRIPTION
content:
The <b><I>go run</I></b> command is an essential part of the Go programming language's toolchain, designed for rapid development and testing. It provides a convenient way to compile and execute Go source code without explicitly managing the intermediate executable file. When invoked, <b><I>go run</I></b> first compiles the specified Go packages or individual .go files into a temporary executable. After successful compilation, it immediately runs this temporary executable. Once the program finishes execution, the temporary binary is automatically deleted. This command is particularly useful for quickly trying out code snippets, running scripts, or testing application logic during the development phase. Unlike <b><I>go build</I></b>, which creates a persistent executable file, <b><I>go run</I></b> abstracts away the compilation step, making it feel more like an interpreted language for rapid prototyping. Arguments provided after the Go source files or package path are passed directly to the executed Go program.


title: CAVEATS
content:
<ul><li><b>Temporary Executable</b>: <b><I>go run</I></b> creates a temporary executable file, typically in the Go build cache or a system temporary directory, and deletes it upon completion. This means you cannot easily inspect the compiled binary or share it directly after running.</li><li><b>Development Tool</b>: While convenient, <b><I>go run</I></b> is primarily intended for development and testing. For deploying applications, it's generally recommended to use <b><I>go build</I></b> to create a named, persistent executable that you can then manage and distribute.</li><li><b>Performance Overhead</b>: For very large projects, the compilation step, though fast for Go, still adds overhead compared to directly executing an already built binary. Repeatedly running <b><I>go run</I></b> might recompile if source files change, which is expected but worth noting.</li></ul>


title: <I>HOW IT WORKS</I>
content:
When you execute <b><I>go run</I></b>, the Go toolchain performs two main steps: <br>1. <b>Compilation</b>: It compiles the specified Go source files and their dependencies into an executable binary. This temporary binary is placed in a build cache or a temporary directory.<br>2. <b>Execution</b>: Immediately after successful compilation, the temporary executable is launched. Any arguments provided after the Go source files are passed directly to this running program.<br>Once the program finishes, the temporary executable file is removed. This seamless compile-then-run process makes <b><I>go run</I></b> highly convenient for iterative development.


title: HISTORY
content:
The <b><I>go run</I></b> command has been an integral part of the Go toolchain since the early versions of Go (Go 1.x). It was designed to simplify the development workflow by abstracting the explicit compilation and execution steps into a single command. This design choice reflects Go's emphasis on developer productivity and ease of use, allowing for a more script-like feel when interacting with Go programs during development. Its core functionality has remained consistent, adapting to changes in the Go module system and build cache mechanisms over time.


title: SYNOPSIS
content:
<b><I>go tool</I></b> <I>&lt;command&gt;</I> [<I>arguments...</I>]<br>Example: <I>go tool pprof</I> [<I>options</I>] <I>binary</I> [<I>profile</I>]


title: PARAMETERS
content:
<b>cover</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates and analyzes code coverage profiles for Go programs.<br><br><b>pprof</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyzes and visualizations performance profiles (CPU, memory, mutex, block) generated by Go programs.<br><br><b>trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyzes and visualizes Go execution traces, showing goroutine, network, syscall, and scheduler events.<br><br><b>vet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Examines Go source code for suspicious constructs, such as potential errors not caught by the compiler.<br><br><b>asm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Go assembler. Translates Go assembly source files into object files. Usually invoked by 'go build'.<br><br><b>compile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Go compiler. Compiles Go source files into object files. Usually invoked by 'go build'.<br><br><b>link</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Go linker. Links object files into an executable binary or a shared library. Usually invoked by 'go build'.<br><br><b>cgo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cgo processes Go source files that import the pseudo-package 'C', enabling calls to C code.<br><br>


title: DESCRIPTION
content:
The <I>go tool</I> command serves as a gateway to various low-level utilities within the Go programming language's toolchain. Unlike standard Go commands like <I>go build</I> or <I>go run</I>, these tools are often invoked for advanced diagnostics, profiling, code analysis, or by the Go toolchain itself during the build process. It provides access to the Go compiler, assembler, linker, profiling tools (<I>pprof</I>), code coverage tools (<I>cover</I>), and static analysis tools (<I>vet</I>), among others. While some tools like <I>go tool pprof</I> are frequently used by developers, others like <I>go tool compile</I> are primarily internal components. Understanding <I>go tool</I> is essential for deep-diving into Go program behavior or for working on the Go compiler and runtime itself.


title: CAVEATS
content:
The <I>go tool</I> command itself is not a standalone executable. It is a subcommand of the main <I>go</I> command and requires a Go language installation. The specific tools available via <I>go tool</I> can vary slightly between Go versions. Each sub-tool has its own set of arguments and usage patterns, which can be complex and are typically documented by running <I>go tool &lt;command&gt; -h</I> or consulting the Go documentation. Many of these tools are low-level and are primarily used by advanced Go developers or for debugging Go's internal mechanisms.


title: COMMON USAGE SCENARIOS
content:
While many <I>go tool</I> subcommands are used internally by the Go toolchain, <I>go tool pprof</I> and <I>go tool trace</I> are frequently used by developers to diagnose performance bottlenecks and understand runtime behavior. <I>go tool cover</I> is crucial for assessing test coverage. <I>go tool vet</I> helps in identifying potential issues in code before compilation.


title: DISCOVERING AVAILABLE TOOLS
content:
To list all tools available through <I>go tool</I> on your system, you can typically run <I>go tool</I> without any arguments. This will print a list of recognized commands. For help on a specific tool, use <I>go tool &lt;command&gt; -h</I> or <I>go tool &lt;command&gt; help</I>.


title: HISTORY
content:
The <I>go tool</I> command and its various sub-tools have been an integral part of the Go programming language's distribution since its early versions. As the Go project matured, the specific set of available tools and their functionalities evolved to support new features, debugging capabilities, and performance analysis requirements of the language and runtime. It serves as a consistent interface to the underlying components of the Go toolchain, ensuring that even as internal implementations change, developers can still access these utilities through a stable command.


title: PARAMETERS
content:
<b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints module information along with the Go version. When executed inside a Go module directory, it lists the main module and its dependencies. If not in a module, it behaves similarly to <i>go version</i>.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints more verbose details about the Go version, potentially including the exact Git commit hash from which the Go toolchain was built, and additional build information.<br><br>


title: DESCRIPTION
content:
The <br><b>go version</b> command is a fundamental subcommand of the <br><i>Go toolchain</i>, providing crucial information about the installed Go compiler and runtime. Its primary function is to display the Go version number, the operating system, and the hardware architecture for which the Go toolchain was built. For instance, it might output <br><i>go version go1.22.4 linux/amd64</i>, clearly indicating the Go release and the target platform. <br><br>This command is indispensable for developers to quickly verify their Go environment, ensuring they are using the correct version for their projects. It's also vital for debugging compatibility issues when collaborating with others or deploying applications to different servers. System administrators and automated build systems heavily rely on <br><b>go version</b> to confirm the presence and specifics of the Go installation, making it a cornerstone for consistent development and deployment workflows, especially within <br><i>CI/CD pipelines</i> to enforce version control and avoid unexpected build failures.


title: CAVEATS
content:
This is not a standalone <br><i>linux command</i> named 'go-version'. Instead, it is a subcommand of the main <br><b>go</b> command: <br><b>go version</b>. It requires the Go toolchain to be installed and accessible via the system's <br><i>PATH</i>. The exact output can vary slightly depending on the Go version and whether it was built from an official release or a custom source.


title: TYPICAL OUTPUT
content:
A standard output for <br><b>go version</b> looks like: <br><i>go version go1.22.4 linux/amd64</i>. This indicates the Go release, the operating system, and the architecture for which it was compiled.


title: USAGE CONTEXT
content:
This command can be executed from any directory in your terminal, provided the <br><i>Go toolchain</i> is properly installed and configured in your system's <br><i>PATH</i> environment variable. It does not require to be run within a Go project directory unless using the <br><b>-m</b> flag for module information.


title: HISTORY
content:
The <br><b>go version</b> command has been an integral part of the Go toolchain since its inception, serving as the primary method to identify the installed Go compiler and runtime. Its consistent output format has made it highly reliable for scripting and automation purposes, particularly in continuous integration and deployment workflows to ensure specific Go versions are used for builds.


title: SYNOPSIS
content:
<b>go vet</b> [<i>vet-flags</i>] [<i>packages</i>]<br><br>Where:<br><i>vet-flags</i>: Flags passed directly to the underlying <I>vet</I> analysis tool.<br><i>packages</i>: One or more package paths (e.g., <I>./...</I> for all subpackages, <I>.</I> for the current package, or specific package import paths like <I>golang.org/x/tools/go/vet</I>).


title: PARAMETERS
content:
<b>-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run all available analysis checkers.<br><br><b>-asmdecl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for inconsistencies in assembly declarations.<br><br><b>-atomic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for common mistakes when using the <I>sync/atomic</I> package.<br><br><b>-bools</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for common mistakes involving boolean expressions.<br><br><b>-buildtags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for errors in <I>//go:build</I> and <I>// +build</I> directives.<br><br><b>-composites</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for unkeyed composite literals.<br><br><b>-fieldalignment</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for structs whose fields are not optimally aligned.<br><br><b>-nilness</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for nil pointer dereferences and other nil-related issues.<br><br><b>-printf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for incorrect <I>printf</I> format strings (default behavior).<br><br><b>-shadow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for shadowed variables.<br><br><b>-stdmethods</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for incorrect signatures of standard library methods.<br><br><b>-structtags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for malformed or uncanonical struct tags.<br><br><b>-test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply checks specific to Go test files.<br><br><b>-unreachable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for unreachable code.<br><br><b>-unusedresult</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for unused results of function calls that return an error or other important value.<br><br><b>-tags=<list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of build tags to consider satisfied during analysis.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output from the <I>vet</I> tool.<br><br>


title: DESCRIPTION
content:
The <I>go vet</I> command is a static analysis tool that examines Go source code and reports suspicious constructs, potential errors, and non-idiomatic uses that the compiler might not catch. It is part of the standard Go toolchain and helps developers identify common mistakes early in the development cycle.<br><br>While it does not replace testing, <I>go vet</I> serves as a valuable first line of defense against bugs by flagging issues like incorrect <I>printf</I> format strings, unreachable code, unkeyed composite literals, improper use of synchronization primitives, and more. It acts as a "vetter" for code quality, focusing on correctness rather than stylistic preferences (which are handled by tools like <I>go fmt</I>). Running <I>go vet</I> regularly on a codebase contributes significantly to maintaining high code quality and reducing the likelihood of runtime errors. Many continuous integration (CI) pipelines include <I>go vet</I> as a mandatory step.


title: CAVEATS
content:
While powerful, <I>go vet</I> is a static analysis tool and cannot detect all possible runtime errors or complex logical bugs. It may occasionally produce false positives, requiring developers to evaluate the reported issue in context. Its focus is on common suspicious patterns rather than strict coding style enforcement (which is often handled by dedicated linters). The analysis can be resource-intensive on very large codebases, especially when using the <I>-all</I> flag, or when dealing with complex dependency graphs.


title: INTEGRATION WITH <I>GO TEST</I>
content:
The <I>go test</I> command can automatically run <I>go vet</I> before running tests. By default, it runs <I>go vet</I> if any packages are specified as arguments. To explicitly control this behavior, use the <I>-vet</I> flag:<br><i><I>go test -vet=off</I></i> (to disable vet)<br><i><I>go test -vet=all</I></i> (to enable vet for all specified packages)<br><i><I>go test -vet=printf</I></i> (to enable only specific vet checks)


title: RUNNING ON MULTIPLE PACKAGES
content:
To run <I>go vet</I> on all packages within the current module or directory tree, use the special <I>./...</I> argument:<br><i><I>go vet ./...</I></i><br>This is a common practice in CI/CD pipelines and local development to ensure comprehensive analysis across the entire project.


title: HISTORY
content:
<I>go vet</I> originated as a standalone tool, <I>vet</I>, existing even before the Go language's open-source release. It was later integrated into the standard <I>go</I> command as <I>go tool vet</I>, and then made directly accessible via <I>go vet</I>. Its consistent presence in the Go toolchain underscores the language's strong emphasis on tooling for code quality and correctness. Over time, new checkers have been added, and existing ones improved, making it an increasingly robust and essential part of the Go development workflow.


title: PARAMETERS
content:
<b>-f &lt;log_file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the path to the input log file to parse. Use '-' to read from standard input.</i><br><br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables parsing and tracking of User-Agents.</i><br><br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables parsing and tracking of hostnames. Requires a DNS resolver to be enabled.</i><br><br><br><b>-p &lt;config_file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a custom configuration file instead of the default.</i><br><br><br><b>--log-format=&lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Manually sets the log format string. Refer to the configuration file for syntax.</i><br><br><br><b>--date-format=&lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Manually sets the date format string. Refer to the configuration file for syntax.</i><br><br><br><b>--time-format=&lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Manually sets the time format string. Refer to the configuration file for syntax.</i><br><br><br><b>-o &lt;output_file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the HTML, JSON, or CSV report to the specified file. The output format is determined by the file extension.</i><br><br><br><b>--real-time-html</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables real-time HTML report generation with WebSocket support.</i><br><br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a default configuration file to stdout.</i><br><br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables ncurses colored metrics on the terminal output.</i><br><br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppresses output to the terminal, useful when only generating a report file.</i><br><br><br><b>--ignore-ip=&lt;IP&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Ignores the specified IP address from the statistics.</i><br><br><br>


title: DESCRIPTION
content:
GoAccess is an open-source, real-time web log analyzer and interactive viewer that runs in a terminal or through your browser. It provides fast and insightful HTTP statistics for system administrators who require a visual server report on the fly. It parses web server access logs (e.g., Apache, Nginx, Amazon S3, CloudFront) and displays a comprehensive set of metrics including unique visitors, requested files, static files, 404s, hosts, operating systems, browsers, referrers, keywords, HTTP status codes, geo-location, and more. GoAccess can process logs incrementally and provide a real-time HTML report, making it ideal for monitoring live traffic. Its ability to parse various log formats and output to multiple formats (interactive terminal, HTML, JSON, CSV) makes it a versatile tool for web analytics and server health monitoring.


title: CAVEATS
content:
<i>While GoAccess is highly efficient, processing extremely large log files (multiple gigabytes) can still consume significant memory and CPU resources, especially when parsing extensive datasets like User-Agents or DNS lookups. For real-time HTML output, ensure that WebSocket connections are properly handled by your web server or proxy to allow updates. Accurate parsing heavily relies on correctly defining the log, date, and time formats; misconfigurations can lead to incorrect or incomplete statistics.</i>


title: <B>INTERACTIVE TERMINAL UI</B>
content:
<i>GoAccess provides an interactive terminal user interface that allows users to explore various statistics by navigating through different modules and sorting data. This is its default mode when no output file is specified.</i><br>


title: <B>CUSTOMIZABLE LOG FORMATS</B>
content:
<i>A key strength of GoAccess is its flexibility in parsing custom log formats. Users can define their log, date, and time formats using directives, making it compatible with virtually any web server log, CDN log (e.g., CloudFront), or load balancer log.</i><br>


title: <B>MULTIPLE OUTPUT FORMATS</B>
content:
<i>Beyond its interactive terminal view, GoAccess can export reports to HTML (for browser viewing, including real-time updates), JSON (for programmatic consumption), and CSV (for spreadsheet analysis). This versatility caters to different reporting and integration needs.</i><br>


title: HISTORY
content:
<i>GoAccess was initially released in 2010 by Gerardo Gallard as an open-source project. It was developed to address the need for a simple, fast, and real-time web log analyzer that could run directly in the terminal, offering an alternative to more complex or resource-intensive solutions. Its development has been driven by community contributions, adding support for various log formats, real-time HTML output, and numerous statistical modules, solidifying its position as a popular choice for quick web server insights.</i>


title: SEE ALSO
content:
<i>grep(1)</i><br>, <i>awk(1)</i><br>, <i>sed(1)</i><br>, <i>tail(1)</i><br>, <i>apachetop</i><br>, <i>webalizer</i><br>, <i>awstats</i><br>


title: SYNOPSIS
content:
<b>gocr</b> [<i>options</i>] &lt;<i>image-file</i>&gt;<br><b>gocr</b> [<i>options</i>] -i &lt;<i>image-file</i>&gt; [<i>-o &lt;output-file&gt;</i>]


title: PARAMETERS
content:
<b>-i &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input image file. If omitted, the image file can be provided as a direct argument after the options.<br><br><b>-o &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output text file for the OCR result. If omitted, the recognized text is printed to standard output (<i>stdout</i>).<br><br><b>-C &lt;charset&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a custom character set to recognize (e.g., '0123456789' for digits only). Characters not in this set will be ignored or marked as unknown.<br><br><b>-b &lt;level&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables barcode detection with a specified level (0=off, 1=on, higher values for more strict detection). Experimental feature.<br><br><b>-c &lt;char&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the character to use for unrecognized characters (e.g., '?' or ' '). By default, <i>gocr</i> might use an underscore '_'.<br><br><b>-d &lt;level&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for internal diagnostics, from 0 (no debug) to higher values for more verbose output, useful for troubleshooting.<br><br><b>-e &lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables experimental enhanced OCR features, with different values indicating specific enhancements or algorithms.<br><br><b>-f &lt;format&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., 'text' for plain text, 'html' for HTML, 'xml' for XML). Defaults to plain text.<br><br><b>-l &lt;lang&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the OCR language to use (e.g., 'en' for English, 'de' for German, 'fr' for French). Affects character set and dictionary lookups.<br><br><b>-m &lt;mode&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the OCR mode of operation (e.g., 1 for line mode, 2 for paragraph mode), influencing how text blocks are processed.<br><br><b>-p &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to font training files, if custom fonts are used or for fine-tuning recognition.<br><br><b>-r &lt;degrees&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rotates the input image by the specified degrees (e.g., 90, 180, 270) clockwise before performing OCR, useful for incorrectly oriented scans.<br><br><b>-s &lt;lines&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of scanlines per character for fine-tuning character recognition, impacting how <i>gocr</i> segments characters.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>gocr</i> program.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with available options and their usage.<br><br>


title: DESCRIPTION
content:
<br><i>gocr</i> (also known as <i>JOCR</i>) is a free and open-source optical character recognition (OCR) program designed to convert scanned images of text into plain text files. Initiated by Joerg Schulenburg in 1999, it aims to provide a lightweight solution for text extraction from images. It supports various image formats, including PNM, PGM, PPM, GIF, PNG, JPG, BMP, and TIFF, often leveraging external libraries like ImageMagick or NetPBM for robust format handling.<br><br>While not as sophisticated or accurate as some modern OCR engines like <i>Tesseract</i>, <i>gocr</i> is valued for its simplicity, minimal dependencies, and its ability to run efficiently on systems with limited resources. It is particularly useful for basic OCR tasks or integration into scripts where a straightforward command-line OCR tool is required. Its output can be directed to standard output or a specified file, making it flexible for piping and further text processing in automated workflows.


title: CAVEATS
content:
<b>Accuracy:</b> <i>gocr</i> is generally less accurate than modern OCR engines like <i>Tesseract</i>, especially on complex layouts, noisy images, or non-standard fonts.<br><b>Image Quality:</b> It performs best with relatively clean, high-contrast, and well-scanned images. Poor image quality significantly degrades recognition results.<br><b>Language Support:</b> While it supports multiple languages, its recognition quality for non-English languages might vary and may not be as robust as other, more extensively trained tools.<br><b>Limited Features:</b> Lacks advanced features such as comprehensive layout analysis, table recognition, or handwriting OCR, which are found in more sophisticated solutions.


title: INTEGRATION WITH IMAGE PROCESSING TOOLS
content:
<i>gocr</i> often yields the best results when used in conjunction with image processing utilities like <i>ImageMagick</i> (e.g., <b>convert</b>) or <i>NetPBM</i> tools. These tools can be used to pre-process images by performing tasks such as deskewing, binarization, noise reduction, or contrast enhancement, which significantly improve <i>gocr</i>'s OCR accuracy.


title: STANDARD INPUT/OUTPUT USAGE
content:
A key strength of <i>gocr</i> for scripting is its ability to read image data from standard input (<i>stdin</i>) and write recognized text to standard output (<i>stdout</i>). This makes it highly suitable for piping within shell scripts, allowing seamless integration into complex text processing pipelines. For example, <b>cat image.pnm | gocr -o - | less</b> could process an image and display its text content.


title: HISTORY
content:
<i>gocr</i> was initiated by Joerg Schulenburg in 1999 as one of the early attempts to create a free and open-source OCR solution for Linux and other Unix-like systems. Its development aimed to provide a lightweight command-line tool that could be easily integrated into scripts and workflows. Over the years, it has seen contributions from various developers, becoming a notable option for those seeking a simple OCR utility without heavy dependencies, particularly suitable for basic tasks and systems with limited resources.


title: SYNOPSIS
content:
<b>gocryptfs</b> [<i>OPTIONS</i>] <<i>ciphertext-directory</i>> [<<i>plaintext-mountpoint</i>>]<br><b>gocryptfs</b> <b>-init</b> [<i>OPTIONS</i>] <<i>ciphertext-directory</i>><br><b>gocryptfs</b> <b>-fsck</b> [<i>OPTIONS</i>] <<i>ciphertext-directory</i>>


title: PARAMETERS
content:
<b><<i>ciphertext-directory</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory where encrypted data will be stored or is already located. This directory holds the encrypted files and the <i>gocryptfs.conf</i> configuration.<br><br><b><<i>plaintext-mountpoint</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory where the decrypted contents will be accessible. This is the mount point for the <i>gocryptfs</i> filesystem. If omitted during a mount operation, <i>gocryptfs</i> will try to use the current directory as the mount point.<br><br><b><b>-init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <i>gocryptfs</i> filesystem in the specified <<i>ciphertext-directory</i>>. This command prompts for a password and creates the necessary configuration files and directory structure.<br><br><b><b>-fsck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the integrity of a <i>gocryptfs</i> filesystem. It verifies the ciphertext files against their stored authentication tags to detect corruption or tampering.<br><br><b><b>-config</b> <<i>file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file instead of the default <i>gocryptfs.conf</i> located within the <<i>ciphertext-directory</i>>.<br><br><b><b>-passwd</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the password for an existing <i>gocryptfs</i> filesystem. You will be prompted for the old and new passwords.<br><br><b><b>-allow_other</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows other users to access the mounted filesystem. This is a FUSE option and typically requires <i>user_allow_other</i> to be set in <i>/etc/fuse.conf</i>.<br><br><b><b>-ro</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mounts the filesystem in read-only mode. No changes can be made to the underlying encrypted data through this mount point.<br><br><b><b>-nonempty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows mounting the filesystem on a directory that is not empty. Existing files or directories in the mountpoint will be hidden by the mounted filesystem until it is unmounted.<br><br><b><b>-fg</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <i>gocryptfs</i> in the foreground. By default, it forks into the background after a successful mount. This option is useful for debugging or when running from a script that manages the lifecycle of the mount.<br><br><b><b>-reverse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mounts the filesystem in reverse mode. In this mode, the <<i>ciphertext-directory</i>> becomes the plaintext source, and the <<i>plaintext-mountpoint</i>> becomes the *encrypted view* of that source. Useful for encrypting data on the fly before syncing it to cloud storage.<br><br><b><b>-masterkey</b> <<i>key</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the master key directly as a hexadecimal string. This bypasses the password prompt and can be used for automated mounting scenarios, though care must be taken with key exposure.<br><br>


title: DESCRIPTION
content:
<i>gocryptfs</i> is a FUSE-based encrypted overlay filesystem written in Go. It allows users to encrypt a directory's contents and access them as a plaintext directory. All files, filenames, and symlink targets are encrypted and authenticated using modern cryptographic primitives like AES-GCM or AES-SIV. The primary goal of <i>gocryptfs</i> is to provide a simple, robust, and secure way to store confidential data in untrusted locations, such as cloud storage services or shared drives. It supports various modes including forward mode (encrypting data as it's written) and reverse mode (creating an encrypted view of an existing plaintext directory), making it versatile for different use cases. It aims for high performance and strong cryptographic guarantees while maintaining a straightforward design.


title: CAVEATS
content:
Performance overhead: While optimized, encryption and decryption operations inherently introduce some CPU and I/O overhead.<br>Metadata leakage: Although file contents and names are encrypted, some metadata like directory structure, number of files, file modification times, and approximate file sizes (block-aligned) might be discernible.<br>No hard links across boundary: Hard links are not supported across the encryption boundary (i.e., between plaintext and ciphertext views).<br>FUSE dependency: <i>gocryptfs</i> relies on the FUSE (Filesystem in Userspace) kernel module and user-space libraries, which must be installed and properly configured.<br>Improper unmount: Forcibly unmounting (e.g., due to system crash or power loss) can potentially leave the filesystem in a dirty state, requiring <i>fsck</i> to verify and repair integrity.


title: REVERSE MODE EXPLAINED
content:
The <b>-reverse</b> option is a powerful and unique feature of <i>gocryptfs</i>. Unlike the standard forward mode where you put encrypted data into the <<i>ciphertext-directory</i>> to view it as plaintext at the <<i>plaintext-mountpoint</i>>, reverse mode flips this. In reverse mode, your <<i>ciphertext-directory</i>> becomes the source of *plaintext* data, and the <<i>plaintext-mountpoint</i>> becomes an *encrypted view* of that data. This is extremely useful for backing up or syncing existing directories (e.g., your 'Documents' folder) to cloud storage, as your original plaintext data remains untouched in its location, while the cloud service only receives the encrypted representation.


title: HISTORY
content:
<i>gocryptfs</i> was initially developed by Arnau Sanchez and first released around 2016. It was conceived as a modern, Go-language alternative to older encrypted filesystem solutions like <i>encfs</i>, aiming for a simpler, more auditable codebase and leveraging up-to-date cryptographic primitives (such as authenticated encryption modes). Its development focused on providing a secure and performant encrypted overlay filesystem that is easy to use and deploy, particularly for scenarios involving cloud synchronization where data privacy is paramount.


title: PARAMETERS
content:
<b>-http</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start an HTTP server to serve documentation on the specified address (e.g., <i>:6060</i>).<br><br><b>-src</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the source code of the requested package or symbol.<br><br><b>-url</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the URL to <i>godoc.org</i> for the given package or symbol.<br><br><b>-html</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the documentation in HTML format to standard output.<br><br><b>-goroot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative <i>GOROOT</i> directory to find Go source files.<br><br><b>-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable the search index for faster searching in HTTP mode.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging, showing more information about operations.<br><br>


title: DESCRIPTION
content:
The <b>godoc</b> command provides a way to display documentation for Go packages, types, functions, and methods. It parses Go source code and extracts documentation comments, presenting them in a human-readable format. This command can be used in two primary modes: as a command-line tool to print documentation directly to the console, or as an HTTP server to serve documentation through a web browser. When run as an HTTP server, it can browse all installed Go packages, their source code, and examples, making it an invaluable tool for Go developers to explore the standard library and third-party modules without an internet connection. It integrates directly with the Go module system and the <i>GOROOT</i> environment variable to locate source files.


title: CAVEATS
content:
The standalone <b>godoc</b> command is largely considered <i>deprecated</i> in modern Go environments. Its primary functionality for command-line display has been superseded by the <b>go doc</b> subcommand. For serving local documentation via HTTP, <b>go doc -http</b> offers similar capabilities. Furthermore, in recent Go versions, the <b>godoc</b> binary is no longer bundled with the standard Go distribution and must be installed separately via <b>go install golang.org/x/tools/cmd/godoc@latest</b>. This makes it less commonly used directly by developers today, who prefer the integrated <b>go doc</b> or <i>pkg.go.dev</i>.


title: WEB SERVER FUNCTIONALITY
content:
When run with the <b>-http</b> option, <b>godoc</b> transforms into a local web server. By default, it often listens on <i>localhost:6060</i>. Navigating to this address in a web browser allows users to browse all Go packages, search for symbols, and view their source code, acting as a personal, offline version of <i>pkg.go.dev</i>.


title: INTEGRATION WITH GO MODULES
content:
<b>godoc</b> (and <b>go doc</b>) automatically resolves and displays documentation for modules located in your <i>GOPATH</i> or module cache, providing a seamless experience for projects using Go Modules.


title: HISTORY
content:
The <b>godoc</b> command was a foundational tool in the early days of the Go programming language, providing a unified and accessible way to view documentation directly from Go source code. It was notable for its ability to generate comprehensive documentation on-the-fly and serve it via a built-in HTTP server, a feature that significantly enhanced developer productivity by allowing offline access to the entire Go standard library documentation. As the Go ecosystem matured, some of <b>godoc</b>'s functionalities were integrated into the main <b>go</b> command, particularly the console-based documentation viewing through <b>go doc</b>. This evolution led to the standalone <b>godoc</b> binary becoming less central, eventually being moved out of the standard Go distribution in favor of <b>go doc</b> and external tools/services like <i>pkg.go.dev</i>, while still being available for separate installation.


title: SYNOPSIS
content:
<i>godot</i> [<i>OPTIONS</i>] [<i>PROJECT_PATH</i>]<br><i>godot --editor</i><br><i>godot --export &lt;PRESET_NAME&gt; &lt;EXPORT_PATH&gt;</i>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive list of all available command-line options and their descriptions.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed Godot Engine version to the console.<br><br><b>--path &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the absolute or relative path to a Godot project folder. If provided, the engine will attempt to run or operate on this project.<br><br><b>--export &lt;preset_name&gt; &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports the currently loaded project using the specified export preset name to the given output path. The preset name must match one defined in the project's export manager.<br><br><b>--export-debug &lt;preset_name&gt; &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <i>--export</i>, but exports a debug version of the project, often including console output and debug symbols.<br><br><b>--editor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the Godot editor to launch, even if a project path is provided or if the engine would normally run the project directly.<br><br><b>--quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits the engine automatically after completing any specified tasks, such as exporting a project or running a script.<br><br><b>--headless</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Godot engine in a headless mode, meaning it runs without a graphical interface. This is crucial for dedicated servers, automated tests, or CI/CD environments.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging output, providing more detailed information about the engine's operations, which can be useful for debugging.<br><br>


title: DESCRIPTION
content:
The <b>godot</b> command refers to the command-line interface for the Godot Engine, a free and open-source game engine renowned for its 2D and 3D game development capabilities. While Godot primarily features a graphical editor, its command-line tool is indispensable for various automated tasks, continuous integration (CI/CD) pipelines, and headless operations. Developers can use the command to run projects directly, export games for different platforms (e.g., Windows, macOS, Linux, Web, Android), launch the editor with specific settings, or perform batch operations without user interaction. It offers a powerful way to integrate game development workflows into scripting environments, enabling efficient project management and deployment.


title: CAVEATS
content:
The availability and exact behavior of the <b>godot</b> command depend on whether the Godot Engine is installed on your system and its executable is accessible in the system's PATH. Command-line options can vary between different major and minor versions of the Godot Engine. It's primarily a specialized developer tool and not a general-purpose system utility.


title: RUNNING A PROJECT FROM THE CLI
content:
To quickly test a Godot project without opening the editor, you can navigate to the project's root directory and simply type <i>godot</i>. Alternatively, you can specify the project path directly: <i>godot --path /home/user/my_game_project</i>. This is ideal for rapid iteration or running game servers.


title: AUTOMATED EXPORTS FOR CI/CD
content:
The <b>godot</b> command-line export functionality is fundamental for continuous integration and continuous deployment pipelines. By running commands like <i>godot --export 'Linux/X11' ./build/my_game.x86_64 --quit</i>, developers can automate the build process, ensuring consistent and reproducible game releases without manual intervention.


title: HISTORY
content:
Godot Engine was conceived by Juan Linietsky and Ariel Manzur in 2007 as an in-house engine for various game development projects. It was publicly released as open-source software under the MIT license in 2014, gaining significant traction due to its flexibility, feature set, and active community. The command-line interface has been a core component from early versions, continuously evolving to support more complex automation and integration needs as the engine matured.


title: PARAMETERS
content:
<b><B>install</B> <I>&lt;version&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specific Go version. For example, <I>goenv install 1.18.1</I>.<br><br><b><B>uninstall</B> <I>&lt;version&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a previously installed Go version from your system.<br><br><b><B>global</B> [<I>&lt;version&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the global Go version. If no version is specified, it shows the current global version. This version is used if no local or shell version is defined.<br><br><b><B>local</B> [<I>&lt;version&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the project-specific Go version. This creates a <I>.go-version</I> file in the current directory, which takes precedence over the global version.<br><br><b><B>shell</B> [<I>&lt;version&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Go version for the current shell session. This takes precedence over both local and global versions, and is typically temporary.<br><br><b><B>versions</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed Go versions and indicates the currently active one with an asterisk.<br><br><b><B>version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the currently active Go version determined by <I>goenv</I>.<br><br><b><B>rehash</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebuilds the shim binaries for all installed Go versions. This is necessary after installing new Go tools or commands via <I>go install</I> from a specific Go version.<br><br><b><B>exec</B> <I>&lt;command&gt;</I> [<I>&lt;args&gt;</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a Go command using the currently active Go version, bypassing shims. Useful for scripting.<br><br><b><B>which</B> <I>&lt;command&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the full path to the executable that <I>goenv</I> would use for the given command, based on the current version.<br><br><b><B>root</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the directory where <I>goenv</I> stores its installed Go versions and shims (typically <I>~/.goenv</I>).<br><br>


title: DESCRIPTION
content:
<I>goenv</I> is a command-line utility designed to simplify the process of managing multiple Go programming language versions on a single machine. It allows developers to easily switch between different Go installations, ensuring that the correct version is used for specific projects or globally. <br><br>Unlike other version managers that might modify system paths directly, <I>goenv</I> operates using a non-invasive shim mechanism. When you invoke a Go command (like <I>go build</I> or <I>go run</I>), <I>goenv</I> intercepts the call and directs it to the appropriate Go executable based on the version configured for your current directory, your shell session, or globally. This functionality is achieved by inserting <I>goenv</I>'s shim directory at the front of your <B>$PATH</B> environment variable. <br><br>This tool is particularly useful for teams working on projects that require different Go versions, or for individual developers who need to test their code against various Go releases. It helps in maintaining a clean development environment, avoiding conflicts that can arise from conflicting Go installations.


title: CAVEATS
content:
For <I>goenv</I> to function correctly, it requires proper shell integration. This usually involves adding <I>eval "$(goenv init -)"</I> to your shell's profile file (e.g., <I>~/.bashrc</I>, <I>~/.zshrc</I>, <I>~/.config/fish/config.fish</I>). Without this, the necessary environment variables and shims will not be loaded. Additionally, <I>goenv</I> relies on your system having the necessary build tools (like a C compiler, <I>git</I>, etc.) to compile Go from source, which is how <I>goenv install</I> often operates. It does not manage Go modules directly, but manages the Go toolchain that handles modules.


title: INSTALLATION AND SETUP
content:
After installing <I>goenv</I> (e.g., via <I>git clone</I> or a package manager), you must initialize it in your shell. Add the following line to your shell's configuration file (<I>~/.bashrc</I>, <I>~/.zshrc</I>, etc.): <br><br> <I>echo 'eval "$(goenv init -)"' >> ~/.bashrc</I> <br><br> Then, restart your shell or run <I>source ~/.bashrc</I> (or your respective config file) for the changes to take effect. This command sets up the necessary <B>$PATH</B> modifications and shell functions that enable <I>goenv</I>'s version switching capabilities.


title: HOW SHIMS WORK
content:
<I>goenv</I> uses shims to intercept Go commands. When <I>goenv</I> is initialized, its shim directory (e.g., <I>~/.goenv/shims</I>) is prepended to your <B>$PATH</B>. This directory contains lightweight executable files (shims) for every Go command (like <I>go</I>, <I>gofmt</I>, <I>go install</I>). When you run a command like <I>go build</I>, your shell finds the <I>goenv</I> shim first. The shim then determines which Go version to use based on the global, local (via <I>.go-version</I> file), or shell configuration, and executes the actual Go command from that version's installation directory, transparently redirecting the command call.


title: HISTORY
content:
<I>goenv</I> emerged as part of a family of version management tools, heavily inspired by the success of <I>rbenv</I> for Ruby. The motivation behind its creation was to provide a similar, lightweight, and unintrusive method for managing multiple versions of the Go programming language. Its design principles emphasize simplicity and reliance on core shell features like <B>$PATH</B> manipulation and command shims, rather than modifying system-wide configurations or requiring elevated privileges. This approach allows developers to maintain isolated and reproducible Go development environments effortlessly, a common need in modern software development.


title: SYNOPSIS
content:
<b>gofmt</b> [<i>flags</i>] [<i>path ...</i>]<br><b>gofmt</b> [<i>flags</i>] [<i>file ...</i>]<br>When no <i>path</i> or <i>file</i> is given, <i>gofmt</i> processes the standard input.


title: PARAMETERS
content:
<b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files whose formatting differs from <i>gofmt</i>'s output. Does not write to files.<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write result to source file instead of standard output. This is the most common and recommended flag for modifying files.<br><br><b><b>-r</b> <i>rule</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply rewrite <i>rule</i>s to the source code. Rules are of the form '<i>pattern</i> -> <i>replacement</i>' and are applied as Go AST transformations.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simplify code. This flag is enabled by default when using <b>-r</b>, applying common Go idiom simplifications.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display diffs of the formatting changes on standard output. The output format is similar to <i>diff -u</i>.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report all parsing errors, not just the first one encountered during processing.<br><br><b><b>-cpuprofile</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write a CPU profile to the specified <i>file</i>, useful for debugging performance issues with <i>gofmt</i> itself.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print verbose information, including details about the files and directories being processed.<br><br><b><b>-local</b> <i>prefix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only consider packages whose import path begins with <i>prefix</i> to be local to the current module or project.<br><br>


title: DESCRIPTION
content:
<i>gofmt</i> is a fundamental tool within the Go programming language ecosystem that automatically formats Go source code according to the official Go programming language style.<br>It operates by parsing the Go source code into an abstract syntax tree (AST) and then printing that AST back into source code format following a predefined set of formatting rules.<br>This process ensures that all Go code formatted by <i>gofmt</i> adheres to a single, canonical style, promoting universal readability and consistency across different projects and developers.<br>It's an essential part of the Go development workflow, often integrated into IDEs, build systems, or pre-commit hooks, effectively eliminating stylistic disagreements and allowing developers to focus purely on the code's logic rather than its aesthetic presentation.


title: CAVEATS
content:
<i>gofmt</i> enforces a strict, opinionated style with no configurable options for customization (e.g., indent size, brace style).<br>This deliberate design choice is intended to eliminate stylistic debates but can be a point of adjustment for developers accustomed to highly configurable code formatters.


title: USAGE WITH THE <B>GO</B> COMMAND
content:
While <i>gofmt</i> can be run directly, it is most frequently invoked via the <b>go fmt</b> subcommand.<br><b>go fmt</b> automatically applies <i>gofmt</i> to all Go source files within the current module or specified packages, making it a convenient wrapper.


title: DETERMINISTIC OUTPUT
content:
A fundamental characteristic of <i>gofmt</i> is its deterministic output. For any given Go source input, it will always produce the exact same formatted output, irrespective of the operating system, environment, or previous formatting.<br>This property is crucial for automated tooling, continuous integration, and maintaining consistent codebases without unnecessary diffs.


title: HISTORY
content:
<i>gofmt</i> was developed as an integral part of the Go programming language project, conceived by Rob Pike.<br>It was released with the initial public release of Go (Go 1.0) in March 2012, though its core principles and implementation were present in early Go development.<br>Its creation was motivated by a strong desire to eliminate style debates and ensure that all Go code is consistently readable across the entire ecosystem, fostering a uniform appearance that significantly aids in code comprehension and review processes.


title: PARAMETERS
content:
<b>-local <i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of Go package prefixes considered 'local' to the current project. Imports with these prefixes are grouped separately, typically after standard library and third-party imports.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write result to the source file instead of standard output. This flag is crucial for in-place modifications.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display diffs instead of writing to the file. This shows what changes <i>goimports</i> would make without applying them.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List files whose formatting would change. Useful for continuous integration checks.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report all errors, not just the first one.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging.<br><br><b>-f <i>file</i> | <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file or directory to process. If omitted, <i>goimports</i> processes the current directory ('.') if no paths are given, or standard input.<br><br><b>-cpuprofile <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write a CPU profile to the specified file.<br><br><b>-memprofile <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write a memory profile to the specified file.<br><br><b>-srcdir <i>dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for source files in the specified directory.<br><br><b>-tabwidth <i>n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set tab width to <i>n</i> (default 8).<br><br><b>-tabindent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indent with tabs instead of spaces.<br><br>


title: DESCRIPTION
content:
<i>goimports</i> is a Go tool that automatically adds missing import paths and removes unused ones for Go source files. It also formats your Go code consistent with <i>gofmt</i>'s style. This ensures that Go source files are well-formatted and have correctly managed import statements, which is crucial for code readability and compilation. It can process individual files, directories, or standard input, making it highly versatile for use in development workflows, build systems, or text editors. By automating import management, <i>goimports</i> significantly reduces manual effort and potential errors associated with dependency declarations in Go projects.


title: CAVEATS
content:
When using the <b>-w</b> flag, <i>goimports</i> modifies files in place; it is always recommended to use version control. It operates on syntactically valid Go code; severe parsing errors may cause it to fail. It relies on the Go module system and environment configuration (e.g., GOPATH) to resolve import paths, which must be correctly set up.


title: INTEGRATION WITH IDES/EDITORS
content:
<i>goimports</i> is widely integrated into popular Go development environments and text editors (e.g., VS Code, GoLand, Vim, Emacs) through language server protocols or specific plugins. This allows for automatic import management and formatting on save, greatly enhancing developer productivity.


title: DETERMINISM
content:
The output of <i>goimports</i> is deterministic, meaning that for the same input and configuration, it will always produce the same output. This is crucial for maintaining consistent code style across teams and for use in automated build or CI/CD pipelines.


title: HISTORY
content:
<i>goimports</i> emerged as a powerful extension to the standard <i>gofmt</i> tool within the Go ecosystem. While <i>gofmt</i> focuses purely on code formatting, <i>goimports</i> adds the intelligence of managing <b>import</b> statements automatically. It was developed to simplify the often tedious task of adding and removing package imports manually, especially in larger projects with many dependencies. Its integration into various Go IDEs and editors has made it an indispensable tool for Go developers, promoting consistent code style and correct dependency management from the early stages of development.


title: SYNOPSIS
content:
<b>golangci-lint</b> <I>command</I> [<I>flags</I>]<br><br>Common commands:<br>&bull; <I>run</I>: Runs linters on the specified paths.<br>&bull; <I>fix</I>: Automatically fixes issues reported by linters.<br>&bull; <I>linters</I>: Lists all supported linters.<br>&bull; <I>version</I>: Prints the golangci-lint version.<br><br>Example: <I>golangci-lint run ./...</I><br>Example with flags: <I>golangci-lint run --config .golangci.yml --timeout 5m</I>


title: PARAMETERS
content:
<b>--config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file path.<br><br><b>--enable <linter></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable a specific linter. Can be used multiple times.<br><br><b>--disable <linter></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable a specific linter. Can be used multiple times.<br><br><b>--skip-dirs <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip directories matching the specified glob pattern.<br><br><b>--out-format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format (e.g., <I>github-actions</I>, <I>json</I>, <I>tab</I>, <I>line</I>).<br><br><b>--issues-exit-code <int></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit code to use when issues are found (default 1).<br><br><b>--fix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically fix issues (if supported by linters and the <I>fix</I> command is used).<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about execution.<br><br><b>--timeout <duration></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum duration for linters execution (e.g., <I>5m</I>, <I>30s</I>).<br><br><b>--concurrency <int></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of linters to run in parallel.<br><br><b>--path-prefix <prefix></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path prefix to remove from output file paths for cleaner reports.<br><br><b>--print-resources-usage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print CPU and memory resources usage of linters at the end of execution.<br><br>


title: DESCRIPTION
content:
golangci-lint is a powerful command-line interface tool designed to orchestrate and run multiple Go linters efficiently. It aggregates the results from various static analysis tools, such as <I>go vet</I>, <I>errcheck</I>, <I>staticcheck</I>, and many others, into a single, comprehensive report. The primary goal of golangci-lint is to significantly speed up the linting process by running linters in parallel and caching their results. It provides a unified configuration file (<I>.golangci.yml</I>) to enable, disable, and configure individual linters, making it easier for developers to maintain code quality and consistency across projects. This tool is widely adopted in Go development workflows, especially in CI/CD pipelines, to enforce coding standards and catch potential issues early in the development cycle.


title: CAVEATS
content:
While designed for speed, <I>golangci-lint</I> can still be resource-intensive on very large codebases, potentially consuming significant CPU and memory. Fine-tuning its extensive configuration for specific project needs can sometimes be complex. Users should also be aware that some linters might occasionally produce false positives, requiring careful consideration and potential issue-specific filtering.


title: SUPPORTED LINTERS
content:
<I>golangci-lint</I> aggregates a vast collection of Go linters, supporting over 100 different static analysis tools. Users can view the full list of supported linters by running the command <I>golangci-lint linters</I>.


title: CONFIGURATION FILE (<I>.GOLANGCI.YML</I>)
content:
The tool leverages a powerful YAML configuration file, typically named <I>.golangci.yml</I>, to define its behavior. This file allows users to enable or disable specific linters, fine-tune individual linter settings, filter issues based on severity or pattern, and customize output formats. This centralized configuration greatly simplifies project-wide code quality enforcement.


title: HISTORY
content:
<I>golangci-lint</I> emerged around 2018 as a comprehensive solution to the growing challenge of managing numerous individual Go linters. Before its development, developers often had to manually install and configure dozens of separate linter tools, leading to inefficiencies and inconsistent code quality checks. The project's core objective was to provide a single, fast, and opinionated tool that could run all these linters in parallel with unified configuration and output. Its focus on performance, ease of use, and broad linter coverage quickly led to its widespread adoption, establishing it as a standard for Go code quality checks in both development environments and CI/CD pipelines.


title: SYNOPSIS
content:
<I>python goldeneye.py &lt;target_url&gt; [options]</I><br><br><b>Examples:</b><br><br>Perform a basic HTTP flood on example.com with 10 workers:<br><I>python goldeneye.py http://example.com -w 10</I><br><br>Conduct an HTTPS flood for 300 seconds using 500 sockets per worker:<br><I>python goldeneye.py https://secure.example.com -s 500 -d 300 --ssl</I>


title: PARAMETERS
content:
<b><code>&lt;target_url&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the target web server to attack (e.g., http://example.com/).<br><br><b><code>-w, --workers &lt;num&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of concurrent workers (threads) to use for the attack. Default is usually 50.<br><br><b><code>-s, --sockets &lt;num&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of sockets each worker should create. Default is typically 70.<br><br><b><code>-m, --method &lt;method&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the HTTP method to use for requests (e.g., GET, POST, HEAD). Default is GET.<br><br><b><code>-d, --duration &lt;seconds&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the duration of the attack in seconds. The attack will stop automatically after this period.<br><br><b><code>-u, --user-agents &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of custom user agents to be used, one per line. If not specified, default randomized user agents are used.<br><br><b><code>-r, --referers &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of custom referer URLs, one per line. Default is randomized.<br><br><b><code>-p, --proxy &lt;proxy_url&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a proxy server to route traffic through (e.g., http://proxy.com:8080). Can be used for anonymity.<br><br><b><code>--data &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing data to be sent with POST requests. Required if <code>-m POST</code> is used.<br><br><b><code>--headers &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing custom HTTP headers to include in requests, one header per line (e.g., 'X-Custom-Header: value').<br><br><b><code>--ssl</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of HTTPS (SSL/TLS) for requests, even if the target URL is HTTP.<br><br><b><code>--random-param</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends a random parameter to the URL, helping to bypass caching mechanisms.<br><br><b><code>--disable-logging</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables console output during the attack.<br><br><b><code>--help</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
GoldenEye is a Python-based HTTP/HTTPS flood tool designed to perform Denial-of-Service (DoS) attacks on web servers. It operates by generating a large volume of concurrent HTTP/HTTPS requests, often leveraging unique user agents and varying HTTP methods, to overwhelm the target server's resources. The tool aims to exhaust server capacity by keeping connections open and continuously requesting resources, making the target unavailable to legitimate users. It's often used in penetration testing environments to assess web server resilience, though its use for malicious purposes is illegal and unethical.


title: CAVEATS
content:
GoldenEye is a DoS attack tool. Using it against any system or network without explicit, written permission from the owner is illegal and can lead to severe legal consequences, including fines and imprisonment. This analysis is for educational and informational purposes only. Do not use this tool for malicious activities.


title: ETHICAL AND LEGAL DISCLAIMER
content:
The information provided about 'goldeneye.py' is strictly for educational, research, and cybersecurity awareness purposes. Unauthorized access to or attacks against computer systems and networks are illegal and punishable by law. Users are solely responsible for their actions and must ensure they comply with all applicable laws and regulations. Never deploy tools like GoldenEye without explicit authorization.


title: OPERATION PRINCIPLES
content:
GoldenEye works by simulating a high volume of legitimate-looking web traffic. It attempts to maintain persistent connections to the target server, constantly sending partial or complete HTTP requests to consume server resources like CPU, memory, and network bandwidth. By continuously refreshing connections and varying request parameters (like user agents and referers), it tries to evade simple blocking rules and cache invalidation, thus maximizing the impact on the target.


title: HISTORY
content:
GoldenEye emerged as a popular open-source Python script for HTTP/HTTPS flood attacks, particularly noted for its simplicity and effectiveness. It gained traction among penetration testers and security enthusiasts for its ability to simulate DoS conditions, and unfortunately, also among malicious actors for actual attacks. Its development reflects the ongoing cat-and-mouse game between DoS tool developers and defensive measures, often being updated to bypass common mitigations like caching and rate limiting.


title: SYNOPSIS
content:
<b>gomi</b> [options] <I>files...</I><br><b>gomi</b> -l | --list<br><b>gomi</b> -r | --restore <I>item_id_or_name</I><br><b>gomi</b> -e | --empty


title: PARAMETERS
content:
<b><I>files...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more files or directories to move to the trash directory.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all items currently in the trash directory, often with their original path and deletion timestamp.<br><br><b>-r, --restore <I>item_id_or_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores a specified item from the trash back to its original location or a specified path. The item can often be identified by an ID from the list, or part of its original name.<br><br><b>-e, --empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permanently deletes all contents from the trash directory, freeing up disk space. This action is irreversible.<br><br>


title: DESCRIPTION
content:
<b>gomi</b> is not a standard command included with most Linux distributions.<br>Instead, it refers to a class of user-created scripts or utilities designed to provide a "trash" or "recycle bin" functionality, similar to graphical desktop environments.<br>Unlike the permanent deletion performed by the <b>rm</b> command, <i>gomi</i> scripts move specified files and directories to a designated hidden directory (the "trash can") on the filesystem.<br>This allows users to recover accidentally deleted files, preventing data loss.<br>The exact behavior, options, and trash location of a <i>gomi</i> implementation can vary widely, as it is typically a custom script written by individuals or small communities to suit their needs.


title: CAVEATS
content:
It is important to understand that <i>gomi</i> is not a standard Linux command; its existence and behavior depend entirely on whether a user or system administrator has installed or created such a script.<br>The functionality can vary significantly between different implementations.<br>Potential caveats include the trash directory consuming significant disk space over time if not regularly emptied, and the absence of a standardized trash directory location across all systems (though some follow the XDG Base Directory Specification for <b>~/.local/share/Trash</b>).


title: TRASH DIRECTORY LOCATION
content:
Custom <i>gomi</i> scripts typically store trashed files in a hidden directory within the user's home directory, such as <b>~/.trash</b> or <b>~/.gomi</b>.<br>More standardized implementations often follow the <I>XDG Base Directory Specification</I>, placing trashed files in <b>~/.local/share/Trash/</b>. This directory contains subdirectories for <b>files</b> and <b>info</b> (metadata about original paths and deletion dates).


title: HISTORY
content:
The concept of a 'trash can' or 'recycle bin' originated in graphical user interfaces (GUIs) to prevent accidental data loss. As Linux command-line users increasingly desired similar safety nets, various individuals and developers began creating shell scripts or simple utilities to emulate this behavior.<br>These scripts, often informally referred to as 'gomi' (Japanese for 'trash' or 'garbage'), typically leverage standard commands like <b>mv</b> to move files to a hidden directory rather than using the destructive <b>rm</b>.<br>While no single standard 'gomi' command emerged, the need led to more robust solutions like <i>trash-cli</i>, which standardize the trash handling according to XDG specifications, fulfilling the same core user requirement.


title: PARAMETERS
content:
<b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable score recording for the game.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure the computer opponent to play as Black stones.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure the computer opponent to play as White stones (human plays Black, which is the default).<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set up a game where the computer plays against itself.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable learning mode, where the computer plays against itself to generate random games.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the computer opponent to make the first move.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-randomize the initial seeds for game variation.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output during gameplay, showing more details.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trace moves, displaying the board state after each move for debugging or analysis.<br><br><b><b>-s</b> <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the board size (e.g., <i>-s 13</i> for a 13x13 board). The default size is 19x19.<br><br><b><b>-u</b> <i>undo_limit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of undos allowed per game (0 for unlimited undos; default is 3).<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit immediately after a game concludes, without prompting for a replay.<br><br><b><i>scorefile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative file path to save game scores (default: <i>$HOME/.gomoku_scores</i>).<br><br>


title: DESCRIPTION
content:
Gomoku is a strategy board game played on a grid, typically 19x19, where the objective is to be the first player to get an unbroken row of five of your stones either horizontally, vertically, or diagonally. The <b>gomoku</b> command-line utility provides a text-based interface to play this game in your terminal. It supports various game modes, including human vs. computer, computer vs. computer, and even a computer learning mode. Players can customize the board size, set undo limits, and view game traces. It also features score saving and offers various options for gameplay configuration and debugging. It is often distributed as part of the <i>bsdgames</i> package, bringing a traditional board game experience to the Linux command line.


title: CAVEATS
content:
The <b>gomoku</b> command provides a purely text-based interface and relies on the <i>curses</i> library for terminal rendering, which might exhibit minor visual differences across various terminal emulators or systems. The computer opponent's strength is fixed within its design and not configurable via command-line parameters. While supporting various board sizes, the default is 19x19.


title: INTERACTION
content:
During gameplay, players interact by entering coordinates for their moves (row and column). The game also supports various single-character commands for control:<br><ul><li><b>q</b> or <b>Q</b>: Quit the current game.</li><li><b>u</b> or <b>U</b>: Undo the last move.</li><li><b>.</b>: Replay the current game from the start.</li><li><b>!</b>: Execute a shell command.</li><li><b>^L</b>: Redraw the screen.</li><li><b>?</b>: Display in-game help.</li></ul>Moves are typically entered as <i>row column</i> (e.g., <i>10 10</i> to place a stone at the center of a 19x19 board).


title: HISTORY
content:
The <b>gomoku</b> command is a classic Unix game, often bundled within the <i>bsdgames</i> package, tracing its origins back to the early days of Unix. It provides a straightforward, terminal-based implementation of the traditional Japanese board game. It was authored by <i>John D. Polstra</i>, contributing to the rich legacy of interactive command-line utilities available on Unix-like systems.


title: SYNOPSIS
content:
<b>goobook</b> <I>[global_options]</I> <b>command</b> <I>[command_args]</I><br><br>Common commands:<br><b>goobook</b> <b>search</b> <I>[query]</I><br><b>goobook</b> <b>lookup</b> <I>contact_id</I><br><b>goobook</b> <b>add</b><br><b>goobook</b> <b>edit</b> <I>contact_id</I><br><b>goobook</b> <b>delete</b> <I>contact_id</I><br><b>goobook</b> <b>authorize</b><br><b>goobook</b> <b>clear-cache</b>


title: PARAMETERS
content:
<b><b>search</b> <I>[query]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches Google Contacts for entries matching the optional <I>query</I> (can be a string or regex).<br><br><b><b>lookup</b> <I>contact_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information for a specific contact identified by its unique <I>contact_id</I>.<br><br><b><b>add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively prompts the user to add a new contact to Google Contacts, opening an editor for details.<br><br><b><b>edit</b> <I>contact_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively edits an existing contact identified by its <I>contact_id</I>, opening an editor to modify its fields.<br><br><b><b>delete</b> <I>contact_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a contact by its <I>contact_id</I>. Requires user confirmation before deletion.<br><br><b><b>authorize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the OAuth2 authorization flow, opening a browser for you to grant <I>goobook</I> access to your Google Contacts.<br><br><b><b>clear-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clears the locally stored cache of Google Contacts, forcing a fresh download on the next operation.<br><br><b><b>import</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports contacts from the specified <I>file</I> (e.g., vCard, CSV) into Google Contacts.<br><br><b><b>export</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports all contacts from Google Contacts to the specified <I>file</I> (e.g., vCard, CSV).<br><br><b><b>help</b> <I>[command]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for <I>goobook</I> in general, or for a specific <I>command</I> if provided.<br><br><b><b>-c</b> <I>FILE</I>, <b>--config-file</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path for the configuration file.<br><br><b><b>-s</b>, <b>--show-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the display of ANSI colors in the output, even if not automatically detected.<br><br><b><b>-n</b>, <b>--no-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of ANSI colors in the output.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more detailed output, primarily useful for debugging purposes.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables extensive debug messages for in-depth troubleshooting.<br><br><b><b>--no-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from using or updating the local contact cache for the current operation.<br><br><b><b>-j</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in JSON format. Applicable to <I>search</I> and <I>lookup</I> commands.<br><br><b><b>-F</b> <I>FORMAT_STRING</I>, <b>--format</b>=<I>FORMAT_STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom output format string for results. Applicable to <I>search</I> and <I>lookup</I> commands.<br><br><b><b>-e</b>, <b>--exact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs an exact match search instead of a partial match. Applicable to the <I>search</I> command.<br><br><b><b>-f</b> <I>FIELDS</I>, <b>--fields</b>=<I>FIELDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the fields displayed in search results to a comma-separated list of field names. Applicable to the <I>search</I> command.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a general help message and exits the program.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the program's version number and exits.<br><br>


title: DESCRIPTION
content:
<I>goobook</I> is a command-line tool that provides a powerful interface to Google Contacts. It enables users to search, add, edit, and delete contacts directly from the terminal, making it highly convenient for scripting or quick lookups. The tool securely syncs with your Google account, retrieving and managing contact information without requiring a web browser. It is particularly useful for integrating contact management into shell scripts, email clients like <I>mutt</I>, or other text-based workflows, offering a fast and efficient way to interact with your address book.


title: CAVEATS
content:
Requires an initial OAuth2 authorization process to grant <I>goobook</I> access to your Google Contacts.<br>Relies on the Google Contacts API, which may change and potentially affect functionality.<br>Interactive modes (e.g., <I>add</I>, <I>edit</I>) require a text editor to be configured via the <I>EDITOR</I> environment variable.<br>Full functionality depends on appropriate network connectivity to Google's services.


title: CONFIGURATION AND AUTHENTICATION
content:
<I>goobook</I> stores its configuration and OAuth2 tokens (required for Google API access) in a user-specific configuration file, typically located at <I>~/.goobookrc</I>. The authorization step, usually performed once via the <B>authorize</B> command, securely manages the API token, which is then cached locally.


title: LOCAL CACHING
content:
To improve performance and reduce API calls, <I>goobook</I> maintains a local cache of your Google Contacts, often at <I>~/.goobook_cache.json</I>. This cache allows for faster retrieval of contact information on subsequent queries. Users can clear this cache with the <B>clear-cache</B> command or bypass it for a specific operation using the <B>--no-cache</B> option.


title: HISTORY
content:
<I>goobook</I> was developed by <I>Carl Chenet</I> as an open-source project to provide robust command-line interaction with Google Contacts. Its development began around 2013-2014, driven by the need for seamless integration of Google contact management into traditional Unix-like environments and text-based applications such as the <I>mutt</I> email client.


title: PARAMETERS
content:
<b><I>search_query</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The term(s) you wish to search for on Google. Multiple words should be provided as arguments, and the script will typically join them into a single query.<br><br><b><b>-l</b>, <b>--lucky</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the 'I'm Feeling Lucky' result directly, if available. This option typically redirects you to the first search result page rather than the full list of results.<br><br><b><b>-b</b> <I>browser_name</I>, <b>--browser</b> <I>browser_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular browser to use (e.g., 'firefox', 'chrome') instead of the system's default browser configured by <b>xdg-open</b>.<br><br>


title: DESCRIPTION
content:
The "google" command is <i>not</i> a standard, pre-installed utility found in most Linux distributions. Instead, it commonly refers to a custom shell alias, function, or script created by users to quickly initiate a Google search directly from the command line. Its primary purpose is to streamline workflow by allowing users to type a query in the terminal, which then automatically opens their default web browser to the corresponding Google search results page. This eliminates the need to manually open a browser, navigate to Google, and then type the search terms. The implementation varies widely; typically, it uses commands like <b>xdg-open</b>, <b>firefox</b>, or <b>chromium-browser</b> to launch the browser with a specially crafted Google search URL. While not official, this user-defined "google" command is a popular productivity hack for developers and system administrators.


title: CAVEATS
content:
The "google" command is <i>not</i> a standard Linux utility; its existence and behavior depend entirely on whether a user or system administrator has created a custom alias, shell function, or script with this name. Therefore:<br><br><b>1. Custom Implementation:</b> Its functionality, available options, and even its very presence can vary greatly between different Linux systems or user configurations.<br><b>2. Browser Dependency:</b> It typically requires a graphical desktop environment and a web browser installed and configured to open URLs.<br><b>3. Internet Connection:</b> An active internet connection is necessary for performing searches.<br><b>4. Security:</b> While generally safe, users should exercise caution if acquiring such a script from untrusted sources, as it could potentially execute arbitrary commands.


title: TYPICAL IMPLEMENTATION EXAMPLE (BASH/ZSH)
content:
A common way to implement the 'google' command in your <i>.bashrc</i> or <i>.zshrc</i> file is as a shell function, often using <b>xdg-open</b> to leverage your system's default browser:<br><br><pre><code>google() {<br>  local query="$@"<br>  local browser="xdg-open"<br>  local lucky=false<br><br>  while [[ "$1" =~ ^- ]]; do<br>    case "$1" in<br>      -l|--lucky) lucky=true; shift ;; <br>      -b|--browser) shift; browser="$1"; shift ;; <br>      *) echo "Unknown option: $1"; return 1 ;; <br>    esac<br>  done<br><br>  query="$@"<br>  if [[ -z "$query" ]]; then<br>    echo "Usage: google [options] &lt;search_query&gt;..."<br>    return 1<br>  fi<br><br>  local search_url="https://www.google.com/search?q=${query// /+}"<br>  if $lucky; then<br>    search_url="https://www.google.com/search?btnI&q=${query// /+}"<br>  fi<br>  <br>  "$browser" "$search_url" &gt; /dev/null 2&gt;&amp;1 &amp;<br>}</code></pre><br>This function processes basic options like <b>--lucky</b> and <b>--browser</b>, constructs the Google search URL, and then uses the specified or default browser to open it in the background, returning control to your terminal immediately.


title: ALTERNATIVE: SIMPLE ALIAS FOR DEFAULT BROWSER
content:
For a very basic setup without options, you can use a simple alias, typically defined in your shell's configuration file (e.g., <i>.bashrc</i> or <i>.zshrc</i>):<br><br><pre><code>alias google='xdg-open "https://www.google.com/search?q=$@" &gt; /dev/null 2&gt;&amp;1 &amp;'</code></pre><br>Note that direct aliases handle arguments differently than functions, and this example might not parse multiple arguments correctly as a single query without further manipulation. For more robust argument handling and options, a shell function is generally preferred.


title: HISTORY
content:
The "google" command, as a user-defined shortcut, has no formal development history like standard Linux utilities. Its origin lies in the desire for increased productivity among command-line users. As Google became the dominant search engine, users naturally sought ways to integrate its functionality into their terminal workflows. This led to the widespread creation of simple shell scripts and aliases, often shared in online communities, which would construct a Google search URL and open it using a browser. While the exact implementation details have evolved with shell features and browser commands, the core concept of a quick <b>google</b> <I>query</I> shortcut has remained popular for well over a decade.


title: PARAMETERS
content:
<b><b>--incognito</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new incognito window, preventing browsing history, cookies, and site data from being saved.<br><br><b><b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a new browser window to open, even if an existing Chrome instance is running.<br><br><b><b>--app=<i>&lt;URL&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified URL in an app mode window, without the usual browser UI elements like address bar or tabs.<br><br><b><b>--profile-directory=<i>&lt;NAME&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the profile to use (e.g., 'Default', 'Profile 1'). Creates it if it doesn't exist.<br><br><b><b>--user-data-dir=<i>&lt;PATH&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default user data directory. Useful for portable installations or specific testing environments.<br><br><b><b>--headless</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs Chrome in headless mode, without a visible UI. Ideal for automated testing, scraping, or server-side rendering.<br><br><b><b>--disable-gpu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables GPU hardware acceleration. Useful for troubleshooting rendering issues or in headless environments.<br><br><b><b>--no-sandbox</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the sandbox. <i>Use with extreme caution</i> as it significantly reduces security.<br><br><b><b>--remote-debugging-port=<i>&lt;PORT&gt;</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables remote debugging over HTTP on the specified port. Useful for programmatically controlling Chrome.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Google Chrome version information to standard output and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a limited set of command-line options and exits.<br><br>


title: DESCRIPTION
content:
The <b>google-chrome</b> command is the primary executable for launching the Google Chrome web browser on Linux systems. It allows users to open new browser windows, specific URLs, or control various aspects of the browser's behavior directly from the command line. Built on the Chromium open-source project, Google Chrome provides a fast, secure, and feature-rich browsing experience, integrating with Google services and offering extensive developer tools.<br><br>The command supports a wide array of flags to customize its launch, including opening in incognito mode, as a specific application, or managing user profiles. It's an essential tool for both everyday web browsing and advanced use cases like web development and automated testing (especially with its headless mode). When invoked without arguments, it typically opens a new browser window with the default homepage or previously open tabs. When URLs are provided, it attempts to open them in new tabs or windows.


title: CAVEATS
content:
Running <b>google-chrome</b> directly as the root user is generally discouraged due to security implications and is often prevented by default. It requires an X server environment (unless using <b>--headless</b>). The browser can be resource-intensive, especially with many tabs or extensions. Many advanced flags are undocumented and primarily for internal development or testing, and their behavior may change without notice.


title: USING MULTIPLE PROFILES
content:
Google Chrome supports multiple user profiles, each with its own bookmarks, history, extensions, and settings. You can launch Chrome with a specific profile using <b>--profile-directory=&lt;NAME&gt;</b>. For example, to open a profile named 'Work': <b>google-chrome --profile-directory="Work"</b>. If the profile doesn't exist, Chrome will create it.


title: HEADLESS MODE FOR AUTOMATION
content:
The <b>--headless</b> flag is extremely powerful for scripting and automation. It allows Chrome to run without a GUI, making it suitable for server environments or CI/CD pipelines. Combined with <b>--remote-debugging-port</b>, it can be controlled programmatically using tools like Puppeteer or Selenium for web scraping, testing, or PDF generation.


title: HISTORY
content:
Google Chrome was first released for Microsoft Windows in September 2008. The Linux version, along with macOS, followed in December 2009, initially as a beta. The <b>google-chrome</b> command became the standard entry point for launching the browser on Linux, following typical naming conventions for desktop applications. Its development and usage have evolved in parallel with the browser's features, with increasing emphasis on command-line options for automation, web development, and integration into various workflows.


title: PARAMETERS
content:
<b>--incognito</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new Incognito window, preventing browsing history, cookies, and site data from being saved.<br><br><b>--new-window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the opening of a new browser window, even if a Chrome instance is already running.<br><br><b>--headless</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs Chrome in headless mode without a graphical user interface, useful for automation, testing, and server environments.<br><br><b>--app=<I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the specified URL as a simplified web application, without typical browser UI elements like the address bar and toolbars.<br><br><b>--profile-directory="<I>ProfileName</I>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the profile directory to use. For example, <B>Default</B>, <B>Profile 1</B>, etc., located within the user data directory.<br><br><b>--user-data-dir="<I>PATH</I>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom directory where Chrome stores user data, including profiles, cache, and extensions. Useful for portable installations or specific testing scenarios.<br><br><b>--disable-gpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables GPU hardware acceleration. Useful for troubleshooting rendering issues or on systems with problematic graphics drivers.<br><br><b>--no-sandbox</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the browser's security sandbox. This is generally discouraged due to security risks but can be necessary in certain isolated environments (e.g., Docker containers).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current version information of Google Chrome to standard output and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message detailing common command-line flags and their usage.<br><br>


title: DESCRIPTION
content:
The <I>google-chrome-stable</I> command on Linux invokes the official, stable release channel of the Google Chrome web browser. Developed by Google, Chrome is a widely used, cross-platform browser known for its speed, minimalistic user interface, and robust feature set. It is built upon the open-source Chromium project and utilizes the Blink rendering engine and V8 JavaScript engine.<br><br>As a stable release, <I>google-chrome-stable</I> offers the most tested and reliable version of the browser, suitable for general daily use. It provides a full web browsing experience, supporting modern web standards, an extensive ecosystem of extensions from the Chrome Web Store, built-in PDF viewer, automatic translation, and synchronization of user data (bookmarks, history, passwords) across devices via a Google account. While based on Chromium, <I>google-chrome-stable</I> includes proprietary components, such as integrated Adobe Flash Player (though increasingly deprecated), Widevine DRM, and Google API keys.


title: CAVEATS
content:
Google Chrome, while widely used, contains proprietary components and involves data collection by Google, which may raise privacy concerns for some users. While generally efficient, it can be resource-intensive, particularly with many tabs or extensions open. Updates for <I>google-chrome-stable</I> are typically managed automatically by the system's package manager (e.g., APT on Debian/Ubuntu, RPM on Fedora/openSUSE), ensuring the browser remains up-to-date with security patches and new features. It's important to note that the browser supports hundreds of command-line flags, many of which are internal debugging or highly specific developer options and are not listed here.


title: RELEASE CHANNELS
content:
<I>google-chrome-stable</I> represents the most thoroughly tested and widely used release channel. Google also offers other channels for different use cases: <B>Beta</B> (previews upcoming features), <B>Dev</B> (developer builds with more recent changes), and <B>Canary</B> (daily, bleeding-edge builds). Users can install these alongside or instead of the stable version to test new features or contribute to development.


title: USER PROFILES
content:
Google Chrome supports multiple user profiles, allowing different users or purposes to have separate browsing data, settings, extensions, bookmarks, and history. This is particularly useful for shared computers or for developers who need distinct environments. Profiles can be managed through the browser's graphical interface or specified directly via the command-line using the <B>--profile-directory</B> or <B>--user-data-dir</B> flags.


title: HISTORY
content:
Google Chrome was first released in 2008 by Google, rapidly gaining market share to become one of the most dominant web browsers globally. Its development on Linux has been consistent since its initial release, providing a native experience for users on the platform. Chrome's success is often attributed to its innovative multi-process architecture (isolating tabs and plugins), the fast V8 JavaScript engine, and its extensive Web Store for extensions. The browser's commitment to web standards and continuous development has profoundly influenced web development and user experience.


title: PARAMETERS
content:
<b>--config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file path.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more detailed information during execution.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-error output, showing only critical messages.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current <i>gopass</i> version information.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows general help information or help for a specific subcommand.<br><br>


title: DESCRIPTION
content:
<i>gopass</i> is a robust, command-line password manager that leverages Git for version control and synchronization, and GPG (GNU Privacy Guard) for strong encryption. As a modern, cross-platform rewrite of the popular <i>pass</i> (password-store) utility, it offers improved speed, advanced features like multi-store support and OTP generation, and enhanced usability across various operating systems.<br><br>It organizes passwords in a hierarchical, encrypted file structure, simplifying the management of multiple password entries. <i>gopass</i> securely shares vaults and synchronizes them across devices via Git. It integrates seamlessly with the clipboard for easy access and provides numerous subcommands for common operations like showing, inserting, generating, and editing passwords. Its design emphasizes simplicity, security, and extensibility.


title: CAVEATS
content:
<b>GPG and Git Dependencies</b>: <i>gopass</i> fundamentally relies on <i>git</i> for synchronization and <i>gpg</i> for encryption. Both must be installed and correctly configured on the system for <i>gopass</i> to function.<br><br><b>GPG Passphrase Management</b>: The security of your stored passwords is directly tied to the strength and security of your GPG passphrase. Loss or compromise of this passphrase can lead to irreversible data loss or unauthorized access.<br><br><b>Git Repository Security</b>: While passwords are encrypted, metadata such as file names can be visible in the Git repository's history. Ensure your Git repository itself is protected.<br><br><b>Clipboard Interaction</b>: Passwords copied to the clipboard remain there temporarily. Be mindful of potential exposure, especially on shared or public systems.


title: <B>SUBCOMMAND STRUCTURE</B>
content:
<i>gopass</i> employs a subcommand-based interface (e.g., `gopass show`, `gopass generate`), analogous to `git`. This design promotes modularity and extensibility, with each subcommand handling a specific aspect of password management.


title: <B>MULTI-STORE SUPPORT</B>
content:
A significant feature of <i>gopass</i> is its capability to manage multiple independent password stores. This allows users to segregate work, personal, or shared passwords into distinct, encrypted vaults.


title: <B>OTP GENERATION</B>
content:
It includes integrated support for generating Time-based One-Time Passwords (TOTP) directly from password entries, streamlining the process of two-factor authentication.


title: HISTORY
content:
<i>gopass</i> was developed as a modern, Go-language rewrite of the original <i>pass</i> (password-store) utility. While <i>pass</i> established a secure and simple model using Unix tools, its shell-script implementation sometimes faced performance and cross-platform limitations. <i>gopass</i> emerged to address these, offering a faster, more robust, and natively cross-platform solution. It expanded on <i>pass</i>'s core by introducing features like multiple password stores, an improved command-line interface, and built-in OTP (One-Time Password) generation, while maintaining the underlying security principles of Git and GPG.


title: SYNOPSIS
content:
<i>gops</i> <B>&lt;command&gt;</B> [options] [arguments]<br><br>Common invocations:<br><i>gops</i> <B>&lt;pid&gt;</B><br><i>gops</i> <B>&lt;addr&gt;</B><br><i>gops</i> agents<br><i>gops</i> stack <B>&lt;pid|addr&gt;</B><br><i>gops</i> cpu <B>&lt;pid|addr&gt;</B> [-o &lt;file&gt;] [-t &lt;duration&gt;]


title: PARAMETERS
content:
<b><B>&lt;pid&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The operating system Process ID of the target Go application. <i>gops</i> will attempt to connect to the agent running within this process.<br><br><b><B>&lt;addr&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The network address (e.g., <i>127.0.0.1:port</i>) where the <i>gops</i> agent of the target Go application is listening. Useful for remote diagnostics or when PID is unknown/unstable.<br><br><b><B>agents</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all <i>gops</i> agents currently running and discoverable on the local host. This helps in identifying the PIDs and addresses of instrumented Go processes.<br><br><b><B>stack</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the stack traces of all active goroutines in the target Go application. Critical for debugging deadlocks, long-running operations, and understanding concurrency state.<br><br><b><B>memstats</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed Go runtime memory statistics, including heap usage, garbage collection information, and allocated objects. Useful for memory leak detection and profiling.<br><br><b><B>cpu</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts CPU profiling for a specified duration and saves the profile data. The output is typically consumed by <i>go tool pprof</i> for visualization and analysis.<br><br><b><B>heap</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the current heap profile of the Go application, showing memory allocations. Also consumable by <i>go tool pprof</i>.<br><br><b><B>goroutine</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the goroutine profile, showing where goroutines are blocked or active. Similar to <i>stack</i> but often used with <i>pprof</i> for visualization.<br><br><b><B>block</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the blocking profile, indicating where goroutines are blocked on synchronization primitives (e.g., mutexes, channels).<br><br><b><B>mutex</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the mutex contention profile, showing where mutexes are being heavily contended.<br><br><b><B>trace</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts an execution trace for a specified duration, providing detailed timeline information of goroutine events, system calls, and more. Analyzed with <i>go tool trace</i>.<br><br><b><B>stats</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continuously prints Go runtime statistics at regular intervals, providing a live view of performance metrics like goroutine count, GC pauses, and memory.<br><i>Common options: -p &lt;duration&gt; (period for stats)</i>.<br><br><b><B>gc</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an immediate garbage collection cycle in the target Go application.<br><br><b><B>version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of the <i>gops</i> tool.<br><br><b><B>-o &lt;file&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Common option used with profiling commands (e.g., <i>cpu</i>, <i>heap</i>) to specify the output file path for the generated profile data.<br><br>


title: DESCRIPTION
content:
<i>gops</i> is a powerful command-line tool designed specifically for inspecting and diagnosing running <B>Go processes</B>. Unlike generic system utilities such as <i>ps</i> or <i>top</i>, <i>gops</i> provides deep insight into the Go runtime, leveraging an embedded agent within the target Go application. This allows it to expose rich, Go-specific metrics and diagnostic data, including goroutine stack traces, heap profiles, CPU profiles, runtime statistics (like GC pause times and goroutine counts), and more.<br><br>It's an indispensable tool for Go developers to pinpoint and troubleshoot issues such as memory leaks, CPU bottlenecks, goroutine deadlocks, and general performance regressions in both development and production environments. For <i>gops</i> to function, the target Go application must be instrumented by importing and initializing the <i>gops</i> agent within its codebase.


title: CAVEATS
content:
The primary limitation of <i>gops</i> is that it <B>requires the target Go application to be explicitly instrumented</B> with the <i>gops</i> agent. It cannot inspect arbitrary Go processes or non-Go applications.<br><br>The agent exposes sensitive runtime data, so proper security measures (e.g., firewall rules, network segmentation) should be in place, especially in production environments, to restrict access to the <i>gops</i> agent's listening port.<br><br>Profiling commands can introduce a <B>performance overhead</B> on the target application, which should be considered during live debugging.<br><br><i>gops</i> is not a standard Linux command; it must be installed separately via the Go toolchain.


title: INSTALLATION
content:
<i>gops</i> is not pre-installed on most Linux systems. It can be installed using the Go toolchain:<br><br><B>go install github.com/google/gops@latest</B><br><br>Ensure your <i>$GOBIN</i> (or <i>$GOPATH/bin</i>) is in your system's <i>$PATH</i> to run <i>gops</i> directly.


title: AGENT INTEGRATION IN GO APPLICATIONS
content:
For a Go application to be diagnosable by <i>gops</i>, it must integrate the <i>gops</i> agent. This is typically done by importing the <i>agent</i> package and calling <i>agent.Listen()</i> early in the application's startup code:<br><br><b>import (</b><br><b>    "log"</b><br><b>    "github.com/google/gops/agent"</b><br><b>)</b><br><br><b>func main() {</b><br><b>    if err := agent.Listen(agent.Options{}); err != nil {</b><br><b>        log.Fatalf("gops agent Listen failed: %v", err)</b><br><b>    }</b><br><b>    // ... rest of your application code</b><br><b>}</b><br><br>The <i>agent.Listen()</i> call starts a goroutine that listens for diagnostic requests on a local socket or network port.


title: HISTORY
content:
<i>gops</i> was developed by Google engineers as part of the broader Go ecosystem to address the need for a more convenient and lightweight way to diagnose Go applications in real-time, especially in production environments. While Go's built-in <i>pprof</i> package provides robust profiling capabilities, it often requires exposing HTTP endpoints or managing signal handlers. <i>gops</i> streamlined this process by providing a unified command-line interface that communicates with a small, embeddable agent.<br><br>Its development focused on making Go runtime diagnostics more accessible, allowing developers to quickly pull various profiles and statistics without restarting applications or complex setup. It has become a widely adopted tool within the Go community for debugging performance and concurrency issues.


title: PARAMETERS
content:
<b>--all, -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads configurations for <i>all</i> defined groups or services in the configuration file.<br><br><b>--force, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a reload, potentially triggering a full service restart if a graceful reload mechanism is not available or fails.<br><br><b>--status, -s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of the configuration reload operations, showing success or failure for each component.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, providing more detailed information about the reload process.<br><br><b>--config <path>, -c <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file to use instead of the default system-wide configuration.<br><br>


title: DESCRIPTION
content:
The <b>goreload</b> command is a <i>hypothetical</i> utility designed to facilitate the graceful reloading of configurations or services for predefined groups of applications. While not a standard command found in common Linux distributions, its conceptual purpose is to streamline the process of applying configuration changes without requiring full service restarts, thereby minimizing downtime.<br><br>It would act as an orchestration layer, reading from a central configuration file to identify which services belong to a particular 'group' and what specific commands or signals (like <b>SIGHUP</b>) should be issued to trigger a configuration reload for each. This makes it particularly useful in complex environments with many interconnected services, allowing administrators to update configurations efficiently across multiple components with a single command. Its design would aim for idempotence and provide clear feedback on reload operations.


title: CAVEATS
content:
<b>IMPORTANT:</b> The <b>goreload</b> command is <i>purely hypothetical</i> and does <i>not</i> exist as a standard utility in any common Linux distribution. This analysis describes a conceptual command based on common system administration patterns (like <b>systemctl reload</b> or <b>apachectl graceful</b>). Any use or expectation of this command in a real-world scenario would require it to be a custom script or application developed specifically for that environment. It is presented here for illustrative purposes to meet the structural requirements of the request.


title: CONFIGURATION FILE FORMAT
content:
The effectiveness of <b>goreload</b> would heavily depend on a well-defined configuration file, typically located at <i>/etc/goreload/config.d/</i> or <i>~/.config/goreload/config</i>. This file would likely use a human-readable format like YAML or TOML to define service 'groups' and associate them with specific reload commands or process IDs. Each entry would specify the command to execute for a graceful reload (e.g., <b>systemctl reload myapp</b> or <b>kill -HUP $(cat /var/run/myapp.pid)</b>).


title: RELOAD MECHANISM
content:
<b>goreload</b> would primarily utilize <b>SIGHUP</b> (Hangup signal) for graceful reloads, as many services are designed to re-read their configuration upon receiving this signal without interrupting ongoing connections. For services that don't support <b>SIGHUP</b>, or in 'force' mode, it might execute predefined restart commands. The command would be robust, checking the success of each reload operation and providing feedback on the process.


title: HISTORY
content:
As a <i>hypothetical</i> command, <b>goreload</b> does not possess a real development history. However, its conceptual design would likely emerge from the need to simplify configuration management in distributed systems and microservice architectures. Administrators often write custom scripts to orchestrate reloads across various services. <b>goreload</b> would represent a consolidated, standardized tool to automate these common tasks, drawing inspiration from existing service managers and configuration management tools that provide reload capabilities (e.g., <b>systemd</b>, <b>Apache</b>, <b>Nginx</b>). Its theoretical inception would address the inefficiency of manually triggering reloads for multiple, interdependent components.


title: SYNOPSIS
content:
<b>openssl genrsa [<i>options</i>] [<i>numbits</i>]</b><br>The <i>numbits</i> argument specifies the desired key length in bits, typically 2048 or 4096. If omitted, 2048 bits is the default.


title: PARAMETERS
content:
<b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a usage message and exits.</i><br><br><b><b>-out <i>filename</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the output file for the generated key. If omitted, the key is written to standard output (stdout).</i><br><br><b><b>-passout <i>arg</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the source for the passphrase used to encrypt the output key. Common formats include <code>pass:<i>password</i></code>, <code>env:<i>VAR</i></code>, <code>file:<i>path</i></code>, or <code>fd:<i>num</i></code>.</i><br><br><b><b>-des</b>, <b>-des3</b>, <b>-aes128</b>, <b>-aes192</b>, <b>-aes256</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Encrypts the private key using the specified symmetric cipher (DES, Triple DES, or AES with various key sizes). If no passphrase is provided via <code>-passout</code>, the user will be prompted for one.</i><br><br><b><b>-f4</b> or <b>-3</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the public exponent for the RSA key. <code>-f4</code> uses 65537 (the default and recommended value), while <code>-3</code> uses 3.</i><br><br><b><b>-vulnerable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a key that is intentionally vulnerable to the ROCA (Return Of Coppersmith's Attack) vulnerability, found in some hardware implementations. Use with extreme caution and only for specific testing purposes, never in production.</i><br><br><b><b>-noout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents the output of the encoded version of the key. This is useful when only side effects (like passphrase prompting) are desired.</i><br><br><b><b><i>numbits</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The desired length of the RSA key in bits. Common values are 2048 (default) or 4096. A minimum of 512 bits is usually enforced, but for security, at least 2048 bits is highly recommended.</i><br><br>


title: DESCRIPTION
content:
<i>genrsa</i> is an OpenSSL command-line utility used for generating RSA (Rivest-Shamir-Adleman) private keys. RSA is a widely used public-key cryptographic algorithm fundamental for secure data transmission and authentication.<br><br>The command produces a new private key, typically in PEM (Privacy-Enhanced Mail) format, which can be further processed or used by other OpenSSL commands, for instance, to generate a Certificate Signing Request (CSR) or self-signed certificates. Users can specify the key's bit length (e.g., 2048, 4096 bits) to determine its strength, with larger bit lengths providing greater security but requiring more computational resources.<br><br>While `genrsa` generates the private key, its corresponding public key can be derived from it. The public key is then shared widely, enabling others to encrypt data for the private key holder or verify digital signatures made by them, ensuring secure and authenticated communication. It's an essential tool for setting up secure servers, client certificates, and various cryptographic applications.


title: CAVEATS
content:
<b>Security Considerations</b>: Choosing a sufficiently large <i>numbits</i> (e.g., 2048 or 4096) is crucial for key strength. Using the <i>-vulnerable</i> option should be strictly avoided in production environments as it deliberately creates insecure keys. Poorly chosen passphrases for encrypted keys can also compromise security.<br><br><b>Randomness</b>: The quality of the generated key heavily relies on the randomness source provided by the operating system. Insufficient entropy can lead to weaker, predictable keys.


title: KEY STRENGTH AND PUBLIC EXPONENT
content:
The <i>numbits</i> parameter determines the cryptographic strength of the RSA key. While 2048 bits is the current standard, 4096 bits offers greater future-proofing against advancements in cryptanalysis. The public exponent, typically 65537 (F4), is a small prime number used in the RSA algorithm. While technically modifiable, using 65537 is highly recommended for security and compatibility reasons.


title: OUTPUT FORMAT
content:
By default, <i>genrsa</i> outputs the private key in PEM format, which is a Base64-encoded representation of the DER (Distinguished Encoding Rules) key, typically enclosed between "BEGIN RSA PRIVATE KEY" and "END RSA PRIVATE KEY" markers. This human-readable format is widely compatible with other OpenSSL commands and cryptographic libraries. Encrypted keys will have markers like "BEGIN ENCRYPTED PRIVATE KEY" or "BEGIN DES3 PRIVATE KEY" depending on the encryption cipher used.


title: HISTORY
content:
<i>genrsa</i> is a foundational component of the OpenSSL project, which began in 1998 as a fork of SSLeay. As a core utility for generating RSA private keys, it has been an integral part of OpenSSL's cryptographic toolkit since its early days, supporting the widespread adoption of RSA for secure communication over the internet. Its functionality has remained largely consistent, with updates primarily focusing on security enhancements, support for stronger ciphers, and integration with evolving cryptographic standards.


title: PARAMETERS
content:
<b>-r, --remote</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Considers remote-tracking branches in the deletion process, often ensuring local branches that track merged remote branches are cleaned up.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force deletion of branches using <I>git branch -D</I>. This allows deletion of unmerged branches or branches whose upstream hasn't been pushed.<br><br><b>-n, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run, listing branches that would be deleted without actually deleting them. Highly recommended for previewing.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts for confirmation before deleting each branch, providing an opportunity to review and skip individual branches.<br><br><b>-k, --keep <branch_pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a pattern (e.g., glob) for branches to explicitly keep and exclude from deletion, even if they are merged.<br><br><b><target_branch></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The branch against which to check for merged branches. If omitted, defaults to the currently checked-out branch (HEAD).<br><br>


title: DESCRIPTION
content:
The <i>git-delete-merged-branches</i> command is a common utility script or alias used to clean up local Git repositories by removing branches that have already been fully merged into the current <b>HEAD</b> branch (or a specified target branch). It automates the process of identifying merged branches and then deleting them, helping to keep the local branch list tidy and manageable. Typically, it identifies branches using <i>git branch --merged</i> and then deletes them using <i>git branch -d</i> or <i>git branch -D</i> (force delete). It often includes safeguards to prevent accidental deletion of important branches like <i>master</i>, <i>main</i>, or <i>develop</i>, and might offer interactive confirmation. This command is <b>not a built-in Git command</b> but rather a highly popular user-created script or function built upon Git's core functionalities. Its primary purpose is to streamline repository hygiene, especially in workflows with many short-lived feature branches.


title: CAVEATS
content:
<ul><li><b>Non-standard Command</b>: This is not a built-in <i>git</i> command. Its exact behavior depends on the specific script or alias implementation you are using. Always verify the source of the script.</li><br><li><b>Potential Data Loss</b>: Without careful use of <i>--dry-run</i> or <i>--interactive</i>, branches can be permanently deleted, especially if <i>--force</i> is used or the branch has not been pushed to a remote repository.</li><br><li><b>Contextual Merged State</b>: A branch might be merged into your current <b>HEAD</b>, but not necessarily into a long-lived branch like <i>main</i> or <i>develop</i>. Ensure you understand which <i>target_branch</i> is being used for the merge check.</li><br><li><b>Local Only</b>: Typically, this command only deletes local branches. Deleting remote branches requires a separate push command (e.g., <i>git push origin --delete &lt;branch_name&gt;</i>).</li><br><li><b>Active Branch Protection</b>: Most implementations prevent deleting the currently checked-out branch.</li></ul>


title: INSTALLATION/SETUP
content:
<br>This command needs to be manually set up as it is not a built-in Git command. It can be implemented as a shell script placed in your <B>$PATH</B> or as a Git alias configured in your <B>.gitconfig</B> file.<br><br>Example as a basic Git alias:<br><I>git config --global alias.delmerged '!git branch --merged | grep -v "master\\|main\\|develop" | xargs git branch -d'</I><br><br>More robust scripts often include error handling, interactivity, and more sophisticated branch exclusion logic.


title: WORKFLOW INTEGRATION
content:
<br>This command is often integrated into automated workflows, such as post-merge hooks in Git or as part of CI/CD pipeline steps. This ensures that local developer environments or build servers remain clean of stale branches after successful merges to integration branches.


title: HISTORY
content:
The <i>git-delete-merged-branches</i> utility does not have a formal, centralized history like built-in Git commands. Its origin stems from the common need for efficient repository hygiene as Git gained widespread adoption. Developers frequently create numerous short-lived feature or bugfix branches, and manually identifying and deleting these after they were merged became a tedious task. This practical necessity led to the proliferation of custom shell scripts and aliases shared within the developer community (e.g., via GitHub Gists, Stack Overflow, and personal dotfiles). While many variations exist, the core logic leveraging <i>git branch --merged</i> for identification and <i>git branch -d</i> for deletion rapidly became a de facto standard for such cleanup utilities. Its evolution is primarily driven by community contributions, practical workflow requirements, and individual preferences for automation rather than a centralized development effort.


title: SYNOPSIS
content:
<i>git &lt;subcommand&gt;</i> [options] [arguments]<br><i>(Note: <b>git-extras</b> is a collection of Git utilities; its commands are invoked directly as <i>git &lt;subcommand&gt;</i> rather than via a single 'git-extras' command itself.)</i>


title: PARAMETERS
content:
<b>The <b>git-extras</b> package extends Git by adding numerous new subcommands. Each subcommand has its own specific options and arguments. Below are a few examples of popular subcommands provided by <b>git-extras</b>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b><i>git info</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive information about the current Git repository.<br><br><b><i>git undo</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the last commit, useful for quick corrections or backing out recent changes.<br><br><b><i>git back</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undoes the last N commits by resetting the branch to a previous state, similar to 'git reset'.<br><br><b><i>git summary</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a compact summary of the current repository, including branches, tags, and commit counts.<br><br><b><i>git release</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a release commit and corresponding tag, simplifying software release management workflows.<br><br><b><i>git clean-branches</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes all local branches that have already been merged into the current branch or its upstream.<br><br><b><i>git pull-request</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automates the creation of a pull request on platforms like GitHub or GitLab directly from the command line.<br><br>


title: DESCRIPTION
content:
<b>git-extras</b> is an open-source collection of over 80 useful Git utilities that significantly enhance the core Git functionality. It provides commands for common Git tasks that are not included in the standard Git distribution, simplifying complex operations and improving developer productivity. These commands cover a wide range of functionalities, from repository information (e.g., <i>git info</i>, <i>git summary</i>) to history manipulation (e.g., <i>git undo</i>, <i>git back</i>), repository cleaning (e.g., <i>git clean-branches</i>), and various shortcuts. By installing <b>git-extras</b>, users gain access to a powerful set of tools that seamlessly integrate with the existing Git command-line interface, allowing them to invoke new commands directly via <i>git &lt;subcommand&gt;</i>. It's a community-driven project aimed at making common, often repetitive, Git workflows more efficient and less error-prone, offering a more robust and streamlined Git experience.


title: CAVEATS
content:
<b>git-extras</b> is not part of the official Git distribution and requires separate installation. While it integrates seamlessly with Git, there's a minor potential for command name clashes if you have custom Git aliases or scripts with identical names. Users should also be aware that some commands might have specific dependencies or platform-specific behaviors (e.g., <i>git pull-request</i> often relies on GitHub or GitLab APIs).


title: INSTALLATION
content:
<b>git-extras</b> can be easily installed using various package managers on different operating systems, such as <i>Homebrew</i> on macOS, <i>apt-get</i> on Debian/Ubuntu, or <i>yum</i> on Fedora/RHEL. Alternatively, it can be installed by cloning its GitHub repository and running the provided installation script, making it accessible across a wide range of environments.


title: COMMAND STRUCTURE
content:
Each utility within <b>git-extras</b> is implemented as an independent shell script (or occasionally other language scripts) that adheres to Git's subcommand architecture. When installed, these scripts are placed in a directory accessible by Git (typically within your PATH), allowing them to be invoked directly as <i>git &lt;script-name&gt;</i>, seamlessly mimicking core Git commands and providing a consistent user experience.


title: HISTORY
content:
<b>git-extras</b> originated around 2011-2012, primarily initiated by TJ Holowaychuk. It rapidly grew into a large, community-maintained open-source project. Its development has consistently focused on addressing common Git workflow inefficiencies and adding utilities for frequently performed, yet cumbersome, operations not covered by core Git, evolving with the needs of developers.


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Export all refs found in the 'refs/' hierarchy.</I><br><br><b>--branches[=<pattern>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Export all branches, or only those matching a specified pattern.</I><br><br><b>--tags[=<pattern>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Export all tags, or only those matching a specified pattern.</I><br><br><b>--full-history</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Ensures all history reachable from the selected commits is exported.</I><br><br><b>--root-commits</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Only export root commits for the selected history, without their parents.</I><br><br><b>--date-format=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify the date format for commit export, e.g., 'raw' or 'iso8601'.</I><br><br><b>--import-marks=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Read marks from the specified file to enable incremental imports.</I><br><br><b>--export-marks=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Write marks to the specified file for subsequent incremental exports.</I><br><br><b>--mark-tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Mark tags in the export output for proper reconstruction during import.</I><br><br><b>--no-data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not export blob contents; useful for structure-only analysis or dry runs.</I><br><br><b>--depth=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Limit the export to the last N commits of reachable history.</I><br><br><b>--since=<date></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Export only commits newer than the specified date.</I><br><br><b>--until=<date></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Export only commits older than the specified date.</I><br><br><b>--max-pack-size=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Limit the size of pack files generated by the output to N bytes.</I><br><br><b>--max-blob-size=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Limit the size of individual blobs exported to N bytes.</I><br><br><b>--reencode-meta</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Re-encode commit metadata (author/committer) to UTF-8 if necessary.</I><br><br>


title: DESCRIPTION
content:
<b>git-fast-export</b> is a Git porcelain command used to output Git repository history in a format suitable for <b>git-fast-import</b>. This streaming format allows for efficient transfer of Git objects (blobs, trees, commits, and tags) and references. It's primarily designed for repository migrations, enabling the conversion of other version control systems' histories into Git, or for exporting a subset of a Git repository's history to another Git repository. The command processes history specified by arguments similar to <b>git rev-list</b>, generating a sequence of <b>fast-import</b> commands that reconstruct the history. Unlike <b>git-bundle</b>, which creates a self-contained archive, <b>git-fast-export</b> produces a stream, making it ideal for piping data directly or processing large repositories incrementally. It's a powerful tool for complex history manipulation and data transfer between Git instances.


title: CAVEATS
content:
The output format is highly specific to <I>git-fast-import</I> and not intended for direct human consumption. <br>Processing very large repositories can generate extremely large output files, requiring significant disk space and memory. <br>Correctly handling history rewrites or complex merges often requires a deep understanding of Git's object model and can be challenging.


title: MARKS FILES
content:
Marks files (<I>--import-marks</I>, <I>--export-marks</I>) are crucial for incremental exports and imports. They map original Git object IDs to new, sequentially generated IDs, allowing <I>git-fast-import</I> to continue processing from a known state without re-importing already processed objects. This is vital for resuming failed imports or periodically synchronizing repositories.


title: OUTPUT FORMAT OVERVIEW
content:
The command generates a series of text-based commands that describe Git objects and references. Key commands include <I>blob</I> (for file contents), <I>commit</I> (for commit metadata and tree states), <I>tag</I> (for annotated tags), <I>reset</I> (to set a branch/ref), and <I>alias</I>. Each command details the object's type, content, and relationship within the Git graph, making it a programmatic representation of a repository's history.


title: HISTORY
content:
<b>git-fast-export</b> was developed as a core component of Git's design philosophy, enabling efficient and flexible data exchange. Its inception parallels that of <b>git-fast-import</b>, providing a robust mechanism for migrating histories from various version control systems into Git. This stream-based approach ensures scalability for large repositories and facilitates integration with other tools for history manipulation. It has been a stable and crucial utility since its early days, evolving with Git to support new features while maintaining its core functionality.


title: SYNOPSIS
content:
<i>Since <b>git-feature</b> is a user-defined script, its synopsis varies. A typical representation might be:<br><br><b>git feature</b> &lt;<i>subcommand</i>&gt; [<i>options</i>] [<i>arguments</i>]<br><br>Where &lt;<i>subcommand</i>&gt; represents an action like <b>start</b>, <b>finish</b>, or <b>publish</b>, and &lt;<i>options</i>&gt; and &lt;<i>arguments</i>&gt; are specific to that action.</i>


title: PARAMETERS
content:
<b>start &lt;<i>feature-name</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Commonly creates and checks out a new feature branch, often from a development branch like <b>develop</b> or <b>main</b>.</i><br><br><b>finish [&lt;<i>feature-name</i>&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Typically integrates the specified or current feature branch into the main development branch (e.g., via merge or rebase), and then deletes the feature branch.</i><br><br><b>publish [&lt;<i>feature-name</i>&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Often pushes the local feature branch to the remote repository, setting up tracking.</i><br><br><b>pull [&lt;<i>feature-name</i>&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Usually updates the current feature branch from its upstream, or pulls changes from a specified development branch into the feature branch.</i><br><br><b>track &lt;<i>feature-name</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sometimes used to check out an existing remote feature branch and set up tracking.</i><br><br>


