# CommandSection

title: THE NIX STORE
content:
The <i>Nix store</i>, typically located at <code>/nix/store</code>, is the central immutable repository where all <i>Nix</i>-managed software, libraries, and configurations are stored. Each package or component in the store has a unique cryptographic hash in its path (e.g., <code>/nix/store/<i>&lt;hash&gt;</i>-<i>&lt;name&gt;</i></code>), ensuring that different versions or builds of the same software can coexist without conflict and that outputs are always identical for identical inputs. This isolation is key to <i>Nix</i>'s reproducibility and reliability.


title: NIX LANGUAGE AND EXPRESSIONS
content:
<i>Nix</i> uses its own declarative, lazily evaluated, functional programming language (the <i>Nix language</i>) to define packages, system configurations, and build instructions. These definitions are called <i>Nix expressions</i>. This language allows users to precisely specify dependencies, build steps, and environment setups in a highly composable and reusable manner, making complex configurations manageable and reproducible across different systems.


title: NIX FLAKES
content:
<i>Nix Flakes</i> are a modern, experimental feature (now widely adopted) that simplify managing and sharing <i>Nix</i> projects. A flake is a directory containing a <code>flake.nix</code> file that declares its inputs (dependencies) and outputs (packages, applications, dev shells, etc.). Flakes provide a standardized way to define reproducible development environments and deployable artifacts, improving usability and portability of <i>Nix</i> projects.


title: HISTORY
content:
The <i>Nix</i> package manager was conceived by <i>Eelco Dolstra</i> as part of his doctoral research at <i>Utrecht University</i> in the early 2000s, with the first public release around 2003. Its development was driven by the desire to overcome the reproducibility and dependency problems inherent in traditional package management systems. The ideas laid out in <i>Nix</i> later formed the foundation for <i>NixOS</i>, a Linux distribution built entirely on <i>Nix</i>'s declarative and reproducible principles. Over the years, <i>Nix</i> has evolved significantly, gaining traction among developers and system administrators seeking robust, reliable, and reproducible software environments, particularly with the advent of 'Nix Flakes' in recent years streamlining its usage.


title: PARAMETERS
content:
<b>--attr <name>, -A <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific attribute from the top-level Nix expression to build. Useful for building specific components from a large Nix file.<br><br><b>--expr <expression>, -E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interprets arguments as Nix expressions rather than file paths. Allows building a derivation defined directly on the command line.<br><br><b>--out-link <name>, -o <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the symbolic link created in the current directory, defaulting to `result`. Use `--no-out-link` to prevent creating one.<br><br><b>--max-jobs <number>, -j <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the maximum number of parallel build jobs. `auto` uses the number of CPU cores; `0` means unlimited.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a full stack trace in case of evaluation errors within the Nix expression, aiding debugging.<br><br><b>--arg <name> <value>, --argstr <name> <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes arguments to the Nix expression. `--arg <name> <value>` passes a Nix value (e.g., a list), while `--argstr <name> <string>` passes a string value.<br><br><b>--keep-failed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the deletion of temporary build directories for failed builds, allowing inspection of the build environment and logs.<br><br><b>--keep-going</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues building other derivations even if some dependencies or independent derivations fail. The command will still exit with a non-zero status if any build failed.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emits structured JSON output instead of human-readable logs for build events, useful for scripting and integration.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would be built without actually performing the build. This can be useful for planning and debugging dependencies.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of logging output, providing more detailed information about the build process.<br><br>


title: DESCRIPTION
content:
The <i>nix-build</i> command is a fundamental tool within the Nix ecosystem, primarily used to build Nix <i>derivations</i>. A derivation is a specification of a build process, including its inputs, outputs, and build script. <i>nix-build</i> takes one or more Nix expressions (typically `.nix` files) or attributes from a Nix expression as input, which ultimately evaluate to derivations. <br><br>Upon execution, <i>nix-build</i> first <i>instantiates</i> the Nix expression into a concrete derivation in the Nix store. Then, it <i>realizes</i> this derivation by executing the specified build actions. It automatically handles dependencies, fetching or building them as needed, ensuring that builds are isolated, reproducible, and atomic. If a build is successful, <i>nix-build</i> creates a symbolic link in the current directory (typically `result`) pointing to the build output in the Nix store. This command is the primary way to compile, package, and install software using Nix.


title: CAVEATS
content:
<b>Disk Space Consumption:</b> Nix stores all build inputs and outputs in the Nix store, which can consume significant disk space over time. Regular garbage collection (`nix-collect-garbage`) is essential to reclaim space.<br><b>Build Times:</b> For complex software or when starting with a new Nix installation, initial builds can be lengthy as all dependencies might need to be downloaded or compiled from scratch.<br><b>Purity Requirements:</b> Builds are expected to be pure. Relying on external factors like unmanaged filesystems or network access (outside of `fetch*` functions) can lead to non-reproducible results. Debugging impure builds can be challenging.<br><b>Nix Language Learning Curve:</b> Effectively using `nix-build` and extending its capabilities often requires a solid understanding of the Nix language and its core concepts (derivations, attributes, builtins, etc.).


title: BUILD PROCESS OVERVIEW
content:
When you run <i>nix-build</i>, it primarily performs two main stages:<br>1. <b>Instantiation:</b> The Nix expression (e.g., your `default.nix` file) is evaluated to produce a derivation, which is a low-level, abstract description of a build. This phase generates a `.drv` file in the Nix store.<br>2. <b>Realization:</b> The derivation is then executed. This involves fetching source code, applying patches, compiling, and installing, with all dependencies automatically managed by Nix. The output of this phase is stored in the Nix store, identified by a unique hash.


title: OUTPUT SYMBOLIC LINK
content:
By default, upon a successful build, <i>nix-build</i> creates a symbolic link named `result` in the current directory. This link points directly to the output path of the built derivation in the Nix store (e.g., `/nix/store/hash-name-package`). This `result` symlink is a convenient and common way to access the built artifacts without needing to know their specific hash in the store.


title: HISTORY
content:
<i>nix-build</i> has been a core component of the Nix package manager since its early days, embodying the fundamental principle of Nix: reproducible, atomic builds by defining software as derivations. While the newer, unified <i>nix</i> command now offers `nix build` as a more modern interface that consolidates many operations, <i>nix-build</i> remains widely used and understood as the classic way to initiate a build within the Nix ecosystem. Its stable and foundational role reflects its importance in the project's evolution and its continued relevance.


title: PARAMETERS
content:
<b>--attr <attr-path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the specified attribute from a Nix expression (e.g., <b>pkgs.hello</b> from a flake or <b>default.nix</b>). Supports multiple <b>--attr</b> flags.<br><br><b>--expr <expression></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the given Nix expression string directly, without needing a file. For example: <b>nix-build --expr 'with import <nixpkgs> {}; hello'</b>.<br><br><b>--file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the expression found in the specified Nix file (default is <b>default.nix</b> or a flake in the current directory).<br><br><b>--no-out-link</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create a symlink named <b>result</b> in the current directory pointing to the build output.<br><br><b>--out-link <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a symlink named <b>path</b> (instead of <b>result</b>) to the build result in the current directory.<br><br><b>--arg <name> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass a value for a top-level argument to the Nix expression being built. The value is interpreted as a Nix expression.<br><br><b>--argstr <name> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass a string value for a top-level argument to the Nix expression. The value is passed as a literal string.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluate the expression and determine what would be built, but do not perform any actual builds or store operations.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output build information and results in JSON format, suitable for machine parsing.<br><br><b>--keep-failed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not delete the temporary build directory if the build fails. Useful for debugging build failures.<br><br><b>--keep-going</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue building other derivations even if one or more derivations fail.<br><br><b>--max-jobs <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow at most N jobs to run in parallel. A value of 0 means infinite jobs (limited by CPU cores).<br><br><b>--cores <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of CPU cores to use for local builds. A value of 0 means all available cores.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show evaluation stack traces when an error occurs during Nix expression evaluation, providing more context for debugging.<br><br><b>--no-allow-substitutes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable fetching pre-built binaries (substitutes) from configured binary caches. Forces local builds.<br><br><b>--fallback</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow falling back to building locally if fetching a substitute from a binary cache fails.<br><br><b>--rebuild</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force rebuilding of a derivation, even if it already exists in the Nix store and is valid.<br><br><b>--system <system></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the system architecture for which to build (e.g., <b>x86_64-linux</b>, <b>aarch64-darwin</b>).<br><br><b>--verbose <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the verbosity level for logging messages. Higher levels provide more detailed output.<br><br>


title: DESCRIPTION
content:
<i>nix-build</i> is a fundamental command in the Nix ecosystem. It evaluates a Nix expression, which typically defines a software package or a set of packages, and then orchestrates its build. The building process involves fetching source code, applying patches, compiling, and installing components into the isolated Nix store. A key feature of Nix builds is their isolation and reproducibility: each build runs in a clean environment, ensuring only declared inputs are available.<br><br>Upon successful completion, <i>nix-build</i> creates a symlink named <b>result</b> (by default) in the current directory, pointing to the built output in the Nix store. This provides easy access to the artifact. It also leverages Nix's caching mechanism, meaning if an identical package has been built before (locally or available via a binary cache), it won't be rebuilt, significantly speeding up development.


title: CAVEATS
content:
Builds can be resource-intensive, consuming significant CPU, memory, and disk space.<br>Network access is often required for fetching source code and pre-built binaries (substitutes).<br>Reproducibility can be compromised if impure inputs are used (e.g., through <b>--impure</b> or by not using flakes effectively).


title: BUILD OUTPUT SYMLINK
content:
By default, <i>nix-build</i> creates a symlink named <b>result</b> in the current directory, pointing to the built derivation in the Nix store. This symlink provides a convenient way to access the built artifact for testing or further processing. This behavior can be controlled with the <b>--no-out-link</b> or <b>--out-link</b> options.


title: REPRODUCIBILITY AND ISOLATION
content:
<i>nix-build</i> leverages Nix's core principles of reproducibility and isolation. Builds occur in a sandboxed environment where only explicitly declared inputs are available, ensuring consistent and reproducible results across different machines and times.


title: CACHING AND SUBSTITUTION
content:
Nix automatically caches build results. If a derivation with identical inputs has been built before (locally or is available from a configured binary cache), <i>nix-build</i> will retrieve the cached output instead of rebuilding, significantly speeding up development and deployment workflows.


title: LEGACY COMMAND
content:
<i>nix-build</i> belongs to the 'legacy' Nix CLI. For modern Nix workflows and a unified command-line experience, consider using the <b>nix build</b> command (e.g., <b>nix build .#myPackage</b> for flakes) which offers similar functionality with an updated interface and often better integration with new Nix features.


title: HISTORY
content:
<i>nix-build</i> is part of the original, 'legacy' Nix command-line interface. It has been a cornerstone of the Nix package manager since its early days, providing the fundamental mechanism for building packages and creating symlinks to their outputs. With the introduction of the unified <b>nix</b> command (often referred to as the 'new' Nix CLI) around Nix 2.0, its functionality has largely been absorbed and extended by <b>nix build</b> and <b>nix develop</b>. While still fully functional and widely used, especially in older scripts or workflows, new Nix projects typically favor the modern <b>nix</b> command for a more consistent user experience.


title: SYNOPSIS
content:
<b>nix-build</b> [<I>path</I>] [<I>options</I>...]<br><b>nix-build</b> <I>--expr</I> <I>expression</I> [<I>options</I>...]<br><b>nix-build</b> <I>--attr</I> <I>attribute-path</I> [<I>options</I>...]


title: PARAMETERS
content:
<b>[<I>path</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the Nix expression file (e.g., <I>default.nix</I>) or directory containing it. Defaults to <I>./default.nix</I> if omitted.<br><br><b>--arg <I>name</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument named <I>name</I> with a Nix expression <I>value</I> to the top-level Nix expression.<br><br><b>--argstr <I>name</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a string argument named <I>name</I> with string <I>value</I> to the top-level Nix expression.<br><br><b>-A <I>attribute-path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects and builds a specific attribute from the Nix expression. Can be used multiple times.<br><br><b>-E, --expr <I>expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluates and builds the given Nix expression string directly, instead of a file.<br><br><b>-Q, --no-out-link</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the creation of the <I>result</I> symlink in the current directory.<br><br><b>-o <I>path</I>, --out-link <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates the symlink to the build result at the specified <I>path</I> instead of <I>./result</I>.<br><br><b>--check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a lightweight sanity check on the built derivation, like checking for missing paths.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would be built and downloaded without actually performing the operations.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a detailed stack trace in case of evaluation errors, useful for debugging Nix expressions.<br><br><b>--max-jobs <I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the number of jobs that Nix can run in parallel during a build. Default is 1.<br><br><b>--builders <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a string of build machines to use (e.g., <I>ssh://user@host arch</I>).<br><br><b>--builders-use-substitutes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows remote builders to use substitutes when possible, rather than rebuilding.<br><br><b>-K, --keep-failed</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents Nix from deleting the temporary build directory when a build fails, useful for debugging.<br><br><b>-L, --print-build-logs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the build logs to standard output as the build progresses.<br><br><b>--option <I>name</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a Nix configuration option for this command invocation (e.g., <I>builders-use-substitutes</I>).<br><br>


title: DESCRIPTION
content:
<b>nix-build</b> is a fundamental command in the Nix package manager, designed to build derivations defined by Nix expressions. When executed, it interprets a specified Nix expression (typically a <I>.nix</I> file or a specific attribute within one) and attempts to build the corresponding software package or configuration. The command ensures a reproducible and atomic build process, leveraging Nix's unique functional approach to package management.<br><br>If the build is successful, <b>nix-build</b> places the resulting output path into the Nix store (e.g., <I>/nix/store/hash-package-version</I>). Crucially, it then creates a symbolic link named <I>result</I> in the current directory, pointing to this store path. This <I>result</I> symlink allows easy access to the built artifact. <b>nix-build</b> is widely used for developing and testing packages, as it isolates build environments and guarantees that dependencies are precisely managed. It supports various options for controlling build parameters, specifying attributes to build, or influencing how the output link is handled.


title: CAVEATS
content:
<b>nix-build</b> requires a working Nix installation and typically interacts with the Nix daemon. Builds can consume significant disk space and CPU resources. The <I>result</I> symlink in the current directory is generally overwritten on subsequent successful runs unless explicitly told not to or linked elsewhere. Dependencies must be precisely defined within the Nix expression for reproducible builds.


title: DEFAULT BEHAVIOR
content:
If no path is specified, <b>nix-build</b> defaults to building the <I>default.nix</I> file found in the current directory.


title: RESULT SYMLINK
content:
By default, a symlink named <I>result</I> is created in the current working directory, pointing to the built derivation in the Nix store. This symlink is typically removed and recreated on subsequent successful builds. Alternative symlink paths can be specified using <I>--out-link</I>.


title: SUBSTITUTES AND CACHES
content:
Before commencing a build, <b>nix-build</b> attempts to download pre-built binaries (known as substitutes) from configured binary caches. This mechanism significantly accelerates the build process by reusing existing artifacts instead of rebuilding from source.


title: HISTORY
content:
<b>nix-build</b> is one of the original, foundational commands of the Nix package manager, introduced early in its development. It encapsulates the core principle of Nix: building software derivations deterministically. Over time, while its fundamental purpose remains unchanged, the Nix ecosystem has evolved, leading to the introduction of the unified <b>nix</b> command (often called <I>nix-command</I>) in Nix 2.0 and later. The <I>nix build</I> subcommand within the new <b>nix</b> command provides a more modern and consistent interface, eventually aiming to supersede <b>nix-build</b>. However, <b>nix-build</b> remains widely used in existing Nix projects and scripts due to its long-standing presence and simplicity for direct derivation building.


title: SYNOPSIS
content:
<code>nix-classic</code> <i>subcommand</i> [options...]<br>(e.g., <i>nix-classic build</i> [options...], <i>nix-classic env</i> [options...])<br><br>This synopsis represents the usage of the classic Nix commands, which <code>nix-classic</code> refers to. The actual <code>nix-classic</code> command itself, if it exists as a wrapper, typically dispatches to these specific tools.


title: PARAMETERS
content:
<b><i>build</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-build</i> for building derivations.<br><br><b><i>env</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-env</i> for managing user environments.<br><br><b><i>store</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-store</i> for low-level Nix store operations.<br><br><b><i>shell</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-shell</i> for creating ad-hoc development environments.<br><br><b><i>instantiate</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-instantiate</i> for evaluating Nix expressions.<br><br><b><i>collect-garbage</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-collect-garbage</i> for cleaning up the Nix store.<br><br><b><i>copy-closure</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes functionality similar to <i>nix-copy-closure</i> for copying derivations to a remote machine.<br><br>


title: DESCRIPTION
content:
<code>nix-classic</code> conceptually represents the traditional command-line interface of the Nix package manager, comprising individual executables like <i>nix-build</i>, <i>nix-env</i>, <i>nix-store</i>, <i>nix-shell</i>, and <i>nix-instantiate</i>. Before the introduction of the unified <i>nix</i> command (e.g., <i>nix build</i>, <i>nix run</i>), these distinct tools were the primary way to interact with Nix. The term <i>nix-classic</i> is often used to differentiate this older paradigm from the modern, streamlined <i>nix</i> CLI, either as an alias or a wrapper script, to provide backward compatibility or to access specific advanced functionalities that are more exposed in the classic interface.


title: CAVEATS
content:
<i>Legacy Interface:</i> <code>nix-classic</code> refers to an older, less unified command-line interface. New users are generally encouraged to use the modern, unified <code>nix</code> command for most operations (e.g., <code>nix build</code> instead of <code>nix-build</code>).<br><i>Availability:</i> The <code>nix-classic</code> executable itself might not be directly available on all Nix installations; it's often a conceptual grouping or an alias for the direct <code>nix-*</code> binaries. Functionality is accessed via the individual classic commands.


title: UNIFIED VS. CLASSIC CLI
content:
The Nix ecosystem has two primary command-line interfaces: the classic one (accessed via distinct <code>nix-*</code> executables, or conceptually through <code>nix-classic</code>) and the unified one (via <code>nix <subcommand></code>). The unified CLI aims for greater consistency and user-friendliness across common operations.


title: BACKWARD COMPATIBILITY
content:
The classic commands are maintained largely for backward compatibility with existing scripts and user muscle memory. Many advanced features and low-level operations are still most directly accessible through the classic interfaces.


title: HISTORY
content:
The concept of <code>nix-classic</code> arose with the significant evolution of the Nix command-line interface. Before Nix 2.0, all interactions were through distinct binaries like <code>nix-build</code>, <code>nix-env</code>, <code>nix-store</code>, etc. With the introduction and maturation of the unified <code>nix</code> command (e.g., <code>nix build</code>, <code>nix shell</code>, <code>nix run</code>), these older commands were grouped under the informal "classic" designation. This distinction became important to manage the transition and provide clarity, allowing users to choose between the older, well-established interface and the newer, more consistent one. While the new CLI is the recommended path for most tasks, the classic commands remain fully supported and essential for certain advanced or specific use cases.


title: PARAMETERS
content:
<b>-d, --delete-old</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes old garbage collector roots, effectively allowing previous system generations or user profiles to be collected.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulated garbage collection without actually deleting any paths, showing what would be freed.<br><br><b>-F <i>BYTES</i>, --max-freed <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops collecting garbage once at least <i>BYTES</i> amount of space has been freed. <i>BYTES</i> can be followed by k, M, G, or T.<br><br><b>-t <i>BYTES</i>, --trim-min-freed <i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues collecting garbage until at least <i>BYTES</i> amount of space has been freed. <i>BYTES</i> can be followed by k, M, G, or T.<br><br><b>-s <i>PATH</i>, --store <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Nix store path to perform garbage collection on (defaults to <i>/nix/store</i>).<br><br><b>--gc-roots <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an additional directory to scan for garbage collector roots.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays more detailed information about the garbage collection process.<br><br>


title: DESCRIPTION
content:
<b>nix-collect-garbage</b> is a crucial utility for managing disk space within the Nix package manager's store. The Nix store, typically located at <i>/nix/store</i>, contains all built software packages, libraries, and their dependencies, identified by unique cryptographic hashes. Due to Nix's immutable design, paths within the store are never modified or overwritten; new versions of software result in new paths.<br><br>Over time, this can lead to an accumulation of unused or "dead" paths that are no longer referenced by any active system profile, user environment, or derivation. This command identifies and deletes such unreferenced paths, effectively reclaiming disk space. It works by determining the "garbage collection roots" – paths that are explicitly marked as in-use (e.g., your active NixOS system generation, user profiles, or explicitly registered roots). Any store path not reachable from these roots is considered garbage and eligible for deletion. Regularly running <b>nix-collect-garbage</b> is essential for maintaining a lean and efficient Nix system.


title: CAVEATS
content:
<b>nix-collect-garbage</b> deletes only paths that are <i>not</i> referenced by any declared garbage collection root. If you manually keep symlinks to store paths or directly reference them from outside a Nix-managed environment without registering them as roots, those paths might be deleted even if you consider them "in use." Always ensure important paths are part of a Nix profile or explicitly added as roots.<br><br>Running this command as root or with appropriate permissions is usually required to modify the Nix store.


title: UNDERSTANDING GARBAGE COLLECTION ROOTS
content:
In Nix, a "garbage collection root" is any file system path that points into the Nix store and is recognized by the garbage collector as a reason to keep the referenced store path (and its closure of dependencies) alive. Common roots include user profiles (created by <b>nix-env</b>), NixOS system generations (<i>/run/current-system</i>), and channel update symlinks. Only store paths <i>not</i> reachable from any active root are considered "garbage" and are subject to deletion by <b>nix-collect-garbage</b>.


title: ACTIVE VS. PASSIVE COLLECTION
content:
By default, <b>nix-collect-garbage</b> performs an active collection, deleting identified garbage. The <b>--dry-run</b> option allows for a passive collection, merely reporting what <i>would</i> be deleted without making any changes. This is useful for previewing the impact of a garbage collection run before committing to it.


title: HISTORY
content:
<b>nix-collect-garbage</b> is one of the original and core utilities in the Nix ecosystem, providing the fundamental mechanism for managing disk space by removing unreferenced store paths. It has been a part of Nix since its early development. While still functional and widely used, its functionality has been increasingly integrated and often superseded by the <b>nix store gc</b> subcommand within the newer, unified <b>nix</b> command-line tool, which offers a more consistent user experience across various Nix operations.


title: SYNOPSIS
content:
<b>nix develop</b> [<I>path</I>] [<I>--command</I> <I>cmd</I>] [<I>--arg</I> <I>name</I> <I>value</I>] [<I>--argstr</I> <I>name</I> <I>value</I>] [<I>--expr</I> <I>expression</I>] [<I>--ignore-environment</I>] [<I>--keep</I> <I>variable</I>] [<I>--unset</I> <I>variable</I>] [<I>--shell</I> <I>path</I>] [<I>--impure</I>] [<I>--override-input</I> <I>input-name</I> <I>path</I>] [<I>--inputs-from</I> <I>flake-ref</I>] [<I>--no-build</I>] [<I>--show-trace</I>] [<I>--verbose</I>]


title: PARAMETERS
content:
<b><I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a Nix expression or flake (e.g., '.' for current directory's flake or 'shell.nix').<br><br><b><I>--command</I> <I>cmd</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of dropping into an interactive shell, execute <i>cmd</i> within the development environment and then exit.<br><br><b><I>--arg</I> <I>name</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass an argument named <i>name</i> with Nix value <i>value</i> to the Nix expression.<br><br><b><I>--argstr</I> <I>name</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass a string argument named <i>name</i> with string value <i>value</i> to the Nix expression.<br><br><b><I>--expr</I> <I>expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluate the given Nix expression instead of reading from a file.<br><br><b><I>--ignore-environment</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start with a clean environment, ignoring inherited variables from the outside shell.<br><br><b><I>--keep</I> <I>variable</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep the specified environment variable from the outside environment.<br><br><b><I>--unset</I> <I>variable</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unset the specified environment variable within the development shell.<br><br><b><I>--shell</I> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an alternative shell executable (e.g., 'bash' or 'zsh') for the development environment.<br><br><b><I>--impure</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the environment to be impure (e.g., inherit <i>PATH</i>). Generally discouraged for reproducibility.<br><br><b><I>--override-input</I> <I>input-name</I> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override a flake input with a different path or URI.<br><br><b><I>--inputs-from</I> <I>flake-ref</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Take flake inputs from another flake reference.<br><br><b><I>--no-build</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't build the development environment, just show what <i>would</i> be built.<br><br><b><I>--show-trace</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show build traces on error, which can be helpful for debugging Nix expressions.<br><br><b><I>--verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of output, showing more details about the build process.<br><br>


title: DESCRIPTION
content:
<i>nix-develop</i> is a powerful command within the Nix ecosystem, designed to create and enter reproducible development environments. It leverages Nix expressions, typically defined in a <b>flake.nix</b> file (for flake-based projects) or a <b>shell.nix</b> file (for legacy projects), to specify all necessary dependencies, tools, and environment variables required for a particular project.<br><br>When executed, <i>nix-develop</i> builds or fetches these components and then drops the user into a new shell where all the specified packages are available in the <i>PATH</i> and other relevant environment variables are set. This ensures that every developer working on a project operates within an identical environment, eliminating "it works on my machine" issues and streamlining onboarding for new team members. It's the modern, declarative approach to managing project-specific development setups, offering significant advantages over traditional imperative methods.


title: CAVEATS
content:
Requires Nix installation and understanding of Nix expressions (especially <b>flake.nix</b> or <b>shell.nix</b>).<br>Flakes are still considered experimental and may require enabling <i>extra-experimental-features = nix-command flakes</i> in your Nix configuration file (<b>nix.conf</b>).<br>Initial entry can be slow if dependencies need to be built or fetched from binary caches for the first time.


title: FLAKE INTEGRATION
content:
<i>nix develop</i> is designed to work seamlessly with Nix flakes. By default, it looks for a <b>flake.nix</b> file in the current directory or specified path and uses the <i>devShells</i> attribute within it to define the environment. This provides a standardized, declarative way to declare development dependencies and tools.


title: REPRODUCIBILITY
content:
One of its core benefits is ensuring that everyone working on a project uses the exact same set of dependencies and tools, thanks to Nix's content-addressable store and flake lock files. This eliminates environment-related discrepancies and enhances collaboration.


title: TYPICAL USE CASES
content:
Ideal for setting up language-specific toolchains (e.g., Python, Node.js, Rust, Go), database clients, compilers, static analysis tools, and any other project-specific software needed for development without polluting the system's global environment.


title: HISTORY
content:
<i>nix-develop</i> emerged as part of the Nix "flakes" initiative, aiming to provide a more standardized, discoverable, and hermetic way to define and manage Nix projects. It is essentially the flake-aware successor to the older <i>nix-shell</i> command. While <i>nix-shell</i> was widely used for setting up development environments, <i>nix-develop</i> (as part of the new <i>nix command</i> interface) introduces clearer input management and better integration with the flake ecosystem, which provides reproducible inputs and outputs. It represents a significant step towards making Nix more accessible and robust for modern development workflows.


title: SYNOPSIS
content:
<b>nix-env</b> [<i>OPTIONS</i>] { <b>-i</b> | <b>-u</b> | <b>-e</b> | <b>-q</b> | <b>-S</b> | <b>--compare-generations</b> | <b>--rollback</b> | <b>--switch-generation</b> | <b>--delete-generations</b> | <b>--list-generations</b> } [<i>ARGUMENTS</i>]


title: PARAMETERS
content:
<b><b>-i</b>, <b>--install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs packages into the user's profile.<br><br><b><b>-u</b>, <b>--upgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades packages in the user's profile to their latest versions.<br><br><b><b>-e</b>, <b>--erase</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases (uninstalls) packages from the user's profile.<br><br><b><b>-q</b>, <b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries packages. Can list installed, available, or selected packages.<br><br><b><b>-S</b>, <b>--search</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages available in the Nix channels.<br><br><b><b>-f</b> <i><path></i>, <b>--file</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a Nix expression file to evaluate for packages.<br><br><b><b>-A</b> <i><attribute-path></i>, <b>--attr</b> <i><attribute-path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects packages by attribute path (e.g., 'nixpkgs.hello').<br><br><b><b>-I</b> <i><path></i>, <b>--include</b> <i><path></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a path to the Nix expression search path.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would be done without actually performing the action.<br><br><b><b>--xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs information in XML format.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs information in JSON format.<br><br><b><b>--list-generations</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all existing generations of the current user profile.<br><br><b><b>--rollback</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rolls back the current user profile to the previous generation.<br><br><b><b>--switch-generation</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the current profile to a specific generation number.<br><br>


title: DESCRIPTION
content:
The <b>nix-env</b> command is a fundamental tool within the Nix ecosystem for managing <i>per-user software environments</i>, often referred to as 'profiles'. It allows users to imperatively install, upgrade, or remove packages from the Nix store without affecting other users or system-wide installations.<br><br>Unlike traditional package managers, <b>nix-env</b> operates transactionally. Each change to a user's profile creates a new <i>'generation'</i>, enabling instant rollbacks to previous states if an update or installation goes wrong. This command sources packages from Nix channels, which are typically synchronized with a set of Nix expressions defining available software. While powerful for individual users, its imperative nature has led to the development of more declarative alternatives like the <b>nix profile</b> subcommand from the unified <b>nix</b> CLI, particularly for system-wide package management in NixOS.


title: CAVEATS
content:
While powerful for individual package management, <b>nix-env</b> is generally <i>not recommended for declarative system-wide package management</i> in NixOS; that role belongs to <b>nixos-rebuild</b>. Its imperative nature can sometimes lead to an environment that's harder to reproduce precisely compared to fully declarative Nix configurations. For modern Nix usage, the <b>nix profile</b> subcommand (part of the unified <b>nix</b> CLI) is often preferred as a more structured and extensible replacement for user environment management.


title: GENERATIONS
content:
Every successful operation with <b>nix-env</b> (install, upgrade, erase) creates a new 'generation' of the user's profile. This allows for <i>atomic updates and instant rollbacks</i> to any previous state, providing a robust mechanism for recovering from broken configurations without complex manual intervention. Generations are managed symphonically with the Nix store.


title: PROFILES
content:
<b>nix-env</b> manages 'user profiles', which are essentially symlink trees in <i>~/.nix-profile</i> (or similar paths) pointing to specific package sets in the Nix store. Each user can have their own isolated profile, allowing different users on the same system to have distinct sets of software installed without conflicts.


title: HISTORY
content:
<b>nix-env</b> is one of the original and foundational user-facing commands in the Nix package manager. It predates the introduction of the unified <b>nix</b> command (often referred to as 'nix-cli' or 'new-cli'). Its design focused on providing robust, transactional per-user package management, a concept central to Nix's atomic upgrades and rollbacks. Over time, while still widely used and available for compatibility, much of its functionality has been superseded by the <b>nix profile</b> subcommand in the newer <b>nix</b> CLI, which offers a more consistent interface with other Nix commands like <b>nix run</b> and <b>nix shell</b>.


title: SYNOPSIS
content:
nix flake <I>subcommand</I> [<I>flake-uri</I> | <I>path</I>] [<I>options...</I>]<br><br>Examples:<br>&nbsp;&nbsp;nix flake build<br>&nbsp;&nbsp;nix flake show github:NixOS/nixpkgs<br>&nbsp;&nbsp;nix flake update


title: PARAMETERS
content:
<b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds the default output or a specific output of a flake. If no flake is specified, it defaults to the current directory.<br><br><b>show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the available outputs of a flake, including attributes like packages, applications, and development shells.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the locked inputs of a flake to their latest versions, modifying the <i>flake.lock</i> file.<br><br><b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new bare flake in the current directory, creating skeleton <i>flake.nix</i> and <i>flake.lock</i> files.<br><br><b>new</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new flake project from a specified template, providing a structured starting point.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows detailed information about a flake, including its inputs, outputs, and current status.<br><br>


title: DESCRIPTION
content:
Nix flakes provide a modern, reproducible, and self-contained way to define Nix projects. The <b>nix flake</b> command serves as the primary interface for interacting with these flake-based projects. It enables users to build, develop, and share Nix configurations with well-defined inputs and outputs.<br>Through various subcommands like <i>build</i>, <i>show</i>, <i>update</i>, and <i>init</i>, users can manage flake dependencies, inspect outputs, and create new flake-based repositories. Flakes drastically improve reproducibility by locking input versions, ensuring that builds are consistent across different environments and times. This approach simplifies dependency management and fosters a more robust ecosystem for Nix users.


title: CAVEATS
content:
Requires Nix version 2.4 or later; flakes became a stable feature in Nix 2.10, but some functionalities might benefit from newer versions.<br>Relies heavily on the <i>flake.nix</i> and <i>flake.lock</i> files for defining and locking project dependencies, which must be correctly maintained.<br>While designed for reproducibility, external factors like network availability for fetching inputs can still affect the initial setup.<br>Can have a learning curve for users new to the Nix ecosystem and its functional programming paradigm.


title: FLAKE STRUCTURE
content:
Flakes are primarily defined by two files:<br><i>flake.nix</i>: Describes the flake's inputs (dependencies) and outputs (like packages, applications, or development shells).<br><i>flake.lock</i>: Automatically generated and updated, this file pins the exact versions and hashes of all transitive inputs, ensuring reproducible builds across different environments.


title: FLAKE URI
content:
Flakes can be referenced using Universal Resource Identifiers (URIs), allowing them to be sourced from various locations. Common formats include:<br><b>path:</b><I>./relative/path</I> (for local directories)<br><b>git:</b><I>https://example.com/repo.git?ref=main</I> (for Git repositories)<br><b>github:</b><I>owner/repo</I> (a convenient shorthand for GitHub repositories)


title: HISTORY
content:
Nix flakes were introduced as an experimental feature in Nix version 2.4, driven by the community's need for better reproducibility, simpler input management, and clearer project boundaries. They aimed to address shortcomings of the traditional Nix approach, such as implicit inputs and difficulties in sharing hermetic development environments.<br>After several iterations and extensive testing, flakes and the <b>nix flake</b> commands transitioned from experimental to stable with Nix version 2.10, marking a significant evolution in how Nix projects are structured and shared. Their adoption has streamlined Nix development workflows and fostered a more robust and interconnected ecosystem.


title: SYNOPSIS
content:
<i>nix-profile</i> [<i>options...</i>] <i>subcommand</i> [<i>subcommand-options...</i>] [<i>arguments...</i>]


title: PARAMETERS
content:
<b><i>install</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds packages to the user profile. For example: <i>nix-profile install nixpkgs#htop</i><br><br><b><i>remove</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes packages from the user profile. For example: <i>nix-profile remove nixpkgs#htop</i><br><br><b><i>update</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the Nix channels used for package lookups, fetching the latest package definitions.<br><br><b><i>upgrade</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades packages in the profile to their latest available versions according to the current channels.<br><br><b><i>list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages currently installed in the active user profile.<br><br><b><i>rollback</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the user profile to a previous generation, effectively undoing recent changes.<br><br><b><i>generations</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the history of all user profile generations, including their creation times and status. (Alias for <i>history</i>)<br><br><b><i>wipe-history</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes older profile generations, freeing up disk space. Use with caution as it prevents rollback to those generations.<br><br><b><i>set-default</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific generation as the default for the user profile, controlling which software is active.<br><br>


title: DESCRIPTION
content:
The <i>nix-profile</i> command, often superseded by the newer <i>nix profile</i> subcommand of the unified <i>nix</i> CLI, is fundamental to managing user-specific software environments within the Nix package manager. It allows non-root users to install, upgrade, and remove packages without affecting the system-wide installation or other users.<br><br>At its core, <i>nix-profile</i> manages a "profile" which is a symlink tree pointing to a specific "generation" of installed packages. Each modification (install, upgrade, remove) creates a new generation, enabling easy rollback to previous states. This declarative approach ensures reproducibility and isolation of user environments, making it a powerful tool for managing personal software installations.


title: CAVEATS
content:
Managing profiles can consume significant disk space if old generations are not regularly garbage collected. While powerful for user environments, <i>nix-profile</i> does not manage global system configurations or services; that's handled by NixOS or Nix's declarative system management.<br><br>Be aware of the distinction between the legacy <i>nix-profile</i> command and the modern <i>nix profile</i> subcommand (part of the unified <i>nix</i> CLI). While functionally similar, the modern command offers improved syntax and integration within the broader Nix ecosystem.


title: GENERATIONS
content:
Each successful operation that modifies the user profile (e.g., <i>install</i>, <i>upgrade</i>, <i>remove</i>) creates a new "generation." A generation is a complete, atomic snapshot of the user's installed software environment. This allows users to effortlessly switch between different versions of their environment or revert to a previous state, providing robust rollback capabilities and ensuring reproducibility.


title: PACKAGE SPECIFICATION
content:
Packages are typically specified using the format <i>nixpkgs#package-name</i> when using flakes. This refers to a package named 'package-name' from the <i>nixpkgs</i> channel. You can also specify packages from other Nix flakes or direct paths to derivations. For older `nix-profile` usage, simply `package-name` would often suffice after setting up channels.


title: LEGACY VS. UNIFIED CLI
content:
The command <i>nix-profile</i> refers to the legacy Nix CLI command. Its functionality is largely mirrored and often improved upon by the <i>nix profile</i> subcommand within the unified <i>nix</i> command (e.g., `nix profile install nixpkgs#htop`). Users are generally encouraged to use the unified <i>nix</i> CLI for modern Nix operations due to its consistency and feature set.


title: HISTORY
content:
The concept of user profiles and generations has been central to Nix's design since its early days, providing a robust mechanism for managing user-specific software environments. The original Nix CLI exposed this functionality primarily through commands like <i>nix-env</i> and later <i>nix-profile</i>. With the advent of the unified <i>nix</i> command-line interface (introduced around Nix 2.0), much of <i>nix-profile</i>'s functionality was integrated into the new <i>nix profile</i> subcommand, simplifying the overall user experience and command structure. While <i>nix-profile</i> still exists for compatibility, <i>nix profile</i> is the recommended modern approach for managing user environments.


title: SYNOPSIS
content:
<B>nix registry</B> <I>SUBCOMMAND</I> [<I>OPTIONS</I>] [<I>ARGUMENTS</I>]<br><br>Available subcommands and their basic usage:<br><B>nix registry add</B> <I>NAME PATH</I> [<I>--flake</I>] [<I>--from ORIGIN</I>] [<I>--dir PATH</I>] [<I>--priority NUMBER</I>]<br><B>nix registry delete</B> <I>NAME</I> [<I>--dir PATH</I>]<br><B>nix registry list</B> [<I>--dir PATH</I>] [<I>--json</I>] [<I>--sort-by PROPERTY</I>]<br><B>nix registry pin</B> <I>NAME</I> [<I>--dir PATH</I>]<br><B>nix registry update</B> [<I>--dir PATH</I>]


title: PARAMETERS
content:
<b>--dir <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the registry should be managed (e.g., for project-specific registries). By default, it operates on the global user registry.<br><br><b>--flake</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <I>add</I> subcommand to explicitly treat the provided <I>PATH</I> as a Nix flake, even if its structure is ambiguous. Nix often infers this automatically.<br><br><b>--from <ORIGIN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <I>add</I> subcommand to specify the origin of the registry entry, such as <I>flake:nixpkgs</I> or <I>channel:nixpkgs</I>. This helps Nix resolve the source properly.<br><br><b>--priority <NUMBER></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <I>add</I> subcommand to assign a lookup priority to the registry entry. Higher numbers mean higher priority. Defaults to 0.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <I>list</I> subcommand to output the registry entries in machine-readable JSON format, suitable for scripting.<br><br><b>--sort-by <PROPERTY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <I>list</I> subcommand to sort the output by a specific property, such as <I>name</I>, <I>priority</I>, or <I>path</I>.<br><br>


title: DESCRIPTION
content:
The <I>nix-registry</I> command is a crucial utility within the Nix package manager for managing the <I>Nix registry</I>. The registry serves as a system for mapping short, human-readable names to Nix expressions, typically Nix flakes or traditional Nix channels. This abstraction simplifies referencing complex Nix inputs, allowing users to refer to, for example, <I>nixpkgs</I> instead of a full Git URL or a local path.<br><br>The command provides several subcommands to interact with this registry: <I>add</I> to create new entries, <I>delete</I> to remove them, <I>list</I> to view existing mappings, <I>pin</I> to fix an entry to a specific version (particularly useful for flakes to ensure reproducible builds by updating their lock file), and <I>update</I> to refresh the default <I>nixpkgs</I> entry.<br><br>Registry entries can be global (stored in <I>/nix/var/nix/profiles/per-user/$USER/nix-registry</I>) or project-specific (stored in <I>.direnv/nix-registry</I> or a custom path using the <I>--dir</I> option), enabling flexible management of dependencies across different development contexts. It streamlines the use of flakes by providing a standardized way to manage their inputs, making Nix usage more intuitive and efficient.


title: CAVEATS
content:
The <I>nix-registry</I> command manages entries that can be either global (for the current user) or local to a specific project. Project-specific entries are often stored in a <I>.direnv/nix-registry</I> directory if <B>direnv</B> is used, or in a path specified by the <I>--dir</I> option. Be mindful of which registry you are modifying or querying.<br><br>The <I>remove</I> subcommand is a deprecated alias for <I>delete</I> and should be avoided in favor of <I>delete</I> for clarity and future compatibility.<br><br>When using <I>pin</I> on a flake registry entry, it effectively updates the corresponding input's locked version within the flake's <I>flake.lock</I> file, ensuring reproducibility. This behavior is similar to <I>nix flake update</I> for a specific input.


title: REGISTRY LOCATIONS
content:
The global user registry is typically located at <I>/nix/var/nix/profiles/per-user/$USER/nix-registry</I>. Project-specific or custom registries can be created and managed using the <I>--dir</I> option, allowing isolated and reproducible development environments.


title: REGISTRY VS. FLAKE INPUTS
content:
While <I>nix-registry</I> allows you to define aliases for flake inputs, direct flake inputs in a <I>flake.nix</I> file take precedence when resolving dependencies within that specific flake. The registry is more for global or shared aliases that can be used interactively or by flakes that reference them indirectly.


title: HISTORY
content:
The <I>nix-registry</I> command was introduced as part of the Nix 2.4/2.5 series, coinciding with the stabilization and wider adoption of Nix flakes. Before its introduction, channel management was primarily handled by <I>nix-channel</I>, and there wasn't a standardized, built-in way to manage short aliases for arbitrary Nix expressions or flake inputs. <I>nix-registry</I> provides a more generic and structured mechanism for defining and managing these mappings, especially vital for the flake ecosystem to abstract away complex flake input paths.


title: PARAMETERS
content:
<b><b>--all-channels</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search all channels available to the current user (e.g., from NIX_PATH).<br><br><b><b>--channel &lt;CHANNEL&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages available in the specified Nix channel. This can be a URL or a name from NIX_PATH.<br><br><b><b>--description</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package descriptions in the search scope, in addition to names.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the search results in a structured JSON format, useful for scripting.<br><br><b><b>--limit &lt;LIMIT&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict the number of returned search results to the specified limit.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the search using only local, cached package data, without contacting remotes.<br><br><b><b>--path &lt;PATH&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages located within a specific Nix path or directory.<br><br><b><b>--remote &lt;REMOTE&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search packages from a designated remote repository or Nix store.<br><br><b><b>--revision &lt;REVISION&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search against a specific revision or commit of a channel's package set.<br><br><b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter results to packages built for the current system architecture (e.g., <I>x86_64-linux</I>).<br><br><b><b>--max-derivations &lt;MAX_DERIVATIONS&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of derivations considered during the search process, impacting performance.<br><br>


title: DESCRIPTION
content:
The <I>nix-search</I> command is a powerful utility for finding software packages within the Nix ecosystem. It allows users to query the vast collection of Nix packages, identifying them by name, and optionally by their descriptions. This command is essential for discovering available software, understanding package names for installation, or finding dependencies for development environments.<br><br>It operates by searching the Nix path (NIX_PATH), which typically includes configured Nix channels or local package definitions. When not in offline mode, it can also query remote sources to retrieve the latest package information. The search mechanism typically uses regular expressions, making it highly flexible for precise or broad searches. The output provides a list of matching packages, often including their full Nix path, description, and the system they target.


title: CAVEATS
content:
The command can be slow when searching very large or numerous remote channels without a strong network connection or sufficient local caching. It's important to note that the standalone <I>nix-search</I> command might be deprecated or superseded by the <I>nix search</I> subcommand within the modern <I>nix</I> unified CLI, which offers similar or enhanced functionality.


title: SEARCH STRING AND REGULAR EXPRESSIONS
content:
The <I>SEARCH_STRING</I> argument is interpreted as a regular expression. This allows for flexible and powerful search queries, enabling users to match partial names, specific patterns, or even combine multiple criteria. For example, <I>nix-search 'firefox|chromium'</I> would find packages related to both browsers.


title: OUTPUT FORMAT
content:
By default, <I>nix-search</I> provides human-readable output, listing package names, versions, and descriptions in a table-like format. The <I>--json</I> option is highly recommended for scripting or programmatic consumption, providing structured data that can be easily parsed and processed by other tools.


title: HISTORY
content:
Historically, package searching in Nix was often performed using <I>nix-env -qa</I>. The dedicated <I>nix-search</I> command (or later, the <I>nix search</I> subcommand) was introduced to provide a more focused and efficient interface for package discovery. This evolution reflects the Nix project's move towards a more user-friendly and consolidated command-line experience, separating search functionality from environment management.


title: PARAMETERS
content:
<b><b>-A</b> <i>attribute</i> or <b>--attr</b> <i>attribute</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an <i>attribute</i> within a Nix expression (e.g., a <i>flake.nix</i> or <i>shell.nix</i>) to build a shell from. This is useful for selecting specific development environments defined within a larger Nix project.<br><br><b><b>--arg</b> <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a Nix <i>value</i> to the function defined in the Nix expression that describes the shell. This allows for parameterizing the environment.<br><br><b><b>--argstr</b> <i>name string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <b>--arg</b>, but specifically passes a string <i>value</i> to the function defined in the Nix expression.<br><br><b><b>--pure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a completely isolated, 'pure' shell environment, discarding most inherited environment variables from the parent shell. This helps ensure greater reproducibility by minimizing external influences.<br><br><b><b>--run</b> <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> within the constructed shell environment instead of entering an interactive shell. The shell exits immediately after the command completes.<br><br><b><b>-p</b> <i>packages</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds the specified <i>packages</i> to the shell environment on the fly without requiring a Nix expression file. Multiple packages can be listed, separated by spaces.<br><br><b><b>--keep</b> <i>VAR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the specified environment variable <i>VAR</i> from the parent environment even when using the <b>--pure</b> option. This is useful for retaining essential variables like SSH_AUTH_SOCK.<br><br><b><b>-I</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i>path</i> to the Nix search path. This influences how Nix resolves imported files within expressions.<br><br>


title: DESCRIPTION
content:
<i>nix-shell</i> is a command in the Nix ecosystem that allows users to create and enter a shell environment where specific dependencies are available. It's particularly useful for development, testing, and building software without globally installing packages. Instead of modifying the system-wide environment, <i>nix-shell</i> constructs a temporary, isolated environment based on a Nix expression (typically <i>shell.nix</i> or a <i>flake.nix</i> entry). This expression defines the packages, build tools, and environmental variables required for a project.<br><br>When invoked, <i>nix-shell</i> builds or fetches these dependencies and then spawns a new shell (e.g., bash) with the specified PATH, NIX_BUILD_CORES, and other variables set up to make the dependencies accessible. This ensures reproducible development environments, prevents dependency conflicts, and simplifies project setup for collaborators. It supports interactive use, where you can explore the environment, or non-interactive use, where it executes a command within the constructed environment. It's a cornerstone for reproducible development and testing workflows within the Nix ecosystem, enabling users to 'jump into' a specific project's environment without polluting their global system.


title: CAVEATS
content:
While powerful, <i>nix-shell</i> environments can sometimes be slow to initialize if dependencies need to be built or downloaded for the first time, potentially consuming significant disk space in the Nix store. Users should also be aware that <i>nix-shell</i> is part of the legacy Nix command set; for modern, reproducible development environments, the Nix team increasingly recommends using <i>nix develop</i> (part of the experimental Nix Flakes feature), which offers improved reproducibility and structure for complex projects. Although <i>nix-shell</i> remains widely used and functional, its role in new projects might be superseded by <i>nix develop</i>.


title: NIX EXPRESSIONS AND <I>SHELL.NIX</I>
content:
The behavior of <i>nix-shell</i> is primarily determined by a Nix expression, often found in a file named <i>shell.nix</i> in the current directory or specified as an argument. This expression defines the packages, build tools, and environment variables that constitute the shell environment. For projects using Nix Flakes, <i>nix-shell</i> can also use the <i>devShell</i> attribute within a <i>flake.nix</i> file to define the environment.


title: INTERACTIVE VS. NON-INTERACTIVE MODES
content:
<i>nix-shell</i> can be used in two primary modes. By default, it spawns an interactive shell (e.g., bash) where the user can execute commands within the defined environment. Alternatively, using the <b>--run</b> <i>command</i> option, <i>nix-shell</i> can execute a specific <i>command</i> in the constructed environment and then exit, making it suitable for scripting or continuous integration pipelines.


title: HISTORY
content:
Nix was created by Eelco Dolstra as part of his PhD research on reproducible software deployment. <i>nix-shell</i> has been a fundamental component since early versions of Nix, providing a simple way to enter isolated development environments. It predates the introduction of Nix Flakes and the unified <b>nix</b> command-line interface, which led to the development of <i>nix develop</i> as a more structured and reproducible successor for defining project environments. Despite newer alternatives, <i>nix-shell</i> remains widely used for quick, ad-hoc environment setup and for interacting with legacy Nix expressions. Its design exemplifies Nix's core principle of reproducible environments.


title: SYNOPSIS
content:
<b>nix-shell</b> [<i>path</i>] [<i>options</i>] -- [<i>args...</i>]<br><b>nix-shell</b> -p <i>packages...</i> [<i>options</i>] -- [<i>args...</i>]<br><b>nix-shell</b> --run <i>command</i>


title: PARAMETERS
content:
<b>-p <i>packages...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters a shell with the specified Nix packages available in the <i>PATH</i> and other environment variables. Useful for ad-hoc environments.<br><br><b>--run <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> within the created shell environment and then exits. The shell is not interactive.<br><br><b>-A <i>attribute</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific derivation or package <i>attribute</i> from the Nix expression to build the shell environment from.<br><br><b>--pure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a purely isolated shell environment. Most environment variables from the calling shell are removed, ensuring reproducibility and reducing interference.<br><br><b>--arg <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument <i>name</i> with a literal Nix <i>value</i> to the Nix expression. The value is parsed as a Nix expression.<br><br><b>--argstr <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument <i>name</i> with a string <i>value</i> to the Nix expression. The value is treated as a literal string.<br><br><b>--keep <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>--pure</i>, preserves the specified environment variable <i>NAME</i> from the calling shell in the new environment.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a detailed evaluation trace for Nix expressions, useful for debugging errors during environment creation.<br><br><b>--option <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a Nix configuration <i>option</i> to the specified <i>value</i> for the duration of the command execution.<br><br>


title: DESCRIPTION
content:
<b>nix-shell</b> allows users to create reproducible and isolated development environments. It instantiates a Nix expression, making specified dependencies and tools available within a new shell session without permanently installing them globally. This is ideal for development, debugging, or running specific commands with precise dependencies. The shell environment is set up such that binaries are available in <i>PATH</i>, and other necessary environment variables are configured. By default, <b>nix-shell</b> looks for <i>shell.nix</i> or <i>default.nix</i> in the current directory, but a specific Nix expression or a list of packages can also be provided. It promotes "pure" environments, minimizing interference from the host system's existing software.


title: CAVEATS
content:
<b>nix-shell</b> aims for pure environments, but without <i>--pure</i>, it can inherit variables that might affect reproducibility. Relying on mutable inputs like <i>NIX_PATH</i> or external system configuration can lead to non-deterministic environments. Shells like <i>zsh</i> or <i>fish</i> might require specific configurations to properly source <i>shell.nix</i> scripts, as <b>nix-shell</b> defaults to <i>bash</i> for its shell startup. Users should be mindful of the <i>shellHook</i> and <i>buildInputs</i> within Nix expressions for proper environment setup.


title: ENVIRONMENT VARIABLES
content:
Several environment variables can influence <b>nix-shell</b>'s behavior:<br><b>NIX_PATH</b>: Controls where Nix looks for imported Nix expressions. It's a colon-separated list of paths.<br><b>NIX_BUILD_SHELL</b>: Specifies the shell to use for building (defaults to <i>bash</i>). Can be overridden.<br><b>NIX_SHELL_PRESERVE_PROMPT</b>: If set, prevents <b>nix-shell</b> from modifying the shell prompt upon entry.


title: USAGE EXAMPLES
content:
To enter a shell with <b>git</b> and <b>htop</b> available:<br><b>nix-shell</b> -p git htop<br><br>To build a shell from <i>shell.nix</i> and run a command:<br><b>nix-shell</b> --run 'npm install && npm start'<br><br>To get a pure shell for a specific attribute from a Nix expression:<br><b>nix-shell</b> -A myProject.devShell --pure


title: HISTORY
content:
<b>nix-shell</b> emerged as a fundamental component of the Nix package manager, evolving alongside NixOS and its declarative approach to system configuration and development. Its design is rooted in the Nix philosophy of reproducible builds and isolated environments, providing a practical way for developers to quickly set up projects with precise dependencies without traditional package installation. While no specific standalone history for <b>nix-shell</b> exists, its development has mirrored the maturation of the Nix ecosystem, becoming indispensable for creating reliable and portable development workflows.


title: SYNOPSIS
content:
<I>nix-store</I> <I>[options]</I> <I>[arguments]</I><br><I>nix-store</I> <I>--add</I> <I>path</I><br><I>nix-store</I> <I>--realise</I> <I>paths...</I><br><I>nix-store</I> <I>--query</I> <I>{--roots | --referrers | --references | --requisites | --outputs | --deriver | --hash | --name}</I> <I>path</I><br><I>nix-store</I> <I>--gc</I> <I>[--print-roots]</I><br><I>nix-store</I> <I>--delete</I> <I>paths...</I><br><I>nix-store</I> <I>--verify</I> <I>[--check-contents]</I>


title: PARAMETERS
content:
<b><code>--add &lt;path&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <I>path</I> to the Nix store, computing its hash and copying contents. Returns the new store path.<br><br><b><code>--realise &lt;paths...&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds (realises) the specified derivation outputs or store paths, making them available in the store.<br><br><b><code>--query &lt;mode&gt; &lt;path&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries information about <I>path</I> based on the specified <I>mode</I> (e.g., <B>--roots</B>, <B>--referrers</B>, <B>--references</B>, <B>--requisites</B>, <B>--outputs</B>, <B>--deriver</B>, <B>--hash</B>, <B>--name</B>).<br><br><b><code>--gc</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs garbage collection, identifying and removing unreferenced store paths to free up disk space.<br><br><b><code>--delete &lt;paths...&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes specific store paths from the Nix store. This operation usually requires root privileges or Nix daemon interaction.<br><br><b><code>--verify</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the cryptographic integrity of store paths. Use <B>--check-contents</B> to verify the actual contents against their hashes.<br><br><b><code>--read-log &lt;path&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads and prints the build log for a given derivation output path.<br><br><b><code>--print-roots</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used in conjunction with <B>--gc</B> to print the list of current garbage collection roots.<br><br><b><code>-I &lt;path&gt;</code> or <code>--include &lt;path&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <I>path</I> to the Nix expression search path, used for resolving <I>import</I> expressions.<br><br><b><code>--max-jobs &lt;N&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of parallel build jobs that Nix can run.<br><br><b><code>--option &lt;name&gt; &lt;value&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides a Nix configuration option for the duration of the command's execution.<br><br><b><code>--xml</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces XML output for query commands, which is useful for programmatic parsing.<br><br>


title: DESCRIPTION
content:
<I>nix-store</I> is a fundamental, low-level command-line utility within the <I>Nix package manager</I> ecosystem. It provides direct interaction with the <B>Nix store</B>, typically located at <I>/nix/store</I>. This directory is the core of Nix's reproducibility and atomic upgrades, as it uniquely identifies and stores every component of a system – packages, derivations, and their dependencies – by cryptographic hash.<br><br>Unlike higher-level Nix commands like <I>nix build</I> or <I>nix shell</I>, <I>nix-store</I> operates on the raw store paths. It's primarily used by Nix itself to perform operations like <B>building derivations</B> (realising outputs), <B>adding new paths</B> to the store, <B>querying relationships</B> between store paths (e.g., dependencies or reverse dependencies), and performing <B>garbage collection</B> to remove unreferenced data. While not typically used by end-users for daily package management, understanding <I>nix-store</I> is crucial for advanced Nix development, debugging, and system administration, offering granular control over the immutable package store.


title: CAVEATS
content:
<I>nix-store</I> is a low-level command; improper use can lead to an inconsistent or corrupted Nix store.<br>Most write operations (e.g., adding, deleting, or realising paths) require root privileges or running through the Nix daemon.<br>Its functionality is progressively being integrated into the higher-level <I>nix</I> command (e.g., <I>nix build</I>, <I>nix store gc</I>), making <I>nix-store</I> less frequently used directly by end-users over time.


title: THE IMMUTABLE NIX STORE
content:
The <I>/nix/store</I> directory, managed by <I>nix-store</I>, is unique. Every path in it is identified by a cryptographic hash of its inputs, making it <B>content-addressed</B> and <B>immutable</B>. This ensures that a build result is always the same given the same inputs, crucial for reproducibility and atomic upgrades. Directly manipulating paths in <I>/nix/store</I> outside of <I>nix-store</I> or the Nix daemon is generally not recommended.


title: GARBAGE COLLECTION ROOTS
content:
Nix's garbage collection, performed via <I>nix-store --gc</I>, only deletes paths that are not 'reachable' from designated <B>garbage collection roots</B>. These roots are typically system profiles, user environments, or explicitly registered paths that the user or system wants to keep. Understanding and managing roots is key to effective store cleanup.


title: HISTORY
content:
<I>nix-store</I> has been a foundational component of the <I>Nix package manager</I> since its inception, embodying the core logic for managing the immutable content-addressed store. While its direct command-line use has gradually diminished for everyday tasks due to the introduction of the more user-friendly unified <I>nix</I> command (starting with Nix 2.0), <I>nix-store</I> remains the underlying engine for many higher-level Nix operations. Its design is central to Nix's principles of reproducible builds and atomic upgrades.


title: PARAMETERS
content:
<b><i>FROM-PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path in the Nix store from which to start tracing dependencies. This is the 'source' of the dependency chain.<br><br><b><i>TO-PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path in the Nix store that is the desired 'target' of the dependency chain. The command will search for paths leading to this store path.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the dependency paths in a structured JSON format, suitable for programmatic parsing.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with usage information for the command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version of the Nix command-line tool.<br><br>


title: DESCRIPTION
content:
<b>nix why-depends</b> is a powerful Nix command-line utility used to determine the dependency path(s) from a specified <i>source</i> Nix store path to a specified <i>target</i> Nix store path. <br><br> In the Nix ecosystem, every package, library, or configuration is represented by a unique cryptographic hash and stored in the <code>/nix/store</code>. Understanding these dependencies is crucial for debugging why a particular library or package is included in a larger build, optimizing build times by identifying unnecessary dependencies, or simply comprehending the intricate dependency graph of your NixOS system or Nix-built applications. <br><br> This command is especially useful for developers and system administrators working with complex Nix derivations, offering insights into the exact chain of dependencies that leads from one component to another, thereby simplifying dependency analysis and problem resolution within the Nix store.


title: CAVEATS
content:
The command operates on paths already present in the Nix store. It might be computationally intensive for extremely large and complex dependency graphs. Ensure <i>FROM-PATH</i> and <i>TO-PATH</i> are valid Nix store paths (e.g., <code>/nix/store/hash-name</code>).


title: OUTPUT FORMAT
content:
By default, <b>nix why-depends</b> outputs a human-readable list of paths, indicating one or more direct or indirect dependency chains. When <b>--json</b> is used, the output is a JSON array of arrays, where each inner array represents a distinct dependency path from <i>FROM-PATH</i> to <i>TO-PATH</i>.


title: HISTORY
content:
<b>nix why-depends</b> is a relatively modern addition to the Nix command-line interface, introduced as part of the unified <b>nix</b> command (e.g., <b>nix help</b> as opposed to older separate commands like <b>nix-store</b>, <b>nix-build</b>, etc.). This consolidation began gaining traction around Nix 2.4. Its purpose was to provide a more intuitive and direct way to query dependency paths compared to manually traversing the store using lower-level tools like <b>nix-store -q --referrers</b>.


title: PARAMETERS
content:
<b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output build results and other information in JSON format.</i><br><br><b><b>--no-link</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not create the default symlink (<i>result</i>) to the build output.</i><br><br><b><b>--out-link</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Create a symlink at the specified <i>path</i> to the build result (default: <i>./result</i>).</i><br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not allow network access during evaluation or building.</i><br><br><b><b>--builders</b> <i>&lt;spec&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify which remote builders to use for distributed builds.</i><br><br><b><b>--flake</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Treat inputs as flake references (e.g., <i>.</i>, <i>nixpkgs#hello</i>).</i><br><br><b><b>--show-trace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show a detailed evaluation trace on error, useful for debugging.</i><br><br><b><b>--refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Re-evaluate and update Nix Flake inputs before building.</i><br><br><b><b>--impure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Allow impure evaluation, which can compromise reproducibility but is sometimes necessary for debugging.</i><br><br><b><b>--override-input</b> <i>&lt;input&gt;=&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override a specific flake input with a different path or URI.</i><br><br><b><b>--max-jobs</b> <i>&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the maximum number of parallel build jobs.</i><br><br><b><b>--cores</b> <i>&lt;n&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the number of CPU cores to use for local builds.</i><br><br><b><b>--store</b> <i>&lt;uri&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify a different Nix store to build into or query.</i><br><br>


title: DESCRIPTION
content:
The <b>nix build</b> command is a cornerstone of the Nix package manager, designed to evaluate and build software derivations into the Nix store. It takes Nix expressions, which define how software should be built, and executes the necessary steps like fetching sources, compiling, and installing.<br><br>Unlike its predecessor, <b>nix-build</b>, this command is part of the modern, unified Nix CLI (often conceptualized as 'nix3') and offers enhanced features, particularly native support for <i>Nix Flakes</i>. It enables users to build specific attributes from a <i>flake.nix</i> file or traditional Nix expressions.<br><br>Upon successful completion, <b>nix build</b> places the built artifacts in the immutable Nix store and, by default, creates a symlink named <i>result</i> in the current directory pointing to the output. This ensures reproducibility and isolation of build products.


title: CAVEATS
content:
<i><br><b>nix build</b> relies on the Nix daemon for multi-user builds or remote operations. Ensure the daemon is running if you encounter permissions or connectivity issues.<br>By design, Nix outputs are immutable; once built, a derivation path in the store cannot be modified. This ensures reproducibility but means changes require rebuilding.<br>The reproducibility of builds depends heavily on the purity of the build environment and the precise definition of all inputs. Impure operations (e.g., network access during build) can compromise reproducibility.</i>


title: <B>DEFAULT OUTPUT SYMLINK</B>
content:
<i>When <b>nix build</b> successfully completes, it creates a symlink named <i>result</i> in the current directory. This symlink points to the root of the built derivation in the Nix store. This is a convenient way to access the built artifacts without knowing their exact cryptic store path.<br><br>For example, if you build a package, you can often find its executables under <i>./result/bin/</i>. The <b>--no-link</b> option can prevent this symlink creation, and <b>--out-link</b> allows specifying a custom symlink name or path.</i>


title: <B>FLAKE INTEGRATION</B>
content:
<i>One of the key strengths of <b>nix build</b> is its deep integration with Nix Flakes. It allows users to directly build specific outputs defined within a <i>flake.nix</i> file. For instance, to build the <i>packages.x86_64-linux.hello</i> output from a flake, you can simply run <i>nix build .#hello</i>.<br><br>This paradigm simplifies dependency management and project structure, making it easier to define and build reproducible projects. <b>nix build</b> leverages the locked inputs of flakes to ensure repeatable builds across different environments.</i>


title: HISTORY
content:
<i>The <b>nix build</b> command emerged as part of the strategic overhaul of the Nix CLI, often referred to as the 'new' or 'nix3' CLI during its development phase. Its primary goal was to provide a more consistent, user-friendly interface and native support for Nix Flakes, a declarative way to manage Nix projects and their dependencies.<br><br>It effectively superseded the older <b>nix-build</b> command, consolidating its functionality while introducing a modern approach to interacting with the Nix ecosystem. The introduction of <b>nix build</b> marked a significant step towards the unification and simplification of common Nix workflows, making it the recommended method for building derivations in modern Nix environments.</i>


title: SEE ALSO
content:
<b>nix run</b>(1), <b>nix shell</b>(1), <b>nix develop</b>(1), <b>nix install</b>(1), <b>nix-store</b>(1)


title: SYNOPSIS
content:
<b>nix develop</b> [<i>--arg &lt;name&gt; &lt;value&gt;</i>...] [<i>--argstr &lt;name&gt; &lt;value&gt;</i>...] [<i>--command &lt;cmd&gt;</i>] [<i>--impure</i>] [<i>--json</i>] [<i>--log-format &lt;format&gt;</i>] [<i>--offline</i>] [<i>--refresh</i>] [<i>--show-trace</i>] [<i>--option &lt;name&gt; &lt;value&gt;</i>...] [<i>--extra-experimental-features &lt;features&gt;</i>...] [<i>&lt;flake-url&gt;</i>] [<i>#&lt;attribute-path&gt;</i>]


title: PARAMETERS
content:
<b><i>--arg &lt;name&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass the value <i>&lt;value&gt;</i> as an argument <i>&lt;name&gt;</i> to the Nix functions in the flake.<br><br><b><i>--argstr &lt;name&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass the string <i>&lt;value&gt;</i> as an argument <i>&lt;name&gt;</i> to the Nix functions in the flake.<br><br><b><i>--command &lt;cmd&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of dropping into a shell, execute <i>&lt;cmd&gt;</i> within the development environment.<br><br><b><i>--impure</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the Nix evaluation to access the system’s environment variables.<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce JSON output, useful for programmatic consumption.<br><br><b><i>--log-format &lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the format of log output (e.g., <i>internal-json</i>).<br><br><b><i>--offline</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't attempt to connect to the network.<br><br><b><i>--refresh</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-fetch the inputs of the flake.<br><br><b><i>--show-trace</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a stack trace in case of Nix evaluation errors.<br><br><b><i>--option &lt;name&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a Nix configuration option for this command invocation.<br><br><b><i>--extra-experimental-features &lt;features&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable additional experimental Nix features (e.g., <i>flakes nix-command</i>).<br><br><b><i>&lt;flake-url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the flake to use (e.g., <i>.</i> for current directory, <i>github:NixOS/nixpkgs</i>).<br><br><b><i>#&lt;attribute-path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific attribute path within the flake to develop (e.g., <i>#devShells.x86_64-linux.default</i> or <i>#devShell</i>).<br><br>


title: DESCRIPTION
content:
<i>nix develop</i> is a Nix command used to set up and enter a self-contained development environment defined by a Nix flake.<br>Unlike traditional package managers that install tools globally, <i>nix develop</i> creates an isolated shell where all specified development dependencies (compilers, libraries, tools) are made available.<br>This ensures project reproducibility, prevents dependency conflicts, and allows multiple projects with different requirements to coexist without interference.<br>It typically looks for a <i>flake.nix</i> file in the current directory or a specified path, builds the <i>devShell</i> attribute from it, and then spawns a shell with the environment variables and paths configured by the flake.<br>This command is a core component of modern Nix workflows for software development.


title: CAVEATS
content:
This command requires Nix 2.4 or newer with experimental features <i>nix-command</i> and <i>flakes</i> enabled.<br>The development environment created is ephemeral; changes made inside the shell are not persisted unless explicitly saved or managed by a Nix build process.<br>Performance can vary depending on the complexity of the flake and the efficiency of Nix's caching mechanisms.


title: FLAKES INTEGRATION
content:
<i>nix develop</i> is fundamentally tied to Nix flakes. It looks for a <i>flake.nix</i> file to define the development environment, specifically utilizing the <i>devShell</i> attribute (or a specific attribute path within <i>devShells</i>) within the flake's outputs to specify dependencies and configurations.


title: ENVIRONMENT ISOLATION
content:
A key feature of <i>nix develop</i> is its ability to create highly isolated development environments.<br>Tools and libraries are made available only within the spawned shell, preventing conflicts with global system installations and ensuring consistent development setups across different machines and users.


title: HISTORY
content:
<i>nix develop</i> was introduced as part of the Nix 2.4 release, alongside the new <i>nix commands</i> and <i>flakes</i> experimental features.<br>It largely superseded <i>nix-shell</i> as the primary way to define and enter declarative development environments using the new flake structure.<br>Its development reflects Nix's ongoing evolution towards more ergonomic, reproducible, and standardized project definitions, particularly for software development.


title: SYNOPSIS
content:
<b>nix edit</b> [<i>common-options</i>] {<<i>flake-ref</i>> | <<i>flake-ref</i>>#<<i>attrpath</i>>}<br><b>nix edit</b> [<i>common-options</i>] <b>--expr</b> <<i>nix-expression</i>><br><b>nix edit</b> [<i>common-options</i>] <b>--file</b> <<i>path</i>>


title: PARAMETERS
content:
<b><b>--expr</b> <<i>nix-expression</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows editing of a Nix expression provided directly as a string, rather than from a file or flake attribute. The string is written to a temporary file for editing.<br><br><b><b>--file</b> <<i>path</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a local file to be edited instead of a flake attribute. This is useful for editing arbitrary Nix files.<br><br><b><b>--apply</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After the editor exits, the modified expression is evaluated and applied. This typically means the associated derivation will be rebuilt or the expression re-evaluated based on the changes.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, the output (especially when combined with <b>--apply</b> for evaluation results) is formatted as JSON. Its direct utility for merely editing is limited.<br><br><b><b>--color</b> <<i>when</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control whether Nix uses colored output. <<i>when</i>> can be <i>auto</i> (default), <i>always</i>, or <i>never</i>.<br><br><b><b>--log-format</b> <<i>format</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the format of log output for operations like evaluation or building. <<i>format</i>> can be <i>raw</i>, <i>internal-json</i>, <i>bar</i>, <i>bar-with-logs</i>, or <i>json</i>.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrease verbosity of the output. Suppresses informational messages.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of the output. Shows more detailed logs and progress.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message for the <i>nix edit</i> command, detailing its usage and options.<br><br>


title: DESCRIPTION
content:
<i>nix edit</i> is a convenience command in the Nix 3.x CLI that allows users to easily inspect and modify Nix expressions. It takes a flake URI or an attribute path within a flake, locates the corresponding Nix expression, and opens it in the user's default editor (defined by the <b>$EDITOR</b> environment variable).<br><br>This is particularly useful for debugging, temporarily patching derivations, or quickly experimenting with changes to a package's definition without manually navigating the Nix store or source tree. After editing, the <b>--apply</b> option can be used to re-evaluate and apply the changes.


title: CAVEATS
content:
Changes made using <i>nix edit</i> are temporary and only applied locally within the Nix store. They are not saved to the original source location of a package or flake unless you explicitly copy the edited content back or commit it.<br><br>Using <b>--apply</b> can trigger significant re-evaluation and potentially rebuilding processes, which might consume considerable time and resources depending on the complexity and size of the modified expression. Ensure your <b>$EDITOR</b> environment variable is configured correctly, otherwise the command may fail or open a default editor you are not familiar with.


title: ENVIRONMENT VARIABLE
content:
The <b>$EDITOR</b> environment variable dictates which text editor <i>nix edit</i> will launch. If this variable is not set, Nix typically falls back to common system editors like <i>vi</i> or <i>nano</i>, or it may produce an error. Setting it to your preferred editor (e.g., <b>EDITOR=nvim</b>) ensures a consistent editing experience.


title: USAGE CONTEXT
content:
This command is invaluable for rapid iteration and debugging in Nix development. It allows developers to quickly prototype changes to a package's build instructions, apply temporary patches to a derivation, or explore the structure of a Nix expression without needing to modify the original source tree. The combination with <b>--apply</b> provides immediate feedback on changes.


title: HISTORY
content:
<i>nix edit</i> was introduced as part of the Nix 3.0 CLI re-design, which aimed to unify and simplify the user interface of the Nix package manager. It provides a more user-friendly way to interact with Nix expressions, streamlining a process that previously required more manual steps like locating source files in the Nix store.


title: SYNOPSIS
content:
<B>nix</B> <B>flake</B> <I>subcommand</I> [<I>options</I>] [<I>arguments</I>]<br><br>Common subcommands:<br>&nbsp;&nbsp;<B>nix</B> <B>flake</B> <B>build</B> [<I>flake-reference</I>]<I>#<output-attribute></I><br>&nbsp;&nbsp;<B>nix</B> <B>flake</B> <B>run</B> [<I>flake-reference</I>]<I>#<app-attribute></I> [<I>--</I> <I>app-args</I>]<br>&nbsp;&nbsp;<B>nix</B> <B>flake</B> <B>update</B> [<I>flake-reference</I>]<br>&nbsp;&nbsp;<B>nix</B> <B>flake</B> <B>init</B> [<I>--template <template-name></I>]<br>&nbsp;&nbsp;<B>nix</B> <B>flake</B> <B>show</B> [<I>flake-reference</I>]


title: PARAMETERS
content:
<b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display stack traces on error for debugging Nix expressions.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce machine-readable JSON output where applicable.<br><br><b>--override-input <name> <flake-ref></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override a specific flake input with a different flake reference or path.<br><br><b>--refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refresh all flake inputs before performing the operation, re-fetching their latest versions.<br><br><b>--flake <flake-ref></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the flake to operate on. Defaults to the flake in the current directory if not provided.<br><br><b>--option <name> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a Nix configuration option for the current command invocation.<br><br>


title: DESCRIPTION
content:
The <B>nix</B> <B>flake</B> command group provides the primary interface for interacting with <I>Nix flakes</I>. Flakes are an experimental feature in Nix 3 that aim to improve reproducibility, composability, and usability of Nix projects. A flake is essentially a directory containing a <I>flake.nix</I> file and optionally a <I>flake.lock</I> file. The <I>flake.nix</I> defines the project's inputs (dependencies) and outputs (like packages, applications, or NixOS modules). The <I>flake.lock</I> file ensures bit-for-bit reproducibility by pinning all inputs to specific revisions and cryptographic hashes.<br><br>Using flakes, developers can define self-contained, versioned Nix projects that are easier to share, build, and integrate with other flakes. This paradigm shift helps manage complex dependencies, provides a more predictable build environment, and facilitates collaboration. The <B>nix</B> <B>flake</B> subcommands allow for operations such as building, running, updating, evaluating, and creating flake-based projects.


title: CAVEATS
content:
Flakes are still an <B>experimental feature</B> in Nix. This means their behavior, API, and underlying implementation may change in future Nix versions. To enable flake functionality, you must add <I>experimental-features = nix-command flakes</I> to your Nix configuration file (<I>nix.conf</I>). While offering significant benefits in reproducibility and dependency management, flakes introduce a new paradigm that can be initially complex for users familiar only with traditional Nix expressions.


title: FLAKE REFERENCES
content:
A <I>flake-reference</I> is a string that specifies the location of a flake. It can be a local path (e.g., <I>.</I> for the current directory, <I>../my-flake</I>), a Git repository URL (e.g., <I>github:NixOS/nixpkgs</I>, <I>git+https://example.com/repo</I>), or a URL to a tarball (e.g., <I>https://example.com/archive.tar.gz</I>). It allows specifying a specific branch, tag, or commit hash for precise versioning.


title: FLAKE.NIX AND FLAKE.LOCK
content:
The <I>flake.nix</I> file is the core of a flake, defining its inputs (dependencies) and outputs (what the flake provides, like packages, applications, or NixOS modules). The <I>flake.lock</I> file, which is automatically generated and updated, pins all direct and transitive inputs to specific cryptographic hashes and Git revisions. This locking mechanism is crucial for guaranteeing bit-for-bit reproducibility of builds, ensuring that a flake will build the same way every time, regardless of when or where it's built.


title: HISTORY
content:
The concept of <I>Nix flakes</I> was introduced as an experimental feature in Nix 2.4, primarily to address limitations in previous Nix workflows, such as ensuring strict reproducibility, standardizing project inputs and outputs, and improving the discoverability of Nix-based projects. Prior to flakes, managing transitive dependencies and ensuring exact build environments across different machines could be challenging. Flakes provide a more robust and opinionated structure, similar to <I>package-lock.json</I> or <I>Gemfile.lock</I> in other ecosystems, aiming to lock down all dependencies to specific revisions. This development marks a significant step towards making Nix more accessible, predictable, and composable for complex software projects.


title: SYNOPSIS
content:
`nix profile <I>subcommand</I> [<I>options</I>...]<br><br>Common subcommands include:<br>  `nix profile <B>install</B> [<I>flake-url</I>] [<I>--profile</I> <I>path</I>] [<I>attr-path</I>]...`<br>  `nix profile <B>remove</B> [<I>--profile</I> <I>path</I>] <I>item-id</I>...`<br>  `nix profile <B>upgrade</B> [<I>--profile</I> <I>path</I>] [<I>item-id</I>]...`<br>  `nix profile <B>list</B> [<I>--profile</I> <I>path</I>]`<br>  `nix profile <B>rollback</B> [<I>--profile</I> <I>path</I>] [<I>generation</I>]`<br>  `nix profile <B>diff-closures</B> [<I>--profile</I> <I>path</I>] [<I>generation1</I>] [<I>generation2</I>]`


title: PARAMETERS
content:
<b><B>install</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds new packages to the user profile. Can install from Nix paths, attribute paths in Nixpkgs, or flake outputs.<br><br><b><B>remove</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes packages from the user profile by their item ID (as shown by `nix profile list`).<br><br><b><B>upgrade</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades packages currently in the user profile to their latest available versions.<br><br><b><B>list</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all packages currently installed in the user profile, showing their item IDs, attribute paths, and current generation.<br><br><b><B>rollback</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the user profile to a previous generation. If no generation is specified, it rolls back to the immediately preceding one.<br><br><b><B>history</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a list of all historical generations of the user profile, including creation dates and descriptions.<br><br><b><B>diff-closures</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares the full dependency closures of two specified profile generations, showing what packages have been added or removed.<br><br><b><I>--profile</I> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative profile path to operate on instead of the default `~/.nix-profile`.<br><br><b><I>--dry-run</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would happen without actually modifying the profile.<br><br><b><I>--print-rollbacks</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For `install` or `upgrade` commands, prints the new generation number to facilitate quick rollback if needed.<br><br><b><I>--show-trace</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a full stack trace for Nix evaluation errors, aiding in debugging.<br><br>


title: DESCRIPTION
content:
The `nix profile` command (often referred to as `nix3-profile` in the context of the new Nix CLI) is the modern, imperative package manager for user-specific environments. It allows users to imperatively add, remove, and upgrade packages in their `~/.nix-profile` symlink, which points to a specific "generation" of their user environment. Each modification creates a new generation, enabling easy rollback to previous states. This command simplifies package management compared to the older `nix-env`, providing a more declarative and reproducible way to manage packages within a user's profile without affecting the global Nix store or other users. It integrates seamlessly with the Nix ecosystem, especially with Nix flakes, allowing users to install packages directly from flake inputs or traditional Nix expressions.


title: CAVEATS
content:
The `nix profile` command manages <I>imperative</I> installations. For truly reproducible and declarative environment definitions, Nix flakes with `nix build` or `nix develop` are generally preferred.<br>Each `nix profile` operation creates a new generation, which consumes disk space. Regular garbage collection (`nix store gc` or `nix-collect-garbage`) is necessary to reclaim space from older, unused generations.<br>Packages installed via `nix profile` are symlinked into the `~/.nix-profile` directory (e.g., `~/.nix-profile/bin`). Ensure this directory is included in your `PATH` environment variable for executables to be found.


title: GENERATIONS AND ROLLBACKS
content:
Every successful `nix profile install`, `remove`, or `upgrade` operation creates a new "generation" of your profile. These generations are numbered chronologically, starting from 1. You can easily view your history with `nix profile history` and revert to any previous stable generation using `nix profile rollback <I>generation_number</I>`, providing a powerful undo mechanism for package changes.


title: FLAKE INTEGRATION
content:
`nix profile` fully supports Nix flakes. You can install packages directly from a flake's outputs, e.g., `nix profile install nixpkgs#hello` or `nix profile install github:NixOS/nixpkgs#firefox`. This allows for highly reproducible installations tied to specific versions of package sets and simplifies managing dependencies from various sources.


title: HISTORY
content:
The `nix profile` command was introduced as a core component of the new Nix 2.0 CLI, which aimed to provide a more consistent and user-friendly interface than the previous collection of disparate `nix-*` commands (such as `nix-env`, `nix-build`, `nix-shell`). It effectively deprecates much of `nix-env`'s functionality for managing user profiles, offering an improved system for tracking profile generations and facilitating easier rollbacks. The transition to the new CLI, and `nix profile` specifically, was a significant step towards a more unified and accessible Nix user experience, especially with the later introduction and integration of Nix flakes.


title: PARAMETERS
content:
<b>--global / -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Applies to <i>add</i>, <i>remove</i>) Modifies the global registry (shared across projects or users) instead of the default project-specific registry.<br><br><b>--flake <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory of the Nix flake to operate on. Defaults to the current working directory.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Applies to <i>list</i>) Outputs the result in a machine-readable JSON format.<br><br><b>--raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Applies to <i>list</i>) Outputs only the raw flake references, without additional formatting.<br><br><b>add <name> <flake-ref></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new registry entry. <I>name</I> is the canonical name, and <I>flake-ref</I> is the flake reference (e.g., a path or URL).<br><br><b>remove <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the registry entry identified by <I>name</I>.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently configured registry entries, showing their names and corresponding flake references.<br><br><b>pin <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pins the registry entry <I>name</I> to its currently resolved locked input. This action locks the exact version of the flake input for reproducibility.<br><br><b>update <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates a pinned registry entry <I>name</I> to its latest available version, resolving it against the most recent flake reference.<br><br>


title: DESCRIPTION
content:
The <b>nix3-registry</b> command is a crucial tool for managing entries within the Nix registry. This registry serves as a mapping mechanism, associating user-friendly, canonical names (e.g., <i>nixpkgs</i>) with specific Nix flake references (e.g., <i>github:NixOS/nixpkgs/nixos-23.11</i>). It's an integral part of the experimental Nix Flakes feature, designed to enhance the reproducibility and usability of Nix-based projects.<br><br>By providing stable names for flake inputs, <b>nix3-registry</b> simplifies dependency management and ensures that builds are consistent across different environments. Users can add new mappings, remove old ones, list all configured entries, and crucially, <b>pin</b> specific versions of inputs to guarantee immutability for reproducible builds. It also supports updating these pinned entries to their latest available versions.


title: CAVEATS
content:
The Nix Flakes feature, including the <b>nix3-registry</b> command, is still considered experimental. Its behavior, command-line interface, and underlying mechanisms might evolve in future Nix releases.<br>Always be mindful of whether you are modifying the project-specific (local) registry or the global registry when using the <i>--global</i> option, as this significantly impacts the scope of your changes.


title: LOCAL VS. GLOBAL REGISTRY
content:
By default, <b>nix3 registry</b> operations are scoped to the current Nix flake project, modifying its local registry data (often implicitly managed). Using the <i>--global</i> option allows you to interact with a shared, user-specific (typically in <i>~/.config/nix/registry.json</i>) or system-wide (<i>/etc/nix/registry.json</i>) registry. This distinction is crucial for managing common dependencies across multiple projects or for system-wide configuration.


title: INTERACTION WITH FLAKE.LOCK
content:
The registry works in conjunction with the <i>flake.lock</i> file. When you <i>pin</i> a registry entry, Nix resolves the flake reference to a precise Git commit hash or content hash and records this in the <i>flake.lock</i> file. Subsequent builds will then use this locked version, ensuring reproducibility. The <i>update</i> subcommand is used to refresh this locked version to the latest available based on the original flake reference.


title: HISTORY
content:
The concept of a Nix registry and the <b>nix3-registry</b> command were introduced as part of the experimental Nix Flakes initiative. Flakes began gaining prominence around Nix version 2.4, aiming to provide a more structured, reproducible, and user-friendly way to manage Nix projects and their dependencies. The registry was a key component in achieving stable and memorable names for flake inputs.


title: PARAMETERS
content:
<b>--file <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load a Nix expression from <I>path</I> into the REPL environment.<br><br><b>--expr <expr></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluate <I>expr</I> directly before entering the REPL.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prohibit undefined variables and attributes during evaluation.<br><br><b>--pure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disallow access to the outside world (e.g., network, /dev/urandom) during evaluation.<br><br><b>--impure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow access to the outside world (this is often the default behavior for the REPL to enable common workflows).<br><br><b>--arg <name> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass an argument named <I>name</I> with Nix value <I>value</I> to the top-level expression loaded into the REPL.<br><br><b>--argstr <name> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass an argument named <I>name</I> with string value <I>value</I> to the top-level expression loaded into the REPL.<br><br><b><path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The path to a Nix expression (file or directory, e.g., <code>./default.nix</code> or <code><nixpkgs></code>) to be loaded and made available in the REPL's top-level scope. If a directory, it looks for <code>default.nix</code>.<br><br>


title: DESCRIPTION
content:
<i>nix3-repl</i> is the <i>Read-Eval-Print Loop</i> for Nix expressions, part of the modern Nix 3 command-line interface. It provides an interactive shell where users can evaluate Nix code snippets, import files, and inspect Nix values and derivations in real-time. This command is invaluable for debugging Nix expressions, learning the Nix language, and quickly testing configuration fragments or package definitions. It starts with a clean environment unless a specific Nix expression file or path is provided, allowing users to build up their context incrementally. The <i>nix3-repl</i> offers a powerful way to understand how Nix resolves paths, handles attributes, and evaluates lazy expressions, making it an essential tool for Nix developers and users alike.


title: CAVEATS
content:
<b>Performance:</b> Large Nix expressions or those involving complex computations can lead to slow evaluation within the REPL.<br><b>Statefulness:</b> Variables defined in the REPL persist within the session, which can sometimes lead to unexpected interactions if not managed carefully.<br><b>Environment Differences:</b> The REPL's evaluation environment might differ slightly from a pure build environment, especially if <code>--impure</code> is used implicitly or explicitly, or due to network access.


title: INTERACTIVE FEATURES
content:
The REPL supports tab completion for variables, attributes, and built-ins. It also allows multiline input and history navigation, similar to other interactive shell environments.


title: CONTEXT LOADING
content:
When a <I>path</I> like <code><nixpkgs></code> is provided as an argument (e.g., <code>nix repl <nixpkgs></code>), the REPL makes the expression at that path available. For example, <code>pkgs</code> will then be directly accessible, allowing you to access <code>pkgs.hello</code> or <code>pkgs.lib</code> without explicit imports inside the REPL.


title: HISTORY
content:
The interactive REPL functionality has been a cornerstone of the Nix ecosystem for a long time, evolving alongside the Nix language itself. The <i>nix3-repl</i> command represents the modern incarnation of this tool, integrated into the unified <i>nix</i> CLI (often referred to as 'new Nix commands') that started gaining prominence around Nix 2.0. This new CLI aims to provide a more consistent and user-friendly interface compared to the older, separate <code>nix-*</code> commands, while retaining the core interactive evaluation capabilities crucial for Nix development and exploration.


title: SYNOPSIS
content:
<B>nix3-run</B> [<I>options</I>] <I>flake-url</I> [<I>--</I> <I>program-args</I>...]<br><B>nix3-run</B> [<I>options</I>] <I>package-name</I> [<I>--</I> <I>program-args</I>...]


title: PARAMETERS
content:
<b><I>flake-url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL or path to a Nix flake containing the program to run (e.g., <I>nixpkgs#hello</I>, <I>gitlab:my-org/my-project</I>, or <I>.</I> for the current directory's flake).<br><br><b><I>package-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A package name from <B>nixpkgs</B> (e.g., <I>nixpkgs#cowsay</I>) or a specific attribute path within a flake.<br><br><b><I>--</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special separator. All arguments following <I>--</I> are passed directly to the program being executed by <B>nix3-run</B>.<br><br><b><I>program-args</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to be passed to the program launched by <B>nix3-run</B>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce command output in JSON format, useful for scripting.<br><br><b>--refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a refresh of flake inputs and any associated data, ensuring the latest versions are used.<br><br><b>--impure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the command to access impure system paths, potentially breaking reproducibility.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to access the network during execution.<br><br>


title: DESCRIPTION
content:
The <B>nix3-run</B> command is a shim or legacy alias for the modern <B>nix run</B> command within the Nix package manager. Its primary purpose is to fetch and execute a program or package defined in a Nix flake or from <B>nixpkgs</B> directly, without needing to explicitly build or install it into your user environment. This makes it ideal for ad-hoc tool usage, quickly testing applications, or running executables from a specific version of a package.<br><br>When invoked, <B>nix3-run</B> (or <B>nix run</B>) will first ensure that the specified package or executable is built and present in the Nix store. If it's not available locally, Nix will download or build it along with all its dependencies in a reproducible manner. Once ready, the program is executed in a clean, isolated environment, inheriting only what's necessary for its operation. This command leverages Nix's content-addressable store and strict dependency management to guarantee that you're running precisely the specified version of a program, free from environmental pollution.


title: CAVEATS
content:
The <B>nix3-run</B> command is largely a legacy alias. Users are encouraged to use the canonical <B>nix run</B> command for all modern Nix workflows. This command (and <B>nix run</B>) requires Nix 2.4 or newer, typically with the 'flakes' experimental feature enabled. While convenient, running commands this way can incur a one-time build or download cost for dependencies if they are not already in your Nix store, potentially consuming network bandwidth and disk space.


title: USAGE EXAMPLES
content:
<b>Run a program from nixpkgs:</b><br><I>nix3-run nixpkgs#cowsay</I><br><I>nix3-run nixpkgs#cowsay -- 'Hello Nix!'</I><br><br><b>Run an executable from the current directory's flake:</b><br>Assume your <B>flake.nix</B> defines an app or package named <I>my-app</I>:<br><I>nix3-run .#my-app</I><br><br><b>Run a specific version of a program from a remote flake:</b><br><I>nix3-run 'github:NixOS/nixpkgs/nixos-23.11#hello'</I>


title: HISTORY
content:
The <B>nix run</B> command was introduced as a part of the new, experimental command-line interface (CLI) for Nix, alongside the 'flakes' feature. This new CLI aimed to simplify common Nix operations and make them more intuitive. The <B>nix3-run</B> alias (and similar <B>nix3-*</B> commands) emerged during the transition period from the older <B>nix-*</B> commands to the unified <B>nix</B> CLI. It served as a compatibility layer or a bridge, allowing scripts and users accustomed to older naming conventions to gradually adopt the new syntax while still benefiting from the new features. Over time, as the new CLI matured, the need for these aliases diminished, with <B>nix run</B> becoming the standard way to execute packages directly.


title: PARAMETERS
content:
<b><i>&lt;flake-url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional flake URL (e.g., <i>github:NixOS/nixpkgs#hello</i>, <i>path:/my/flake</i>) to specify where to search. If omitted, it defaults to the primary <i>nixpkgs</i> instance in the current flake's inputs or the global registry.<br><br><b><i>&lt;query&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more search terms to match against package names, descriptions, or attribute paths. Multiple terms will narrow the search.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output search results in a machine-readable JSON format, suitable for scripting and programmatic parsing.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate without attempting to connect to the internet, useful for reproducible builds or when network access is unavailable.<br><br><b><b>--refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a refresh of the flake registry and all flake inputs before performing the search, ensuring the latest package metadata is used.<br><br><b><b>--inputs-from</b> <i>&lt;flake-url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the search using the flake inputs defined in a different flake, without changing the current directory's flake context.<br><br><b><b>--override-input</b> <i>&lt;name&gt;</i> <i>&lt;path|flake-url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Temporarily override a specific flake input named <i>&lt;name&gt;</i> with a local path or another flake URL for the duration of the search.<br><br><b><b>--system</b> <i>&lt;system&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages compatible with a specific system architecture (e.g., <i>x86_64-linux</i>, <i>aarch64-darwin</i>) instead of the current system.<br><br><b><b>--legacy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the search using the legacy <i>NIX_PATH</i> mechanism instead of the default flake-based evaluation. Useful for non-flake environments.<br><br>


title: DESCRIPTION
content:
<i>nix search</i> is a powerful command in the Nix ecosystem, designed to help users discover and locate packages, derivations, and attributes available within the Nix store or defined in Nix flakes. It queries package registries, local flake inputs, or specified flake URLs to find items matching one or more provided string patterns.<br><br>This command is crucial for exploring the vast collection of software managed by Nix, allowing users to search by package name, description, or other metadata. The output typically presents the package's attribute path, version, and a concise description, making it easy to identify the desired software. <i>nix search</i> seamlessly integrates with the Nix flake system, enabling searches across various Nix channels, specific flake inputs, or arbitrary local/remote flake URLs. It serves as the primary tool for users to efficiently navigate and leverage the Nix package collection.


title: CAVEATS
content:
The initial execution of <i>nix search</i> or runs with <b>--refresh</b> can be slow as it might involve fetching significant package metadata from the internet.<br><br>The command searches against *available* derivations in the configured repositories or flakes, not necessarily packages currently *installed* on your system.<br><br>The textual output can be verbose; using the <b>--json</b> option is highly recommended for scripting or integration with other tools.


title: HISTORY
content:
The <i>nix search</i> command is a core component of the "new" Nix command-line interface (CLI), which was introduced as an experimental feature (<i>nix-command</i>) and became the default CLI in Nix versions 2.4/2.6 onwards. Prior to this, users often relied on commands like <i>nix-env -qa</i> or manual browsing of the NixOS package website for package discovery. The unified <i>nix search</i> command provides a more intuitive, powerful, and flake-aware mechanism for searching Nix packages and attributes directly from the terminal, integrating seamlessly with the modern Nix ecosystem.


title: PARAMETERS
content:
<b><b>add-root</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <i>PATH</i> as a garbage collector root, preventing it from being collected. Useful for keeping specific derivations or generations alive.<br><br><b><b>cat</b> <i>STORE_PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the contents of a file inside a <i>STORE_PATH</i> to standard output. Useful for quickly inspecting configuration or source files.<br><br><b><b>copy</b> <i>PATH</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies one or more <i>PATH</i>s from a local or remote Nix store to another. Essential for setting up binary caches or distributing built artifacts.<br><br><b><b>gc</b> [<i>options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the garbage collector to delete unreachable paths from the Nix store, reclaiming disk space. Options control behavior like deletion dry-runs or maximum space to free.<br><br><b><b>path-info</b> <i>STORE_PATH</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows detailed information about one or more <i>STORE_PATH</i>s, including their closure size, references, and whether they are valid.<br><br><b><b>prefetch-url</b> <i>URL</i> [<i>options</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a file from a specified <i>URL</i> and adds it to the Nix store. Useful for fetching external sources with integrity checks.<br><br><b><b>read-log</b> <i>STORE_PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads and prints the build log for a given <i>STORE_PATH</i>, which can help in debugging failed builds or understanding build processes.<br><br>


title: DESCRIPTION
content:
The <b>nix3-store</b> command (part of the modern <b>nix store</b> command within the unified Nix CLI) provides a crucial low-level interface for interacting directly with the Nix store.<br><br>The Nix store is the foundational component of the Nix package manager, acting as a global, content-addressable, and immutable filesystem location (typically <i>/nix/store</i>) where all software components, configurations, and build artifacts are stored. Each path in the store is uniquely identified by a cryptographic hash of its inputs and dependencies, ensuring reproducibility and preventing conflicts.<br><br>This command allows users and automated systems to perform various operations on store paths, such as querying their information, adding or deleting garbage collector roots, copying paths between stores, running the garbage collector to reclaim disk space, and inspecting build logs. It's often used by Nix internals or for advanced debugging and system management, providing granular control over the integrity and state of the installed software ecosystem.


title: CAVEATS
content:
Direct manipulation of the Nix store using <b>nix store</b> subcommands should be done with caution, as improper usage can lead to an inconsistent store state or break dependencies. Specifically, manually removing paths without using <b>nix store gc</b> is highly discouraged. Paths in the Nix store are immutable; once created, they cannot be modified. All changes result in new store paths.


title: CONTENT-ADDRESSABLE STORAGE
content:
A core concept behind the Nix store is <i>content-addressable storage</i>. This means that every path in the store is named by a cryptographic hash of its complete set of inputs (source code, build scripts, dependencies, etc.). This ensures that if two different build processes produce the exact same output, they will share the same store path, leading to efficient storage and guaranteeing bit-for-bit reproducibility.


title: GARBAGE COLLECTION ROOTS
content:
To prevent essential software from being deleted by the garbage collector (GC), Nix uses <i>GC roots</i>. These are symlinks from well-known locations (like user profiles or system configurations) pointing into the Nix store. Any store path reachable from a GC root is considered 'live' and will not be collected. <b>nix store add-root</b> explicitly creates such roots, ensuring specific derivations persist.


title: HISTORY
content:
The functionality of <b>nix store</b> was historically provided by a standalone executable named <b>nix-store</b>. With the introduction of the unified Nix command-line interface (CLI), many of the legacy Nix commands were integrated as subcommands under the main <b>nix</b> executable. Thus, <b>nix3-store</b> (or `nix3` implying the unified CLI) refers to the <b>nix store</b> subcommand, signifying a shift towards a more consistent and user-friendly command structure while retaining the powerful low-level store management capabilities.


title: PARAMETERS
content:
<b><I>PATH</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more Nix store paths (e.g., <I>/nix/store/&lt;hash&gt;-pkg</I>) for which to find reverse dependencies. This is the specific item whose usage you want to investigate.<br><br><b>--recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively show all paths depending on the specified <I>PATH</I>, not just direct dependencies. This provides a comprehensive view of the entire dependency chain.<br><br><b>--roots</b><br>&nbsp;&nbsp;&nbsp;&nbsp;In addition to showing paths depending on <I>PATH</I>, also display the ultimate garbage collector roots (e.g., user profiles, explicitly registered GC roots) that depend on those intermediate paths. This is particularly useful for understanding why something is not being garbage collected.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format, which is ideal for programmatic parsing and integration with scripts or other tools.<br><br><b>--store <I>STORE_URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a different Nix store to query instead of the default local store.<br><br>


title: DESCRIPTION
content:
The <I>nix why-depends</I> command, part of the modern Nix 3.x command-line interface, is a powerful tool for analyzing the dependency graph within the Nix store. Given a specific Nix store path (e.g., a package or library), it traverses the dependency graph <I>in reverse</I> to identify which other Nix store paths directly or indirectly depend on the specified item. This functionality is crucial for understanding disk space usage, debugging build inputs, and identifying components that are preventing others from being garbage collected. It helps users trace the chain of dependencies from a root down to a specific dependent path, providing clarity on how various parts of the Nix system are interconnected.


title: CAVEATS
content:
For Nix stores with a very large number of paths or deeply nested dependency graphs, the <I>nix why-depends</I> command can take a significant amount of time to compute and display results. The output, especially when using the <I>--recursive</I> option without specific filtering, can be quite extensive. It only reports on paths that are currently present in the Nix store; paths that have already been garbage collected will not appear in the results.


title: COMMON USE CASES
content:
<I>nix why-depends</I> is frequently used for:<br><b>Disk Space Management:</b> Identifying which large packages or profiles are pulling in specific dependencies, helping to inform decisions about what can be safely removed or optimized.<br><b>Debugging Build Failures:</b> Tracing back dependencies to understand why a particular component is being built or is failing.<br><b>Garbage Collection Analysis:</b> Determining which active roots (e.g., your user profile, generations) are preventing a specific store path from being garbage collected, thereby freeing up disk space.


title: OUTPUT INTERPRETATION
content:
By default, the command displays a human-readable tree-like structure. Each line represents a path in the dependency chain, with indentation indicating the depth of dependency. The specified <I>PATH</I> will typically appear at the bottom of a chain, with its direct and indirect reverse dependencies listed above it.


title: HISTORY
content:
The functionality provided by <I>nix why-depends</I> has been a fundamental part of the Nix ecosystem for understanding store dependencies for many years. Originally, this capability was often exposed through a separate executable, <I>nix-why-depends</I>. With the evolution to the unified <I>nix</I> command-line interface (commonly referred to as the 'new CLI' or part of Nix 2.0+ and 3.x series), its functionality was integrated as a subcommand, making it more accessible and consistent with other Nix operations. Its core purpose of reverse dependency analysis has remained unchanged throughout its development.


title: SYNOPSIS
content:
<b><I>nixos-container</I></b> <I>COMMAND</I> [<I>OPTIONS</I>] [<I>ARGUMENTS</I>]<br><br>Examples:<br><b><I>nixos-container</I></b> create my-container<br><b><I>nixos-container</I></b> start my-container<br><b><I>nixos-container</I></b> enter my-container --root -- /bin/bash<br><b><I>nixos-container</I></b> list


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command or a specific subcommand.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a stack trace on error (a common Nix/NixOS option).<br><br><b>create --auto-start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the newly created container immediately after creation.<br><br><b>create --ephemeral</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mark the container as ephemeral; it will be destroyed when stopped.<br><br><b>create --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the creation of a container, potentially overwriting an existing one.<br><br><b>destroy --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the destruction of a container, even if it's running.<br><br><b>enter --root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the container as the root user. By default, it uses the current user.<br><br><b>enter --set-env <VAR=VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an environment variable for the command executed inside the container.<br><br><b>pull-config --switch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;After pulling the configuration, activate it inside the container.<br><br>


title: DESCRIPTION
content:
The <b><I>nixos-container</I></b> command-line tool provides a declarative interface for managing lightweight containers on NixOS. Leveraging <I>systemd-nspawn</I> internally, it extends its capabilities with the power of NixOS's reproducible configuration management. Users define their containers, including their networking, state persistence, and internal NixOS configuration, directly within their main NixOS system configuration (typically <I>/etc/nixos/configuration.nix</I>).<br><br>This approach enables highly reproducible, version-controlled container environments ideal for service isolation, development sandboxes, or testing. <b><I>nixos-container</I></b> simplifies common tasks such as container creation, starting, stopping, entering, and destruction, integrating seamlessly with the NixOS build and activation process. Unlike tools like Docker, <b><I>nixos-container</I></b> focuses on encapsulating full NixOS systems, managed purely declaratively, rather than isolated application layers. It supports both privileged and unprivileged (rootless) operations, offering flexibility for various use cases while maintaining the strong guarantees of the Nix ecosystem.


title: CAVEATS
content:
Built upon <I>systemd-nspawn</I>, not a full virtual machine or a Docker-style layered image system.<br>Requires NixOS as the host operating system.<br>Networking configuration (e.g., bridged, host, private) can be complex and requires careful setup in the NixOS configuration.<br>Rootless containers, while supported, may have certain limitations depending on kernel features and host system configuration.<br>Container state persistence is governed by the <I>stateDir</I> option in the container's NixOS configuration.<br>Debugging services inside containers might require specific tools and understanding of <I>systemd-nspawn</I> logging.


title: COMMON SUBCOMMANDS
content:
The primary functionality of <I>nixos-container</I> is accessed via subcommands:<br><b><I>create</I></b> <I>&lt;name&gt;</I>: Builds and initializes a new container based on its NixOS declaration.<br><b><I>start</I></b> <I>&lt;name&gt;</I>: Starts a configured container.<br><b><I>stop</I></b> <I>&lt;name&gt;</I>: Stops a running container.<br><b><I>status</I></b> <I>&lt;name&gt;</I>: Displays the current status of a container.<br><b><I>enter</I></b> <I>&lt;name&gt;</I> [-- <I>command</I>...]: Enters a running container's shell or executes a specific command inside it.<br><b><I>destroy</I></b> <I>&lt;name&gt;</I>: Permanently removes a container and its associated state.<br><b><I>list</I></b>: Lists all containers defined in the NixOS configuration.<br><b><I>rootless-install</I></b>: Prepares the host system for running rootless containers for the current user.<br><b><I>pull-config</I></b> <I>&lt;name&gt;</I>: Pulls the latest host configuration into the container, allowing it to reconfigure itself.


title: DECLARATIVE CONFIGURATION
content:
Containers managed by <I>nixos-container</I> are defined declaratively in the host's <I>/etc/nixos/configuration.nix</I> or an imported module. An example definition typically looks like:<br><b><I>containers.my-web-server = {</I></b><br><i>  config = {</i><br><i>    system.stateVersion = "23.11";</i><br><i>    networking.hostName = "web-server";</i><br><i>    # ... other NixOS options for the container ...</i><br><i>  };</i><br><i>  autoStart = true;</i><br><i>  privateNetwork = true;</i><br><i>  # ... other container-specific options ...</i><br><b><I>};</I></b><br>This configuration is then applied via <I>nixos-rebuild switch</I> on the host, which prepares the container environments.


title: NETWORKING
content:
Containers can be configured with various networking modes:<br><b><I>privateNetwork</I></b>: Creates a private network for the container with NAT to the host's network.<br><b><I>hostAddress</I></b> / <b><I>containerAddress</I></b>: Defines specific IP addresses for the host and container within the private network.<br><b><I>extraHostPaths</I></b>: Allows mounting paths from the host into the container.<br><b><I>bindHost</I></b>: Binds a specific host IP address to the container.<br><b><I>network</I></b>: Connects the container to a specific network bridge on the host.


title: HISTORY
content:
The <b><I>nixos-container</I></b> tool emerged as a natural evolution of NixOS's declarative approach to system management, extending it to lightweight containerization. Initially, NixOS users leveraged <I>systemd-nspawn</I> directly. However, the need for a more integrated, declarative, and reproducible way to manage these containers led to the development of <b><I>nixos-container</I></b>. Its focus has always been on providing a seamless experience within the NixOS ecosystem, allowing container definitions to be part of the host's central <I>configuration.nix</I>. Significant development has included improvements in networking capabilities and the introduction of robust rootless container support, making it a powerful tool for creating isolated, reproducible environments.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the option information in JSON format, suitable for programmatic parsing.<br><br><b>--xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the option information in XML format.<br><br><b>--builtins</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes options that are built into Nix itself, beyond just NixOS specific modules.<br><br><b>--type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the expected type of the option (e.g., <I>string</I>, <I>boolean</I>, <I>listOf package</I>).<br><br><b>--value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current evaluated value of the option based on the configuration.<br><br><b>--file <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a path to a NixOS configuration file to query options from, instead of the active system.<br><br><b>--flake <FLAKE_REF></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a Nix flake reference (e.g., <I>.#nixosConfigurations.my-system</I>) to evaluate options from.<br><br><b>--system <SYSTEM></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the system architecture (e.g., <I>x86_64-linux</I>) for evaluation.<br><br><b>--system-path <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to an existing system closure, overriding the system detected or specified by <I>--system</I>.<br><br><b>--root <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the NixOS installation directory.<br><br><b>--cores <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of CPU cores to use for Nix evaluation.<br><br><b>--max-memory-size <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum memory size in MB to be used by Nix for evaluation.<br><br><b>--option <NAME> <VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a specific Nix option (e.g., <I>binary-caches</I>) with a custom value to the evaluation context.<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed Nix evaluation traces on errors, useful for debugging.<br><br><b>--override-input <INPUT> <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides a specific flake input with a custom path during evaluation.<br><br><b>--rebuild-d-dir <PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory for <I>rebuild-d</I> files (internal use for development).<br><br><b>--tarball-url <URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a URL to fetch the <I>nixpkgs</I> tarball from, for non-flake configurations.<br><br><b>--impure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows impure evaluation, which can access files outside the Nix store (e.g., <I>/dev/urandom</I>).<br><br>


title: DESCRIPTION
content:
<I>nixos-option</I> is a powerful command-line utility for exploring and querying the vast array of configuration options available within a NixOS system. It allows users to search for, view the type of, and retrieve the current evaluated value of specific NixOS options. This tool is indispensable for NixOS administrators and developers, enabling them to efficiently navigate the extensive configuration space, understand available settings, and diagnose system configuration issues.<br><br>It can query options from the currently running system, a specified NixOS configuration file, or even a Nix flake, providing flexibility for various development and debugging scenarios. By understanding the options and their current values, users can more effectively write and debug their declarative NixOS configurations.


title: CAVEATS
content:
<I>nixos-option</I> evaluates the NixOS configuration to provide accurate information, which can be computationally intensive and time-consuming for large or complex systems. It requires a NixOS environment or a specified configuration/flake to function correctly. Using the <I>--value</I> option might trigger extensive evaluation, potentially leading to long execution times or errors if the configuration is broken or contains undeclared dependencies.


title: DISCOVERING OPTIONS
content:
Users can execute <I>nixos-option</I> without any arguments to list all available top-level configuration options. To narrow down the search, a partial name can be provided, such as <B>nixos-option networking</B>, which will display all options related to networking. This interactive exploration greatly aids in finding relevant configuration points.


title: DEBUGGING CONFIGURATION
content:
By combining options like <I>--type</I> and <I>--value</I>, users can inspect both the expected type and the currently evaluated value of a specific option within their configuration. For example, <B>nixos-option boot.loader.systemd-boot.enable --type --value</B> provides crucial insights for debugging configuration discrepancies or unexpected system behavior.


title: PROGRAMMATIC ACCESS
content:
The <I>--json</I> output format makes <I>nixos-option</I> an excellent candidate for scripting and integration into other tools or automated workflows. This allows developers to build custom scripts that dynamically query and respond to NixOS configuration details.


title: HISTORY
content:
The <I>nixos-option</I> command emerged as a vital tool with the growth and increasing complexity of the NixOS declarative configuration system. As NixOS evolved, defining system state through a vast module system and numerous configuration options, the need for a straightforward way to discover and inspect these options directly from the command line became paramount. It significantly simplified the process for users and developers to understand and interact with the intricate NixOS configuration space, moving beyond simply relying on external documentation or manual exploration of source code.


title: SYNOPSIS
content:
<code>nixos-rebuild <b>[subcommand]</b> <b>[options...]</b></code><br>Examples:<br><code>nixos-rebuild <b>switch</b></code><br><code>nixos-rebuild <b>boot</b> --flake <i>.</i>#<i>myConfig</i></code><br><code>nixos-rebuild <b>rollback</b></code>


title: PARAMETERS
content:
<b><code>switch</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Builds and activates the new configuration immediately. This is the most common subcommand.</i><br><br><b><code>boot</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Builds the configuration and sets it as the default boot entry. Requires a reboot to take effect.</i><br><br><b><code>test</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Builds the configuration and temporarily loads it into a testing environment without global activation.</i><br><br><b><code>dry-run</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the planned changes and derivations that would be built without actually performing the build or activation.</i><br><br><b><code>build</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Only builds the specified configuration into the Nix store without activating it.</i><br><br><b><code>rollback</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reverts the system to the previously active configuration generation.</i><br><br><b><code>--flake <i><flake-uri></i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a Nix flake to build the system configuration from. E.g., <code>.</code>, <code>github:NixOS/nixpkgs#nixos-23.11</code>.</i><br><br><b><code>-I <i><path></i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds <code><path></code> to the Nix search path for finding imported Nix expressions (legacy method).</i><br><br><b><code>--upgrade</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Upgrades Nixpkgs before building the configuration. Often used with non-flake setups.</i><br><br><b><code>--show-trace</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays detailed stack traces during evaluation errors, useful for debugging.</i><br><br><b><code>--cores <i><N></i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the number of CPU cores to use for parallel builds.</i><br><br><b><code>--max-jobs <i><N></i></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the maximum number of parallel build jobs.</i><br><br>


title: DESCRIPTION
content:
<code>nixos-rebuild</code> is the central command for managing NixOS system configurations. It takes a declarative Nix expression (typically <code>configuration.nix</code> or a Nix flake) describing the desired system state, builds it using the Nix package manager, and then atomically switches the running system to this new configuration. This process ensures system stability and reproducibility by guaranteeing that all dependencies are correctly built and linked. It supports rolling back to previous system generations, providing a robust mechanism for recovery in case of issues. The command leverages Nix's immutable store and cryptographic hashing to achieve highly reliable and atomic updates, making system management straightforward and safe.


title: CAVEATS
content:
Requires root privileges to perform system-wide changes.<br>Initial builds or significant configuration changes can consume considerable time and disk space.<br>Network connectivity is often required to fetch necessary packages and sources.<br>While rollbacks are atomic for the system configuration, they do not revert changes to user data or persistent state outside the Nix store.


title: DECLARATIVE SYSTEM MANAGEMENT
content:
<code>nixos-rebuild</code> exemplifies NixOS's declarative approach, where the desired system state is described in configuration files, and the command ensures the system matches that declaration, rather than imperatively executing steps.


title: ATOMIC UPDATES AND ROLLBACKS
content:
Every successful <code>nixos-rebuild</code> operation creates a new "generation" of the system. This allows for atomic switches between generations and instant rollbacks to any prior working state, providing unparalleled system stability and recovery capabilities.


title: FLAKE INTEGRATION
content:
Modern NixOS configurations often leverage <I>Nix flakes</I>. <code>nixos-rebuild</code> fully supports flakes via the <code>--flake</code> option, enabling reproducible, self-contained, and easily shareable system configurations defined by a <code>flake.nix</code> file.


title: HISTORY
content:
<code>nixos-rebuild</code> has been a fundamental component of the NixOS project since its inception, embodying the declarative and atomic update philosophy of the operating system. Its evolution has closely mirrored that of the Nix package manager, adapting to new features like the introduction of flakes, which significantly streamlined configuration management and reproducibility. It remains the primary user-facing tool for managing system state on NixOS, solidifying its role as a cornerstone of the distribution.


title: SYNOPSIS
content:
<b>nixpkgs-review</b> &lt;<i>command</i>&gt; [<i>options</i>] [<i>arguments</i>]<br><br>Common commands include:<br><b>nixpkgs-review pr</b> &lt;<i>PR_NUMBER_OR_URL</i>&gt; [<i>options</i>]<br><b>nixpkgs-review head</b> [<i>options</i>]<br><b>nixpkgs-review wip</b> [<i>options</i>]<br><b>nixpkgs-review build-products</b> [<i>options</i>] &lt;<i>paths...</i>&gt;


title: PARAMETERS
content:
<b>pr <PR_NUMBER_OR_URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reviews a specific GitHub pull request by its number or URL.<br><br><b>head</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reviews changes between the current HEAD and the upstream <i>nixpkgs</i> branch.<br><br><b>wip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reviews changes in the current working tree, useful for local development.<br><br><b>build-products</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows building specific derivations or paths within the review context.<br><br><b>-j, --cores <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum number of CPU cores to use for parallel builds.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows which derivations would be built without actually performing the builds.<br><br><b>--build-args <ARGS></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes additional arguments directly to the underlying <i>nix-build</i> command.<br><br><b>--package <PACKAGE_NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the review to a specific package, improving efficiency for targeted changes (used with 'pr' command).<br><br><b>--attr <ATTR_PATH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the review to a specific attribute path, e.g., 'pkgs.hello' (used with 'pr' command).<br><br><b>--keep-going</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues building other derivations even if some derivations fail, useful for diagnosing multiple issues.<br><br><b>--test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs tests defined for the derivations in the review.<br><br><b>--system <SYSTEM></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target system for builds, e.g., 'x86_64-linux' or 'aarch64-darwin'.<br><br><b>--offload <TARGET></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Offloads builds to a remote Nix builder, potentially speeding up reviews or using specific hardware.<br><br>


title: DESCRIPTION
content:
<i>nixpkgs-review</i> is a crucial tool for contributors to the Nixpkgs repository. It automates the process of testing changes introduced by a GitHub pull request locally on a user's machine. By fetching the PR's commits, merging them with the upstream <i>nixpkgs</i> branch, and then attempting to build or test the affected derivations, it helps identify regressions, build failures, or other issues before changes are merged.<br><br>This allows reviewers to quickly verify the correctness of proposed updates without manually setting up complex build environments. It can operate on an entire PR, specific packages, or even just local changes, providing flexibility for different review scenarios. It primarily uses <i>nix-build</i> and <i>nix-instantiate</i> internally.


title: CAVEATS
content:
<i>nixpkgs-review</i> can be resource-intensive, requiring significant disk space and CPU time, especially for large pull requests or when rebuilding many dependencies. Its performance is highly dependent on the user's system specifications and the extent of changes being reviewed. It assumes a local clone of the <i>nixpkgs</i> repository is available and updated. While effective for build and basic test verification, it doesn't replace manual testing for complex runtime behaviors not covered by automated tests.


title: TYPICAL WORKFLOW
content:
Users typically start by navigating to their local <i>nixpkgs</i> clone, then run <b>nixpkgs-review pr</b> &lt;<i>PR_NUMBER</i>&gt;. The tool fetches the PR, merges it with the current branch, and attempts to build or test the affected derivations. Reviewers then check the output for build failures or test regressions before providing feedback on the GitHub pull request.


title: CACHE UTILIZATION
content:
One of <i>nixpkgs-review</i>'s strengths is its ability to leverage Nix's content-addressable caching. If derivations or their dependencies have been built before (either locally or via a binary cache), they won't be rebuilt, significantly speeding up subsequent reviews and reducing resource consumption.


title: HISTORY
content:
<i>nixpkgs-review</i> originated as a community-driven effort within the Nix ecosystem to standardize and streamline the process of reviewing pull requests for the massive <i>nixpkgs</i> repository. Initially, various ad-hoc scripts were used for local testing. As the size and complexity of <i>nixpkgs</i> grew, a more robust and unified tool became essential to enable efficient collaboration and maintain the repository's quality. Its development reflects the Nix community's commitment to robust CI/CD practices, allowing for a high volume of contributions while ensuring stability.


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts output to Shift_JIS encoding.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts output to EUC-JP encoding.<br><br><b><b>-j</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts output to JIS encoding.<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts output to UTF-8 encoding.<br><br><b><b>-Lu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts line endings to Unix (LF) format.<br><br><b><b>-Lw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts line endings to Windows (CRLF) format.<br><br><b><b>-Lm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts line endings to Mac (CR) format.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes MIME Base64 encoding.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes MIME Quoted-Printable encoding.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the guessed input encoding to standard error without performing conversion.<br><br><b><b>-o</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes output to the specified <i>&lt;file&gt;</i> instead of standard output.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<i>nkf</i> (Network Kanji Filter) is a powerful and versatile command-line utility primarily designed for character encoding conversion, especially for various Japanese character sets (JIS, EUC-JP, Shift_JIS, UTF-8, etc.). Beyond character encoding, it also excels at converting line-ending conventions (Unix LF, Windows CRLF, Mac CR) and decoding MIME-encoded text (Base64 and Quoted-Printable). It automatically detects the input encoding in many cases, making it a valuable tool for processing text files from different sources or for preparing text for different operating systems or applications. Its flexibility makes it indispensable for developers, system administrators, and anyone working with multilingual or cross-platform text data.


title: CAVEATS
content:
While <i>nkf</i> supports UTF-8, its core strength and primary development focus have been on handling legacy Japanese character sets. Its automatic encoding detection might not be flawless, especially with very short or ambiguous input data. Certain options (e.g., <b>-S</b>, <b>-E</b>, <b>-J</b>, <b>-W</b>) convert backslashes to yen signs, which can be an unexpected side effect outside of Japanese contexts.


title: INPUT/OUTPUT HANDLING
content:
By default, <i>nkf</i> reads from standard input if no file arguments are provided. The converted output is sent to standard output unless the <b>-o</b> option is used to specify an output file. When multiple input files are specified, their converted contents are concatenated and directed to the chosen output destination.


title: HISTORY
content:
<i>nkf</i> was developed in Japan in the late 1980s and early 1990s to address the complexities of character encoding and line-ending differences across diverse computing environments, particularly within the Japanese internet and UNIX communities. Its primary purpose was to facilitate the seamless exchange of text data encoded in different Japanese character sets (JIS, Shift_JIS, EUC-JP) and to reconcile the varying line-ending conventions between Unix, MS-DOS, and Macintosh systems. It quickly became a de-facto standard tool for these conversions in Japan and has since adapted to support newer encodings like UTF-8, remaining widely used today.


title: PARAMETERS
content:
<b><b>-b</b> <i>STYLE</i>, <b>--body-numbering=</b><i>STYLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the numbering style for body lines. Common styles include <i>'a'</i> (number all lines), <i>'t'</i> (number non-empty lines), <i>'n'</i> (no numbering), or <i>'pREGEXP'</i> (number lines matching the basic regular expression).<br><br><b><b>-h</b> <i>STYLE</i>, <b>--header-numbering=</b><i>STYLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the numbering style for header lines.<br><br><b><b>-f</b> <i>STYLE</i>, <b>--footer-numbering=</b><i>STYLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the numbering style for footer lines.<br><br><b><b>-l</b> <i>NUMBER</i>, <b>--line-increment=</b><i>NUMBER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the increment between line numbers. Defaults to 1.<br><br><b><b>-v</b> <i>NUMBER</i>, <b>--starting-line-number=</b><i>NUMBER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the starting line number for the first line of a logical page. Defaults to 1.<br><br><b><b>-w</b> <i>NUMBER</i>, <b>--width=</b><i>NUMBER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of characters to use for the line number. Defaults to 6.<br><br><b><b>-n</b> <i>FORMAT</i>, <b>--number-format=</b><i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the format of the line number. Options include <i>'ln'</i> (left justified, no leading zeros), <i>'rn'</i> (right justified, no leading zeros), and <i>'rz'</i> (right justified, leading zeros). Defaults to <i>'rn'</i>.<br><br><b><b>-s</b> <i>STRING</i>, <b>--separator=</b><i>STRING</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the string used to separate the line number from the text. Defaults to a tab character.<br><br><b><b>-p</b>, <b>--no-renumber-at-start-of-logical-page</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not renumber lines at the start of each logical page. This can make numbering continuous across logical pages.<br><br><b><b>-d</b> <i>CC</i>, <b>--delimiter=</b><i>CC</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the two-character delimiter for logical page sections. The default delimiters are <i>'\:'</i> (for header, body, footer). For example, <i>'-d' 'ab'</i> would recognize 'ab' as a delimiter.<br><br>


title: DESCRIPTION
content:
<b>nl</b> is a powerful utility for numbering lines of files or standard input, writing the result to standard output. Unlike simpler numbering tools like <i>cat -n</i>, <b>nl</b> offers extensive control over the numbering process. It can number all lines, non-empty lines, or only lines matching a specific regular expression. A key feature is its ability to recognize and number lines within logical page sections – header, body, and footer – allowing for independent numbering styles for each section. This makes <b>nl</b> particularly useful for formatting source code, documents, or log files where precise line numbering with specific formatting or sectioning is required. It provides options to customize the starting number, increment, number width, format (left-justified, right-justified, zero-padded), and the separator between the line number and the line text, offering a high degree of flexibility for various text processing tasks.


title: CAVEATS
content:
<b>nl</b>'s primary strength lies in its ability to handle logical page numbering, which can be more complex to configure than simple line numbering tools. If only basic, continuous line numbering is needed, a simpler command like <i>cat -n</i> might be sufficient and easier to use. Understanding the concept of logical pages and their delimiters is crucial for leveraging <b>nl</b>'s advanced features effectively.


title: LOGICAL PAGE STRUCTURE
content:
<b>nl</b> processes text in logical pages, which are typically composed of three sections: header, body, and footer. These sections are identified by specific delimiters. By default, <i>'\:\:'</i> (two backslashes followed by two colons) marks the start of a header, <i>'\:'</i> (one backslash followed by one colon) marks the start of a footer, and <i>'\:\:\:'</i> (two backslashes followed by three colons) marks the end of a header and start of a body, or end of a body and start of a footer, depending on context. This structure allows independent numbering styles and starting numbers for different parts of a document.


title: NUMBERING STYLES (<I>STYLE</I>)
content:
The <i>STYLE</i> argument for options like <b>-b</b>, <b>-h</b>, and <b>-f</b> determines how lines are numbered within a section:<br><ul><li><i>'a'</i>: Number all lines.</li><li><i>'t'</i>: Number non-empty lines (default for body).</li><li><i>'n'</i>: Do not number lines (default for header/footer).</li><li><i>'pREGEXP'</i>: Number only lines that match the basic regular expression <i>REGEXP</i>.</li></ul>


title: NUMBERING FORMATS (<I>FORMAT</I>)
content:
The <i>FORMAT</i> argument for <b>-n</b> controls the line number's appearance:<br><ul><li><i>'ln'</i>: Left-justified, no leading zeros.</li><li><i>'rn'</i>: Right-justified, no leading zeros (default).</li><li><i>'rz'</i>: Right-justified, with leading zeros.</li></ul>


title: HISTORY
content:
The <b>nl</b> command is a standard utility found in Unix-like operating systems. Its roots trace back to AT&T Unix System V, providing advanced line numbering capabilities beyond what simpler tools offered. It has been a consistent part of the GNU Core Utilities, ensuring its widespread availability and ongoing maintenance in Linux distributions. Its design reflects the need for sophisticated text formatting, particularly in environments dealing with source code or structured documents.


title: SEE ALSO
content:
<i>cat(1)</i> - Concatenate files and print on the standard output (specifically <i>cat -n</i> for line numbering)., <i>grep(1)</i> - Print lines matching a pattern., <i>sed(1)</i> - Stream editor for filtering and transforming text., <i>awk(1)</i> - Pattern scanning and processing language.


title: DESCRIPTION
content:
<i>nlmconv</i> is a utility from the <b>nfs-utils</b> package. Its primary function is to convert binary Network Lock Manager (NLM) monitor files into a human-readable text format. These monitor files, typically found in directories like <i>/var/lib/nfs/statd/sm</i>, store information about remote hosts that the <b>rpc.statd</b> (status monitor) daemon is monitoring for NLM-related purposes.<br>By converting these files, system administrators can inspect the current state of NLM-monitored clients and servers, which is crucial for diagnosing network file locking issues in NFS environments. The command reads the specified binary file and prints its converted textual content to standard output. <i>nlmconv</i> serves as an essential tool for debugging and maintaining NFS client/server stability when dealing with advisory file locking.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br>Requires the <b>nfs-utils</b> package to be installed.<br>The command expects a specific binary format; using it on arbitrary files will likely result in unreadable output or errors.<br>Its utility is specific to environments utilizing NFS with NLM for file locking.<br>Output is always to standard output; there is no option for an output file.


title: FILE LOCATION
content:
NLM monitor files are typically located under <i>/var/lib/nfs/statd/sm/</i> on Linux systems. Each file within this directory usually corresponds to a monitored host.


title: HISTORY
content:
The Network Lock Manager (NLM) protocol is an integral part of the Network File System (NFS), designed to provide advisory file locking capabilities across a network. <i>nlmconv</i> was developed as part of the <b>nfs-utils</b> suite, which provides essential tools for managing NFS services.<br>Its existence reflects the need for system administrators to have visibility into the state of NLM's monitoring service (<b>rpc.statd</b>), particularly for debugging and ensuring proper file locking behavior in complex distributed environments. Its purpose remains consistent since its introduction: to translate internal, machine-readable NLM state files into an understandable format.


title: PARAMETERS
content:
<b><b>-a</b> <i>&lt;rate_in_kB/s&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum scale value for the traffic graph, affecting both incoming and outgoing traffic.<br><br><b><b>-i</b> <i>&lt;rate_in_kB/s&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum scale value for the incoming traffic graph only.<br><br><b><b>-o</b> <i>&lt;rate_in_kB/s&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum scale value for the outgoing traffic graph only.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays multiple specified devices on the same graph, if applicable, providing a combined view.<br><br><b><b>-t</b> <i>&lt;milliseconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the refresh interval in milliseconds. The default is 500ms (half a second).<br><br><b><b>-u</b> <i>&lt;h|k|m|g&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the unit for displaying current traffic rates (h=bytes, k=KB, m=MB, g=GB). Default is KB.<br><br><b><b>-U</b> <i>&lt;h|k|m|g&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the unit for displaying total transferred data (h=bytes, k=KB, m=MB, g=GB). Default is KB.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays bandwidth in bits/second instead of bytes/second for current rates and totals.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help screen with available options and their descriptions.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information about the <i>nload</i> utility.<br><br><b><b>DEVICES</b>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more network interfaces to monitor (e.g., <i>eth0 wlan0</i>). If omitted, <i>nload</i> attempts to monitor all active interfaces.<br><br>


title: DESCRIPTION
content:
<i>nload</i> is a lightweight command-line tool designed for real-time monitoring of network traffic and disk I/O.<br><br>It presents a clear, graphical representation of incoming and outgoing bandwidth for specified network devices, along with disk read/write activity. Users can quickly see current transfer rates and total data transferred, making it useful for diagnosing network bottlenecks or observing disk activity. Its simple interface makes it accessible for quick checks without requiring complex configuration, providing an instant visual overview of network and disk activity directly in your terminal.


title: CAVEATS
content:
<i>nload</i> typically requires root privileges or appropriate capabilities (e.g., <i>CAP_NET_ADMIN</i>) to access network interface statistics on Linux systems.<br><br>While useful for a quick overview, it does not provide per-process network usage or detailed connection information like some other network monitoring tools. Its graphical display is character-based, offering a good visual approximation but not the precision of GUI-based tools.


title: DISK I/O MONITORING
content:
Beyond network traffic, <i>nload</i> also provides basic disk read/write statistics, making it a versatile tool for gaining a quick overall understanding of system resource utilization in one consolidated view.


title: REAL-TIME VISUALIZATION
content:
The core strength of <i>nload</i> lies in its ability to present real-time, character-based graphs of network traffic. This immediate visual feedback is invaluable for quickly identifying network bottlenecks, traffic spikes, or sustained usage without requiring complex analysis.


title: HISTORY
content:
<i>nload</i> was developed by Roland Riedel, aiming to provide a simple, curses-based interface for real-time network and disk I/O monitoring. Its development focused on ease of use and immediate visual feedback, making it a popular choice for quick diagnostics and system overview in terminal environments.


title: PARAMETERS
content:
<b><b><I>-a</I></b>, <b><I>--debug-syms</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all symbols, including debugger-only symbols, not just external or static symbols.<br><br><b><b><I>-C</I></b>, <b><I>--demangle</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Demangle (decode) low-level symbol names into user-readable names. Useful for C++ or other languages with name mangling.<br><br><b><b><I>-D</I></b>, <b><I>--dynamic</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display dynamic symbols only, which are used by dynamic linking at runtime. These are usually in the dynamic symbol table.<br><br><b><b><I>-g</I></b>, <b><I>--extern-only</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only global (external) symbols, excluding local symbols.<br><br><b><b><I>-l</I></b>, <b><I>--line-numbers</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For each symbol, display the filename and line number where it was defined, if available in the debugging information.<br><br><b><b><I>-n</I></b>, <b><I>--numeric-sort</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort symbols by their address (value) numerically instead of alphabetically by name.<br><br><b><b><I>-P</I></b>, <b><I>--portability</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the standard output format, which is more easily parseable by scripts and consistent across different systems.<br><br><b><b><I>-S</I></b>, <b><I>--print-size</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For defined symbols, print the symbol's size as well as its value.<br><br><b><b><I>-s</I></b>, <b><I>--print-armap</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When listing symbols from an archive library, print the archive's symbol map.<br><br><b><b><I>-t</I></b> <I>radix</I>, <b><I>--radix</I></b>=<I>radix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the radix (base) for printing symbol values (e.g., 'd' for decimal, 'o' for octal, 'x' for hexadecimal).<br><br><b><b><I>-u</I></b>, <b><I>--undefined-only</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only undefined symbols, which are referenced by the object file but not defined within it (typically resolved during linking).<br><br><b><b><I>--defined-only</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only symbols that are defined within the object file, excluding undefined ones.<br><br><b><b><I>--target</I></b>=<I>BFDNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the object code format if <b><I>nm</I></b> cannot determine it automatically (e.g., elf32-i386).<br><br>


title: DESCRIPTION
content:
The <b><I>nm</I></b> command inspects compiled object files, shared libraries, and static libraries to list the symbols they define or reference. Symbols are essentially names of functions, global variables, and static variables within a program. <b><I>nm</I></b> displays the symbol's name, its value (address), and its type, which indicates whether it's a code section (text), data section, uninitialized data (BSS), or undefined (referenced but not defined in the current file).<br><br>This utility is invaluable for debugging, reverse engineering, and analyzing software binaries. Developers use it to verify which functions and variables are exported or imported by a library, check for symbol name collisions, or understand the memory layout of an executable. By providing insight into the internal structure of compiled code, <b><I>nm</I></b> helps in understanding the linking process and identifying missing or misplaced symbols during software development.


title: CAVEATS
content:
The exact output format and available options for <b><I>nm</I></b> can vary slightly between different Unix-like systems, especially between GNU <b><I>nm</I></b> (part of GNU Binutils) and BSD <b><I>nm</I></b>. The information displayed by <b><I>nm</I></b> is directly dependent on the symbol table present in the object file, which can be influenced by compiler and linker flags (e.g., debug symbols may be stripped to reduce file size).


title: UNDERSTANDING SYMBOL TYPES
content:
The second field in <b><I>nm</I></b>'s output is the symbol type, represented by a single character. Uppercase characters indicate global symbols, while lowercase characters indicate local symbols. Common types include:<br><b><I>A</I></b>: Absolute symbol. Its value is fixed and will not change.<br><b><I>B</I></b> or <b><I>b</I></b>: Uninitialized data (BSS) section symbol.<br><b><I>C</I></b>: Common symbol. An uninitialized data symbol that may be merged with other common symbols.<br><b><I>D</I></b> or <b><I>d</I></b>: Initialized data section symbol.<br><b><I>N</I></b>: Debugging symbol.<br><b><I>R</I></b> or <b><I>r</I></b>: Read-only data section symbol.<br><b><I>T</I></b> or <b><I>t</I></b>: Text (code) section symbol.<br><b><I>U</I></b>: Undefined symbol. Referenced but not defined in this object file, requiring resolution during linking.<br><b><I>V</I></b> or <b><I>v</I></b>: Weak object symbol. Can be overridden by a global symbol definition.<br><b><I>W</I></b> or <b><I>w</I></b>: Weak function symbol. Can be overridden by a global symbol definition.<br><b><I>?</I></b>: Unknown symbol type, often due to an error.


title: HISTORY
content:
<b><I>nm</I></b> is a long-standing utility in the Unix toolchain, typically part of the GNU Binutils project on Linux systems. Its design and functionality date back to early Unix implementations, providing fundamental capabilities for low-level program analysis. Over time, it has evolved to support new object file formats (like ELF) and architectures, while maintaining its core purpose of listing symbols.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <i>brief help message</i> and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <i>version information</i> of the applet and exits.<br><br><b><b>--no-indicator</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the applet but <i>does not display an icon</i> in the system tray. This can be useful for debugging or specific integrations where the visual indicator is not desired.<br><br><b><b>--indicator</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the applet to <i>display its icon</i> in the system tray. This is often the default behavior but can be used for explicit clarity.<br><br><b><b>--gapplication-service</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An internal option used when <b>nm-applet</b> is started as a <i>DBus service</i>. Not typically used directly by end-users.<br><br>


title: DESCRIPTION
content:
The <b>nm-applet</b> is a graphical user interface (GUI) component of the <i>NetworkManager</i> suite, typically residing in the system tray or notification area of a desktop environment.<br><br>Its primary purpose is to provide users with a convenient and intuitive way to manage network connections directly from their desktop. This includes connecting to Wi-Fi networks, configuring wired connections, setting up VPNs, and managing mobile broadband connections.<br><br>The applet displays the current network status, allowing users to quickly see if they are connected, what network they are on, and if there are available networks. It offers quick access to network settings, enabling users to enable/disable networking, select different Wi-Fi networks, input passwords, and edit connection properties. It's an essential tool for providing a seamless network experience on Linux desktops, abstracting away the complexities of command-line network configuration.


title: CAVEATS
content:
The <b>nm-applet</b> requires the <i>NetworkManager</i> daemon to be running in the background to function. It also relies on a graphical desktop environment with a system tray or notification area for its visual components.<br><br>Issues may arise if the desktop environment's notification area is not properly configured or if there are conflicts with other network management tools. Its functionality is entirely dependent on the underlying <i>NetworkManager</i> service; if <i>NetworkManager</i> is not working correctly, the applet will also fail to provide network management capabilities.


title: AUTOMATIC STARTUP
content:
<b>nm-applet</b> is typically launched automatically by desktop environments (e.g., <i>GNOME</i>, <i>KDE</i>, <i>XFCE</i>) during user login. This ensures that the user always has a convenient way to manage their network connections without needing to manually start the applet.


title: DEPENDENCIES
content:
Beyond the <i>NetworkManager</i> daemon, <b>nm-applet</b> depends on several desktop environment libraries and a system tray implementation to render its icon and menus correctly. It also often relies on <i>polkit</i> for privilege escalation when performing actions that require root permissions, such as adding new system-wide connections.


title: HISTORY
content:
<b>nm-applet</b> is an integral part of the <i>NetworkManager</i> project, which was originally initiated by <i>Red Hat</i> to simplify network configuration on Linux, particularly for laptops and mobile devices that frequently switch networks. It was designed to replace cumbersome manual configuration with an intuitive graphical interface.<br><br>Over the years, it has evolved alongside the <i>NetworkManager</i> daemon itself, adapting to new network technologies and desktop environment standards (like <i>GNOME</i>, <i>KDE</i>, etc.). Its continuous development ensures it remains a user-friendly and robust tool for network management on Linux systems.


title: PARAMETERS
content:
<b>-a, --debug-syms</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all symbols, including debugger-only symbols.<br><br><b>-C, --demangle</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Demangle low-level symbol names into user-level names.<br><br><b>-D, --dynamic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display dynamic symbols only.<br><br><b>-g, --extern-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only external (global) symbols.<br><br><b>-n, --numeric-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort symbols numerically by address.<br><br><b>-P, --portability</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the POSIX.2 output format, similar to SVR4 nm.<br><br><b>-r, --reverse-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse the order of the sort (ascending to descending or vice-versa).<br><br><b>-S, --print-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print symbol size in addition to other information.<br><br><b>-u, --undefined-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only undefined symbols (symbols referenced but not defined in the object file).<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version number of <i>nm</i>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print a summary of the options and exit.<br><br><b>--no-sort</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not sort the symbols; display them in the order encountered in the object file.<br><br>


title: DESCRIPTION
content:
<b>nm-classic</b> is a utility program that lists symbols from object files, executable files, and object-file archives (libraries). It is part of the GNU Binutils package and is used to inspect the symbol table of compiled binaries.<br><br>Symbols represent functions, global variables, and other named entities defined or referenced within the code. Understanding the symbol table is crucial for debugging, linking, and analyzing compiled programs, allowing developers to see what functions are exported, imported, or internally used by a module. The "classic" suffix often distinguishes it from alternative <i>nm</i> implementations, such as <i>llvm-nm</i>, ensuring the use of the traditional GNU version.


title: CAVEATS
content:
<b>nm-classic</b> is a specific alias or symlink to the GNU Binutils <i>nm</i> command. Users should be aware that other <i>nm</i> implementations (e.g., from LLVM/Clang) might exist on their system and have slightly different features or output formats. Using <b>nm-classic</b> guarantees the behavior of the traditional GNU toolchain's symbol lister, which relies on the BFD (Binary File Descriptor) library for object file parsing.


title: SYMBOL TYPES
content:
Symbols listed by <i>nm</i> are typically followed by a character indicating their type (e.g., 'T' for text section, 'D' for data section, 'B' for BSS section, 'U' for undefined, 'W' for weak, 'A' for absolute). Lowercase indicates a local symbol, while uppercase indicates a global (external) symbol.


title: OUTPUT FORMAT
content:
The default output format for <i>nm</i> typically includes the symbol's address (if defined), the symbol type character, and the symbol name. Options like <i>-P</i> or <i>--portability</i> can change this format for easier parsing by scripts or other tools, ensuring a consistent output across different systems.


title: HISTORY
content:
The <i>nm</i> utility is a standard tool in Unix-like operating systems, tracing its roots back to early AT&T Unix versions. <b>nm-classic</b> specifically refers to the version provided by the GNU Binutils project, a collection of programming tools for creating and managing binary programs. GNU Binutils, including <i>nm</i>, has been under active development since the 1980s and is a cornerstone of the GNU toolchain, widely used in Linux and other Unix-like systems. The <b>nm-classic</b> alias or executable typically arises in environments where alternative <i>nm</i> implementations (like <i>llvm-nm</i> from the LLVM project) might be present, allowing users to explicitly choose the GNU Binutils version.


title: SYNOPSIS
content:
<b>nm-online</b> [<i>OPTIONS</i>]<br>The most common usage involves specifying a timeout and optionally checking for full connectivity:<br><b>nm-online</b> [<b>-t</b> <i>SECONDS</i>] [<b>-q</b>] [<b>-s</b>]


title: PARAMETERS
content:
<b><b>-t</b>, <b>--timeout=</b><i>SECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum number of seconds to wait for network connectivity. If the network is not online within this period, the command exits with a non-zero status. A value of <i>0</i> means to wait indefinitely.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all standard output messages, only returning an exit status.<br><br><b><b>-s</b>, <b>--check-connectivity</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <b>nm-online</b> to wait until <i>NetworkManager</i> reports full Internet connectivity, as opposed to just an active connection. This involves <i>NetworkManager</i>'s configured connectivity check mechanism (e.g., reaching a public URL).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br>


title: DESCRIPTION
content:
<b>nm-online</b> is a command-line utility provided by <i>NetworkManager</i> that waits for an active network connection. It blocks execution until <i>NetworkManager</i> reports a successful network connection, or until a specified timeout period expires. This command is particularly useful in startup scripts, systemd service units, or any automated process where network availability is a prerequisite for subsequent operations.<br><br>It checks for different levels of connectivity: by default, it waits for a basic active connection; with the <i>--check-connectivity</i> option, it waits for full Internet connectivity as determined by <i>NetworkManager</i>'s configured connectivity checks. Upon success, it exits with a zero status, indicating that the network is ready.


title: CAVEATS
content:
<b>nm-online</b> relies entirely on <i>NetworkManager</i>'s state and configuration. If <i>NetworkManager</i> is not running, or is misconfigured, <b>nm-online</b> will not function as expected. The <i>--check-connectivity</i> option's effectiveness depends on <i>NetworkManager</i> having a properly configured connectivity check URI; if not configured, it might not accurately reflect Internet reachability.<br><br>It does not guarantee application-level connectivity (e.g., DNS resolution might still fail, or a specific remote service might be down, even if the network is "online").


title: EXIT STATUS
content:
<b>nm-online</b> returns the following exit codes:<br><i>0</i>: The network connection is active and online (or connectivity check succeeded if <i>--check-connectivity</i> was used).<br><i>1</i>: A timeout occurred before the network became online.<br><i>2</i>: An error occurred (e.g., <i>NetworkManager</i> not running or D-Bus communication failed).


title: DEFAULT BEHAVIOR
content:
By default, if <b>nm-online</b> detects that a connection is already active when it is started, it exits immediately with a success status (<i>0</i>). It does not wait unless an active connection is not found initially.


title: HISTORY
content:
<b>nm-online</b> has been an integral part of the <i>NetworkManager</i> project since its early days, evolving with <i>NetworkManager</i> itself. Its primary purpose has always been to provide a reliable method for scripts and services to synchronize with the network's readiness state. As <i>NetworkManager</i> gained more sophisticated connectivity checking capabilities, <b>nm-online</b> also incorporated options like <i>--check-connectivity</i> to reflect these advancements, ensuring that services could wait for a higher assurance of network availability.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of nm-tool and exits.<br><br><b>-i, --show-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays details for all network devices, including inactive ones.<br><br><b>-c, --show-active</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only active network connections and their associated devices.<br><br><b>-a, --show-detail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides detailed information for active connections and devices.<br><br><b>-p, --pretty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Deprecated) This option is no longer used and has no effect.<br><br><b>-t, --timeout=SECONDS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout in seconds for NetworkManager to respond. If NetworkManager doesn't respond within this time, nm-tool will exit.<br><br><b>-w, --wait-ip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Deprecated) Waits for an IP address to be assigned to the active connection before exiting. No longer used.<br><br>


title: DESCRIPTION
content:
<i>nm-tool</i> was a command-line utility for interacting with the <i>NetworkManager</i> daemon on Linux systems. It provided a simple way to display network device status, active connections, and basic network configuration details directly from the terminal. Its primary use cases included quickly checking the current network connectivity, listing available Wi-Fi networks, and reviewing IP address assignments. <br><br>While once a common tool for system administrators and users, <i>nm-tool</i> has largely been superseded and deprecated in favor of the more powerful and feature-rich <i>nmcli</i> (NetworkManager Command Line Interface) utility. Most modern Linux distributions recommend or only include <i>nmcli</i> for NetworkManager interaction, making <i>nm-tool</i> less relevant for current network management tasks.


title: CAVEATS
content:
The <i>nm-tool</i> utility is considered largely deprecated. It has been replaced by the more comprehensive and actively maintained <i>nmcli</i> utility, which offers a broader range of commands for managing connections, devices, and NetworkManager settings. Users are strongly encouraged to use <i>nmcli</i> for all NetworkManager-related tasks on modern Linux systems, as <i>nm-tool</i> may not be available by default or may provide limited functionality.


title: TYPICAL USAGE (PRIOR TO DEPRECATION)
content:
Before its deprecation, a common use of <i>nm-tool</i> was to quickly view the overall network status. Running <i>nm-tool</i> without any options would display a summary of current network activity, including whether networking was enabled, the primary connection, and details about active devices (e.g., Ethernet, Wi-Fi). For instance, it could show the IP address, gateway, and DNS servers for the active connection, and list detected Wi-Fi networks along with their signal strength.<br><br>Example of old output:<br><code><br>NetworkManager State: connected<br><br>- Device: eth0 -------------------------------------------------------------<br>  Type:              Wired<br>  Driver:            e1000e<br>  State:             connected<br>  Default:           yes<br>  <br>  IPv4 Settings:<br>    Address:         192.168.1.100<br>    Prefix:          24 (255.255.255.0)<br>    Gateway:         192.168.1.1<br>    <br>    DNS:             192.168.1.1<br></code>


title: HISTORY
content:
<i>nm-tool</i> was introduced as a command-line interface for <i>NetworkManager</i>, offering a simple way to display network status. It served as a basic diagnostic and information retrieval tool. However, as <i>NetworkManager</i> evolved, the need for a more robust and scriptable command-line utility became apparent. This led to the development of <i>nmcli</i>, which began to gain prominence around NetworkManager version 0.9. By NetworkManager 1.0 and subsequent releases, <i>nmcli</i> became the officially recommended and primary command-line interface, effectively deprecating <i>nm-tool</i>. While some older systems may still have it, it's generally omitted from newer installations or exists as a compatibility stub.


title: SYNOPSIS
content:
<b>nmbd</b> [<b>-D</b>] [<b>-F</b>] [<b>-S</b>] [<b>-H</b> <i>&lt;filename&gt;</i>] [<b>-s</b> <i>&lt;configuration file&gt;</i>] [<b>-d</b> <i>&lt;debug level&gt;</i>] [<b>-l</b> <i>&lt;log directory&gt;</i>] [<b>-V</b>]


title: PARAMETERS
content:
<b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b>nmbd</b> as a daemon in the background. This is the default behavior when run from system init scripts.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b>nmbd</b> in the foreground. This is useful for debugging or when running under a process supervisor.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Log output to standard output (stdout) instead of syslog. Typically used in conjunction with <b>-F</b>.<br><br><b><b>-H</b> <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the <i>lmhosts</i> file, which provides static NetBIOS name to IP address mappings.<br><br><b><b>-s</b> <i>&lt;configuration file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the Samba configuration file, typically <i>/etc/samba/smb.conf</i>.<br><br><b><b>-d</b> <i>&lt;debug level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the debug (log) level. Levels range from 0 (no logging) to 10 (maximum debugging information).<br><br><b><b>-l</b> <i>&lt;log directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where log files should be written. Overrides the <i>log file</i> parameter in <i>smb.conf</i>.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the <b>nmbd</b> version number and exit.<br><br>


title: DESCRIPTION
content:
<b>nmbd</b> is a fundamental daemon within the Samba suite, providing essential NetBIOS over IP (NetBT) name services. It is responsible for handling NetBIOS name registration, resolution, and release requests, which are crucial for Windows clients to locate resources by name on a network. <b>nmbd</b> can function as a Windows Internet Name Service (WINS) server, offering dynamic name resolution, or it can forward resolution requests to an existing WINS server configured in <i>smb.conf</i>.<br><br>Beyond name services, <b>nmbd</b> plays a significant role in network browsing. It participates in the election process for the Local Master Browser within a workgroup and maintains the browse list, allowing clients to discover available shares and printers. Its presence ensures that Samba shares are visible and accessible by name to Windows machines, making it indispensable for proper Samba functionality in a Windows-centric environment. It typically runs in the background as a system service.


title: CAVEATS
content:
<b>Firewall Rules</b>: <b>nmbd</b> requires UDP ports 137 (NetBIOS Name Service) and 138 (NetBIOS Datagram Service) to be open on any firewalls for its core functionality.<br><b>WINS Configuration</b>: For optimal network performance and to prevent conflicts, it is strongly recommended to have only one active WINS server per subnet. Carefully configure <b>nmbd</b>'s WINS role via <i>smb.conf</i>.<br><b>smb.conf Dependence</b>: While <b>nmbd</b> has command-line options, its primary behavior, including its role as a WINS server or master browser, is governed by parameters set within the <i>smb.conf</i> configuration file.


title: CONFIGURATION VIA SMB.CONF
content:
<b>nmbd</b>'s operational parameters, such as its <i>workgroup</i>, <i>netbios name</i>, whether it acts as a <i>wins support</i> server, or relies on an external <i>wins server</i>, are primarily configured within the <i>[global]</i> section of the <b>smb.conf</b> file. This centralizes Samba's network identity and behavior, making <b>smb.conf</b> the primary control point for <b>nmbd</b>.


title: NETWORK PORTS
content:
<b>nmbd</b> communicates using specific UDP ports: <b>UDP 137</b> for NetBIOS Name Service (NBNAMES) and <b>UDP 138</b> for NetBIOS Datagram Service (NBDATAGRAM). These ports are essential for name resolution and browsing functions. Ensure they are not blocked by firewalls on the Samba server or network path.


title: HISTORY
content:
<b>nmbd</b> has been a core component of the Samba suite since its inception, providing the critical NetBIOS name service and browsing capabilities that allowed Unix/Linux systems to seamlessly integrate into Windows networks. It evolved to support various versions of Windows networking protocols. While initially some behaviors could be controlled via command-line flags, much of its configuration migrated to the central <i>smb.conf</i> file over time, streamlining Samba management. Its ongoing development ensures compatibility with newer Windows versions and network environments, remaining indispensable for Samba's file and print sharing services.


title: SYNOPSIS
content:
<b><I>nmblookup</I></b> [<I>options</I>] <I>NetBIOS name</I><br><b><I>nmblookup</I></b> <I>-A | --address</I> <I>IP address</I> [<I>options</I>]


title: PARAMETERS
content:
<b><I>NetBIOS name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The NetBIOS name to look up. Can be a hostname, service name, or workgroup name.<br><br><b><b>-A</b>, <b>--address</b> <I>IP address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a reverse lookup, resolving an IP address to its corresponding NetBIOS name.<br><br><b><b>-S</b>, <b>--status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the NetBIOS status of a host, returning a list of all registered NetBIOS names for that machine.<br><br><b><b>-R</b>, <b>--recursion</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the recursion desired bit in the NetBIOS query. Used when querying WINS servers to request recursive resolution.<br><br><b><b>-U</b> <I>unicast address</I>, <b>--unicast</b> <I>unicast address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends queries to a specific unicast address (e.g., a WINS server IP address) instead of broadcasting on the local subnet.<br><br><b><b>-B</b> <I>broadcast address</I>, <b>--broadcast</b> <I>broadcast address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a specific broadcast address for name queries, overriding the default subnet broadcast address.<br><br><b><b>-M</b> <I>name</I>, <b>--master-browser</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Looks up the master browser for a specific workgroup or domain. The <I>name</I> is typically the workgroup/domain name.<br><br><b><b>-d</b> <I>debug level</I>, <b>--debuglevel</b> <I>debug level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug (logging) level. A higher number provides more verbose output.<br><br><b><b>-s</b> <I>smb config file</I>, <b>--configfile</b> <I>smb config file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative Samba configuration file to use instead of the default.<br><br>


title: DESCRIPTION
content:
<I>nmblookup</I> is a client that queries NetBIOS names from hosts using NetBIOS over TCP/IP (NBT). It can perform various types of lookups, including broadcast queries for local subnet names, unicast queries to specific WINS servers, and reverse lookups from IP addresses to NetBIOS names.<br><br>It's an essential tool for troubleshooting Samba and Windows networking environments where NetBIOS name resolution is in use. It helps identify registered NetBIOS names and their corresponding IP addresses, or find a domain's master browser.


title: CAVEATS
content:
<I>nmblookup</I> relies on NetBIOS over TCP/IP (NBT), which is less prevalent in modern, pure DNS-centric networks. Its functionality depends on proper NetBIOS name resolution services (like WINS or local broadcasts) being active and accessible.<br><br>Firewall rules often block NetBIOS ports (UDP 137, 138, TCP 139, 445), which can hinder its operation.


title: NETBIOS NAME TYPES
content:
NetBIOS names are 16-character names. The 16th character (known as the NetBIOS suffix or resource byte) denotes the type of service or resource registered by that name (e.g., `<00>` for Workstation Service, `<20>` for File Server Service, `<1B>` for Domain Master Browser). The <b>-S</b> (status) option often reveals these suffixes.


title: PORT USAGE
content:
<I>nmblookup</I> primarily uses UDP ports 137 (NetBIOS Name Service) and 138 (NetBIOS Datagram Service) for broadcast queries and unicast queries to WINS servers. Ensure these ports are not blocked by firewalls if encountering issues.


title: HISTORY
content:
<I>nmblookup</I> is a component of the Samba suite, an open-source project that re-implements the SMB/CIFS networking protocol. Samba's development began in the early 1990s to enable Linux/Unix systems to seamlessly interact with Microsoft Windows networks.<br><br>The command provides the NetBIOS name resolution client functionality, which was crucial for Windows network discovery and resource access in the era before DNS became the primary resolution method for all network services. While its direct usage has diminished in some modern environments, it remains a valuable tool for legacy systems and for troubleshooting NetBIOS-dependent network issues.


title: SYNOPSIS
content:
<b>nmcli</b> [<i>OPTIONS</i>] <i>OBJECT</i> { <i>COMMAND</i> | <b>help</b> }<br><br>Common Objects:<br>&nbsp;&nbsp;<b>general</b><br>&nbsp;&nbsp;<b>networking</b><br>&nbsp;&nbsp;<b>radio</b><br>&nbsp;&nbsp;<b>connection</b> (or <b>con</b>)<br>&nbsp;&nbsp;<b>device</b> (or <b>dev</b>)<br>&nbsp;&nbsp;<b>agent</b><br>&nbsp;&nbsp;<b>monitor</b><br><br>Example: <b>nmcli</b> <b>connection</b> <b>show</b><br>Example: <b>nmcli</b> <b>device</b> <b>wifi</b> <b>connect</b> <i>SSID</i> <b>password</b> <i>WPA_PASSPHRASE</i>


title: PARAMETERS
content:
<b>--terse, -t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in a terse (script-friendly) format with fields separated by colons.<br><br><b>--fields <field_list>, -f <field_list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which fields to output. Use 'all' for all fields, or a comma-separated list of field names. Only effective with --terse or --pretty.<br><br><b>--expanded, -e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in an expanded format, where each field is on its own line.<br><br><b>--colors <arg>, -c <arg></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Whether to use colors in the output. 'auto', 'always', or 'never'.<br><br><b>--pretty, -p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty print output. Attempts to use human-readable formatting and aligned columns.<br><br><b>--width <width>, -w <width></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set output width for tables. Useful with --pretty.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show nmcli version and exit.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show nmcli help and exit. Can be used with an object or command for specific help (e.g., 'nmcli connection help').<br><br><b>--ask, -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for missing parameters. If a parameter is missing (e.g., Wi-Fi password), nmcli will prompt the user for it.<br><br>


title: DESCRIPTION
content:
The <b>nmcli</b> command-line utility is a powerful client for <I>NetworkManager</I>, allowing users to control network settings directly from the terminal. It provides a comprehensive set of functionalities for managing network connections and devices. <br><br>With <b>nmcli</b>, you can perform various tasks such as displaying network status, activating and deactivating network connections, creating new connections (e.g., Wi-Fi, Ethernet, VPN), editing existing ones, and deleting them. It also allows for device management, including bringing interfaces up or down, scanning for Wi-Fi networks, and managing network radio states. <br><br><b>nmcli</b> is particularly useful for scripting, server environments, or for users who prefer a command-line interface over graphical tools. Its versatile options and subcommands make it an essential tool for network administration on Linux systems where NetworkManager is in use.


title: CAVEATS
content:
<i><b>nmcli</b> requires the <I>NetworkManager</I> service to be running to function correctly. Most operations, especially those that modify system network configurations, require root privileges or membership in specific user groups (e.g., 'nmcli-l' for limited users, or typically sudo/root for full control). The default output can be verbose; using options like <B>--terse</B> and <B>--fields</B> is highly recommended for scripting.</i>


title: CORE OBJECTS
content:
<b>nmcli</b> organizes its functionalities around several core <I>objects</I>. These objects represent different aspects of network management:<br><ul><li><b>general</b>: Overall NetworkManager status.</li><li><b>networking</b>: Global networking enablement/disablement.</li><li><b>radio</b>: Control Wi-Fi and WWAN radio states.</li><li><b>connection</b>: Manage network connections (profiles) including add, modify, delete, activate, deactivate.</li><li><b>device</b>: Manage network hardware devices, show status, connect to Wi-Fi.</li><li><b>agent</b>: Manage NetworkManager secret agents.</li><li><b>monitor</b>: Monitor NetworkManager events.</li></ul>Understanding these objects is crucial for effective use of <b>nmcli</b>.


title: SCRIPTING AND OUTPUT
content:
For scripting purposes, <b>nmcli</b>'s output can be tailored using the <B>--terse</B> (<B>-t</B>) and <B>--fields</B> (<B>-f</B>) options. This allows for precise parsing of command output, making it reliable for automation tasks. For instance, <B>nmcli -t -f IP4.ADDRESS dev show eth0</B> will output only the IPv4 address of eth0 in a clean, parsable format.


title: HISTORY
content:
<i><b>nmcli</b> was developed as part of the <I>NetworkManager</I> project to provide a robust and scriptable command-line interface for managing network connections. It emerged as a modern alternative to traditional tools like <I>ifconfig</I> and <I>route</I> for systems managed by <I>NetworkManager</I>, evolving over time to become a comprehensive utility capable of handling complex network configurations and device states. Its focus has always been to offer full control over <I>NetworkManager</I>'s capabilities from the terminal, complementing graphical and curses-based frontends.</i>


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>nmcli-agent</b> program.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief help message detailing the command's usage and available options.<br><br><b><b>--register</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Registers this instance of the agent with <b>NetworkManager</b>. This action is usually handled automatically when the agent is started by a client needing its services.<br><br>


title: DESCRIPTION
content:
The <b>nmcli-agent</b> is a crucial helper program within the <b>NetworkManager</b> framework. Its primary role is to serve as a <i>secret agent</i>, providing a graphical user interface when <b>NetworkManager</b> requires sensitive information from the user. For instance, when attempting to connect to a Wi-Fi network that demands a passphrase, or a VPN connection needing a password, <b>nmcli-agent</b> automatically launches.<br><br>It then presents a secure graphical dialog box—often leveraging underlying systems like <i>libsecret</i> or <i>gnome-keyring</i>—to prompt the user for the necessary credentials. This functionality is particularly vital for command-line <b>NetworkManager</b> clients like <b>nmcli</b>, which inherently lack the ability to display graphical prompts. By providing this interactive secret input mechanism, <b>nmcli-agent</b> ensures that network configuration remains user-friendly and secure, even when managed from the terminal. Users typically do not invoke it directly; it starts on demand when a secret is required by a client.


title: CAVEATS
content:
The <b>nmcli-agent</b> primarily provides a <i>graphical</i> secret prompt. This means it requires a graphical session and display server to function correctly. If running in a purely <b>headless</b> environment or without an active graphical session, it may not be able to display the prompt, and network connections requiring secrets might fail.<br><br>Users typically do not invoke <b>nmcli-agent</b> directly; it is an internal component launched by <b>NetworkManager</b> clients (like <b>nmcli</b>) when a secret is needed. Relying on other graphical components such as <i>gnome-keyring</i> or <i>libsecret</i> for backend secret storage is crucial for its operation.


title: PURPOSE AND ROLE
content:
The main purpose of <b>nmcli-agent</b> is to bridge the communication gap between <b>NetworkManager</b>'s requirement for interactive secret input and the non-graphical nature of command-line tools like <b>nmcli</b>. It ensures that users can securely provide necessary credentials through a graphical prompt, even when managing network connections from the terminal, making the process seamless and secure.


title: AUTOMATIC INVOCATION
content:
Unlike many command-line utilities, <b>nmcli-agent</b> is rarely invoked directly by the user. Instead, it is automatically launched by <b>NetworkManager</b> clients (such as <b>nmcli</b>) whenever a network connection attempt necessitates a secret (e.g., a Wi-Fi password or VPN credentials) that is not already known or stored. This on-demand behavior ensures that the agent is only active when required, contributing to an efficient and user-friendly network setup experience.


title: HISTORY
content:
<b>nmcli-agent</b> is an integral part of the <b>NetworkManager</b> project, which originated in 2004 with the goal of simplifying network configuration on Linux systems. As <b>nmcli</b> evolved into a robust command-line interface for <b>NetworkManager</b>, a clear need emerged for a mechanism to handle interactive secret requests—especially for sensitive data like Wi-Fi passphrases or VPN credentials that users might prefer not to pre-configure or store persistently. <b>nmcli-agent</b> was developed to address this gap, providing the necessary graphical prompts that a purely command-line tool like <b>nmcli</b> could not natively offer. Its integration ensures a consistent and secure method for users to supply network secrets across various <b>NetworkManager</b> clients, enhancing overall usability and security.


title: PARAMETERS
content:
<b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the state of all NetworkManager-controlled network devices. This provides a quick overview of network interfaces, their types, and current status (e.g., 'connected', 'disconnected', 'unavailable').<br><br><b><b>show</b> [<i>IFNAME</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific network device identified by its interface name (e.g., 'eth0', 'wlan0'). If <i>IFNAME</i> is omitted, it shows details for all devices. Information includes general device properties, IP configuration, hardware address, and the active connection profile.<br><br><b><b>disconnect</b> <i>IFNAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates and disconnects a specified network device. This prevents NetworkManager from using the device until it is explicitly reconnected or a connection is activated on it. It does not delete the device or its connection profiles.<br><br><b><b>connect</b> <i>IFNAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specified network device. If a suitable connection profile exists and is configured for automatic connection, NetworkManager will attempt to bring the device up and connect using that profile. This can be used to re-enable a previously disconnected device.<br><br><b><b>delete</b> <i>IFNAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a software-based network device, such as a bridge, bond, or VLAN interface, that was previously created by NetworkManager. This command does not apply to physical hardware devices.<br><br><b><b>set</b> <i>IFNAME</i> managed {yes|no}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether NetworkManager should manage a specific device. Setting it to 'no' will cause NetworkManager to ignore the device, leaving it unmanaged. Setting it to 'yes' brings it back under NetworkManager's control. This is useful for troubleshooting or integrating with other network management tools.<br><br><b><i>General nmcli options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>nmcli device</i> command also supports general <i>nmcli</i> options like <b>--terse</b> (-t) for machine-parsable output, <b>--fields</b> (-f) to specify output columns, and <b>--pretty</b> (-p) for enhanced readability.<br><br>


title: DESCRIPTION
content:
The <i>nmcli device</i> command is a powerful subcommand of the <i>nmcli</i> utility, designed for interacting with and managing network interfaces (devices) controlled by NetworkManager. It provides a command-line interface to view device status, show detailed information, disconnect or connect devices, and even delete software-based interfaces like bridges or bonds.<br><br>NetworkManager is a system network service that manages network connections. The <i>nmcli device</i> command allows administrators and users to get a quick overview of all active and inactive network interfaces, diagnose connectivity issues, and manually control device states. It's an essential tool for scripting network configurations and monitoring in Linux environments where NetworkManager is in use.


title: CAVEATS
content:
The <i>nmcli device</i> command requires the NetworkManager service to be running. Modifying device states (e.g., `disconnect`, `connect`, `delete`, `set`) often requires root privileges or membership in a privileged group. This command primarily manages devices recognized and controlled by NetworkManager; some low-level kernel-managed interfaces might not be directly configurable via <i>nmcli device</i>.


title: DEVICE STATES
content:
Understanding the 'STATE' column in <b>nmcli device status</b> output is crucial. Common states include 'connected' (device is active and connected), 'disconnected' (device is active but not linked to a network), 'unavailable' (device is present but not usable), and 'unmanaged' (NetworkManager is ignoring the device).


title: INTERACTION WITH CONNECTIONS
content:
While <b>nmcli device</b> manages the hardware interface, <b>nmcli connection</b> manages the network profiles. A device needs an active connection profile to become 'connected'. Disconnecting a device (<b>nmcli device disconnect</b>) deactivates the current connection on that device, but the connection profile remains available for future use.


title: HISTORY
content:
The <i>nmcli</i> command-line tool, including its <i>device</i> subcommand, was introduced as part of the NetworkManager project, which gained prominence in the mid-2000s as a daemon to simplify network configuration on Linux. <i>nmcli</i> emerged as the preferred command-line interface for NetworkManager, offering a more powerful and scriptable alternative to older tools and configuration files. The `device` subcommand has been a core component since `nmcli`'s early development, providing essential capabilities for managing network interfaces.


title: PARAMETERS
content:
<b><b>-t</b>, <b>--terse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in terse (script-friendly) format. This suppresses column headers and other human-readable decorations. Fields are separated by colons (':').<br><br><b><b>-f</b>, <b>--fields</b> <I>field1,field2,...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which fields to show in the output. Use a comma-separated list of field names. '<i>all</i>' displays all available fields, while '<i>common</i>' shows commonly used fields.<br><br><b><b>-e</b>, <b>--escape</b> <I>yes|no</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escape all values in terse mode output. Default is '<i>yes</i>', which ensures that values containing the field separator are correctly handled.<br><br><b><b>-m</b>, <b>--mode</b> <I>tabular|multiline</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output mode. '<i>tabular</i>' (default for most commands) displays data in columns. '<i>multiline</i>' prints each field on a new line, useful for detailed views.<br><br><b><b>-c</b>, <b>--colors</b> <I>auto|yes|no</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control color output. '<i>auto</i>' (default) uses colors if the output is a terminal, '<i>yes</i>' forces colors, and '<i>no</i>' disables them.<br><br><b><b>-n</b>, <b>--nocheck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check if NetworkManager is running. Commands might fail if NetworkManager is not active.<br><br><b><b>-w</b>, <b>--wait</b> <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for NetworkManager to become available. A value of '<i>0</i>' (default) means wait indefinitely.<br><br><b><b>-a</b>, <b>--ask</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt interactively for any missing parameters, such as passwords or passphrases.<br><br><b><b>-p</b>, <b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce pretty, human-readable output, including column headers and formatted values. (Often default for interactive use).<br><br><b><b>-s</b>, <b>--show-secrets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display sensitive information, such as Wi-Fi passwords, in the output. Use with extreme caution as this exposes credentials.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the <i>nmcli</i> version information.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print general help or command-specific help information.<br><br>


title: DESCRIPTION
content:
<i>nmcli</i> is a powerful command-line client for NetworkManager, enabling users to manage and monitor network connections and devices directly from the terminal. It provides a consistent and scriptable interface for controlling various aspects of network configuration, from setting up simple Ethernet connections to configuring complex VPNs, Wi-Fi networks, and bond interfaces.<br><br>Designed to be both user-friendly for interactive use and robust for scripting, <i>nmcli</i> can display network status, activate or deactivate connections, manage network devices, and control global NetworkManager settings. It has largely superseded older network configuration methods like 'ifup' and 'ifdown' for dynamic network environments, offering a modern and integrated approach to network management on Linux systems.


title: CAVEATS
content:
When using the <i>--terse</i> output format, careful parsing is required as the exact number and order of fields can vary. Relying on <i>nmcli</i>'s terse output for critical scripting tasks may necessitate robust error handling and parsing logic. The <i>--show-secrets</i> option should be used with extreme caution, as it will display sensitive network credentials directly in the terminal, potentially compromising security.


title: OBJECT TYPES
content:
<i>nmcli</i> commands are structured around specific <I>OBJECT</I> types, each representing a distinct aspect of NetworkManager's functionality. Understanding these objects is fundamental to using <i>nmcli</i> effectively:<br><br><b>connection</b>: Manages network profiles that define how to connect to a network (e.g., Wi-Fi SSIDs, VPN configurations, Ethernet settings).<br><b>device</b>: Controls network hardware interfaces (e.g., 'eth0', 'wlan0', 'tun0'), allowing operations like enabling/disabling, viewing status, and restarting.<br><b>radio</b>: Manages the global state of wireless technologies like Wi-Fi and WWAN (mobile broadband), enabling or disabling them system-wide.<br><b>general</b>: Provides general information about NetworkManager's status and global control settings.<br><b>networking</b>: Controls NetworkManager's overall networking state, allowing to enable or disable all managed networking.<br><b>agent</b>: Manages NetworkManager secrets agents, which handle user authentication and password storage.<br><b>monitor</b>: Allows monitoring NetworkManager events and changes in real-time.


title: COMMON ARGUMENTS
content:
Many <i>nmcli</i> commands accept common arguments to identify specific connections, devices, or to filter output. These include:<br><br><b>id</b>: Refers to the name of a connection profile.<br><b>uuid</b>: Refers to the Universally Unique Identifier of a connection profile, offering a stable and unique way to identify connections.<br><b>ifname</b>: Refers to the operating system's interface name for a network device (e.g., 'eth0', 'wlan0').<br><b>type</b>: Specifies the type of network connection (e.g., 'ethernet', 'wifi', 'vpn', 'bridge').<br><b>state</b>: Used to filter or query based on the current operational state of a device or connection (e.g., 'connected', 'disconnected', 'unavailable').


title: HISTORY
content:
<i>nmcli</i> is a core component of the NetworkManager project, which was initiated in 2004 to provide a modern, dynamic framework for managing network connections on Linux. It emerged to address the challenges of mobile and wireless networking, offering an alternative to traditional static network configuration files. Over the years, <i>nmcli</i> has matured alongside NetworkManager, becoming the primary command-line tool for interacting with the service across various Linux distributions, reflecting continuous development to meet evolving networking demands.


title: PARAMETERS
content:
<b><b>--escape</b>, <b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escape output to prevent issues with special characters, useful when parsing names or values.<br><br><b><b>--colors</b> <<i>auto|always|never</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control whether output uses colors for better readability. '<i>auto</i>' is default, '<i>always</i>' forces colors, '<i>never</i>' disables them.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help for the <b>nmcli</b> command and its subcommands, including global options.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show <b>nmcli</b> version information.<br><br>


title: DESCRIPTION
content:
<b>nmcli monitor</b> is a subcommand of the <b>nmcli</b> (NetworkManager command-line interface) utility, designed for real-time observation of NetworkManager's activities. It streams events related to network devices, connections, and overall NetworkManager state changes directly to the terminal. This command is invaluable for debugging network issues, understanding NetworkManager's behavior, and verifying network configuration changes as they happen.<br><br>It displays notifications for various events including device activation/deactivation, connection establishment/teardown, IP address assignments, DNS updates, and Wi-Fi scanning results. The output provides dynamic insights into how NetworkManager manages network interfaces, making it a powerful tool for system administrators and network engineers alike. The continuous stream of information helps identify transient issues or unexpected network transitions that might be difficult to catch with static status commands.


title: CAVEATS
content:
The <b>nmcli monitor</b> command requires the NetworkManager service to be running and active. Its output can be extremely verbose on busy networks, continuously streaming events to the console. Due to its dynamic, event-based nature, the output is generally not suitable for structured parsing with tools like <b>grep</b> or <b>awk</b> in a programmatic way, unlike other <b>nmcli</b> commands that produce tabular data. Furthermore, to access all event information, appropriate user permissions (e.g., membership in the <i>netdev</i> group or root privileges) may be necessary.


title: TYPICAL USAGE
content:
To use <b>nmcli monitor</b>, simply run it in a terminal. It will immediately start displaying events as NetworkManager detects them. To stop monitoring, press <b>Ctrl+C</b>. This command is often run in a dedicated terminal window while performing other network configurations or debugging, allowing for immediate feedback on system changes.


title: INTERPRETING OUTPUT
content:
The output of <b>nmcli monitor</b> consists of time-stamped lines detailing various events. Common events include: <br><i>Device</i> state changes (e.g., '<i>device (eth0): link connected</i>', '<i>device (wlan0): activation successful</i>'). <br><i>Connection</i> state changes (e.g., '<i>connection (my_wifi): activated</i>'). <br><i>NetworkManager</i> state changes (e.g., '<i>NetworkManager state is 'connected (global)'</i>'). <br>It provides a granular view of NetworkManager's decision-making and operational status, invaluable for understanding network dynamics.


title: HISTORY
content:
The <b>nmcli</b> utility, which includes the <b>monitor</b> subcommand, is part of the NetworkManager project, initiated by Red Hat in 2004. <b>nmcli</b> itself was introduced as the primary command-line interface for NetworkManager, offering a more user-friendly and scriptable alternative to direct D-Bus interactions. The <b>monitor</b> subcommand was subsequently added to provide real-time event streaming capabilities, enhancing <b>nmcli</b>'s diagnostic and debugging functionalities as NetworkManager evolved to handle complex network environments.


title: SYNOPSIS
content:
The core command is <b>nmcli</b>. Its general syntax for performing networking tasks is:<br><b>nmcli</b> [<i>OPTIONS</i>] <i>OBJECT</i> { <i>COMMAND</i> | <i>help</i> }<br><br>Common <i>OBJECTS</i> relevant to networking include:<br><b>connection</b> (or <b>c</b>): For managing network connection profiles (e.g., Wi-Fi network definitions, Ethernet configurations).<br><b>device</b> (or <b>d</b>): For managing network interfaces (e.g., <i>eth0</i>, <i>wlan0</i>).<br><b>radio</b> (or <b>r</b>): For managing global Wi-Fi and WWAN radio states.<br><b>general</b> (or <b>g</b>): For managing NetworkManager's overall status and hostname.<br><b>monitor</b> (or <b>m</b>): For monitoring NetworkManager events and changes.<br><br>Examples:<br><b>nmcli connection show</b><br><b>nmcli device status</b><br><b>nmcli radio wifi off</b>


title: PARAMETERS
content:
<b><b>-t</b>, <b>--terse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in terse format, suitable for scripting. It typically produces colon-separated key-value pairs.<br><br><b><b>-p</b>, <b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in a human-readable, 'pretty' format with aligned columns and headers (often the default for interactive use).<br><br><b><b>-f</b>, <b>--fields <field1,field2,...></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which fields to output. Use 'all' to show all available fields for the given object.<br><br><b><b>-e</b>, <b>--escape</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escape colons and backslashes in terse mode output, useful when dealing with data that might contain these characters.<br><br><b><b>-n</b>, <b>--nocheck</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't check for NetworkManager availability. Forces <b>nmcli</b> to run even if NetworkManager is not detected.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the <b>nmcli</b> version information and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the general help message or help for a specific object/command.<br><br><b><b>-o</b>, <b>--overview</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print an overview of available fields for a connection when used with 'connection show'.<br><br><b><b>-s</b>, <b>--show-secrets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show secrets (e.g., Wi-Fi passwords) when displaying connection details. Use with extreme caution as it exposes sensitive information.<br><br><b><b>-a</b>, <b>--ask</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for missing parameters interactively if necessary.<br><br><b><b>-w</b>, <b>--wait <seconds></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for NetworkManager's startup completion for a specified number of seconds before executing the command.<br><br><b><b>-r</b>, <b>--retry <count></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retry operations on NetworkManager failure for a specified number of times.<br><br>


title: DESCRIPTION
content:
<i>nmcli-networking</i> is not a standalone command but refers to the use of the <b>nmcli</b> (NetworkManager Command Line Interface) tool for managing network connections and devices. <b>nmcli</b> is the primary command-line interface for controlling the NetworkManager daemon, which dynamically configures and manages network connections on Linux systems. It allows users and scripts to view, add, modify, delete, activate, and deactivate network connections, and manage various networking devices like Ethernet, Wi-Fi, VPNs, and mobile broadband. It provides a robust and consistent way to manage network settings, simplifying complex configurations and enabling automation for system administrators and power users.


title: CAVEATS
content:
<b>nmcli</b> relies heavily on the NetworkManager daemon. If NetworkManager is not running, disabled, or encounters critical errors, <b>nmcli</b> will not function as expected.<br>Many operations, especially those that modify system-wide network configurations or bring up/down interfaces, require root privileges (e.g., by using <b>sudo</b>).<br>Care must be taken when modifying or deactivating active network connections, as it can temporarily disrupt network connectivity, potentially leading to loss of access.<br>Its terse output format (<code>-t</code>) is highly powerful for scripting but requires careful parsing due to its colon-separated structure and potential for escaped characters.


title: CONNECTION PROFILES VS. DEVICES
content:
<b>nmcli</b> conceptually distinguishes between 'connection profiles' and 'devices'. A 'connection profile' (managed by <code>nmcli connection</code>) is a set of configuration details for how to connect to a network (e.g., 'Home Wi-Fi', 'Office Ethernet'). A 'device' (managed by <code>nmcli device</code>) is a physical or virtual network interface (e.g., <i>eth0</i>, <i>wlan0</i>). A connection profile can be activated on a compatible device, effectively configuring that device to connect to a specific network.


title: ACTIVATION AND DEACTIVATION
content:
Networking in <b>nmcli</b> often involves the concept of 'activation' and 'deactivation'. Activating a connection profile on a device brings up the network connection, configuring the device according to the profile's settings. Deactivating a device or connection profile disconnects it from the network.


title: AUTO-CONNECT FEATURE
content:
Connection profiles can be configured to automatically connect when their associated device becomes available. This 'auto-connect' feature simplifies network management for users, as the system can automatically establish connections without manual intervention upon boot or device hot-plugging.


title: HISTORY
content:
NetworkManager was introduced to Linux distributions to simplify network configuration, particularly for portable devices (laptops) that frequently change network environments. It aimed to provide a consistent and dynamic way to manage various network types (wired, wireless, mobile broadband, VPNs) without manual intervention. <b>nmcli</b> emerged as its robust command-line interface, offering a powerful alternative to graphical tools and enabling comprehensive scripting of network tasks. Its development has focused on achieving feature parity with other NetworkManager interfaces, improving user experience for command-line users, and enhancing its capabilities for system administrators and automation.


title: SEE ALSO
content:
NetworkManager(8), nmcli(1), nmcli-examples(7), nmtui(1), nm-connection-editor(1), ip(8), ifconfig(8)


title: SYNOPSIS
content:
<I>nmcli radio</I><br><I>nmcli radio</I> { <I>all</I> | <I>wifi</I> | <I>wwan</I> | <I>bluetooth</I> } { <I>on</I> | <I>off</I> }


title: PARAMETERS
content:
<b><I>all</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the operation to all available wireless radios: Wi-Fi, WWAN, and Bluetooth.<br><br><b><I>wifi</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically targets and controls the Wi-Fi radio.<br><br><b><I>wwan</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically targets and controls the WWAN (mobile broadband) radio.<br><br><b><I>bluetooth</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically targets and controls the Bluetooth radio.<br><br><b><I>on</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the specified radio(s).<br><br><b><I>off</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the specified radio(s).<br><br>


title: DESCRIPTION
content:
<I>nmcli radio</I> is a specific subcommand of the <I>nmcli</I> (NetworkManager Command Line Interface) tool. It provides a simple yet powerful way to manage the global enabled/disabled state of various wireless radio technologies present on a system. This includes Wi-Fi, WWAN (Wireless Wide Area Network, commonly referred to as mobile broadband), and Bluetooth. Users can query the current status of these radios, or toggle their state (on/off) either individually or all at once. This functionality is essential for power management, quickly enabling or disabling wireless connectivity, or complying with airline mode requirements. It acts on the hardware's global state, not on individual network connections.


title: CAVEATS
content:
Requires the NetworkManager service to be running for <I>nmcli</I> to function correctly.<br>Changes made with <I>nmcli radio</I> typically require root privileges or membership in a group with NetworkManager administrative permissions (e.g., <I>network</I> group) to take effect.<br>The availability and functionality of <I>wwan</I> and <I>bluetooth</I> controls depend on the presence of corresponding hardware and drivers on the system.<br>Disabling a radio globally with <I>nmcli radio off</I> will prevent any network connections using that technology from operating, regardless of their individual connection status.


title: QUERYING RADIO STATUS
content:
When invoked without any arguments (i.e., <I>nmcli radio</I>), the command displays the current status of all known wireless radios. The output typically shows each radio (WIFI, WWAN, BLUETOOTH) and its current state (enabled or disabled).


title: PERSISTENCE
content:
Changes made with <I>nmcli radio</I> are generally persistent across reboots, as NetworkManager remembers the last state of the radios. However, specific hardware or system configurations might override this behavior.


title: HISTORY
content:
<I>nmcli</I> is the command-line interface for NetworkManager, a dynamic network configuration and management daemon widely adopted in Linux distributions. NetworkManager itself was initiated by Red Hat in 2004 with the goal of simplifying network setup, particularly for mobile users. The <I>nmcli</I> tool, including subcommands like <I>radio</I>, has evolved over time to provide comprehensive control over NetworkManager's functionalities from the terminal, becoming an indispensable tool for both desktop users and system administrators managing network interfaces programmatically or via scripts.


title: SYNOPSIS
content:
<b>nmon</b> [<i>interactive-keys</i>]<br><b>nmon</b> [-f] [-s <<i>interval</i>>] [-c <<i>count</i>>] [-o <<i>filename</i>>] [-t] [-m <<i>directory</i>>] [...<i>other_options</i>]


title: PARAMETERS
content:
<b>-s <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the data collection interval in seconds for batch mode.<br><br><b>-c <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of snapshots to capture in batch mode.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the generation of a spreadsheet-formatted output filename (e.g., hostname_YYMMDD_HHMM.nmon).<br><br><b>-o <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output data filename for batch mode. Typically used with -f.<br><br><b>-m <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory for data files when using -f.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes top processes in the batch output file or interactive display.<br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the collection of asynchronous I/O statistics.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the collection of Logical Volume Manager (LVM) statistics.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <i>nmon</i> in black and white mode, useful for non-color terminals.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with available options.<br><br>


title: DESCRIPTION
content:
<i>nmon</i> (Nigel's Monitor) is a versatile command-line tool designed for comprehensive system performance monitoring on Linux and AIX.<br><br>It provides a snapshot of various system resources, including CPU utilization, memory usage, disk I/O, network activity, top processes, file systems, and more. <i>nmon</i> can operate in two primary modes: an interactive, real-time display mode that updates statistics directly on the terminal, and a data collection mode that saves performance metrics to a file for later analysis. The output files generated in data collection mode are in a spreadsheet-friendly format, commonly analyzed using the <i>nmon_analyzer</i> tool.<br><br>Its lightweight nature and rich set of metrics make it an invaluable utility for identifying performance bottlenecks, understanding system behavior over time, and capacity planning. Originally developed by Nigel Griffiths at IBM for AIX, <i>nmon</i> was later ported to Linux and has become a widely adopted open-source tool for system administrators and performance engineers.


title: CAVEATS
content:
While <i>nmon</i> is generally lightweight, running it with very short intervals or for extended periods in batch mode can consume noticeable system resources, especially CPU and disk I/O for writing logs.<br><br>The interactive mode requires the <i>ncurses</i> library to be installed on the system.<br><br>Analysis of the generated .nmon files typically requires external tools like <i>nmon_analyzer</i> (a spreadsheet macro) or other custom scripts, as <i>nmon</i> itself does not provide built-in graphical analysis.


title: INTERACTIVE COMMANDS
content:
When <i>nmon</i> is run without options, it enters interactive mode. Various keys can be pressed to toggle different statistics views:<br><b>c</b>: CPU utilization<br><b>m</b>: Memory statistics<br><b>d</b>: Disk I/O statistics<br><b>n</b>: Network I/O statistics<br><b>t</b>: Top processes<br><b>V</b>: Virtual Memory and paging<br><b>q</b>: Quit <i>nmon</i>


title: DATA ANALYSIS
content:
Output files generated by <i>nmon</i> (typically with a .nmon extension) are colon-separated data, designed to be easily imported into spreadsheet applications. The official <i>nmon_analyzer</i> is an Excel macro that processes these files to generate graphs and detailed reports, simplifying the visualization and interpretation of performance data over time.


title: HISTORY
content:
<i>nmon</i> was originally developed by Nigel Griffiths while working at IBM for performance monitoring on AIX systems. Due to its utility and efficiency, it was later ported to Linux and became an open-source project. Its development has been community-driven since its release as open-source, making it a staple in many Linux system administration toolkits. It continues to be updated and maintained, reflecting its ongoing relevance in system performance analysis.


title: SYNOPSIS
content:
<i><b>No standard synopsis available.</b> The 'nms' command is not a recognized utility in standard Linux distributions. Its syntax, if it exists in a specific environment, would be entirely dependent on its local definition (e.g., a custom script or alias) or the specific Network Management System software that provides it.</i>


title: DESCRIPTION
content:
The term 'nms' does not refer to a standard, universally recognized Linux command within typical distributions. It commonly stands for 'Network Management System,' referring to comprehensive software applications designed to monitor, manage, and report on network devices, services, and overall network health. While various commercial and open-source NMS software packages (e.g., OpenNMS, Nagios, Zabbix, PRTG) exist and provide their own specific command-line interfaces or utilities for configuration and interaction, a general-purpose 'nms' command is not part of core Linux operating system functionalities. Users encountering 'nms' are likely dealing with a custom script, an alias, or a command specifically bundled with an installed third-party network management suite rather than a system-wide utility.


title: CAVEATS
content:
The absence of 'nms' as a standard Linux command implies that its behavior, availability, and syntax are highly context-dependent. It could be a local alias, a custom script, or a command-line tool bundled with a specific third-party Network Management System (NMS) installation. Therefore, its usage and expected output would vary significantly. Users should consult local documentation or the documentation for the specific NMS software they are using if 'nms' is encountered in their environment.


title: NON-STANDARD COMMAND CLARIFICATION
content:
It is crucial for users to understand that 'nms' is not a native or universally recognized Linux command. If you encounter 'nms' in a command-line context, it is highly probable that it refers to a user-defined alias, a custom shell script created for a specific purpose, or a command-line utility that is part of a particular third-party Network Management System (NMS) software package installed on that specific machine (e.g., OpenNMS, Nagios, Zabbix). Therefore, its functionality, arguments, and expected output would be unique to that specific local implementation and not generalizable across Linux systems.


title: HISTORY
content:
As 'nms' is not a standard Linux command, there is no specific historical development or usage associated with it within the Linux kernel or core utilities. The broader concept of Network Management Systems (NMS) has evolved significantly since the early days of networking, driven by standards like SNMP (Simple Network Management Protocol). Early NMS tools focused on basic device monitoring, while modern NMS platforms integrate advanced features like fault management, performance monitoring, configuration management, and security analysis. Various proprietary and open-source NMS solutions have their own rich development histories, but 'nms' as a standalone command does not.


title: PARAMETERS
content:
<b>nmtui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the main menu, allowing interactive navigation to edit connections, activate connections, or set the hostname.<br><br><b>nmtui edit <I>connection-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly opens the 'Edit a connection' dialog for the specified connection ID. This allows immediate modification of a particular network profile.<br><br><b>nmtui connect <I>connection-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the 'Activate a connection' dialog, pre-selecting the specified connection ID and attempting to activate it. Useful for quickly bringing up a specific network interface.<br><br><b>nmtui hostname</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly opens the 'Set System Hostname' dialog, allowing modification of the system's hostname.<br><br><b>nmtui status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise summary of the NetworkManager status, including connection states and general connectivity.<br><br>


title: DESCRIPTION
content:
<i>nmtui</i> is a curses-based Text User Interface (TUI) for configuring and managing network connections using NetworkManager. It provides a menu-driven, interactive way to perform common networking tasks directly from the terminal, making it ideal for server environments, SSH sessions, or situations where a graphical desktop environment is unavailable.<br><br>Users can easily add, edit, activate, and deactivate network connections, modify connection profiles (e.g., IP addresses, DNS servers, Wi-Fi settings), and manage the system's hostname. Its intuitive interface, navigated using arrow keys, Tab, and Enter, simplifies network configuration for users who might find <i>nmcli</i>'s command-line syntax too complex or prefer a visual workflow without the overhead of a full GUI. <i>nmtui</i> essentially brings the ease of graphical network configuration to the command line.


title: CAVEATS
content:
<i>nmtui</i> requires the <i>NetworkManager</i> service to be running. It uses D-Bus for communication with <i>NetworkManager</i> and typically requires root privileges or appropriate D-Bus policy permissions to modify network configurations. As a TUI, it's primarily designed for interactive use and is not suitable for complex scripting without tools like <i>expect</i>.


title: INTERACTIVE NAVIGATION
content:
Within the <i>nmtui</i> interface, navigate using <b>arrow keys</b> (Up, Down, Left, Right), <b>Tab</b> to move between elements, <b>Enter</b> to select or confirm, and <b>Esc</b> to go back or cancel. Options are often highlighted, and text input fields allow direct typing.


title: HISTORY
content:
<i>nmtui</i> is part of the <i>NetworkManager</i> project, which was initiated by Red Hat to simplify network configuration on Linux systems. While <i>nmcli</i> provided a powerful command-line interface, <i>nmtui</i> was developed to offer a more user-friendly, interactive text-based alternative for environments lacking a full graphical desktop. It leverages the <i>ncurses</i> library to provide its menu-driven interface, making network management accessible and intuitive for administrators and users in text-only console sessions.


title: SYNOPSIS
content:
The phrase "nmtui-connect" refers to an action performed within the interactive <I>nmtui</I> utility, not a standalone command with direct syntax. Therefore, it does not have a unique command synopsis. However, to directly access the connection activation interface within <I>nmtui</I>, one can invoke the tool in 'connect' mode:<br><b>nmtui</b> <I>connect</I>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>nmtui connect</b> mode does not accept direct command-line parameters for connection selection. The process of choosing and activating a network connection is entirely interactive, performed through the <I>nmtui</I> graphical interface.<br><br>


title: DESCRIPTION
content:
The command <b>nmtui-connect</b> is not a standalone executable or command in Linux. Instead, it refers conceptually to the process of activating or managing network connections within the <I>nmtui</I> (NetworkManager Text User Interface) program. <I>nmtui</I> provides a simple, curses-based graphical interface for configuring NetworkManager. Users launch <I>nmtui</I> and navigate its menus to perform various networking tasks, including activating existing connections, editing connection profiles, or setting the system hostname. When a user selects 'Activate a connection' within <I>nmtui</I>, they are presented with a list of available network profiles. Selecting a profile and confirming activates that connection, which is the action the phrase 'nmtui-connect' likely refers to. This interactive process abstracts away the direct command-line arguments typically found in tools like <I>nmcli</I>, offering a user-friendly way to manage network interfaces without complex syntax.


title: CAVEATS
content:
The term "nmtui-connect" is not a direct, executable Linux command. It serves as a conceptual shorthand for the action of activating a network connection using the interactive <I>nmtui</I> utility. Users must launch <I>nmtui</I> (or specifically <I>nmtui connect</I>) and interact with its text-based interface to perform connection operations. It is distinct from command-line tools like <I>nmcli</I> which operate non-interactively with specific arguments.


title: INTERACTIVE CONNECTION PROCESS
content:
Upon executing <b>nmtui connect</b> (or launching <b>nmtui</b> and navigating to 'Activate a connection'), users are presented with a scrollable list of available network connections (profiles). These profiles can include various types of networks such as Wi-Fi networks, wired Ethernet connections, VPNs, or mobile broadband connections. Users navigate this list using arrow keys, select a desired connection, and press Enter (or the 'Activate' button) to initiate the connection. For password-protected networks, <I>nmtui</I> will interactively prompt for the necessary credentials within the terminal. This entire process is menu-driven and does not involve passing connection-specific parameters directly on the command line.


title: HISTORY
content:
The <I>nmtui</I> utility, which facilitates the connection functionality referred to as "nmtui-connect," was developed as part of the NetworkManager project. NetworkManager is a critical system service for managing network connections and configurations on Linux. <I>nmtui</I> was introduced to offer a simpler, curses-based alternative to the more complex <I>nmcli</I> command-line tool. It emerged as a user-friendly interactive interface for common networking tasks, particularly beneficial for users without direct desktop GUI access or those preferring a terminal-based workflow. Its core 'connect' functionality has been an integral part of its design since its inception, providing an easy way to activate configured network profiles.


title: PARAMETERS
content:
<b><i>[<connection_name>]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. The name of the NetworkManager connection to edit. If provided, <b><code>nmtui</code></b> will attempt to open that specific connection for modification. If omitted, it will display a list of existing connections to choose from or an option to add a new one.<br><br>


title: DESCRIPTION
content:
<b><code>nmtui-edit</code></b> refers to the functionality provided by the <b><code>nmtui</code></b> command specifically for editing network connections. <b><code>nmtui</code></b> is a curses-based text user interface (TUI) for <b>NetworkManager</b>, designed to simplify network configuration on Linux systems, especially in environments without a graphical desktop.<br><br>The <b><code>nmtui edit</code></b> subcommand (which <b><code>nmtui-edit</code></b> conceptually represents) allows users to directly jump into modifying existing network connections or creating new ones. It offers an intuitive, menu-driven interface to configure various connection properties, including IP addresses (DHCP/static), DNS servers, Wi-Fi security (SSID, password), Ethernet device assignments, VPN settings, and more. This tool provides a user-friendly alternative to manually editing configuration files or using complex <b><code>nmcli</code></b> commands for common network management tasks.


title: CAVEATS
content:
<ul><li>Requires the <b>NetworkManager</b> service to be running.</li><li>Saving changes typically requires <b><code>root</code></b> privileges or sufficient <b><code>polkit</code></b> permissions.</li><li>As a curses-based interface, it requires a terminal environment for interaction.</li><li>Changes made are applied by <b>NetworkManager</b> and may affect currently active network connections.</li><li><b><code>nmtui-edit</code></b> is not a direct command, but rather refers to the <b><code>edit</code></b> subcommand of <b><code>nmtui</code></b>.</li></ul>


title: ADDING NEW CONNECTIONS
content:
While <b><code>nmtui edit</code></b> primarily focuses on modifying existing connections, if invoked without a <i><connection_name></i> or if no existing connections are selected from the list, it provides an intuitive option to create a <i>new network connection</i> from scratch.


title: INTERACTIVE NAVIGATION
content:
The <b><code>nmtui</code></b> interface is navigated using keyboard inputs. Users typically use arrow keys (Up, Down, Left, Right), the <b><code>Tab</code></b> key to cycle through elements, the <b><code>Enter</code></b> key to select or confirm, and the <b><code>Esc</code></b> key to cancel or go back.


title: HISTORY
content:
<b><code>nmtui</code></b> (and its subcommands like <b><code>edit</code></b>) was introduced as part of <b>NetworkManager</b> to provide a user-friendly, interactive text interface. Its development focused on simplifying network configuration for command-line users, complementing <b><code>nmcli</code></b> (the command-line interface) and graphical tools. It became a standard utility for managing network connections in various Linux distributions, especially useful for server administrators or in minimal desktop environments.


title: SYNOPSIS
content:
<b>nmtui-hostname</b><br><br><i>Note: This command is an interactive utility and does not accept direct command-line arguments or options. All interactions occur within its text-based interface.</i>


title: DESCRIPTION
content:
<i>nmtui-hostname</i> is a text-based user interface (TUI) utility specifically designed to allow system administrators to interactively configure the system's hostname. It is an integral part of the NetworkManager suite of tools, providing a simplified, curses-based interface focused solely on this task.<br><br>When executed, it presents a straightforward screen displaying the current hostname, where the user can easily input and confirm a new desired hostname. NetworkManager then takes care of applying the change persistently across system reboots, typically by updating the <i>/etc/hostname</i> file and informing <i>systemd-hostnamed</i>. This command greatly simplifies hostname management, especially beneficial in server environments or remote SSH sessions where a graphical user interface is unavailable. It requires <i>root</i> privileges for operation.


title: CAVEATS
content:
<ul><li>Requires <i>root</i> privileges to execute successfully.</li><li>Relies on the <i>NetworkManager</i> daemon being active and running on the system.</li><li>Changes made using this utility are persistent across system reboots.</li><li>As a TUI, it requires a terminal emulator capable of rendering ncurses interfaces.</li></ul>


title: INTERACTIVE USAGE
content:
Upon launching, <i>nmtui-hostname</i> displays a simple interactive form. Users can typically navigate using arrow keys and the Tab key, input the new hostname into a dedicated text field, and confirm their changes using the Enter key. The interface is intuitive and designed for minimal interaction.


title: BACKEND INTERACTION
content:
It's important to note that <i>nmtui-hostname</i> does not directly modify system configuration files. Instead, it communicates with the running NetworkManager daemon. NetworkManager then handles the proper persistent storage of the hostname, typically by updating the <i>/etc/hostname</i> file, and also ensures that <i>systemd-hostnamed</i> is notified of the change to update the system's runtime hostname.


title: HISTORY
content:
The <i>nmtui</i> utility, from which <i>nmtui-hostname</i> is often a specialized invocation or symbolic link, was developed as part of the NetworkManager project. NetworkManager itself emerged as a key component in Linux distributions in the mid-2000s to simplify network configuration. <i>nmtui</i> specifically gained popularity as an accessible, curses-based alternative to command-line tools like <i>nmcli</i> or manual configuration, proving particularly useful for server management or minimal installations. <i>nmtui-hostname</i> provides a convenient, dedicated shortcut for the common administrative task of changing the system hostname, reflecting NetworkManager's evolution towards more specialized and user-friendly tools.


title: SYNOPSIS
content:
<b>nnn</b> [<i>OPTIONS</i>] [<i>PATH</i>]<br><i>PATH</i> is an optional initial directory to start in. If not specified, <b>nnn</b> starts in the current directory.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display file/directory information in the status bar.<br><br><b><b>-b</b> <i>key</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a bookmark using its assigned single-character <i>key</i>.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy the absolute path of the selected file to the clipboard on quit.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable directory colorization; use default terminal colors.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable desktop notifications and desktop file opening (always use <i>EDITOR</i>/<i>PAGER</i>/<i>NNN_OPENER</i>).<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open selected file with the specified <i>EDITOR</i> (or <i>NNN_EDITOR</i>) on quit.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable fuzzy search for filtering directory contents.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show hidden files (dotfiles and dotdirs).<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open files and launch applications using <i>xdg-open</i>, <i>rifle</i>, or a custom opener script.<br><br><b><b>-p</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read paths from <i>file</i> for the picker mode.<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start <b>nnn</b> in read-only mode, preventing any file system modifications.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable as-you-type search filtering within the current directory.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make the as-you-type search case-sensitive.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details during operation.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launch <i>nuke</i> on quit. <i>nuke</i> is a command-line interface for common file operations.<br><br>


title: DESCRIPTION
content:
<b>nnn</b> is a remarkably compact and high-performance terminal file manager designed for efficiency and speed. It offers a minimalist interface while providing a rich set of features for everyday file management tasks. Built with a focus on speed and minimal resource usage, <b>nnn</b> allows users to navigate directories, perform file operations (copy, move, delete), and launch applications with incredible responsiveness. <br><br>It supports various modes including bookmarking, fuzzy search, and a unique "contexts" feature to manage multiple workspaces. Its extensibility is a core strength, leveraging a powerful plugin system that allows users to add custom functionality for file preview, archive management, media playback, and more. <b>nnn</b> aims to be a seamless part of a command-line workflow, integrating well with shell commands and external utilities for a truly powerful terminal experience.


title: CAVEATS
content:
<b>nnn</b> is a text-based user interface (TUI) application, meaning it operates entirely within the terminal and does not provide a graphical user interface (GUI). Its power lies in keyboard-driven efficiency, which may require some initial learning for users accustomed to mouse-centric file managers. Advanced features like file previews, archive extraction, and custom file opening rely heavily on external utilities (e.g., <i>less</i>, <i>atool</i>, <i>xdg-open</i>, <i>rifle</i>, <i>exiftool</i>) which must be installed and configured separately. While minimal, this dependency on external tools ensures flexibility but adds to the initial setup complexity for a fully-featured experience.


title: PLUGINS
content:
<b>nnn</b>'s functionality can be vastly extended through its rich plugin ecosystem. Plugins are simple shell scripts that reside in a specific directory (typically <i>${XDG_CONFIG_HOME}/nnn/plugins</i> or <i>~/.config/nnn/plugins</i>) and can be invoked from within <b>nnn</b> using keyboard shortcuts. These plugins enable features like custom file previews, media playback, archive handling, Git integration, and many more, allowing users to tailor <b>nnn</b> to their specific workflows without adding bloat to the core application.


title: CONTEXTS
content:
A unique feature of <b>nnn</b> is its support for up to four 'contexts' or workspaces. Each context maintains its own history and state, allowing users to navigate and manage files in multiple directories simultaneously without opening multiple instances of <b>nnn</b>. This is particularly useful for tasks involving copying or moving files between distant locations, or for simply keeping track of different project directories. Contexts can be switched using the <i>1-4</i> keys.


title: HISTORY
content:
<b>nnn</b> was created by Arun Prakash Jana (jarun) with the primary goal of developing an extremely fast and minimalist terminal file manager. It began as a highly optimized alternative to existing TUI file managers, emphasizing speed, small footprint, and extensibility through a plugin system rather than bloating the core application. Since its inception, <b>nnn</b> has gained significant popularity within the Linux and Unix-like communities for its robust performance and straightforward design, evolving with contributions from a vibrant open-source community while maintaining its core philosophy of speed and efficiency.


title: SEE ALSO
content:
<i>ranger(1)</i>, <i>mc(1)</i>, <i>lf(1)</i>, <i>ls(1)</i>, <i>cd(1)</i>, <i>xdg-open(1)</i>, <i>less(1)</i>


title: SYNOPSIS
content:
<b>nodemon</b> [<i>options</i>] [<i>your_script.js</i>] [<i>script_arguments</i>]<br><b>nodemon</b> [<i>options</i>] --exec [<i>command</i>] [<i>command_arguments</i>]<br><b>nodemon</b> [<i>options</i>]


title: PARAMETERS
content:
<b><b>-w</b>, <b>--watch</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a directory or file to watch. Can be used multiple times.<br><br><b><b>-i</b>, <b>--ignore</b> <i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore specified files or directories from being watched. Uses glob patterns. Can be used multiple times.<br><br><b><b>-e</b>, <b>--ext</b> <i>&lt;extensions&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify file extensions to watch (e.g., <i>js,pug,css</i>). Defaults to <i>js,mjs,json,coffee</i>.<br><br><b><b>--exec</b> <i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified command instead of 'node' (e.g., <i>python app.py</i>).<br><br><b><b>-d</b>, <b>--delay</b> <i>&lt;milliseconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delay the restart for a specified duration after a change is detected. Defaults to 1000ms.<br><br><b><b>-L</b>, <b>--legacy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the legacy 'polling' watch method, useful for NFS or Samba shares.<br><br><b><b>-V</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set logging level to verbose, showing more internal information.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all logging output from nodemon itself, showing only script output.<br><br><b><b>--exitcrash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit nodemon if the child process crashes (useful for CI environments).<br><br><b><b>--signal</b> <i>&lt;signal&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the signal to send to the child process on restart (e.g., <i>SIGUSR2</i>). Defaults to <i>SIGTERM</i>.<br><br><b><b>-x</b>, <b>--script-restart</b> <i>&lt;script&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows specifying a different script to run on restart. Deprecated, use <i>--exec</i> instead.<br><br><b><b>--config</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file (default is <i>nodemon.json</i>).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i><b>nodemon</b></i> is a utility that monitors for any changes in your source code and automatically restarts your server, making development faster and more efficient. It is primarily used for Node.js based applications, but can be configured to run any command, making it useful for other languages and frameworks.<br><br>Instead of manually stopping and starting your Node.js application every time you make a change, nodemon listens for file system events (or polls for changes) and, upon detecting a modification, sends a signal to gracefully shut down the running process and then re-launches it.<br><br>This significantly streamlines the development workflow by providing immediate feedback on code changes without requiring manual intervention, allowing developers to focus more on coding and less on task management. It comes with flexible configuration options to ignore specific files or directories, watch only certain file extensions, and execute custom commands.


title: CAVEATS
content:
While <i><b>nodemon</b></i> is highly effective, it might consume more CPU resources when watching a large number of files, especially when using the legacy polling method (<i>--legacy</i> or on network drives). It's crucial to properly configure <i>--ignore</i> to avoid unnecessary restarts caused by changes in temporary files or <i>node_modules</i>. In some environments, file system events might not be reliable, requiring the use of the polling option, which can be less efficient. Forceful termination (<i>SIGKILL</i>) might be used if the process doesn't shut down gracefully with <i>SIGTERM</i>, potentially leading to data loss if the application doesn't handle signals correctly.


title: CONFIGURATION FILES
content:
<i><b>nodemon</b></i> can be configured via a <i>nodemon.json</i> file placed in your project root or specified via the <i>--config</i> flag. This allows for project-specific watch paths, ignore patterns, and executable commands to be defined centrally, reducing the need for lengthy command-line arguments. Global configurations can also be set in <i>~/.nodemon.json</i>.


title: MANUAL RESTART
content:
Even with automatic monitoring, there are times when you might want to force a restart. You can do this by typing <i>rs</i> (for restart) into the terminal where <i><b>nodemon</b></i> is running and pressing <i>Enter</i>. This provides immediate control over your development server.


title: DEFAULT BEHAVIOR
content:
When no script is specified, <i><b>nodemon</b></i> will look for <i>server.js</i>, <i>app.js</i>, or <i>main.js</i> in the current directory and run it. By default, it automatically ignores common development directories like <i>node_modules</i> and <i>.git</i>.


title: HISTORY
content:
<i><b>nodemon</b></i> was created by Remy Sharp to address the common pain point for Node.js developers: the need to manually restart the server after every code change. Before <i>nodemon</i>, developers would often use shell scripts or other tools to achieve similar functionality, but <i>nodemon</i> provided a dedicated, opinionated, and highly effective solution. It quickly became a standard tool in the Node.js development ecosystem due to its simplicity, ease of use, and significant productivity gains. Its continuous development and wide adoption have cemented its place as an indispensable utility for building robust and dynamic Node.js applications.


title: SYNOPSIS
content:
<b>nodenv</b> <i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>...]<br><b>nodenv</b> <i>install</i> <i>&lt;version&gt;</i><br><b>nodenv</b> <i>global</i> <i>&lt;version&gt;</i><br><b>nodenv</b> <i>local</i> <i>&lt;version&gt;</i><br><b>nodenv</b> <i>versions</i><br><b>nodenv</b> <i>which</i> <i>&lt;executable&gt;</i><br><b>nodenv</b> <i>rehash</i>


title: PARAMETERS
content:
<b><b>install</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified Node.js version. This command typically requires the <i>node-build</i> plugin to function.<br><br><b><b>global</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default Node.js version for all shells. This version is used when no local or shell-specific version is set.<br><br><b><b>local</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Node.js version for the current directory and its subdirectories by creating a <i>.node-version</i> file.<br><br><b><b>versions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed Node.js versions, indicating which one is currently active.<br><br><b><b>which</b> <i>&lt;executable&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the full path to the executable (e.g., <i>node</i>, <i>npm</i>) that <b>nodenv</b> will run for the current context.<br><br><b><b>rehash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs shims for all Node.js executables and globally installed npm packages known to <b>nodenv</b>. Essential to run after installing new versions or global packages.<br><br><b><b>shell</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Node.js version for the current shell session only. This setting overrides global and local versions and is temporary.<br><br><b><b>uninstall</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstalls a specific Node.js version from your system.<br><br>


title: DESCRIPTION
content:
<b>nodenv</b> is a lightweight command-line utility designed for managing multiple Node.js versions on a single system. It empowers developers to seamlessly switch between different Node.js environments, whether globally for all projects or locally on a per-project basis, utilizing `.node-version` files. <br><br>The core mechanism of nodenv involves inserting its "shims" directory at the front of your <b>PATH</b> environment variable. This setup allows nodenv to intercept calls to Node.js related executables like <i>node</i>, <i>npm</i>, and <i>npx</i>. When a Node.js command is invoked, nodenv intelligently determines the appropriate Node.js version to use based on the current directory, the presence of `.node-version` files, and global configurations, before transparently passing the command to the selected Node.js installation. <br><br>This approach emphasizes simplicity and non-invasiveness, requiring minimal shell integration. It's often extended with plugins like <i>node-build</i> to streamline the installation of new Node.js versions. By ensuring project-specific Node.js environments without conflicts, nodenv is an invaluable tool for development workflows that require support for various Node.js versions.


title: CAVEATS
content:
<b>nodenv</b> relies heavily on manipulating your <i>PATH</i> environment variable; incorrect shell setup can lead to issues. Users must explicitly run <i><b>nodenv rehash</b></i> after installing new Node.js versions or global npm packages for new executables to be discoverable via shims. It does not ship with an installer for Node.js itself, relying on plugins like <i>node-build</i> or manual installations.


title: PLUGINS
content:
<b>nodenv</b>'s core functionality can be significantly extended through a robust plugin system. The most crucial plugin is <i>node-build</i>, which provides the <b>install</b> command, enabling effortless downloading and compiling of various Node.js versions directly.


title: SHIMS
content:
A fundamental concept in <b>nodenv</b> is the use of "shims." These are small executable scripts placed in your <i>PATH</i> that intercept calls to Node.js commands (like <i>node</i>, <i>npm</i>, <i>npx</i>). When a shim is executed, <b>nodenv</b> determines the correct Node.js version for the current context and then transparently passes the command to the actual Node.js executable.


title: HISTORY
content:
<b>nodenv</b> was inspired by the design principles of <b>rbenv</b>, a popular Ruby version manager. It emerged as an alternative to more intrusive version management solutions, emphasizing simplicity, minimal shell integration, and an extensible plugin-based architecture. Its development focuses on being unopinionated and providing a clean way to manage Node.js versions through <i>PATH</i> manipulation and shims.


title: PARAMETERS
content:
<b><I>COMMAND</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to be executed, which will ignore the SIGHUP signal.<br><br><b>[<I>ARG</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments passed to the `COMMAND`.<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:
`nohup` (short for "no hang up") is a POSIX command that runs a specified command such that it ignores the SIGHUP (hang-up) signal. This signal is typically sent to a process by the operating system when its controlling terminal is closed or disconnected, which would normally terminate the process. By using `<b>nohup</b>`, long-running processes can continue executing in the background even after the user logs out or the network connection is lost.<br><br>When a command is run with `<b>nohup</b>`, its standard output and standard error are, by default, redirected to a file named `<b>nohup.out</b>` in the current directory. If the current directory is not writable, the output is redirected to `<b>$HOME/nohup.out</b>`. Standard input is redirected from `<b>/dev/null</b>`. It's important to note that `<b>nohup</b>` itself does not automatically background the command; to run a process in the background and disconnect from the terminal, one must typically append `<b>&</b>` to the command. This combination makes `<b>nohup</b>` a crucial utility for managing persistent background tasks on remote servers.


title: CAVEATS
content:
<ul><li>`<b>nohup</b>` does not automatically send a process to the background; you must explicitly append `<b>&</b>` (ampersand) to the command to run it in the background.</li><li>`<b>nohup</b>` primarily handles the SIGHUP signal. Other signals (e.g., SIGTERM, SIGKILL) can still terminate the process.</li><li>Default output redirection to `<b>nohup.out</b>` can lead to large files if not managed. Always consider explicit redirection (`<b>> file.log 2>&1</b>`) for better control.</li><li>Standard input is redirected from `<b>/dev/null</b>`, so interactive commands will not work as expected.</li></ul>


title: OUTPUT REDIRECTION
content:
By default, `<b>nohup</b>` redirects standard output and standard error to a file named `<b>nohup.out</b>` in the current working directory. If `<b>nohup.out</b>` cannot be created or is not writable, it attempts to write to `<b>$HOME/nohup.out</b>`. To redirect output to a different file, you must explicitly do so, for example: `<b>nohup command > output.log 2>&1 &</b>`.


title: INPUT HANDLING
content:
`<b>nohup</b>` automatically redirects standard input to `<b>/dev/null</b>`. This means that the command being run with `<b>nohup</b>` will not be able to receive any input from the terminal after it is started. This is generally desired for background processes but is an important consideration for interactive scripts.


title: HISTORY
content:
`<b>nohup</b>` has been a fundamental utility in Unix-like operating systems since their early days. It addresses the basic need to run processes that persist beyond the lifetime of a user's login session. Its design is simple and effective, predating more complex session management tools like `<b>screen</b>` and `<b>tmux</b>`, but it remains a widely used and essential command for its specific purpose.


title: PARAMETERS
content:
<b><code>--help</code>, <code>-h</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><code>--version</code>, <code>-v</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information and exits.<br><br><b><code>--verbose</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of output, showing more details about the comparison process.<br><br><b><code>--format &lt;FORMAT&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for differences (e.g., `text`, `xml`, `html`).<br><br><b><code>--ignore-whitespace</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores differences in whitespace during comparison.<br><br><b><code>--ignore-attributes &lt;ATTR&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores differences in specified attributes (e.g., `id`, `class`). Can be repeated for multiple attributes.<br><br><b><code>--ignore-children</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores differences in child nodes, focusing only on the current node's content and attributes.<br><br><b><i>FILE1</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the first XML or HTML file for comparison.<br><br><b><i>FILE2</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the second XML or HTML file for comparison.<br><br>


title: DESCRIPTION
content:
The term "nokogiri" primarily refers to a powerful <b>Ruby library</b> for parsing and manipulating HTML and XML documents. While `nokogiri` itself is not a direct standalone Linux command in the traditional sense (like `ls` or `grep`), the `nokogiri` <i>gem</i> often installs a utility called `nokogiri-diff`.<br><br>This utility provides a command-line interface for comparing two XML or HTML files. It leverages the Nokogiri library's parsing capabilities to identify and present the structural and content differences between the two documents. It's particularly useful for development workflows, testing, or auditing changes in web content or data feeds.<br><br>Its presence as an executable demonstrates a practical command-line application of the underlying Nokogiri library's power beyond typical Ruby script usage.


title: CAVEATS
content:
The `nokogiri-diff` command is a specific utility for document comparison, not a general-purpose XML/HTML parsing or manipulation tool from the command line. Its functionality is limited to identifying differences. For more complex operations like extracting data, modifying structures, or validating documents, direct use of the Nokogiri Ruby library within a Ruby script is necessary. Its availability depends on the `nokogiri` gem being installed on the system, and it might not be in the default system PATH depending on the Ruby installation method.


title: INSTALLATION
content:
To use `nokogiri-diff`, you must first have Ruby installed, and then install the `nokogiri` gem. This is typically done via <code>gem install nokogiri</code> or by including <code>gem 'nokogiri'</code> in a Gemfile and running <code>bundle install</code>. Ensure that necessary system libraries (like libxml2 and libxslt) are also present, as Nokogiri relies on them for its C extensions.


title: COMPARISON LOGIC
content:
<code>nokogiri-diff</code> performs a structural comparison, meaning it understands the tree-like nature of XML/HTML documents. It doesn't just compare text lines; it identifies changes in elements, attributes, and text content within the document's hierarchy, making it more intelligent for structured data than a simple line-by-line diff.


title: HISTORY
content:
Nokogiri itself was first released in 2008, developed by Aaron Patterson and others. It rapidly became the de facto standard for XML and HTML parsing in the Ruby ecosystem due to its speed (being C-based, leveraging libxml2 and libxslt) and powerful API. The `nokogiri-diff` utility, while not as prominent as the library itself, has been included as a bundled executable script within the `nokogiri` gem for many years, providing a convenient command-line interface for a specific common task: comparing structured documents, directly leveraging the library's robust parsing capabilities.


title: SEE ALSO
content:
diff(1): <br>Compares two files line by line., xmllint(1): <br>A command-line XML tool from libxml2, often used for parsing, validating, and formatting XML., tidy(1): <br>A command-line tool for cleaning up and validating HTML., gem(1): <br>The RubyGems package manager command, used for installing and managing Ruby gems like `nokogiri`., bundle(1): <br>Bundler, a dependency manager for Ruby, often used to install gems including Nokogiri.


title: DESCRIPTION
content:
The <b>nologin</b> command, typically located at <i>/usr/sbin/nologin</i>, is a special shell program designed to prevent direct interactive login access for a user account. When a user's login shell in <i>/etc/passwd</i> is set to <b>nologin</b>, any attempt by that user to log in via mechanisms like <b>login(1)</b> or <b>sshd(8)</b> will be denied. Instead of granting a shell prompt, <b>nologin</b> displays a configurable message (by default, "This account is currently not available.") to the user and then immediately exits with a non-zero status, effectively terminating the login attempt. This utility is widely used for system accounts (e.g., <i>daemon</i>, <i>bin</i>, <i>nobody</i>) that do not require interactive shell access, for accounts that are temporarily disabled, or for accounts dedicated to specific services (e.g., an FTP-only user). It acts as a simple yet effective security measure by limiting potential attack surfaces and ensuring that even if a user's password becomes compromised, an attacker cannot gain a shell on the system.


title: CAVEATS
content:
Using <b>nologin</b> only prevents interactive shell access. It does <i>not</i> prevent access to other services (such as FTP, Samba, Web services, or mail) if those services are separately configured to allow access for the account. Additionally, it does not inherently prevent a user from executing commands via <b>sudo</b> if their <i>sudoers</i> configuration permits it. It is not a substitute for robust security practices like strong passwords and proper file permissions.


title: USAGE
content:
To set <b>nologin</b> as a user's shell, you can use:<br><i>sudo usermod -s /usr/sbin/nologin username</i><br>When creating a new user:<br><i>sudo useradd -s /usr/sbin/nologin newuser</i><br>Alternatively, a user can change their own shell (if permitted) using:<br><i>chsh -s /usr/sbin/nologin</i>


title: CUSTOMIZING THE MESSAGE
content:
By default, <b>nologin</b> displays a generic message. To customize this message, create a file named <i>/etc/nologin.txt</i>. The contents of this file will be displayed to the user upon a failed login attempt instead of the default message.


title: COMPARISON WITH <B>FALSE(1)</B>
content:
While <b>false(1)</b> can also be used as a login shell to deny access (as it simply exits with a non-zero status), it provides no message to the user, making the reason for login failure less clear. <b>nologin</b> offers a more user-friendly experience by explicitly informing the user that their account is unavailable.


title: HISTORY
content:
The concept of a 'nologin' shell has been a fundamental part of Unix-like operating systems for decades, providing a simple and standardized way to disable interactive login access for specific user accounts. Its core functionality has remained consistent over time, serving as a basic but essential tool in user account management and system security.


title: SYNOPSIS
content:
<b>nomad</b> [<i>global options</i>] <i>&lt;command&gt;</i> [<i>subcommand options</i>] [<i>arguments</i>]<br><br>Common commands include:<br><i>&nbsp;&nbsp;</i><b>nomad agent</b> [<i>options</i>]<br><i>&nbsp;&nbsp;</i><b>nomad job</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>args</i>]<br><i>&nbsp;&nbsp;</i><b>nomad status</b> [<i>options</i>] [<i>&lt;job-id&gt;</i>]<br><i>&nbsp;&nbsp;</i><b>nomad alloc</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>args</i>]<br><i>&nbsp;&nbsp;</i><b>nomad node</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>args</i>]


title: PARAMETERS
content:
<b><b>-address=&lt;addr&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Address of the Nomad server to connect to (e.g., http://127.0.0.1:4646).</I><br><br><b><b>-region=&lt;region&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The region of the Nomad servers to make API requests against.</I><br><br><b><b>-namespace=&lt;namespace&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The target namespace for the command (default: 'default').</I><br><br><b><b>-log-level=&lt;level&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets the Nomad agent's log level (e.g., info, debug, trace).</I><br><br><b><b>-config=&lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Path to a configuration file or directory for the Nomad agent.</I><br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prints the Nomad version and exits.</I><br><br><b><b>-non-interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Disables interactive mode for commands that might prompt for user input.</I><br><br><b><i>(Subcommand-specific options)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Many Nomad subcommands (e.g., <b>nomad agent</b>, <b>nomad job run</b>) have their own extensive sets of options. Examples include <b>-dev</b> for starting a development agent, <b>-server</b> to enable server mode, or <b>-data-dir</b> for specifying data storage paths.</I><br><br>


title: DESCRIPTION
content:
HashiCorp <b>Nomad</b> is a flexible and efficient workload orchestrator that enables organizations to deploy, manage, and scale applications across diverse infrastructures. It supports various workload types, including containerized (Docker, Podman), virtualized (QEMU, Firecracker), and raw executables, making it highly adaptable to different environments. Nomad simplifies infrastructure management by providing a single workflow for scheduling applications on bare metal, virtual machines, or cloud instances. It integrates seamlessly with other HashiCorp tools like Consul for service discovery and Vault for secrets management. Its lightweight design and single binary make it easy to operate, while its powerful scheduling capabilities ensure optimal resource utilization and high availability for services. Nomad focuses on operational simplicity and a broad range of workload compatibility, providing a robust alternative to more complex orchestrators.


title: CAVEATS
content:
Nomad requires a running agent (server or client) to function, either locally or remotely. Job definitions are typically written in HashiCorp Configuration Language (HCL), which requires familiarity with its syntax. Proper understanding of its architecture and integration with other tools (like Consul and Vault) is crucial for secure and efficient production deployments. Resource management and task scheduling in large-scale deployments often require careful tuning for optimal performance.


title: <I>ARCHITECTURE</I>
content:
Nomad operates with a client-server architecture. <b>Servers</b> manage the cluster state, handle job submissions, and make scheduling decisions, utilizing a consensus protocol (Raft) for high availability. <b>Clients</b> register with servers, provide available resources, and execute tasks based on server instructions. Communication occurs over RPC.


title: <I>WORKLOAD DRIVERS</I>
content:
Nomad supports various workload types through its extensible driver system. This includes <b>Docker</b> containers, <b>QEMU</b> virtual machines, Java <b>Jar</b> files, raw <b>exec</b>utables, and more. This flexibility allows a single Nomad cluster to schedule diverse applications, optimizing resource utilization across different technology stacks.


title: HISTORY
content:
Nomad was open-sourced by HashiCorp in September 2015, building on their experience with Vagrant, Consul, and Vault. It was conceived as a lightweight, flexible, and highly available scheduler capable of orchestrating a wide range of workloads, not limited to just containers. This broad applicability differentiated it from other orchestrators emerging at the time. Since its initial release, Nomad has continuously evolved, adding support for more workload drivers (e.g., Podman, Firecracker), advanced scheduling features, and enterprise capabilities, while maintaining its core tenets of operational simplicity and comprehensive workload compatibility.


title: PARAMETERS
content:
<b>login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates your NordVPN account. Typically opens a browser window for authentication.<br><br><b>connect [<country|city|ID>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Establishes a VPN connection. You can specify a country (e.g., 'us'), city (e.g., 'new york'), or a specific server ID. Supports options like <I>--group</I> (e.g., 'double_vpn', 'p2p') and <I>--protocol</I> (e.g., 'nordlynx', 'openvpn_udp').<br><br><b>disconnect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Terminates the active VPN connection.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current VPN connection status, including the connected server, IP address, and protocol.<br><br><b>settings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current NordVPN application settings. Use <I>nordvpn settings set <option> <value></I> to modify them.<br><br><b>set <option> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures various NordVPN settings. Common options include <I>killswitch on|off</I>, <I>autoconnect on|off</I>, <I>dns <IP></I>, <I>protocol <protocol></I>, <I>cybersec on|off</I>, and <I>meshnet on|off</I>.<br><br><b>account</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays your NordVPN account information, including subscription status and expiration date.<br><br><b>whitelist <add|remove|status|clear></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages the VPN Kill Switch whitelist. You can whitelist applications, IP subnets, or ports to bypass the VPN connection.<br><br><b>refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes the local server list cache to ensure you have the latest server information.<br><br><b>enable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the NordVPN service daemon. This allows the client to establish VPN connections and manage network traffic.<br><br><b>disable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the NordVPN service daemon. This prevents the client from establishing VPN connections.<br><br><b>autoconnect [on|off]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures whether NordVPN should automatically connect to a VPN server when the service starts or on system boot.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for and installs updates for the NordVPN client application.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed NordVPN client version.<br><br><b>diagnose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gathers diagnostic information about the NordVPN client and system for troubleshooting purposes.<br><br>


title: DESCRIPTION
content:
The `nordvpn` command-line interface provides a robust and comprehensive way to manage your NordVPN connection directly from your Linux terminal. It allows users to connect to VPN servers, disconnect, view connection status, and configure advanced settings such as Kill Switch, auto-connect, DNS, and preferred protocols (NordLynx, OpenVPN). It's designed for seamless integration and automation, enabling users to maintain online privacy and security without a graphical user interface. The client manages network routing, DNS resolution, and firewall rules to ensure your traffic is protected efficiently and securely.


title: CAVEATS
content:
A valid NordVPN subscription is required for service usage.<br>The `nordvpn` daemon service must be running for commands to function; it's typically managed with `systemctl` (e.g., `sudo systemctl start nordvpn.service`).<br>Kill Switch functionality relies on underlying firewall mechanisms (like iptables or nftables) and can block all internet traffic if the VPN connection drops or is not established.


title: SERVICE MANAGEMENT
content:
The `nordvpn` client relies on a background service. You can manage this service using `systemctl`. For example:<br><I>sudo systemctl start nordvpn.service</I> (start the daemon)<br><I>sudo systemctl stop nordvpn.service</I> (stop the daemon)<br><I>sudo systemctl enable nordvpn.service</I> (enable daemon to start on boot)<br><I>sudo systemctl disable nordvpn.service</I> (disable daemon from starting on boot)<br><I>sudo systemctl status nordvpn.service</I> (check daemon status)


title: THREAT PROTECTION LITE
content:
NordVPN offers a Threat Protection Lite feature that blocks malicious websites and ads at the DNS level. Enable it with <I>nordvpn set threat-protection-lite on</I>. Note that the full Threat Protection suite is typically available on desktop GUI applications and offers more extensive features.


title: MESHNET
content:
Meshnet is a NordVPN feature that allows you to create secure, private connections between your devices, enabling direct access to files and services as if they were on the same local network, even across different geographical locations. It can be toggled using <I>nordvpn set meshnet on|off</I>.


title: HISTORY
content:
NordVPN was founded in 2012. Its Linux command-line client has steadily evolved, becoming a primary interface for many Linux users to manage their VPN connections. Early versions primarily relied on the OpenVPN protocol. The introduction of NordLynx (NordVPN's WireGuard-based protocol) and features like Meshnet significantly enhanced performance, functionality, and user experience, making the CLI a powerful and feature-rich tool for privacy and security on Linux systems.


title: SEE ALSO
content:
openvpn(8): For manual OpenVPN configurations., systemctl(1): For managing the `nordvpn` background service., nmcli(1): NetworkManager command-line tool, related to general network configuration., iptables(8): Linux firewall utility, related to Kill Switch implementation., nftables(8): Modern Linux firewall utility, also related to Kill Switch implementation.


title: SYNOPSIS
content:
noti [<I>options</I>] [<b><I>message</I></b>]<br>noti <b>run</b> [<I>options</I>] <b><I>command</I></b> [<b><I>arguments...</I></b>]<br>noti <b>exec</b> [<I>options</I>] <b><I>command</I></b> [<b><I>arguments...</I></b>]<br>noti <b>success</b> [<I>options</I>] [<b><I>message</I></b>]<br>noti <b>fail</b> [<I>options</I>] [<b><I>message</I></b>]<br><b><I>command</I></b> | noti [<I>options</I>]


title: PARAMETERS
content:
<b><b>-t</b>, <b>--title</b> <I>text</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set a custom title for the notification.</I><br><br><b><b>-m</b>, <b>--message</b> <I>text</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set a custom message for the notification.</I><br><br><b><b>-s</b>, <b>--sound</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify a sound to play with the notification (service dependent).</I><br><br><b><b>-p</b>, <b>--priority</b> <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set the notification priority (service dependent).</I><br><br><b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Include system information (e.g., hostname, user) in the notification.</I><br><br><b><b>-e</b>, <b>--env</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Include environment variables in the notification details.</I><br><br><b><b>-d</b>, <b>--desktop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force sending a desktop notification.</I><br><br><b><b>-C</b>, <b>--config</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify an alternative configuration file path.</I><br><br><b><b>--no-details</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Omit execution details (e.g., duration, exit code) from the message.</I><br><br><b><b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not print the executed command's output to standard output.</I><br><br><b><b>--oneshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Bypass the configuration file and require direct service flags (e.g., <b>--pushover-token</b>).</I><br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not actually send the notification; just print what would be sent.</I><br><br><b><b>-V</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enable verbose output for debugging and information.</I><br><br><b><b>-D</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Enable debug output for more detailed logging.</I><br><br><b><b>--service</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specify a named service from the config file to use.</I><br><br>


title: DESCRIPTION
content:
<i>noti</i> is a powerful command-line utility that sends notifications to various services upon the completion or failure of a command. It is designed to keep you informed about long-running tasks without constantly monitoring your terminal. <br><br>It supports a wide array of notification channels, including popular services like Pushover, Pushbullet, Slack, and Telegram, as well as email, desktop notifications, and custom scripts. <i>noti</i> can be used in several ways: by piping the output of a command, by prefixing a command with <i>noti</i>, or by wrapping a command execution. It provides options to send success or failure messages, customize titles and messages, and even play sounds. Configuration is typically managed through a YAML file, allowing for flexible setup of multiple notification services.


title: CAVEATS
content:
<i>noti</i> relies heavily on external notification services, requiring internet connectivity and proper API key/token configuration for most services. Its initial setup can be complex due to the YAML configuration file, especially when setting up multiple services. Features like custom sounds or specific priorities are service-dependent and may not work across all supported notification channels. <br>When using <i>noti</i> with long-running background processes, ensure that the environment variables and paths required by <i>noti</i> are correctly inherited, especially if it's sending system-specific information.


title: CONFIGURATION FILE
content:
<i>noti</i> typically reads its configuration from a YAML file, usually located at <b>~/.noti.yaml</b> or <b>~/.config/noti/config.yaml</b>. This file allows users to define and configure multiple notification services (e.g., Pushover, Slack, Telegram, Email, Desktop) with their respective API keys, tokens, and default settings.


title: USAGE PATTERNS
content:
<i>noti</i> integrates seamlessly with shell scripting. Common usage patterns include: <br><i>command</i> <b>&&</b> <i>noti success "Command done!"</i> (notify on success)<br><i>command</i> <b>||</b> <i>noti fail "Command failed!"</i> (notify on failure)<br><i>long_command</i> <b>|</b> <i>noti</i> (send command output as message)<br><i>noti run "long_command with args"</i> (wrap execution for auto-notification).


title: HISTORY
content:
<i>noti</i> is a relatively modern command-line tool, primarily developed by <b>variadico</b>, that gained traction through its open-source presence on platforms like GitHub. It was created to address the common need for command-line users to be asynchronously notified about the status of long-running processes. Its development has focused on expanding support for various notification services and improving ease of configuration, rather than undergoing major historical revisions typical of older Unix utilities.


title: SYNOPSIS
content:
<b>notify-send</b> [OPTIONS] <SUMMARY> [BODY]<br><br><i>SUMMARY</i>: The summary text of the notification, typically displayed as a bold title.<br><i>BODY</i>: Optional. The main body text of the notification, usually displayed below the summary.


title: PARAMETERS
content:
<b><b>-u</b>, <b>--urgency=</b><i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the urgency level of the notification. Possible levels are <i>low</i>, <i>normal</i>, or <i>critical</i>. Critical notifications often bypass timeout settings and might require explicit user dismissal.<br><br><b><b>-t</b>, <b>--expire-time=</b><i>MILLISECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the timeout duration for the notification in milliseconds. A value of 0 indicates that the notification should never expire on its own (until clicked or dismissed by the user).<br><br><b><b>-i</b>, <b>--icon=</b><i>ICON</i>[<i>,ICON...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an icon to display with the notification. This can be a stock icon name (e.g., 'dialog-information', 'emblem-important') or an absolute path to an image file (e.g., '/usr/share/icons/gnome/256x256/apps/utilities-terminal.png').<br><br><b><b>-a</b>, <b>--app-name=</b><i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the application name sending the notification. This can influence how the notification daemon groups or displays messages, or which icon to show.<br><br><b><b>-c</b>, <b>--category=</b><i>CATEGORY</i>[<i>,CATEGORY...</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the notification category, which can provide hints to the notification server about the type of event. Examples include 'device', 'email', 'transfer'.<br><br><b><b>-h</b>, <b>--hint=</b><i>TYPE:NAME:VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds extra information (hints) to the notification. This is a more advanced option, allowing control over various properties like X/Y position (e.g., <i>int:x:100</i>), transient behavior, or desktop entry (e.g., <i>string:desktop-entry:firefox</i>).<br><br><b><b>-R</b>, <b>--replace=</b><i>ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces an existing notification with the given ID. This is useful for updating a persistent notification (e.g., a progress bar) rather than creating a new one each time.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for notify-send and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and exits.<br><br>


title: DESCRIPTION
content:
notify-send is a command-line tool that sends desktop notifications to the user's notification daemon (e.g., dunst, GNOME Shell, KDE Plasma's notification system) via the D-Bus Desktop Notifications Specification. These notifications typically appear as small pop-up bubbles or banners on the screen, providing transient messages without interrupting the user's workflow.<br><br>It is commonly used by shell scripts or applications to inform the user about events, completion of tasks, or urgent status changes. It supports various options to customize the appearance and behavior of the notification, such as setting urgency levels, timeouts, icons, and categories. The notification daemon handles the display and persistence of these messages, making notify-send a versatile tool for system administrators and developers.


title: CAVEATS
content:
notify-send relies on a running notification daemon that implements the D-Bus Desktop Notifications Specification. If no such daemon is running (common on minimal installations or servers), the command might fail silently or produce a D-Bus related error. The exact appearance and behavior of notifications (e.g., position, theme, sound) are entirely determined by the user's notification daemon and desktop environment, not by notify-send itself. Icon paths must be absolute paths to image files or valid stock icon names present in the system's icon themes.


title: D-BUS INTEGRATION
content:
notify-send communicates with the notification daemon over D-Bus, an inter-process communication system. This architecture decouples the sender (notify-send) from the display mechanism, allowing different desktop environments and notification daemons to render messages in their own unique ways while adhering to a common underlying protocol. This ensures cross-desktop compatibility and flexibility.


title: SCRIPTING USAGE
content:
notify-send is a popular choice for shell scripting. For example, to notify a user when a long-running command finishes: <i>'long_running_command && notify-send "Task Complete" "Your command has finished running."'.</i> It can also be used with conditional logic to alert on errors or specific events.


title: HISTORY
content:
notify-send is part of the <i>libnotify</i> library, which provides a simple API for sending desktop notifications. It originated within the GNOME project and has since become a standard command-line utility across various Linux desktop environments. Its development closely follows the D-Bus Desktop Notifications Specification, first published around 2005, which standardized how applications communicate transient messages to the user without direct GUI interaction. Its widespread adoption highlights the importance of a uniform, non-intrusive notification mechanism for applications and scripts.


title: SYNOPSIS
content:
<i><b>notmuch</b> [global-options] &lt;command&gt; [command-options] [arguments]</i><br><br><i><b>Common Commands:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>new</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>search</b> [options] &lt;query&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>show</b> [options] &lt;query&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>tag</b> [options] (+tag|-tag ...) &lt;query&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>count</b> [options] &lt;query&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>restore</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>compact</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>reindex</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>notmuch</b> <b>help</b> [command]</i>


title: PARAMETERS
content:
<b><i>--config=&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file path instead of the default.<br><br><b><i>--profile=&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a specific named profile from the configuration file, allowing for multiple notmuch configurations.<br><br><b><i>--database=&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the location of the notmuch database directory, overriding the configured path.<br><br><b><i>--batch</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables batch mode, preventing interactive prompts and useful for scripting.<br><br><b><i>--color[=always|never|auto]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls color output. 'auto' (default) enables color when output is to a TTY, 'always' forces it, 'never' disables it.<br><br><b><i>--debug</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug logging to standard error for diagnostic purposes.<br><br><b><i>--format=&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the general output format for commands like 'search' or 'show' (e.g., 'json', 'sexp', 'text').<br><br><b><i>--output=&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically requests JSON or S-expression output for applicable commands (e.g., 'json', 'sexp', 'json-0', 'sexp-0').<br><br><b><i>--sort=newest-first|oldest-first</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts search results by date, either newest (default) or oldest first.<br><br><b><i>--reverse</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverses the default or specified sort order for results.<br><br><b><i>--limit=&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the number of results returned by a search query to N.<br><br><b><i>--offset=&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the first N results, useful for pagination of search results.<br><br><b><i>--format-string=&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a custom format string for detailed control over output presentation for specific commands.<br><br>


title: DESCRIPTION
content:
<i><b>notmuch</b> is a powerful and fast command-line interface (CLI) tool designed for indexing, searching, and managing large collections of email messages. It operates on email stored in the <B>Maildir</B> format, treating each email as a file in the filesystem. Unlike traditional email clients that rely on hierarchical folders, notmuch uses a flexible tagging system, allowing a single email to be associated with multiple categories simultaneously.<br><br>At its core, notmuch leverages the <B>Xapian</B> search engine to provide lightning-fast full-text searches across millions of messages. It does not handle sending or receiving email itself, but rather acts as a robust backend for indexing and searching. This makes it an ideal companion for CLI mail clients like <B>Mutt</B> or powerful text editors like <B>Emacs</B> (via <B>notmuch.el</B>). Its strength lies in its speed, flexible tagging, and powerful search query syntax, making email management efficient and intuitive for technical users.</i>


title: CAVEATS
content:
<i><b>notmuch</b> is solely an email indexer and search tool; it does not handle sending or receiving email itself. It fundamentally requires emails to be stored in the <B>Maildir</B> format. While highly optimized for speed, performance on extremely large databases (millions of emails) can still be influenced by underlying filesystem and disk I/O characteristics. Its primary interface is the command line, meaning a full email management experience usually requires integration with other tools or email clients.</i>


title: <I>TAGS VS. FOLDERS</I>
content:
<i>A core concept of <b>notmuch</b> is its reliance on a tagging system rather than traditional hierarchical folders. Emails are indexed from their filesystem location, and arbitrary tags are then applied to them. An email can have multiple tags (e.g., 'inbox', 'work', 'project-x', 'important'), allowing for far more flexible organization and retrieval than being confined to a single folder.</i>


title: <I>POWERFUL SEARCH SYNTAX</I>
content:
<i><b>notmuch</b> utilizes the powerful <B>Xapian</B> query language, enabling sophisticated searches. Users can combine terms with boolean operators (<B>AND</B>, <B>OR</B>, <B>NOT</B>), use wildcards (<B>*</B>), search within specific fields (e.g., <B>from:david</B>, <B>subject:report</B>), and filter by dates (e.g., <B>date:yesterday..today</B>, <B>date:3weeks..ago</B>). This allows for highly precise and rapid retrieval of messages across massive archives.</i>


title: <I>INTEGRATION AND FRONTENDS</I>
content:
<i>While <b>notmuch</b> provides a robust command-line interface, it is primarily designed to be a backend tool. It integrates seamlessly with various frontends and other email-related tools. Prominent integrations include <B>notmuch.el</B> for <B>Emacs</B>, various scripts for <B>Mutt</B>, and other community-developed applications like <B>nmapp</B> or <B>alot</B>. These frontends provide a user-friendly interface for interacting with the notmuch database and managing email.</i>


title: HISTORY
content:
<i><b>notmuch</b> was created by David Bremner, with its first public announcement and release dating back to 2010. Its development was driven by the growing need for a fast, efficient, and flexible way to search and manage large email archives, particularly those stored in the <B>Maildir</B> format. Traditional folder-based email organization often became cumbersome with large volumes, leading to the adoption of a tagging system. Written primarily in C and leveraging the <B>Xapian</B> search library for indexing, notmuch quickly gained popularity in the open-source community for its robust performance and extensibility.</i>


title: SEE ALSO
content:
<i>mutt(1)</i>, <i>emacs(1)</i>, <i>find(1)</i>, <i>grep(1)</i>, <i>procmail(1)</i>, <i>dovecot(1)</i>


title: SYNOPSIS
content:
<b>nova</b> [<i>global-options</i>] &lt;<i>subcommand</i>&gt; [<i>subcommand-options</i>] [<i>arguments</i>]<br><br><i>Examples:</i><br><b>nova</b> <i>list</i><br><b>nova</b> <i>boot</i> --<i>flavor</i> <i>m1.tiny</i> --<i>image</i> <i>ubuntu-18.04</i> --<i>key-name</i> <i>mykey</i> <i>my-instance</i><br><b>nova</b> <i>show</i> <i>&lt;instance_id&gt;</i>


title: PARAMETERS
content:
<b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show debug output for the command execution, useful for troubleshooting API calls.<br><br><b><b>--os-auth-url</b> <i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authentication URL for the OpenStack Identity service (Keystone). This is typically set via environment variables.<br><br><b><b>--os-username</b> <i>&lt;username&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Username for authenticating with the OpenStack cloud. Commonly set via environment variables.<br><br><b><b>--os-password</b> <i>&lt;password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Password for the specified username. Also frequently managed through environment variables.<br><br><b><b>--os-project-name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Project (formerly tenant) name for authentication. Usually sourced from an 'openrc' file or environment variables.<br><br><b><b>--os-region-name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the region to use, especially relevant in multi-region OpenStack deployments. Typically set via environment variables.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the program's version number and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message for the <b>nova</b> client itself, or for a specific subcommand if provided (e.g., <b>nova help boot</b>).<br><br>


title: DESCRIPTION
content:
The <b>nova</b> command is the legacy command-line interface (CLI) for interacting with OpenStack Compute, known as Nova. Nova is the core service responsible for provisioning and managing virtual machines (instances) within an OpenStack cloud environment. This powerful command allows cloud administrators and users to perform a wide range of operations, including launching new instances, listing available images and "flavors" (instance sizes), managing SSH keypairs for secure access, allocating floating IPs, and controlling security groups to define network access rules.<br><br>While the more recent <b>openstack</b> unified CLI is now the recommended tool for managing OpenStack services, the <b>nova</b> client remains widely used due to its specific focus on compute functionalities and familiarity among long-time OpenStack users. It provides a direct, scriptable way to automate cloud infrastructure management tasks, offering granular control over compute resources.


title: CAVEATS
content:
The <b>nova</b> client is a command-line interface tool and requires an operational OpenStack cloud environment to interact with. It heavily relies on proper authentication credentials, typically sourced from an 'openrc' file or environment variables (e.g., <b>OS_AUTH_URL</b>, <b>OS_USERNAME</b>). As a legacy client, its development has largely ceased in favor of the unified <b>openstack</b> client. Consequently, some newer Nova API features or functionalities might not be fully supported by the <b>nova</b> client and may necessitate the use of the <b>openstack</b> client or direct API calls. Installation often involves Python's package manager, <b>pip</b> (e.g., <i>pip install python-novaclient</i>).


title: ENVIRONMENT VARIABLES
content:
The <b>nova</b> command relies heavily on environment variables for configuration, particularly for authentication. Users typically source an 'openrc' file provided by their OpenStack cloud to set variables like <b>OS_AUTH_URL</b>, <b>OS_USERNAME</b>, <b>OS_PASSWORD</b>, <b>OS_PROJECT_NAME</b>, and <b>OS_REGION_NAME</b>. This streamlines authentication and allows commands to be executed without explicitly passing these parameters each time.


title: SUBCOMMANDS
content:
The functionality of the <b>nova</b> client is organized into various subcommands, each performing a specific set of operations. Common subcommands include <b>list</b> (to list instances), <b>boot</b> (to launch a new instance), <b>show</b> (to display details of an instance), <b>delete</b> (to terminate an instance), <b>flavor-list</b> (to list instance sizes), <b>image-list</b> (to list available images), and <b>keypair-list</b> (to list SSH keypairs). Users can get a full list of subcommands by running <b>nova help</b>.


title: HISTORY
content:
The <b>nova</b> client originated as part of the early development of OpenStack, specifically designed to interact with the Compute (Nova) service, which was one of the foundational components of the cloud platform. As OpenStack grew and diversified with numerous services, a need arose for a unified command-line interface. This led to the development of the <b>openstack</b> client, which aims to provide a single entry point for managing all OpenStack services.<br><br>While the <b>openstack</b> client is now the primary and recommended tool, the <b>nova</b> client persists due to its historical significance, established user base, and the fact that it still effectively performs its core compute management tasks. Its usage has shifted from primary interaction to more specialized or legacy scripting scenarios.


title: PARAMETERS
content:
<b>(None typically)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As <I>now</I> is usually a user-defined alias or a simple script, it typically does not define its own unique parameters. If implemented as <I>alias now='date'</I>, then it effectively inherits all parameters of the <I>date</I> command. However, the conceptual <I>now</I> command is designed for simplicity and immediate feedback, often used without needing additional arguments or complex formatting options of its own.<br><br>


title: DESCRIPTION
content:
<I>now</I> is not a standard, standalone Linux command explicitly shipped with typical operating system distributions' core utilities. Instead, it represents a commonly adopted informal convention, predominantly implemented by individual users as a convenient shell alias or a very simple custom script. Its primary purpose is to provide a quick and immediate output of the current system date and time. It serves as a practical shortcut for more verbose commands like <I>date</I>, enabling users to instantly retrieve 'what time is it now?' information.<br><br>This user-defined utility enhances command-line efficiency, offering a streamlined way to get current timestamp data for various purposes, including simple logging, quick checks, or integrating into custom shell scripts where brevity is desired. Its widespread informal adoption highlights the flexibility and customization capabilities inherent in Linux shell environments, allowing users to tailor their workflow for maximum productivity.


title: CAVEATS
content:
<b>Non-Standard:</b> <I>now</I> is not a built-in or standard command across Linux distributions. Its availability and behavior depend entirely on whether a user has defined it in their shell configuration (e.g., in <I>.bashrc</I> or <I>.zshrc</I>).<br><b>Implementation Varies:</b> Its exact functionality and output can differ significantly based on how it's implemented (e.g., a simple <I>date</I> wrapper, a custom script with specific formatting, or even a different command altogether).<br><b>Potential for Conflicts:</b> If an application or system utility defines a command named <I>now</I>, it could conflict with a user's alias or script, leading to unexpected behavior.


title: COMMON IMPLEMENTATIONS
content:
The most frequent way to implement a <I>now</I> command is through a shell alias in a user's shell configuration file, such as <I>.bashrc</I> (for Bash) or <I>.zshrc</I> (for Zsh). Examples include:<br><code>alias now='date +%T'</code><br>This alias makes <I>now</I> print only the current time (e.g., <I>14:30:55</I>).<br>Another common implementation for full date and time:<br><code>alias now='date'</code><br>This allows users to simply type <I>now</I> in their terminal to get the default <I>date</I> command output. More complex scripts might be used for custom formatting or additional information, but the alias is most prevalent for quick time checks.


title: HISTORY
content:
The concept of a <I>now</I> command emerged from the user community's desire for a very quick and memorable way to get the current time without typing the full <I>date</I> command or specific formatting options. It's a testament to the flexibility of shell environments, allowing users to create personalized shortcuts. Its 'development' isn't formal but rather an organic spread of a useful shell alias or simple script practice, adopted by many for personal productivity and convenience over time, becoming a common informal utility.


title: PARAMETERS
content:
<b><i>--tcp</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate TCP packets. Allows setting TCP flags, sequence numbers, and options.<br><br><b><i>--udp</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate UDP packets. Can specify source and destination ports.<br><br><b><i>--icmp</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate ICMP packets. Supports various ICMP types (echo request, timestamp, etc.).<br><br><b><i>--arp</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate ARP requests or replies. Useful for network discovery and spoofing.<br><br><b><i>--eth</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate raw Ethernet frames. Provides the lowest level of control.<br><br><b><i>-c &lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop after sending <i>&lt;count&gt;</i> packets.<br><br><b><i>-p &lt;port&gt;</i>, <i>--dest-port &lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the destination port for TCP or UDP packets.<br><br><b><i>--source-port &lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the source port for TCP or UDP packets.<br><br><b><i>--data &lt;hex string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append a custom hexadecimal string as raw data payload to packets.<br><br><b><i>--data-string &lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append an ASCII string as raw data payload to packets.<br><br><b><i>--ttl &lt;ttl&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the IP Time-to-Live field for outgoing packets.<br><br><b><i>--rate &lt;rate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send packets at a specified rate (e.g., <i>100/s</i> for 100 packets per second, <i>1k/s</i>, <i>10m</i> for 10 minutes duration).<br><br><b><i>--delay &lt;time&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait the specified <i>&lt;time&gt;</i> (e.g., <i>500ms</i>, <i>1s</i>) between sending packets.<br><br><b><i>--privileged</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run with escalated privileges (e.g., to craft arbitrary IP headers or use raw sockets). This is often required for advanced packet crafting.<br><br><b><i>--echo-client</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in echo client mode, sending probes to an <b>nping</b> echo server and measuring response times.<br><br><b><i>--echo-server</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in echo server mode, listening for and responding to <b>nping</b> echo clients.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity level. Use <i>-vv</i> for even more details about packets sent and received.<br><br><b><i>-S &lt;IP&gt;</i>, <i>--source-ip &lt;IP&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the source IP address for outgoing packets. Requires privileges.<br><br>


title: DESCRIPTION
content:
<b>nping</b> is a versatile open-source command-line utility, part of the Nmap suite, designed for generating and analyzing network packets. It allows users to craft custom packets across various protocols, including TCP, UDP, ICMP, and ARP, with granular control over header fields and data payloads.<br><br><b>nping</b> can be used for network stack stress testing, firewall rule verification, network performance measurement (latency, jitter), and security auditing. Beyond simple packet generation, <b>nping</b> can also measure response times, act as an echo client or server, and even simulate denial-of-service attacks by controlling packet rates and counts. Its flexibility makes it an invaluable tool for network administrators, security professionals, and developers alike, offering capabilities far beyond a traditional <b>ping</b> utility.


title: CAVEATS
content:
<b>nping</b> often requires root or administrator privileges to perform raw socket operations, such as crafting custom IP, TCP, UDP, ICMP, ARP, or Ethernet headers. <br><br>Misuse of <b>nping</b> can generate high volumes of traffic, potentially disrupting network services or violating network usage policies. Users should exercise caution and ensure they have proper authorization before using it on any network.


title: ECHO MODE
content:
<b>nping</b> includes a unique 'echo mode' that allows it to function as both a client and a server. This enables accurate measurement of network latency and jitter between two points, providing more detailed insights than a standard <b>ping</b> by supporting various protocols (TCP, UDP, ICMP) and custom payloads. It's ideal for precise network performance diagnostics.


title: EXTENSIVE PROTOCOL SUPPORT
content:
Beyond basic ICMP, <b>nping</b> offers comprehensive support for crafting packets across multiple network layers. This includes: <br><ul><li><i>ARP</i> (Address Resolution Protocol)</li><li><i>Ethernet</i> (raw frames)</li><li><i>IP</i> (with options for fragmentation, source routing, custom IDs)</li><li><i>ICMP</i> (various types and codes)</li><li><i>TCP</i> (with fine-grained control over flags like SYN, ACK, RST, FIN; sequence numbers; window size; and options like MSS, Window Scale, SACK)</li><li><i>UDP</i> (with custom source/destination ports and data).</li></ul> This deep control makes it invaluable for specific protocol testing and analysis.


title: HISTORY
content:
<b>nping</b> was developed by the Nmap Project and first publicly released as part of Nmap 5.00 in July 2009. It was conceived to address the need for a highly flexible and powerful packet generator and response analyzer, going beyond the capabilities of traditional tools like <b>ping</b> and even <b>hping3</b>, while seamlessly integrating with the Nmap ecosystem. Its development aimed to provide network professionals with precise control over network traffic for testing, troubleshooting, and security assessments.


title: SYNOPSIS
content:
<b>npm</b> <i>[command]</i> <i>[options]</i> <i>[arguments]</i><br><br>Examples:<br><i>npm</i> <b>install</b> <i>[package-name]</i><br><i>npm</i> <b>run</b> <i>[script-name]</i><br><i>npm</i> <b>init</b><br><i>npm</i> <b>publish</b><br><i>npm</i> <b>help</b> <i>[command]</i>


title: PARAMETERS
content:
<b><i>npm</i> primarily operates via subcommands, each with its own specific set of options and arguments. The following are common <b>global</b> options that can often be applied to most <i>npm</i> commands:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <i>npm</i> version and exits.<br><br><b><b>--help</b> <i>[command]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <i>npm</i> or a specific <i>npm</i> command.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs data in <i>JSON</i> format.<br><br><b><b>--global</b>, <b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in 'global' mode, installing packages into the <i>npm</i> installation directory rather than the current project.<br><br><b><b>--loglevel</b> <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level (e.g., <i>silent</i>, <i>error</i>, <i>warn</i>, <i>info</i>, <i>verbose</i>, <i>silly</i>).<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would happen without actually making any changes.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>npm</i> to do something it otherwise might not do.<br><br><b><b>--yes</b>, <b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answers 'yes' to prompts.<br><br><b><b>--prefix</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The location to install global packages or to find configuration files.<br><br><b><b>--audit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a security audit, typically when installing packages.<br><br><b><b>--save-dev</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Package will appear in your <i>devDependencies</i>. Only relevant for <i>npm install</i>.<br><br><b><b>--save-optional</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Package will appear in your <i>optionalDependencies</i>. Only relevant for <i>npm install</i>.<br><br><b><b>--no-save</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents saving the package to <i>dependencies</i> in <i>package.json</i>. Only relevant for <i>npm install</i>.<br><br>


title: DESCRIPTION
content:
<i>npm</i>, short for <b>Node Package Manager</b>, is the default package manager for the JavaScript runtime environment Node.js. It's a fundamental tool for developers working with Node.js, enabling them to install, manage, and publish reusable pieces of code known as "packages" or "modules."<br><br>At its core, <i>npm</i> facilitates interaction with the <b>npm registry</b>, a vast online database of open-source JavaScript projects. Developers use <i>npm</i> to download and install packages required by their projects, manage project dependencies defined in a <i>package.json</i> file, and execute scripts defined within that file. It also provides a way to publish new packages, contributing to the ever-growing JavaScript ecosystem.<br><br><i>npm</i> plays a crucial role in modern web development, simplifying dependency management for front-end frameworks (like React, Angular, Vue), back-end services (with Express.js), and various developer tools. Its ability to handle complex dependency trees and automate common tasks makes it an indispensable tool for building scalable and maintainable JavaScript applications.


title: CAVEATS
content:
<b>Disk Space Usage:</b> <i>npm</i> installations, especially with deep dependency trees, can consume significant disk space in the <i>node_modules</i> directory. This can be a concern for projects with many dependencies.<br><br><b>Dependency Conflicts:</b> Resolving complex dependency graphs can sometimes lead to version conflicts or "dependency hell" where different packages require incompatible versions of the same dependency.<br><br><b>Security Concerns:</b> While the <i>npm</i> registry is vast, vigilance is required. Malicious or poorly maintained packages can pose security risks, making it crucial to audit dependencies (e.g., using <i>npm audit</i>).<br><br><b>Network Dependence:</b> Most <i>npm</i> operations require an internet connection to access the <i>npm</i> registry, though local caches can mitigate some offline usage.


title: <B>THE <I>PACKAGE.JSON</I> FILE</B>
content:
This file is central to every <i>npm</i> project. It stores metadata about the project (name, version, description) and, critically, lists all project dependencies (<i>dependencies</i>, <i>devDependencies</i>, etc.) and defines scripts that can be run using <i>npm run</i>.


title: <B>THE <I>NODE_MODULES</I> DIRECTORY</B>
content:
When you run <i>npm install</i>, all project dependencies are downloaded and placed into this directory within your project's root. This directory can become very large due to transitive dependencies.


title: <B><I>NPM</I> REGISTRY</B>
content:
The official public <i>npm</i> registry is a vast online database of open-source JavaScript packages. It serves as the primary source for downloading packages and for publishing your own reusable modules to the community.


title: <B>COMMON <I>NPM</I> COMMANDS</B>
content:
Beyond installing packages, <i>npm</i> offers numerous commands:<br> - <i><b>install</b></i>: Installs packages and dependencies.<br> - <i><b>run</b></i>: Executes predefined scripts from <i>package.json</i>.<br> - <i><b>init</b></i>: Creates a new <i>package.json</i> file.<br> - <i><b>publish</b></i>: Publishes a package to the <i>npm</i> registry.<br> - <i><b>update</b></i>: Updates packages to their latest compatible versions.<br> - <i><b>test</b></i>: Runs tests defined in <i>package.json</i>.


title: HISTORY
content:
<i>npm</i> was initially created by <b>Isaac Schlueter</b> and first released in <b>January 2010</b>. It quickly became the de facto standard package manager for Node.js, growing alongside the Node.js ecosystem itself. Its development was driven by the need for a robust system to manage the reusable modules that were emerging in the burgeoning JavaScript server-side environment. In 2020, <i>npm, Inc.</i>, the company behind <i>npm</i>, was acquired by <b>GitHub</b> (a subsidiary of Microsoft). This acquisition aimed to ensure the long-term viability and continued development of the <i>npm</i> registry and client, which are critical infrastructure for the global JavaScript community. The project has seen continuous improvements in performance, security, and features, including the introduction of workspaces and improved audit capabilities.


title: SYNOPSIS
content:
<b>npm access</b> <i>&lt;subcommand&gt;</i> [options]<br><br><b>Subcommands:</b><br>  <b>npm access public</b> <i>&lt;package-name&gt;</i><br>  <b>npm access restricted</b> <i>&lt;package-name&gt;</i><br>  <b>npm access grant</b> <i>&lt;read|write&gt; &lt;scope:team|user&gt; &lt;package-name&gt;</i><br>  <b>npm access revoke</b> <i>&lt;read|write&gt; &lt;scope:team|user&gt; &lt;package-name&gt;</i><br>  <b>npm access ls-packages</b> [<i>&lt;user&gt;|&lt;scope:team&gt;</i>]<br>  <b>npm access ls-collaborators</b> <i>&lt;package-name&gt;</i> [<i>&lt;user&gt;</i>]


title: PARAMETERS
content:
<b><b>public</b> <i>&lt;package-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes a package publicly visible and installable by anyone. This is often the default for new packages unless configured otherwise.<br><br><b><b>restricted</b> <i>&lt;package-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricts access to a package, making it private. Only users or teams explicitly granted access can view or install it. This is commonly used for private modules in organizations.<br><br><b><b>grant</b> <i>&lt;read|write&gt; &lt;scope:team|user&gt; &lt;package-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Grants either <i>read</i> or <i>write</i> access to a specific user or an npm team for a given package. <i>Read</i> access allows viewing and installing; <i>write</i> access allows publishing and modifying the package.<br><br><b><b>revoke</b> <i>&lt;read|write&gt; &lt;scope:team|user&gt; &lt;package-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Revokes previously granted <i>read</i> or <i>write</i> access from a user or npm team for a package.<br><br><b><b>ls-packages</b> [<i>&lt;user&gt;|&lt;scope:team&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages that a specified user or team has access to. If no user or team is specified, it lists packages the current logged-in user has access to.<br><br><b><b>ls-collaborators</b> <i>&lt;package-name&gt;</i> [<i>&lt;user&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all collaborators (users and teams) on a specific package, along with their respective access levels (<i>read</i> or <i>write</i>). Optionally, if a user is specified, it shows only their access level to that package.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the command results in JSON format, which is useful for programmatic consumption and scripting.<br><br><b><b>--otp</b> <i>&lt;one-time-password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a one-time password for commands that require two-factor authentication (2FA).<br><br><b><b>--registry</b> <i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative npm registry URL to use for the command, overriding the default configured registry.<br><br>


title: DESCRIPTION
content:
The <b>npm access</b> command is a powerful tool within the npm ecosystem for controlling the visibility and permissions of packages published to the npm registry. It enables package maintainers to define who can read, publish, or modify their packages.<br><br>Through various subcommands, <b>npm access</b> allows you to:<br><i>public</i> or <i>restrict</i> a package's general visibility.<br><i>grant</i> or <i>revoke</i> specific <i>read</i> or <i>write</i> access to individual users or npm teams.<br><i>list packages</i> that a user or team has access to, or <i>list collaborators</i> on a specific package.<br><br>This granularity is crucial for managing both public open-source projects and private organizational modules, ensuring secure collaboration and proper distribution control.


title: CAVEATS
content:
You must be logged into the npm registry (e.g., using <b>npm adduser</b> or <b>npm login</b>) to use <b>npm access</b> commands that modify permissions.<br><br>To modify a package's access, you must be a maintainer (owner) of that package or part of an npm team with <i>write</i> access to it.<br><br>Using the <b>grant</b> or <b>revoke</b> commands with teams (e.g., <i>&lt;scope:team&gt;</i>) requires the team to be part of an npm organization.<br><br>Packages set to <b>restricted</b> are considered private and may incur associated costs or limitations based on your npm plan.


title: ACCESS LEVELS: READ VS. WRITE
content:
<b>npm access</b> distinguishes between two primary access levels: <i>read</i> and <i>write</i>.<br><i>Read</i> access permits users or teams to view package metadata and install the package. This is the minimum required to consume a private package.<br><i>Write</i> access grants the ability to publish new versions, modify package metadata, and manage collaborators (including using <b>npm access</b> to change permissions). Only users or teams with <i>write</i> access can maintain a package.


title: ORGANIZATIONS AND TEAMS
content:
<b>npm access</b> leverages npm's organization and team features for managing access at scale. An npm organization can contain multiple teams, and users can be members of multiple teams. By granting or revoking access to a team (e.g., `<i>@myorg:developers</i>`), all members of that team automatically inherit or lose the specified access to the package. This simplifies permission management for large projects and companies.


title: HISTORY
content:
The <b>npm access</b> command was introduced to provide more granular and flexible control over package permissions, building upon the capabilities of the older <b>npm owner</b> command. Its development coincided with the growth of npm organizations and the increasing need for private modules and collaborative team management within npm. It solidified the ability to manage <i>read</i> and <i>write</i> access for both individual users and structured npm teams, making it a cornerstone for enterprise and team-based npm workflows.


title: SYNOPSIS
content:
<b>npm adduser</b> [<b>--registry</b> <i>&lt;url&gt;</i>] [<b>--scope</b> <i>&lt;scope&gt;</i>] [<b>--auth-type</b> <i>&lt;type&gt;</i>]


title: PARAMETERS
content:
<b><b>--registry</b> <i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the npm registry to use for this operation. If not specified, npm uses the default registry configured in <i>.npmrc</i> or the public npm registry.<br><br><b><b>--scope</b> <i>&lt;scope&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associates the user credentials with a specific scope. This is useful when you need to authenticate against a private registry for packages under a particular scope (e.g., <i>@myscope:registry=https://private.registry.com</i>).<br><br><b><b>--auth-type</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the authentication method. Possible values include <i>always</i> (sends basic auth on every request), <i>web</i> (opens a browser for login), and <i>legacy</i> (the default interactive prompt, using username/password). <i>web</i> is often used for two-factor authentication or SSO workflows.<br><br>


title: DESCRIPTION
content:
The <i>npm adduser</i> command is used to either create a new user account on the configured npm registry or to log in an existing user. When executed, it interactively prompts the user for a username, password, and email address. These credentials are then used to authenticate with the registry. Once successfully logged in, npm stores an authentication token or credentials in the user's <i>~/.npmrc</i> configuration file. This allows subsequent commands like <i>npm publish</i> to securely interact with the registry without requiring re-authentication.<br><br>It's a fundamental command for package maintainers and anyone needing to publish packages to npm or a private registry. The command is essentially an alias for <i>npm login</i>, which is often preferred for its clearer intent.


title: CAVEATS
content:
The command requires an active internet connection to communicate with the npm registry. While credentials are typically transmitted over HTTPS, the overall security depends on the registry's implementation. For automation, <i>npm adduser</i> is interactive and not easily scriptable without tools like <i>expect</i>.<br><br>For better security, consider using API tokens instead of username/password, and ensure your <i>.npmrc</i> file permissions are restrictive to prevent unauthorized access to stored credentials.


title: <I>CONFIGURATION AND .NPMRC</I>
content:
Upon successful authentication, <i>npm adduser</i> modifies the user's <i>~/.npmrc</i> file (or a specified <i>.npmrc</i> if <i>--userconfig</i> is used). It typically adds an authentication token (e.g., <i>//registry.npmjs.org/:_authToken="YOUR_TOKEN"</i>) or username/password entries for the specified registry. This token is then automatically included in headers for subsequent authenticated requests to that registry. Understanding this file is key for managing npm's behavior and credentials.


title: <I>SECURITY CONSIDERATIONS</I>
content:
When using <i>npm adduser</i>, especially with the default interactive prompt, credentials are exchanged. For public npm, token-based authentication is preferred over username/password. Users should be aware that the <i>.npmrc</i> file stores these tokens. Protecting this file with appropriate file system permissions (e.g., <i>chmod 600 ~/.npmrc</i>) is critical to prevent unauthorized access to your npm account. Using environment variables for sensitive data (e.g., <i>NPM_TOKEN</i>) or credential helpers can further enhance security, especially in CI/CD environments.


title: HISTORY
content:
<i>npm adduser</i> has been a core command since the early days of npm, providing the initial mechanism for users to authenticate and publish packages. Over time, its functionality has evolved to support various authentication methods, including the transition from simple username/password basic authentication to more secure token-based authentication.<br><br>The introduction of <i>npm login</i> as an alias aimed to clarify the command's primary purpose of logging in, rather than exclusively adding new users, as existing users also use it to authenticate. It remains crucial for the decentralized package ecosystem enabled by npm.


title: DESCRIPTION
content:
The <B>npm-author</B> command, as a standalone executable or direct <I>npm</I> subcommand, <I>does not exist</I> within the standard npm CLI. Instead, author-related functionalities and information are managed through various other mechanisms and commands in the npm ecosystem.<br><br>This primarily includes the <B>author</B> field in a project's <I>package.json</I> file, which serves as metadata about the primary developer. For managing actual ownership and publishing permissions of a package on the npm registry, the <B>npm owner</B> command is used. Additionally, user accounts on the npm registry, which are necessary for anyone to publish packages or become an owner, are created and managed via the <B>npm adduser</B> command.<br><br>Therefore, while the concept of an 'npm author' is central to package development and distribution, it is facilitated by a combination of file metadata and specific <I>npm</I> registry interaction commands, rather than a single <I>npm-author</I> command.


title: CAVEATS
content:
The command <B>npm-author</B> is <B>not a recognized command</B> in the npm CLI. Users attempting to manage package authors or owners should refer to the documentation for <B>npm owner</B> (for registry-level package ownership) or the <B>author</B> and <B>contributors</B> fields within the <I>package.json</I> file (for package metadata). Creating a new npm user account is done via <B>npm adduser</B>.


title: THE 'AUTHOR' FIELD IN PACKAGE.JSON
content:
The <B>author</B> field in a project's <I>package.json</I> file is a metadata field that describes the primary developer or organization responsible for the package. It typically contains a string in the format <I>"Name &lt;email&gt; (url)"</I> or an object with <I>name</I>, <I>email</I>, and <I>url</I> properties. This field is for informational purposes and does not directly control publishing permissions. The <B>contributors</B> field is similar but allows for an array of multiple individuals.


title: MANAGING PACKAGE OWNERS WITH NPM OWNER
content:
The <B>npm owner</B> command is used to manage the list of users who have publishing access to a specific package on the npm registry. It provides subcommands like: <B>npm owner add &lt;user&gt; [&lt;package&gt;]</B> to grant publishing rights; <B>npm owner rm &lt;user&gt; [&lt;package&gt;]</B> to revoke rights; and <B>npm owner ls [&lt;package&gt;]</B> to list current owners. These commands are crucial for collaborative package development and maintenance, allowing teams to share control over publishing.


title: CREATING NPM USER ACCOUNTS WITH NPM ADDUSER
content:
Before a user can be added as an owner of a package or publish a package themselves, they must have an account on the npm registry. The <B>npm adduser</B> command (also aliased as <B>npm login</B>) facilitates this process by prompting the user for a username, password, and email address, thereby creating or authenticating their npm account. This command is a prerequisite for any user-specific actions on the npm registry, including becoming a package author or owner.


title: HISTORY
content:
Historically, author information for npm packages was primarily managed via the <B>author</B> field in <I>package.json</I>, a simple metadata entry. As npm grew, the need for finer-grained control over package publishing permissions arose, leading to the introduction of the <B>npm owner</B> command. This command allows multiple users to be designated as 'owners' of a package on the npm registry, granting them publishing rights. The concept of an 'author' evolved from a complex system involving registry-level permissions and user accounts, all without the need for a specific <I>npm-author</I> command.


title: PARAMETERS
content:
<b>[<I>package-spec</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional identifier for the package whose bug tracker URL should be opened. This can be a package name (e.g., <I>react</I>), a package name with a version or tag (e.g., <I>lodash@4</I>, <I>vue@next</I>), or a path to a package directory. If omitted, <b>npm bugs</b> defaults to the package in the current working directory.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the bug tracker URL in JSON format to standard output instead of opening it in a web browser. This is useful for programmatic access or scripting.<br><br><b>--registry <I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base URL of the npm registry to use when resolving package information.<br><br><b>--workspace <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command within a specific workspace. Applicable when working with npm workspaces (monorepos).<br><br><b>--workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command for all configured workspaces within the current project, opening a bug tracker for each. Excludes the root project unless <I>--include-workspace-root</I> is also specified.<br><br><b>--include-workspace-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <I>--workspaces</I>, ensures that the root project's bug tracker is also considered and opened.<br><br>


title: DESCRIPTION
content:
The <b>npm bugs</b> command is a utility within the Node Package Manager (<I>npm</I>) that allows users to quickly access the bug tracker or issue reporting page associated with a specific package.<br><br>When invoked without a package name, it attempts to open the bug tracker for the package in the current working directory, inferring the package from the <I>package.json</I> file. If a <I>package-spec</I> (e.g., <I>package@version</I>) is provided, <b>npm bugs</b> will look up that package in the npm registry and retrieve its bug tracker URL. This URL is typically found in the <I>bugs</I> field of the package's <I>package.json</I> metadata.<br><br>The command then attempts to open this URL using your system's default web browser. This streamlines the process of reporting issues or checking known bugs for dependencies or your own projects, without manually searching for the bug tracker link. It's a convenient shortcut for developers and users to engage with package maintainers regarding defects or feature requests.


title: CAVEATS
content:
The command relies on the <I>bugs</I> field being present and correctly configured in the package's <I>package.json</I> file or its metadata in the npm registry. If this field is missing or malformed, <b>npm bugs</b> may fail to open a URL or open an incorrect one.<br><br>It requires a graphical environment and a default web browser configured on the system to open the URL automatically. In headless environments, the <I>--json</I> option should be used to retrieve the URL programmatically.


title: DEFAULT BROWSER
content:
<b>npm bugs</b> uses the system's default command for opening URLs (e.g., <I>xdg-open</I> on Linux, <I>open</I> on macOS, <I>start</I> on Windows). Ensure your system is configured to open URLs with your preferred web browser.


title: NO URL FOUND
content:
If a package's <I>package.json</I> or registry metadata does not contain a <I>bugs</I> field, or if the field is empty, <b>npm bugs</b> will report an error indicating that no bug tracker URL could be found for the specified package.


title: HISTORY
content:
<b>npm bugs</b> is an integral part of the <b>npm</b> CLI, which was first released in January 2010. Its inclusion reflects the <b>npm</b> project's goal of simplifying common developer workflows, such as quickly accessing package resources like documentation, repositories, and bug trackers. As <b>npm</b> evolved into the dominant package manager for Node.js, commands like <b>npm bugs</b> became standard utilities, providing immediate access to community support and issue reporting mechanisms, contributing to the health and maintainability of the vast npm ecosystem.


title: SYNOPSIS
content:
<pre>npm cache add &lt;tarball-file | tarball-url | package-spec&gt;<br>npm cache clean [--force]<br>npm cache ls [&lt;pkg-spec&gt;]<br>npm cache verify<br>npm cache rm &lt;key&gt;...</pre>


title: PARAMETERS
content:
<b>add <tarball-file | tarball-url | package-spec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a package directly to the cache. This can be a local tarball file, a URL to a tarball, or a standard package specification (e.g., <b>lodash@latest</b>).<br><br><b>clean [--force]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes all or specific data from the cache. Since npm v5, <b>clean</b> requires the <b>--force</b> flag by default to prevent accidental cache clearing, as the cache is typically self-managing.<br><br><b>ls [<pkg-spec>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the contents of the cache. If a <b>pkg-spec</b> is provided, it lists only entries related to that package.<br><br><b>verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the integrity of the cache contents. It prunes out invalid or corrupted entries and ensures all data is accounted for, repairing the cache as needed.<br><br><b>rm <key>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>npm cache clean</b>, which also requires <b>--force</b> for full cache clearing.<br><br>


title: DESCRIPTION
content:
<i>npm cache</i> provides subcommands to interact with npm's internal cache. This cache stores downloaded package tarballs and metadata, significantly speeding up subsequent installations of the same packages and enabling offline installations. It's designed to be robust and self-healing. The cache uses a content-addressable storage model, meaning that each piece of data is stored based on a cryptographic hash of its content, preventing data corruption and ensuring integrity.


title: CAVEATS
content:
<ul><li><b>Disk Space</b>: The cache can consume a significant amount of disk space over time, especially with many projects and dependencies.</li><li><b><code>--force</code> for <code>clean</code></b>: Users accustomed to older npm versions might forget the mandatory <b>--force</b> flag for <b>npm cache clean</b> (since npm v5), leading to unexpected behavior (command doing nothing).</li><li><b>Transparency</b>: While robust, directly manipulating the cache is generally not recommended unless you understand its internal structure, as it's designed to be self-managing.</li></ul>


title: CACHE LOCATION
content:
The default cache directory is platform-specific but can be found by running <b>npm config get cache</b>. Typically, it's located in <b>~/.npm/_cacache</b> on Unix-like systems.


title: PURPOSE OF CACHE
content:
The primary goals of the npm cache are to accelerate package installations by reusing downloaded tarballs and to enable offline installation of packages that have been previously cached.


title: HISTORY
content:
Prior to npm v5, the cache was a simpler, less robust system that could occasionally get corrupted, necessitating frequent <b>npm cache clean</b> operations.<br>With the release of npm v5 (May 2017), the caching mechanism was completely rewritten using <b>cacache</b>. This new system introduced content-addressable storage, self-healing capabilities, and better integrity checks, making the cache much more reliable and reducing the need for manual cleaning.


title: PARAMETERS
content:
<b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively update outdated packages.<br><br><b>-s, --skip-unused</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check for unused packages.<br><br><b>-i, --skip-incompatible</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check for incompatible package versions.<br><br><b>-g, --global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check global packages instead of local project dependencies.<br><br><b>-E, --save-exact</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When updating, save the exact version number (no caret or tilde).<br><br><b>-p, --production</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only production dependencies, skipping development dependencies.<br><br><b>-D, --dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check only development dependencies, skipping production dependencies.<br><br><b>-y, --yarn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <i>npm-check</i> to use Yarn for package operations.<br><br><b>--clear-cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear <i>npm-check</i>'s internal cache.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format instead of the interactive CLI.<br><br><b>--ignore-dev-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip checking 'dev-only' packages that are unused when the production flag is used.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of <i>npm-check</i>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for <i>npm-check</i>.<br><br>


title: DESCRIPTION
content:
<i>npm-check</i> is a command-line tool designed to help developers manage Node.js project dependencies efficiently. It scans the <b>package.json</b> file and the <b>node_modules</b> directory to identify several issues: outdated dependencies, packages that are listed but not used, packages that are used but not listed, and even incorrect versions. It presents the information in a clear, color-coded, interactive interface, making it easy to see which packages need attention. A significant feature is its ability to interactively update outdated packages, allowing users to select which ones to upgrade. This tool enhances project maintainability and reduces dependency-related issues, ensuring a healthy and up-to-date project environment.


title: CAVEATS
content:
Requires Node.js and either npm or Yarn to be installed.<br>May not perfectly detect all 'unused' packages in complex applications with dynamic imports.<br>Interactive update mode can be slow for projects with a large number of dependencies.<br>This is a third-party tool, not part of the core npm CLI.


title: INTERACTIVITY
content:
<i>npm-check</i> is renowned for its interactive command-line interface, which allows users to navigate and select packages for updates directly within the terminal, providing a highly engaging user experience.


title: COLOR-CODED OUTPUT
content:
The tool utilizes different colors to highlight the status of dependencies (e.g., <b>green</b> for up-to-date, <b>yellow</b> for minor updates, <b>red</b> for major updates or issues), significantly improving readability and enabling quick identification of problems.


title: HISTORY
content:
<i>npm-check</i> was created to provide a more comprehensive and user-friendly alternative to the native <i>npm outdated</i> command. Its interactive interface and ability to check for unused and incompatible packages differentiate it. It is an open-source project that has seen continuous development by its community since its inception.


title: PARAMETERS
content:
<b><b>--prefix</b> &lt;<i>path</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory to resolve relative paths for when looking up <i>package.json</i> and <i>node_modules</i>. Often used to specify an alternate installation location.<br><br><b><b>--production</b><br><b>--omit=dev</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install only production dependencies. Development dependencies are skipped.<br><br><b><b>--no-optional</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent optional dependencies from being installed.<br><br><b><b>--ignore-scripts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not run <i>pre/post</i> install scripts defined in <i>package.json</i>. This can be useful for security or to speed up installations.<br><br><b><b>--loglevel</b> &lt;<i>level</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the level of logging messages to display. Common levels include <i>silent</i>, <i>error</i>, <i>warn</i>, <i>info</i>, <i>http</i>, <i>verbose</i>, <i>silly</i>.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output raw JSON data for machine readability, especially useful for programmatic consumption of command results.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the installation without actually making any changes to the file system. Shows what <i>npm ci</i> would do.<br><br><b><b>--registry</b> &lt;<i>url</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom npm registry URL to fetch packages from.<br><br><b><b>--legacy-peer-deps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permit the installation to proceed even if peer dependency conflicts are found. This can help bypass strict peer dependency checks that might otherwise block installations.<br><br>


title: DESCRIPTION
content:
<i>npm ci</i> is explicitly designed for automated environments like Continuous Integration/Continuous Deployment (CI/CD) pipelines. It ensures that a project's dependencies are installed exactly as defined in the <i>package-lock.json</i> or <i>npm-shrinkwrap.json</i> file. Unlike <i>npm install</i>, <i>npm ci</i> will first remove any existing <i>node_modules</i> directory before performing a fresh, clean installation. This guarantees a consistent and reproducible dependency state across different environments and runs, preventing partial updates or unintended dependency upgrades.<br><br>It is generally faster than <i>npm install</i> in CI scenarios because it skips dependency resolution and directly installs from the lock file. It prioritizes strict adherence to the lock file, making it ideal for build processes where exact dependency versions are critical for reliability.


title: CAVEATS
content:
Requires a <i>package-lock.json</i> or <i>npm-shrinkwrap.json</i> file to be present in the project root.<br>The <i>package-lock.json</i> must be consistent with <i>package.json</i>. If discrepancies are found (e.g., a dependency in <i>package.json</i> is not in the lock file), <i>npm ci</i> will fail.<br><i>npm ci</i> will always delete the existing <i>node_modules</i> directory before installing, ensuring a clean slate. This means any local changes or uncommitted modules in <i>node_modules</i> will be lost.<br>It will never modify <i>package.json</i> or <i>package-lock.json</i>.


title: ERROR HANDLING
content:
<i>npm ci</i> is designed to fail explicitly if a <i>package-lock.json</i> is missing or if it's out of sync with <i>package.json</i>. This strict behavior provides immediate feedback on potential dependency inconsistencies, aiding in debugging and maintaining project integrity.


title: PERFORMANCE
content:
In many CI scenarios, <i>npm ci</i> is significantly faster than <i>npm install</i>. This is because it skips the dependency resolution phase (as it trusts the lock file entirely) and directly installs packages, leading to quicker build times.


title: HISTORY
content:
<i>npm ci</i> was introduced in <b>npm v5.7.0</b> in January 2018. Its development was driven by the need for a more deterministic, reliable, and faster installation method specifically tailored for automated build and deployment environments (CI/CD). Prior to <i>npm ci</i>, <i>npm install</i> was often used, but its behavior of potentially modifying <i>package-lock.json</i> or being less strict about exact versions could lead to inconsistencies across different build runs. <i>npm ci</i> provides a strict contract, ensuring exact reproducibility.


title: SYNOPSIS
content:
<I>npm config set <key> <value> [<options>]</I><br><I>npm config get <key> [<options>]</I><br><I>npm config delete <key> [<options>]</I><br><I>npm config list [<options>]</I><br><I>npm config edit [<options>]</I><br><I>npm config fix [<options>]</I>


title: PARAMETERS
content:
<b>--global, -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the global configuration file (<I>$PREFIX/etc/npmrc</I>) instead of the user configuration file (<I>~/.npmrc</I>).<br><br><b>--location <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which configuration file level ('project', 'user', or 'global') to modify or query. This option overrides the <I>--global</I> flag.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <I>npm config list</I> to display all configuration values in full, including default values.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <I>npm config list</I> to output configuration values in JSON format.<br><br><b>--editor <editor></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the executable to use as an editor when <I>npm config edit</I> is run. Overrides <I>EDITOR</I> or <I>VISUAL</I> environment variables.<br><br><b>--userconfig <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the user's npm configuration file. Overrides the default user config path (<I>~/.npmrc</I>).<br><br><b>--globalconfig <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the global npm configuration file. Overrides the default global config path (<I>$PREFIX/etc/npmrc</I>).<br><br>


title: DESCRIPTION
content:
The <I>npm config</I> command allows users to get, set, delete, and list the npm configuration values. These configurations control various aspects of npm's behavior, such as proxy settings, registry URL, package installation locations, and more. <br> <br> Configuration settings can exist at multiple levels: project-specific (<I>./.npmrc</I>), user-specific (<I>~/.npmrc</I>), global (<I>$PREFIX/etc/npmrc</I>), and built-in defaults. When a configuration value is requested, npm resolves it based on this hierarchy, with project-level settings overriding user-level, and user-level overriding global and built-in. <br> <br> This command is essential for tailoring npm's operations to specific environments or project needs, enabling developers to customize their workflow, manage private registries, or configure network proxies efficiently.


title: CAVEATS
content:
Setting a configuration value using <I>npm config set</I> without <I>--global</I> or <I>--location global</I> will save it to the user's <I>.npmrc</I> file (<I>~/.npmrc</I>).<br>Configuration values are read from multiple sources in a specific order of precedence: command line flags, environment variables, project <I>.npmrc</I>, user <I>.npmrc</I>, global <I>.npmrc</I>, and built-in defaults.<br>Sensitive information like tokens or passwords should be handled with care. Consider using environment variables for such data if possible, or ensure <I>.npmrc</I> files have appropriate permissions.


title: CONFIGURATION FILE LOCATIONS
content:
Npm configuration can be stored in several <I>.npmrc</I> files. The typical locations are:<br><b>Project-level:</b> <I>./.npmrc</I> (in the current working directory). This is primarily used for project-specific settings that should be committed to version control.<br><b>User-level:</b> <I>~/.npmrc</I> (in the user's home directory). This file stores user-specific settings that apply across all projects for that user.<br><b>Global-level:</b> <I>$PREFIX/etc/npmrc</I> (where <I>$PREFIX</I> is typically <I>/usr/local</I> or a Node.js installation directory). This file contains system-wide settings.<br><b>Built-in:</b> npm also has a set of default, built-in configurations that serve as a baseline.


title: PRECEDENCE
content:
When npm resolves a configuration value, it applies a specific order of precedence, with higher levels overriding lower ones:<br>1. Command-line flags (e.g., <I>--registry=...</I>)<br>2. Environment variables (e.g., <I>npm_config_registry=...</I>)<br>3. Project <I>.npmrc</I> file<br>4. User <I>.npmrc</I> file (<I>~/.npmrc</I>)<br>5. Global <I>.npmrc</I> file (<I>$PREFIX/etc/npmrc</I>)<br>6. Built-in defaults


title: HISTORY
content:
The <I>npm config</I> command is an integral part of the npm (Node Package Manager) utility, which was first released in 2010. As npm evolved to manage a vast ecosystem of Node.js packages, the need for robust and flexible configuration management became paramount. The <I>config</I> subcommand was introduced early in npm's development lifecycle to provide a standardized way for users to customize npm's behavior. Its design reflects the common UNIX philosophy of configuration files, allowing settings to be overridden at different levels (project, user, global) to accommodate diverse development environments and deployment scenarios. Continuous improvements have focused on enhancing clarity, adding new configuration options, and ensuring compatibility across different npm versions.


title: SYNOPSIS
content:
<code><b>npm</b> <i>dedupe</i> [<i>--prefix</i> &lt;path&gt;] [<i>--dry-run</i>] [<i>--force</i>] [<i>...additional npm options</i>]</code>


title: PARAMETERS
content:
<b><i>--dry-run</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the command's execution without making any changes to the filesystem. It shows what <i>would</i> happen.<br><br><b><i>--force</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the deduplication process, potentially overwriting existing files or symlinks. Use this option with caution.<br><br><b><i>--prefix</i> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in the directory specified by <code><i>&lt;path&gt;</i></code> instead of the current working directory, affecting that project's <code>node_modules</code>.<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the result as a JSON object to standard output, suitable for programmatic parsing.<br><br>


title: DESCRIPTION
content:
<code><b>npm</b> <i>dedupe</i></code> (short for "deduplicate") is an npm command designed to optimize the <code>node_modules</code> directory within a Node.js project. Its primary function is to simplify the local package tree by identifying and reducing redundant installations of the same package. When multiple packages depend on the same version of another package, <code><b>npm</b> <i>dedupe</i></code> attempts to hoist that shared dependency to a higher, common ancestor in the <code>node_modules</code> hierarchy.<br><br>This process reduces the overall size of the <code>node_modules</code> directory, can potentially speed up installations, and helps avoid potential issues with conflicting package versions or module resolution. While <code><b>npm</b> <i>install</i></code> often performs a form of deduplication automatically, <code><b>npm</b> <i>dedupe</i></code> can be explicitly run to re-optimize the tree, especially after manual modifications or if the dependency tree has become suboptimal. It ensures that only one copy of a package exists at a given level of the tree, creating symlinks to shared copies where possible.


title: CAVEATS
content:
<ul><li><br> <b>Automatic Deduplication:</b> Since npm v7, <code><b>npm</b> <i>install</i></code> inherently performs a significant amount of deduplication automatically. Running <code><b>npm</b> <i>dedupe</i></code> explicitly might not always result in further significant changes unless the dependency tree has become particularly complex or has been manually altered.</li><li><br> <b>Re-introduction:</b> The <code><b>npm</b> <i>dedupe</i></code> command was deprecated in npm v7, with its functionality merged into <code><b>npm</b> <i>install</i></code>. However, due to user demand and specific use cases, it was re-introduced as a standalone command in later versions (e.g., npm 8.x onwards), allowing for explicit deduplication.</li><li><br> <b>Symlinks:</b> Deduplication heavily relies on creating symlinks to shared package instances. On some operating systems or specific setups (e.g., networked file systems), symlink creation or resolution might behave differently, potentially impacting the effectiveness or stability of the deduplicated structure.</li></ul>


title: PURPOSE AND BENEFITS
content:
The primary benefit of running <code><b>npm</b> <i>dedupe</i></code> is to reduce the overall size of the <code>node_modules</code> directory by minimizing redundant package installations. This can lead to faster installation times, reduced disk space usage, and a cleaner dependency tree, which can be particularly advantageous in CI/CD environments or when dealing with large projects with many nested dependencies.


title: WHEN TO USE
content:
While <code><b>npm</b> <i>install</i></code> handles most deduplication automatically, <code><b>npm</b> <i>dedupe</i></code> can be useful in specific situations:<br><br><i>1. After manual dependency changes:</i> If you've manually edited <code>package.json</code> or tampered with <code>node_modules</code>.<br><i>2. To resolve complex dependency issues:</i> Sometimes, a specific dependency graph might not be optimally deduplicated by default.<br><i>3. To ensure consistency:</i> Before committing <code>node_modules</code> (though generally discouraged) or deploying, to guarantee a consistent, optimized state.


title: HISTORY
content:
The <code><b>npm</b> <i>dedupe</i></code> command has been a part of npm for a long time, serving as a vital tool for optimizing the <code>node_modules</code> structure. Its evolution saw a notable change with the release of <b>npm v7</b>, where the core deduplication logic was integrated directly into the <code><b>npm</b> <i>install</i></code> command, leading to the standalone <code><i>dedupe</i></code> command being deprecated. This change aimed to simplify the workflow, making dependency optimization a default behavior during installation.<br><br>However, the explicit control offered by a dedicated <code><i>dedupe</i></code> command proved valuable for specific scenarios, such as after manual dependency adjustments or when troubleshooting complex dependency trees. Consequently, the <code><b>npm</b> <i>dedupe</i></code> command was re-introduced in subsequent npm versions (e.g., <b>npm 8.x</b>), providing users with the option to explicitly trigger the deduplication process independent of an <code><i>install</i></code> operation, reflecting the community's need for finer-grained control over package management.


title: SYNOPSIS
content:
<b>npm deprecate</b> <I>&lt;pkg&gt;[@&lt;version&gt;]</I> <I>&lt;message&gt;</I><br><i>Note: To un-deprecate, use an empty string for the message.</i>


title: PARAMETERS
content:
<b><I>&lt;pkg&gt;[@&lt;version&gt;]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the package to deprecate. Optionally, specify a particular version (e.g., <i>1.0.0</i>) or a version range (e.g., <i>1.x</i>, <i>&lt;2.0.0</i>) to target. If no version is specified, all versions of the package will be deprecated.<br><br><b><I>&lt;message&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The deprecation message that will be displayed to users when they attempt to install the deprecated package version. Use an empty string <b>""</b> to un-deprecate a previously deprecated version.<br><br>


title: DESCRIPTION
content:
The <b>npm deprecate</b> command allows package maintainers to mark specific versions or a range of versions of their published packages as deprecated. When a user attempts to install a deprecated version, npm will display a warning message, indicating that the version should not be used. This feature is crucial for signaling various issues, such as security vulnerabilities, critical bugs, or encouraging users to upgrade to a newer, more stable version, or migrate to an entirely different package. <br><br>Deprecating a package version is a permanent action recorded in the npm registry. It helps guide the community towards healthier and more secure package usage patterns. Maintainers typically use this command when a version is no longer supported, has known issues, or an alternative package is now preferred.


title: CAVEATS
content:
Deprecation is a permanent action for a given version. While you can "un-deprecate" by setting an empty message, the record of deprecation remains in the registry.<br>Only package owners can deprecate versions of their packages.<br>The deprecation message, once set, cannot be directly edited for a specific version; you must un-deprecate and then re-deprecate with a new message.<br>The deprecation warning is displayed to users during <b>npm install</b> operations, not when the package is already installed.


title: <B>UN-DEPRECATING A PACKAGE</B>
content:
To remove a deprecation warning from a package version, you simply run the <b>npm deprecate</b> command again for that specific version, but pass an <i>empty string</i> as the message. For example: <b>npm deprecate</b> <i>my-package@1.0.0 ""</i>


title: <B>IMPACT ON USERS</B>
content:
When a package version is deprecated, users who try to install it will see the specified deprecation message as a warning during the <b>npm install</b> process. This helps them identify potentially problematic dependencies and encourages them to update their package versions or consider alternatives.


title: HISTORY
content:
The <b>npm deprecate</b> command has been a foundational part of the npm CLI since its early days, providing a critical tool for package maintainers to communicate the lifecycle status of their published modules. Its core functionality has remained stable over many npm versions, reflecting its importance in guiding developers towards current and secure package dependencies.


title: SYNOPSIS
content:
<b>npm doctor</b> [<I>--json</I>] [<I>--registry</I> <I>url</I>] [<I>--prefix</I> <I>path</I>] [<I>--help</I>] [<I>--version</I>]


title: PARAMETERS
content:
<b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the diagnostic results in JSON format, useful for programmatic consumption or scripting.<br><br><b><I>--registry</I> <I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate <b>npm</b> registry URL to use for network connectivity checks instead of the default.<br><br><b><I>--prefix</I> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks write permissions for a specified alternate prefix path. This is typically where global <b>npm</b> packages are installed.<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>npm doctor</b> command, including usage and available options.<br><br><b><I>--version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed <b>npm</b> version being used by the command.<br><br>


title: DESCRIPTION
content:
<b>npm doctor</b> is a powerful diagnostic tool designed to verify the health and configuration of your Node.js and <b>npm</b> environment. It executes a series of automated checks to pinpoint common problems that can hinder <b>npm</b>'s functionality.<br><br>The command inspects critical aspects such as the compatibility of your Node.js and <b>npm</b> versions, network connectivity to the configured <b>npm</b> registry, and crucial read/write permissions for both the <b>npm</b> cache directory and the global installation prefix. It also verifies other system dependencies, like Git, if required for certain package installations.<br><br>By providing clear feedback and actionable suggestions, <b>npm doctor</b> helps users quickly identify and resolve underlying environmental or configuration issues, making it an invaluable utility for troubleshooting unexpected <b>npm</b> behavior and ensuring a smooth development workflow.


title: CAVEATS
content:
While <b>npm doctor</b> is effective for identifying many common environmental issues, it may not detect all possible problems, especially those related to specific project configurations, complex network proxy setups not configured for <b>npm</b>, or deep-seated system issues. The suggested solutions are general and might require adaptation based on your specific operating system and environment. It also requires an active internet connection to perform registry connectivity checks.


title: COMPREHENSIVE CHECKS PERFORMED
content:
The <b>npm doctor</b> command performs a variety of crucial checks to ensure a healthy <b>npm</b> environment:<br><b>&bull; Version Compatibility:</b> Verifies that your installed <b>npm</b> and Node.js versions are compatible and up-to-date.<br><b>&bull; Registry Connectivity:</b> Tests the ability to connect to the configured <b>npm</b> registry, essential for package downloads.<br><b>&bull; Cache Permissions:</b> Checks read and write access to the <b>npm</b> cache directory, preventing issues with downloaded packages.<br><b>&bull; Global Installation Permissions:</b> Ensures appropriate permissions for the directory where global <b>npm</b> packages are installed.<br><b>&bull; Git Availability:</b> Confirms that Git is installed and accessible if any project dependencies require Git-based installations.


title: HISTORY
content:
The <b>npm doctor</b> command was introduced in <b>npm</b> version 5.7.0, released in January 2018. Its primary motivation was to empower users to self-diagnose and resolve common environmental issues that frequently led to <b>npm</b> malfunctions, thereby reducing the burden on support and improving user experience. It marked a significant step towards making the <b>npm</b> CLI more self-sufficient in troubleshooting.


title: PARAMETERS
content:
<b>-p, --production</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan only production dependencies, excluding development dependencies.<br><br><b>-d, --development</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan only development dependencies, excluding production dependencies.<br><br><b>-s, --show-paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the full file paths to the duplicate modules detected.<br><br><b>-i, --ignore <patterns></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of glob patterns to ignore when scanning for duplicates.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the scan results in JSON format for programmatic parsing.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output in the terminal, useful for non-interactive environments.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version number of the <b>npm-find-dupes</b> command.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message, showing command usage and options.<br><br><b>[path]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory to scan for duplicate <i>npm</i> packages. If omitted, the current working directory is used by default.<br><br>


title: DESCRIPTION
content:
<b>npm-find-dupes</b> is a command-line utility for <i>Node.js</i> projects that identifies and lists duplicate package installations within the <i>node_modules</i> directory. It helps developers diagnose issues caused by redundant dependencies, such as increased application bundle size, longer installation times, and potential runtime conflicts arising from multiple versions of the same package. The command scans the dependency tree and reports instances where a package exists multiple times, often under different sub-dependencies, providing visibility into the structure of installed modules. It serves as a diagnostic tool, providing insights necessary for optimizing dependency management and ensuring a leaner, more efficient project.


title: CAVEATS
content:
<i>npm-find-dupes</i> is a diagnostic tool; it identifies but does not automatically fix duplicate installations. Resolution often requires using <i>npm dedupe</i> or manually adjusting <i>package.json</i> dependencies. Duplicates can occur due to different sub-dependencies requiring varying versions of the same package, or poorly managed dependency trees.


title: INSTALLATION
content:
To use <i>npm-find-dupes</i>, it typically needs to be installed globally via <i>npm</i>: <br><i><b>npm install -g npm-find-dupes</b></i> <br>This makes the <i>npm-find-dupes</i> command available directly in your terminal.


title: HISTORY
content:
<i>npm-find-dupes</i> is an <i>npm</i> package created to address the common problem of duplicate package installations in <i>Node.js</i> projects. Its development focuses on providing a clear diagnostic view of the dependency tree, helping developers manage and optimize their project's dependencies effectively by highlighting redundant modules.


title: PARAMETERS
content:
<b>[<I>pkg</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Displays funding information specifically for the given package name. If omitted, lists all fundable dependencies.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the funding information in a machine-readable JSON format, suitable for programmatic parsing.<br><br><b>--workspace <I>workspace_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command in the context of a specific workspace. Only dependencies within that workspace will be considered.<br><br><b>--workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command across all configured workspaces. Funding information for dependencies unique across all workspaces will be displayed.<br><br><b>--no-workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the workspace-aware behavior, even if `npm_config_workspaces=true` is set. Ensures the command only operates on the root project.<br><br>


title: DESCRIPTION
content:
The <i>npm fund</i> command allows developers to <br>list and explore financial support options for the <br>open-source packages their project depends on. <br>It reads the <i>funding</i> field from <i>package.json</i> files <br>in the dependency tree to provide direct links to <br>crowdfunding campaigns, donation platforms, <br>or sponsorship pages. By default, it outputs a <br>list of all unique dependencies that provide <br>funding information, grouped by their respective <br>funding URLs. <br><br>This command aims to promote sustainability in <br>the open-source ecosystem by making it easier <br>for users to contribute to the maintainers <br>whose work powers their applications.


title: CAVEATS
content:
Not all dependencies provide funding information. <br>The information displayed depends on the `funding` field <br>present in the `package.json` files of your dependencies. <br>This command processes the local `node_modules` <br>and `package-lock.json`, so an up-to-date installation <br>is recommended for accurate results.


title: USAGE EXAMPLES
content:
<b>npm fund</b><br>Lists all unique fundable dependencies and their funding URLs.<br><br><b>npm fund express</b><br>Shows funding information specifically for the 'express' package.<br><br><b>npm fund --json</b><br>Outputs the funding data for all dependencies in JSON format.


title: THE 'FUNDING' FIELD
content:
Maintainers can add a 'funding' field to their <br><i>package.json</i> to enable this feature. It can be a <br>single URL string or an array of objects, <br>each containing a 'type' and 'url' property. <br>For example:<br><br><i>"funding": "https://opencollective.com/my-package"</i><br><br>or<br><br><i>"funding": [<br>  { "type": "opencollective", "url": "https://opencollective.com/my-package" },<br>  { "type": "patreon", "url": "https://www.patreon.com/my-package" }<br>]</i>


title: HISTORY
content:
The <i>npm fund</i> command was introduced in <b>npm@6.9.0</b>, <br>released in August 2019. Its addition was part of <br>npm's broader effort to support the financial <br>sustainability of the open-source ecosystem, <br>providing a direct and discoverable way for <br>users to contribute back to the projects they rely upon.


title: PARAMETERS
content:
<b>--yes, -y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Skips all prompts</I> and uses default values to create <i>package.json</i>.<br><br><b>--force, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Forces initialization</I>, potentially overwriting an existing <i>package.json</i> or bypassing errors.<br><br><b>--scope <scope></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When creating a scoped package, <I>specifies the scope</I> (e.g., `@myorg`).<br><br><b>--ignore-scripts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prevents any scripts</I> (e.g., `preinstall`) from being executed during the initialization process.<br><br><b>--private</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets `private: true`</I> in <i>package.json</i> to prevent accidental publication to the npm registry.<br><br><b><initializer></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Uses a specific 'create-' package</I> (e.g., `react-app` for `create-react-app`) to scaffold a project.<br><br>


title: DESCRIPTION
content:
The <b>npm init</b> command is a fundamental utility in the Node.js ecosystem, primarily used to establish or update the <i>package.json</i> file for a project. This crucial file acts as the manifest for any Node.js package, containing vital metadata such as its name, version, description, entry point, test commands, scripts, dependencies, author, and license information.<br><br>When executed without specific options, <b>npm init</b> operates interactively, prompting the user for various details to populate the <i>package.json</i>. This guided process ensures that the generated file accurately reflects the project's characteristics. If a <i>package.json</i> already exists in the current directory, <b>npm init</b> will attempt to update it, merging new inputs with existing data.<br><br>A common and highly efficient usage is <b>npm init -y</b> (or <b>--yes</b>), which bypasses all interactive prompts. Instead, it automatically generates a <i>package.json</i> file populated with sensible default values. These defaults are often derived from the current directory name, npm's configuration, and standard conventions (e.g., version "1.0.0", main "index.js"). This non-interactive mode is particularly useful for quickly bootstrapping new projects or for automated build processes.<br><br>Beyond simple initialization, <b>npm init</b> can also leverage 'initializer' packages (e.g., <b>npm init react-app</b>, <b>npm init vite</b>). When used in this manner, it functions as a convenient shortcut for <b>npm create <initializer></b>, downloading and executing a specified 'create-' package to scaffold a new project with predefined structures and dependencies. This makes it an indispensable tool for starting diverse Node.js-based applications, from web apps to command-line tools.


title: CAVEATS
content:
Using <b>npm init -y</b> provides speed but may generate a <i>package.json</i> that requires <I>manual adjustments</I> for specific project needs.<br><br>When utilizing an <b><initializer></b> (e.g., <b>npm init next-app</b>), npm will first download the corresponding `create-<initializer>` package, which requires an active internet connection.<br><br><b>npm init</b> only creates the <i>package.json</i> file; it <I>does not install any dependencies</I> or project scaffolding beyond what the initializer provides. This typically requires a subsequent <b>npm install</b> command.


title: THE `PACKAGE.JSON` FILE
content:
The <i>package.json</i> file is the heart of any Node.js project managed by npm. It contains crucial metadata, scripts, and dependency declarations. <b>npm init</b> is the primary tool to generate this file, ensuring consistency and proper project management.


title: INITIALIZER PACKAGES (`CREATE-*`)
content:
When <b>npm init</b> is followed by an <I>initializer</I> (e.g., <b>npm init vite</b>), it acts as a shorthand for <b>npm create <initializer></b>. This mechanism downloads and executes a corresponding `create-<initializer>` package from the npm registry, providing a powerful way to scaffold complex project structures quickly with predefined configurations and dependencies.


title: HISTORY
content:
The <b>npm</b> package manager, along with its core commands like <b>npm init</b>, was developed by Isaac Z. Schlueter and first released in <I>January 2010</I>. <b>npm init</b> has been a foundational command since early versions, providing a standardized and interactive way for developers to set up new Node.js projects. Over time, its functionality expanded to include the convenient <b>--yes</b> flag for quick initialization and the integration of <I>initializer packages</I> (e.g., <b>npm init <template></b>), significantly streamlining the scaffolding of various application types.


title: PARAMETERS
content:
<b>--save, -S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Default behavior since npm 5</i>) <br>Saves the installed package as a production dependency in the <i><b>dependencies</b></i> field of <i><b>package.json</b></i>.<br><br><b>--save-dev, -D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the installed package as a development dependency in the <i><b>devDependencies</b></i> field of <i><b>package.json</b></i>.<br><br><b>--save-optional, -O</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the installed package as an optional dependency in the <i><b>optionalDependencies</b></i> field of <i><b>package.json</b></i>.<br><br><b>--global, -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs the package globally, making its executables available in the system's PATH. Global packages are not project-specific dependencies.<br><br><b>--production</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs only production dependencies (i.e., those in <i><b>dependencies</b></i> and <i><b>optionalDependencies</b></i>), skipping <i><b>devDependencies</b></i>. This is commonly used in deployment environments.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces npm to fetch remote resources even if local caches exist, or to re-install packages. Can override certain checks or warnings.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run, showing what would happen without actually making any changes to the file system or <i><b>package.json</b></i>.<br><br><b>--legacy-peer-deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs npm to install peer dependencies using the legacy algorithm (pre-npm v7), which can help with older projects or complex dependency trees.<br><br><b>--no-package-lock</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents npm from writing a <i><b>package-lock.json</b></i> file. This is generally discouraged for reproducible builds.<br><br>


title: DESCRIPTION
content:
<i><b>npm install</b></i> is the fundamental command for managing project dependencies within the Node.js ecosystem. When executed without arguments in a directory containing a <i><b>package.json</b></i> file, it reads the <i><b>dependencies</b></i> and <i><b>devDependencies</b></i> listed within it and downloads them into the local <i><b>node_modules</b></i> directory.<br><br>If a <i><b>package-lock.json</b></i> (or <i><b>npm-shrinkwrap.json</b></i>) file is present, <i><b>npm install</b></i> strictly adheres to it, guaranteeing reproducible builds by installing exact versions of all direct and transitive dependencies. Alternatively, <i><b>npm install <package-name></b></i> can be used to add a specific package, optionally saving it to your <i><b>package.json</b></i>. It is an indispensable tool for setting up development environments and deploying Node.js applications efficiently.


title: CAVEATS
content:
<b>Disk Space & <i>node_modules</i> size:</b> <br>The <i><b>node_modules</b></i> directory can grow very large, consuming significant disk space, especially in projects with many dependencies.<br><br><b><i>package-lock.json</i> Conflicts:</b> <br>When collaborating, merge conflicts in <i><b>package-lock.json</b></i> are common and require careful resolution to maintain consistent builds.<br><br><b>Peer Dependency Warnings:</b> <br>Npm may warn about unresolved peer dependencies. While often just warnings, they can sometimes indicate potential incompatibility issues.<br><br><b>Security Vulnerabilities:</b> <br>Dependencies can contain security vulnerabilities. Regularly running <i><b>npm audit</b></i> after <i><b>npm install</b></i> is highly recommended to identify and mitigate risks.


title: <I>PACKAGE-LOCK.JSON</I> VS. <I>PACKAGE.JSON</I>
content:
<i><b>package.json</b></i> defines your project's direct dependencies with version ranges (e.g., <i><b>^1.0.0</b></i>), while <i><b>package-lock.json</b></i> records the exact, immutable dependency tree, including transitive dependencies, used during the last <i><b>npm install</b></i>. This ensures consistent installs across different environments, preventing 'it works on my machine' scenarios.


title: <I>NPM INSTALL</I> VS. <I>NPM CI</I>
content:
While <i><b>npm install</b></i> is used for general package management (installing new packages, updating, or fresh installs), <i><b>npm ci</b></i> (clean install) is specifically designed for automated environments like CI/CD pipelines. <i><b>npm ci</b></i> *requires* a <i><b>package-lock.json</b></i> and installs dependencies by first deleting <i><b>node_modules</b></i> and then performing a fresh install based *only* on the lock file, without modifying it. This ensures much faster and more reproducible builds in a controlled environment.


title: HISTORY
content:
Npm (Node Package Manager), created by Isaac Schlueter, was first released in January 2010 and quickly became the default package manager for Node.js. Its introduction was pivotal for the rapid growth of the Node.js ecosystem, standardizing how developers share and consume modules. The <i><b>npm install</b></i> command has been at the core of this, continually evolving to handle increasingly complex dependency graphs. Key milestones include the introduction of <i><b>package-lock.json</b></i> in npm v5 to ensure deterministic installs, and the shift in npm v7 to a new, stricter peer dependency resolution algorithm, significantly impacting how <i><b>npm install</b></i> behaves.


title: SYNOPSIS
content:
<b>npm login</b> [<b>--registry=</b><I>url</I>] [<b>--scope=</b><I>scope</I>] [<b>--no-otp</b> | <b>--otp</b> <I><code></I>]


title: PARAMETERS
content:
<b><b>--registry=</b><I>url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the registry to log in to. If not provided, npm uses the default registry (<b>registry.npmjs.org</b>).<br><br><b><b>--scope=</b><I>scope</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associates the login credentials with a specific scope. This is useful when working with private scoped packages that might be hosted on a different registry.<br><br><b><b>--no-otp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the one-time password prompt. This is generally discouraged for security reasons but can be useful in automated environments where OTP input is not possible. If 2FA is enabled and this flag is used, the login will likely fail.<br><br><b><b>--otp</b> <I><code></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a one-time password directly, bypassing the interactive prompt. This is used when 2FA is enabled and the OTP is available through other means (e.g., environment variable, script output).<br><br>


title: DESCRIPTION
content:
The <b>npm login</b> command allows users to authenticate themselves with an npm registry. This is essential for publishing packages, installing private packages, or accessing scoped packages from private registries.<br><br>When executed, it interactively prompts the user for a username, password, and email address. If two-factor authentication (2FA) is enabled for the account, it will also prompt for a one-time password (OTP).<br><br>Upon successful authentication, <b>npm login</b> stores an authentication token in the user's <b>.npmrc</b> configuration file, typically located in the home directory (<b>~/.npmrc</b>). This token is then used for subsequent authenticated npm operations, such as <b>npm publish</b> or <b>npm install</b> for private packages. It's the primary way to establish an authenticated session with the npm registry.


title: CAVEATS
content:
The authentication token stored in <b>.npmrc</b> grants access to your npm account. Ensure your <b>.npmrc</b> file has appropriate permissions (e.g., <b>chmod 600 ~/.npmrc</b>) to prevent unauthorized access. Using <b>--no-otp</b> can reduce security if 2FA is enabled for your account.<br><br>Be cautious when logging into public or shared machines, as tokens can persist.


title: HISTORY
content:
The <b>npm login</b> command has been a fundamental part of the npm CLI since its early days, providing the necessary mechanism for users to authenticate with npm registries. Initially, it was often an alias for <b>npm adduser</b>, and in many current versions, <b>npm adduser</b> still performs the same interactive login process. Its core functionality has remained consistent: facilitating secure access for publishing and consuming private packages. Over time, features like 2FA support (via <b>--otp</b>) have been integrated to enhance security.


title: PARAMETERS
content:
<b>-g, --global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List packages in the global install root instead of the current project.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results as a JSON object, useful for scripting and programmatic parsing.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show extended information for each package, including licenses, description, and repository.<br><br><b>--parseable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in a format that is easily parseable by other commands or scripts, typically one package path per line.<br><br><b>--depth=<n></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the depth of the dependency tree. <b>--depth=0</b> shows only top-level dependencies.<br><br><b>--link</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only packages that are symlinked.<br><br><b>--production</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only production dependencies (excluding dev dependencies).<br><br><b>--development</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only development dependencies (excluding production dependencies).<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all dependencies, including production, development, optional, peer, and bundled.<br><br><b>--omit <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Omit specific dependency types (e.g., <i>dev</i>, <i>optional</i>, <i>peer</i>). Can be specified multiple times.<br><br><b>--include <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include specific dependency types (e.g., <i>dev</i>, <i>optional</i>, <i>peer</i>). Can be specified multiple times.<br><br><b>--dedupe</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a deduplicated tree. This is useful after running <b>npm dedupe</b>.<br><br><b>--versions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only the package name and version number, without the full tree.<br><br><b>--silent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output, useful when only the exit code is needed.<br><br><b>--loglevel <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging level for the output (e.g., <i>info</i>, <i>warn</i>, <i>error</i>).<br><br>


title: DESCRIPTION
content:
The <b>npm ls</b> command displays a tree of installed <i>node_modules</i> packages and their dependencies. By default, it lists packages installed locally in the current project directory. Using the <b>-g</b> or <b>--global</b> option, it can list packages installed globally across your system.<br><br>This command is invaluable for understanding the actual state of your project's dependencies, including their versions and the hierarchy in which they are installed. It helps in identifying potential issues like duplicate packages, hoisted dependencies, or unmet peer dependencies. The output can be an ASCII tree, which is easy to read, or a JSON object for programmatic parsing. It provides a quick overview of what's present in your <i>node_modules</i> folder, which may differ from what's declared in your <i>package.json</i> due to various installation processes or dependency conflicts.


title: CAVEATS
content:
For projects with a very large number of dependencies, the default ASCII tree output can be extremely verbose and slow to generate. Consider using <b>--depth=0</b> or <b>--json</b> for better performance and readability.<br><br>The command displays what is <i>actually installed</i> in <i>node_modules</i>, which might not always align perfectly with the dependencies declared in your <i>package.json</i> due to hoisting, uninstalled packages, or differing versions from previous installations.<br><br>Output can contain warnings like <i>UNMET PEER DEPENDENCY</i>, indicating a peer dependency requirement that hasn't been met by a parent package. This isn't always an error but should be understood.<br><br>The `npm ls` command does not modify the filesystem; it is purely an inspection tool.


title: OUTPUT INTERPRETATION
content:
The default ASCII tree output indicates the hierarchical relationship between packages. Symbols like ` extraneous` or ` unmet peer dependency` provide critical information about the state of your installed packages. `extraneous` means the package is installed but not listed in <i>package.json</i>, while `unmet peer dependency` means a required peer dependency for a package is missing.


title: DEPENDENCY TYPES
content:
Understanding dependency types is crucial. <i>Dependencies</i> are required for the application to run. <i>DevDependencies</i> are only needed for development and testing. <i>PeerDependencies</i> are required by the package itself, but not installed directly by npm; the consuming project is expected to provide them. <i>OptionalDependencies</i> are optional and don't cause installation failure if missing. <i>BundledDependencies</i> are an array of package names that are bundled when publishing.


title: PERFORMANCE CONSIDERATIONS
content:
For very deep or wide dependency trees, `npm ls` can consume significant memory and time. Using options like <b>--depth</b>, <b>--production</b>, or piping the output to `grep` or `less` can significantly improve its usability and performance in large projects.


title: HISTORY
content:
The <b>npm ls</b> command has been a fundamental utility within the npm CLI since its early days, evolving alongside npm's dependency resolution algorithms and the structure of the <i>node_modules</i> directory. Its core functionality of displaying the installed dependency tree has remained constant, but new options have been added over time to provide more granular control over output format, depth, and the types of dependencies to display, reflecting the growing complexity of modern JavaScript projects and the need for better introspection tools. It continues to be one of the most frequently used npm commands for developers to debug and understand their project's dependency graph.


title: SEE ALSO
content:
npm install(1), npm uninstall(1), npm update(1), npm view(1), npm outdated(1), npm prune(1), npm help(1)


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the availability status and associated details in JSON format. This is useful for programmatic consumption of the command's result.<br><br>


title: DESCRIPTION
content:
The <i>npm-name</i> command line utility allows developers to quickly determine if a desired package name is available on the npm registry. It serves as a crucial tool for avoiding naming conflicts when creating new packages for the Node.js ecosystem.<br><br>By querying the npm registry directly, it provides a real-time status check, indicating whether a name is free to use or if it has already been registered by another user. This helps streamline the package creation process, ensuring that developers can secure unique and relevant names for their projects. It's particularly useful in automated scripts or for quick manual verification before initiating an <i>npm init</i> or <i>npm publish</i> workflow. The tool outputs a clear message indicating availability or unavailability, with an option to receive the output in JSON format for programmatic parsing.


title: CAVEATS
content:
The availability status provided by <i>npm-name</i> is real-time at the moment of the query but does not guarantee future availability. Another user could register the name immediately after your check. Additionally, the command relies on the npm registry API, which may be subject to rate limits or temporary downtime, potentially affecting the accuracy or responsiveness of the query.


title: USAGE EXAMPLES
content:
Check if 'my-awesome-package' is available:<br><i>npm-name my-awesome-package</i><br><br>Get JSON output for 'another-name':<br><i>npm-name another-name --json</i>


