# CommandSection

title: CAVEATS
content:
When adding a dependency from <i>crates.io</i> without specifying a version, <i>cargo-add</i> will fetch the latest version. This adds a caret (^) requirement, meaning future builds might resolve to newer compatible versions, which could subtly change behavior if strict versioning is not desired.<br><br>For local path or Git dependencies, ensure the specified path or URL is correct and accessible. If no exact version is specified for <i>crates.io</i> dependencies, an internet connection is generally required to fetch metadata.


title: DEPENDENCY RESOLUTION
content:
By default, <i>cargo-add</i> will attempt to find the latest compatible version of a crate from <i>crates.io</i> if no version is specified. It then adds a caret (<i>^</i>) requirement (e.g., <i>^1.2.3</i>) to <i>Cargo.toml</i>, allowing Cargo to use newer compatible versions in future builds.


title: WORKSPACE SUPPORT
content:
In a Cargo workspace, <i>cargo-add</i> can be used to add dependencies to a specific package within the workspace using the <b>--package</b> (<i>-p</i>) option, or to the workspace root's <i>Cargo.toml</i> using the <b>--workspace</b> flag, facilitating centralized or per-member dependency management.


title: FEATURES
content:
The command allows fine-grained control over crate features. You can disable default features with <b>--no-default-features</b> and specify custom features with the <b>--features</b> option, enabling you to tailor the dependency's functionality to your project's needs.


title: HISTORY
content:
Initially, <i>cargo-add</i> was distributed as an external subcommand, often installed via <i>cargo install cargo-edit</i>, providing a useful utility for Rust developers. Recognizing its widespread utility and user demand, it was integrated directly into the core <b>Cargo</b> toolchain. This integration became official with Rust 1.62.0, released on June 23, 2022, making it a first-class subcommand and removing the need for a separate installation step.


title: PARAMETERS
content:
<b><b>BENCH</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, only run the benchmark target with the given name. If omitted, all benchmark targets are run.<br><br><b><b>--release</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build artifacts in release mode, with optimizations. <i>This is crucial for meaningful benchmark results.</i><br><br><b><b>-p</b> <i><SPEC></i>, <b>--package</b> <i><SPEC></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench only the specified package, useful in a workspace.<br><br><b><b>--lib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench the package's library.<br><br><b><b>--bin</b> <i><NAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench the specified binary target.<br><br><b><b>--bins</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench all binary targets.<br><br><b><b>--example</b> <i><NAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench the specified example target.<br><br><b><b>--examples</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench all example targets.<br><br><b><b>--bench</b> <i><NAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench the specified benchmark target.<br><br><b><b>--benches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench all benchmark targets.<br><br><b><b>--all-targets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench all targets (library, binaries, examples, tests, and benchmarks).<br><br><b><b>--features</b> <i><FEATURES></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space or comma separated list of features to activate.<br><br><b><b>--all-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of all packages in the workspace.<br><br><b><b>--no-default-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the `default` feature.<br><br><b><b>--target</b> <i><TRIPLE></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build for the target triple (e.g., `x86_64-unknown-linux-gnu`).<br><br><b><b>-j</b> <i><N></i>, <b>--jobs</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of parallel jobs to run. Defaults to the number of CPUs.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output from Cargo.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print Cargo log messages.<br><br><b><b>--workspace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bench all packages in the workspace.<br><br><b><b>--profile</b> <i><NAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build with the given profile (e.g., `dev`, `release`, or a custom profile).<br><br><b><b>--</b> <i><ARGS>...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments following `<b>--</b>` are passed directly to the benchmark executable. These are often used to configure the benchmarking harness, e.g., `<b>-- --noplot</b>` for Criterion.rs.<br><br>


title: DESCRIPTION
content:
The <b>cargo bench</b> command is a fundamental part of the Rust ecosystem's build tool, Cargo. It compiles and executes the benchmarks defined within a Rust project. Unlike <b>cargo test</b> which runs correctness checks, <b>cargo bench</b> focuses on measuring the performance characteristics of code sections, such as execution time, throughput, or memory usage.<br><br>Benchmarks in Rust are typically defined in separate `[[bench]]` sections in the `Cargo.toml` file or placed in the `benches/` directory. They rely on external benchmarking harnesses like <i>Criterion.rs</i> or the older <i>bencher</i> crate, as Rust's standard library does not provide a built-in benchmarking framework. When `cargo bench` is invoked, it compiles these benchmark targets and then runs them, often passing control to the chosen benchmarking harness to perform statistical analysis and report results. For accurate and meaningful performance metrics, it is crucial to run benchmarks in release mode using the `<b>--release</b>` flag, as this enables compiler optimizations that are disabled in debug builds.


title: CAVEATS
content:
Benchmarking in Rust, especially with `cargo bench`, requires careful consideration:<br><br>1.  <b>Harness Requirement:</b> Rust's standard library does <i>not</i> provide a built-in benchmarking harness. You must add an external crate like <i>Criterion.rs</i> (recommended) or <i>bencher</i> as a `dev-dependency` in your `Cargo.toml` and implement your benchmarks using its API.<br>2.  <b>Release Mode:</b> Always run benchmarks with the `<b>--release</b>` flag. Running in debug mode (default) will yield artificially slow results due to lack of compiler optimizations.<br>3.  <b>Environmental Factors:</b> Benchmark results can be highly sensitive to the operating system's state, background processes, CPU frequency scaling, and even temperature. For consistent results, run benchmarks on a stable, isolated system with minimal background activity.<br>4.  <b>Microbenchmarking Pitfalls:</b> Be aware of compiler optimizations that might optimize away code being benchmarked if it has no observable side effects. Ensure your benchmarks are measuring what you intend.


title: CONFIGURING A BENCHMARKING HARNESS (E.G., CRITERION.RS)
content:
To use `cargo bench`, you first need to configure a benchmarking harness. For <i>Criterion.rs</i>, you typically:<br><br>1.  Add `criterion` as a `dev-dependency` in your `Cargo.toml` file, for example:<br>    `[dev-dependencies]`<br>    `criterion = { version = "0.5", features = ["html_reports"] }`<br>    Then, configure the benchmark target (if using Criterion as a separate executable, which is common for full features):<br>    `[[bench]]`<br>    `name = "my_benchmarks"`<br>    `harness = false`<br><br>2.  Create a benchmark file, typically in `benches/my_benchmarks.rs`, and write your benchmark functions using the Criterion API. A simple example:<br>    `use criterion::{criterion_group, criterion_main, Criterion};`<br>    `fn bench_my_function(c: &mut Criterion) {`<br>        `c.bench_function("my_function", |b| b.iter(|| { /* code to benchmark */ }));`<br>    `}`<br>    `criterion_group!(benches, bench_my_function);`<br>    `criterion_main!(benches);`<br><br>After setup, you can run your benchmarks using `<b>cargo bench</b>` or, for optimal results, `<b>cargo bench --release</b>`.


title: PASSING ARGUMENTS TO BENCHMARKS
content:
Arguments can be passed to the benchmark executable using `<b>--</b>` after all `cargo bench` options. This is especially useful for controlling the behavior of the benchmarking harness itself.<br><br>For example, with <i>Criterion.rs</i>, you can use these arguments:<br><i>1.  Prevent HTML reports:</i> `<b>cargo bench -- --noplot</b>`<br><i>2.  Compare against a baseline:</i> `<b>cargo bench -- --baseline old_version</b>`<br><i>3.  Run only a specific benchmark function:</i> `<b>cargo bench -- --test my_benchmark_name</b>`<br>These arguments vary depending on the chosen benchmarking crate.


title: HISTORY
content:
<i>Cargo</i>, the Rust package manager and build system, has been an integral part of the Rust programming language since its early development. The `bench` subcommand was introduced to provide a standardized way of measuring code performance, reflecting Rust's strong emphasis on performance. While early Rust versions included a basic benchmarking capability via the `test` crate, the ecosystem quickly gravitated towards more sophisticated external crates like <i>Criterion.rs</i> due to their advanced statistical analysis, plotting capabilities, and robust setup for reliable performance measurement. `cargo bench` has remained the consistent interface for invoking these benchmarks, adapting to and integrating with the evolving best practices of the Rust performance community.


title: PARAMETERS
content:
<b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles the package in release mode with optimizations. Artifacts are placed in <I>target/release/</I>.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds for the specified target triple (e.g., <I>x86_64-unknown-linux-gnu</I>).<br><br><b>-p <SPEC>, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the specified package(s) within the workspace. This option can be used multiple times.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds all packages in the current workspace.<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the specified binary target. This option can be used multiple times.<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the library target of the current package.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the specified example target. This option can be used multiple times.<br><br><b>--test <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the specified test target. This option can be used multiple times.<br><br><b>--benches <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds only the specified benchmark target. This option can be used multiple times.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space or comma separated list of features to activate.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates all available features of the current package.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the <I>default</I> feature.<br><br><b>-j <N>, --jobs <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of parallel jobs to run. Defaults to the number of CPUs.<br><br><b>--profile <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds with the given build profile (e.g., <I>dev</I>, <I>release</I>, <I>test</I>, <I>bench</I>).<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses verbose output, printing more information during the build process.<br><br><b>--message-format <FMT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The output format for messages (e.g., <I>json</I>).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run'; doesn't actually build anything, just prints what would be done.<br><br>


title: DESCRIPTION
content:
<b>cargo build</b> is the fundamental command within the Rust ecosystem's build system, <I>Cargo</I>. Its primary purpose is to compile the current package (crate) and all its dependencies into executable binaries, libraries, or other build artifacts. When you execute <b>cargo build</b> in a Rust project directory, Cargo reads the <I>Cargo.toml</I> manifest file to understand the project's structure, dependencies, and configuration. It then proceeds to download and compile any missing dependencies, followed by the compilation of your own source code. By default, <b>cargo build</b> compiles in <I>debug mode</I>, which includes debugging symbols and performs fewer optimizations, making the compilation process faster and debugging easier. For production-ready builds, the <b>--release</b> flag is used to compile in <I>release mode</I>, which applies aggressive optimizations for performance and produces smaller binaries. Cargo intelligently caches compiled dependencies, meaning subsequent builds are significantly faster as only changed files and their dependents are recompiled. This command is essential for developing, testing, and preparing Rust applications for deployment.


title: CAVEATS
content:
Requires a correctly installed <I>Rust toolchain</I> (Rust compiler <I>rustc</I> and Cargo itself).<br>The first build of a project or when dependencies change significantly can be time-consuming and consume considerable disk space, especially for large dependency trees.<br>Cross-compilation using <b>--target</b> often requires specific target toolchains to be installed (e.g., via <I>rustup target add <TRIPLE></I>).<br>Network access is required for downloading new dependencies from <I>crates.io</I>.


title: BUILD PROFILES AND OUTPUT PATHS
content:
By default, <b>cargo build</b> compiles in the <I>debug</I> profile, placing artifacts in <I>project_root</I>/<I>target</I>/<I>debug</I>/. When <b>cargo build --release</b> is used, it compiles in the <I>release</I> profile, with artifacts located in <I>project_root</I>/<I>target</I>/<I>release</I>/. These profiles can be customized in <I>Cargo.toml</I> to define different compilation settings, such as optimization levels, debug info, and link-time optimizations, for various build scenarios.


title: INCREMENTAL COMPILATION
content:
<b>cargo build</b> leverages incremental compilation to speed up rebuilds. After the initial full build, Cargo only recompiles the parts of the code that have changed and any parts that depend on them. This significantly reduces compilation times for iterative development, making the edit-compile-test cycle much faster. The compiled artifacts and metadata for incremental builds are stored in <I>project_root</I>/<I>target</I>/<I>debug</I>/.fingerprint/ and other subdirectories.


title: HISTORY
content:
<I>Cargo</I> was developed alongside the Rust programming language itself, becoming an integral part of the Rust ecosystem. Its development began early in Rust's history, with a significant push for its stabilization and feature completeness leading up to the 1.0 release of Rust in May 2015. Since then, <b>cargo build</b> has been the standard way to compile Rust projects, abstracting away the complexities of managing source files, dependencies, and build configurations. Its design emphasizes convention over configuration, making it easy for developers to get started without extensive setup. Continuous development has added support for workspaces, features, profiles, and more granular control over the build process, solidifying Cargo's position as the official and indispensable build system and package manager for Rust.


title: SYNOPSIS
content:
<b>cargo check</b> [<I>OPTIONS</I>]<br><br>Common invocation patterns:<br><b>cargo check</b><br><b>cargo check</b> --release<br><b>cargo check</b> --target x86_64-unknown-linux-gnu


title: PARAMETERS
content:
<b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for the specified target triple (e.g., x86_64-unknown-linux-gnu).<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check with optimizations, indicating a release build profile. This also disables debug assertions.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check all packages in the current workspace.<br><br><b>-p <SPEC>, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified package. This may be a package ID specification.<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified binary target.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified example target.<br><br><b>--test <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified test target.<br><br><b>--bench <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified benchmark target.<br><br><b>--all-targets</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check all available targets (bins, examples, tests, benches, and the library).<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated list of features to activate for the current package.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features for the current package.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the default features for the current package.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print cargo log messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details about the process.<br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: 'auto' (default), 'always', 'never'.<br><br><b>--message-format <FMT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output compiler messages in a specific format (e.g., 'json', 'json-diagnostic-rendered-ansi').<br><br>


title: DESCRIPTION
content:
<b>cargo check</b> is a Rust command-line tool that performs a <I>fast, non-linking compilation</I> of a local package and all its dependencies. Unlike <b>cargo build</b>, it <I>does not produce an executable or a library</I>. Its primary purpose is to <I>validate code for compilation errors, warnings, and correctness issues</I> without incurring the overhead of code generation and linking. This makes it significantly faster for iterative development, allowing developers to quickly catch syntax errors, type mismatches, and other basic compilation failures. It's often used as a preliminary step before <b>cargo build</b> or <b>cargo test</b> to ensure the code is syntactically and semantically sound.


title: CAVEATS
content:
Does not produce an executable; it's purely a <I>syntax and type checking pass</I>.<br>While faster than <b>cargo build</b>, it still performs full type checking and can be slow on very large codebases.<br>It will not catch runtime errors or issues related to linking.<br>Requires a <I>Cargo.toml</I> file in the current directory or a parent directory to identify the project.


title: INTEGRATION WITH IDES
content:
Many Rust IDE plugins or language servers (e.g., <I>rust-analyzer</I>) use <b>cargo check</b> under the hood to provide immediate compilation errors and warnings as you type, significantly enhancing the development experience by offering real-time feedback.


title: HISTORY
content:
<b>cargo</b> is the official Rust package manager and build system, introduced alongside the Rust programming language. The <b>check</b> subcommand was added relatively early in <b>cargo</b>'s development (around the Rust 1.10 timeframe, released in July 2016) to address the need for a faster compilation feedback loop. Before <b>check</b>, developers often had to run <b>cargo build</b> to validate code, which was slower due to code generation and linking. <b>cargo check</b> was designed specifically to provide quick feedback on correctness, making it an essential tool for rapid iterative development in Rust.


title: PARAMETERS
content:
<b>-p <SPEC>, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean only the specified package's artifacts within the workspace.<br><br><b>--doc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean only the <i>target/doc</i> directory, where documentation generated by <i>cargo doc</i> resides.<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean artifacts from the <i>target/release</i> directory (optimized build) instead of the default <i>target/debug</i> directory.<br><br><b>--profile <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean artifacts for a specific build profile (e.g., <i>dev</i>, <i>release</i>, or a custom profile).<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean artifacts only for the specified target triple (e.g., <i>x86_64-unknown-linux-gnu</i>).<br><br><b>--target-dir <DIR></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where all generated artifacts are stored. Defaults to <i>target</i> relative to the workspace root.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print Cargo's `clean` output messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, printing more information during the cleaning process.<br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: <i>auto</i>, <i>always</i>, <i>never</i>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information about the command.<br><br>


title: DESCRIPTION
content:
The <b>cargo clean</b> command is used to remove the <i>target</i> directory, which contains all compiled artifacts generated by Rust's build system (Cargo). This includes executables, libraries, intermediate object files, and documentation generated by <i>cargo doc</i>. Its primary purposes are to free up disk space, ensure a clean build from scratch for troubleshooting, or to prepare a project for distribution without unnecessary compiled files. Running <b>cargo clean</b> ensures that the next build will be a full recompilation, which can resolve issues caused by stale or corrupted build caches.


title: CAVEATS
content:
Using <b>cargo clean</b> deletes all compiled outputs, meaning the next build will require a full recompilation of your project and its dependencies, which can be time-consuming. It does <b>not</b> clean Cargo's global caches (e.g., downloaded crates in <i>~/.cargo/registry</i> or git checkouts in <i>~/.cargo/git</i>), nor does it remove files from the <i>.cargo/bin</i> directory for installed binaries.


title: WHEN TO USE
content:
<b>cargo clean</b> is particularly useful in several scenarios:<br> - When troubleshooting persistent build errors that might be due to stale artifacts.<br> - To free up disk space, as compiled projects, especially with multiple build profiles or targets, can consume significant storage.<br> - Before distributing a project or committing to version control, to ensure only source files are included.<br> - In Continuous Integration/Continuous Deployment (CI/CD) pipelines to guarantee a fresh build environment for each job.


title: PARTIAL CLEANING
content:
While <b>cargo clean</b> by default removes the entire <i>target</i> directory, options like <i>--doc</i>, <i>--release</i>, <i>--profile</i>, and <i>--target</i> allow for more granular control, enabling you to clean only specific subsets of artifacts without deleting everything. This is useful if you only want to clear, for instance, release builds without affecting your debug development flow.


title: HISTORY
content:
<b>Cargo</b>, the Rust package manager and build system, was introduced early in Rust's development (around 2014) to standardize project management, dependency resolution, and compilation. The <b>cargo clean</b> command has been a fundamental utility within Cargo from its inception, providing a straightforward and integrated way to manage build artifacts and maintain a tidy development environment.


title: SYNOPSIS
content:
cargo clippy [<i>options</i>] [<i>--</i> <I>rustc/clippy_args</I>...]<br><br>Common invocation examples:<br><code>cargo clippy</code><br><code>cargo clippy --fix</code><br><code>cargo clippy -- -D warnings</code><br><code>cargo clippy -p my_crate --target x86_64-unknown-linux-gnu</code>


title: PARAMETERS
content:
<b>--package <SPEC>, -p <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run clippy only for the specified package(s).<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run clippy for all packages in the current workspace.<br><br><b>--all-targets</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check all targets (library, binaries, tests, examples, benchmarks).<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified binary target.<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the library target.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified example target.<br><br><b>--test <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified test target.<br><br><b>--bench <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only the specified benchmark target.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated list of features to activate.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the default features.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build for the specified target triple (e.g., <I>x86_64-unknown-linux-gnu</I>).<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build artifacts in release mode, with optimizations.<br><br><b>--profile <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build artifacts with the specified profile.<br><br><b>--fix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically fix code when possible based on clippy suggestions.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print cargo log messages.<br><br><b>--message-format <FMT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output messages in specified format (e.g., <I>human</I>, <I>json</I>, <I>json-render-diagnostics</I>, <I>short</I>).<br><br><b>-- <ARGS>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments following <B>--</B> are passed directly to the underlying <I>rustc</I> and <I>clippy</I> invocation. This is commonly used for setting lint levels (e.g., <B>-D warnings</B> to treat all warnings as errors, or <B>-D clippy::unwrap_used</B> to deny specific lints).<br><br>


title: DESCRIPTION
content:
<i>cargo-clippy</i> is a powerful <B>linting tool</B> for the <B>Rust programming language</B> that extends the analysis capabilities of the standard Rust compiler (<i>rustc</i>). Unlike <i>rustc</i>, which focuses on syntax and type correctness, <i>clippy</i> performs deeper static analysis to identify common programming mistakes, stylistic deviations, potential bugs, and sub-optimal code patterns. It offers <I>actionable suggestions</I> to improve code quality, readability, and performance. <i>clippy</i> includes a vast collection of lints, which are highly configurable and categorized by severity (e.g., <B>warn</B>, <B>deny</B>). It integrates seamlessly with the <B>Cargo build system</B>, making it easy to incorporate into development workflows and CI/CD pipelines. Utilizing <i>clippy</i> helps enforce best practices, reduce technical debt, and elevate the overall standard of Rust code in projects.


title: CAVEATS
content:
<B>False Positives:</B> While <I>clippy</I> is highly effective, it can occasionally flag code that is intentionally written in a specific way, leading to false positives. These can usually be suppressed using <code>#[allow(clippy::lint_name)]</code> attributes on the specific code.<br><B>Performance:</B> Running <I>clippy</I> can be noticeably slower than a standard <code>cargo build</code> due to the extensive static analysis it performs. For quicker feedback, it's often integrated into CI pipelines or run selectively rather than on every minor code change.<br><B>Configuration Complexity:</B> With hundreds of lints, configuring <I>clippy</I> to precisely suit a project's needs can initially seem daunting. However, its powerful customization options via <i>clippy.toml</i> or <i>Cargo.toml</i> allow for fine-grained control.


title: CONFIGURATION
content:
<i>cargo-clippy</i>'s behavior and lint settings can be extensively customized. The primary methods include: <br>1. A <I>clippy.toml</I> file placed in the project root directory. <br>2. Adding a <code>[lints.clippy]</code> section directly to your project's <I>Cargo.toml</I> file. <br>These configuration files allow developers to adjust the severity levels of specific lints, disable lints, or configure thresholds for certain checks (e.g., maximum function complexity, maximum number of arguments).


title: LINT LEVELS
content:
Lints in <i>clippy</i> can be assigned various levels, determining how they are reported: <br>• <I>allow</I>: The lint is ignored.<br>• <I>warn</I>: The lint is reported as a warning.<br>• <I>deny</I>: The lint is treated as an error, causing the build to fail.<br>• <I>forbid</I>: Similar to <I>deny</I>, but also prevents overriding the lint level with <code>#[allow(...)]</code> attributes.<br>These levels can be set project-wide in configuration files or specified on the command line using the <B>--</B> separator (e.g., <code>cargo clippy -- -D clippy::unwrap_used</code>).


title: HISTORY
content:
<i>cargo-clippy</i> originated as an independent community-driven project named <I>rust-clippy</I>. Its significant utility and widespread adoption led to its official integration into the main <B>Rust project repository</B> (<i>rust-lang/rust</i>) in 2017. This integration solidified <i>clippy</i>'s role as the <I>official linter</I> for the Rust programming language. Since then, it has been maintained and developed in tandem with the Rust compiler itself, ensuring continuous compatibility with new Rust versions and language features. Its consistent evolution has made it an indispensable tool for Rust developers striving for high-quality, idiomatic code.


title: PARAMETERS
content:
<b><b>--open</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the generated documentation in your default web browser after compilation.<br><br><b><b>--no-deps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates documentation only for the current package, omitting documentation for its dependencies.<br><br><b><b>--document-private-items</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes documentation for private items (not just public ones). Useful for internal development or debugging.<br><br><b><b>--target <I>TRIPLE</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds documentation for a specific target triple (e.g., <i>x86_64-unknown-linux-gnu</i>).<br><br><b><b>-p <I>SPEC</I></b>, <b>--package <I>SPEC</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents only the specified package. This is useful in workspaces with multiple crates.<br><br><b><b>--features <I>FEATURES</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space or comma separated list of features to activate when building the documentation.<br><br><b><b>--all-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates all available features of the package and its dependencies.<br><br><b><b>--no-default-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the <i>default</i> feature of the package.<br><br><b><b>--release</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds documentation with release optimizations, similar to <i>cargo build --release</i>.<br><br><b><b>--target-dir <I>DIRECTORY</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the directory where generated artifacts (including documentation) are placed.<br><br><b><b>--workspace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents all members of the current workspace.<br><br><b><b>--lib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents only the library target of the current package.<br><br><b><b>--bin <I>NAME</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents only the specified binary target.<br><br><b><b>--bins</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents all binary targets.<br><br><b><b>--all-targets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Documents all available targets (library, binaries, examples, tests, benches).<br>Note: Many common <i>cargo</i> options like <i>-v</i> (verbose) or <i>--color</i> are also supported.<br><br>


title: DESCRIPTION
content:
<i>cargo doc</i> is a subcommand of Cargo, Rust's official build system and package manager. Its primary purpose is to generate comprehensive, browsable HTML documentation for a Rust project's crates and their dependencies. It leverages the <i>rustdoc</i> tool, which parses your Rust source code, specifically focusing on <I>doc comments</I> (lines starting with <i>///</i> or <i>//!</i>) and public API definitions. These doc comments can contain Markdown formatting, allowing developers to write rich, readable explanations, examples, and usage guides directly within the code.<br><br>By default, <i>cargo doc</i> generates documentation for all public items within your crate and its dependencies, placing the output in the <i>target/doc/</i> directory. The generated documentation includes an <i>index.html</i> file that serves as the entry point, providing navigation to all documented modules, structs, enums, functions, and traits. This command is invaluable for understanding both your own codebase and external libraries, providing an interactive, searchable interface to explore APIs and understand their usage without needing to consult external websites or manually parse source code.


title: CAVEATS
content:
<i>cargo doc</i> relies heavily on the <i>rustdoc</i> tool, which must be part of your installed Rust toolchain. By default, it only generates documentation for public items; use <i>--document-private-items</i> to include private ones. While doc comments support Markdown, specific syntax is required for internal links (e.g., <i>[<code>struct_name</code>]</i> for types or <i>[<code>module::function</code>]</i> for functions). Generating documentation for large projects with many dependencies can be time-consuming due to the compilation and processing involved.


title: DOC COMMENTS
content:
Rust supports two main types of doc comments:<br><i>///</i>: Outer doc comments, which document the item they are attached to.<br><i>//!</i>: Inner doc comments, which document the item that contains them (e.g., a crate or module).<br>Both support Markdown syntax for rich formatting, code examples, and linking to other items.


title: OUTPUT LOCATION
content:
The generated HTML documentation is typically placed in the <i>target/doc/</i> directory within your project. Each crate gets its own subdirectory, and the main entry point is usually <i>target/doc/your_crate_name/index.html</i> or <i>target/doc/index.html</i> for the root of all documented crates (including dependencies).


title: DOCTESTS
content:
While <i>cargo doc</i> generates documentation, it's worth noting that code examples within doc comments can also be executed as part of your test suite using <i>cargo test</i>. This ensures that your documentation's code examples remain correct and up-to-date, a powerful feature for maintaining high-quality documentation.


title: HISTORY
content:
The concept of integrated documentation generation has been a cornerstone of the Rust language and its tooling from early on. <i>rustdoc</i>, the underlying tool for <i>cargo doc</i>, has continuously evolved alongside the language, adding features like improved search, theme support, and sophisticated cross-crate linking. <i>cargo doc</i> itself, as a core Cargo subcommand, has been available since Cargo's inception, making documentation generation a seamless and standard part of the Rust development workflow. Its stable presence underscores Rust's strong emphasis on clear, accessible, and high-quality API documentation.


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch all dependencies for all packages in the workspace.<br><br><b>--target <i><triple></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch dependencies only for the specified target triple (e.g., <i>x86_64-unknown-linux-gnu</i>).<br><br><b>--jobs <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of parallel jobs to run.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch dependencies for the current workspace. This is the default if no package is specified.<br><br><b>-p <i><SPEC></i>, --package <i><SPEC></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch dependencies for a specific package in the workspace.<br><br><b>--manifest-path <i><PATH></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <i>Cargo.toml</i> file for the package.<br><br><b>--frozen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <i>Cargo.lock</i> to be up-to-date. If not, Cargo will exit with an error.<br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <i>Cargo.lock</i> to be present and up-to-date. If not, Cargo will exit with an error. Unlike <b>--frozen</b>, this implies <i>Cargo.lock</i> must exist.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in offline mode, using only cached dependencies. No network requests will be made.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details about the fetching process.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print <b>cargo</b> log messages, only errors.<br><br><b>--color <i><WHEN></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control color output (`auto`, `always`, `never`).<br><br><b>--features <i><FEATURES></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space or comma separated list of features to activate for the current package.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of the current package.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the `default` feature of the current package.<br><br><b>--ignore-rust-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore <i>rust-version</i> specification in packages. Useful for older toolchains.<br><br><b>--registry <i><registry></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the registry to use (e.g., <i>crates-io</i>).<br><br><b>--index <i><index></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;URL of the registry index to use.<br><br><b>--profile <i><NAME></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetch dependencies for the specified profile (e.g., <i>dev</i>, <i>release</i>). This influences conditional dependencies.<br><br>


title: DESCRIPTION
content:
<b>cargo fetch</b> is a subcommand of the Rust package manager, <b>cargo</b>. Its primary function is to download all direct and transitive dependencies required by the current Rust project (or specified packages) into the local Cargo registry cache. Unlike <b>cargo build</b> or <b>cargo run</b>, <b>cargo fetch</b> does not compile any code; it solely fetches the source code of the dependencies.<br><br>This command is particularly useful for preparing a project for offline development, ensuring that all necessary crates are available locally without an internet connection, or for pre-populating build environments in CI/CD pipelines. It respects the <i>Cargo.lock</i> file, meaning it will download the exact versions of dependencies recorded there, ensuring reproducible builds. If no <i>Cargo.lock</i> exists or <b>--locked</b> is not specified, it may perform an update to determine the latest compatible versions before fetching. The downloaded crates are stored in Cargo's global cache, typically located in <i>~/.cargo/registry/src</i>, making them accessible to multiple projects.


title: CAVEATS
content:
<ul><li><b>Disk Space:</b> Fetching numerous or large dependencies can consume significant disk space in the Cargo cache over time.</li><li><b>Network Requirement:</b> Requires an active internet connection to download dependencies if they are not already cached.</li><li><b><i>Cargo.lock</i> Importance:</b> While <b>cargo fetch</b> uses <i>Cargo.lock</i>, running it without <b>--locked</b> might trigger an update of the <i>Cargo.lock</i> file, potentially fetching newer dependency versions than intended if <i>Cargo.toml</i> allows it. Use <b>--locked</b> for strict reproducibility.</li><li><b>No Compilation:</b> This command only downloads; it does not compile or build the fetched crates. Subsequent commands like <b>cargo build</b> or <b>cargo run</b> are still needed for compilation and execution.</li></ul>


title: CACHE LOCATION
content:
Dependencies fetched by <b>cargo fetch</b> are stored in Cargo's global cache, typically located at <i>~/.cargo/registry/src/</i> on Linux. This cache is shared across all Rust projects on the system, avoiding redundant downloads and saving disk space.


title: OFFLINE DEVELOPMENT WORKFLOW
content:
After running <b>cargo fetch</b>, you can work on your project and perform builds (<b>cargo build</b>) or runs (<b>cargo run</b>) without an internet connection, provided all necessary dependencies were successfully fetched beforehand. For strict offline operation during subsequent commands, you can combine them with the <b>--offline</b> flag (e.g., <b>cargo build --offline</b>).


title: HISTORY
content:
The <b>cargo fetch</b> command has been an integral part of the Rust <b>cargo</b> build system since its early development stages. As <b>cargo</b> evolved into a robust package manager, the need for efficient dependency management, including pre-fetching for offline use or CI/CD pipelines, made <b>fetch</b> a foundational component. Its design aligns with <b>cargo</b>'s philosophy of reproducible builds, heavily relying on the <b>Cargo.lock</b> file to ensure consistent dependency versions across environments. It has seen continuous refinement alongside the broader <b>cargo</b> and Rust ecosystem, with new options added to cater to specific use cases.


title: PARAMETERS
content:
<b>--edition</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fixes warnings and errors specifically related to the current Rust edition.<br><br><b>--prepare-for <EDITION></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies fixes to prepare the code for migration to a specified future Rust edition.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates all available features of the crate being fixed.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents activation of the <i>default</i> feature of the crate.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a space-separated list of features to activate during the fix process.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies fixes to all packages within the current Cargo workspace.<br><br><b>-p <SPEC>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fixes only the specified packages by their name or path.<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fixes only the library target of the current package.<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fixes only the specified binary target of the current package.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fixes code for a specific compilation target triple (e.g., <i>x86_64-unknown-linux-gnu</i>).<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the fix process.<br><br>


title: DESCRIPTION
content:
<i>cargo fix</i> is a powerful subcommand of the Rust package manager, Cargo, designed to automatically apply common compiler suggestions to fix code. Its primary purpose is to help Rust developers migrate code to newer Rust editions, fix deprecated syntax, or apply automatic suggestions from compiler lints (e.g., from <i>rustc</i> or <i>Clippy</i>).<br><br>The command works by internally running <i>cargo check</i> (or a similar build process) and parsing the structured diagnostics output from the Rust compiler. When the compiler identifies a warning or error for which it can suggest a deterministic fix, <i>cargo fix</i> applies these changes directly to the source code files. This automates routine code modernization and cleanup, significantly reducing manual effort. It is particularly valuable when upgrading large projects across Rust editions or when dealing with numerous minor warnings. Users are always encouraged to review the changes made by <i>cargo fix</i>, typically via version control diffs, before committing them.


title: CAVEATS
content:
While powerful, <i>cargo fix</i> doesn't resolve all compilation issues; it only applies fixes for problems where the compiler provides an explicit suggestion. Always review the changes made by <i>cargo fix</i> using a version control system (e.g., <i>git diff</i>) before committing them, as automated changes, though usually safe, should be verified. In rare cases, applying one fix might reveal or introduce new warnings or errors that require manual intervention. It also typically requires a working internet connection for dependency resolution unless the <i>--offline</i> flag is used.


title: HOW IT WORKS
content:
<i>cargo fix</i> operates by invoking the Rust compiler (<i>rustc</i>) in a way that generates machine-readable JSON output for its diagnostics. The compiler provides 'suggestions' within this output, detailing a specific span of code to modify and the replacement text. <i>cargo fix</i> then parses these suggestions and applies the necessary changes directly to the source files on disk. It intelligently handles multiple suggestions within a single file and ensures proper file encoding. This mechanism makes it highly reliable for applying compiler-recommended changes.


title: IDEMPOTENCY
content:
When run multiple times on the same codebase, <i>cargo fix</i> is generally idempotent for a given set of compiler diagnostics. This means that once all fixable issues have been addressed, subsequent runs on the same codebase without code changes should ideally result in no further modifications. It applies deterministic changes based on the compiler's output, ensuring consistent results.


title: HISTORY
content:
<i>cargo fix</i> was introduced as an experimental feature with the release of the Rust 2018 Edition. Its primary motivation was to provide an automated path for migrating existing Rust 2015 codebases to the new edition, addressing breaking changes and deprecations. Following its successful adoption, it became a stable and integral part of the Cargo toolchain. Its development is closely tied to the Rust compiler's diagnostic system, which is continually improved to provide more precise and actionable suggestions. This command has significantly streamlined the process of keeping Rust projects up-to-date with new language features, deprecations, and best practices across different Rust editions.


title: PARAMETERS
content:
<b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format all packages in the current workspace.<br><br><b><b>--package</b> <<i>SPEC</i>>, <b>-p</b> <<i>SPEC</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the specified package.<br><br><b><b>--lib</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the current package's library.<br><br><b><b>--bin</b> <<i>NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the specified binary.<br><br><b><b>--example</b> <<i>NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the specified example.<br><br><b><b>--test</b> <<i>NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the specified test.<br><br><b><b>--bench</b> <<i>NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format only the specified benchmark.<br><br><b><b>--target</b> <<i>TRIPLE</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format for the given target triple.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print <i>rustfmt</i> output to stdout.<br><br><b><b>--message-format</b> <<i>FMT</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output messages in a specific format (e.g., human, json).<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output.<br><br><b><b>--color</b> <<i>WHEN</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used (auto, always, never).<br><br><b><b>--config-cli</b> <<i>KEY=VALUE</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a <i>rustfmt</i> config option directly from the command line, overriding <i>rustfmt.toml</i>.<br><br><b><b>--</b> <<i>RUSTFMT_OPTIONS</i>>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass arbitrary options directly to the underlying <i>rustfmt</i> command. Common <i>rustfmt</i> options include <i>--check</i> (to only check formatting without writing), <i>--emit stdout</i> (to print to stdout), or <i>--files</i> <<i>path</i>>... (to format specific paths).<br><br>


title: DESCRIPTION
content:
<i>cargo-fmt</i> is a convenient subcommand of <i>cargo</i>, the Rust package manager, designed to automatically format Rust source code. It acts as a wrapper around <i>rustfmt</i>, the official Rust code formatter, ensuring consistent code style across projects. This consistency greatly enhances code readability, maintainability, and streamlines collaborative development.<br><br>When invoked without arguments, <i>cargo-fmt</i> formats all Rust files within the current package. It can also target specific packages, binaries, or libraries. A key feature is the ability to pass arbitrary <i>rustfmt</i> options using a double-dash (<i>--</i>), enabling functionalities like checking formatting without modifying files (<i>--check</i>) or printing formatted code to stdout. The formatting rules are highly configurable via a <i>rustfmt.toml</i> file placed in the project root or parent directories, allowing teams to tailor the style to their preferences while still benefiting from automation.


title: CAVEATS
content:
<i>cargo-fmt</i> requires <i>rustfmt</i> to be installed and available in the system's PATH, which is typically done via <i>rustup component add rustfmt</i>. While highly configurable through <i>rustfmt.toml</i>, <i>rustfmt</i> is an opinionated formatter, meaning it enforces a specific style. Always commit your changes or back up your code before running <i>cargo-fmt</i>, as it modifies files in place.


title: CONFIGURATION
content:
<i>cargo-fmt</i> respects configuration options defined in a <i>rustfmt.toml</i> file. This file can be placed in the project root or a parent directory, allowing for per-project or per-workspace customization of formatting rules. Options like <i>max_width</i>, <i>tab_spaces</i>, and <i>imports_layout</i> can be adjusted here.


title: CI/CD INTEGRATION
content:
The command <i>cargo fmt -- --check</i> is invaluable for Continuous Integration/Continuous Deployment (CI/CD) pipelines. It allows you to verify that all code in the repository adheres to the defined formatting standards without actually modifying any files, thus failing the build if unformatted code is detected. This ensures code style consistency before merging changes.


title: HISTORY
content:
<i>rustfmt</i>, the core formatting tool, was initially developed by Nick Cameron and others, evolving into an official component of the Rust distribution. The <i>cargo-fmt</i> subcommand was later introduced as a seamless integration with <i>cargo</i>, simplifying the workflow for Rust developers to apply consistent code formatting across their projects. This standardization effort helps maintain high code quality and readability within the Rust ecosystem, continually evolving with new Rust editions and community contributions.


title: PARAMETERS
content:
<b><b>--manifest-path</b> <i>&lt;PATH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <i>Cargo.toml</i> file. If not specified, Cargo will search for it in the current directory and parent directories.<br><br><b><b>--workspace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the current workspace. This requires the crate to be a member of a workspace.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run without accessing the network. Fails if dependencies are not found in the local cache.<br><br><b><b>--frozen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <i>Cargo.lock</i> and all dependencies to be up-to-date. If not, Cargo will exit with an error. This is a stronger check than <b>--locked</b>.<br><br><b><b>--locked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <i>Cargo.lock</i> to be up-to-date. If not, Cargo will exit with an error. Allows network access if necessary for other operations.<br><br><b><b>--features</b> <i>&lt;FEATURES&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated list of features to activate when resolving dependencies. The resolver will include dependencies required by these features.<br><br><b><b>--all-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of all packages in the workspace (or the current package if not in a workspace) when resolving dependencies.<br><br><b><b>--no-default-features</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the default features of the resolved package or packages in the workspace.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output messages, including information about the resolver's process.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print Cargo log messages. Only errors will be output.<br><br><b><b>--color</b> <i>&lt;WHEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: <i>auto</i> (default), <i>always</i>, <i>never</i>.<br><br>


title: DESCRIPTION
content:
The <b>cargo generate-lockfile</b> command is a built-in subcommand of Rust's package manager, Cargo. Its primary purpose is to ensure that a <i>Cargo.lock</i> file exists and is up-to-date for a given Rust project based on its <i>Cargo.toml</i> manifest.<br><br>Unlike <b>cargo build</b> or <b>cargo fetch</b>, which also interact with the lockfile, <b>cargo generate-lockfile</b> solely focuses on resolving and writing the dependency graph. It does not download source code for dependencies (unless necessary for resolution metadata) and does not compile any code. This makes it particularly useful in continuous integration (CI) environments or for reproducible builds, where you want to guarantee a consistent dependency set without performing a full build or risking unwanted dependency updates from <b>cargo update</b>.


title: CAVEATS
content:
This command does <i>not</i> download source code for dependencies (unless strictly necessary for metadata resolution) nor compile any code. Its sole purpose is to resolve and write the <i>Cargo.lock</i> file.<br><br>It can fail if network access is required for dependency resolution (e.g., new dependencies or missing cache) and <b>--offline</b> is used, or if the <i>Cargo.toml</i> contains unresolvable dependencies.<br><br>While it ensures a <i>Cargo.lock</i>, it does not guarantee that all dependency sources are downloaded or ready for compilation; for that, <b>cargo fetch</b> or <b>cargo build</b> would be needed.


title: USE CASES
content:
Ideal for CI/CD pipelines to ensure a consistent <i>`Cargo.lock`</i> is present before other build steps, or for pre-populating a development environment with a resolved dependency graph without incurring compilation time. It can also be used as a pre-commit hook to ensure the lockfile is always up-to-date with <i>`Cargo.toml`</i>.


title: IDEMPOTENCY
content:
When run on a project where the <i>`Cargo.toml`</i> and an existing <i>`Cargo.lock`</i> are consistent (i.e., no changes are required to the dependency graph), the command is idempotent and will typically make no changes to the lockfile.


title: HISTORY
content:
The <b>cargo generate-lockfile</b> command was introduced as a built-in feature in Rust's Cargo package manager with Rust version 1.37.0, released on August 22, 2019. Prior to its introduction, users often relied on commands like <b>`cargo fetch`</b> or <b>`cargo build`</b> to implicitly generate or update the <i>`Cargo.lock`</i> file. This dedicated command was added to provide a clearer, more targeted way to manage the lockfile, especially for scenarios requiring reproducible builds or CI/CD pipelines where precise control over dependency resolution without full compilation was desired.


title: PARAMETERS
content:
<b><I>SUBCOMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of a `cargo` subcommand (e.g., `build`, `run`, `test`) for which to display detailed help. If this argument is omitted, `cargo help` displays general help for `cargo` itself.<br><br>


title: DESCRIPTION
content:
The `cargo help` command is a fundamental subcommand of `cargo`, the Rust package manager. Its primary function is to display comprehensive help information related to `cargo` itself or any of its numerous subcommands. When invoked simply as `<b>cargo help</b>`, it provides an overview of available `cargo` commands, common options, and basic usage instructions. This serves as an excellent starting point for new users or a quick reference for experienced developers.<br><br>The power of `cargo help` extends to individual subcommands by appending the subcommand's name, for example, `<b>cargo help build</b>` or `<b>cargo help run</b>`. This action provides detailed insights into a specific subcommand's purpose, syntax, available options, and argument expectations. It's an indispensable tool for understanding command-line interfaces without needing to consult external documentation or online resources.<br><br>By centralizing help documentation directly within the tool, `cargo help` significantly improves developer productivity and the discoverability of features within the Rust ecosystem, ensuring users can quickly find the information they need to effectively use `cargo` for building, running, testing, and publishing Rust projects.


title: CAVEATS
content:
`cargo help` is not a standalone executable; it must always be invoked through the `cargo` binary (e.g., `<b>cargo help</b>`, not just `help`).<br>Its functionality relies on a correctly installed Rust toolchain.<br>The output and specific help messages provided by `cargo help` may vary slightly between different versions of `cargo` as features are added or modified.


title: GLOBAL CARGO OPTIONS
content:
While `cargo help` itself takes minimal specific parameters, it respects the <I>global</I> `cargo` options that can be applied to any subcommand. These options typically precede the subcommand itself. Examples include, but are not limited to, `<b>--verbose</b>` (to show more detailed output), `<b>--quiet</b>` (to suppress non-error messages), `<b>--color</b> <I>WHEN</I>` (to control color output), and `<b>--locked</b>`. For instance, to get verbose help for the `build` subcommand, one would use: `<b>cargo --verbose help build</b>`.


title: HISTORY
content:
The `cargo help` subcommand has been an integral part of the `cargo` command-line interface since its early development phases, predating Rust's 1.0 stable release. Its design aligns with the common Unix philosophy of providing self-documenting tools with built-in help. As `cargo` and the Rust ecosystem have evolved, with new subcommands and options being introduced regularly, `cargo help` has consistently adapted, serving as a dynamic and up-to-date source of command usage information for developers. Its consistent presence reinforces `cargo`'s commitment to user-friendliness and feature discoverability within the Rust ecosystem.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints help information.</i><br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints version information.</i><br><br><b>--bin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Creates a binary application (default).</i><br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Creates a library project.</i><br><br><b>--vcs <VCS></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initializes a new Git, Mercurial, Pijul, or Fossil repository, or none. Valid options: git, hg, pijul, fossil, none. Default is 'git'.</i><br><br><b>--edition <EDITION></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Rust edition to use for the new project (e.g., 2015, 2018, 2021). Defaults to the latest stable edition.</i><br><br><b>--name <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the package name. By default, it derives the name from the directory name.</i><br><br><b><PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The directory to initialize the project in. If omitted, the current directory is used.</i><br><br>


title: DESCRIPTION
content:
<i>cargo init</i> is a fundamental command in the Rust ecosystem, used to set up the basic structure for a new Rust project within an existing or specified directory. Unlike `cargo new`, which creates a new directory and then initializes a project inside it, `cargo init` initializes a project in the <i>current directory</i> or a provided <i><PATH></i>.<br><br>This command is essential for developers starting a new Rust application or library, providing a ready-to-use directory layout, a `Cargo.toml` manifest file, and a boilerplate source file (e.g., `src/main.rs` for binaries or `src/lib.rs` for libraries). The `Cargo.toml` file generated by `cargo init` acts as the project's manifest, defining its name, version, dependencies, and other metadata. By default, `cargo init` creates a binary application project, but it can be configured to create a library project using the `--lib` option. It also defaults to initializing a Git repository, which can be changed or disabled with the `--vcs` option. This command streamlines the project setup process, allowing developers to quickly begin writing Rust code without manually creating directories and files.


title: CAVEATS
content:
<i>cargo init</i> will not overwrite existing files in the target directory. If `Cargo.toml` or source files (`src/main.rs`, `src/lib.rs`) already exist, the command will fail to prevent accidental data loss. <br>The command cannot be run inside an existing Cargo project. <br>By default, it initializes a Git repository; ensure Git is installed if this behavior is desired or use `--vcs none` to disable it.


title: <I>CARGO INIT</I> VS. <I>CARGO NEW</I>
content:
While both `cargo init` and `cargo new` create a new Rust project, `cargo new <PATH>` creates a <i>new directory</i> named `<PATH>` and initializes the project inside it. In contrast, `cargo init [<PATH>]` initializes a project in the <i>current directory</i> if `<PATH>` is omitted, or in the specified existing directory `<PATH>`. Use `cargo init` when you already have a project folder and want to add Cargo support to it. Use `cargo new` when you want to start a completely fresh project in a brand new folder.


title: <I>PROJECT STRUCTURE</I>
content:
Upon successful execution, `cargo init` creates a standard Rust project structure: <br>- `Cargo.toml`: The project manifest file. <br>- `src/`: Directory for source code. <br>  - `src/main.rs`: (For binary projects, default) Contains the `main` function. <br>  - `src/lib.rs`: (For library projects, with `--lib`) Contains the library's public API. <br>- `.git/`: (If `--vcs git` or default) Git repository initialized.


title: HISTORY
content:
The `cargo` package manager was developed alongside the Rust programming language from its early stages, aiming to provide a robust and integrated build system. Commands like `cargo init` and `cargo new` have been core functionalities from the beginning, simplifying project setup and adhering to best practices for Rust project structure. `cargo init` specifically addresses the need to initialize a project in an already existing directory, complementing `cargo new` which creates a new directory. Its evolution has focused on improving default settings (like the default Rust edition and VCS integration) and providing more flexibility through options, aligning with the language's stable releases and community needs.


title: SYNOPSIS
content:
<b>cargo install</b> [<I>OPTIONS</I>] <I>CRATE</I><br><b>cargo install</b> [<I>OPTIONS</I>] <I>--path</I> <I>PATH</I><br><b>cargo install</b> [<I>OPTIONS</I>] <I>--git</I> <I>URL</I> [<I>CRATE</I>]


title: PARAMETERS
content:
<b><I>CRATE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the crate to install from <I>crates.io</I>.<br><br><b><I>--version</I> <I>VERSION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specific version of the crate.<br><br><b><I>--path</I> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a crate from a local path.<br><br><b><I>--git</I> <I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a crate from a Git repository.<br><br><b><I>--force</I>, <I>-f</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces reinstallation even if the crate is already installed.<br><br><b><I>--root</I> <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the installation root directory.<br><br><b><I>--target</I> <I>TRIPLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds for a specific target architecture.<br><br><b><I>--profile</I> <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds with a specific profile (e.g., <I>release</I> or <I>debug</I>).<br><br><b><I>--features</I> <I>FEATURES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates specified features.<br><br><b><I>--all-features</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates all available features.<br><br><b><I>--no-default-features</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not activate default features.<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds with debug information (not optimized).<br><br><b><I>--offline</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Works offline, without accessing the network.<br><br><b><I>--bins</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only install binaries listed in the package.<br><br><b><I>--examples</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only install examples listed in the package.<br><br>


title: DESCRIPTION
content:
<I>cargo install</I> is a <I>Cargo</I> subcommand used to compile and install Rust executables. It fetches the specified crate from <I>crates.io</I> (Rust's package registry), a Git repository, or a local path, then compiles its binary targets and places them into a specified installation directory, typically <I>~/.cargo/bin</I>. This command is essential for distributing and using command-line tools written in Rust, making them accessible via your system's <I>PATH</I> after installation. It handles dependency resolution and compilation, similar to <I>cargo build</I>, but specifically for installation. If the binary already exists, it will be updated.


title: CAVEATS
content:
For binaries installed by <I>cargo install</I> to be directly executable from the command line, the installation directory (typically <I>~/.cargo/bin</I>) must be included in your system's <I>PATH</I> environment variable. If not, you'll need to specify the full path to run them. Compilation can be time-consuming, especially for projects with many dependencies. Conflicts can occur if you try to install a binary with the same name as an existing system command, requiring the <I>--force</I> flag for an overwrite.


title: DEFAULT INSTALLATION LOCATION
content:
By default, <I>cargo install</I> places compiled binaries into <I>$HOME/.cargo/bin</I>. This directory is usually added to your system's <I>PATH</I> by the <I>rustup</I> installer during initial setup, ensuring that installed binaries are immediately executable from any terminal location. If this is not the case, you may need to manually add <I>$HOME/.cargo/bin</I> to your <I>PATH</I> in your shell's configuration file (e.g., <I>.bashrc</I>, <I>.zshrc</I>).


title: HISTORY
content:
<I>cargo install</I> has been a core part of the <I>Cargo</I> tool since its early development alongside the Rust programming language. It emerged as the standard method for users to easily acquire and use command-line applications written in Rust, directly leveraging <I>Cargo</I>'s robust dependency management and build capabilities. Its integration into the <I>Cargo</I> ecosystem made it a fundamental component for the distribution and adoption of Rust-based tooling, becoming ubiquitous for developers publishing their command-line utilities.


title: SEE ALSO
content:
<b>cargo</b>(1): The Rust package manager and build tool., <b>rustup</b>(1): The Rust toolchain installer and manager., <b>rustc</b>(1): The Rust compiler., <b>env</b>(1): Used to manage environment variables like <I>PATH</I>.


title: PARAMETERS
content:
<b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Return the path to the workspace root's <i>Cargo.toml</i> instead of the current package's root <i>Cargo.toml</i>. If the current package is part of a workspace, this will print the workspace root. If not, it will still point to the package's own <i>Cargo.toml</i>.<br><br><b>--message-format <FORMAT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output format for the project path. Supported formats include <i>json</i> for machine-readable output and the default <i>plain</i> for just the path.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a brief help message.<br><br>


title: DESCRIPTION
content:
<i>cargo locate-project</i> is a utility subcommand for the Rust package manager, <b>Cargo</b>. Its primary function is to programmatically determine and print the absolute path to the <i>Cargo.toml</i> file that defines the current Rust project or workspace. When executed within a Rust project directory, it navigates up the directory tree until it finds the nearest <i>Cargo.toml</i> file and outputs its path.<br><br>This command is particularly useful for scripting and build systems that need to locate the project root, independent of the current working directory. It provides options to specify whether to find the package root or the workspace root, and to control the output format for machine readability.


title: CAVEATS
content:
This command must be run within a directory that is part of a <b>Cargo</b> project or workspace. If no <i>Cargo.toml</i> file is found in the current directory or any parent directories, the command will exit with an error. The output path always points to the <i>Cargo.toml</i> file itself, not its containing directory.


title: OUTPUT FORMATS
content:
The <i>--message-format</i> option significantly affects the output. When set to <i>json</i>, the command outputs a JSON object containing a single key <i>root</i> whose value is the absolute path to the <i>Cargo.toml</i> file. For example:<br><i>{"root":"/path/to/your/project/Cargo.toml"}</i><br><br>The default behavior (without <i>--message-format</i> or with <i>--message-format plain</i>) is to simply print the absolute path to the <i>Cargo.toml</i> file to standard output, followed by a newline.


title: HISTORY
content:
<i>cargo locate-project</i> was introduced as a core utility within the <b>Cargo</b> ecosystem to provide a standardized and reliable mechanism for scripts and external tools to programmatically discover the root of a <b>Cargo</b> project or workspace. This capability is crucial for automated build pipelines, IDE integrations, and custom tooling that need to operate from the correct project context, regardless of the current working directory. It streamlined project interaction by offering a consistent API for root identification.


title: PARAMETERS
content:
<b>[TOKEN]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The API token to store. If omitted, the command will prompt for it interactively via standard input.<br><br><b>--registry <REGISTRY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the registry to log into. For example, '--registry my-private-registry'. If not specified, it defaults to 'crates.io'.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information about the command and exits.<br><br>


title: DESCRIPTION
content:
The <i>cargo login</i> command is used to store an API token for authenticating with a <i>Cargo</i> registry, such as <i>crates.io</i> or a custom private registry. This token is essential for operations that require authentication, primarily publishing new crates (<i>cargo publish</i>) or managing existing ones. When executed without a token argument, <i>cargo login</i> will prompt the user to enter the token interactively. Alternatively, the token can be piped to standard input for non-interactive scripts.<br><br>The provided API token is stored in the <i>~/.cargo/credentials.toml</i> file. By default, it stores the token for the <i>crates.io</i> registry. However, the <i>--registry</i> option allows specifying a different registry, enabling authentication with private or internal <i>Cargo</i> repositories. This command streamlines the authentication process, allowing developers to interact with <i>Cargo</i> registries without manually passing authentication headers for each command.


title: CAVEATS
content:
The API token is stored in <i>~/.cargo/credentials.toml</i>. While this file's permissions are typically set to be user-readable only, the token itself is stored in plaintext. It is crucial to protect this file from unauthorized access, as the token grants publishing privileges to the associated registry. Users should ensure their tokens have appropriate scopes and revoke them if compromised or no longer needed.


title: TOKEN STORAGE LOCATION
content:
The API token is stored in the <i>~/.cargo/credentials.toml</i> file. This file uses TOML format and typically contains a section for each registry with its corresponding token.


title: CUSTOM REGISTRIES CONFIGURATION
content:
Before logging into a custom registry, it must be defined in your <i>~/.cargo/config.toml</i> file. For example:<br><i>[registries.my-private-registry]<br>index = "https://my-private-registry.com/git/index"</i><br>After configuration, you can use <i>cargo login --registry my-private-registry</i>.


title: ENVIRONMENT VARIABLE ALTERNATIVE
content:
As an alternative to storing the token via <i>cargo login</i>, you can provide a token using an environment variable. For example, for the <i>crates.io</i> registry, set <i>CARGO_REGISTRIES_CRATES_IO_TOKEN=your_token_here</i>. For a custom registry named <i>my-private-registry</i>, use <i>CARGO_REGISTRIES_MY_PRIVATE_REGISTRY_TOKEN=your_token_here</i>. This is useful for CI/CD environments or temporary authentication.


title: HISTORY
content:
The <i>cargo login</i> command has been a fundamental part of the <i>Cargo</i> build system and package manager since its early development. It was introduced to provide a standardized and user-friendly method for authenticating with <i>crates.io</i> and custom registries, a necessity for the package distribution model of the Rust ecosystem. Its inclusion significantly simplified the workflow for publishing and managing Rust crates, making secure registry interactions accessible to developers.


title: PARAMETERS
content:
<b><I>--registry</I> <I>REGISTRY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the registry to log out from. If not specified, <i>cargo-logout</i> defaults to logging out from the official crates.io registry. This name typically corresponds to an entry in the <i>.cargo/config.toml</i> file under the '[registries]' section.<br><br>


title: DESCRIPTION
content:
The <i>cargo-logout</i> command is used to remove an API token previously stored by the <i>cargo login</i> command from the local Cargo credentials file. This file, typically located at <i>~/.cargo/credentials</i>, stores authentication tokens for various package registries (like crates.io or private registries). Removing the token prevents future <i>cargo publish</i> operations from automatically authenticating with that registry from the current machine without re-logging in. This is important for security, especially when working on shared machines or after changing a registry account, ensuring that old tokens are no longer accessible locally.


title: CAVEATS
content:
Logging out with <i>cargo-logout</i> only removes the token from your local machine's credentials file. It does <b>not</b> revoke the token on the registry's server. If the token was compromised or you want to invalidate it globally, you must do so through the respective registry's website or API (e.g., crates.io user account settings).


title: CREDENTIAL STORAGE
content:
API tokens are stored in the user's home directory within the <i>.cargo/credentials</i> file. This file is typically a TOML file that looks something like:<br><i>[registry]<br>token = "YOUR_TOKEN_HERE"</i><br>It's crucial to keep this file secure as it contains sensitive authentication information.


title: DEFAULT REGISTRY
content:
When no <i>--registry</i> option is provided, <i>cargo-logout</i> implicitly targets the default registry, which is <i>crates.io</i>. This simplifies the command for most common use cases involving the official Rust package registry.


title: HISTORY
content:
The ability to manage API tokens (via <i>cargo login</i> and <i>cargo logout</i>) was introduced into Cargo to support publishing packages to crates.io and later to private or custom registries. These commands provide a secure and convenient way to authenticate operations like <i>cargo publish</i> without embedding tokens directly in commands or environment variables, which is less secure.


title: SYNOPSIS
content:
<b>cargo owner</b> <i>&lt;SUBCOMMAND&gt;</i> [<i>OPTIONS</i>]<br><br><b>cargo owner add</b> <i>&lt;USER_NAME&gt;</i> <b>--crate</b> <i>&lt;CRATE_NAME&gt;</i> [<i>OPTIONS</i>]<br><b>cargo owner remove</b> <i>&lt;USER_NAME&gt;</i> <b>--crate</b> <i>&lt;CRATE_NAME&gt;</i> [<i>OPTIONS</i>]<br><b>cargo owner list</b> <b>--crate</b> <i>&lt;CRATE_NAME&gt;</i> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><b>add</b> <i>&lt;USER_NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a user as an owner of the specified crate. <i>&lt;USER_NAME&gt;</i> is the `crates.io` username to add.<br><br><b><b>remove</b> <i>&lt;USER_NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a user from the ownership list of the specified crate. <i>&lt;USER_NAME&gt;</i> is the `crates.io` username to remove.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all current owners of the specified crate.<br><br><b><b>--crate</b> <i>&lt;CRATE_NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Required for add, remove, list)</i> Specifies the name of the crate whose ownership will be managed. For example: <b>--crate my-package</b>.<br><br><b><b>--registry</b> <i>&lt;REGISTRY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the registry to interact with. Defaults to <b>crates.io</b> if not specified.<br><br><b><b>--token</b> <i>&lt;TOKEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An API token to use for authentication with the registry. If not provided, Cargo will attempt to use a token from the configuration.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, displaying more details about the operation.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print `cargo` log messages, suppressing non-error output.<br><br><b><b>--color</b> <i>&lt;WHEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: <b>auto</b>, <b>always</b>, <b>never</b>.<br><br><b><b>--frozen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that <b>Cargo.lock</b> and all caches are up to date before proceeding. Fails if they are not.<br><br><b><b>--locked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that <b>Cargo.lock</b> is up to date before proceeding. Fails if it is not.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run without accessing the network. Fails if network access is required for the operation.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information for the <b>owner</b> command or a specific subcommand.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information for `cargo`.<br><br>


title: DESCRIPTION
content:
<b>cargo owner</b> is an essential subcommand of <b>cargo</b>, the Rust package manager and build system. It provides functionalities to manage the ownership of a package (referred to as a "crate") that has been published to <b>crates.io</b>, the official Rust package registry. The concept of "owners" is critical for collaborative development and security: package owners are authorized to publish new versions of a crate, yank specific versions from the registry, and modify the list of other owners. This command facilitates the process of adding new developers to a project's ownership team, removing individuals who are no longer active, or simply listing all current owners for a given crate. It serves as a vital tool for maintaining control and ensuring the integrity of published Rust libraries and applications, enabling distributed teams to manage their projects efficiently. All operations performed by <b>cargo owner</b> interact directly with the <b>crates.io</b> API, necessitating proper authentication, typically achieved through an API token configured with <b>cargo</b>.


title: CAVEATS
content:
This command directly interacts with the <b>crates.io</b> registry and requires network access. <br><br> Authentication via a valid API token for your `crates.io` account is mandatory to perform ownership modifications (<b>add</b> or <b>remove</b>). <br><br> Only existing owners of a crate possess the necessary permissions to add or remove other owners. <br><br> The <b>--crate</b> option is required for the <b>add</b>, <b>remove</b>, and <b>list</b> subcommands, specifying which package's ownership is being managed.


title: CRATES.IO AUTHENTICATION
content:
To use <b>cargo owner</b> for modifying ownership (<b>add</b> or <b>remove</b>), you must be authenticated with <b>crates.io</b>. This is typically done by running <b>cargo login</b> with an API token obtained from your <b>crates.io</b> account settings. The token grants `cargo` the necessary permissions to interact with the registry on your behalf.


title: ROLE OF AN OWNER
content:
An owner of a crate on <b>crates.io</b> has significant control over the package. They can publish new versions of the crate, yank existing versions (making them unavailable for new builds), and, crucially, manage the list of other owners by adding or removing them. This shared responsibility is key for open-source project sustainability.


title: HISTORY
content:
The <b>owner</b> subcommand has been an integral part of the <b>cargo</b> tool since its early development, coinciding with the stable release of Rust 1.0 in 2015. It was designed from the outset to facilitate collaborative package maintenance on <b>crates.io</b>, enabling multiple trusted individuals to manage the lifecycle of a single Rust crate. Its stable functionality has remained consistent, serving as a core feature for managing access and control over published Rust libraries and applications.


title: PARAMETERS
content:
<b>--no-verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Skip verification of the contents of the package.</I> This means it won't build the package before packaging.<br><br><b>--no-metadata-check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Skip checking `Cargo.toml` for missing metadata.</I> Useful if you're packaging for reasons other than publishing to crates.io.<br><br><b>--allow-dirty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Allow the cargo package command to be run even if the working directory is dirty.</I> This is useful for testing or packaging non-public versions.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Perform all checks and create a temporary archive, but do not write the `.crate` file to disk.</I> Useful for seeing what would be packaged.<br><br><b>-p <SPEC>, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Package only the specified package.</I> If omitted, packages the current workspace root package.<br><br><b>-j <N>, --jobs <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Number of parallel jobs to run.</I><br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Build for the target triple.</I><br><br><b>--profile <PROFILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Build with the given profile.</I> (e.g., `dev`, `release`).<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Activate all available features.</I><br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not activate the `default` feature.</I><br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Space-separated list of features to activate.</I><br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Package the workspace root, even if not the current directory.</I><br><br><b>--manifest-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Path to the `Cargo.toml` file.</I><br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use verbose output.</I><br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not print cargo log messages.</I><br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Coloring: auto, always, never.</I><br><br><b>--frozen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Require `Cargo.lock` and `Cargo.toml` to be up-to-date and disallow network access.</I><br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Require `Cargo.lock` to be up-to-date.</I><br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Disallow network access.</I><br><br><b>--config <KEY=VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set a configuration value.</I><br><br><b>-Z <FLAG></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Unstable (nightly-only) flag.</I><br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prints help information.</I><br><br>


title: DESCRIPTION
content:
The <b>cargo package</b> command is a crucial part of the Rust ecosystem's publishing workflow. Its primary purpose is to take a Rust package (a crate) and create a <i>.crate</i> archive file, which is the standardized format for distributing Rust packages. This archive typically contains the source code of the package, its <i>Cargo.toml</i> manifest, and any other necessary files specified in <i>Cargo.toml</i>'s <I>include</I> or <I>exclude</I> directives.<br><br>Before creating the archive, <b>cargo package</b> performs several important checks to ensure the package is ready for publishing. These checks include:<br><ul><li>Verifying that the working directory is clean (no uncommitted changes).</li><li>Building the package to ensure it compiles successfully with the specified features and targets.</li><li>Running metadata checks to ensure <i>Cargo.toml</i> has essential fields like <i>description</i>, <i>license</i> or <i>license-file</i>, and <i>documentation</i>.</li></ul>This command is usually executed as a preliminary step before <b>cargo publish</b>, allowing developers to test the packaging process and inspect the generated <i>.crate</i> file locally before pushing it to a registry like crates.io.


title: CAVEATS
content:
<ul><li>By default, <b>cargo package</b> requires the Git working directory to be clean. This prevents accidentally packaging uncommitted or untracked changes. Use <b>--allow-dirty</b> to bypass this for testing purposes.</li><li>The command does not actually publish your package to a registry; it only creates the <i>.crate</i> archive. You must use <b>cargo publish</b> for that.</li><li>Skipping verification checks with <b>--no-verify</b> or <b>--no-metadata-check</b> is generally not recommended for packages intended for public distribution, as it might lead to non-compiling or improperly described packages.</li></ul>


title: OUTPUT FILE
content:
The command generates a <i>.crate</i> file (e.g., <i>my_crate-1.0.0.crate</i>) in the <i>target/package</i> directory of your project. This file is a gzipped tar archive containing all necessary files for the package.


title: VERIFICATION STEPS
content:
The default verification process ensures that the package builds successfully, its tests pass (if any), and its metadata meets publishing requirements. This helps catch potential issues before a package is published and consumed by others.


title: HISTORY
content:
The <b>cargo package</b> command is an integral part of Cargo, the Rust package manager, which was initially introduced alongside the Rust programming language itself. Cargo's development began around 2014, aiming to provide a robust and easy-to-use system for managing Rust projects, their dependencies, and their distribution. The <b>package</b> command has been a core component of Cargo's release workflow since its early stable versions, facilitating the creation of reproducible <i>.crate</i> archives necessary for publishing to crates.io, Rust's official package registry. Its design reflects Rust's emphasis on correctness and safety, performing checks before packaging to ensure a higher quality of published crates.


title: PARAMETERS
content:
<b><I>SPEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The package specification to resolve. If omitted, resolves the current package in the working directory.<br><br><b><b>-p</b> <I>SPEC</I>, <b>--package</b> <I>SPEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the package to operate on (and output its ID). This is an alternative to providing <I>SPEC</I> directly as an argument.<br><br><b><b>--workspace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the package ID for the workspace root package. Implies <I>--all</I> when used with <I>--message-format=json</I>.<br><br><b><b>--workspace-root</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the absolute path to the workspace root directory instead of a package ID.<br><br><b><b>--query-cargo-home</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the absolute path to Cargo's home directory instead of a package ID.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output all package IDs in the workspace. Usually used with <I>--message-format=json</I> for structured output.<br><br><b><b>--manifest-path</b> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <I>Cargo.toml</I> file. Defaults to the one in the current directory or a parent directory.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print warnings or other informational messages to standard error.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run without accessing the network.<br><br><b><b>--frozen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> to be up to date and do not make any network requests.<br><br><b><b>--locked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> to be up to date but allow network requests.<br><br><b><b>--color</b> <I>WHEN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls when colors are used in output: <I>auto</I>, <I>always</I>, or <I>never</I>.<br><br><b><b>--target-dir</b> <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directory for generated artifacts and intermediate files.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information.<br><br>


title: DESCRIPTION
content:
<b>cargo pkgid</b> is a utility subcommand of Cargo, Rust's package manager, designed to resolve and output the <I>package ID</I> for a given package specification. A package ID uniquely identifies a package in Cargo's build graph, typically represented as a URL-like string (e.g., <I>file:///path/to/my-package?version=1.0.0</I> or <I>https://github.com/rust-lang/cargo?tag=cargo-0.60.0</I>).<br><br>This command is primarily used in scripting contexts where a unique, canonical identifier for a package is required. It can resolve local workspace packages, registry dependencies, or Git dependencies. By default, it prints the package ID of the current package to standard output. It's an essential tool for build systems and CI/CD pipelines that need to interact programmatically with Cargo's understanding of packages.


title: CAVEATS
content:
<b>cargo pkgid</b> is designed for machine-readable output. Its primary output is a single line string (the package ID, path, or Cargo home). It's not intended for human-readable debugging of package dependencies. For more detailed package information, consider <I>cargo metadata</I> or <I>cargo tree</I>. The command requires a valid Cargo project context to function correctly, unless <I>--query-cargo-home</I> is used.


title: PACKAGE ID FORMAT
content:
A package ID is a URL-like string that uniquely identifies a package. The format can vary depending on the package's origin (local path, registry, Git repository). Examples:<br><I>file:///path/to/project?version=1.2.3</I><br><I>registry+https://github.com/rust-lang/crates.io-index#my-crate@1.0.0</I><br><I>git+https://github.com/rust-lang/cargo?tag=cargo-0.60.0#abcdef12345</I>


title: SCRIPTING USAGE
content:
This command is particularly useful in shell scripts or CI/CD pipelines to dynamically get a package's canonical identifier or relevant paths. For instance, to get the current package's ID:<br><br><I>CURRENT_PKG_ID=$(cargo pkgid)</I><br><br>Or to find the workspace root:<br><br><I>WORKSPACE_ROOT=$(cargo pkgid --workspace-root)</I><br><br>These outputs can then be used by other commands or scripts that require a specific package reference or project path.


title: HISTORY
content:
<b>cargo pkgid</b> has been a part of the Cargo toolkit since early versions of the Rust programming language and its package manager. It provides a stable and consistent way to query package identities, serving as a fundamental building block for more complex build scripts and automation tasks within the Rust ecosystem. Its design emphasizes simplicity and machine-readability for programmatic interaction.


title: PARAMETERS
content:
<b><b>--token</b> <I>TOKEN</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an API token to use for authentication to the registry. This overrides any saved token from <I>cargo login</I>.<br><br><b><b>--no-verify</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips verification of the crate's contents and integrity after packaging. This includes skipping the execution of tests before publishing. Use with caution.<br><br><b><b>--allow-dirty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows publishing the crate even if the Git working directory contains uncommitted changes. By default, Cargo prevents publishing from a dirty directory.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs all pre-flight checks, packaging, and validation steps without actually uploading the crate to the registry. Highly recommended for testing the publishing process.<br><br><b><b>--registry</b> <I>REGISTRY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the registry to publish to, overriding the default <I>crates.io</I>. The registry must be pre-configured in your <I>.cargo/config.toml</I>.<br><br><b><b>-p</b>, <b>--package</b> <I>SPEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the package to publish. This option is useful in a workspace with multiple packages; otherwise, it defaults to the current package.<br><br><b><b>--manifest-path</b> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <I>Cargo.toml</I> file for the package being published.<br><br>


title: DESCRIPTION
content:
<I>cargo publish</I> is the essential command used to upload a Rust package, also known as a crate, to a public or private package registry. By default, it targets <I>crates.io</I>, the official package registry for Rust. This action makes your crate available for other developers to discover and use as a dependency in their own Rust projects, fostering collaboration and code reuse within the Rust ecosystem.<br><br>Before the actual publication, <I>cargo publish</I> performs several critical pre-flight checks: it validates the package's metadata in <I>Cargo.toml</I>, ensures there are no uncommitted changes in your working directory (unless explicitly overridden), builds and tests the crate to verify its integrity, and then creates a source tarball (a <I>.crate</I> file). This tarball is then uploaded to the specified registry. Successful publication requires prior authentication, typically managed via the <I>cargo login</I> command or by providing a token directly.


title: CAVEATS
content:
<b>Authentication Prerequisite:</b> Requires prior authentication with the target registry using <I>cargo login</I> or by providing a token via the <I>--token</I> option.<br><br><b>Clean Working Directory:</b> By default, the Git working directory must be clean (i.e., no uncommitted changes) to publish. Use <I>--allow-dirty</I> to bypass this check.<br><br><b>Crate Uniqueness & Immutability:</b> The chosen crate name must be unique on the target registry. Once a specific version of a crate is published, it is immutable and cannot be modified or re-uploaded.<br><br><b>Metadata Requirements:</b> Essential metadata fields in <I>Cargo.toml</I> such as <I>description</I>, <I>license</I> (or <I>license-file</I>), <I>readme</I>, <I>repository</I>, and <I>homepage</I> are highly recommended or, in some cases, required by registries like <I>crates.io</I>.<br><br><b>Dependency Availability:</b> All transitive dependencies of your crate must also be published and available on the registry before your crate can be successfully published.


title: AUTHENTICATION PROCESS
content:
Before you can publish a crate to <I>crates.io</I> (the default registry), you must authenticate your machine. This is typically achieved by running the command <I>cargo login &lt;YOUR_API_TOKEN&gt;</I>, which securely stores your API token locally. This token grants Cargo the necessary permissions to upload packages on your behalf. Alternatively, the token can be provided directly via the <I>--token</I> argument for a single publication.


title: PUBLISHING WORKFLOW AND CHECKS
content:
The publishing process is designed to ensure crate quality and integrity. Cargo first attempts to build the crate to verify it compiles. It then runs the crate's tests (unless <I>--no-verify</I> is specified). It also performs various sanity checks on your <I>Cargo.toml</I> metadata and ensures your working directory is clean (unless <I>--allow-dirty</I> is used). Finally, it packages your crate's source code into a gzipped tarball (<I>.crate</I> file) and uploads it to the registry. It's highly recommended to use <I>--dry-run</I> to test this entire workflow without actually uploading.


title: HISTORY
content:
<I>cargo publish</I> is a core command within Cargo, the official Rust package manager. Cargo was developed alongside the Rust language to provide a robust and integrated build system and dependency manager. The ability to publish crates to <I>crates.io</I> has been fundamental since the early days of the Rust ecosystem, enabling the widespread sharing and reuse of libraries. The command's functionality has consistently evolved with Cargo, adding features like <I>--dry-run</I> for safe testing and enhanced validation checks to ensure the quality and integrity of published crates, reflecting the community's commitment to a stable and reliable package registry.


title: PARAMETERS
content:
<b><CRATE>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Required.</I> One or more names of crates to remove from dependencies.<br><br><b>--dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove from <I>[dev-dependencies]</I> section instead of the default <I>[dependencies]</I>.<br><br><b>--build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove from <I>[build-dependencies]</I> section instead of the default <I>[dependencies]</I>.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove from target-specific dependencies (e.g., <I>--target x86_64-unknown-linux-gnu</I>).<br><br><b>-p, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Package to remove the dependency from. This is useful in a workspace to specify which member package should be modified.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the dependency from the workspace root's <I>Cargo.toml</I>, if applicable.<br><br><b>--manifest-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <I>Cargo.toml</I> file. By default, Cargo searches for <I>Cargo.toml</I> in the current directory or its parent directories.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a 'dry run' of the command. Don't actually write any changes to disk, but print what would happen.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print cargo log messages.<br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: <I>auto</I>, <I>always</I>, <I>never</I>.<br><br><b>--frozen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> and cache are up to date.<br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> is up to date.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run without accessing the network.<br><br>


title: DESCRIPTION
content:
<b>cargo remove</b> is a subcommand of the Rust package manager, <b>Cargo</b>, used to remove dependencies from a Rust project's <I>Cargo.toml</I> manifest file.<br>When executed, it automatically updates the <I>[dependencies]</I> section (or <I>[dev-dependencies]</I>, <I>[build-dependencies]</I>, or target-specific sections if specified) by deleting the entry for the specified crate(s).<br>It also updates the <I>Cargo.lock</I> file to reflect the change, ensuring consistency. This command streamlines dependency management, making it easy to unregister unneeded libraries from your project.<br>It operates on the active package by default or can be directed to a specific package or workspace using options.


title: CAVEATS
content:
Modifies your project's <I>Cargo.toml</I> and <I>Cargo.lock</I> files directly. Always consider version control before making significant changes.<br>This command only removes the dependency entry from the manifest. It does not delete cached crate data from your local Cargo registry or the <I>target</I> directory. Use <I>cargo clean</I> to remove compiled artifacts.<br>If the removed dependency is still referenced in your code, your project will fail to compile. Ensure all usages are also removed.<br>Removing a dependency might implicitly remove other dependencies that only that crate pulled in, potentially affecting the build graph.


title: MULTIPLE CRATES
content:
You can specify multiple crate names to remove them in a single command, e.g., <I>cargo remove serde reqwest</I>.


title: VERSION SPECIFICITY
content:
<b>cargo remove</b> operates on the crate name only. It does not require or allow specifying a version number, as it removes the entire dependency entry for that crate from the manifest.


title: HISTORY
content:
The functionality of <b>cargo remove</b> was originally provided by an external <I>cargo</I> subcommand, <I>cargo-edit</I> (specifically its <I>cargo rm</I> subcommand). This external tool was widely adopted due to its convenience.<br>Recognizing the utility and common need for direct dependency management, the <I>remove</I> subcommand was officially integrated into the core <I>Cargo</I> toolchain itself, starting with <I>Rust 1.62.0</I> (released <I>June 30, 2022</I>). This integration significantly improved its accessibility and solidified its status as a core Cargo feature.


title: SYNOPSIS
content:
<B>cargo report</B> &lt;SUBCOMMAND&gt; [<I>OPTIONS</I>]<br><br>Current primary subcommands include:<br><br><B>cargo report future-incompatibilities</B> [<I>OPTIONS</I>]<br><B>cargo report security</B> [<I>OPTIONS</I>]


title: PARAMETERS
content:
<b>--package <SPEC> or -p <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report for specific package(s) only within the workspace.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report on all packages in the current workspace.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report for the specified target triple (e.g., x86_64-unknown-linux-gnu).<br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't update `Cargo.lock` if it's out of date, but use existing lockfile.<br><br><b>--frozen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't update `Cargo.lock` and fail if it's out of date or missing.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in offline mode, without accessing the network.<br><br><b>--verbose or -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details.<br><br><b>--quiet or -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress non-error output, showing only critical information.<br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control output coloring. <I>WHEN</I> can be `auto`, `always`, or `never`.<br><br><b>--format <FORMAT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Subcommand specific) Output format for the report (e.g., `human`, `json`, `markdown`).<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Subcommand specific) Output the report in JSON format (shorthand for `--format json`).<br><br><b>--output <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Subcommand specific) Write the report to a file at the specified path instead of stdout.<br><br><b>--ignore-source-metadata</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <I>future-incompatibilities</I>) Ignore source metadata when checking incompatibilities.<br><br><b>--advisory-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <I>security</I>) Path to a local security advisory database (e.g., from `rustsec-advisory-db`).<br><br><b>--deny-file <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <I>security</I>) Path to a TOML file containing a list of advisories to ignore.<br><br><b>--deny-format <FORMAT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <I>security</I>) Format of the deny file. Currently only `toml` is supported.<br><br><b>--show-license</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <I>security</I>) Show license information for identified vulnerabilities (if available).<br><br>


title: DESCRIPTION
content:
cargo report is a versatile <I>Cargo subcommand</I> designed to generate various types of reports concerning your Rust projects and their dependencies. It acts as a central hub for reporting functionalities that might otherwise be scattered across different tools or <I>cargo</I> subcommands. Its primary use cases currently revolve around two main areas: identifying <I>future incompatibility lints</I> and scanning for <I>security advisories</I> against known vulnerabilities. This command empowers developers to maintain the health, compatibility, and security of their Rust applications by providing structured, often machine-readable, output. It's particularly useful in <I>CI/CD pipelines</I> for automated checks, helping developers proactively address potential issues before they become critical. By consolidating reporting features, `cargo report` streamlines the process of code quality and security auditing within the Rust ecosystem.


title: CAVEATS
content:
cargo report commands often require specific conditions:<br><br><ul><li>The <I>Rust toolchain</I> must be installed and accessible on your system.</li><li><B>cargo report future-incompatibilities</B> typically requires a <I>nightly Rust toolchain</I> to effectively detect future lints, as these are experimental compiler features.</li><li><B>cargo report security</B> relies on the <I>RustSec advisory database</I>. For accurate and up-to-date results, this database needs to be synchronized, which Cargo usually handles automatically when connected to the internet.</li><li>These commands operate within the context of a <I>Cargo project</I> with a `Cargo.toml` file.</li></ul>


title: FUTURE INCOMPATIBILITIES REPORT
content:
The <B>future-incompatibilities</B> subcommand identifies compiler lints that will become hard errors or warnings in future Rust versions. This is crucial for proactive maintenance and ensuring forward compatibility of Rust codebases. It helps developers address code patterns that might break with future compiler upgrades, often requiring a <I>nightly Rust toolchain</I> to run these experimental checks effectively. The report can be generated in human-readable or JSON formats, making it suitable for both developer inspection and automated parsing.


title: SECURITY REPORT
content:
The <B>security</B> subcommand scans your project's dependencies against the <I>RustSec advisory database</I> for known vulnerabilities. It reports any found advisories, providing details like advisory IDs, affected versions, and severity. This command is vital for maintaining a secure supply chain for your Rust applications and is often integrated into automated security checks in CI/CD pipelines. It supports various output formats, including human-readable, JSON, and Markdown, facilitating integration into diverse reporting systems. Users can also specify local advisory databases or provide deny files to ignore specific advisories.


title: HISTORY
content:
The `cargo report` subcommand was introduced to provide a standardized and official way to generate various reports within the Cargo ecosystem, consolidating functionalities that might otherwise be external or less organized. The <B>cargo report future-incompatibilities</B> subcommand was one of the first additions, designed to help users prepare for upcoming breaking changes in the Rust language and compiler. More recently, the <B>cargo report security</B> subcommand was added, aiming to integrate robust security vulnerability scanning directly into Cargo, potentially reducing reliance on external tools like `cargo-audit` for core advisory checks. Its development reflects a broader effort to enhance the built-in tooling for code quality and security within the Rust project, making these crucial checks more accessible and integrated.


title: PARAMETERS
content:
<b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build for the specified target triple (e.g., x86_64-unknown-linux-gnu). This affects the architecture and operating system for which the code is compiled.<br><br><b>--profile <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build with the given build profile (e.g., <I>dev</I>, <I>release</I>, or a custom profile defined in <I>Cargo.toml</I>). This overrides the default profile for the current invocation.<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build with the <I>release</I> profile (optimized build). This is a convenient shortcut for <I>--profile release</I>.<br><br><b>-Z <FLAG></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unstable (nightly-only) Cargo flags, used for experimental Cargo features or diagnostics. For example, <I>-Z build-std</I>.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated list of features to activate. For example, <I>--features "serde_derive json"</I>.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of the selected package.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the <I>default</I> feature.<br><br><b>--package <SPEC>, -p <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build only the specified package. This option may be specified multiple times. <I>SPEC</I> can be a package name or a path.<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the package's library.<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the specified binary. This option may be specified multiple times. If no <I>NAME</I> is given, all binaries are built.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the specified example. This option may be specified multiple times. If no <I>NAME</I> is given, all examples are built.<br><br><b>--test <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the specified test. This option may be specified multiple times. If no <I>NAME</I> is given, all tests are built.<br><br><b>--bench <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the specified benchmark. This option may be specified multiple times. If no <I>NAME</I> is given, all benchmarks are built.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output. May be specified twice for even more output (<I>-vv</I>).<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print Cargo log messages, only output from <I>rustc</I> itself or errors.<br><br><b>--color <WHEN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in output. Possible values: <I>auto</I> (default), <I>always</I>, <I>never</I>.<br><br><b>--manifest-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <I>Cargo.toml</I> file. By default, <I>Cargo</I> searches for <I>Cargo.toml</I> in the current directory or parent directories.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build all members in the current workspace. This option is only valid if the current directory is within a workspace.<br><br><b>--frozen, --locked, --offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls network access for fetching dependencies. <I>--frozen</I> ensures no new lockfile updates, <I>--locked</I> ensures no new lockfile updates and uses existing, <I>--offline</I> works without network.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A mandatory separator indicating that all subsequent arguments are to be passed directly to the <I>rustc</I> compiler. Any arguments following this separator will not be interpreted by <I>Cargo</I>.<br><br><b><I>RUSTC_OPTIONS</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more options/flags that will be passed directly to the <I>rustc</I> compiler. Examples include <I>-C opt-level=z</I>, <I>-C link-arg="-lc++"</I>, <I>--emit=asm</I>, <I>-Z unstable-options</I>, etc. Refer to <I>rustc --help</I> for a full list.<br><br>


title: DESCRIPTION
content:
<i>cargo rustc</i> is a <I>Cargo</I> subcommand that compiles a package and allows passing arbitrary command-line arguments directly to the underlying <I>rustc</I> compiler. This command acts as a wrapper around the compilation process, primarily extending the functionality of <I>cargo build</I> or <I>cargo check</I> by exposing the full power of <I>rustc</I>. It is particularly useful for advanced scenarios where fine-grained control over the compilation is required, such as enabling unstable compiler features, setting specific optimization levels, or adding linker arguments that <I>Cargo</I> does not expose directly. When invoked, <I>cargo rustc</I> first resolves dependencies and prepares the build environment, then executes <I>rustc</I> with the specified target and the user-provided flags. The command respects <I>Cargo</I>'s build configuration, including <I>Cargo.toml</I> profiles and environment variables.


title: CAVEATS
content:
1. <b>Mandatory Separator</b>: The <I>--</I> separator is crucial. All arguments intended for <I>rustc</I> must come after it; arguments before it are consumed by <I>Cargo</I>.<br>2. <b>Toolchain Dependency</b>: Some <I>rustc</I> flags (especially those starting with <I>-Z</I>) are unstable and only available on the <I>nightly</I> Rust toolchain. Using them on stable will result in an error.<br>3. <b>Conflict Risk</b>: Passing certain <I>rustc</I> flags might conflict with <I>Cargo</I>'s default build process or cause unexpected behavior. Exercise caution and understand the implications of the flags you pass.<br>4. <b>Limited Scope</b>: <I>cargo rustc</I> focuses solely on the compilation step. It doesn't affect other <I>Cargo</I> commands like <I>cargo test</I> or <I>cargo run</I> directly, though their compilation steps might be influenced if they implicitly call <I>rustc</I> with the same configuration.


title: COMMON USE CASES
content:
<b>1. Enabling Unstable Features:</b> Used to enable experimental <I>rustc</I> features that are not yet stable. For example, <I>cargo rustc -- -Z build-std</I> to build the standard library from source.<br><b>2. Passing Linker Flags:</b> Essential for linking against specific libraries or frameworks, especially in C/C++ interop or when building for embedded systems. Example: <I>cargo rustc -- -C link-arg="-framework CoreFoundation"</I> (on macOS).<br><b>3. Custom Optimization Levels:</b> Overriding profile-defined optimization for specific needs, like smallest size (<I>opt-level=z</I>) or maximum performance (<I>opt-level=3</I>). Example: <I>cargo rustc --release -- -C opt-level=z</I>.<br><b>4. Emitting Compiler Artifacts:</b> Generating intermediate files such as assembly code, LLVM IR, or MIR for debugging or analysis. Example: <I>cargo rustc -- --emit=asm</I>.


title: INTERACTION WITH BUILD PROFILES
content:
<I>cargo rustc</I> honors the build profiles defined in <I>Cargo.toml</I> (e.g., <I>dev</I>, <I>release</I>). You can specify a profile using <I>--profile &lt;NAME&gt;</I> or <I>--release</I>. Any <I>rustc</I> options passed via <I>--</I> will then be applied <I>in addition to</I> or potentially <I>overriding</I> the options set by that profile. This allows for fine-tuning specific builds without altering your <I>Cargo.toml</I> for every experimental compile.


title: HISTORY
content:
<I>cargo rustc</I> has been a fundamental subcommand within the <I>Cargo</I> toolchain since its early days, reflecting the Rust ecosystem's commitment to both high-level package management and low-level compiler control. Its evolution is intertwined with the development of <I>rustc</I> itself, as new compiler features and flags often become accessible via <I>cargo rustc</I> before or alongside more direct <I>Cargo.toml</I> configurations. It serves as a vital escape hatch for power users, enabling experimentation with cutting-edge compiler optimizations, custom linking, or addressing specific platform requirements not natively handled by default <I>Cargo</I> settings. While many common needs are now met by <I>Cargo</I> itself or build scripts, <I>cargo rustc</I> remains indispensable for niche or advanced scenarios, ensuring that developers are never entirely restricted from direct compiler interaction.


title: PARAMETERS
content:
<b><I>CARGO_OPTIONS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;These options control how <i>cargo</i> builds the project before running <i>rustdoc</i>. Common options include specifying targets, features, and build profiles.<br><br><b>--package <SPEC>, -p <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document only the specified package(s) in the workspace.<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document the package's library.<br><br><b> --bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document the specified binary target. Can be used multiple times.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document the specified example target. Can be used multiple times.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document for the given target triple (e.g., <code>x86_64-unknown-linux-gnu</code>).<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document with the release profile (optimized with <code>--opt-level=3</code>).<br><br><b>--profile <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Document with the specified build profile.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space or comma separated list of features to activate.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the <code>default</code> feature.<br><br><b>--open</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the generated documentation in a web browser after compilation.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A separator indicating that all subsequent arguments are passed directly to the <i>rustdoc</i> executable.<br><br><b><I>RUSTDOC_OPTIONS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;These options are passed directly to the <i>rustdoc</i> command. They control <i>rustdoc</i>'s behavior, such as output format, lints, or testing documentation examples.<br><br><b>-o <DIR>, --output <DIR></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the generated documentation to the specified directory instead of the default <code>target/doc</code>.<br><br><b>--test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run code examples embedded within documentation comments as tests. This is a crucial feature for ensuring code examples remain correct.<br><br><b>--test-args <ARGS></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass extra arguments to the test runner when <code>--test</code> is used.<br><br><b>--cfg <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure the crate with arbitrary <code>cfg</code> flags, affecting conditional compilation for documentation.<br><br><b>--deny <LINT>, --forbid <LINT>, --warn <LINT>, --allow <LINT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control how <i>rustdoc</i> handles specific lint warnings or errors during documentation generation.<br><br>


title: DESCRIPTION
content:
The <b>cargo rustdoc</b> command is a subcommand of <i>cargo</i>, Rust's package manager and build system. It is used to generate HTML documentation for a Rust project's API (Application Programming Interface). It leverages the <i>rustdoc</i> tool internally, which processes special documentation comments within Rust source code (often written in Markdown syntax) to produce a navigable set of web pages.<br><br>This command is essential for creating comprehensive and easily accessible documentation for Rust libraries and applications. It automatically compiles the project, then runs <i>rustdoc</i> on the compiled artifacts. The generated documentation is typically placed in the <code>target/doc/</code> directory of the project, making it simple to publish or share the API documentation.


title: CAVEATS
content:
The <b>cargo rustdoc</b> command is not a standalone executable; it must be invoked via <i>cargo</i>. All arguments intended for <i>rustdoc</i> itself (e.g., <code>--test</code>, <code>-o</code>) must be placed after the <code>--</code> separator. Forgetting the separator will cause <i>cargo</i> to interpret them as its own options, leading to errors. The command requires a valid Rust project with a <code>Cargo.toml</code> file.


title: DOCUMENTATION OUTPUT LOCATION
content:
By default, the generated HTML documentation is placed in the <code>target/doc/</code> directory within your project. You can open the <code>index.html</code> file in this directory to view the documentation locally.


title: DOC COMMENTS
content:
Documentation is generated from special comments in Rust code, typically starting with <code>///</code> for items or <code>//!</code> for module-level documentation. These comments support Markdown for rich text formatting and code examples.


title: OPENING DOCUMENTATION
content:
The <code>--open</code> flag is very convenient as it automatically launches your default web browser to display the generated documentation after the command completes successfully.


title: HISTORY
content:
Rust has a strong emphasis on documentation, and <i>rustdoc</i> has been a core part of the Rust toolchain since its early days. <b>cargo rustdoc</b> was introduced to seamlessly integrate the documentation generation process with Rust's build system, making it as easy to generate docs as it is to compile code. This integration simplified workflows and promoted the widespread adoption of comprehensive API documentation within the Rust ecosystem.


title: PARAMETERS
content:
<b><i>&lt;QUERY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The search term(s) or keywords to look for in crate names and descriptions on <i>crates.io</i>.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print <i>cargo</i> log messages, resulting in less verbose output.<br><br><b><b>--registry</b> <i>&lt;REGISTRY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the registry to use (defaults to 'crates-io'). Useful for custom registries.<br><br><b><b>--index</b> <i>&lt;INDEX&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;URL of the registry index to use, overriding the default <i>crates.io</i> index.<br><br><b><b>--limit</b> <i>&lt;LIMIT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of results returned (defaults to a reasonable number, e.g., 10 or 20).<br><br><b><b>--color</b> <i>&lt;WHEN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control when colors are used in the output: <i>auto</i> (default), <i>always</i>, or <i>never</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information for the <i>cargo search</i> command and exits.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details about operations.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information for <i>cargo</i> and exits.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run without accessing the network. For <i>cargo search</i>, this will cause the command to fail as it requires network access to query the registry.<br><br>


title: DESCRIPTION
content:
<i>cargo search</i> is a powerful subcommand of the Rust package manager, <i>cargo</i>, designed to help developers discover and find Rust packages (known as <i>crates</i>) on the official Rust community's registry, <i>crates.io</i>. This command serves as the primary interface for exploring the vast ecosystem of open-source Rust libraries and executables.<br><br>When executed with a search <i>&lt;QUERY&gt;</i>, it efficiently queries the remote registry, filtering through thousands of available crates. It then returns a concise list of matching crates, typically displaying their names, a brief description of their functionality, and the latest published version. This facilitates the rapid identification of suitable dependencies for new or existing Rust projects, enabling developers to leverage the collective work of the Rust community and accelerate their development process. It's an indispensable tool for anyone building with Rust.


title: CAVEATS
content:
<i>cargo search</i> primarily relies on an active internet connection to query the remote <i>crates.io</i> registry. Running the command with <b>--offline</b> or without network access will result in an error or no results.<br>The search functionality typically matches against crate names and the short descriptions provided by crate authors, not against the full content of the crates or their documentation. Therefore, broad or highly specific queries might require refinement.<br>By default, <i>cargo search</i> limits the number of results displayed. To view more matches, the <b>--limit</b> option must be used with a higher value.


title: CRATES.IO INTEGRATION
content:
<i>cargo search</i> directly queries <i>crates.io</i>, which is the official and primary package registry for Rust. All public crates submitted by the community are indexed and made searchable through this platform, ensuring access to the vast majority of Rust's open-source ecosystem.


title: SEARCH SCOPE AND RELEVANCE
content:
The search algorithm prioritizes matches in crate names and then considers keywords within the crate's description. It does not perform full-text searches of a crate's README, source code, or documentation. Users should be aware that the relevance of results is based on this limited metadata, and broader terms might yield more comprehensive results.


title: HISTORY
content:
The <i>cargo search</i> subcommand has been a foundational element of the <i>cargo</i> toolchain since the early development phases of the Rust programming language. Its rapid integration was crucial for fostering a collaborative ecosystem, enabling developers to easily discover, evaluate, and integrate community-contributed code. While its core functionality of querying <i>crates.io</i> has remained consistent, minor enhancements have been implemented over time to improve search performance, refine output formatting, and introduce options like limiting results or specifying alternative registries.


title: PARAMETERS
content:
<b>--no-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile tests without running them.<br><br><b>--no-fail-fast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run all tests even if some fail, instead of stopping after the first failure.<br><br><b>--test <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run only the specified integration test binary (e.g., <I>--test my_integration_test</I>).<br><br><b>--lib</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the current package's library target.<br><br><b>--bin <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test a specific binary target.<br><br><b>--example <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test a specific example.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate specified comma-separated features (e.g., <I>--features "foo,bar"</I>).<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of the package.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test all packages in the current workspace.<br><br><b>-p <SPEC> / --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test a specific package in the workspace.<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build tests in release mode with optimizations.<br><br><b>-j <N> / --jobs <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of parallel jobs to run for compilation.<br><br><b>-v / --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing extra information.<br><br><b>-- --nocapture</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't capture stdout/stderr of test processes; print directly to console. Useful for debugging.<br><br><b>-- --test-threads <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of threads to use for running tests concurrently. Defaults to the number of CPU cores.<br><br><b>-- --ignored</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run only tests marked with <I>#[ignore]</I>.<br><br><b>-- --show-output</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show stdout/stderr for successful tests as well (not just failures).<br><br><b>-- --skip <TESTNAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip tests matching the provided <I>TESTNAME</I>.<br><br>


title: DESCRIPTION
content:
The <b>cargo test</b> command compiles and executes all tests found in the current <i>Rust</i> package or workspace. It's an integral part of the <i>Rust</i> development workflow, ensuring code correctness and stability.<br>By default, <b>cargo test</b> discovers and runs three types of tests: unit tests (functions annotated with <I>#[test]</I> within modules), integration tests (files placed in the <I>tests/</I> directory, treated as separate crates), and documentation tests (code examples embedded in documentation comments).<br>The command first builds the test binaries and then runs them, reporting the outcome for each test, including passed, failed, and ignored counts. This streamlined approach makes testing an efficient and accessible part of <i>Rust</i> development.


title: CAVEATS
content:
Tests must be written in <i>Rust</i> and annotated with <I>#[test]</I> or placed in the appropriate directory (<I>tests/</I> for integration tests).<br>Arguments specified after <I>--</I> are passed directly to the test binary, not interpreted by <b>cargo</b> itself. This distinction is crucial for options like <I>--nocapture</I> or <I>--test-threads</I>.<br>Large test suites can be slow; consider using <I>--jobs</I> for faster compilation or targeting specific tests during development.


title: TEST FILTERING
content:
You can run specific tests by providing part of their name as an argument directly after <I>cargo test</I> (e.g., <I>cargo test my_specific_test</I>). This will filter both unit and integration tests whose names contain the given string. Regular expressions can also be used for more advanced filtering.


title: ENVIRONMENT VARIABLES
content:
<I>RUST_BACKTRACE=1</I>: Displays a backtrace on panic in tests, aiding in debugging.<br><I>RUST_TEST_THREADS=<N></I>: Overrides the default number of test threads globally, equivalent to passing <I>-- --test-threads <N></I>.


title: DOCTESTS
content:
<b>cargo test</b> automatically discovers and runs code examples embedded within documentation comments (marked with <I>```rust</I>). This ensures that your documentation remains accurate and up-to-date with your code's behavior, promoting high-quality documentation practices.


title: HISTORY
content:
<b>cargo test</b> has been a core component of the <i>Rust</i> ecosystem since the early days of <i>Cargo</i> and before the <i>Rust 1.0</i> release. Its integration with the built-in test framework (<I>libtest</I>) has made testing a seamless and fundamental part of <i>Rust</i> development. Over time, features like doctests and improved filtering capabilities have been added, enhancing its versatility and developer experience.


title: PARAMETERS
content:
<b>-p <SPEC>, --package <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the dependency tree for a specific package within the workspace. This is useful in multi-package workspaces.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display dependencies for a specific compilation target (e.g., <I>x86_64-unknown-linux-gnu</I>). This limits the dependencies shown to only those relevant for that target.<br><br><b>--depth <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the display of the dependency tree to the specified maximum depth. Helps in focusing on immediate dependencies.<br><br><b>--invert</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the tree, showing reverse dependencies. This means it shows which packages depend on a given package, rather than what a package depends on.<br><br><b>--no-dedupe</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not deduplicate repeated dependencies in the tree. By default, duplicate entries are marked with <I>(*)</I> and not fully repeated.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activate all available features of all packages involved in the dependency graph.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not activate the default features of the selected packages.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of features to activate for the selected packages.<br><br><b>--build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include build dependencies (from the <I>[build-dependencies]</I> section) in the tree.<br><br><b>--dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include development dependencies (from the <I>[dev-dependencies]</I> section) in the tree.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the dependency tree for all packages in the current workspace.<br><br><b>--filter <SPEC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter out specified packages from the tree display. Can be used to reduce clutter.<br><br><b>--format <FORMAT></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the dependency tree in a specific format, such as <I>json</I>, <I>dot</I>, or <I>graphviz</I>.<br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> to be up to date and not regenerate it.<br><br><b>--frozen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require <I>Cargo.lock</I> and <I>Cargo.toml</I> to be up to date and not regenerate or update them.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate without network access. Requires all dependencies to be cached locally.<br><br><b>--manifest-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <I>Cargo.toml</I> file. Useful when not running from the project root.<br><br>


title: DESCRIPTION
content:
<i>cargo tree</i> is a powerful subcommand of <i>cargo</i>, the Rust package manager, designed to display the dependency graph of a Rust project. It recursively lists all direct and transitive dependencies required by a package, providing a clear hierarchical view of its entire dependency ecosystem. This tool is invaluable for understanding the composition of a project, identifying potential dependency conflicts (e.g., multiple versions of the same crate), debugging build issues, and optimizing project structure. It can filter dependencies by type (build, dev, target), show which features are enabled, and even invert the tree to show reverse dependencies. Its ability to represent the complex relationships between crates makes it an essential utility for Rust developers.


title: CAVEATS
content:
The output for large projects can be extremely verbose, making it difficult to parse without filtering or limiting depth.<br><i>cargo tree</i> relies on the project's <I>Cargo.lock</I> file or performs dependency resolution; an outdated <I>Cargo.lock</I> might not reflect the most current dependency graph.<br>Different versions of the same crate might appear in the tree, especially if explicit version ranges or feature flags lead to divergent dependency paths. Duplicates are marked with <I>(*)</I> by default.


title: UNDERSTANDING OUTPUT SYMBOLS
content:
<i>cargo tree</i> uses special symbols to convey additional information about dependencies:<br><ul><li><I>(*)</I>: Indicates a duplicate dependency that was resolved to an earlier version in the tree and thus not fully re-listed.</li><li><I>(proc-macro)</I>: Marks a procedural macro crate, which is compiled for the host system and executed during compilation.</li><li><I>(build)</I>: Denotes a build dependency, specified in the <I>[build-dependencies]</I> section of <I>Cargo.toml</I>.</li><li><I>(dev)</I>: Signifies a development dependency, found in the <I>[dev-dependencies]</I> section, typically used for tests or examples.</li><li><I>(target &lt;TRIPLE&gt;)</I>: Indicates a target-specific dependency, only included when building for a particular target triple.</li></ul>


title: FEATURE ACTIVATION AND CONDITIONAL COMPILATION
content:
A significant strength of <i>cargo tree</i> is its ability to show which features are activated for each crate in the dependency graph. This is crucial for understanding how optional dependencies and conditional compilation affect the final build. The command can be configured with <I>--all-features</I>, <I>--no-default-features</I>, or <I>--features</I> to simulate different build configurations and observe their impact on the dependency tree.


title: HISTORY
content:
Initially, <i>cargo tree</i> existed as an external <I>cargo-tree</I> subcommand, distributed as a separate Cargo plugin or binary. Due to its widespread utility and frequent adoption by the Rust community for dependency analysis, it was officially integrated into the main <i>cargo</i> binary as a built-in subcommand. This integration occurred around the release of Rust 1.44 in July 2020, making it more accessible and simplifying its usage and discoverability for all Rust developers.


title: SYNOPSIS
content:
<b><i>cargo uninstall</i></b> [<i>OPTIONS</i>] <<i>NAME</i>>...<br><b><i>cargo uninstall</i></b> [<i>OPTIONS</i>] <i>--workspace</i>


title: PARAMETERS
content:
<b><<i>NAME</i>>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more names of the packages to uninstall. These are the crate names, not necessarily the binary names.<br><br><b><i>--root</i> <<i>DIR</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directory to uninstall from. Defaults to the Cargo home directory (typically <i>~/.cargo</i>), meaning binaries are removed from <i>~/.cargo/bin</i>.<br><br><b><i>--target</i> <<i>TRIPLE</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstall binaries for the specified target triple (e.g., <i>x86_64-unknown-linux-gnu</i>), useful for cross-compiled installations.<br><br><b><i>--list</i>, <i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed packages and their associated binaries that were installed via <i><b>cargo install</b></i>, without performing any uninstallation.<br><br><b><i>--workspace</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls all binaries that belong to the current workspace and were previously installed using <i><b>cargo install</b></i>.<br><br><b><i>--verbose</i>, <i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details about the uninstallation process.<br><br><b><i>--quiet</i>, <i>-q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all command output, showing only errors.<br><br><b><i>--color</i> <<i>WHEN</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls when colors are used in output. Possible values are <i>auto</i> (default), <i>always</i>, or <i>never</i>.<br><br><b><i>--frozen</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requires <i>Cargo.lock</i> to be up to date. If not, Cargo will exit with an error without attempting to update it.<br><br><b><i>--locked</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requires <i>Cargo.lock</i> to be up to date and fails if it is not. Equivalent to <i>--frozen</i>.<br><br><b><i>--offline</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs without accessing the network. Fails if a network connection is required.<br><br><b><i>--help</i>, <i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information about the command and its options.<br><br>


title: DESCRIPTION
content:
The <i><b>cargo uninstall</b></i> command is a subcommand of the Rust package manager, Cargo. It is used to remove local Rust binaries that were previously installed using the <i><b>cargo install</b></i> command.<br><br>When executed, <i><b>cargo uninstall</b></i> searches for the specified executable(s) within the Cargo home directory's <i>bin</i> subdirectory (typically <i>~/.cargo/bin</i> or a custom directory specified by the <i>CARGO_HOME</i> environment variable or the <i>--root</i> option). It can uninstall one or more specific packages by name, or uninstall all binaries associated with the current workspace using the <i>--workspace</i> option.<br><br>This command plays a vital role in maintaining a clean and efficient Rust development environment, allowing developers to remove unneeded or outdated Rust tools and applications that have been installed globally or within a specific project context.


title: CAVEATS
content:
<i><b>cargo uninstall</b></i> is designed exclusively for executables installed by <i><b>cargo install</b></i>. It will not remove binaries installed by other methods (e.g., system package managers or manual compilation). It also does not remove source code, build caches, or any other data not residing in the designated binary installation directory. Users must have appropriate file system permissions to modify the installation directory (e.g., <i>~/.cargo/bin</i>).


title: ENVIRONMENT VARIABLES
content:
The behavior of <i><b>cargo uninstall</b></i> can be influenced by standard Cargo environment variables, such as <i>CARGO_HOME</i>. This variable specifies the root directory where Cargo stores its binaries, registry, and other files. If <i>CARGO_HOME</i> is set, <i><b>cargo uninstall</b></i> will operate on that directory instead of the default <i>~/.cargo</i>.


title: LISTING CAPABILITIES
content:
The <i><b>--list</b></i> option is a powerful feature that allows users to quickly inspect which Rust executables have been installed via <i><b>cargo install</b></i>. This helps in identifying packages that might need to be uninstalled or updated, providing a clear overview of the installed Rust tools.


title: HISTORY
content:
The <i><b>cargo uninstall</b></i> command, alongside <i><b>cargo install</b></i>, has been a core component of the Rust ecosystem since the early days of Cargo's development. Cargo, the official Rust package manager, was created to streamline project management, dependency resolution, and building processes for Rust applications. These commands provide a consistent and integrated way for developers to manage global or project-specific Rust tools and executables, reflecting Rust's commitment to developer convenience and ecosystem stability.


title: SYNOPSIS
content:
<i><B>cargo install-update</B> [<I>OPTIONS</I>] [<I>CRATE</I>...]<br><B>cargo install-update</B> <B>--all</B> [<I>OPTIONS</I>]<br><B>cargo install-update</B> <B>--list</B></i>


title: PARAMETERS
content:
<b><I>CRATE</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies one or more names of <I>cargo</I> crates (tools) to update. If no crates are specified and <B>--all</B> is not used, it typically does nothing or lists usage.</i><br><br><b><B>-a</B>, <B>--all</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Updates all <I>cargo</I> crates that were previously installed using <B>cargo install</B>. This is the most common use case for bulk updates.</i><br><br><b><B>-l</B>, <B>--list</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists all <I>cargo</I> crates that are currently installed and can be managed by <B>cargo install-update</B>, along with their versions.</i><br><br><b><B>-f</B>, <B>--force</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Forces recompilation of crates even if they appear to be up to date, useful for resolving potential issues or rebuilding with different flags.</i><br><br><b><B>--dry-run</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Performs a dry run, showing what actions would be taken (e.g., which crates would be updated) without actually modifying anything on the system.</i><br><br><b><B>-v</B>, <B>--verbose</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses verbose output, providing more detailed information about the update process, including compilation steps.</i><br><br><b><B>--git</B> <I>GIT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Updates a crate from a specified Git repository URL instead of <I>crates.io</I>. Useful for development versions.</i><br><br><b><B>--path</B> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Updates a crate from a local filesystem path. This is useful when developing the tool itself.</i><br><br><b><B>--target</B> <I>TARGET</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compiles the crate for a specific target triple (e.g., <I>x86_64-unknown-linux-gnu</I>).</i><br><br><b><B>--features</B> <I>FEATURES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>A space-separated list of features to compile with. Overrides default features.</i><br><br><b><B>--no-default-features</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not compile with default features. Often used in conjunction with <B>--features</B>.</i><br><br><b><B>--all-features</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compile with all available features.</i><br><br><b><B>--profile</B> <I>PROFILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the Cargo build profile to use (e.g., <I>release</I> for optimized, production-ready binaries, or <I>dev</I> for faster debug builds).</i><br><br><b><B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Builds the crate with debug information. Equivalent to <B>--profile dev</B> but often explicitly stated for clarity.</i><br><br><b><B>--jobs</B> <I>JOBS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Number of parallel jobs to run during compilation. Useful for controlling resource usage on multi-core systems.</i><br><br><b><B>--locked</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Requires <I>Cargo.lock</I> to be up to date. If <I>Cargo.lock</I> is missing or outdated, an error is produced.</i><br><br><b><B>--offline</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compiles without network access, using only cached dependencies. This requires all necessary dependencies to be present locally.</i><br><br><b><B>--bin-path</B> <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies an alternative path where the updated binaries should be installed, overriding the default <I>$CARGO_HOME/bin</I>.</i><br><br><b><B>--root</B> <I>ROOT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Installs the updated crate into a specific root directory structure, similar to how <B>cargo install --root</B> works.</i><br><br><b><B>--allow-prerelease</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Allows updating to prerelease versions (e.g., <I>0.1.0-alpha.1</I>) of crates, which are typically ignored by default.</i><br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a help message with command usage and options, then exits.</i><br><br>


title: DESCRIPTION
content:
<i>The <B>cargo-update</B> command, typically invoked as <B>cargo install-update</B>, is a vital utility for Rust developers to manage and keep their global <B>cargo</B> subcommands up-to-date.<br><br>While <B>cargo update</B> (without the 'install-' prefix) is a built-in <B>cargo</B> command used for refreshing project dependencies defined in <B>Cargo.toml</B>, <B>cargo install-update</B> focuses specifically on binaries previously installed using <B>cargo install</B>.<br><br>It addresses a common need in the Rust ecosystem by providing a convenient way to re-download and re-compile the latest versions of your globally installed development tools (e.g., <I>cargo-audit</I>, <I>cargo-watch</I>, <I>cargo-expand</I>). This process involves querying <I>crates.io</I> (the Rust package registry) for newer versions and then recompiling the tool, ensuring you always have the most recent features and bug fixes.<br><br>It's an essential tool for maintaining a healthy and current Rust development environment.</i>


title: CAVEATS
content:
<i><B>cargo-update</B> is a third-party tool and not part of the core <B>cargo</B> distribution. It must be installed separately via <B>cargo install cargo-update</B> before it can be used.<br><br>Updates involve recompiling Rust code, which can consume significant CPU and time, especially for many tools or on less powerful systems. The compilation process requires the Rust toolchain (compiler, linker) to be properly set up.<br><br>It relies on the availability of network access to <I>crates.io</I> for fetching new versions and their dependencies, unless the <B>--offline</B> flag is used and all dependencies are cached.</i>


title: <I>INSTALLATION</I>
content:
<i>To use <B>cargo install-update</B>, you must first install it using <B>cargo</B> itself. This is typically a one-time setup:<br><B>cargo install cargo-update</B><br><br>After successful installation, the command is usually available as <B>cargo install-update</B>, or simply <B>cargo update</B> if your shell's path resolves it differently (though the former is recommended to avoid confusion).</i>


title: <I>DISTINCTION FROM CARGO UPDATE</I>
content:
<i>It is important to differentiate <B>cargo install-update</B> from the built-in <B>cargo update</B> command. While both deal with 'updating', <B>cargo update</B> (without 'install-') is used within a Rust project directory to update that project's dependencies as specified in its <I>Cargo.lock</I> file. <B>cargo install-update</B>, conversely, manages standalone binaries installed globally on your system via <B>cargo install</B>, independently of any specific project's dependencies.</i>


title: HISTORY
content:
<i>The need for a dedicated command to update globally installed <B>cargo</B> subcommands became apparent as the Rust ecosystem matured and more tools were distributed via <B>cargo install</B>. Prior to <B>cargo-update</B>'s widespread adoption, developers often had to manually <B>cargo uninstall</B> and then <B>cargo install</B> each tool to update them, a cumbersome process.<br><br><B>cargo-update</B> (originally <I>cargo-install-update</I>) was created by Alex Crichton, a prominent member of the Rust team, to streamline this process. It quickly became an essential tool for managing a growing collection of Rust command-line utilities, filling a crucial gap in the <B>cargo</B> toolchain. Its development and maintenance are now often handled by the <I>crate-ci</I> group, ensuring its continued relevance and functionality within the Rust development workflow.</i>


title: PARAMETERS
content:
<b>--output <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where dependencies should be vendored. If not provided, it defaults to <i>.cargo/vendor</i> in the workspace root.<br><br><b>--respect-source-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;By default, <i>cargo-vendor</i> adds <i>source</i> replacement entries to <i>.cargo/config.toml</i>. This option prevents that, requiring manual configuration of the vendored path.<br><br><b>--sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes the vendored directory with <i>Cargo.lock</i>, removing any unused dependencies and adding new ones.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use verbose output, showing more details about the vendoring process.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print <i>cargo</i> log messages, silencing most output.<br><br><b>--manifest-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <i>Cargo.toml</i> file for the package or workspace being vendored.<br><br><b>--target <TRIPLE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Vendor dependencies specifically for the given target triple (e.g., <i>x86_64-unknown-linux-gnu</i>).<br><br><b>--locked</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requires <i>Cargo.lock</i> to be up to date. If it's not, <i>cargo-vendor</i> will exit with an error.<br><br><b>--no-default-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not enable default features for the root package.<br><br><b>--all-features</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable all features for the root package.<br><br><b>--features <FEATURES></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of features to enable for the root package.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Vendor all dependencies for all packages in the current workspace.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print <i>cargo-vendor</i>'s version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information about the command.<br><br>


title: DESCRIPTION
content:
`cargo-vendor` is a subcommand of the Rust package manager, <i>cargo</i>, designed to copy all Git and Registry dependencies required by a Rust project into a local directory. This process, known as "vendoring," allows projects to be built without an active internet connection, making it invaluable for offline development, reproducible builds, and deployment in air-gapped environments. <br><br>When executed, `cargo-vendor` fetches all necessary crates and places them into a specified output directory (by default, <i>.cargo/vendor</i> relative to the workspace root). Crucially, it also updates the project's <i>.cargo/config.toml</i> file to redirect <i>cargo</i>'s source resolution to these locally vendored dependencies instead of the network. This ensures that subsequent build commands (e.g., `cargo build`, `cargo test`) will use the copied dependencies, guaranteeing consistency and eliminating external network reliance. It's a fundamental tool for managing project dependencies in controlled or restricted environments.


title: CAVEATS
content:
By default, `cargo-vendor` does not vendor <i>build-dependencies</i> or <i>dev-dependencies</i> unless they are also regular dependencies. <br>The vendored directory can become quite large, especially for projects with many dependencies, which can impact disk space and version control repository size if committed. <br>Managing vendored dependencies manually (e.g., outside of `cargo-vendor --sync`) can lead to inconsistencies between the <i>Cargo.lock</i> and the actual vendored crates.


title: CONFIGURATION FILE IMPACT
content:
When `cargo-vendor` runs, it modifies or creates a <i>.cargo/config.toml</i> file in the project's <i>.cargo</i> directory. This file contains <i>source</i> replacement entries that redirect <i>cargo</i> to use the locally vendored dependencies instead of fetching them from <i>crates.io</i> or Git repositories. These entries typically look like: <br> <i>[source.'crates-io'] <br> replace-with = "vendored-sources" <br> <br> [source.vendored-sources] <br> directory = "vendor"</i> <br> (where "vendor" is the path specified by <i>--output</i>).


title: TYPICAL WORKFLOW
content:
A common workflow involves running `cargo vendor` once to populate the local directory. The <i>.cargo/config.toml</i> and the vendored directory (e.g., <i>.cargo/vendor</i>) are then often committed to version control. This ensures that anyone cloning the repository can build the project immediately without requiring an internet connection, relying solely on the vendored dependencies.


title: HISTORY
content:
The `cargo-vendor` subcommand was introduced to address the growing need for offline compilation and reproducible builds within the Rust ecosystem. It was integrated into <i>cargo</i> to provide a standardized, convenient way to "snapshot" dependencies, moving beyond manual methods or ad-hoc scripts. Its development reflects the Rust community's focus on robust tooling and support for diverse development environments, including those with restricted network access or strict build requirements.


title: SYNOPSIS
content:
<b>cargo verify-project</b> [<i>OPTIONS</i>] [<i>PATH</i>]<br><br><I>PATH</I> defaults to the current working directory.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses cargo log messages and other output.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details.<br><br><b>--workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Considers the entire workspace as the project root, even if run from a subdirectory.<br><br><b>-Z <FLAG>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables unstable (nightly-only) flags for experimental features.<br><br><b>[PATH]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the project directory to verify. Defaults to the current directory.<br><br>


title: DESCRIPTION
content:
The <b>cargo-verify-project</b> command is a crucial utility within the Rust programming ecosystem, primarily designed to quickly validate the structural integrity and manifest (<I>Cargo.toml</I>) of a Rust project or workspace. <br><br>Unlike <I>cargo check</I> or <I>cargo build</I>, which perform full compilation or type-checking, <I>verify-project</I> focuses solely on whether the project's layout, manifest syntax, and configuration are valid and well-formed. It checks for common issues such as missing required fields in <I>Cargo.toml</I>, incorrect path specifications, or invalid manifest structure. <br><br>This command is particularly useful for integrated development environments (IDEs) and other tooling that need to understand the project's structure without incurring the overhead of a full build. It helps ensure that a project is set up correctly before attempting more complex operations, providing a rapid feedback loop for developers. <br><br>It can be run against a specific path or the current directory, and it can also consider the entire workspace.


title: CAVEATS
content:
<b>cargo-verify-project</b> performs only structural and manifest validation; <i>it does not compile code, check for compilation errors, or verify type correctness</i>. For deeper code analysis, commands like <I>cargo check</I> or <I>cargo build</I> are required. Its output is typically concise, focusing on structural validity.


title: HISTORY
content:
The <b>cargo-verify-project</b> command was introduced to address the growing need for tooling and IDEs to understand Rust project structures quickly and efficiently. It provides a lightweight mechanism to validate project manifests without the overhead of a full compilation, which is crucial for responsive development environments. Its development reflects Cargo's evolution towards becoming a more robust and tool-friendly package manager.


title: DESCRIPTION
content:
The <b>cargo-version</b> command, invoked as <I>cargo version</I>, is a crucial subcommand of the Rust package manager, <b>Cargo</b>. Its primary function is to display detailed version information about the <b>Cargo</b> tool itself, the underlying <b>rustc</b> (Rust compiler) it uses, and often includes details about the active <b>rustup</b> toolchain (e.g., stable, beta, nightly) and its build date. This command is invaluable for debugging and understanding the Rust development environment, especially when dealing with version-specific issues or ensuring consistent toolchain usage across projects. It provides a quick snapshot of the Rust ecosystem components in use, aiding in reproducibility and problem diagnosis. Unlike <I>cargo --version</I>, which provides a concise output, <I>cargo version</I> offers more comprehensive details about the toolchain and its build environment.


title: CAVEATS
content:
This command is a subcommand of <b>cargo</b>, not a standalone executable. It does not accept any specific command-line options that alter its behavior or output, beyond global <b>cargo</b> options (which rarely apply or have an effect on this particular subcommand). The output might vary slightly depending on whether <I>rustup</I> is installed and actively managing the Rust toolchain, as it often includes <I>rustup</I> toolchain information.


title: DISTINCTION FROM CARGO --VERSION
content:
While <I>cargo version</I> provides detailed toolchain information (e.g., build date, toolchain name, host triple), <I>cargo --version</I> offers a more concise output, typically showing only the <b>Cargo</b> version and the <b>rustc</b> version. Both commands serve to inform about the installed versions but cater to slightly different levels of detail and typical usage scenarios.


title: HISTORY
content:
<b>Cargo</b>, the Rust package manager, was developed alongside the Rust programming language to automate project dependency management and build processes. The <I>version</I> subcommand has been a fundamental diagnostic tool from early in Cargo's development. Its utility significantly increased with the introduction of <I>rustup</I>, the Rust toolchain installer, which allows users to easily switch between different Rust versions (stable, beta, nightly), making it crucial to quickly identify the currently active toolchain.


title: PARAMETERS
content:
<b><CRATE_NAME>@<VERSION_NUMBER></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the crate and its version to yank or un-yank. Multiple <i>CRATE_NAME</i>@<i>VERSION_NUMBER</i> pairs can be provided.<br><br><b><b>--crate</b> <<i>CRATE_NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alternative way to specify the crate name.<br><br><b><b>--version</b> <<i>VERSION_NUMBER</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alternative way to specify the crate version. Must be used with <b>--crate</b>.<br><br><b><b>--yank</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly marks the specified crate version(s) as yanked. This is the default action if neither <b>--yank</b> nor <b>--undo</b> is provided.<br><br><b><b>--undo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverses a previous yank operation, making the specified crate version(s) available again for new dependencies.<br><br><b><b>--token</b> <<i>API_TOKEN</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An API token to use for authentication with the registry. If not provided, Cargo will attempt to use a token from the configuration (e.g., from the <i>~/.cargo/credentials</i> file).<br><br><b><b>--registry</b> <<i>REGISTRY_NAME</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the registry to interact with (e.g., <i>crates.io</i>). If not specified, the default registry is used.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run' of the yank operation. Cargo will report what actions it would take without actually making any changes on the registry. Useful for testing.<br><br>


title: DESCRIPTION
content:
The <b>cargo yank</b> command is used to mark a specific version of a crate as 'yanked' on a package registry, such as crates.io. <br><br>Yanking a version does <i>not</i> delete it from the registry. Instead, it prevents new projects from resolving to that particular version, effectively deprecating it. This is useful for removing a version that has critical bugs or security vulnerabilities without breaking existing builds that might already depend on it via a <i>Cargo.lock</i> file.<br><br>When a crate version is yanked, new dependency resolutions will avoid it. However, if a <i>Cargo.lock</i> file already specifies a yanked version, Cargo will still download and use it. This ensures stability for existing projects while guiding new projects towards more stable or secure versions.


title: CAVEATS
content:
<i><b>Doesn't Delete:</b></i> Yanking a version does <i>not</i> delete it from the registry; it only marks it as unavailable for new resolutions.<br><br><i><b>Existing Builds:</b></i> Existing projects with a <i>Cargo.lock</i> file that specifies a yanked version will still be able to download and use that version.<br><br><i><b>Ownership Required:</b></i> Only the owner(s) of a crate can yank or un-yank its versions.<br><br><i><b>Dependency Stability:</b></i> You cannot yank the only version of a crate if other crates in the ecosystem depend on it. This prevents breaking the dependency graph for critical foundational crates.<br><br><i><b>Authentication:</b></i> The command requires proper authentication (an API token) to interact with the registry.


title: IMPACT ON DEPENDENCY RESOLUTION
content:
When Cargo resolves dependencies for a new project or when updating existing ones, it will by default avoid selecting yanked versions. This ensures that new builds receive the most up-to-date and potentially safer versions of dependencies.<br><br>However, if a <i>Cargo.lock</i> file already pins a specific, yanked version, Cargo will respect that lock file and continue to use the yanked version, maintaining reproducibility.


title: WHEN TO USE
content:
<b>cargo yank</b> is primarily used to address issues discovered after a crate version has been published, such as critical bugs, security vulnerabilities, or severe regressions.<br><br>It allows maintainers to discourage usage of a problematic version without forcing a breaking change on users who have already adopted it.


title: HISTORY
content:
The <b>cargo yank</b> command has been an integral part of the Cargo package manager from relatively early in its development, reflecting the necessity for maintainers to manage crate versions effectively on registries like crates.io. Its introduction addressed the need to deprecate faulty or insecure versions without completely removing them and breaking existing builds, a common challenge in package management ecosystems. It evolved alongside other commands focused on registry interaction and crate lifecycle management.


title: SYNOPSIS
content:
<b>cariddi</b> [<i>options</i>] {<i>-u &lt;target_url&gt;</i> | <i>-l &lt;list_file&gt;</i>} [<i>-w &lt;wordlist&gt;</i>]


title: PARAMETERS
content:
<b><b>-u, --url &lt;target_url&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a single target URL for content discovery. This is a mandatory option if <b>--list</b> is not used.<br><br><b><b>-l, --list &lt;list_file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a path to a file containing a list of target URLs, one per line. This is a mandatory option if <b>--url</b> is not used.<br><br><b><b>-w, --wordlist &lt;wordlist_file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path to the wordlist file to be used for brute-forcing directories and files. If not specified, a default wordlist might be used or discovery will be limited.<br><br><b><b>-s, --subdomains</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables subdomain enumeration for the target(s).<br><br><b><b>-r, --recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates recursive content discovery on found directories.<br><br><b><b>-d, --depth &lt;int&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum recursion depth when <b>--recursive</b> is enabled. Default is usually 1.<br><br><b><b>-t, --threads &lt;int&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the number of concurrent threads to use for requests. Higher values increase speed but can strain the target or network.<br><br><b><b>-c, --status-codes &lt;codes&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of HTTP status codes to include in the output (e.g., '200,301,403').<br><br><b><b>-x, --exclude-status &lt;codes&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of HTTP status codes to exclude from the output.<br><br><b><b>-o, --output &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the discovery results to the specified file.<br><br><b><b>-j, --json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in JSON format.<br><br><b><b>-p, --proxy &lt;proxy_url&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures an HTTP/SOCKS5 proxy for all requests (e.g., 'http://127.0.0.1:8080').<br><br><b><b>--headers &lt;headers&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds custom HTTP headers (e.g., 'Authorization: Bearer token'). Can be specified multiple times.<br><br><b><b>--cookies &lt;cookies&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds custom HTTP cookies (e.g., 'PHPSESSID=value').<br><br><b><b>--data &lt;data&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends HTTP POST data with requests (e.g., 'key=value').<br><br><b><b>--timeout &lt;duration&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the HTTP request timeout duration (e.g., '5s').<br><br><b><b>--user-agent &lt;agent&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom User-Agent string for requests.<br><br><b><b>--random-agent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a random User-Agent string for each request.<br><br><b><b>--delay &lt;duration&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a delay between HTTP requests (e.g., '100ms').<br><br><b><b>--add-extension &lt;ext&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends specified extensions to wordlist entries (e.g., '.php,.bak').<br><br><b><b>--no-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output.<br><br><b><b>--disable-tls-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables TLS certificate verification, useful for self-signed certificates.<br><br><b><b>-v, --verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during the scan.<br><br><b><b>-h, --help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>cariddi</b> version information and exits.<br><br>


title: DESCRIPTION
content:
<b>cariddi</b> is a powerful, multi-threaded command-line tool designed for comprehensive web content discovery and network reconnaissance. Written in Go, it efficiently identifies hidden directories, files, and subdomains on web servers. It leverages wordlists to brute-force common paths and supports recursive scanning to uncover deeper structures within a target website.<br><br>Primarily used by penetration testers and security professionals, <b>cariddi</b> aids in mapping out the attack surface of web applications. Its features include customizable HTTP headers and cookies, proxy support, timeout settings, and filtering options based on HTTP status codes and response lengths. The tool can output results in various formats, including JSON, making it suitable for integration into automated workflows.<br><br>Beyond simple content discovery, <b>cariddi</b> can also enumerate subdomains, providing a more complete picture of an organization's web presence. Its multi-threaded nature ensures rapid execution, making it an efficient choice for initial reconnaissance phases of security assessments.


title: CAVEATS
content:
<b>cariddi</b> is not a standard Linux command and must be installed separately, typically by compiling from source using Go or downloading pre-compiled binaries. Its aggressive scanning nature can potentially be detected by intrusion detection systems (IDS) or lead to IP blocking. Users must ensure they have proper authorization before scanning any target system, as unauthorized scanning can be illegal and unethical.


title: INSTALLATION
content:
As <b>cariddi</b> is not pre-installed on most Linux distributions, it typically needs to be built from source if Go is installed (<code>go install github.com/milo2012/cariddi@latest</code>) or downloaded as a pre-compiled binary from its GitHub releases page. Ensure the resulting executable is in your system's PATH for easy access.


title: ETHICAL USE
content:
It is imperative to use <b>cariddi</b> responsibly and ethically. Only scan systems for which you have explicit permission. Unauthorized scanning can lead to legal repercussions and may be considered a cyberattack. Always adhere to local laws and regulations concerning computer security and network scanning.


title: HISTORY
content:
<b>cariddi</b> is a relatively modern tool, developed by `milo2012` and primarily hosted on GitHub. It was created to fill a specific niche in web reconnaissance, focusing on efficient and multi-threaded content discovery. Its development leverages the Go programming language, known for its concurrency features, which contributes to <b>cariddi</b>'s speed and performance. While its exact initial release date isn't widely publicized, its continuous updates reflect an active development aiming to provide robust features for penetration testing and security auditing, evolving to include advanced filtering and output options based on community needs.


title: SYNOPSIS
content:
<b>carp</b> <i>&lt;command&gt;</i> [<i>arguments...</i>]<br><b>carp</b> <b>configure</b> <i>&lt;interface&gt;</i> <b>vhid</b> <i>&lt;id&gt;</i> [<b>addr</b> <i>&lt;ip/mask&gt;</i>] [<i>options...</i>]<br><b>carp</b> <b>status</b> [<i>&lt;interface&gt;</i>]<br><b>carp</b> <b>{up|down}</b> <i>&lt;interface&gt;</i>


title: PARAMETERS
content:
<b><i>interface</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface (e.g., <b>eth0</b>) to configure CARP on.<br><br><b><b>vhid</b> <i>id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>Virtual Host ID</i> (1-255) for the CARP group. This must be unique per group and shared across participating hosts.<br><br><b><b>addr</b> <i>ip/mask</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns the shared virtual IP address and its subnet mask (e.g., <b>192.168.1.1/24</b>) to the CARP group. This is the address that fails over.<br><br><b><b>advbase</b> <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the base interval (in seconds) for CARP advertisement packets (default 1). These packets are used for master election and state synchronization.<br><br><b><b>advskew</b> <i>milliseconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an additional time (in milliseconds) to <b>advbase</b>. A lower skew value indicates a higher priority for becoming master, allowing you to bias election.<br><br><b><b>pass</b> <i>password</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the authentication password for the CARP group. This ensures only authorized hosts can participate and prevents spoofing of advertisements.<br><br><b><b>status</b> [<i>interface</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current CARP state (master/backup) and configuration for a specified interface or all CARP-enabled interfaces.<br><br><b><b>up</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the CARP interface, allowing it to participate in master election and advertise its state.<br><br><b><b>down</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates the CARP interface, withdrawing it from the CARP group and releasing the virtual IP.<br><br>


title: DESCRIPTION
content:
CARP (Common Address Redundancy Protocol) is a network protocol designed to provide redundancy and failover for IP addresses, ensuring high availability of network services. It allows multiple hosts on the same segment to share a set of IP addresses. In the event of a primary host failure, a backup host seamlessly takes over the IP addresses, maintaining service continuity.<br><br>While CARP originated and is natively supported on OpenBSD, a dedicated <b>carp</b> command as a user-space utility does <i>not</i> exist on standard Linux distributions. Linux typically achieves similar high-availability functionality through VRRP (Virtual Router Redundancy Protocol) implementations, most notably via the <i>keepalived</i> daemon, or by configuring network interfaces and kernel parameters using tools like <b>ip</b> and <b>sysctl</b>.<br><br>This analysis describes the functionality a <b>carp</b> command <i>would</i> expose if it existed as a direct Linux utility for managing CARP protocol states, reflecting its common use-cases.


title: CAVEATS
content:
It is crucial to note that a direct, dedicated <b>carp</b> command does <i>not</i> exist as a standard utility on typical Linux distributions. While the CARP protocol itself exists and is used in network architectures, its management on Linux is usually achieved through other means: <br><br><ul><li><b>Virtual Router Redundancy Protocol (VRRP)</b>: Linux commonly uses VRRP, implemented by daemons like <i>keepalived</i>, to achieve similar high-availability functionality.</li><li><b>Standard Networking Tools</b>: IP address configuration and routing on Linux are handled by the <b>ip</b> command (from iproute2) and network interface configuration files.</li><li><b>Kernel Parameters</b>: CARP-related kernel tunables, if present (though often specific to BSDs), would be managed via <b>sysctl</b>.</li></ul>This analysis describes a <i>hypothetical</i> <b>carp</b> command to illustrate the protocol's concepts and typical configuration parameters, based on how such a command *would* function if it were available.


title: LINUX EQUIVALENTS
content:
On Linux, the functionality provided by CARP is typically achieved using the Virtual Router Redundancy Protocol (VRRP). The most popular open-source software implementing VRRP for Linux is <i>keepalived</i>. It integrates with <i>ipvsadm</i> for load balancing and provides robust health checking mechanisms to ensure high availability. While the protocols differ in some technical details and origins, both aim to provide seamless failover for shared IP addresses.


title: CARP PROTOCOL DETAILS
content:
CARP operates by sending advertisement packets to multicast addresses. A master host is elected based on configured parameters like <b>advbase</b> (advertisement base interval) and <b>advskew</b> (skew time). The host with the lowest combined <b>advbase</b> + <b>advskew</b> becomes the master. It supports IPsec authentication for securing advertisement packets using a shared password, preventing unauthorized takeover of the virtual IP address. CARP uses a Virtual Host ID (VHID) to group multiple physical hosts sharing the same virtual IP address.


title: HISTORY
content:
CARP was developed by OpenBSD as a free, open alternative to proprietary router redundancy protocols like VRRP and HSRP, addressing concerns about patent infringement and licensing. It was designed to provide robust and secure IP address failover within local area networks. While its native implementation is a core part of OpenBSD's networking stack, the principles of CARP have influenced high-availability solutions across other operating systems. On Linux, similar functionalities are predominantly fulfilled by VRRP implementations (e.g., <i>keepalived</i>), which were already well-established before CARP's widespread adoption.


title: SYNOPSIS
content:
<i>case WORD in</i><br><i>  PATTERN1 | PATTERN2)</i><br><i>    COMMAND-LIST1</i><br><i>    ;;</i><br><i>  PATTERN3)</i><br><i>    COMMAND-LIST2</i><br><i>    ;;</i><br><i>  *)</i><br><i>    DEFAULT-COMMAND-LIST</i><br><i>    ;;</i><br><i>esac</i>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>case</i> construct is a shell keyword and does not accept traditional command-line parameters or options. Its behavior is defined by the <i>WORD</i> it evaluates and the <i>PATTERN</i>s it attempts to match against within the script.<br><br>


title: DESCRIPTION
content:
The <i>case</i> construct in shell scripting (like <i>bash</i>, <i>sh</i>, <i>ksh</i>) provides a multi-way branching mechanism, allowing a block of commands to be executed based on the pattern matching of a given <i>WORD</i>. It's often used as a cleaner alternative to a long chain of <i>if/elif/else</i> statements, especially when comparing a single variable against multiple possible values or patterns. The <i>case</i> statement evaluates an expression against a list of <i>PATTERN</i>s. When the first match is found, the corresponding <i>COMMAND-LIST</i> is executed. Unlike <i>switch</i> statements in some other languages, <i>case</i> statements in shells automatically 'break' after the first matching pattern's commands are executed, meaning there's no fall-through behavior by default. The <i>PATTERN</i>s can utilize shell globbing characters (<i>*</i>, <i>?</i>, <i>[]</i>).


title: CAVEATS
content:
<ul><li>Patterns are matched from top to bottom. The first matching pattern's <i>COMMAND-LIST</i> is executed, and then the entire <i>case</i> statement terminates.</li><li>Patterns use shell globbing rules (filename expansion) rather than regular expressions. Be mindful of special characters like <i>*</i>, <i>?</i>, <i>[]</i>, and <i>|</i>.</li><li>The <i>;;</i> terminator is crucial. Omitting it would result in a syntax error for that specific pattern block. While some shells (e.g., Bash 4+) offer extensions like <i>;&</i> (fall-through, execute next list) or <i>;;;</i> (fall-through, test next list), the standard <i>case</i> uses <i>;;</i> for termination.</li><li>The <i>*)</i> pattern acts as a wildcard, matching anything if no other patterns have matched. It is good practice to include it as the last pattern for robust error handling or default behavior.</li></ul>


title: PATTERN MATCHING ORDER
content:
Patterns are evaluated sequentially. The first pattern that matches the <i>WORD</i> triggers its associated <i>COMMAND-LIST</i>, and then the <i>case</i> statement completes. This means the order of patterns can be significant, especially if patterns overlap (e.g., <i>a*</i> and <i>abc</i>).


title: GLOBBING PATTERNS
content:
Patterns inside <i>case</i> statements are typically standard shell globbing patterns, similar to those used for filename expansion. This includes:<br>    *   <i>*</i>: Matches zero or more characters.<br>    *   <i>?</i>: Matches exactly one character.<br>    *   <i>[chars]</i>: Matches any one character from <i>chars</i> (e.g., <i>[aeiou]</i>).<br>    *   <i>[!chars]</i> or <i>[^chars]</i>: Matches any one character <i>not</i> from <i>chars</i>.<br>    *   <i>|</i>: Used to separate multiple patterns for a single command list (logical OR).<br>    *   Literal characters: Match themselves.


title: HISTORY
content:
The <i>case</i> statement is a fundamental construct in Unix shell programming, tracing its origins back to the Bourne Shell (<i>sh</i>) in the late 1970s. It was designed to provide a structured way for multi-way branching, offering a cleaner and more readable alternative to nested <i>if/elif</i> statements for certain types of conditional logic. Its syntax and behavior have remained largely consistent across various POSIX-compliant shells, including <i>ksh</i>, <i>bash</i>, and <i>zsh</i>, cementing its place as a standard tool in shell scripting.


title: PARAMETERS
content:
<b><I>target_directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The optional directory where the SquashFS snapshot of the live session's changes will be saved. For example, if you want to save it to a USB drive mounted at /media/usb, you might specify <I>/media/usb/casper-rw</I> or <I>/media/usb/changes.squashfs</I> (the tool typically creates a .squashfs file inside this directory). If not specified, the command might use a default location, typically within the live environment's temporary storage, or behave differently depending on the casper version and configuration, sometimes requiring manual setup or erroring out if no suitable default is found.<br><br>


title: DESCRIPTION
content:
<b>casper-snapshot</b> is a utility included in the <b>casper</b> package, primarily used in <I>Ubuntu-based live environments</I>. Its main function is to capture and save the changes made to the filesystem of a running live session. These changes, which occur in a <I>union filesystem</I> (like overlayfs), are consolidated into a <I>SquashFS image</I>. This snapshot can then be utilized for several purposes: to maintain persistence across reboots in a live USB, or to create a customized live ISO containing the modifications. It essentially allows users to preserve their work and configurations from a volatile live session, transforming temporary changes into a persistent state.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br><i>Requires a running casper live session environment to function correctly.</i><br><i>Only captures changes made on top of the base read-only filesystem, not the entire system.</i><br><i>The size of the generated snapshot depends on the volume of changes; ensure sufficient free space in the target_directory.</i><br><i>The generated snapshot file (.squashfs) does not automatically enable persistence; it must be correctly configured with boot options (e.g., 'persistent' or 'casper-rw') for the live system to load it on subsequent boots.</i><br><i>Directly saving to a FAT32 filesystem may cause issues with large files (>4GB) or proper file permissions due to FAT32 limitations. Consider using ext2/3/4 filesystems for the target.</i>


title: OUTPUT FILE
content:
The command typically creates a SquashFS file (e.g., <I>casper-rw</I> or <I>changes.squashfs</I>) within the specified <I>target_directory</I>. This file contains the compressed filesystem changes. The exact filename might vary depending on the <b>casper</b> configuration or the specific method of invocation.


title: INTERNAL MECHANISM
content:
<b>casper-snapshot</b> works by identifying and packaging the differences between the current live filesystem (which uses a <I>union mount</I> to combine a read-only base with a writable overlay) and the original read-only base. It leverages tools like <I>mksquashfs</I> internally to compress these changes into a single, efficient SquashFS image.


title: HISTORY
content:
The <b>casper-snapshot</b> command, along with the broader <b>casper</b> framework, was developed as a crucial component of Ubuntu's efforts to create robust and user-friendly live CD/USB environments. Its primary goal was to address the challenge of persistence in live sessions, allowing users to save their work and configurations without having to install the operating system. It has been a staple tool for 'remastering' custom Ubuntu ISOs and enabling persistent live USB drives since the early days of Ubuntu.


title: SYNOPSIS
content:
<pre><b>cat</b> [<i>OPTION</i>]... [<i>FILE</i>]...</pre><br>Reads files sequentially, writing them to standard output. If <i>FILE</i> is not specified, or if <i>FILE</i> is '-', <b>cat</b> reads from standard input.


title: PARAMETERS
content:
<b>-b, --number-nonblank</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number non-blank output lines, starting at 1.<br><br><b>-E, --show-ends</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display '$' at the end of each line.<br><br><b>-n, --number</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number all output lines, starting at 1.<br><br><b>-s, --squeeze-blank</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Squeeze multiple adjacent blank lines into a single blank line.<br><br><b>-T, --show-tabs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display TAB characters as '^I'.<br><br><b>-v, --show-nonprinting</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use '^' and 'M-' notation for non-printing characters, except for LFD and TAB.<br><br><b>-A, --show-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Equivalent to <b>-vET</b>. Shows tabs, ends, and non-printing characters.<br><br><b>-u, --nobuf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unbuffered output. (Often ignored by GNU `cat` as output is typically unbuffered by default or handled by the kernel).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
<b>cat</b>, short for <i>concatenate</i>, is one of the most fundamental and frequently used commands in Unix-like operating systems. Its primary purpose is to read files sequentially and write their contents to the standard output. If no files are specified, or if a hyphen (<b>-</b>) is given as a filename, <b>cat</b> reads from standard input.<br><br>The command is versatile: it can display the content of a single file, combine multiple files into one (concatenation), or create new files from user input. While simple, <b>cat</b> is a powerful tool when combined with shell redirection operators. For instance, `cat file1 file2 > combined_file` will merge the contents of `file1` and `file2` into `combined_file`. It's often used for quick inspection of text files or as part of a larger pipeline to process data.<br><br>However, it's important to note that <b>cat</b> simply dumps content without pagination, which means for very large files, the output might scroll off the screen quickly. Its simplicity and effectiveness make it a cornerstone of shell scripting and daily command-line operations.


title: CAVEATS
content:
<br><ul><li><b>Binary Files</b>: Using <b>cat</b> on binary files can result in garbled output on your terminal, potentially corrupting display settings, and may even cause beeps or other undesirable side effects.</li><li><b>Large Files</b>: <b>cat</b> simply dumps the entire file content to standard output without any paging. For very large files, this means the content will scroll past quickly, making it difficult to read or inspect interactively. Use pagers like <b>less</b> or <b>more</b> for large files.</li><li><b>"Useless Use of Cat" (UUOC)</b>: A common anti-pattern where <b>cat</b> is used unnecessarily. For example, `cat file | grep pattern` is less efficient than `grep pattern file`. While harmless, it adds an extra process.</li></ul>


title: STANDARD INPUT INTERACTION
content:
When <b>cat</b> is invoked without any <i>FILE</i> arguments (e.g., just `cat`), or if `<b>-</b>` is specified as a filename, it reads directly from standard input (stdin). This means it will echo whatever you type into the terminal until you signal the end of the input (usually by pressing <b>Ctrl+D</b> on a new line). This interactive mode is often used for quickly creating small text files or testing command pipelines.


title: FILE CREATION AND APPENDING WITH REDIRECTION
content:
One of the most common and powerful uses of <b>cat</b> is in conjunction with shell redirection operators. You can create a new file by directing <b>cat</b>'s output: `<b>cat > new_file.txt</b>`. You can append to an existing file using `<b>cat >> existing_file.txt</b>`. In both cases, <b>cat</b> reads from standard input until EOF (Ctrl+D), writing whatever you type to the specified file. This makes <b>cat</b> a simple text editor for quick, non-interactive tasks.


title: HISTORY
content:
The <b>cat</b> command has been a staple of Unix-like operating systems since their early days. It originated in AT&T Bell Labs as part of the initial Unix development in the early 1970s. Its name, <i>concatenate</i>, directly reflects its primary function of joining files together. As a fundamental utility, its core functionality has remained remarkably consistent over decades, a testament to its simple yet effective design.<br><br>While its basic use is straightforward, <b>cat</b> gained notoriety in the Unix community for the concept of "Useless Use of Cat" (UUOC). This refers to scenarios where <b>cat</b> is piped into another command that could directly read from a file, such as `cat file | wc -l` instead of `wc -l file`. Despite this playful criticism, <b>cat</b> remains an indispensable tool for displaying file contents, interacting with standard input/output, and combining text streams in shell scripts. Its enduring presence underscores its foundational role in the Unix philosophy of small, specialized tools that do one thing well.


title: PARAMETERS
content:
<b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <b>true color</b> (24-bit) output mode, providing the highest color fidelity possible in supported terminals.<br><br><b>-w <I>WIDTH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output width of the image in terminal columns. The image will be scaled to fit this width.<br><br><b>-h <I>HEIGHT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output height of the image in terminal rows. The image will be scaled to fit this height.<br><br><b>-r <I>RATIO</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a custom width/height ratio. For example, 0.5 will make the image twice as tall as it is wide.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available character sets that <i>catimg</i> can use for rendering the image.<br><br><b>-t <I>CHAR_SET</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a particular character set to use for rendering (e.g., <b>block</b>, <b>ascii</b>, <b>unicode</b>, <b>braille</b>).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Swap foreground and background colors, effectively inversing the image's colors.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve the image's original aspect ratio (default behavior). This prevents distortion.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force aspect ratio, ignoring the original. This can lead to distorted images but might be useful with custom <b>-w</b> or <b>-h</b> values.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downscale the image if it is too large for the terminal window (default behavior).<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upscale the image if it is too small for the terminal window (default behavior).<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not upscale or downscale the image; display it at its natural character size, potentially cropping or leaving empty space.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing additional information like image dimensions and target output size.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of <i>catimg</i>.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message, listing all available options and their usage.<br><br>


title: DESCRIPTION
content:
<i>catimg</i> is a versatile command-line utility designed to render images directly within a terminal emulator. It accomplishes this by ingeniously converting traditional image pixel data into character-based representations, utilizing various character sets including standard ASCII, broader Unicode characters, or even specialized braille patterns. For modern terminals that boast support for <b>true color</b> (24-bit color), <i>catimg</i> can display images with remarkable color fidelity and detail. In environments with less capable terminals, it intelligently falls back to either 256-color or even more basic 8-color palettes, ensuring broad compatibility. The tool supports a wide array of common image formats such as PNG, JPEG, and GIF, making it an excellent and rapid solution for quick visual previews, for viewing images in environments where a graphical user interface (GUI) is either unavailable or undesired (like remote SSH sessions), or for seamless integration into custom shell scripts and automated workflows.


title: CAVEATS
content:
The quality and appearance of images displayed by <i>catimg</i> are highly dependent on the capabilities of the terminal emulator being used. Optimal results, especially with <b>true color</b>, require a terminal that fully supports 24-bit color. Character set rendering may also vary, leading to inconsistencies across different terminals. Displaying very large images can consume significant CPU resources and memory, potentially leading to slower performance.


title: TRUE COLOR AND TERMINAL SUPPORT
content:
For the best visual experience, ensure your terminal emulator (e.g., Alacritty, iTerm2, Kitty, GNOME Terminal with correct settings) supports <b>24-bit true color</b>. Without it, <i>catimg</i> will fall back to a more limited color palette, which may reduce image quality. You can often check your terminal's true color support using external utilities or by testing <i>catimg</i> with the <b>-c</b> option on a colorful image.


title: USE CASES
content:
<i>catimg</i> is particularly useful in several scenarios:<br><b>Quick Previews:</b> Rapidly view images without launching a full-fledged graphical viewer.<br><b>Remote Servers:</b> Display images when logged into a server via SSH where no GUI is available.<br><b>Scripting:</b> Integrate image display into shell scripts for notifications, banners, or interactive tools.<br><b>Customization:</b> Personalize your terminal environment with images as part of your prompt or startup messages.


title: HISTORY
content:
<i>catimg</i> emerged as terminal emulators gained more sophisticated capabilities, particularly with the widespread adoption of <b>true color</b> support. Its development fills a niche for command-line users who require quick, native image viewing without reliance on graphical environments. It represents a step forward from older ASCII art converters by aiming for higher fidelity and direct color reproduction, making it a popular choice in scripting, remote server administration, and for customizing command-line interfaces.


title: SYNOPSIS
content:
<b>catman</b> [<b>-w</b>|<b>-c</b>] [<b>-q</b>] [<b>-p</b>] [<b>-r</b>] [<b>-s</b> <I>sections</I>] [<b>-M</b> <I>manpath</I>] [<I>manpages...</I>]


title: PARAMETERS
content:
<b><b>-w</b>, <b>--write</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Default behavior.</I> Creates or updates the pre-formatted manual pages. This is the normal mode of operation.<br><br><b><b>-c</b>, <b>--clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes pre-formatted manual pages that do not have a corresponding source manual page, effectively cleaning up outdated caches.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output messages, useful for automated scripts.<br><br><b><b>-p</b>, <b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a progress bar during the operation, providing visual feedback.<br><br><b><b>-r</b>, <b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively searches for manual pages within the specified <I>manpath</I>.<br><br><b><b>-s</b> <I>sections</I>, <b>--sections</b>=<I>sections</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the operation to manual pages within the specified colon-separated list of sections (e.g., '1:8').<br><br><b><b>-M</b> <I>manpath</I>, <b>--manpath</b>=<I>manpath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <I>manpath</I> to search for and store manual pages, overriding the default system configuration.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints extensive debugging information during execution.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>catman</I> utility.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message and exits.<br><br><b><I>manpages...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional list of specific manual pages to process. If omitted, <I>catman</I> processes all relevant manual pages in the specified or default <I>manpath</I>.<br><br>


title: DESCRIPTION
content:
<I>catman</I> is a utility program within the <I>man-db</I> package, designed to create and update the pre-formatted ("cat") versions of Linux manual pages. When you view a manual page using the <I>man</I> command, it typically displays a cached, pre-processed version rather than parsing the original source file (usually a <I>groff</I> document) every time. <I>catman</I> is responsible for generating these optimized "cat" pages, which are stored in subdirectories like <I>cat1</I>, <I>cat2</I>, etc., within the manual page hierarchy.<br><br>The primary purpose of <I>catman</I> is to significantly speed up the display of manual pages by performing the formatting work in advance. It can process all manual pages within a specified <I>manpath</I> or only a selection of them. Additionally, it can clean up outdated "cat" pages that no longer have corresponding source manual pages, helping to maintain a consistent and efficient manual page system.<br><br>While essential for the operation of the <I>man</I> command, <I>catman</I> is generally used by system administrators, package managers, or automated system scripts rather than by end-users. Its operation often requires elevated privileges to modify system-wide manual page directories.


title: CAVEATS
content:
Using <I>catman</I> incorrectly or with insufficient permissions can lead to corrupted or inaccessible manual pages. It is primarily a system administration tool and should be used with caution, typically requiring root privileges to modify system-wide manual page directories. For general index updates, <I>mandb(8)</I> is often the preferred and more comprehensive utility.


title: TYPICAL USAGE
content:
<I>catman</I> is frequently invoked by system package managers during software installation or updates to ensure that newly installed manual pages are correctly formatted and indexed. It can also be run periodically via cron jobs to refresh the entire manual page cache or clean up stale entries, ensuring the <I>man</I> system remains up-to-date and efficient.


title: HISTORY
content:
<I>catman</I> is an integral part of the <I>man-db</I> project, which emerged as a modern and more efficient replacement for older manual page systems on Linux. The <I>man-db</I> package, and thus <I>catman</I>, was developed to address performance bottlenecks and improve the management of manual pages by leveraging a database-driven approach and pre-formatted "cat" pages. Its design focuses on creating a robust and fast system for serving documentation, becoming a standard component of most contemporary Linux distributions.


title: SEE ALSO
content:
<b>man(1)</b>, <b>mandb(8)</b>, <b>apropos(1)</b>, <b>whatis(1)</b>, <b>groff(1)</b>, <b>gzip(1)</b>


title: SYNOPSIS
content:
<b>cavif</b> [OPTIONS] &lt;INPUT_FILE&gt;...<br><b>cavif</b> [OPTIONS] &lt;INPUT_FILE&gt; -o &lt;OUTPUT_FILE&gt;<br><b>cavif</b> [OPTIONS] &lt;INPUT_FILE&gt;... --dir &lt;OUTPUT_DIRECTORY&gt;


title: PARAMETERS
content:
<b><I>-Q, --quality &lt;QUALITY&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the quality level for AVIF encoding, ranging from 0 (lowest quality, smallest file) to 100 (highest quality, largest file). Default is usually 60-80.<br><br><b><I>-s, --speed &lt;SPEED&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the encoding speed, from 0 (slowest, best compression) to 10 (fastest, less compression). Higher speed means faster encoding but larger file sizes.<br><br><b><I>-p, --parallel &lt;NUM_THREADS&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of threads to use for encoding, leveraging multi-core processors for faster processing.<br><br><b><I>--depth &lt;DEPTH&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bit depth for the output AVIF image (e.g., 8, 10, or 12 bits). Higher depths allow for more color precision, but increase file size.<br><br><b><I>-o, --output &lt;OUTPUT_FILE&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file path for a single input file. If omitted for a single input, it defaults to a new file with .avif extension in the current directory.<br><br><b><I>--dir &lt;OUTPUT_DIRECTORY&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Designates an output directory when converting multiple input files. Each input file will be converted to an AVIF file in this directory with its original name and .avif extension.<br><br><b><I>--lossless</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encodes the image in a lossless manner. This typically results in larger file sizes but preserves every detail of the original image.<br><br><b><I>--alphar</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encodes the alpha channel losslessly. This is useful for images with transparency where preserving alpha fidelity is critical.<br><br><b><I>--overwrite</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows overwriting existing output files without prompting for confirmation.<br><br><b><I>-q, --quiet</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational output, showing only errors.<br><br><b><I>-v, --verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details about the encoding process.<br><br><b><I>-h, --help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and usage.<br><br>


title: DESCRIPTION
content:
cavif is a command-line tool written in <I>Rust</I> designed to convert various image formats, predominantly <I>JPEG</I> and <I>PNG</I>, into the modern and highly efficient <I>AVIF</I> (AV1 Image File Format). AVIF utilizes the advanced compression capabilities of the <I>AV1</I> video codec, offering superior compression ratios compared to traditional formats like JPEG, which often results in significantly smaller file sizes with minimal or no perceptible loss in image quality. This makes AVIF an excellent choice for web optimization, reducing bandwidth usage, and efficient image storage.<br><br>The tool acts as a user-friendly front-end to the underlying <I>libavif</I> library, abstracting away complex details and providing straightforward options for encoding parameters such as quality, speed, and color depth. <I>cavif</I> supports features like transparency (alpha channel), various chroma subsampling options, and allows users to balance encoding speed against compression efficiency. Its implementation in Rust often contributes to its performance and memory efficiency, making it suitable for batch conversions or integration into automated image processing workflows.


title: CAVEATS
content:
cavif is a third-party utility and not part of standard Linux core utilities. It requires <I>Rust</I> and <I>Cargo</I> for installation (typically via <I>cargo install cavif</I>).<br>While AVIF offers excellent compression, its adoption is still growing, and not all image viewers or web browsers fully support it. Always test compatibility with your target audience or platform.<br>Encoding large images or using very high quality/slow speed settings can be CPU-intensive and time-consuming.


title: <B>INSTALLATION</B>
content:
To install <I>cavif</I>, you typically need to have <I>Rust</I> and its package manager, <I>Cargo</I>, installed on your system. Once they are set up, you can install <I>cavif</I> directly from <I>crates.io</I> using the command: <br><b>cargo install cavif</b>.<br>Ensure your <I>Cargo</I> binary directory (e.g., <I>~/.cargo/bin</I>) is in your system's <I>PATH</I> to execute the command directly.


title: <B>USE CASES</B>
content:
<I>cavif</I> is primarily used for:<br><br>• <I>Web Image Optimization:</I> Reducing image file sizes for websites to improve loading times and user experience.<br>• <I>Archival and Storage:</I> Efficiently storing large collections of images with minimal quality loss.<br>• <I>Automated Workflows:</I> Integrating into scripts or build processes for automatic image conversion during development or deployment.<br>• <I>Reducing Bandwidth Costs:</I> For services that serve many images, smaller files can significantly reduce data transfer costs.


title: HISTORY
content:
<I>cavif</I> emerged as a modern, <I>Rust</I>-based command-line interface for encoding images to the <I>AVIF</I> format. The <I>AVIF</I> format itself is relatively new, based on the open and royalty-free <I>AV1</I> video codec developed by the <I>Alliance for Open Media (AOMedia)</I>. As AVIF gained traction as a successor to formats like <I>JPEG</I> due to its superior compression and features like transparency, tools like <I>cavif</I> were developed to make the encoding process accessible to users outside of complex video encoding pipelines. Its development in <I>Rust</I> is a notable aspect, often associated with performance and reliability. It became a popular choice for web developers and users looking for an efficient way to optimize images for the web or for storage.


title: SEE ALSO
content:
<I>avifenc(1)</I> (Official AVIF encoder utility from libavif), <I>cwebp(1)</I> (WebP image encoder), <I>ffmpeg(1)</I> (Multimedia framework that can encode AVIF), <I>convert(1)</I> (ImageMagick command-line tool for image manipulation and conversion)


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the standard C style, typically resembling Bell Laboratories' conventions.<br><br><b><b>-l</b> <i>len</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum line length to <i>len</i> characters. Lines exceeding this length will be broken. The default is 79 characters.<br><br><b><b>-j</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Joins multiple 'case' labels onto a single line.<br><br><b><b>-f</b> <i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a formatting style. Available types include: <i>all</i>, <i>k&r</i> (Kernighan & Ritchie), <i>indent</i>, and <i>sysv</i>.<br><br><b><b>-ps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inserts a space after every right parenthesis.<br><br><b><b>-bss</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Breaks braces onto their own lines (e.g., <code>if (a) { b; }</code> becomes <code>if (a)<br>{ b; }</code>).<br><br><b><b>-bad</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encloses declarations in braces.<br><br><b><b>-nfn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents newlines from being inserted before function names.<br><br>


title: DESCRIPTION
content:
The <i>cb</i> (C Beautifier) command is a classic Unix utility designed to reformat C source code. It reads C program text from standard input and outputs the beautified version to standard output, making it suitable for piping or redirection. Its primary function is to enhance code readability by consistently adjusting indentation, spacing, and the placement of braces, particularly for constructs like <i>if-else</i>, <i>for</i>, <i>while</i>, and <i>switch</i> statements, as well as function definitions. While <i>cb</i> aims to enforce a consistent coding style, it operates on a lexical level rather than performing a full syntactic or semantic analysis of the C code. This means it can sometimes be confused by complex preprocessor macros or non-standard C constructs. Despite its age and the availability of more sophisticated code formatters today, <i>cb</i> historically served as a valuable tool for developers to quickly clean up poorly formatted code or to apply a basic, uniform style across a codebase.


title: CAVEATS
content:
The <i>cb</i> command is a simple, lexical formatter and does not perform full syntactic or semantic analysis of C code. This limitation means it can sometimes produce incorrect or undesirable formatting when encountering complex preprocessor macros, especially those that drastically alter the code structure. It is designed exclusively for C code and offers no support for C++ or other programming languages. Furthermore, <i>cb</i> writes its output to standard output, requiring users to explicitly redirect the output to a file if they wish to modify the original source. On many modern Linux distributions, <i>cb</i> is not installed by default and is largely considered obsolete, having been superseded by more robust and configurable code formatters like <i>indent</i>, <i>astyle</i>, or <i>clang-format</i>, which offer greater control and better understanding of C syntax.


title: BASIC USAGE
content:
To use <i>cb</i>, you typically pipe the content of a C source file to its standard input, and then redirect its standard output to a new file or back to the original file (with caution). For example: <br> <code>cat my_program.c | cb > my_program_formatted.c</code> <br> or <br> <code>cb &lt; my_program.c > my_program_formatted.c</code>.


title: STYLING LIMITATIONS
content:
While <i>cb</i> can adjust indentation and brace placement, it does not modify comments or string literals within the code. Its stylistic options are relatively limited compared to modern formatters, primarily focusing on variations of common C coding styles like Kernighan & Ritchie (K&R) or System V.


title: HISTORY
content:
The <i>cb</i> command originated in early Unix systems, particularly in environments like Bell Laboratories, and later became a component of various Unix distributions, including System V and BSD variants. Its development reflects the need for automated code formatting during an era when consistent coding styles were manually enforced or managed with simpler tools. It was designed to help programmers maintain readable code without the aid of modern IDEs or advanced language parsers. While once a useful utility, its development largely ceased as more sophisticated formatters, capable of deeper syntax analysis and greater customization, emerged. Today, it is mostly found in historical Unix archives or as part of compatibility packages like <i>bsd-utils</i> on some Linux distributions, serving as a testament to early efforts in code style automation.


title: SYNOPSIS
content:
<b>cbatticon</b> [<i>-c</i>] [<i>-d</i>] [<i>-f format</i>] [<i>-t low:high</i>] [<i>-p</i>] [<i>-u</i>]


title: PARAMETERS
content:
<b><i>-c</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the charging icon when the battery is currently charging.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the discharging icon when the battery is currently discharging.<br><br><b><i>-f format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom output <i>format string</i>. This string can contain placeholders for battery percentage, various icons, and other status information. The exact placeholders depend on the specific <i>cbatticon</i> version.<br><br><b><i>-t low:high</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets battery percentage <i>thresholds</i> for changing icon representations. For example, '20:80' might mean one icon below 20%, another between 20-80%, and a third above 80%.<br><br><b><i>-p</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the battery percentage alongside the icon or as the primary output, depending on other options and default behavior.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays an 'unknown' or 'full' icon when the battery status is not clearly charging or discharging, or when fully charged and not connected to power.<br><br>


title: DESCRIPTION
content:
<i>cbatticon</i> is a lightweight and minimalist utility designed to display current battery status. It is predominantly used within window managers such as <i>dwm</i> to provide a compact visual representation of battery charge, often integrated directly into the status bar. The command typically outputs a string comprising an icon (indicating charging, discharging, or full) and/or the percentage of remaining battery life. It retrieves battery information directly from the system's power supply interface, usually through the <i>/sys/class/power_supply/</i> directory. Its design philosophy emphasizes simplicity and efficiency, making it an ideal choice for users seeking a clean and unobtrusive battery indicator without the overhead of more complex graphical tools.


title: CAVEATS
content:
The exact behavior and available options of <i>cbatticon</i> can vary significantly between different versions or user-compiled instances, as it is often patched or customized by users of <i>suckless</i> tools. Users should consult their specific installation's documentation or source code for precise details. It primarily relies on battery information exposed through the <i>/sys/class/power_supply/</i> interface; systems that do not expose this information or use a different mechanism may not be compatible.


title: INTEGRATION WITH STATUS BARS
content:
<i>cbatticon</i> is not a standalone graphical application. Instead, it is typically used in conjunction with status bar utilities (like <i>xsetroot</i> or direct manipulation of <i>/proc/self/fd/0</i> in <i>dwm</i>'s status bar scripts) to periodically update and display battery information. Users often write small shell scripts that call <i>cbatticon</i>, format its output, and then push that output to their status bar. An example of such a script snippet might be: <br><br><i>while true; do <br>&nbsp;&nbsp;xsetroot -name "$(cbatticon -p)" <br>&nbsp;&nbsp;sleep 60 <br>done</i>


title: HISTORY
content:
<i>cbatticon</i> emerges from the <i>suckless.org</i> community, known for developing minimalist and highly customizable software like <i>dwm</i> and <i>st</i>. Its development aligns with the suckless philosophy of creating simple, efficient, and single-purpose tools that do one thing well. It's not a standalone project with a long release history but rather a small utility often included or adapted as a patch within users' <i>dwm</i> configurations. Its history is therefore less about formal releases and more about community contribution and adaptation to specific user needs within the suckless ecosystem.


title: PARAMETERS
content:
<b>-i, --iterations &lt;number&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate a specified number of tree generations before exiting. Use <i>0</i> for infinite iterations (unless <b>--live</b> is used).<br><br><b>-l, --live</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>live mode</i>, causing the tree to animate continuously and infinitely loop without regenerating.<br><br><b>-s, --speed &lt;ms&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the animation speed by defining the delay between frames in <i>milliseconds</i>. Lower values mean faster animation.<br><br><b>-c, --color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>color output</i> for the bonsai tree, leaves, and birds. Highly recommended for visual appeal.<br><br><b>-F, --force-colors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to force <i>24-bit true colors</i>. Requires a terminal emulator with true color support.<br><br><b>-b, --birds</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display small <i>animated birds</i> flying around the tree. Works best with color enabled.<br><br><b>-B, --no-bold</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the use of <i>bold text</i> for rendering the tree trunk and branches.<br><br><b>-L, --long-sleep &lt;ms&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define a <i>longer sleep duration</i> (in milliseconds) between iterations or full growth cycles.<br><br><b>-f, --full-screen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to utilize the <i>full terminal screen</i> for rendering the bonsai tree, maximizing its size.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display <i>version information</i> for the cbonsai command and then exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a <i>help message</i> detailing command usage and available options, then exit.<br><br>


title: DESCRIPTION
content:
<b>cbonsai</b> is a lightweight, <i>ncurses-based</i> program that renders an animated <i>ASCII art bonsai tree</i> directly in your terminal. It's designed to be a playful and visually appealing command-line utility, often used for relaxation, as a screensaver, or simply to add a unique aesthetic to your console.<br><br>The tree grows and changes over time, showcasing different phases of its life cycle, from a sprouting sapling to a mature tree, complete with falling leaves. Its simplicity and charm make it a popular choice for users looking for a bit of calm and beauty within the otherwise text-heavy Linux environment. It's highly customizable, allowing users to control aspects like growth speed, leaf color, and even the appearance of birds. It leverages terminal capabilities to provide a smooth, dynamic animation without heavy resource consumption.


title: CAVEATS
content:
<b>cbonsai</b> relies on <i>ncurses</i> and terminal capabilities.<br><i>True color support</i> (<b>-F</b>) is terminal-dependent.<br>Performance can vary with terminal emulator and system load.<br>The visual appearance might differ slightly based on the terminal's font and aspect ratio.<br>May not work as expected in non-VT100 compatible terminals.


title: DEPENDENCIES
content:
Requires the <i>ncurses</i> library for terminal manipulation and a C compiler (like <i>GCC</i> or <i>Clang</i>) for compilation if installing from source.


title: INSTALLATION
content:
Typically available in most popular Linux distribution repositories. For example, on Debian/Ubuntu systems, it can be installed via: <br><i>sudo apt install cbonsai</i>


title: USAGE AS SCREENSAVER
content:
Although not a true system screensaver, <b>cbonsai</b> can be used for continuous display in a terminal by running it in a loop or within a <i>tmux</i>/<i>screen</i> session, often combined with <b>--live</b> mode.


title: HISTORY
content:
<b>cbonsai</b> was initially created by <i>Holger Just</i> (dogontheloose) and first publicly released around <i>2020</i>. It quickly gained traction within the Linux community as a delightful and unconventional terminal utility. Developed as an <i>open-source project</i>, its code is hosted on GitHub, encouraging community contributions and continuous improvements. It represents a modern take on command-line entertainment, purely focused on aesthetic enjoyment and light interaction within the terminal environment, rather than traditional system tasks.


title: PARAMETERS
content:
<b><b>-project</b> <i>project-id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Google Cloud project ID to operate within. This overrides the default project configured in the Google Cloud SDK or environment variables.<br><br><b><b>-instance</b> <i>instance-id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Bigtable instance ID to connect to for the operation. This is mandatory for most data and table management commands.<br><br><b><b>-creds</b> <i>path-to-key-file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the path to a service account JSON key file for authentication. Alternative authentication methods include `gcloud auth application-default login`.<br><br><b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific operation to perform, such as <b>createinstance</b>, <b>createtable</b>, <b>read</b>, <b>ls</b>, or <b>delete</b>. <i>cbt</i> is organized around these subcommands, each with its own syntax and purpose.<br><br><b><i>command-options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the chosen <i>command</i>. These modify the behavior of the subcommand, for example, specifying column families, row ranges, or cluster configurations.<br><br><b><i>arguments</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Positional arguments required by the <i>command</i>, such as an instance ID, table name, row key, or a value to write.<br><br>


title: DESCRIPTION
content:
<i>cbt</i> is a command-line interface (CLI) tool for interacting with Google Cloud Bigtable, a fully managed, scalable NoSQL database service. It is developed by Google and built with Go, providing a convenient way for developers and administrators to manage Bigtable instances, clusters, tables, and data directly from their terminal.<br><br>Unlike traditional Linux commands that operate on local filesystems or system processes, <i>cbt</i> facilitates operations on a remote cloud service. It allows users to perform tasks such as creating and deleting instances and tables, reading and writing data, managing column families, and inspecting table schemas without writing any code. <i>cbt</i> is often used for scripting administrative tasks, ad-hoc data lookups, and troubleshooting within Bigtable environments. It requires proper Google Cloud authentication and project configuration to function.


title: CAVEATS
content:
The <i>cbt</i> command is specifically designed for Google Cloud Bigtable and is not a general-purpose Linux utility. It requires a Google Cloud project, a Bigtable instance, and proper authentication (e.g., via <i>gcloud</i> SDK or service account keys) to function. Network connectivity to Google Cloud is also necessary. Its installation typically involves the <i>Google Cloud SDK</i> or building from source using <I>Go</I>.


title: INSTALLATION
content:
The <i>cbt</i> command is typically installed as part of the <I>Google Cloud SDK</I> (gcloud CLI). It can also be built and installed directly from its open-source <I>Go</I> repository on GitHub.


title: AUTHENTICATION
content:
To interact with Google Cloud Bigtable, <i>cbt</i> requires authentication. The most common method is to use <I>Google Cloud SDK</I> credentials, often set up via `gcloud auth application-default login`, or by specifying a service account key file using the <b>-creds</b> option.


title: HISTORY
content:
The <i>cbt</i> command was developed by Google as part of the <i>Google Cloud</i> ecosystem, specifically for administering and interacting with <i>Google Cloud Bigtable</i>. It is written in <I>Go</I> and open-sourced, evolving alongside the <i>Bigtable</i> service itself to provide a direct, powerful command-line interface for managing data and schemas in the <I>NoSQL</I> database.


title: PARAMETERS
content:
<b><b>-o</b> <I>output_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output file (executable, object, or library).<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile or assemble the source files, but do not link. Outputs object files (.o).<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile source files to assembly code (.s), but do not assemble or link.<br><br><b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run only the preprocessor stage. Output goes to standard output by default.<br><br><b><b>-I</b> <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add directory <I>dir</I> to the list of directories to be searched for header files.<br><br><b><b>-L</b> <I>dir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add directory <I>dir</I> to the list of directories to be searched for library files.<br><br><b><b>-l</b> <I>lib</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Link with the library named <I>lib</I>. The compiler searches for <I>liblib.a</I> or <I>liblib.so</I>.<br><br><b><b>-Wall</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable all commonly used warning messages.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce debugging information (for use with debuggers like GDB).<br><br><b><b>-O</b><I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize the generated code. <I>level</I> can be 0 (no optimization), 1, 2, 3, or s (size optimization).<br><br><b><b>-std=</b><I>version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the C standard to which the code should conform (e.g., <b>c99</b>, <b>c11</b>, <b>gnu11</b>).<br><br>


title: DESCRIPTION
content:
<i>cc</i> is a command on Linux systems that typically acts as the default C compiler. Historically, <i>cc</i> referred to the original C compiler provided with Unix systems. On modern Linux distributions, <i>cc</i> is almost invariably a symbolic link to <b>gcc</b> (GNU Compiler Collection) or sometimes <b>clang</b>. Its primary purpose is to compile C source code files into executable programs or object files.<br><br>It orchestrates the entire compilation process, which includes preprocessing, compilation (to assembly), assembly (to object code), and linking. While it's primarily associated with C, the underlying <b>gcc</b> or <b>clang</b> compiler supports many other languages like C++, Fortran, and others, though <i>cc</i> specifically implies the C compiler frontend. It's a fundamental tool for software development, allowing developers to turn human-readable source code into machine-executable binaries.


title: CAVEATS
content:
<I>cc</I> on Linux is typically a symbolic link to a specific compiler, most commonly <b>gcc</b> (GNU Compiler Collection) or sometimes <b>clang</b>. Its behavior and supported options are therefore largely determined by the actual compiler it points to. While it's used for C, the underlying compiler can often handle C++ and other languages, but for explicit C++ compilation, <b>g++</b> or <b>clang++</b> are usually preferred.


title: <B>THE COMPILATION PROCESS</B>
content:
When you invoke <I>cc</I> to compile a source file, it typically goes through several stages:<br>1. <b>Preprocessing</b>: Handles directives like <I>#include</I> and <I>#define</I>, expanding macros and including header files. Output is an expanded source file.<br>2. <b>Compilation</b>: Translates the preprocessed code into assembly language specific to the target architecture.<br>3. <b>Assembly</b>: Converts the assembly code into machine code (object code), typically stored in <I>.o</I> files.<br>4. <b>Linking</b>: Combines the object files with necessary libraries (like the C standard library) to produce a final executable program or a shared library.


title: <B>DEFAULT OUTPUT</B>
content:
If no output file name is specified using the <b>-o</b> option, <I>cc</I> will, by default, create an executable file named <I>a.out</I> in the current directory. This name also has historical significance in Unix systems.


title: HISTORY
content:
The command name <I>cc</I> has historical roots, dating back to the earliest versions of Unix where it referred to the original Bell Labs C compiler. As the C language gained popularity and various compilers emerged, <I>cc</I> became a conventional alias or symbolic link to the system's default C compiler. In the Linux ecosystem, the GNU Compiler Collection (GCC), developed by the GNU Project, became the predominant C compiler, leading to <I>cc</I> almost universally pointing to <I>gcc</I>. This convention ensures that scripts and build systems written for a generic Unix environment can reliably invoke the system's C compiler.


title: SYNOPSIS
content:
<I>ccache</I> <I>[OPTION...]</I><br>
<I>ccache</I> <I>&lt;compiler&gt;</I> <I>[ARG...]</I><br>
<I>ccache</I> <I>-s</I> <I>[OPTION...]</I><br>
<I>ccache</I> <I>-C</I> <I>[OPTION...]</I>


title: PARAMETERS
content:
<b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show current cache statistics.<br><br><b>--show-stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show current cache statistics.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zero current cache statistics.<br><br><b>--zero-stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zero current cache statistics.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear the entire cache.<br><br><b>--clear</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear the entire cache.<br><br><b>-M SIZE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum cache size (e.g., -M 10G or -M 500M).<br><br><b>--max-size=SIZE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum cache size.<br><br><b>-F</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flush any pending writes to disk.<br><br><b>--flush</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flush any pending writes to disk.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current effective configuration.<br><br><b>--show-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current effective configuration.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display ccache version information.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message.<br><br>


title: DESCRIPTION
content:
<i>ccache</i> is a compiler cache. It acts as a wrapper around your C/C++/Objective-C compiler, significantly speeding up recompilation times. When you compile code, <i>ccache</i> intercepts the compiler call. It then calculates a hash of the source code, compiler options, preprocessor output, and other relevant environment variables. If a matching compilation has been performed before and is found in the cache, <i>ccache</i> simply returns the cached object file, avoiding the actual compiler invocation. If no match is found, <i>ccache</i> executes the real compiler, stores the resulting object file in its cache, and then passes it back to the build system. This process is transparent to the build system, making it easy to integrate. While it doesn't speed up the very first full build, it provides substantial benefits during iterative development cycles, saving developers valuable time.


title: CAVEATS
content:
While <i>ccache</i> is highly effective, it has some limitations. It does not speed up the initial full build of a project, as there are no cached results yet. It can consume significant disk space, so it's important to monitor and manage the cache size using the <i>-M</i> option. In rare cases, if environmental variables or compiler options are changed in a subtle way not tracked by <i>ccache</i>'s hashing algorithm, it might serve a stale cache entry, though this is uncommon with default settings. Proper integration often involves prepending <i>ccache</i>'s directory to your <i>PATH</i>, which needs to be correctly set up.


title: PATH INTEGRATION
content:
The most common way to use <i>ccache</i> is to create symbolic links (e.g., <i>gcc</i>, <i>g++</i>, <i>cc</i>) to the <i>ccache</i> executable in a directory, and then prepend this directory to your system's <i>PATH</i> environment variable. When a build system invokes <i>gcc</i>, it will find the <i>ccache</i> symlink first, which then executes <i>ccache</i>, which in turn calls the actual compiler. This makes <i>ccache</i> completely transparent to the build process.


title: CACHE DIRECTORY AND CONFIGURATION
content:
By default, <i>ccache</i> stores its cache files in <i>~/.ccache</i>. This location can be customized using the <i>CCACHE_DIR</i> environment variable. <i>ccache</i> also offers extensive configuration options via environment variables (e.g., <i>CCACHE_MAXSIZE</i>, <i>CCACHE_COMPILERCHECK</i>) and a configuration file (usually <i>~/.config/ccache/ccache.conf</i>). These options allow fine-tuning of caching behavior, such as hash extensions, compiler check methods, and debug logging.


title: HISTORY
content:
<i>ccache</i> was initially developed by Andrew Tridgell, known for his work on rsync and Samba. It was first released around 2004 and quickly gained popularity in the open-source community for its ability to significantly reduce build times in large projects. It has since been widely adopted by projects such as the Linux kernel, WebKit, and LLVM, becoming a staple tool for developers. The project continues to be actively maintained and improved upon, ensuring its compatibility with modern compilers and build systems.


title: PARAMETERS
content:
<b><B>list</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists installed or available compiler components.<br><br><b><B>info</B> <I>component</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific compiler component.<br><br><b><B>install</B> <I>component</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically installs a new compiler component or toolchain.<br><br><b><B>remove</B> <I>component</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hypothetically removes an installed compiler component.<br><br><b><B>check</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the integrity and dependencies of installed compiler components.<br><br><b><B>-v</B>, <B>--verbose</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for detailed execution information.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and available options.<br><br>


title: DESCRIPTION
content:
The <I>ccomps</I> command is not a standard Linux utility. This description is based on a hypothetical command designed to manage various components of C compilers, such as toolchains, libraries, headers, and specific compiler versions. It would ideally provide functionalities for listing installed components, verifying their integrity, managing different compiler environments, and potentially installing or updating compiler-related packages. The utility would be crucial for developers working with multiple C/C++ projects requiring specific compiler configurations or ensuring consistent development environments. Its primary purpose would be to streamline the management of complex compiler infrastructures beyond basic package management tools.


title: CAVEATS
content:
The <I>ccomps</I> command is not a standard or commonly recognized utility in most Linux distributions. The functionality and syntax described here are entirely hypothetical, based on an interpretation of 'C Compiler Components' as a potential command name. Users attempting to execute 'ccomps' on a standard Linux system will likely encounter a 'command not found' error. This information is illustrative of what such a command *might* do if it existed as a dedicated compiler component manager.


title: HYPOTHETICAL USE CASES
content:
If <I>ccomps</I> were a real command, it could be used by build systems to ensure specific compiler versions are available, by developers to quickly switch between different compiler configurations for testing, or by system administrators to manage and audit installed compiler toolchains across a development server.


title: HISTORY
content:
As <I>ccomps</I> is not a standard Linux command, there is no documented history of its development or usage within the open-source community. If such a tool were to exist, its development would likely stem from the increasing complexity of managing diverse compiler toolchains, cross-compilation environments, and specific library versions required by various C/C++ projects, aiming to provide a higher-level abstraction over traditional package managers for compiler-specific needs.


title: PARAMETERS
content:
<b><I>DIRECTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the target directory. This can be an absolute path (starting from root '/') or a relative path (from the current directory).<br><br><b>(no argument)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes to the user's home directory (e.g., <i>/home/username</i>).<br><br><b>~</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Also changes to the user's home directory. This is a common shell expansion for the home directory path.<br><br><b>-</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes to the previous working directory, stored in the <b>OLDPWD</b> environment variable. This is useful for toggling between two directories.<br><br><b>..</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves up one level in the directory hierarchy (to the parent directory).<br><br><b>.</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refers to the current directory. Using <b>cd .</b> effectively does nothing, remaining in the current directory.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Logical) Follows symbolic links. This is the default behavior. When encountering a symbolic link, the new directory path will reflect the linked path, not the physical path it points to.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Physical) Resolves symbolic links. When encountering a symbolic link, <b>cd -P</b> will resolve it to its physical location, ignoring the symbolic link itself. This updates the <b>PWD</b> variable to the canonical physical path.<br><br>


title: DESCRIPTION
content:
The <b>cd</b> (change directory) command is a fundamental utility in Linux and Unix-like operating systems, used to navigate the file system.<br><br>It modifies the shell's current working directory, allowing users to move between different directories and access their contents. When you execute <b>cd</b>, it changes the internal state of your shell process, updating environment variables like <b>PWD</b> (current working directory) and <b>OLDPWD</b> (previous working directory).<br><br>Unlike many other commands, <b>cd</b> is almost always a <i>shell built-in</i>, meaning it's executed directly by your shell (e.g., Bash, Zsh) rather than being a separate executable program. This is crucial because a separate program cannot change the working directory of its parent process (your shell). Its simplicity and constant usage make it one of the most frequently typed commands in any terminal session.


title: CAVEATS
content:
<b>cd</b> is almost universally a <i>shell built-in</i>. This means `which cd` will typically not find an executable, and it runs directly within your current shell process. This is essential for it to change the working directory of that specific shell session.<br><br>To successfully change into a directory, you need <i>execute</i> permission on all directories in the path leading to the target directory. You also need <i>read</i> permission on the target directory if you intend to list its contents using `ls`.


title: ENVIRONMENT VARIABLES
content:
The <b>cd</b> command manipulates two important environment variables: <b>PWD</b> and <b>OLDPWD</b>. <b>PWD</b> always holds the absolute path of the current working directory, and <b>OLDPWD</b> stores the path of the directory you were in immediately before the last <b>cd</b> command. These variables are often used by other commands and scripts for path management.


title: TAB COMPLETION
content:
Modern shells offer excellent <i>tab completion</i> for <b>cd</b>. By typing `cd` followed by a few letters of a directory name and pressing the Tab key, the shell will attempt to complete the directory name, making navigation much faster and less prone to typing errors.


title: HISTORY
content:
The <b>cd</b> command has been a staple of Unix-like operating systems since their inception in the 1970s. Its fundamental role in file system navigation has ensured its consistent presence and behavior across various Unix versions and subsequent Linux distributions. Being a shell built-in from very early on was a critical design choice to enable its functionality effectively within a user's interactive session.


title: SYNOPSIS
content:
<b>colordctl create-profile</b> [<i>OPTIONS</i>...] [<i>TYPE</i> <i>ID</i> | <b>--filename</b> <i>PATH</i>]


title: PARAMETERS
content:
<b><i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The category of the color profile (e.g., <i>display</i>, <i>printer</i>, <i>scanner</i>, <i>generic</i>). Required when creating an empty profile.<br><br><b><i>ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A unique string identifier for the new profile. Required when creating an empty profile.<br><br><b><b>--filename</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the path to an existing ICC profile file to import and register. If used, <i>TYPE</i> and <i>ID</i> are not required, as properties are read from the file.<br><br><b><b>--scope</b> <i>SCOPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the visibility of the profile. Possible values are <i>user</i> (for current user only) or <i>system</i> (for all users). Default is <i>system</i>.<br><br><b><b>--description</b> <i>TEXT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Sets a human-readable description for the profile.<br><br><b><b>--model</b> <i>TEXT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the device model associated with the profile.<br><br><b><b>--vendor</b> <i>TEXT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the device vendor associated with the profile.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays program version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>cd-create-profile</b> command name is likely a typo for <b>colordctl create-profile</b>. <br> <br> <b>colordctl create-profile</b> is a subcommand of the <b>colordctl</b> utility, which serves as the command-line interface for the <i>colord</i> system daemon. The primary purpose of this subcommand is to create and register new color profile objects within the <i>colord</i> daemon's database. It can either create a new, empty profile entry, which can be populated with ICC data later, or directly import an existing ICC (International Color Consortium) profile file during the creation process. <br> <br> This command is crucial for applications and users who need to manage custom color profiles for various devices such as displays, printers, scanners, and cameras. By registering profiles with <i>colord</i>, these profiles become available for system-wide color management, ensuring consistent color reproduction across different devices and applications. It is often used by graphical configuration tools or automation scripts rather than directly by end-users.


title: CAVEATS
content:
The command name <b>cd-create-profile</b> is highly likely a typo for <b>colordctl create-profile</b>. <br> <br> This command requires the <i>colord</i> daemon to be running and relies on D-Bus communication. <br> <br> Creating system-wide profiles (<b>--scope system</b>) typically requires elevated privileges (e.g., running with <b>sudo</b>). <br> <br> This command only registers the profile with <i>colord</i>; associating it with a specific hardware device usually requires additional <b>colordctl</b> commands, such as <b>colordctl device-add-profile</b>.


title: PROFILE STORAGE AND MANAGEMENT
content:
Profiles created or imported using <b>colordctl create-profile</b> are stored and managed by the <i>colord</i> daemon. System-wide profiles are typically located in <i>/var/lib/colord/icc/</i>, while user-specific profiles are found in <i>~/.local/share/icc/</i>. The <i>colord</i> daemon ensures proper access control and integration with the system's color management workflows.


title: EMPTY VS. IMPORTED PROFILES
content:
The flexibility to create either an empty profile or directly import an existing ICC file allows for different workflows. Empty profiles are useful when an ICC file is not immediately available but a placeholder is needed, or when a profile will be generated dynamically by another process. Importing directly is convenient for integrating pre-existing standard or custom profiles.


title: HISTORY
content:
The <i>colord</i> project, which provides color management services on Linux, was initiated around 2009. The <b>colordctl</b> utility, its primary command-line client, has been a core component since its early development. The <b>create-profile</b> subcommand has been a fundamental function within <b>colordctl</b>, allowing users and applications to programmatically add and manage color profiles, adapting over time to incorporate more features and options for comprehensive profile management.


title: SYNOPSIS
content:
<b><code>cd-fix-profile</code></b><br><i>(or often)</i><br><b><code>source</code></b> <i>path/to/</i><b><code>cd-fix-profile.sh</code></b>


title: DESCRIPTION
content:
The <b><code>cd-fix-profile</code></b> is <i>not</i> a standard, universally available Linux command or utility. Instead, its name typically refers to a custom shell script designed to diagnose and resolve issues related to the <b><code>cd</code></b> (change directory) built-in command, primarily by examining and modifying shell configuration files such as <i><code>~/.profile</code></i>, <i><code>~/.bash_profile</code></i>, <i><code>~/.bashrc</code></i>, or <i><code>~/.zshrc</code></i>.<br><br>The purpose of such a script is to address scenarios where <b><code>cd</code></b> might behave unexpectedly. This could include issues like an incorrectly set <i><code>CDPATH</code></i> environment variable, conflicting aliases or shell functions overriding the default <b><code>cd</code></b> behavior, or problems specific to environments like Windows Subsystem for Linux (WSL) where path handling can differ. A <b><code>cd-fix-profile</code></b> script would typically inspect these configurations, potentially correct them automatically, or provide guidance to the user on how to manually fix the perceived problem, aiming to restore the standard and expected functionality of the <b><code>cd</code></b> command.


title: CAVEATS
content:
As <b><code>cd-fix-profile</code></b> is a custom script rather than a standard command, its functionality, safety, and effectiveness are entirely dependent on its specific implementation. Users should exercise extreme caution: always review the script's contents before execution, as it has the potential to modify critical shell configuration files, which could lead to unintended system behavior or security vulnerabilities if not properly written or understood. There is no standard behavior or expected output; it varies from one script to another.


title: TYPICAL SCRIPT ACTIONS
content:
A common <b><code>cd-fix-profile</code></b> script might:<br>&#x2022; Check for and unset problematic <i><code>CDPATH</code></i> variables.<br>&#x2022; Remove or redefine custom <b><code>cd</code></b> aliases or functions.<br>&#x2022; Examine <i><code>PATH</code></i> variable issues.<br>&#x2022; Identify and correct syntax errors in sourced profile files.<br>&#x2022; Offer interactive prompts for applying fixes.<br>&#x2022; Backup existing profile files before making changes.


title: CONTEXT OF USE
content:
This type of script is most commonly found in:<br>&#x2022; Personal user directories for self-troubleshooting.<br>&#x2022; System administration toolkits for mass configuration.<br>&#x2022; Development environment setup scripts (e.g., dotfiles repositories).<br>&#x2022; Online forums or guides as a recommended solution for specific <b><code>cd</code></b>-related quirks (e.g., in WSL environments or after certain software installations).


title: HISTORY
content:
There is no formal development history for <b><code>cd-fix-profile</code></b> as it is not a standardized command. Its existence stems from the common need among Linux users and system administrators to troubleshoot and automatically correct shell configuration issues that affect the basic functionality of the <b><code>cd</code></b> command. Such scripts are typically created ad-hoc or as part of larger configuration management efforts, especially in environments where shell configurations might be complex or prone to inconsistencies, such as cross-platform development setups (e.g., WSL) or highly customized shell environments.


title: SYNOPSIS
content:
`<b>cdecl</b>` [`-a`] [`-p`] [`<i>expression</i>`]<br>When `<i>expression</i>` is omitted, `<b>cdecl</b>` enters interactive mode.


title: PARAMETERS
content:
<b>`<b>-a</b>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Produce Arabic numerals for array sizes instead of English words (e.g., `[10]` instead of `ten`).</i><br><br><b>`<b>-p</b>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable pedantic mode, insisting on `int` for integer types, as required by Kernighan and Ritchie's C standard.</i><br><br><b>`<i>expression</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>A C declaration or an English description to be translated. If provided, `<b>cdecl</b>` operates non-interactively; otherwise, it enters interactive mode.</i><br><br>


title: DESCRIPTION
content:
`<b>cdecl</b>` is a command-line utility designed to assist C programmers in understanding and constructing complex C declarations. It acts as a bidirectional translator: it can take a C declaration and render it in plain English, or conversely, take an English description of a type and generate the corresponding C declaration.<br><br>This functionality is particularly useful for deciphering intricate pointer, array, and function pointer declarations, which are often sources of confusion for C developers. When invoked without arguments, `<b>cdecl</b>` enters an interactive mode, allowing users to repeatedly input declarations or descriptions. It supports commands like `<b>declare</b>` (C to English), `<b>cast</b>` (English to C), and `<b>explain</b>` (C expression to English). Its ability to clarify ambiguous or convoluted syntax makes it an invaluable tool for both learning C and debugging declaration errors.


title: CAVEATS
content:
<i>`<b>cdecl</b>` may sometimes parse overly complex or ambiguous C declarations incorrectly due to inherent ambiguities in C's syntax. It focuses primarily on declarations and does not fully understand all C syntax constructs, preprocessor directives, or compiler-specific extensions. Its utility is primarily for understanding core C declaration syntax.</i>


title: INTERACTIVE MODE COMMANDS
content:
<i>When run without an `<i>expression</i>`, `<b>cdecl</b>` enters an interactive shell. Within this mode, users can issue specific commands:<br><br>`<b>declare</b> <i><C_declaration></i>`: Translates a C declaration into English.<br>`<b>cast</b> <i><English_description></i>`: Translates an English description into a C declaration.<br>`<b>explain</b> <i><C_expression></i>`: Provides an English explanation for a C expression.<br>`<b>help</b>`: Displays information about interactive commands.<br>`<b>quit</b>`: Exits the interactive mode.</i>


title: HISTORY
content:
<i>The `<b>cdecl</b>` utility has roots in the early days of C programming, designed to address the inherent complexity of C's declaration syntax. The original version was developed by David Anderson, with significant enhancements later contributed by Tony L. Hansen. It emerged as a practical tool for programmers grappling with pointers, arrays, and function pointers, becoming a classic utility for C development environments on Unix-like systems. Its design reflects a focus on clarity and education, aiming to demystify one of C's more challenging aspects.</i>


title: SEE ALSO
content:
<b>gcc</b>(1): <i>The GNU C Compiler, for compiling C code that includes declarations.</i>, <b>cpp</b>(1): <i>The C Preprocessor, which handles directives before compilation.</i>, <b>indent</b>(1): <i>A utility for formatting C source code, which can help in readability.</i>, <b>splint</b>(1): <i>A static analysis tool for C programs, useful for identifying potential errors and questionable code constructs.</i>


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the AWS CDK CLI and exiting.<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows verbose logging output during command execution.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output, including stack traces for errors.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emits output in JSON format, useful for programmatic consumption.<br><br><b><b>--context</b> <i>&lt;key=value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes arbitrary context values to the CDK application. Can be specified multiple times.<br><br><b><b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables strict mode, causing the CDK to fail on warnings during synthesis.<br><br><b><b>--app</b> <i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the command-line program to execute to generate the CDK application (e.g., 'npx ts-node bin/my-app.ts').<br><br><b><b>--output</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output directory for synthesized CloudFormation templates.<br><br><b><b>--no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output.<br><br>


title: DESCRIPTION
content:
The <b>cdk</b> command-line interface (CLI) is the primary tool for interacting with the <i>AWS Cloud Development Kit (CDK)</i>. It's important to note that <b>cdk</b> is not a standard, pre-installed Linux command; rather, it's a Node.js-based application typically installed via npm or yarn, primarily used for managing AWS cloud resources.<br><br>The AWS CDK is a software development framework for defining your cloud application resources using familiar programming languages. It synthesizes a <i>CloudFormation</i> template, which AWS CloudFormation then deploys. The <b>cdk</b> CLI allows developers to synthesize, deploy, diff, and destroy cloud infrastructure stacks defined in languages like TypeScript, Python, Java, C#, and Go.<br><br>It enables developers to use high-level constructs, which are pre-built, reusable components that encapsulate AWS best practices. This approach significantly speeds up cloud infrastructure development, making it more manageable and less prone to errors compared to writing raw CloudFormation templates.


title: CAVEATS
content:
The <b>cdk</b> command is not part of the standard Linux utility set. It requires <i>Node.js</i> and <i>npm</i> (or <i>yarn</i>) to be installed on the system to be used. It is primarily designed for interacting with <i>AWS cloud resources</i> and requires valid AWS credentials and an AWS account to deploy infrastructure. While a powerful tool for infrastructure as code, its utility is limited to AWS and ecosystems that integrate with AWS CloudFormation.


title: COMMON COMMANDS
content:
Beyond the global options, the <b>cdk</b> CLI provides several subcommands for different operations:<br><ul><li><b>cdk synth</b>: Synthesizes the CDK application into a CloudFormation template.</li><li><b>cdk deploy</b> <i>[stack-name]</i>: Deploys a specified stack (or all stacks) to your AWS account.</li><li><b>cdk diff</b> <i>[stack-name]</i>: Compares the deployed stack with the current local definition.</li><li><b>cdk destroy</b> <i>[stack-name]</i>: Destroys a specified stack and its resources.</li><li><b>cdk bootstrap</b>: Deploys the CDK Toolkit staging resources (e.g., S3 bucket, IAM roles) into an AWS environment.</li><li><b>cdk ls</b>: Lists all stacks defined in your CDK application.</li><li><b>cdk init</b>: Initializes a new CDK project from a template.</li></ul>


title: INSTALLATION
content:
The <b>cdk</b> CLI is typically installed globally using <i>npm</i> (Node Package Manager) or <i>yarn</i>:<br><i><pre>npm install -g aws-cdk</pre></i><br>or<br><i><pre>yarn global add aws-cdk</pre></i><br>This makes the <b>cdk</b> command available in your system's PATH.


title: HISTORY
content:
The AWS Cloud Development Kit (CDK) was initially launched as a developer preview in July 2018 and became generally available in <i>July 2019</i>. Developed by Amazon Web Services, it quickly gained traction in the infrastructure as code (IaC) space by allowing developers to define cloud resources using general-purpose programming languages. Its development aimed to address the complexities of managing cloud infrastructure through declarative templates, offering a more programmatic and object-oriented approach. It has seen continuous development and new features added with regular releases, becoming a key tool for many AWS users.


title: SEE ALSO
content:
aws(1) - AWS Command Line Interface, npm(1) - Node.js package manager, yarn(1) - JavaScript package manager, terraform(1) - HashiCorp Terraform CLI (another IaC tool)


title: SYNOPSIS
content:
<b>cdrdao</b> <i>&lt;command&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><br>Common commands include:<br><b>cdrdao read-toc</b> [<i>options</i>] <i>&lt;toc-file&gt;</i><br><b>cdrdao write</b> [<i>options</i>] <i>&lt;toc-file&gt;</i><br><b>cdrdao simulate</b> [<i>options</i>] <i>&lt;toc-file&gt;</i><br><b>cdrdao read-cd</b> [<i>options</i>] <i>&lt;image-file&gt;</i>


title: PARAMETERS
content:
<b><b>--device</b> <i>&lt;bus,id,lun&gt;</i> | <i>&lt;/dev/sgX&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the SCSI CD/DVD burner device to use. For example, <i>0,0,0</i> or <i>/dev/sg0</i>.<br><br><b><b>--speed</b> <i>&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the recording speed. Use <i>0</i> for maximum speed.<br><br><b><b>--driver</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the CD-R/RW device driver to use (e.g., <i>generic-scsi</i>, <i>ricoh-mp6200</i>). Automatically detected in most cases.<br><br><b><b>--buffers</b> <i>&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of buffers to use for writing data. Higher values can improve performance.<br><br><b><b>--eject</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ejects the disc from the drive after a successful operation.<br><br><b><b>--blank</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Blanks a rewritable disc. <i>&lt;type&gt;</i> can be <i>full</i> or <i>fast</i>.<br><br><b><b>--cuefile</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an input CUE sheet file for reading or writing, an alternative to a TOC file.<br><br><b><b>--read-raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When reading, reads raw disc data including subchannel information.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an operation that might otherwise be prevented (e.g., overwriting files).<br><br>


title: DESCRIPTION
content:
<i>cdrdao</i> is a powerful command-line utility for writing CD-R/RW discs using the Disc-At-Once (DAO) recording method. This mode writes the entire CD in a single continuous session, providing superior control over the disc's structure compared to Track-At-Once (TAO) recording. DAO allows for the creation of truly gapless audio tracks, precise placement of indices, and the inclusion of subcode information like ISRC and CD-TEXT. It operates by reading a <b>TOC</b> (Table Of Contents) file, which precisely defines the disc's layout, including track types, start/end points, and pre-gaps, and a corresponding <b>BIN</b> (binary image) file containing the actual raw data for all tracks. This makes <i>cdrdao</i> an indispensable tool for creating Red Book compliant audio CDs, exact duplicates of existing discs, or complex bootable CDs where precise layout and subcode control are critical.


title: CAVEATS
content:
<i>cdrdao</i> typically requires direct access to the SCSI generic (sg) device, which may require root privileges or proper udev rules. Its reliance on the <b>TOC/BIN</b> file format can have a learning curve compared to simpler burning tools. Support for specific drives and features may vary, and modern drives might not fully expose all DAO capabilities as older ones did. It is less actively developed than some other burning utilities.


title: HISTORY
content:
Developed to fill a gap in Linux CD burning tools, <i>cdrdao</i> provided robust Disc-At-Once (DAO) recording, which was crucial for creating precise audio CDs and exact disc copies. It became a preferred tool for audio mastering and archival due to its ability to handle gapless tracks and subcode data accurately, a feature often lacking or limited in other available tools of its time (like <i>cdrecord</i> which focused on Track-At-Once).


title: SYNOPSIS
content:
<br><B>ceph</B> [<i>global-options</i>] &lt;<i>subcommand</i>&gt; [<i>subcommand-options</i>] [<i>arguments</i>]<br><br>Common invocations include:<br><B>ceph</B> <I>status</I><br><B>ceph</B> <I>health</I><br><B>ceph</B> <I>osd</I> <I>tree</I><br><B>ceph</B> <I>pg</I> <I>dump</I><br><B>ceph</B> <I>auth</I> <I>ls</I>


title: PARAMETERS
content:
<b><i>global-options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options that apply to the <B>ceph</B> command itself, influencing connection, output format, or debug level.<br><br><b><B>--cluster</B> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Ceph cluster name to connect to (default is 'ceph').<br><br><b><B>--conf</B> <I>&lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an alternative path to the Ceph configuration file (<I>ceph.conf</I>).<br><br><b><B>--name</B> <I>&lt;user&gt;</I>, <B>--id</B> <I>&lt;user&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user ID (e.g., <I>client.admin</I>) for authentication.<br><br><b><B>--keyring</B> <I>&lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the keyring file containing authentication keys.<br><br><b><B>--format</B> <I>&lt;format&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format (e.g., <I>json</I>, <I>yaml</I>, <I>plain</I>). Useful for scripting.<br><br><b><B>--pretty</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty-prints JSON or XML output for better human readability.<br><br><b>&lt;<i>subcommand</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The core operation to perform (e.g., <I>status</I>, <I>health</I>, <I>osd</I>, <I>pool</I>, <I>auth</I>). Each subcommand has its own set of specific options and arguments.<br><br><b><i>subcommand-options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Options specific to the chosen &lt;<i>subcommand</i>&gt;.<br><br><b><i>arguments</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional positional arguments required by the &lt;<i>subcommand</i>&gt;.<br><br>


title: DESCRIPTION
content:
The <B>ceph</B> command is the primary command-line interface (CLI) for administering and interacting with a Ceph distributed storage cluster. It allows administrators to query cluster status, manage storage pools, and control various Ceph services such as OSDs (Object Storage Daemons), MONs (Monitors), MDSs (Metadata Servers), and MGRs (Managers). It provides comprehensive insights into cluster health, performance metrics, and configuration settings. Through its rich set of subcommands, <B>ceph</B> enables essential tasks like creating and deleting pools, managing authentication keys, adjusting configuration parameters, monitoring placement groups (PGs), and initiating data scrub operations. It is an indispensable tool for daily operations, troubleshooting, and scaling Ceph deployments.


title: CAVEATS
content:
Requires proper authentication (e.g., a keyring file with sufficient permissions) to connect to the Ceph cluster.<br>Many commands, especially those modifying cluster state, require administrative privileges.<br>Incorrect use of certain commands (e.g., <B>osd rm</B>, <B>pool delete</B>) can lead to data loss or cluster instability. Always understand the command's impact before execution.<br>Network connectivity to Ceph monitors is essential for the <B>ceph</B> CLI to function.


title: MANAGER MODULES
content:
The <B>ceph</B> command provides interfaces to various <I>ceph-mgr</I> modules, enabling features like dashboards (<B>ceph dashboard</B>), telemetry (<B>ceph telemetry</B>), and Prometheus exports (<B>ceph prometheus</B>). These modules extend the management capabilities without requiring new binary installations.


title: OUTPUT FORMATS
content:
The <B>--format</B> option is crucial for scripting and automation, allowing the output to be parsed programmatically in <I>json</I>, <I>yaml</I>, or <I>xml</I> formats, rather than human-readable <I>plain</I> text. The <B>--pretty</B> option further enhances readability for <I>json</I> and <I>xml</I>.


title: HISTORY
content:
The <B>ceph</B> command is an integral part of the Ceph project, which began development by Sage Weil in 2004 as part of his PhD dissertation. It was open-sourced in 2007. The <B>ceph</B> CLI has evolved alongside the cluster itself, incorporating new subcommands and functionalities with each major release (e.g., Mimic, Nautilus, Octopus, Pacific, Quincy, Reef), reflecting the growing complexity and capabilities of the Ceph storage platform. It is continuously maintained and improved by the vibrant open-source community.


title: SYNOPSIS
content:
<b>certbot</b> [<i>SUBCOMMAND</i>] [<i>options</i>]<br><br><i>Common Subcommands</i>:<br>&nbsp;&nbsp;&nbsp;<b>run</b><br>&nbsp;&nbsp;&nbsp;<b>certonly</b><br>&nbsp;&nbsp;&nbsp;<b>renew</b><br>&nbsp;&nbsp;&nbsp;<b>revoke</b><br>&nbsp;&nbsp;&nbsp;<b>delete</b><br>&nbsp;&nbsp;&nbsp;<b>certificates</b><br>&nbsp;&nbsp;&nbsp;<b>register</b>


title: PARAMETERS
content:
<b>run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Obtain and install a new certificate.</I><br><br><b>certonly</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Obtain a certificate without installing it.</I><br><br><b>renew</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Renew all installed certificates that are due for renewal.</I><br><br><b>revoke</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Revoke a previously issued certificate.</I><br><br><b>delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Delete a certificate and its configuration.</I><br><br><b>certificates</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>List all certificates managed by Certbot.</I><br><br><b>register</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Register a new account with Let's Encrypt.</I><br><br><b>-d DOMAIN</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify a domain name for which to obtain a certificate. Can be specified multiple times.</I><br><br><b>--webroot -w PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Authenticate using the webroot method, placing files in a specified webroot directory.</I><br><br><b>--apache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use the Apache plugin for authentication and installation.</I><br><br><b>--nginx</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use the Nginx plugin for authentication and installation.</I><br><br><b>--standalone</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Run a standalone web server for authentication. Requires port 80/443 to be free.</I><br><br><b>--dns-PLUGIN</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use a specific DNS plugin (e.g., --dns-cloudflare, --dns-route53) for DNS-01 authentication.</I><br><br><b>--email EMAIL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Email address for urgent notices and account recovery.</I><br><br><b>--agree-tos</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Automatically agree to the Let's Encrypt Terms of Service.</I><br><br><b>--force-renewal</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force renewal of a certificate even if it's not yet due.</I><br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Perform a test run without making any changes to the system or requesting real certificates.</I><br><br><b>--non-interactive -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Run Certbot non-interactively, suitable for scripting.</I><br><br>


title: DESCRIPTION
content:
Certbot is a free, open-source software tool developed by the Electronic Frontier Foundation (EFF). Its primary purpose is to automate the process of obtaining, installing, and renewing SSL/TLS certificates from Let's Encrypt, a free, automated, and open certificate authority. <br><br>Certbot simplifies the traditionally complex task of securing websites with HTTPS. It handles various aspects, including: <br><I>Domain Validation</I>: It can automatically prove control of your domain to Let's Encrypt using methods like HTTP-01 (by serving a specific file) or DNS-01 (by creating a specific DNS record). <br><I>Certificate Issuance</I>: Once validated, Certbot requests and receives the SSL/TLS certificate. <br><I>Installation</I>: For supported web servers like Apache and Nginx, Certbot can automatically configure the server to use the new certificate, enabling HTTPS. <br><I>Automated Renewal</I>: Let's Encrypt certificates are short-lived (90 days), requiring frequent renewal. Certbot excels here by automating renewals, often through cron jobs or systemd timers, ensuring continuous HTTPS availability without manual intervention. <br><br>By abstracting away much of the complexity, Certbot has played a pivotal role in the widespread adoption of HTTPS, making secure communication accessible to a vast number of websites and users globally.


title: CAVEATS
content:
<I>Root Privileges</I>: Certbot typically requires root or sudo privileges to perform operations like writing to system directories, configuring web servers, or binding to privileged ports (80/443).<br><I>Network Connectivity</I>: The server running Certbot must have outbound network access to Let's Encrypt's API servers. For HTTP-01 challenges, incoming connections on port 80 or 443 must be allowed. For DNS-01, DNS resolution must be functional.<br><I>Web Server Configuration</I>: While Certbot's plugins are robust, highly customized web server configurations might sometimes require manual adjustments post-installation.<br><I>Wildcard Certificates</I>: Obtaining wildcard certificates (*.example.com) specifically requires the DNS-01 authentication method.


title: AUTOMATED RENEWAL MECHANISM
content:
Certbot certificates have a 90-day validity period. To ensure continuous HTTPS availability, Certbot is designed to be run periodically (e.g., daily or twice a day) via a cron job or systemd timer. The <I>certbot renew</I> command checks if any certificates are due for renewal (typically when they are within 30 days of expiry) and renews them automatically, reloading the web server if necessary.


title: PLUGIN ARCHITECTURE
content:
Certbot utilizes a plugin-based architecture to support various web servers and authentication methods. This allows it to interact seamlessly with different environments. Examples include installer plugins like <I>--apache</I> and <I>--nginx</I> that handle both authentication and configuration, and authenticator plugins like <I>--webroot</I> or <I>--standalone</I> for challenge validation, or specific DNS plugins for the DNS-01 challenge.


title: HISTORY
content:
Certbot's origins trace back to the <I>Let's Encrypt client</I>, an initiative by the Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, and others, launched with the goal of encrypting the entire web. The initial client, released in beta in 2015, was designed to simplify obtaining certificates from the nascent Let's Encrypt certificate authority. <br><br>In 2016, the project was officially renamed to <I>Certbot</I> to reflect its capability to manage certificates more broadly, though its primary use remains with Let's Encrypt. This renaming also aimed to distinguish the client from the Let's Encrypt CA itself. Since its inception, Certbot has been instrumental in driving the widespread adoption of HTTPS, making secure communication a standard rather than an exception on the internet. It continues to be actively developed and maintained by the EFF.


title: PARAMETERS
content:
<b>-d, --depth &lt;num&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the depth to crawl beyond the initial URL. Default is 2.<br><br><b>-m, --min_length &lt;num&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum length a word must have to be included in the list. Default is 3.<br><br><b>-o, --offsite</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows <i>cewl</i> to follow offsite links during crawling. By default, it stays on the initial domain.<br><br><b>-w, --write &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated word list to the specified file instead of standard output.<br><br><b>-u, --ua &lt;agent&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the User-Agent string to be used for HTTP requests, useful for bypassing some WAFs or for stealth.<br><br><b>-H, --auth_header &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an additional HTTP authentication header (e.g., for Basic Auth, Bearer tokens).<br><br><b>--data &lt;string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends POST data with requests, useful for crawling sites that require form submissions.<br><br><b>--no-elements</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes words found within HTML element tags (e.g., <i>&lt;div&gt;</i>, <i>&lt;span&gt;</i>).<br><br><b>--lowercase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts all extracted words to lowercase.<br><br><b>--count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the count of each unique word found, useful for statistical analysis.<br><br><b>--exclude &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a file containing words to exclude from the final word list.<br><br><b>--meta</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts words from document metadata (e.g., PDF, DOC files) found on the site.<br><br><b>--email</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts and lists email addresses found on the target website.<br><br><b>--proxy &lt;host:port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Routes HTTP requests through a specified proxy server.<br><br><b>--ssl-no-verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables SSL certificate verification, useful for sites with self-signed certificates or for local proxying.<br><br><b>--timeout &lt;num&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the connection timeout in seconds.<br><br>


title: DESCRIPTION
content:
<i>cewl</i> (Custom Word List) is a Ruby-based command-line tool designed to create custom word lists by crawling target URLs. It extracts unique words from the HTML content of the specified website and its sub-pages (up to a defined depth). These generated word lists are commonly used in penetration testing, particularly for dictionary attacks against password-protected systems, where the assumption is that users might use words related to their organization or website content as passwords. It can also extract email addresses and metadata from documents found on the site, further enriching potential attack vectors.


title: CAVEATS
content:
Using <i>cewl</i> for unauthorized access to systems or data is illegal and unethical. It should only be used on systems where explicit permission has been granted, or for personal educational purposes on your own controlled environments. Be mindful of the load you place on target servers, as extensive crawling can be mistaken for a denial-of-service attack.


title: ETHICAL CONSIDERATIONS
content:
Always obtain explicit written permission before using <i>cewl</i> against any third-party website or system. Unauthorized use can lead to legal consequences. It is a powerful reconnaissance tool that can be misused for malicious purposes.


title: TYPICAL WORKFLOW
content:
A common workflow involves using <i>cewl</i> to generate a custom wordlist from a target's public-facing website. This wordlist is then fed into password cracking tools like <i>John the Ripper</i> or <i>Hashcat</i> to attempt to brute-force credentials on services like SSH, FTP, or web logins. The idea is that employees might use easily guessable passwords derived from company-specific terms.


title: HISTORY
content:
<i>cewl</i> was originally developed by Robin Wood (digininja) as a Ruby script. It gained popularity within the penetration testing community for its simple yet effective approach to generating context-specific wordlists. It's often included in penetration testing distributions like Kali Linux, highlighting its utility in the security domain. Its development has focused on enhancing crawling capabilities, parsing options, and network handling.


title: SYNOPSIS
content:
<br><b><I>cf [global-options] COMMAND [arguments] [command-options]</I></b><br><br>This synopsis illustrates the general structure. The <b><I>cf</I></b> command is followed by optional <b><I>global-options</I></b> that affect the CLI's behavior across all commands. A specific <b><I>COMMAND</I></b> (e.g., <b><I>login</I></b>, <b><I>push</I></b>, <b><I>apps</I></b>) is then invoked, often accompanied by <b><I>arguments</I></b> (like an application name or service name) and <b><I>command-options</I></b> specific to that particular command.


title: PARAMETERS
content:
<b><b><I>--version, -v</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the CLI version.<br><br><b><b><I>--help, -h</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help for the global CLI or a specific command.<br><br><b><b><I>--trace, -t</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows API request and response details for debugging.<br><br><b><b><I>--debug</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging, including API details and command execution flow.<br><br>


title: DESCRIPTION
content:
The <b><I>cf</I></b> command is the Cloud Foundry Command Line Interface (CLI), an essential tool for interacting with Cloud Foundry instances. Cloud Foundry is an open-source, multi-cloud Application Platform as a Service (PaaS) that enables developers to build, deploy, run, and scale applications without managing underlying infrastructure. The <b><I>cf</I></b> CLI provides a unified interface to perform various operations, including deploying applications from source code or Docker images, managing service instances (databases, message queues, etc.), binding services to applications, scaling applications, viewing logs, managing organizations and spaces, and handling user permissions. It acts as the primary user interface to a Cloud Foundry deployment, abstracting complex cloud operations into simple, developer-centric commands. While not a core utility included in typical Linux distributions, it is widely used by developers working with Cloud Foundry environments and is installed on Linux systems.


title: CAVEATS
content:
<br>The <b><I>cf</I></b> command is not a standard utility included with most Linux distributions; it must be installed separately. It requires a Cloud Foundry instance (e.g., Cloud.gov, IBM Cloud, SAP BTP, or a self-hosted BOSH deployment) to connect and function. Successful operation depends on proper authentication (using <b><I>cf login</I></b>) and continuous network connectivity to the Cloud Foundry API endpoint. The command's functionality is entirely dependent on the availability and configuration of the targeted Cloud Foundry environment.


title: COMMON COMMANDS
content:
While <b><I>cf</I></b> offers numerous commands, some are used frequently: <br> <b><I>cf login</I></b>: Authenticates the CLI with a Cloud Foundry instance.<br> <b><I>cf push</I></b>: Deploys an application to Cloud Foundry.<br> <b><I>cf apps</I></b>: Lists deployed applications.<br> <b><I>cf services</I></b>: Lists provisioned service instances.<br> <b><I>cf logs</I></b>: Streams application logs in real-time.


title: INSTALLATION
content:
The <b><I>cf</I></b> CLI can be installed on Linux via various methods, including package managers (e.g., <b><I>apt</I></b>, <b><I>yum</I></b>), direct download of binaries from the Cloud Foundry releases page, or using <b><I>go get</I></b> if Go is installed. This makes it easily accessible across different Linux distributions.


title: HISTORY
content:
<br>Cloud Foundry was initially developed by VMware and released as open source in April 2011. Pivotal Software (spun out from EMC/VMware) became the primary commercial entity behind its development. The <b><I>cf</I></b> CLI has evolved significantly since its inception, continually adding new features and improving user experience to keep pace with the Cloud Foundry platform's capabilities. In 2015, Cloud Foundry became a Linux Foundation project, fostering broader community collaboration. The CLI is actively maintained, with frequent updates to support new Cloud Foundry features, security patches, and compatibility across various operating systems, reflecting its central role in interacting with the PaaS environment.


title: SEE ALSO
content:
ssh(1) - For direct shell access to application instances via <b><I>cf ssh</I></b>., curl(1) - Represents the underlying HTTP/S communication with the Cloud Foundry API., git(1) - Often used for managing source code that is then pushed to Cloud Foundry., docker - (No man section) For building and managing container images, which <b><I>cf</I></b> can deploy., kubectl - (No man section) For managing Kubernetes, a common alternative/complementary container orchestration platform.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits the program.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs version information and exits.<br><br><b><b>-Z</b>, <b>--zero</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fills the partition table with zeros, effectively destroying all existing partition information. Use with extreme caution as this will lead to data loss.<br><br><b><b>-L</b>, <b>--color</b>[=<i>WHEN</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Colorizes the output. <i>WHEN</i> can be 'always', 'auto', or 'never'.<br><br><b><b>-t</b>, <b>--type</b> <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the partition table type to use (e.g., 'dos' for MBR, 'gpt' for GUID Partition Table, 'sgi', 'sun', 'mac', 'bsd').<br><br><b><b>-s</b>, <b>--specify</b> <i>DISK_SIZE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the disk size in bytes. Useful for loop devices or when the size cannot be automatically detected.<br><br>


title: DESCRIPTION
content:
<i>cfdisk</i> is a powerful utility used for manipulating disk partition tables in a user-friendly, menu-driven interface. Unlike its command-line counterpart <i>fdisk</i>, <i>cfdisk</i> leverages the <br>curses library to provide a visual, interactive experience, making partition management more intuitive for many users. <br><br>It allows system administrators and users to create, delete, resize, and modify partitions on block devices (like hard drives or SSDs). <i>cfdisk</i> primarily supports MBR (DOS) and GPT (GUID Partition Table) partitioning schemes, automatically detecting the existing type or allowing the user to specify it. Changes made within <i>cfdisk</i> are not written to the disk immediately; they are staged and only applied when the user explicitly chooses the 'Write' option, providing a safety net against accidental modifications. <br><br>While <i>cfdisk</i> excels at managing partition table entries, it does not format partitions or manage file systems directly. Users must use separate tools like <i>mkfs</i> to create file systems after partitioning and <i>resize2fs</i> (for extN file systems) if they need to resize existing file systems. Access to <i>cfdisk</i> requires root privileges due to its direct interaction with disk devices.


title: CAVEATS
content:
Using <i>cfdisk</i> incorrectly can lead to severe data loss. Always back up important data before making any changes to disk partitions.<br><br>Changes are committed to disk only when you explicitly select the 'Write' option from the interactive menu. Until then, changes are temporary and in-memory.<br><br><i>cfdisk</i> operates on raw disk devices, not individual partitions. Ensure that any partitions on the target device are unmounted before proceeding.<br><br>While <i>cfdisk</i> can create/delete/resize partition table entries, it does not manage file systems. Resizing a partition often requires separate file system utilities (e.g., <i>resize2fs</i>) to adjust the file system to the new partition size. Failure to do so can lead to data corruption or inaccessible partitions.


title: INTERACTIVE INTERFACE
content:
Upon launching <i>cfdisk</i> with a device (e.g., <i>cfdisk /dev/sda</i>), it presents a full-screen, menu-driven interface. Users navigate using arrow keys (Up/Down for partitions, Left/Right for menu options) and press Enter to select. Common actions include:<br><br><b>New</b>: Create a new partition.<br><b>Delete</b>: Remove an existing partition.<br><b>Resize</b>: Change the size of a partition.<br><b>Type</b>: Change the partition type ID.<br><b>Bootable</b>: Toggle the bootable flag for MBR partitions.<br><b>Write</b>: Commit all pending changes to the disk (<i>critical step!</i>).<br><b>Quit</b>: Exit <i>cfdisk</i> without saving changes (if 'Write' wasn't used).<br><br>The interface provides immediate visual feedback on partition layout and available disk space.


title: PARTITION TABLE SUPPORT
content:
<i>cfdisk</i> primarily supports two widely used partition table types:<br><br><b>MBR (Master Boot Record) / DOS</b>: The older, traditional partitioning scheme, commonly used on disks up to 2TB. It supports up to four primary partitions, or three primary and one extended partition containing logical partitions.<br><br><b>GPT (GUID Partition Table)</b>: A newer, more robust partitioning scheme, designed for larger disks (beyond 2TB) and supporting virtually unlimited partitions. GPT is increasingly common on modern systems.<br><br><i>cfdisk</i> usually auto-detects the partition table type, but the <i>--type</i> option allows explicit selection.


title: HISTORY
content:
<i>cfdisk</i> is part of the <i>util-linux</i> project, a collection of essential system utilities for Linux. It was developed as a more user-friendly alternative to the traditional <i>fdisk</i> command, specifically designed to leverage the ncurses library for an interactive, pseudo-graphical interface. This approach made partition management less prone to syntax errors and more accessible to users. Its development has focused on providing a stable and robust tool for fundamental disk partitioning tasks across various Linux distributions.


title: SYNOPSIS
content:
The functionality typically associated with 'cfscores' is accessed through the <B>cf-hub</B> command with its <B>--scores</B> option.<br><br><B>cf-hub</B> [<I>options</I>] <B>--scores</B> [<I>score_options</I>]<br><br>While not a direct command, this syntax represents how CFEngine compliance scores are queried on the policy server.


title: PARAMETERS
content:
<b>--scores</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Triggers the display of policy compliance scores.<br><br><b>--host <hostname_pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters scores to display for hosts matching the specified pattern.<br><br><b>--policy <policy_name_pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters scores based on policy names matching the specified pattern.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the score data in JSON format for programmatic parsing.<br><br><b>--summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays an aggregated summary of policy scores across all managed hosts.<br><br><b>--list-host-scores</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a detailed list of individual host scores, including all policy scores.<br><br><b>--limit <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the number of hosts or entries displayed in the score output.<br><br><b>--body <body_name_pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters scores for policies containing a specific body name pattern.<br><br><b>--tag <tag_name_pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters scores based on host tags matching the specified pattern.<br><br>


title: DESCRIPTION
content:
The <b>cfscores</b> command is not a standard, standalone Linux utility. It most commonly refers to the concept of policy compliance scores within the <I>CFEngine</I> automation and configuration management system. In <I>CFEngine 3</I> and later versions, these scores quantify how well a host adheres to defined policies, rules, and desired states. They provide an aggregated view of compliance, helping administrators identify non-compliant systems or policy violations.<br><br>While a direct `cfscores` executable does not typically exist, the functionality to view these scores is integrated into <I>CFEngine</I> tools, notably via options like <B>cf-hub --scores</B> on the policy server or through the <I>CFEngine Mission Portal</I>. The scores are derived from policy evaluations performed by <B>cf-agent</B> on client hosts and aggregated by <B>cf-hub</B> on the policy server, offering crucial insights into the overall health and security posture of the managed infrastructure.


title: CAVEATS
content:
The term 'cfscores' does not refer to a standalone executable on most Linux systems. Its functionality is exclusively provided as part of the <I>CFEngine</I> configuration management suite, primarily through the <B>cf-hub</B> utility. Therefore, its availability and behavior are entirely dependent on a <I>CFEngine</I> installation and its version. Users not running <I>CFEngine</I> will not have access to 'cfscores' functionality. Custom scripts might use 'cfscores' as a conceptual name, but these are not part of a standard distribution.


title: HOW CFENGINE SCORES ARE CALCULATED
content:
CFEngine policy scores are calculated based on the outcomes of policy promises on each client host. For each promise, <B>cf-agent</B> reports a status (e.g., kept, repaired, failed, not_applicable, etc.). These statuses are aggregated by <B>cf-hub</B> on the policy server. Scores are often presented as percentages, indicating the proportion of promises kept or the level of deviation from the desired state. High scores (e.g., 100%) indicate full compliance, while lower scores highlight areas requiring attention or remediation.


title: INTEGRATION WITH MISSION PORTAL
content:
While <B>cf-hub --scores</B> provides command-line access, the <I>CFEngine Mission Portal</I> offers a comprehensive graphical interface for visualizing policy compliance scores. It provides dashboards, historical trends, and drill-down capabilities, making it easier for administrators to monitor the compliance posture of their entire infrastructure, identify top non-compliant hosts or policies, and generate reports.


title: HISTORY
content:
The concept of policy compliance scores was introduced and refined within <I>CFEngine 3</I>, specifically designed to provide quantitative metrics on the state of managed infrastructure. This feature was developed to help organizations maintain continuous compliance, identify deviations from desired states, and provide an objective measure of their configuration management effectiveness. The integration of score reporting into <B>cf-hub</B> (the CFEngine policy server) became a key component for both command-line and graphical reporting (via the <I>CFEngine Mission Portal</I>), evolving with subsequent CFEngine releases to offer more detailed insights and reporting options.


title: SYNOPSIS
content:
<b>cgclassify</b> -g <I>controller_list</I>:<I>path</I> [-g <I>controller_list</I>:<I>path</I> ...] <I>pid</I>...<br><b>cgclassify</b> [-h|--help] [-v|--version]


title: PARAMETERS
content:
<b>-g <controller_list>:<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target control group(s) for the tasks. <I>controller_list</I> is a comma-separated list of cgroup subsystems (e.g., <i>cpu,memory</i>). <I>path</I> is the absolute path to the cgroup directory within the cgroup filesystem hierarchy.<br><br><b><pid>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more process IDs (PIDs) or thread IDs (TIDs) to move into the specified cgroup(s). These are the tasks whose resource assignments will be changed.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<i>cgclassify</i> is a utility from the <b>libcgroup</b> tools that allows an administrator or authorized user to dynamically move running processes or threads into specified control groups (cgroups). This command is crucial for real-time resource management, as cgroups are a Linux kernel feature for organizing processes hierarchically and allocating system resources (like CPU, memory, I/O, network) among them.<br><br>By moving a task into a different cgroup, its resource constraints and accounting immediately change according to the rules defined for that target cgroup. It operates by writing the process ID (PID) or thread ID (TID) to the <i>tasks</i> or <i>cgroup.procs</i> file within the target cgroup's subsystem directory in the cgroup virtual filesystem. This enables administrators to rebalance workloads or adjust resource allocations on the fly without restarting applications.


title: CAVEATS
content:
Permissions: Requires root privileges or the <i>CAP_SYS_ADMIN</i> capability to move processes between cgroups.<br>Cgroup Hierarchy: Primarily designed for Cgroup v1, which uses distinct hierarchies for different controllers. While the underlying <i>cgroup.procs</i> mechanism is shared with Cgroup v2, <i>cgclassify</i>'s direct usage patterns align with v1.<br>Cgroup Existence: The target cgroup(s) specified by the <I>-g</I> option must already exist before <i>cgclassify</i> is run (e.g., created by <i>cgcreate</i> or manually).<br>Inheritance: Moving a process does not automatically move its future child processes. For persistent assignments, Cgroup rules managed by <i>cgrulesengd</i> are often used.


title: COMMON USE CASES
content:
Dynamically re-prioritizing a running batch job by moving it to a cgroup with lower CPU or I/O priority.<br>Adjusting resource limits for a critical service on the fly without requiring a service restart.<br>Correcting processes that accidentally started in the wrong cgroup.<br>Debugging and testing cgroup configurations by manually assigning processes and observing their behavior under new resource constraints.


title: PREREQUISITES
content:
The cgroup filesystem must be mounted (typically at <i>/sys/fs/cgroup</i>).<br>The necessary cgroup subsystems (e.g., cpu, memory) must be enabled and mounted within the cgroup hierarchy.<br>User must have sufficient permissions (root or <i>CAP_SYS_ADMIN</i>) to modify cgroup assignments.


title: HISTORY
content:
<i>cgclassify</i> is an integral part of the <b>libcgroup</b> tools suite, which was developed alongside the introduction of the cgroups (control groups) feature in the Linux kernel (version 2.6.24). It has served as a fundamental utility for administrators to dynamically manage and reassign tasks to specific resource groups, adapting with the evolving capabilities of the cgroups subsystem over time.


title: SYNOPSIS
content:
<b>cgcreate</b> <br><i>[ -a <user>:<group> ]</i> <br><i>[ -t <task_user>:<task_group> ]</i> <br><b>-g</b> <i><controllers>:<path></i>


title: PARAMETERS
content:
<b><b>-g</b> <i><controllers>:<path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>This mandatory option specifies the comma-separated list of cgroup controllers (e.g., <b>cpu</b>,<b>memory</b>,<b>io</b>) that will be associated with the new cgroup, and the absolute path for the new cgroup within the cgroup hierarchy (e.g., <b>mygroup/subgroup</b>).</i><br><br><b><b>-a</b> <i><user>:<group></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the ownership (user and group) for the newly created cgroup directory in the cgroup virtual filesystem. This allows specified non-root users and groups to manage files within this cgroup's directory.</i><br><br><b><b>-t</b> <i><task_user>:<task_group></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the ownership (user and group) for the <b>tasks</b> file within the newly created cgroup directory. The <b>tasks</b> file is used to add or remove process PIDs from the cgroup. Setting its permissions allows specific users to manage process assignments to the cgroup.</i><br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a brief help message about the command's usage and options, then exits.</i><br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the version information of the <b>cgcreate</b> utility and exits.</i><br><br>


title: DESCRIPTION
content:
<b>cgcreate</b> <i>is a fundamental utility from the <b>libcgroup</b> tools package, designed to establish new control groups (cgroups) within the Linux kernel's cgroup filesystem. Cgroups provide a powerful mechanism for organizing processes hierarchically and allocating system resources such as CPU, memory, I/O, and network bandwidth among them.<br><br>By using <b>cgcreate</b>, administrators can define a new resource management boundary where specific limits, priorities, or isolations can be applied to a collection of processes. The command requires specifying the desired controllers (e.g., <b>cpu</b>, <b>memory</b>, <b>io</b>) that will govern the cgroup, along with its unique path within the cgroup hierarchy. This is an essential first step in setting up granular resource isolation for applications, services, or containers on a Linux system.<br><br>Under the hood, <b>cgcreate</b> operates by creating directories and files in the cgroup virtual filesystem (typically mounted at <b>/sys/fs/cgroup</b>), which reflects the cgroup's structure and allows resource parameters to be configured and monitored. It also offers options to set permissions for the newly created cgroup directory and its <b>tasks</b> file, enabling non-root users to manage processes within specific cgroups.</i>


title: CAVEATS
content:
<b>Permissions:</b> <i>Typically, <b>cgcreate</b> requires root privileges to operate, as it directly manipulates kernel-level resources and the cgroup filesystem. While <b>-a</b> and <b>-t</b> allow setting permissions for sub-directories, the initial creation usually needs elevated access.</i><br><b>Kernel Support:</b> <i>The Linux kernel must have cgroup support enabled and the cgroup virtual filesystem must be mounted (usually at <b>/sys/fs/cgroup</b>) for <b>cgcreate</b> to function. Modern distributions usually handle this automatically.</i><br><b>Hierarchy Design:</b> <i>Careful planning is necessary when designing cgroup hierarchies to ensure proper resource isolation and avoid unintended resource starvation or conflicts between groups.</i>


title: <B>CGROUP FILESYSTEM INTERFACE</B>
content:
<i><b>cgcreate</b>'s primary action is to create new directories and special files within the mounted cgroup virtual filesystem, typically located at <b>/sys/fs/cgroup</b>. For each controller specified (e.g., <b>cpu</b>, <b>memory</b>), <b>cgcreate</b> establishes the specified path as a subdirectory. This filesystem interface is the direct, low-level way the kernel exposes cgroup functionality, where files within these directories can be read from or written to in order to configure cgroup parameters (e.g., <b>cpu.shares</b>, <b>memory.limit_in_bytes</b>).</i>


title: HISTORY
content:
<i>The concept of control groups (cgroups) was initially developed by Google engineers in 2006 (first named process containers) and was merged into the Linux kernel in 2007. The <b>libcgroup</b> tools, including <b>cgcreate</b>, were subsequently developed to provide a user-friendly interface for managing cgroups from userspace, abstracting the direct manipulation of the cgroup filesystem. These tools became widely adopted as cgroups solidified their position as a core feature for resource management in Linux distributions, container technologies (like Docker, LXC), and systemd, which uses cgroups heavily for service management.</i>


title: SEE ALSO
content:
<b>cgexec(1)</b>, <b>cgclassify(1)</b>, <b>cgset(1)</b>, <b>cgdelete(1)</b>, <b>lscgroup(1)</b>, <b>lssubsys(1)</b>, <b>cgroups(7)</b>


title: SYNOPSIS
content:
<b><I>cgexec</I></b> [<b>-g</b> <I>controllers</I>:<I>group</I>] [<b>-l</b>] [<b>-k</b>] [<b>-r</b> <I>root_path</I>] [<b>--sticky</b>] <I>command</I> [<I>arguments</I>...]<br><br><b><I>cgexec</I></b> <b>--group</b> <I>controllers</I>:<I>group</I> <I>command</I> [<I>arguments</I>...]


title: PARAMETERS
content:
<b><b>-g</b> <I>controllers</I>:<I>group</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the cgroup(s) for the command. <I>controllers</I> is a comma-separated list of cgroup subsystems (e.g., cpu,memory). <I>group</I> is the path to the cgroup within that hierarchy.<br><br><b><b>--group</b> <I>controllers</I>:<I>group</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Equivalent to <b>-g</b>.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available cgroups and their controllers.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Kills all tasks in the specified cgroup(s) when <I>cgexec</I> exits. Use with caution.<br><br><b><b>-r</b> <I>root_path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative cgroup filesystem root directory.<br><br><b><b>--sticky</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the executed command and its children 'sticky', meaning they will remain in the cgroup even if they fork or exec new processes, unless explicitly moved.<br><br><b><I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to be executed within the specified cgroup.<br><br><b>[<I>arguments</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments passed to the executed command.<br><br>


title: DESCRIPTION
content:
The <I>cgexec</I> command executes a specified command within a designated Linux control group (<I>cgroup</I>). Cgroups provide a mechanism for organizing processes hierarchically and distributing system resources along that hierarchy. <I>cgexec</I> allows administrators to precisely control the resources (CPU, memory, I/O, etc.) consumed by a particular application or set of processes by placing them into an isolated cgroup. This is crucial for resource management, workload isolation, performance optimization, and preventing resource starvation among different services or users on a system. It ensures that critical applications receive the necessary resources while limiting others, contributing to system stability and predictability. <I>cgexec</I> is a fundamental tool for managing complex resource allocation scenarios.


title: CAVEATS
content:
The <I>cgroup</I> filesystem must be mounted for <I>cgexec</I> to function correctly. Permissions are critical; typically, root privileges are required to create or modify cgroups. Existing cgroups must be defined or created using tools like <I>cgcreate</I> beforehand. Understanding the cgroup hierarchy and controller specifics is essential for correct usage. <I>cgexec</I> primarily interacts with cgroup v1; cgroup v2 (unified hierarchy) adoption, often managed by <I>systemd</I>, can alter cgroup management paradigms.


title: EXAMPLE USAGE
content:
To run a <I>stress</I> command within a cgroup named <I>mygroup</I> under the <I>cpu</I> and <I>memory</I> controllers, you would first ensure the cgroup exists (e.g., using <I>cgcreate -g cpu,memory:/mygroup</I>), and then execute:<br><br><I>cgexec -g cpu,memory:/mygroup stress -c 2 --vm 1 --vm-bytes 100M</I><br><br>This command would allocate two CPU stressors and one memory stressor (100MB) to the <I>mygroup</I> cgroup, allowing its resource consumption to be monitored and limited independently from other processes on the system.


title: HISTORY
content:
<I>cgexec</I> is part of the <I>libcgroup</I> tools suite, which provides a user-space interface for managing Linux control groups. Cgroups were initially introduced into the Linux kernel around version 2.6.24. The <I>libcgroup</I> project developed these utilities to offer a standardized way for system administrators and applications to interact with the kernel's cgroup functionality. While cgroup v1 remains widely used with these tools, the Linux ecosystem is gradually moving towards cgroup v2, managed primarily by <I>systemd</I>, which might influence the long-term relevance or specific use cases of <I>libcgroup</I> tools like <I>cgexec</I>.


title: PARAMETERS
content:
<b><B>-u</B> &lt;<I>username</I>&gt; / <B>--username</B> &lt;<I>username</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for which the password needs to be reset. This is a mandatory option.<br><br><b><B>--batch</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command in non-interactive mode. The command will automatically generate a new, strong password and print it to standard output. Useful for scripting.<br><br><b><B>--stdin</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the new password from standard input (stdin). This is useful when piping a password to the command, avoiding exposure in shell history.<br><br><b><B>--silent</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most informational messages, only showing critical output (e.g., the new password in batch mode).<br><br><b><B>--config</B> &lt;<I>path</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Elasticsearch configuration directory. Useful if the default path is not applicable.<br><br><b><B>--url</B> &lt;<I>url</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the Elasticsearch instance to connect to. By default, it connects to <I>http://localhost:9200</I>.<br><br><b><B>-v</B> / <B>--verbose</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of output, providing more detailed information during execution.<br><br>


title: DESCRIPTION
content:
The <I>elasticsearch-reset-password</I> command is a crucial utility provided by Elasticsearch to securely reset passwords for both built-in users (like <I>elastic</I>, <I>kibana_system</I>, <I>logstash_system</I>, <I>beats_system</I>) and any custom users created within the Elasticsearch security realm. This command is typically found in the <I>bin</I> directory of your Elasticsearch installation. It's essential for regaining access to your cluster if user passwords are lost or for rotating security credentials as part of regular security practices. By default, it operates interactively, prompting the user for the new password. However, it also supports non-interactive modes for scripting and automation, where it can either generate a strong, random password or accept a password via standard input. Using this tool ensures that passwords are reset safely without direct manipulation of configuration files or the need for API calls that might expose credentials.


title: CAVEATS
content:
<B>Permissions:</B> The command must be executed with sufficient privileges, typically by the user running the Elasticsearch process (e.g., <I>elasticsearch</I> user) or <I>root</I>.<br><B>Elasticsearch State:</B> The Elasticsearch cluster must be running and accessible for the password reset to succeed.<br><B>Generated Passwords:</B> When using <I>--batch</I>, a cryptographically strong, random password is generated. Ensure you securely store this password as it will not be displayed again.<br><B>Built-in Users:</B> Exercise extreme caution when resetting passwords for built-in users like <I>elastic</I>, as they have extensive privileges and are critical for cluster operation.<br><B>Java Dependency:</B> Requires a compatible Java Runtime Environment (JRE) to be installed and accessible via the <I>PATH</I> or configured via the <I>JAVA_HOME</I> environment variable.


title: <B>TYPICAL LOCATION</B>
content:
The command is usually located in the <I>$ES_HOME/bin</I> directory, where <I>$ES_HOME</I> is the root directory of your Elasticsearch installation. It's recommended to run it from this directory or add <I>$ES_HOME/bin</I> to your system's <I>PATH</I>.


title: <B>USAGE EXAMPLE (INTERACTIVE)</B>
content:
<br><I>./elasticsearch-reset-password -u elastic</I><br><i>(This will prompt you to enter the new password twice)</i>


title: <B>USAGE EXAMPLE (NON-INTERACTIVE, GENERATE PASSWORD)</B>
content:
<br><I>./elasticsearch-reset-password -u kibana_system --batch</I><br><i>(This will output a new, random password for the kibana_system user)</i>


title: <B>USAGE EXAMPLE (NON-INTERACTIVE, PROVIDE PASSWORD)</B>
content:
<br><I>echo "MyStrongNewPassword" | ./elasticsearch-reset-password -u logstash_system --stdin</I><br><i>(This sets "MyStrongNewPassword" for the logstash_system user)</i>


title: HISTORY
content:
The <I>elasticsearch-reset-password</I> utility is part of Elasticsearch's X-Pack security features, which became a core part of the default distribution starting with Elasticsearch 6.8 (basic security tier) and fully open-sourced for basic features in 7.0. Its development reflects the growing need for robust, built-in security mechanisms within the Elasticsearch ecosystem, enabling administrators to manage user credentials directly from the command line without relying solely on API calls or external tools.


title: SEE ALSO
content:
<I>No direct standard Linux manual pages for this application-specific utility.</I> However, it is an integral part of <B>Elasticsearch</B> security, functionally similar to system user password tools like <I>passwd(1)</I> but for the Elasticsearch realm.


title: TLDR
content:
<b>Reset the password of the user to an auto-generated value and print it in the console</b>`elasticsearch-reset-password [[-u|--username]] [user]`<br><b>Prompt interactively to reset the password for a native user</b>`elasticsearch-reset-password [[-u|--username]] [user] [[-i|--interactive]]`<br><b>Interactively reset the password for a user at a specified Elasticsearch node URL</b>`elasticsearch-reset-password --url [host]:[port] [[-u|--username]] [user] [[-i|--interactive]]`


title: PARAMETERS
content:
<b><b>-c</b> <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specific command on the NTP server, then exits. Common commands include <i>peers</i>, <i>associations</i>, <i>sysinfo</i>, etc.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, displaying additional information useful for troubleshooting.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters interactive mode, allowing multiple commands to be executed sequentially without exiting.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not convert host addresses to names, displaying them as dotted-quad IP addresses instead.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of peers in a concise format, showing their status, stratum, offset, and jitter.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the NTP server and then exits. This is similar to <b>-c peers</b> and <b>-c associations</b> for a quick overview.<br><br><b><b>-r</b> <i>retry_delay</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial retry delay for queries, in seconds.<br><br><b><b>-t</b> <i>timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout for queries, in seconds.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version number of <b>ntpq</b>.<br><br><b><i>host</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the host or IP address of the NTP server to query. If omitted, <b>ntpq</b> defaults to <i>localhost</i>.<br><br>


title: DESCRIPTION
content:
The command <i>ntp-ctl</i> is not a standard Linux utility. This analysis provides information based on <b>ntpq</b>, the widely used Network Time Protocol (NTP) query program. <b>ntpq</b> is an interactive utility that allows users to monitor and control the <b>ntpd</b> daemon. It can be used to query any compatible NTP server on the network for current state information, including the status of configured peers, system variables, and protocol statistics. This tool is essential for diagnosing NTP synchronization issues and verifying the health of time services. While <i>ntp-ctl</i> is not a recognized command, <b>ntpq</b> serves the purpose of controlling and querying NTP services on most Linux distributions.


title: CAVEATS
content:
The command <i>ntp-ctl</i> is not a standard Linux command and will likely result in 'command not found'. The analysis provided is for <b>ntpq</b>, which is the standard NTP query tool. <b>ntpq</b> requires the <b>ntpd</b> daemon to be running on the target host for most queries to return meaningful information. Some operations may require root privileges or specific network permissions.


title: NTP CONTROL UTILITIES
content:
While <i>ntp-ctl</i> is not a recognized command on standard Linux systems, the functionality of controlling and querying NTP services is commonly provided by tools like <b>ntpq</b> (for the NTP daemon) and <b>chronyc</b> (for the Chrony NTP client/server). These utilities offer comprehensive capabilities for monitoring time synchronization status, peer information, and system variables crucial for network time management.


title: HISTORY
content:
<b>ntpq</b> has been an integral part of the NTP reference implementation since its early versions. Developed alongside the Network Time Protocol itself, it has evolved to support new protocol features and provide robust diagnostic capabilities for NTP daemon operations. Its design reflects the continuous development of the NTP protocol, allowing administrators to monitor and manage time synchronization effectively across diverse network environments.


title: TLDR
content:
<b>Display information about the current state of the NTP daemon</b>`ntp-ctl status`<br><b>Check if the specified configuration file (default: /etc/ntpd-rs/ntp.toml) is valid</b>`ntp-ctl [[-c|--config]] [path/to/config] validate`<br><b>Interactively run a single synchronization of the clock</b>`sudo ntp-ctl force-sync`


title: PARAMETERS
content:
<b>y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables mail notification.</i> This tells the <b>comsat</b> daemon to notify you when new mail arrives.<br><br><b>n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables mail notification.</i> This stops <b>comsat</b> from sending mail alerts to your terminal.<br><br>


title: DESCRIPTION
content:
<b>biff</b> is a traditional Unix command-line utility designed to provide immediate notifications of new incoming mail. When enabled, it monitors the user's mailbox file for changes. Upon the arrival of a new email, <b>biff</b> prints the mail header and the first few lines of the message directly to the user's terminal, interrupting whatever they might be doing. This functionality relies on the <b>comsat</b> (or <b>biff-server</b>) daemon, which actively watches mailboxes and sends notifications. While once a popular feature for system administrators and power users on text-based terminals, <b>biff</b> has largely been superseded by modern graphical mail clients and notification systems that offer richer and less intrusive ways to manage email alerts. It remains available primarily for historical compatibility or in minimalist console environments.


title: CAVEATS
content:
<b>biff</b> requires the <b>comsat</b> (or <b>biff-server</b>) daemon to be running on the system to function correctly. Without <b>comsat</b>, <b>biff</b> will not be able to provide notifications.<br>Notifications are printed directly to the terminal, which can be disruptive, especially if you are in the middle of editing a file or running another command.<br>In modern desktop environments, graphical mail clients and notification systems offer more integrated and less intrusive mail alerts, making <b>biff</b> less relevant for most users.<br>Printing mail headers and content directly to the terminal could potentially expose sensitive information to shoulder-surfers or in screen recordings.<br>It primarily works for local mailboxes, not typically for remote IMAP/POP3 accounts without specific server-side integration.


title: <B>HOW <B>BIFF</B> WORKS</B>
content:
When you execute <b>biff y</b>, the <b>biff</b> client program sends a UDP datagram to the <b>comsat</b> server, typically on port 512 (biff/comsat service). This datagram includes your terminal device name. The <b>comsat</b> daemon then adds your terminal to its list of devices to notify. When <b>comsat</b> detects new mail in your mailbox file (e.g., <i>/var/mail/$USER</i>), it reads the mailbox, formats the notification (header and first few lines), and attempts to write this information directly to the specified terminal using <i>write(2)</i> or similar low-level system calls, bypassing the shell.


title: <B>MODERN RELEVANCE</B>
content:
In contemporary computing environments, <b>biff</b> is rarely used by the average user. Modern email clients like Thunderbird, Outlook, or webmail interfaces provide rich, configurable, and often non-intrusive notifications (e.g., pop-up alerts, sound notifications, tray icons) that are far more suitable for desktop use. <b>biff</b>'s primary utility now lies in niche scenarios, such as very minimalist console-only setups, for historical interest, or by system administrators who prefer a traditional Unix toolset.


title: HISTORY
content:
<b>biff</b> is a venerable command tracing its origins back to early Unix systems, particularly BSD. It was designed to address the need for immediate mail notification in a time when users typically worked on text-based terminals and didn't have graphical interfaces or persistent mail clients. The command is named after a dog belonging to the developer who created it. Its reliance on the <b>comsat</b> (or <b>biff-server</b>) daemon dates back to these early implementations, where <b>comsat</b> would monitor <i>/var/mail</i> or <i>~/Mailbox</i> and broadcast mail arrival information. While widely used in the 1980s and 1990s, its prominence waned with the advent of graphical user interfaces and sophisticated email clients, which offer more advanced and user-friendly notification mechanisms. Despite this, <b>biff</b> remains a testament to the ingenuity of early Unix developers and is still found on many systems for backward compatibility.


title: TLDR
content:
<b>Print the current time in a format of your choosing</b>`biff time fmt [[-f|--format]] rfc3339 now`<br><b>Print multiple relative times in one command</b>`biff time fmt [[-f|--format]] '%c' now -1d 'next sat' 'last monday' '9pm last mon'`<br><b>Print the current time in another time zone, and round it the nearest 15 minute increment</b>`biff time in Asia/Bangkok now | biff time round [[-i|--increment]] 15 [[-s|--smallest]] minute`<br><b>Convert a time between two different time zone</b>`TZ='Japan' biff time in America/New_York 02:30`<br><b>Print a past or future time relative to current time</b>`biff time add [-1d|1d|1w|-1m|1y|...] now`<br><b>Add a complex duration to the current time</b>`biff time add '1 week, 12 hours ago' now`<br><b>Find the duration since a date in the past and round it to the desired precision</b>`biff span since 2025-01-20T12:00 [[-l|--largest]] year`<br><b>Find timestamps in a log file and reformat them into your local time in place</b>`biff tag lines /tmp/access.log | biff time in system | biff time fmt [[-f|--format]] '%c' | head [[-n|--lines]] 3 | biff untag [[-s|--substitute]]`


title: TLDR
content:
<b>List all refs (branches and tags)</b>`git for-each-ref`<br><b>List only branches</b>`git for-each-ref refs/heads/`<br><b>List only tags</b>`git for-each-ref refs/tags/`<br><b>Show branches merged into HEAD</b>`git for-each-ref --merged HEAD refs/heads/`<br><b>List short names of all refs</b>`git for-each-ref --format "%(refname:short)"`<br><b>Sort refs by committer date (most recent first)</b>`git for-each-ref --sort -committerdate`<br><b>Sort refs by committer date (oldest first)</b>`git for-each-ref --sort committerdate`<br><b>Limit output to a specified number of refs</b>`git for-each-ref --count [count]`


title: TLDR
content:
<b>Show the name for HEAD</b>`git name-rev HEAD`<br><b>Show only the name</b>`git name-rev --name-only HEAD`<br><b>Enumerate all matching ref names</b>`git name-rev --all`<br><b>Use only tags to name the commit</b>`git name-rev --tags HEAD`<br><b>Exit with a non-zero status code instead of printing undefined for unknown commits</b>`git name-rev --no-undefined [commit-ish]`<br><b>Show names for multiple commits</b>`git name-rev HEAD~1 HEAD~2 main`<br><b>Restrict names to branch refs</b>`git name-rev --refs refs/heads/ [commit-ish]`<br><b>Read commit IDs from stdin</b>`echo "[commit-ish]" | git name-rev --annotate-stdin`


title: PARAMETERS
content:
<b><b>-conf</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default <I>dunstrc</I>.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current version information of <b>Dunst</b>.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a reload signal to a running <b>Dunst</b> instance, causing it to re-read its configuration file.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a status request to a running <b>Dunst</b> instance, useful for debugging or monitoring its state.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses debug messages printed to standard output or log files, making output quieter.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints incoming notifications to standard output in a simple format, primarily used for debugging notification streams.<br><br>


title: DESCRIPTION
content:
<b>Dunst</b> is a highly configurable and lightweight notification daemon designed for Linux and BSD systems. It strictly adheres to the <I>Freedesktop.org Notification Specification</I>, making it compatible with most applications that send desktop notifications. Unlike heavier desktop environments' notification systems, <b>Dunst</b> operates independently, making it an ideal choice for minimalist window managers like i3, bspwm, or Sway.<br><br>Its core strengths include speed, unobtrusiveness, and extensive customization options. Users can define rules based on urgency, sender, or content to alter notification appearance, duration, or even execute custom scripts. It also features a notification history, allowing users to recall past alerts, and supports interactive actions directly from the notification.<br><br><b>Dunst</b> aims to provide essential notification functionality without unnecessary bloat, offering a seamless and personalized notification experience.


title: CAVEATS
content:
While highly customizable, <b>Dunst</b> relies heavily on its configuration file (<I>dunstrc</I>) for advanced features, which can become complex for new users. It requires a running <I>X11</I> or <I>Wayland</I> display server to function. Debugging configuration issues often involves manually checking the <I>dunstrc</I> file and running <b>Dunst</b> with verbose output (`-x` option).


title: CONFIGURATION FILE
content:
The primary configuration for <b>Dunst</b> is handled via the <I>dunstrc</I> file, typically located at <I>~/.config/dunst/dunstrc</I> or <I>$XDG_CONFIG_HOME/dunst/dunstrc</I>. This file allows extensive customization of appearance (font, colors, geometry), behavior (notification rules, urgency levels, timeout), and keyboard shortcuts. It is the central place for defining how notifications are displayed and handled.


title: NOTIFICATION RULES
content:
<b>Dunst</b> allows users to define powerful rules in the <I>dunstrc</I> file to modify notifications based on various criteria such as application name, summary, body, or urgency level. These rules can alter the notification's appearance, timeout, or even execute a custom script in response to an event, providing granular control over how alerts are displayed and processed.


title: RUNTIME CONTROL
content:
A separate utility, <I>dunstctl</I>, provides command-line control over a running <b>Dunst</b> instance. It can be used to close the current notification, view notification history, invoke actions associated with notifications, or pause/resume <b>Dunst</b>. This allows for dynamic interaction with the daemon without needing to restart it or rely on graphical interfaces.


title: HISTORY
content:
<b>Dunst</b> emerged as a response to the perceived bloat and lack of customization in existing notification daemons prevalent in traditional desktop environments. Its development aimed to provide a fast, minimalist, and highly configurable solution, especially appealing to users of tiling window managers and those who prefer a desktop environment-agnostic setup. Since its inception, it has gained significant traction within the Linux community for its efficiency and flexibility, becoming a de facto standard for lightweight notification management.


title: TLDR
content:
<b>Start dunst</b>`dunst`<br><b>Display a notification on startup</b>`dunst -startup_notification`<br><b>Print incoming notifications to stdout</b>`dunst -print`<br><b>Use the specified configuration file (default: $XDG_CONFIG_HOME/dunst/dunstrc)</b>`dunst [[-conf|-config]] [path/to/file]`


title: SYNOPSIS
content:
<B>aws pricing get-products</B> [--service-code <I>value</I>] [--filters <I>value</I> [<I>value</I>...]] [--format-version <I>value</I>] [--region <I>value</I>] [--output <I>value</I>] [--query <I>value</I>] [<I>global-options</I>]


title: PARAMETERS
content:
<b>--service-code <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the service for which to retrieve pricing data (e.g., AmazonEC2, AmazonS3).<br><br><b>--filters <I>value</I> [<I>value</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A list of filters to narrow down the products, specified as 'Field=<I>fieldName</I>,Type=TERM_MATCH,Value=<I>fieldValue</I>'.<br><br><b>--format-version <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The format version of the pricing data response (e.g., aws_v1).<br><br><b>--region <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the AWS region to connect to for the pricing service API endpoint.<br><br><b>--output <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format, such as <I>json</I>, <I>text</I>, or <I>yaml</I>.<br><br><b>--query <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A JMESPath query to filter and transform the command's JSON output.<br><br>


title: DESCRIPTION
content:
The command line utility for accessing AWS pricing information is primarily handled by the <I>aws pricing</I> service within the AWS Command Line Interface (CLI). Specifically, the <B>aws pricing get-products</B> command enables users to programmatically retrieve detailed pricing data for various AWS services and their associated products directly from the AWS Price List API. This command is not a standalone Linux utility but rather a part of the official AWS CLI package, which must be installed and configured.<br><br>It provides comprehensive attributes such as service codes (e.g., AmazonEC2, AmazonS3), product families, specific instance types, regions, and their corresponding price dimensions (e.g., On-Demand, Reserved Instance, Savings Plan rates). This functionality is invaluable for developers, system administrators, and financial analysts for automating cost analysis, integrating real-time pricing into custom applications, forecasting budgets, and making informed decisions about resource provisioning based on current AWS costs.


title: CAVEATS
content:
The command <B>aws-pricing</B> as a standalone Linux command does not exist. The functionalities described pertain to the <B>aws pricing</B> service within the AWS CLI. Users must have the AWS CLI installed and configured with appropriate AWS credentials. The output from <B>aws pricing get-products</B> can be extremely verbose and complex, often requiring external tools like <I>jq</I> for effective parsing and data extraction. There are API rate limits that apply to the Pricing API, so excessive calls may be throttled. Pricing data might have a slight latency compared to real-time changes on the AWS console.


title: PARSING OUTPUT
content:
The JSON output from <B>aws pricing get-products</B> contains nested structures for products and their price dimensions. Effectively extracting specific pricing points, such as the On-Demand hourly rate for a particular instance type in a given region, typically requires piping the command's output to a JSON processing tool like <I>jq</I>. For example, filtering for Linux EC2 instances might involve complex <I>jq</I> queries to navigate through 'product', 'attributes', and 'terms' sections of the JSON response.


title: COMMON USE CASES
content:
Beyond simple lookups, this command is critical for building custom cloud cost calculators, creating scripts that automatically monitor and alert on price changes for specific services, and validating billing information against published prices. It also plays a role in implementing cost-aware auto-scaling solutions or provisioning strategies where the most cost-effective resource configuration is dynamically selected based on current pricing data.


title: HISTORY
content:
Before the advent of programmatic APIs, AWS pricing data was primarily available through web pages or PDF documents, making automated analysis challenging. AWS introduced the Price List API to address this, providing a structured, queryable data source. The AWS CLI integrated this API, offering commands like <B>aws pricing get-products</B> as a user-friendly interface. This evolution has significantly empowered developers and finance teams to automate cost management, track price changes, and build sophisticated tools for AWS resource optimization, adapting to the dynamic nature of AWS pricing models.


title: PARAMETERS
content:
<b><I>Global AWS CLI Options (applicable to any AWS CLI command, including aws rds operations)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;These options are passed to the main <b>aws</b> command and affect its overall behavior, such as region and output format.<br><br><b>--region <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the AWS region to send the request to (e.g., <i>us-east-1</i>).<br><br><b>--output <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., <i>json</i>, <i>text</i>, <i>table</i>).<br><br><b>--profile <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a specific named profile from your credential file (e.g., <i>default</i>, <i>dev</i>).<br><br><b>--endpoint-url <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default endpoint for the RDS service, useful for local development or private endpoints.<br><br><b>--no-paginate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables pagination for commands that return a large number of results.<br><br><b><I>Subcommand-specific Parameters (vary greatly by RDS operation)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;These parameters are specific to the chosen <i>subcommand</i> (e.g., <i>create-db-instance</i>, <i>describe-db-instances</i>). Below are examples of commonly used parameters for RDS operations.<br><br><b>--db-instance-identifier <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A unique name for the DB instance (e.g., <i>my-prod-db</i>). Used in many operations like creation, modification, or deletion.<br><br><b>--db-instance-class <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The compute and memory capacity of the DB instance (e.g., <i>db.t3.micro</i>, <i>db.m5.large</i>). Required for creating or modifying instances.<br><br><b>--engine <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the database engine (e.g., <i>mysql</i>, <i>postgres</i>, <i>aurora</i>). Required for creating new instances.<br><br><b>--master-username <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The master user name for the DB instance. Required for creating new instances.<br><br><b>--master-user-password <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The master user password for the DB instance. Required for creating new instances.<br><br><b>--allocated-storage <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The size of the storage in GiB. Required for creating new instances.<br><br><b>--skip-final-snapshot | --no-skip-final-snapshot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>delete-db-instance</i> to specify whether to skip creating a final DB snapshot before deletion.<br><br>


title: DESCRIPTION
content:
The <b>aws rds</b> command, part of the AWS Command Line Interface (CLI), provides a powerful way to interact with and manage Amazon Relational Database Service (RDS) resources directly from your terminal. AWS RDS is a web service that simplifies the setup, operation, and scaling of relational databases in the cloud, supporting various database engines like MySQL, PostgreSQL, Oracle, SQL Server, and Amazon Aurora.<br><br>This command allows users to perform a wide range of operations including creating, modifying, and deleting DB instances; managing database snapshots, security groups, parameter groups, and more. It abstracts away many complex database administration tasks, enabling developers and administrators to focus on application development and data management.<br><br><i>Note: The term 'aws-rds' is commonly used to refer to the 'rds' subcommand within the official 'aws' CLI, rather than a standalone 'aws-rds' executable. This analysis assumes the functionality of 'aws rds'.</i>


title: CAVEATS
content:
<b>Authentication and Permissions</b>: Requires valid AWS credentials configured (e.g., via <i>aws configure</i> or environment variables) with appropriate IAM permissions for RDS actions. Without correct permissions, operations will fail with access denied errors.<br><br><b>Region Specificity</b>: Operations are region-specific. Ensure the correct AWS region is used via the <i>--region</i> option or a configured profile, as resources in one region are not visible or manageable from another.<br><br><b>Asynchronous Operations</b>: Many RDS operations (e.g., creating, modifying, deleting DB instances) are asynchronous and can take several minutes or longer to complete. The CLI command might return quickly, but the resource will remain in a 'pending' state until the operation is fully processed.<br><br><b>Cost Implications</b>: Creating or running RDS instances incurs costs, which vary significantly by instance class, storage type and size, data transfer, and Multi-AZ configurations. Always review pricing and monitor usage to avoid unexpected charges.<br><br><b>Resource Limits</b>: AWS accounts have default resource limits for RDS (e.g., maximum number of DB instances). If you exceed these limits, you'll need to request a limit increase through AWS Support.


title: COMMON WORKFLOWS AND EXAMPLES
content:
Here are examples of common operations using the <b>aws rds</b> command:<br><br><i>Creating a DB Instance</i>:<br>aws rds create-db-instance --db-instance-identifier my-test-db --db-instance-class db.t3.micro --engine mysql --master-username admin --master-user-password 'MySecurePassword123' --allocated-storage 20 --vpc-security-group-ids sg-xxxxxxxxxxxxxxxxx --db-subnet-group-name my-db-subnet-group<br><br><i>Describing DB Instances</i>:<br>aws rds describe-db-instances --db-instance-identifier my-test-db<br><i>(To list all instances):<br></i>aws rds describe-db-instances<br><br><i>Deleting a DB Instance</i>:<br>aws rds delete-db-instance --db-instance-identifier my-test-db --skip-final-snapshot<br><br><i>Creating a DB Snapshot</i>:<br>aws rds create-db-snapshot --db-snapshot-identifier my-test-db-snapshot-2023-10-27 --db-instance-identifier my-test-db


title: CONFIGURATION AND CREDENTIALS
content:
The AWS CLI relies on credentials and configuration files, typically located at <i>~/.aws/credentials</i> and <i>~/.aws/config</i>. These files define AWS access keys, secret keys, default regions, and named profiles. Using <i>aws configure</i> is the recommended way to set up these files, allowing secure management of AWS resources without embedding sensitive information directly in commands.


title: HISTORY
content:
The AWS CLI was first released in 2013, providing a unified command-line interface for interacting with AWS services. Amazon RDS itself launched in 2009 to simplify the operational burden of running relational databases. The <b>aws rds</b> sub-command has evolved significantly since then, adding support for new database engines (like Aurora), features (like Multi-AZ deployments, read replicas), and fine-grained control over instance configuration as the RDS service itself expanded. Its development is tightly coupled with the ongoing evolution of the AWS RDS service.


title: PARAMETERS
content:
<b><b>login</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates with AWS SSO and fetches temporary credentials.<br><br><b><b>configure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Guides through setting up a new AWS SSO profile.<br><br><b><b>profiles</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all configured AWS SSO profiles.<br><br><b><b>assume</b> <i>&lt;profile-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assumes a specific role associated with an SSO profile, often setting environment variables for CLI access.<br><br><b><b>refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes expired AWS SSO credentials without full re-authentication.<br><br><b><b>env</b> <i>&lt;profile-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <i>export</i> commands for environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc.) for a given profile, suitable for <i>eval</i>.<br><br><b><b>--profile</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the SSO profile to use for the command.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or subcommand.<br><br>


title: DESCRIPTION
content:
<i>aws-sso</i> is commonly a community-driven or custom helper script designed to streamline authentication with AWS Single Sign-On (SSO) and assuming AWS roles directly from the command line.<br>It typically acts as a wrapper around the official <i>aws configure sso</i> and <i>aws sso login</i> processes, offering a more user-friendly interface.<br>Its primary goal is to simplify fetching temporary AWS credentials for various AWS accounts and roles configured via SSO, thereby easing the use of the AWS CLI and SDKs without manual credential handling.<br>It often manages multiple SSO profiles, assists with token refreshing, and automates the process of setting environment variables for CLI access, greatly improving developer experience when working with AWS SSO enabled organizations.


title: CAVEATS
content:
<i>aws-sso</i> is typically a third-party script or personal wrapper, not an official AWS CLI command directly from Amazon.<br>Its functionality can vary significantly between different implementations, so users should consult the specific script's documentation.<br>It generally requires <i>aws-cli</i> v2 to be installed and configured for SSO.<br>Always verify the source and contents of any <i>aws-sso</i> script before execution due to security implications of credential management.


title: SHELL INTEGRATION
content:
For immediate credential application in the current shell session, <i>aws-sso</i> commands are often used with <i>eval</i>, e.g., <i>eval $(aws-sso env &lt;profile&gt;)</i>.<br>This sets the necessary environment variables (access key, secret key, session token) and expiration, allowing seamless use of the AWS CLI and SDKs until the credentials expire.


title: MULTI-PROFILE MANAGEMENT
content:
A key benefit of <i>aws-sso</i> is its ability to easily manage and switch between different AWS accounts and roles configured under AWS SSO.<br>This significantly enhances productivity for users working across multiple environments or projects, providing quick access to respective AWS resources.


title: HISTORY
content:
The emergence of <i>aws-sso</i> scripts stems from the need to simplify AWS SSO integration with the AWS CLI.<br>While AWS CLI v2 provides native SSO support, the process of configuring and frequently switching roles can be cumbersome for developers.<br>Community developers and users created these helper scripts to abstract this complexity, offering a more fluid experience for managing temporary credentials and multiple AWS SSO profiles efficiently.


title: SYNOPSIS
content:
<b>awslogs</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>&lt;log-group-name&gt;</i>] [<i>&lt;log-stream-name&gt;</i>]<br><br>Common subcommands include:<br>&nbsp;&nbsp;<b>awslogs get</b> <i>&lt;log-group-name&gt;</i> [<i>&lt;log-stream-name&gt;</i>] [<i>options</i>]<br>&nbsp;&nbsp;<b>awslogs tail</b> <i>&lt;log-group-name&gt;</i> [<i>options</i>]<br>&nbsp;&nbsp;<b>awslogs groups</b> [<i>options</i>]<br>&nbsp;&nbsp;<b>awslogs streams</b> <i>&lt;log-group-name&gt;</i> [<i>options</i>]


title: PARAMETERS
content:
<b>--start <timestamp></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve logs starting from this time. Can be relative (e.g., '10m ago') or absolute (e.g., '2023-01-01 10:00:00').<br><br><b>--end <timestamp></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve logs up to this time. Similar format to <b>--start</b>.<br><br><b>-f, --follow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <b>tail</b> subcommand) Continuously stream new log events as they arrive, similar to <b>tail -f</b>.<br><br><b>--filter-pattern <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter log events using a CloudWatch Logs filter pattern syntax.<br><br><b>--limit <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of log events returned.<br><br><b>--profile <profile-name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific AWS named profile from your AWS credentials file.<br><br><b>--region <aws-region></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the AWS region to interact with (e.g., <i>us-east-1</i>).<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output for log events.<br><br>


title: DESCRIPTION
content:
<b>awslogs</b> is a command-line utility designed to interact with Amazon CloudWatch Logs. It allows users to retrieve, filter, and tail log events from CloudWatch Log Groups and Log Streams directly from their terminal. Unlike standard Linux commands that operate on local files, <b>awslogs</b> provides a convenient way to access centralized cloud logs, making it invaluable for monitoring, debugging, and troubleshooting applications deployed on AWS.<br><br>It often acts as a wrapper around the AWS CloudWatch Logs API, providing a user-friendly interface for tasks like real-time log monitoring (similar to <b>tail -f</b>) or fetching historical log data within specified time ranges. It's typically a Python-based utility, requiring valid AWS credentials and configuration to function.


title: CAVEATS
content:
Requires valid AWS credentials and configuration (e.g., <i>~/.aws/credentials</i>, <i>~/.aws/config</i>) to access CloudWatch Logs.<br>Not a default system utility; must be installed separately (e.g., via <b>pip</b>).<br>Operations may incur AWS API request costs and data transfer charges depending on usage volume.<br>Subject to CloudWatch Logs API rate limits.<br>The exact command syntax and available options can vary slightly based on the specific version or implementation (e.g., standalone <b>awslogs</b> vs. AWS CLI's <b>aws logs</b>). This analysis focuses on the commonly understood standalone utility.


title: SUBCOMMANDS EXPLAINED
content:
<b>awslogs</b> operates primarily through subcommands, each performing a specific function:<br><i>&nbsp;&nbsp;<b>get</b></i>: Retrieves historical log events from a specified log group and optional log stream within a given time range.<br><i>&nbsp;&nbsp;<b>tail</b></i>: Continuously streams new log events from a log group, providing real-time monitoring capabilities similar to <b>tail -f</b> for local files.<br><i>&nbsp;&nbsp;<b>groups</b></i>: Lists all CloudWatch Log Groups accessible to the configured AWS account and region.<br><i>&nbsp;&nbsp;<b>streams</b></i>: Lists log streams within a specified log group.


title: INSTALLATION
content:
<b>awslogs</b> is typically installed using Python's package manager, <b>pip</b>:<br><i>&nbsp;&nbsp;pip install awslogs</i><br>Users should ensure they have <b>pip</b> and Python installed on their system before attempting installation.


title: HISTORY
content:
The <b>awslogs</b> utility emerged as a popular standalone Python script to simplify interaction with Amazon CloudWatch Logs, often complementing or predating the comprehensive `aws logs` commands available in the official AWS CLI. Its development was driven by the need for a more <b>tail -f</b>-like experience for cloud-based logs, which was not natively available when CloudWatch Logs first launched. It quickly became a go-to tool for developers and operations teams due to its ease of use and focused functionality for log retrieval and monitoring.


title: DESCRIPTION
content:
The <B>az logout</B> command is an essential component of the <I>Azure Command-Line Interface (CLI)</I>, a powerful and cross-platform tool designed for managing <I>Azure</I> cloud resources. Its primary function is to terminate the active authentication session for an <I>Azure</I> account within the CLI context.<br><br>Upon execution, <B>az logout</B> effectively removes stored authentication tokens and cached credentials, thereby logging you out of the currently authenticated <I>Azure</I> identity. This action requires a fresh login using the <B>az login</B> command for any subsequent interactions with <I>Azure</I> services via the CLI.<br><br>It is crucial for security, particularly when working on shared systems or after completing sensitive tasks, to prevent unauthorized access to your <I>Azure</I> subscriptions. The command operates silently, requiring no specific operational parameters, and serves as a straightforward method to ensure a clean authentication state. It helps in clearing authentication caches, providing a fresh start for new operations or for switching between different <I>Azure</I> accounts or directories.


title: CAVEATS
content:
<B>No Confirmation Prompt</B>: The command executes immediately without an explicit 'Are you sure?' confirmation prompt.<br><br><B>Global vs. Specific Logout</B>: It logs out the *currently active* interactive account and removes its associated tokens. It might not clear all cached service principal credentials if they were configured separately or if multiple accounts are stored in a non-interactive way.<br><br><B>Browser/Application Sessions</B>: Logging out via the CLI does <I>not</I> affect active sessions in web browsers, other <I>Azure</I>-connected applications, or services that use their own authentication mechanisms. Its scope is limited to the CLI's authentication context.<br><br><B>Local Data</B>: It primarily removes authentication tokens and does not delete local configuration files, settings, or data unrelated to the authentication process.


title: GLOBAL ARGUMENTS
content:
While <B>az logout</B> has no unique operational parameters specific to its logout functionality, it supports common global <I>Azure CLI</I> arguments that apply to almost all <I>az</I> commands. These include <B>--help</B> (<I>-h</I>) to display usage information, <B>--output</B> (<I>-o</I>) to specify the output format (e.g., <I>json</I>, <I>table</I>, <I>tsv</I>), <B>--query</B> for <I>JMESPath</I> filtering of command output, and verbosity flags like <B>--verbose</B> or <B>--debug</B>. These arguments modify the command's behavior in terms of help, output presentation, or logging, rather than its core action.


title: SECURITY BEST PRACTICES
content:
Utilizing <B>az logout</B> regularly is a strong security practice, especially in shared or public computing environments. It minimizes the risk of unauthorized access to your <I>Azure</I> resources by ensuring that no active CLI session remains authenticated when your work is completed or when you step away from the machine. It is analogous to locking your workstation or signing out of web services after use, contributing significantly to maintaining the security and integrity of your cloud management activities.


title: HISTORY
content:
The <I>Azure CLI</I> has been a cornerstone for <I>Azure</I> resource management since its early iterations, evolving rapidly to support new services and features. <B>az logout</B> has been a fundamental and consistent component, present since the CLI's initial stable releases (e.g., <B>az CLI 2.0</B> onward). Its development directly aligns with the broader evolution of the <I>Azure</I> platform and its stringent security requirements. The command's functionality has remained remarkably stable, focusing purely on session termination to ensure secure and efficient management of cloud resources. It reflects a standard practice in command-line tools to provide clear session management capabilities for user authentication, contributing to the overall security posture of cloud operations.


title: SEE ALSO
content:
<B>az login</B>: Log in to an Azure account., <B>az account show</B>: Display the currently active Azure subscription details., <B>az account list</B>: List all available Azure subscriptions accessible by the current credentials., <B>az account clear</B>: Clear all stored Azure CLI accounts and subscriptions. (More aggressive than <B>logout</B>)


title: SYNOPSIS
content:
<I>az repos</I> <I>&lt;subcommand&gt;</I> [<I>options</I>]<br><br>Common subcommands include:<br><I>az repos create</I> --name <I>&lt;repository-name&gt;</I> [--org <I>&lt;organization-url&gt;</I>] [--project <I>&lt;project-name&gt;</I>]<br><I>az repos list</I> [--org <I>&lt;organization-url&gt;</I>] [--project <I>&lt;project-name&gt;</I>]<br><I>az repos show</I> --id <I>&lt;repository-id-or-name&gt;</I> [--org <I>&lt;organization-url&gt;</I>] [--project <I>&lt;project-name&gt;</I>]<br><I>az repos delete</I> --id <I>&lt;repository-id-or-name&gt;</I> [--org <I>&lt;organization-url&gt;</I>] [--project <I>&lt;project-name&gt;</I>] [--yes]<br><I>az repos policy</I> <I>&lt;policy-subcommand&gt;</I> [<I>options</I>]<br><I>az repos pr</I> <I>&lt;pr-subcommand&gt;</I> [<I>options</I>]


title: PARAMETERS
content:
<b><I>--org</I> | <I>--organization</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Azure DevOps organization URL (e.g., <I>https://dev.azure.com/myorganization</I>). Applicable to most subcommands.<br><br><b><I>--project</I> | <I>--p</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name or ID of the Azure DevOps project. Applicable to most subcommands.<br><br><b><I>--id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ID or name of the repository. Required for operations targeting a specific repository (e.g., <I>show</I>, <I>delete</I>, <I>update</I>).<br><br><b><I>--name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the repository. Used when creating a new repository or updating an existing one.<br><br><b><I>--default-branch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default branch for a repository (e.g., <I>main</I>, <I>master</I>). Used with <I>az repos update</I>.<br><br><b><I>--detect {true, false}</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically detect organization and project from Git configuration. Default is <I>true</I>.<br><br><b><I>--output {json, jsonc, table, tsv, yaml, none}</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for the command results. Defaults to <I>json</I>.<br><br><b><I>--query</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A JMESPath query string used to filter the output of the command.<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the command or subcommand.<br><br>


title: DESCRIPTION
content:
The <I>az repos</I> command group, part of the Azure Command-Line Interface (Azure CLI), provides a robust set of tools for managing Git repositories within Azure DevOps. It enables users to interact programmatically with repositories, branches, pull requests, and policies directly from the command line. This group is fundamental for automating various repository management tasks, scripting continuous integration/continuous delivery (CI/CD) pipelines, and integrating with other systems.<br><br>Users can perform operations such as listing existing repositories, creating new ones, updating repository settings, managing branches, configuring critical branch policies (e.g., minimum reviewers, build validation), and handling pull requests. The <I>az repos</I> commands leverage the Azure DevOps REST APIs, offering a powerful way to manage version control and collaborative development within Azure DevOps organizations. It requires an authenticated Azure CLI session and appropriate permissions within Azure DevOps to function correctly, making it an indispensable tool for developers and DevOps engineers working with Azure DevOps services.


title: CAVEATS
content:
The <I>az repos</I> command group is not a standalone executable but a collection of subcommands within the Azure CLI. It requires the Azure CLI to be installed and configured. Operations necessitate proper authentication (e.g., via <I>az login</I> or Personal Access Token) and sufficient permissions within the targeted Azure DevOps organization and project. Users must specify a subcommand (like <I>list</I>, <I>create</I>, <I>policy</I>, <I>pr</I>) to perform any action.


title: AUTHENTICATION
content:
Most <I>az repos</I> operations require authentication to your Azure DevOps organization. This is typically achieved using <I>az login</I> for interactive browser-based authentication or by configuring a Personal Access Token (PAT) as a non-interactive authentication method, suitable for scripting and automation.


title: CONTEXT AND DEFAULTS
content:
To simplify command usage, you can set default organization and project values using <I>az devops configure</I> or by setting environment variables (<I>AZURE_DEVOPS_ORG</I>, <I>AZURE_DEVOPS_PROJECT</I>). This eliminates the need to specify the <I>--org</I> and <I>--project</I> parameters with every command, making your scripts more concise.


title: SUBCOMMAND STRUCTURE
content:
The <I>az repos</I> command is a *group* that contains numerous *subgroups* (e.g., <I>az repos policy</I>, <I>az repos pr</I>) and direct *commands* (e.g., <I>az repos list</I>, <I>az repos create</I>). To execute an action, you must always append a specific subcommand or navigate through subgroups to the desired command. For example, to manage pull request policies, you would use <I>az repos policy pr</I>.


title: HISTORY
content:
The Azure CLI, developed by Microsoft, provides a cross-platform command-line interface for managing Azure resources. The functionality for Azure DevOps, including the <I>az repos</I> command group, was initially introduced as an extension (<I>azure-devops</I>) to the core CLI. Its integration into the main CLI reflects the increasing importance of automating Azure DevOps tasks and the demand for programmatic interaction with CI/CD pipelines and version control systems. The ongoing development of <I>az repos</I> aligns with modern DevOps practices, Infrastructure as Code (IaC), and GitOps principles, allowing for seamless integration and automation of repository management within the Azure ecosystem.


title: SYNOPSIS
content:
<b>arptables</b> [-t <i>table</i>] {-A|-D} <i>chain rule-specification</i><br><b>arptables</b> [-t <i>table</i>] -I <i>chain</i> [<i>rulenum</i>] <i>rule-specification</i><br><b>arptables</b> [-t <i>table</i>] -R <i>chain rulenum rule-specification</i><br><b>arptables</b> [-t <i>table</i>] -D <i>chain rulenum</i><br><b>arptables</b> [-t <i>table</i>] {-F|-L|-Z|-N|-X|-P} [<i>chain</i>]<br><b>arptables</b> [-t <i>table</i>] -E <i>old-chain-name new-chain-name</i><br><b>arptables</b> -V | -h


title: PARAMETERS
content:
<b>-t <i>table</i>, --table <i>table</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the table to operate on. The default is 'filter'.<br><br><b>-A <i>chain</i>, --append <i>chain</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append a rule to the end of the specified chain.<br><br><b>-D <i>chain</i>, --delete <i>chain</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete a rule from the specified chain. Can be by rule specification or number.<br><br><b>-I <i>chain</i> [<i>rulenum</i>], --insert <i>chain</i> [<i>rulenum</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Insert a rule at a specified position (default: 1) in the chain.<br><br><b>-R <i>chain rulenum</i>, --replace <i>chain rulenum</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace a rule at a specified position in the chain.<br><br><b>-F [<i>chain</i>], --flush [<i>chain</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flush (delete all rules) from a specific chain, or all chains if none specified.<br><br><b>-L [<i>chain</i>], --list [<i>chain</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all rules in a specific chain, or all chains if none specified.<br><br><b>-Z [<i>chain</i>], --zero [<i>chain</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zero the packet and byte counters for a specific chain/rule, or all if none specified.<br><br><b>-N <i>chain</i>, --new-chain <i>chain</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new user-defined chain.<br><br><b>-X [<i>chain</i>], --delete-chain [<i>chain</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete an empty user-defined chain. Deletes all if none specified.<br><br><b>-P <i>chain target</i>, --policy <i>chain target</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the default policy for a built-in chain (e.g., ACCEPT, DROP).<br><br><b>-E <i>old-chain-name new-chain-name</i>, --rename-chain <i>old-chain-name new-chain-name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rename a user-defined chain.<br><br><b>-p <i>protocol</i>, --protocol <i>protocol</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches a specific ARP protocol type (e.g., <b>ethernet</b>, <b>ieee802.3</b>).<br><br><b>--opcode <i>opcode</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches a specific ARP operation code (e.g., <b>request</b>, <b>reply</b>, <b>drarp</b>).<br><br><b>-s <i>address[/mask]</i>, --source <i>address[/mask]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the source IP address in the ARP packet.<br><br><b>-d <i>address[/mask]</i>, --destination <i>address[/mask]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the destination IP address in the ARP packet.<br><br><b>--source-mac <i>address</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the source MAC address in the ARP packet (e.g., 00:11:22:33:44:55).<br><br><b>--destination-mac <i>address</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the destination MAC address in the ARP packet.<br><br><b>-i <i>name</i>, --in-interface <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the incoming interface name. Only for <b>INPUT</b> and <b>FORWARD</b> chains.<br><br><b>-o <i>name</i>, --out-interface <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the outgoing interface name. Only for <b>OUTPUT</b> and <b>FORWARD</b> chains.<br><br><b>-j <i>target</i>, --jump <i>target</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target of the rule (e.g., <b>ACCEPT</b>, <b>DROP</b>, <b>LOG</b>, <b>RETURN</b>, or a user-defined chain).<br><br><b>-m <i>match</i> [--<i>option</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads an extension match module and its specific options.<br><br><b>!</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Negates the meaning of the next match or target (e.g., <b>! -s 192.168.1.1</b>).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more verbose output, showing interface name and options.<br><br><b>-n, --numeric</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Numeric output of IP addresses and ports, avoiding DNS lookups.<br><br><b>--line-numbers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show line numbers when listing rules.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program version.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message.<br><br><b>-w [<i>seconds</i>], --wait [<i>seconds</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the xtables exclusive lock before proceeding. Optional timeout in seconds.<br><br><b>--wait-interval <i>microseconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interval to wait between attempts to acquire the xtables lock, for use with <b>--wait</b>.<br><br>


title: DESCRIPTION
content:
<i>arptables</i> is a user-space utility that allows system administrators to configure the ARP packet filter rules in the Linux kernel. It is part of the Netfilter project, analogous to <i>iptables</i> for IP packets and <i>ebtables</i> for Ethernet frames, but specifically designed to handle Address Resolution Protocol (ARP) packets. By defining rules, administrators can filter ARP requests and replies based on various criteria such as MAC addresses, IP addresses, and network interfaces. This capability is crucial for enhancing network security, enabling protection against common attacks like ARP spoofing, man-in-the-middle attacks, and denial-of-service attempts related to ARP.<br><br>Rules are processed sequentially within predefined chains (like <b>INPUT</b>, <b>OUTPUT</b>, <b>FORWARD</b>) or custom user-defined chains. Each rule specifies criteria for matching an ARP packet and a target action to take if a match occurs, such as <b>ACCEPT</b> (allow the packet) or <b>DROP</b> (discard the packet). <i>arptables</i> provides a flexible framework for fine-grained control over ARP traffic, contributing significantly to overall network integrity and stability.


title: CAVEATS
content:
<i>arptables</i> operates exclusively on ARP packets, unlike <i>iptables</i> (IP) or <i>ebtables</i> (Ethernet frames).<br>Rule persistence requires saving the configuration (e.g., using <b>arptables-save</b> and <b>arptables-restore</b>, or integrating with systemd/init scripts) as rules are lost upon reboot.<br>It requires root privileges to configure.<br>Rules are processed sequentially within a chain; misconfigured rules can inadvertently block legitimate ARP traffic.


title: TABLES AND CHAINS
content:
<i>arptables</i> uses tables to organize rules, similar to <i>iptables</i>. The primary table is <b>filter</b>, which is implicitly used if no table is specified. Within this table, there are three built-in chains:<br><b>INPUT</b>: For ARP packets destined to the local host's ARP stack.<br><b>OUTPUT</b>: For ARP packets originating from the local host.<br><b>FORWARD</b>: For ARP packets being routed through the host (typically less common for ARP, but exists for completeness).<br>Administrators can also create custom user-defined chains to group rules logically, which can be jumped to from built-in chains.


title: TARGETS (ACTIONS)
content:
When an ARP packet matches a rule, the rule's target determines the action to take. Common targets include:<br><b>ACCEPT</b>: Allows the ARP packet to pass.<br><b>DROP</b>: Discards the ARP packet.<br><b>LOG</b>: Logs information about the matching packet to the kernel log, then continues to the next rule.<br><b>RETURN</b>: Stops processing rules in the current chain and returns to the calling chain (or the default policy if it was a built-in chain).<br>User-defined chains can also be specified as targets, allowing for modular rule sets.


title: HISTORY
content:
<i>arptables</i> is an integral component of the Linux Netfilter framework, developed alongside <i>iptables</i> and <i>ebtables</i> to provide comprehensive packet filtering capabilities across different network layers. Its inception was driven by the need for granular control over Address Resolution Protocol (ARP) traffic, specifically to mitigate network security threats like ARP spoofing and related man-in-the-middle attacks. As part of the wider Netfilter ecosystem, its development and usage patterns closely mirror those of its IP-layer counterpart, making it a familiar tool for network administrators accustomed to Linux firewalling concepts.


title: SYNOPSIS
content:
<b><I>aws s3 sync</I></b> <i>&lt;SOURCE&gt; &lt;DESTINATION&gt;</i> [<i>&lt;OPTIONS&gt;</i>]<br><br>Examples of SOURCE/DESTINATION:<br><i>&lt;LocalPath&gt;</i><br><i>s3://&lt;Bucket&gt;[/Prefix]</i>


title: PARAMETERS
content:
<b><i>&lt;SOURCE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the source directory or S3 prefix.<br><br><b><i>&lt;DESTINATION&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the destination directory or S3 prefix.<br><br><b><b>--exclude</b> <i>&lt;PATTERN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files or objects that match the specified pattern from the synchronization operation.<br><br><b><b>--include</b> <i>&lt;PATTERN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes files or objects that match the specified pattern. This option overrides any preceding <b>--exclude</b> patterns.<br><br><b><b>--dryrun</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run without making any changes, showing which operations would be performed.<br><br><b><b>--delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes files or objects in the destination that are not present in the source. <b>Use with extreme caution.</b><br><br><b><b>--exact-timestamps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares timestamps with millisecond precision instead of just second precision to determine if a file needs to be synchronized.<br><br><b><b>--acl</b> <i>&lt;ACL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the access control list (ACL) for the uploaded objects. E.g., 'public-read', 'private'.<br><br><b><b>--storage-class</b> <i>&lt;CLASS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the storage class for the uploaded objects. E.g., 'STANDARD', 'INTELLIGENT_TIERING', 'GLACIER_IR', 'DEEP_ARCHIVE'.<br><br><b><b>--sse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables server-side encryption for the uploaded objects using S3-managed encryption keys.<br><br><b><b>--sse-kms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables server-side encryption for the uploaded objects using AWS KMS-managed keys. Optionally specify 'KMSKeyId'.<br><br><b><b>--sse-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables server-side encryption for the uploaded objects using customer-provided encryption keys. Requires 'SSECustomerKey' and 'SSECustomerKeyMD5'.<br><br><b><b>--profile</b> <i>&lt;PROFILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a specific profile from the AWS credentials file to authenticate the command.<br><br>


title: DESCRIPTION
content:
The <b><I>aws s3 sync</I></b> command provides a robust and efficient way to synchronize files and directories between a local filesystem and an Amazon S3 bucket, or between two S3 locations.<br><br>It intelligently determines which files need to be copied by comparing file sizes and last modified timestamps (and MD5 checksums for S3 objects). This makes it significantly more efficient than simple copy operations, especially for large datasets or repeated synchronization tasks, as it only transfers new or modified files.<br><br>Common use cases include backing up local data to S3, deploying website content, replicating data between S3 buckets, and ensuring data consistency across various environments. It supports powerful options for filtering files, controlling access, and managing storage classes, offering a cloud-native equivalent to the traditional <i>rsync</i> utility for S3.


title: CAVEATS
content:
The <b>--delete</b> option is powerful and can lead to irreversible data loss. Always perform a <b>--dryrun</b> before using <b>--delete</b> to understand the impact.<br><br>Synchronization is primarily based on file size and last modified timestamp. While efficient, differences in timestamp precision between local filesystems and S3 can sometimes lead to unexpected re-transfers. The <b>--exact-timestamps</b> option can mitigate this but might also increase transfer frequency.<br><br>The command generally performs a one-way sync from source to destination. It does not handle bi-directional synchronization or advanced versioning logic automatically.


title: COMPARISON LOGIC
content:
When synchronizing, <b><I>aws s3 sync</I></b> compares files/objects based on their size and last modified timestamp. If both are identical, the file is skipped. For S3-to-S3 transfers or after uploading local files, it also uses the ETag (often an MD5 checksum for non-multipart uploads) to verify integrity and determine if an object has changed.


title: MULTIPART UPLOADS
content:
For large files, <b><I>aws s3 sync</I></b> automatically leverages S3's multipart upload capability. This breaks large files into smaller parts, uploading them concurrently, which significantly improves transfer speed and resilience, especially over unstable networks. If a part fails, only that part needs to be re-uploaded.


title: HISTORY
content:
The <b><I>aws s3 sync</I></b> command is an integral part of the AWS Command Line Interface (CLI), which was first released in 2013. It quickly became a crucial utility for developers and system administrators, providing a native and optimized way to interact with Amazon S3. Its development focused on addressing the common need for efficient, robust data synchronization that was previously handled by general-purpose tools like <i>rsync</i> or custom scripts, adapting them for the cloud-object storage paradigm. Over the years, it has been continually updated to support new S3 features, performance improvements, and user experience enhancements.


title: SYNOPSIS
content:
<I>az pipelines &lt;subcommand&gt; [options]</I><br><br>Common subcommands and their typical usage:<br><I>az pipelines run --definition-id &lt;id&gt; [--branch &lt;branch&gt;] [--org &lt;organization_url&gt;] [--project &lt;project_name&gt;]</I><br><I>az pipelines list [--org &lt;organization_url&gt;] [--project &lt;project_name&gt;]</I><br><I>az pipelines show --definition-id &lt;id&gt; [--org &lt;organization_url&gt;] [--project &lt;project_name&gt;]</I><br><I>az pipelines create --name &lt;pipeline_name&gt; --repository &lt;repo_name&gt; --repository-type &lt;type&gt; --yml-path &lt;path&gt; [--org &lt;organization_url&gt;] [--project &lt;project_name&gt;]</I>


title: PARAMETERS
content:
<b>run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queues a new run for a pipeline. Requires <b>--definition-id</b> or <b>--definition-name</b>.<br><br><b>--definition-id <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;ID of the pipeline definition. Required for 'run', 'show'.<br><br><b>--definition-name <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the pipeline definition. Alternative to <b>--definition-id</b>.<br><br><b>--branch <branch_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Branch to queue the run for. Default is the pipeline's default branch.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all pipelines in a project.<br><br><b>show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gets the details of a specific pipeline definition.<br><br><b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new pipeline. Requires repository details and path to YAML file.<br><br><b>--name <pipeline_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the new pipeline to create.<br><br><b>--repository <repo_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the repository where the pipeline YAML is located.<br><br><b>--repository-type <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Type of the repository (e.g., TfsGit, GitHub, Bitbucket). Defaults to TfsGit.<br><br><b>--yml-path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the YAML file within the repository (e.g., azure-pipelines.yml).<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an existing pipeline definition.<br><br><b>delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a pipeline definition. Requires <b>--definition-id</b> or <b>--definition-name</b>.<br><br><b>--org <organization_url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Azure DevOps organization URL (e.g., https://dev.azure.com/myorg). Required if not set as default.<br><br><b>--project <project_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name or ID of the Azure DevOps project. Required if not set as default.<br><br><b>--output <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format: json (default), jsonc, table, tsv, yaml, none.<br><br><b>--query <JMESPath></b><br>&nbsp;&nbsp;&nbsp;&nbsp;JMESPath query string. Filters and formats output.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity to show all debug logs.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show debug logs.<br><br><b>--help -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help for the command or subcommand.<br><br>


title: DESCRIPTION
content:
<b>az pipelines</b> is a powerful command within the Azure Command Line Interface (CLI) that enables developers and operations teams to manage Azure DevOps build and release pipelines directly from the terminal. It provides a comprehensive set of functionalities to interact with CI/CD (Continuous Integration/Continuous Delivery) processes, including creating new pipelines, listing existing ones, viewing details, initiating runs, updating configurations, and deleting pipelines.<br><br>This command is an essential tool for automating pipeline management tasks, integrating with scripts, and streamlining DevOps workflows. It allows for programmatic control over the entire lifecycle of a pipeline, from definition to execution and monitoring, making it a cornerstone for efficient and repeatable software delivery in an Azure DevOps environment.


title: CAVEATS
content:
<ul><li>Requires the Azure CLI to be installed and the <b>azure-devops</b> extension to be enabled.</li><li><b>Authentication:</b> Users must be logged in to Azure CLI (<b>az login</b>) and have appropriate permissions within the target Azure DevOps organization and project to perform operations.</li><li><b>Context:</b> <b>az pipelines</b> commands operate within the context of an Azure DevOps organization and project, which often need to be specified using <b>--org</b> and <b>--project</b> or set as defaults.</li><li><b>Network Connectivity:</b> A stable internet connection is required to communicate with Azure DevOps services.</li><li><b>YAML-based Pipelines:</b> While the command can interact with both Classic and YAML pipelines, the <b>create</b> command primarily focuses on YAML-based definitions.</li></ul>


title: AUTHENTICATION AND DEFAULTS
content:
Before using <b>az pipelines</b>, ensure you are logged into Azure CLI using <b>az login</b>. You can also set default organization and project using <b>az devops configure --defaults organization=YOUR_ORG project=YOUR_PROJECT</b> to avoid specifying them with every command.


title: PIPELINE YAML DEFINITION
content:
For creating new pipelines, <b>az pipelines create</b> often requires specifying a path to a YAML file that defines the pipeline's steps, stages, and triggers. This YAML file is typically stored in a Git repository connected to Azure DevOps.


title: HISTORY
content:
The <b>az pipelines</b> command is a key part of the <b>azure-devops</b> extension for the Azure CLI. The Azure CLI itself was introduced to provide a cross-platform command-line experience for managing Azure resources. As Microsoft's DevOps story evolved from Team Foundation Server (TFS) and Visual Studio Team Services (VSTS) to Azure DevOps, the Azure CLI adapted to include rich functionality for managing these services. The <b>az pipelines</b> command specifically matured to support the increasing adoption of YAML-based pipelines, offering programmatic control over CI/CD definitions and runs, which became crucial for Git-centric and infrastructure-as-code workflows. Its development has focused on parity with the web portal's capabilities, enabling full automation of DevOps practices.


title: SYNOPSIS
content:
<b>az tag</b> {<i>create</i> | <i>delete</i> | <i>list</i> | <i>update</i>} [--resource-id <i>ID</i> | --resource-group <i>NAME</i>] [options]


title: PARAMETERS
content:
<b><b>--resource-id</b> <I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The full resource ID of the Azure resource (e.g., subscription, resource group, or specific resource) to manage tags for. Example: /subscriptions/<I>ID</I>/resourceGroups/<I>RG</I>/providers/<I>Microsoft.Compute</I>/virtualMachines/<I>VM</I>.<br><br><b><b>--resource-group</b> <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the resource group that contains the resource. This is an alternative to <b>--resource-id</b> when targeting a resource group or a resource within a known group.<br><br><b><b>--name</b> <I>KEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name (key) of the tag to be created or deleted. Used specifically with the 'create' subcommand for a single tag, or with 'delete' to remove a specific tag key.<br><br><b><b>--tags</b> <I>KEY[=VALUE] KEY[=VALUE]...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Space-separated tags in 'key=value' format. If a value is not specified for a key, it defaults to an empty string. Example: 'Environment=Prod Project=Alpha'. This parameter is used with 'create', 'update', and 'delete' subcommands.<br><br><b><b>--operation</b> {<I>replace</I> | <I>merge</I> | <I>delete</I>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required when using the <i>update</i> subcommand. Specifies how tags are applied: <i>replace</i> (replaces all existing tags with the new ones), <i>merge</i> (adds new tags and updates existing ones), or <i>delete</i> (removes specified tags from the resource).<br><br><b><b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for confirmation. This option is typically used with the <i>delete</i> subcommand to suppress interactive confirmation prompts for tag removal.<br><br>


title: DESCRIPTION
content:
<i>az tag</i> commands provide a powerful way to manage metadata on Azure resources, resource groups, and subscriptions through key-value pairs known as tags.<br><br>Tags are essential for organizing, categorizing, and managing Azure deployments, especially at scale. They enable capabilities such as cost allocation, applying governance policies (e.g., ensuring all resources have an 'Environment' tag), and streamlining automation scripts. For instance, you can use tags to identify resources belonging to a specific department, environment (dev/test/prod), or project.<br><br>The command group allows users to programmatically <b>create</b> new tags, <b>update</b> existing ones (merging, replacing, or deleting specific tags), <b>delete</b> tags, and <b>list</b> all tags associated with a given resource or scope. This flexibility makes <i>az tag</i> indispensable for maintaining a well-governed and organized Azure environment.


title: CAVEATS
content:
Limitations apply to Azure tags:<br><i>Tag limits:</i> A resource or resource group can have a maximum of 50 tags. Subscription tags are limited to 10.<br><i>Case-insensitivity:</i> Tag names are case-insensitive when performing operations, but the casing is preserved.<br><i>Character limits:</i> Tag names are limited to 512 characters, and tag values to 256 characters.<br><i>Permissions:</i> Users require specific permissions (e.g., 'Microsoft.Resources/tags/write') to manage tags, typically covered by the 'Contributor' or 'Owner' roles.


title: TAGGING BEST PRACTICES
content:
Tags are critical for implementing proper cloud governance. Best practices include defining a consistent tagging strategy (e.g., Environment, CostCenter, Owner, Project), enforcing it with Azure Policy, and using tags for cost management and reporting. Effective tagging ensures resources are easily identifiable, manageable, and auditable.


title: SCOPE OF TAGGING
content:
Tags can be applied at different scopes within Azure: at the subscription level, resource group level, or directly on individual resources. Tags applied at a higher scope (e.g., resource group) are not automatically inherited by resources within that scope, but can be propagated or enforced using Azure Policy.


title: HISTORY
content:
The <i>az tag</i> command group is an integral part of the Azure CLI, which was first released in 2016. Tagging itself is a foundational capability within Azure for resource organization and governance. As Azure CLI evolved, the <i>az tag</i> commands were developed to provide a robust, programmatic interface for managing these critical resource metadata. Its development has focused on reflecting the evolving capabilities of Azure resource management and providing a consistent command-line experience for users.


title: SYNOPSIS
content:
Given that <I>az-term</I> is not a standard Linux command, a universally recognized synopsis cannot be provided. If it were a real command, its synopsis would typically follow the pattern: <br><I><b>az-term</b> [options] [arguments]</I>


title: DESCRIPTION
content:
The command <I>az-term</I> does not appear to be a standard utility or a widely recognized command in common Linux distributions. Extensive searches in official documentation, manual pages, and common package repositories do not yield information regarding a standalone <I>az-term</I> command. It is highly probable that <I>az-term</I> refers to: <br>1. <I>A custom script or alias:</I> Defined by a user or an organization for specific internal purposes.<br>2. <I>A component of a niche application:</I> Not broadly distributed or documented.<br>3. <I>A typographical error:</I> Potentially intended for a different, existing command (e.g., related to Azure CLI commands starting with <I>az</I>).<br>4. <I>A conceptual or hypothetical command:</I> Without a real-world implementation.<br><br>As such, a definitive analysis of its syntax, parameters, or behavior cannot be provided based on standard Linux command knowledge.


title: CAVEATS
content:
As <I>az-term</I> is not a standard Linux command, attempting to execute it in a typical environment will likely result in a 'command not found' error. Any functionality or behavior associated with this name would be entirely dependent on its specific implementation (if any) in a particular environment. Users should not expect <I>az-term</I> to be present or functional on a general Linux system.


title: VERIFICATION ON YOUR SYSTEM
content:
To ascertain if <I>az-term</I> exists on your specific Linux system, you can use common shell commands:<br><ul><li>Use <i>which az-term</i> to check if the command is in your PATH.</li><li>Try <i>man az-term</i> to look for a manual page.</li><li>Execute <i>type az-term</i> to see if it's an alias, function, or executable.</li></ul>If these commands return no output or an error, it confirms the non-standard nature of the command in that particular environment.


title: HISTORY
content:
There is no documented history for a standard <I>az-term</I> Linux command, as it does not appear to be part of the official Linux utilities or a widely adopted open-source project. Its potential origins would be specific to individual users, projects, or highly specialized deployments.


title: PARAMETERS
content:
<b><I>-t</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the current terminal width for the output. This option overrides any specified <I>-w</I> width.<br><br><b><I>-w</I> <I>width</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the width of the output in characters. If this option is not given, the default width is often 132 characters (historically related to printer widths).<br><br><b><I>message</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more words or strings to be converted into large characters. Each word provided as an argument will typically be printed on its own line, or separated by a larger space if concatenated.<br><br>


title: DESCRIPTION
content:
The <b>banner</b> command generates large, stylized ASCII art characters from input text, displaying them on standard output. Originally used for creating large-format printouts (e.g., banners for dot-matrix printers), it's now often employed to produce eye-catching messages directly in the terminal. Each character is typically constructed from a matrix of '<b>#</b>' or '<b>*</b>' symbols, making it highly visible. It's useful for drawing attention to specific messages in scripts, terminal sessions, or log files. The output format can vary slightly depending on the specific implementation, but the core function of large character rendering remains consistent.


title: CAVEATS
content:
Output can be very wide, potentially wrapping lines in smaller terminals if <I>-t</I> or an appropriate <I>-w</I> is not used.<br>Behavior and available options can vary significantly between different <b>banner</b> implementations (e.g., <b>bsd-utils</b> <b>banner</b> vs. <b>sysvbanner</b>).<br>It uses a fixed font, so character rendering is basic compared to modern ASCII art generators.<br>Not all characters or symbols may be supported or rendered correctly.


title: COMPATIBILITY AND IMPLEMENTATIONS
content:
The behavior of <b>banner</b> can differ based on its specific implementation. Some Linux distributions include <b>banner</b> as part of <b>bsd-utils</b>, offering the <I>-t</I> and <I>-w</I> options. Other systems might provide <b>sysvbanner</b> (often symlinked as <b>banner</b> from <b>sysvinit-utils</b>), which typically doesn't have options and prints the entire input string on a single line using a fixed block font. Users should consult their system's <b>man banner</b> page for precise details of their installed version.


title: HISTORY
content:
The <b>banner</b> command is a classic Unix utility, dating back to early BSD distributions. Its primary purpose was to print large, attention-grabbing text on continuous-form paper using dot-matrix printers. Over time, its use transitioned to the terminal, where it became a simple way to display prominent messages. While newer, more sophisticated ASCII art generators like <b>figlet</b> and <b>toilet</b> offer greater flexibility and font options, <b>banner</b> remains available on many systems as a lightweight, historical tool, often part of utility packages like <b>bsd-utils</b> or <b>sysvinit-utils</b>. Its simplicity ensures its continued, albeit niche, utility.


title: SYNOPSIS
content:
<b>bash</b> [<I>options</I>] [<I>file</I>]<br><b>bash</b> [<I>options</I>] <b>-c</b> <I>command-string</I> [<I>command-name</I> [<I>arguments</I>...]]<br><b>bash</b> [<I>options</I>] <b>-s</b> [<I>arguments</I>...]


title: PARAMETERS
content:
<b>-c <command_string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute <I>command_string</I> as a command.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the shell to be interactive.<br><br><b>-l, --login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make this shell a login shell.<br><br><b>--norc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not read the startup file <i>~/.bashrc</i>.<br><br><b>--rcfile <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute commands from <I>file</I> instead of <i>~/.bashrc</i>.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read commands from standard input.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print commands and their arguments as they are executed.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>bash</i>, or the <b>B</b>ourne-<b>A</b>gain <b>SH</b>ell, is a Unix shell and command language interpreter. It's the default interactive shell on most Linux distributions and macOS. Bash executes commands read from standard input, a file, or a string. It supports powerful features such as command-line editing, command history, job control, aliases, functions, and programmable completion. Beyond interactive use, bash is a robust scripting language, widely used for automating tasks, system administration, and general-purpose programming. It combines features from the original Bourne shell (<i>sh</i>) with enhancements from <i>csh</i> and <i>ksh</i>, making it a versatile and widely adopted tool for both novice and experienced users to interact with the operating system.


title: CAVEATS
content:
<i>bash</i> behavior can differ significantly between login and non-login shells, and interactive vs. non-interactive sessions, due to different startup file (<i>.profile</i>, <i>.bash_profile</i>, <i>.bashrc</i>) processing. Scripts intended for portability should ideally adhere to POSIX <i>sh</i> syntax to avoid <i>bash</i>-specific features. Historically, <i>bash</i> was notably affected by the "Shellshock" vulnerability, highlighting the importance of keeping software updated.


title: STARTUP FILES
content:
When <i>bash</i> starts, it executes commands from various startup files depending on whether it's a login shell, non-login interactive shell, or non-interactive shell. Common files include <i>~/.bash_profile</i> (login shells), <i>~/.bashrc</i> (interactive non-login shells), and <i>/etc/profile</i> and <i>/etc/bash.bashrc</i> (system-wide). These files are crucial for setting environment variables, aliases, and functions.


title: JOB CONTROL
content:
<i>bash</i> supports job control, allowing users to manage multiple processes running in the foreground or background. Commands can be suspended (<i>Ctrl+Z</i>), sent to the background (<i>&</i> or <i>bg</i>), brought to the foreground (<i>fg</i>), and listed (<i>jobs</i>). This feature enhances productivity for interactive shell sessions.


title: HISTORY
content:
<i>bash</i> was created by Brian Fox for the GNU Project as a free software replacement for the Bourne shell (<i>sh</i>). First released in 1989, it quickly gained popularity due to its robust feature set, incorporating desirable elements from <i>ksh</i> and <i>csh</i>, such as command-line editing and history. It became the default shell for most Linux distributions and macOS, playing a pivotal role in the open-source ecosystem.


title: SYNOPSIS
content:
<b>bedtools</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><br>Example: <b>bedtools</b> <i>intersect</i> <b>-a</b> <i>file_A.bed</i> <b>-b</b> <i>file_B.bed</i>


title: PARAMETERS
content:
<b>intersect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Finds overlapping intervals between two BED/GFF/VCF files (A and B).<br><br><b>merge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Combines overlapping or adjacent intervals in a single file into a consolidated set.<br><br><b>subtract</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the portions of intervals in file A that overlap with intervals in file B.<br><br><b>flank</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates new intervals that flank (upstream or downstream) existing intervals relative to strand.<br><br><b>slop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extends the start and/or end of intervals by a specified number of bases.<br><br><b>sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts BED/GFF/VCF files by chromosome and then by start position.<br><br><b>closest</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Finds the closest interval in file B for each interval in file A, reporting distance.<br><br><b>coverage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Computes the coverage of intervals in file A by intervals in file B, reporting depth and fraction.<br><br><b>getfasta</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts DNA sequences corresponding to intervals from a FASTA reference genome.<br><br><b>annotate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds annotations (e.g., counts, sums, means) to intervals from another file based on overlaps.<br><br>


title: DESCRIPTION
content:
<i>bedtools</i> is a comprehensive, open-source suite of command-line utilities designed for manipulating genomic features and intervals. Developed by Aaron Quinlan and his team, it provides efficient tools for common genomics tasks such as intersecting, merging, counting, and comparing genomic regions across various file formats, including BED, GFF, VCF, and BAM. Its modular design allows users to combine multiple operations through piping, making it an indispensable tool for bioinformatics researchers and computational biologists. <i>bedtools</i> excels in speed and versatility, facilitating complex analyses on large-scale genomic datasets, from identifying overlaps between gene annotations and sequencing reads to performing advanced feature arithmetic.


title: CAVEATS
content:
Users must ensure consistency in chromosome naming conventions (e.g., 'chr1' vs. '1') across all input files. <i>bedtools</i> typically uses 0-based start coordinates and 1-based end coordinates for BED files, which can be a common source of off-by-one errors if not handled carefully. Performance for large files can be optimized significantly by pre-sorting input files, especially for operations like <i>intersect</i> and <i>merge</i>.


title: COORDINATE SYSTEM
content:
BED files, which are central to <i>bedtools</i> operations, typically use a 0-based start coordinate and a 1-based end coordinate. This means the start position is inclusive (the first base of the interval), and the end position is exclusive (the base *after* the end of the interval). For example, a 10-base interval from 100 to 109 would be represented as 'chr1\t100\t110' in BED format. Understanding this convention is crucial to avoid off-by-one errors.


title: INPUT/OUTPUT FORMATS & PIPING
content:
<i>bedtools</i> supports a wide range of genomic file formats beyond BED, including GFF/GTF, VCF, BAM, and FASTA. Its design emphasizes standard input/output (stdin/stdout), allowing seamless integration into complex command-line pipelines. Users can pipe the output of one <i>bedtools</i> subcommand directly as input to another, or combine it with other Unix utilities like <b>grep</b>, <b>awk</b>, and <b>sort</b> for highly customized analyses.


title: HISTORY
content:
<i>bedtools</i> was initially developed by <b>Aaron R. Quinlan</b> and his team at the University of Utah and later at the University of Virginia. The first major release was around 2009-2010. It quickly gained widespread adoption in the genomics community due to its speed, comprehensive functionality, and ease of use in command-line scripting. Its development is ongoing, with new features and optimizations regularly added, reflecting the evolving needs of genomics research. It is a cornerstone tool in many bioinformatics pipelines.


title: PARAMETERS
content:
<b><I>capture_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the .cap file generated by the <b>besside-ng</b> tool. This file contains the captured wireless network traffic from which WPS-related information will be extracted.<br><br>


title: DESCRIPTION
content:
The <b>besside-ng-crawler</b> command is a utility within the <I>Aircrack-ng</I> suite designed to process capture files generated by <b>besside-ng</b>. Its primary function is to 'crawl' or analyze these .cap files to extract information crucial for exploiting Wi-Fi Protected Setup (WPS) vulnerabilities. Specifically, it identifies and processes EAPOL (Extensible Authentication Protocol over LAN) packets and other data that contain WPS handshake elements, which can then be used to brute-force or recover WPS PINs. It streamlines the WPS attack process by consolidating relevant data from raw packet captures, making it easier to identify WPS-enabled access points and extract the necessary information for a WPS PIN cracking attempt. It acts as a data pre-processor for further WPS attacks.


title: CAVEATS
content:
<b>Dependency on besside-ng:</b> This command requires capture files specifically generated by the <b>besside-ng</b> tool. Files from other capture tools may not contain the necessary format or data for successful processing.<br><b>WPS Specific:</b> It is solely useful for networks utilizing WPS. If the target network does not have WPS enabled, or if WPS has been disabled, this tool will not yield useful information.<br><b>Data Quality:</b> The effectiveness of <b>besside-ng-crawler</b> heavily relies on the quality and completeness of the captured data. Incomplete or corrupted captures may lead to inaccurate or no results.


title: TYPICAL WORKFLOW INTEGRATION
content:
<b>besside-ng-crawler</b> typically fits into a larger WPS cracking workflow. First, <b>airmon-ng</b> is used to put the wireless adapter into monitor mode. Then, <b>besside-ng</b> is run to capture traffic and attempt to obtain WPS parameters and handshake data, saving it to a .cap file. Finally, <b>besside-ng-crawler</b> processes this .cap file to identify and extract the relevant WPS information for further analysis or brute-force attempts on the WPS PIN using other tools.


title: OUTPUT INFORMATION
content:
The output of <b>besside-ng-crawler</b> generally provides a summary of detected APs, their BSSIDs, ESSIDs, and whether WPS information was successfully extracted. It helps in quickly identifying which WPS-enabled networks have enough captured data to proceed with a PIN cracking attempt.


title: HISTORY
content:
<b>besside-ng-crawler</b> is an integral part of the <I>Aircrack-ng</I> project, a comprehensive suite of tools for auditing wireless networks. The Aircrack-ng suite itself is a continuation of the original Aircrack project. As Wi-Fi security evolved and new vulnerabilities like WPS were discovered, tools like <b>besside-ng</b> were developed to exploit these. <b>besside-ng-crawler</b> was introduced as a companion utility to process the specific capture formats and data generated by <b>besside-ng</b>, facilitating the automated extraction of WPS-related information. Its development is tied to the ongoing research and exploitation of WPS vulnerabilities within the wireless security community.


title: SYNOPSIS
content:
<b><I>bird</I></b> [-c <I>config_file</I>] [-d] [-D <I>level</I>] [-p] [-s <I>socket_file</I>] [-u <I>user</I>] [-g <I>group</I>]


title: PARAMETERS
content:
<b>-c <I>config_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file to load instead of the default (e.g., /etc/bird/bird.conf).<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the daemon in debug mode, writing verbose output to stderr. Useful for troubleshooting.<br><br><b>-D <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debugging level. Higher levels (e.g., 5 or 6) provide more detailed output.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses and checks the syntax of the specified configuration file and then exits without starting the daemon. Essential for configuration validation.<br><br><b>-s <I>socket_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the control socket file that <b><I>birdc</I></b> will use to communicate with the daemon. Defaults to /var/run/bird.ctl.<br><br><b>-u <I>user</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the daemon's effective user ID after initialization for enhanced security, dropping root privileges.<br><br><b>-g <I>group</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the daemon's effective group ID after initialization for enhanced security, dropping root privileges.<br><br>


title: DESCRIPTION
content:
The <b><I>bird</I></b> command refers to the <b>BIRD</b> (Border Gateway Protocol, Interior Gateway Protocol) routing daemon. It's a powerful and highly configurable daemon designed to implement and manage various dynamic routing protocols such as BGPv4, RIPv2, OSPFv2, and OSPFv3 on Unix-like operating systems, primarily Linux.<br><br>BIRD handles routing tables, exchanges routing information with other routers, and applies complex routing policies based on its configuration. It supports both IPv4 and IPv6 routing.<br><br>While <b><I>bird</I></b> itself is the daemon process that runs in the background, its primary interaction and control are typically performed via the <b><I>birdc</I></b> client command, which communicates with the daemon through a control socket.


title: CAVEATS
content:
Configuring <b><I>bird</I></b> requires substantial knowledge of networking, routing protocols (BGP, OSPF, RIP), and its specific configuration language. Errors in configuration can lead to network instability, routing blackholes, or loops. Most ongoing interaction and management of the running daemon occur via the <b><I>birdc</I></b> client, not direct command-line invocation of <b><I>bird</I></b> itself after initial startup.


title: CONTROL WITH BIRDC CLIENT
content:
The <b><I>bird</I></b> daemon is primarily controlled and managed using the <b><I>birdc</I></b> command-line client. <b><I>birdc</I></b> connects to the daemon's control socket to issue commands such as 'show protocols', 'show routes', 'configure', 'reload', 'restart', and 'quit', allowing real-time monitoring and configuration changes.


