# CommandSection

title: EXIT CODES
content:
The command typically returns the following exit codes:<br><b>0</b>: The specified package name is available.<br><b>1</b>: The specified package name is already taken or an error occurred during the query (e.g., network issue, registry downtime).


title: HISTORY
content:
The <i>npm-name</i> utility was created by Sindre Sorhus, a prolific open-source developer known for his many small, focused, and widely used npm packages. It was initially released in 2014, emerging as a practical solution to a common developer need: quickly verifying package name availability in the rapidly expanding npm ecosystem. Its development reflects the community's demand for simple, single-purpose tools that integrate seamlessly into the Node.js development workflow, contributing to more efficient package management and publication practices.


title: SYNOPSIS
content:
The primary syntax for <b>npm org</b> involves a subcommand to specify the desired action.<br><br><b>npm org</b> <i>&lt;command&gt;</i><br><br>Common <i>&lt;command&gt;</i> options include:<br><br><b>npm org ls</b> [<i>&lt;orgname&gt;</i>]<br><b>npm org add</b> <i>&lt;orgname&gt; &lt;username&gt;</i> [<i>&lt;role&gt;</i>]<br><b>npm org rm</b> <i>&lt;orgname&gt; &lt;username&gt;</i><br><b>npm org set</b> <i>&lt;orgname&gt; &lt;key&gt; &lt;value&gt;</i><br><b>npm org enable-public-signup</b> <i>&lt;orgname&gt;</i><br><b>npm org disable-public-signup</b> <i>&lt;orgname&gt;</i>


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs data in JSON format for programmatic use.<br><br><b>--otp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a one-time password from a two-factor authenticator, required for certain registry operations.<br><br><b>--registry</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base URL of the npm registry to use, overriding the default configured registry.<br><br><b>orgname</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the npm organization to manage.<br><br><b>username</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The npm username of the member to add or remove from an organization.<br><br><b>role</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The role to assign to a new member (e.g., <i>developer</i> or <i>admin</i>). Defaults to <i>developer</i>.<br><br><b>key</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The configuration key to set for an organization (e.g., <i>public-signup</i>).<br><br><b>value</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The value to assign to a configuration key (e.g., <i>true</i> or <i>false</i>).<br><br>


title: DESCRIPTION
content:
<b>npm org</b> is a powerful subcommand within the <b>npm</b> command-line interface, designed for managing organizations on the npm registry. Organizations provide a structured way to group collaborators and packages, enabling enhanced control over access permissions, especially crucial for larger development teams or companies. This command facilitates several key operations related to organization management, such as adding or removing members, listing organization details, and enabling/disabling public sign-ups. It integrates with the <b>npm-team</b> command to provide more granular control over package access for specific groups of users within an organization. Utilizing <b>npm org</b> helps maintain clear administrative oversight and efficient collaboration when working with private or public packages under a collective entity on npm.


title: CAVEATS
content:
Requires an authenticated npm session. Administrative actions typically require <i>admin</i> privileges within the organization. Commands involving registry changes may require a one-time password (<i>--otp</i>) if two-factor authentication is enabled for your account.<br>Network connectivity is essential for interacting with the npm registry.


title: ROLES WITHIN AN ORGANIZATION
content:
When adding a member to an organization, you can specify their role:<br><i><b>developer</b></i>: Can publish packages to teams they are part of.<br><i><b>admin</b></i>: Has full administrative control over the organization, including adding/removing members and managing teams.


title: INTEGRATION WITH NPM-TEAM
content:
While <b>npm org</b> manages overall organization membership, <b>npm-team</b> provides more granular control. Teams allow you to define subsets of organization members and assign specific permissions to packages for those teams. Use <b>npm org</b> to manage the organization's members, then <b>npm-team</b> to assign members to teams and manage team-specific package access.


title: HISTORY
content:
The concept of organizations was introduced to the npm registry to cater to the needs of larger development teams and enterprises. This feature provided a robust mechanism for collaborative package development and granular access control, particularly for private packages. The <b>npm org</b> command evolved as the primary interface for managing these organizational structures, complementing the existing user and package management commands within the npm CLI.


title: SYNOPSIS
content:
npm outdated [--json | --long | --parseable] [--depth=<depth>] [--global] [--workspaces] [<package-spec> ...]


title: PARAMETERS
content:
<b>[<package-spec> ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies one or more package names to check for outdated versions. If omitted, all project dependencies are checked.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the results in JSON format, which is useful for programmatic consumption.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays additional columns in the output, such as <code>Package Type</code> (e.g., <code>Dependencies</code>, <code>devDependencies</code>), <code>Homepage</code>, and <code>License</code>.<br><br><b>--parseable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the results in a tab-separated, machine-parseable format, making it easier for scripts to process the data.<br><br><b>--depth=<depth></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the depth of the dependency tree traversal. A depth of <code>0</code> will only show top-level dependencies.<br><br><b>--global, -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for outdated packages installed globally on your system rather than in the current project.<br><br><b>--workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for outdated packages across all configured workspaces in the project.<br><br>


title: DESCRIPTION
content:
<b>npm outdated</b> is a powerful command within the Node.js package manager (npm) ecosystem that helps developers identify dependencies in their project that have newer versions available. It scans your project's <code>node_modules</code> directory and compares the currently installed package versions against the versions specified in your <code>package.json</code> file, as well as the absolute latest versions available in the npm registry.<br><br>The command provides a clear, tabular output, detailing for each package its <i>current installed version</i>, the <i>"wanted" version</i> (the highest version that satisfies the semantic versioning range defined in <code>package.json</code> without breaking changes), and the <i>"latest" version</i> (the newest version published to the registry, which may include major, potentially breaking, updates). This crucial insight allows developers to proactively manage their project's dependencies, ensuring they can leverage bug fixes, performance improvements, and new features, while also staying informed about potential breaking changes that might arise from major version updates. It's an essential tool for dependency management and maintaining project health.


title: CAVEATS
content:
While <b>npm outdated</b> is a highly valuable tool, it's important to understand its nuances. The command only checks for <i>newer</i> versions; it does not identify unused or redundant dependencies. The output often uses color coding: <i>red</i> typically indicates a major version bump available (a potentially breaking change), while <i>yellow</i> signals a minor or patch update (usually safe).<br><br>The distinction between the "Wanted" and "Latest" columns is crucial. "Wanted" represents the highest version that satisfies the semver range specified in your <code>package.json</code> and is generally safe to update to using <code>npm update</code>. "Latest" is the absolute newest version published, which might be a major version requiring manual <code>npm install &lt;package&gt;@latest</code> and thorough testing due to potential breaking changes. Furthermore, <b>npm outdated</b> queries the npm registry; thus, it requires an active internet connection to provide up-to-date information.


title: EXIT CODES
content:
The <b>npm outdated</b> command provides specific exit codes that are useful for scripting and automation:<br><ul><li><code>0</code>: No packages are outdated.</li><li><code>1</code>: At least one package is outdated.</li><li>Any other non-zero code: An error occurred during command execution.</li></ul>


title: HISTORY
content:
The <b>npm outdated</b> command has been a fundamental utility within the npm CLI since its early days, reflecting the critical need for effective dependency management in Node.js projects. As the npm ecosystem expanded rapidly and projects accumulated numerous direct and transitive dependencies, the importance of easily identifying and managing outdated packages grew significantly. Its consistent presence and evolution alongside the npm CLI have made it an indispensable tool for developers to maintain the health, security, and performance of their applications by keeping dependencies up-to-date.


title: SYNOPSIS
content:
npm owner add <I>user</I> <I>package</I><br>npm owner rm <I>user</I> <I>package</I><br>npm owner ls <I>package</I><br>npm owner <I>command</I> [--registry <I>registry url</I>]


title: PARAMETERS
content:
<b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a specified user as an owner to a package. Requires <I>user</I> and <I>package</I> arguments.<br><br><b>rm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified user as an owner from a package. Requires <I>user</I> and <I>package</I> arguments.<br><br><b>ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all owners of a specified package. Requires a <I>package</I> argument.<br><br><b><I>user</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The npm username to be added or removed from package ownership.<br><br><b><I>package</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the package whose owners are being managed or listed.<br><br><b>--registry <I>registry url</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the registry to use for the command, overriding the default.<br><br>


title: DESCRIPTION
content:
The <B>npm owner</B> command is a vital part of the npm command-line interface, designed to manage the list of users who have publishing and modification rights for a specific package hosted on the npm registry. It facilitates collaborative development by allowing multiple team members to manage a single package. This command provides three primary subcommands: <I>add</I>, <I>rm</I> (remove), and <I>ls</I> (list).<br><br>The <B>add</B> subcommand grants ownership rights to a specified user for a given package. The <B>rm</B> subcommand revokes these rights, preventing a user from publishing new versions or modifying the package metadata. The <B>ls</B> subcommand displays all current owners of a package. Effective use of <B>npm owner</B> ensures proper access control and accountability for package maintenance, especially in team environments. It's important to note that performing 'add' or 'rm' operations typically requires the user to be an existing owner of the package and to be authenticated with the npm registry.


title: CAVEATS
content:
Only existing package owners can add or remove other owners for a package. To perform modification operations (<I>add</I> or <I>rm</I>), you must be logged in to npm via <B>npm login</B>. The package must already exist on the npm registry. Removing the last owner of a package is generally prevented to avoid orphaned packages.


title: PERMISSIONS AND AUTHENTICATION
content:
Any operations that modify package ownership (like <I>add</I> or <I>rm</I>) require you to be authenticated with the npm registry using <B>npm login</B>. Furthermore, only existing owners of a package have the necessary permissions to add or remove other owners for that package.


title: HISTORY
content:
The <B>npm owner</B> command has been a fundamental part of npm's package management capabilities since its early development, allowing for collaborative package development on the npm registry. Its functionality evolved alongside other access control mechanisms, providing a clear way to delegate publishing rights and maintain package integrity across teams.


title: SYNOPSIS
content:
<pre><code><b>npm query</b> <I>&#x3C;selector-string></I> [<I>&#x3C;options></I>]</code></pre><br><I>&#x3C;selector-string></I>: A CSS-like selector used to target specific nodes in the dependency graph.<br><I>&#x3C;options></I>: Various flags to control output format, filtering, and scope.


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results as a JSON array.<br><br><b>--include-workspace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include workspaces in the dependency graph traversal.<br><br><b>--workspace-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict the query to only the root workspace.<br><br><b>--production, --omit=dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only include production dependencies.<br><br><b>--development, --omit=prod</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only include development dependencies.<br><br><b>--depth <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the depth of dependency traversal.<br><br><b>--workspace <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in a specific workspace.<br><br><b>--workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in all configured workspaces.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display extended information for each matched node.<br><br><b>--parseable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output a parseable format, often suitable for scripting.<br><br><b>--legend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a legend explaining the output format symbols.<br><br><b>--filter <filter-string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter results based on property values (e.g., '--filter 'name=react'').<br><br><b>--query-root <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start the query from a specific directory path instead of the current working directory.<br><br><b>--engine-strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Obey <I>engine-strict</I> rules when querying dependencies.<br><br><b>--prefer-online</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prefer online version checks for faster results, even if offline cache is available.<br><br><b>--no-offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the command to operate online, ignoring any offline cache.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in offline mode, using only cached data.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force actions, ignoring warnings or potential conflicts.<br><br><b>--no-unicode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use unicode characters in output, useful for terminals that don't support them.<br><br><b>--no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use colors in output.<br><br>


title: DESCRIPTION
content:
The <I>npm query</I> command allows users to inspect and traverse the dependency graph of an npm project using CSS-like selectors. Introduced in <I>npm@9</I>, it provides a powerful way to filter, analyze, and understand the relationships between packages within a project, including workspaces. It can identify production dependencies, development dependencies, optional dependencies, peer dependencies, and more. The command leverages a dedicated query engine to efficiently navigate the <I>node_modules</I> tree and <I>package.json</I> configurations, returning a list of matched dependency nodes. This enables advanced use cases like finding specific versions, identifying extraneous packages, or understanding the impact of dependency changes.


title: CAVEATS
content:
The <I>npm query</I> command requires npm version 9.0.0 or higher. Its functionality relies on a robust internal query engine designed for npm's specific dependency graph structure, which may not behave identically to standard DOM CSS selectors in all edge cases. Querying extremely large or complex dependency trees can be resource-intensive and may take some time. The selector syntax, while CSS-like, has specific extensions and limitations tailored for npm packages.


title: QUERY SELECTORS
content:
<I>npm query</I> uses CSS-like selectors to navigate the dependency graph. Common selectors include:<br><br><I>&#x3C;selector> &#x3C;selector></I>: Descendant selector.<br><I>&#x3C;selector> > &#x3C;selector></I>: Child selector.<br><I>:root</I>: Matches the project's root package.<br><I>:link</I>: Matches packages that are symlinked (e.g., workspaces).<br><I>:prod</I> / <I>:production</I>: Matches production dependencies.<br><I>:dev</I> / <I>:development</I>: Matches development dependencies.<br><I>:optional</I>: Matches optional dependencies.<br><I>:peer</I>: Matches peer dependencies.<br><I>:bundle</I>: Matches bundled dependencies.<br><I>:extraneous</I>: Matches packages not explicitly listed in <I>package.json</I>.<br><I>:invalid</I>: Matches packages that are invalid (e.g., missing).<br><I>:deduped</I>: Matches deduped packages.<br><I>[name]</I>: Matches by package name.<br><I>[version='1.0.0']</I>: Matches by specific version.<br><I>[name^='foo']</I>: Matches by regex on name (e.g., name starts with 'foo').<br><I>[homepage]</I>: Matches if an attribute exists.<br><I>[name='foo'][version^='1.']</I>: Multiple attribute matching.


title: OUTPUT FORMATS
content:
By default, <I>npm query</I> outputs a human-readable tree-like structure.<br>The <I>--json</I> option provides a machine-readable JSON array of objects, each representing a matched node with detailed metadata.<br>The <I>--long</I> option adds more details to the default output, such as paths and license information.<br>The <I>--parseable</I> option provides a simplified, colon-separated output, useful for scripting.<br>The <I>--legend</I> option helps interpret the default output's symbols and colors.


title: HISTORY
content:
The <I>npm query</I> command was officially introduced with the release of <b>npm@9.0.0</b> in October 2022. It was developed to provide a standardized, powerful, and programmatic way to inspect and analyze the complex dependency graphs that characterize modern JavaScript projects, especially those leveraging npm workspaces. Prior to its introduction, users relied on combinations of <I>npm ls</I>, <I>grep</I>, and custom scripting to achieve similar analysis. <I>npm query</I> consolidates this functionality into a single, intuitive interface, built upon the underlying <I>@npmcli/query</I> package. Its development aimed to empower developers with better tools for understanding their project's dependencies for security audits, performance optimization, and general project maintenance.


title: PARAMETERS
content:
<b>-- <args...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any arguments following '--' are passed directly to the <i>start</i> script executed during the restart process. These are not options for <b>npm restart</b> itself, but for the underlying script.<br><br>


title: DESCRIPTION
content:
<b>npm restart</b> is an <b>npm</b> command that executes a sequence of lifecycle scripts defined in a Node.js project's <i>package.json</i> file. It effectively combines the actions of <b>npm stop</b> and <b>npm start</b>. When <b>npm restart</b> is invoked, it first attempts to run the <i>stop</i> script (if defined), preceded by <i>prestop</i> and followed by <i>poststop</i>. After the stop sequence completes, it then executes the <i>start</i> script (if defined), preceded by <i>prestart</i> and followed by <i>poststart</i>. This provides a convenient way to gracefully shut down and then re-launch a Node.js application or service, making it ideal for deployments or development workflows requiring a full refresh. It relies entirely on the <i>scripts</i> section within <i>package.json</i> to define the actual commands for stopping and starting the application.


title: CAVEATS
content:
<ul><li><b>npm restart</b> requires <i>stop</i> and <i>start</i> scripts (or their <i>pre</i>/<i>post</i> counterparts) to be defined in the <i>scripts</i> section of your <i>package.json</i> for it to perform meaningful actions. If these scripts are not defined, <b>npm restart</b> will complete without error but without performing any specific stop or start operations.</li><li>Errors in <i>prestop</i>, <i>stop</i>, <i>poststop</i>, <i>prestart</i>, <i>start</i>, or <i>poststart</i> scripts will cause the entire <b>npm restart</b> process to terminate.</li><li>This command is part of the <b>npm</b> CLI tool for Node.js projects, not a standalone operating system command.</li></ul>


title: LIFECYCLE SCRIPT SEQUENCE
content:
When <b>npm restart</b> is invoked, it sequentially executes a series of lifecycle scripts defined in your <i>package.json</i>:<br>1. <i>prestop</i> (runs before <i>stop</i>)<br>2. <i>stop</i> (main stopping script)<br>3. <i>poststop</i> (runs after <i>stop</i>)<br>4. <i>prestart</i> (runs before <i>start</i>)<br>5. <i>start</i> (main starting script)<br>6. <i>poststart</i> (runs after <i>start</i>)<br>All these scripts are optional. If a script is not defined, <b>npm</b> simply skips it. If any executed script returns a non-zero exit code, the entire <b>npm restart</b> command fails.


title: <I>PACKAGE.JSON</I> CONFIGURATION
content:
The commands executed by <b>npm restart</b> are configured in the <i>"scripts"</i> section of your project's <i>package.json</i> file. For instance, you might have:<br><I>"scripts": {<br>&nbsp;&nbsp;&nbsp;&nbsp;"stop": "node ./scripts/graceful-shutdown.js",<br>&nbsp;&nbsp;&nbsp;&nbsp;"start": "node app.js --port 3000"<br>}</I><br>This allows for custom logic to be executed for stopping and starting your application.


title: HISTORY
content:
<b>npm</b> (Node Package Manager) was created by Isaac Schlueter and first released in 2010. The concept of lifecycle scripts, including <i>start</i> and <i>stop</i>, has been a core feature of <b>npm</b> since its early days, allowing developers to standardize project operations. <b>npm restart</b> was introduced as a convenience command to bundle the common <i>stop</i> and <i>start</i> sequence, streamlining development and deployment workflows for Node.js applications.


title: SYNOPSIS
content:
<B>npm root</B> [<B>--global</B>|<B>-g</B>] [<B>--prefix</B> <I>path</I>] [<B>--json</B>] [<B>--parseable</B>]


title: PARAMETERS
content:
<b><B>--global</B>, <B>-g</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the global <I>node_modules</I> directory path, where packages installed with <B>npm install -g</B> would reside.<br><br><b><B>--prefix</B> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <I>node_modules</I> directory path associated with the specified <I>prefix</I> path, overriding the default project or global prefix.<br><br><b><B>--json</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the path as a JSON string. Useful for programmatic consumption.<br><br><b><B>--parseable</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the path in a machine-parseable format (a single line). Useful for scripting.<br><br>


title: DESCRIPTION
content:
<B>npm root</B> is an <I>npm</I> subcommand that prints the absolute path to the <I>node_modules</I> directory. This directory is where <I>npm</I> installs project dependencies locally or global packages if specified.<br><br>By default, when run within an <I>npm</I> project, it shows the local <I>node_modules</I> path relative to the current project's root. When the <B>--global</B> or <B>-g</B> option is used, it outputs the path to the global <I>node_modules</I> directory, where globally installed packages reside.<br><br>This command is highly useful for scripting, debugging package resolution issues, or simply understanding where <I>npm</I> manages your dependencies. It reflects <I>npm</I>'s current configuration, including any <I>prefix</I> settings, and does not perform any installation or modification to the filesystem.


title: CAVEATS
content:
The output of <B>npm root</B> is dynamic; it depends on the current working directory for local roots and <I>npm</I> configuration (like <I>prefix</I>) for global roots. <br>It does not create the directory if it doesn't already exist. Running it in a directory not part of an <I>npm</I> project might output a path higher up the directory tree or the global root based on <I>npm</I>'s fallback logic.


title: LOCAL VS. GLOBAL ROOT
content:
When <B>npm root</B> is run without <B>--global</B>, it determines the local <I>node_modules</I> path, which is typically <I>&lt;current_project_root&gt;/node_modules</I>. This is where dependencies listed in <I>package.json</I> are installed. <br><br>With <B>--global</B>, it reports the system-wide global <I>node_modules</I> path, usually configured by <I>npm</I> during installation or via the <I>prefix</I> configuration. This is where executables for global commands are often linked from.


title: CONFIGURATION INFLUENCE
content:
The exact path returned by <B>npm root --global</B> can be influenced by the <I>prefix</I> configuration. You can inspect this value using <B>npm config get prefix</B>. Setting a custom <I>prefix</I> will change where <I>npm</I> installs global packages and, consequently, what <B>npm root --global</B> reports.


title: HISTORY
content:
<B>npm root</B> has been a fundamental command within the <I>npm</I> ecosystem since its early versions, serving the essential purpose of reporting package installation locations. Its core functionality has remained consistent, with additions primarily focusing on output formatting options like <B>--json</B> and <B>--parseable</B> to enhance its utility in scripting and automation.


title: SYNOPSIS
content:
<b>npm run</b> <i>&lt;script&gt;</i><br><b>npm run</b> <i>&lt;script&gt;</i> <b>[--</b> <i>&lt;args&gt;...</i><b>]</b><br><b>npm run</b><br><b>npm run-script</b> <i>&lt;script&gt;</i> <b>[--</b> <i>&lt;args&gt;...</i><b>]


title: PARAMETERS
content:
<b><i>&lt;script&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the script to execute as defined in the <i>"scripts"</i> section of <i>package.json</i>.<br><br><b><b>--</b> <i>&lt;args&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to pass additional arguments directly to the executed script. Everything after <i><b>--</b></i> is treated as arguments for the script itself, not for <b>npm run</b>.<br><br><b><b>--silent</b> or <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output from <b>npm</b> itself, showing only the standard output and error of the executed script.<br><br><b><b>--if-present</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>npm run</b> from throwing an error if the specified script does not exist in <i>package.json</i>. The command will simply exit with status 0.<br><br><b><b>--workspace</b> <i>&lt;workspace_name&gt;</i> or <b>-w</b> <i>&lt;workspace_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the script within a specific workspace (for monorepos). Can be specified multiple times to target multiple workspaces.<br><br><b><b>--prefix</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the directory where <b>npm run</b> will look for the <i>package.json</i> file to read scripts from. Useful for running scripts in a different project root.<br><br>


title: DESCRIPTION
content:
The <b>npm run</b> command is a fundamental utility within the Node.js ecosystem, primarily used to execute arbitrary commands defined in the <i>"scripts"</i> field of a project's <i>package.json</i> file. <br><br>It serves as the backbone for automating various development tasks, including building projects, running tests, linting code, starting development servers, and deploying applications. When <b>npm run</b> executes a script, it automatically prepends the <i>node_modules/.bin</i> directory to the system's PATH, making locally installed executable packages available directly by name without needing to specify their full path. <br><br>Scripts are executed in a sub-shell, allowing for the use of shell-specific features like pipes, redirects, and environment variables. If additional arguments need to be passed to the executed script, they can be appended after a <i>"--"</i> separator. Running <b>npm run</b> without any arguments will list all available scripts defined in the <i>package.json</i>. It's an indispensable tool for managing project workflows and ensuring consistent task execution across different development environments.


title: CAVEATS
content:
When running scripts, <b>npm run</b> temporarily modifies the system's PATH environment variable to include <i>node_modules/.bin</i>. This allows direct execution of binaries installed by local dependencies. Scripts are executed in a sub-shell, which means platform-specific shell syntax (e.g., Windows vs. Linux/macOS commands, path separators, variable expansion) must be considered for cross-platform compatibility. The exit code of the script executed by <b>npm run</b> is propagated as the exit code of the <b>npm run</b> command itself. Always be cautious when running scripts from untrusted <i>package.json</i> files, as they can execute arbitrary commands on your system.


title: LIFECYCLE HOOKS
content:
<b>npm run</b> automatically executes special <i>lifecycle scripts</i> defined as <i>pre&lt;script&gt;</i> and <i>post&lt;script&gt;</i> before and after the main script, respectively. For example, running <i><b>npm run test</b></i> will first execute a <i>pretest</i> script (if defined), then the <i>test</i> script, and finally the <i>posttest</i> script.


title: ENVIRONMENT VARIABLES
content:
Inside a script executed by <b>npm run</b>, numerous environment variables are made available, providing context about the project, <b>npm</b> configuration, and the currently running script. These include variables like <i>NPM_PACKAGE_NAME</i>, <i>NPM_PACKAGE_VERSION</i>, <i>NPM_CONFIG_PREFIX</i>, and <i>NPM_COMMAND</i>, among others, prefixed with <i>NPM_</i>.


title: SPECIAL SHORTCUTS
content:
For commonly used scripts, <b>npm</b> provides convenient shortcuts. Commands like <i><b>npm start</b></i>, <i><b>npm test</b></i>, <i><b>npm stop</b></i>, and <i><b>npm restart</b></i> are direct aliases for <i><b>npm run start</b></i>, <i><b>npm run test</b></i>, <i><b>npm run stop</b></i>, and <i><b>npm run restart</b></i>, respectively. This simplifies their invocation.


title: HISTORY
content:
Script execution has been a core feature of the Node Package Manager (<b>npm</b>) since its early days, making it an integral part of the Node.js development workflow. The full command, <b>npm run-script</b>, was later aliased to the more convenient and widely used <b>npm run</b> for brevity. Its evolution has closely mirrored the growth of the Node.js and JavaScript ecosystems, adapting to new project structures like monorepos with features like workspace support, and remaining a central tool for task automation.


title: SYNOPSIS
content:
<b>npm run</b> <i>&lt;script-name&gt;</i> [<b>--</b> <i>&lt;args&gt;...</i>]<br><b>npm run</b> [<i>&lt;script-name&gt;</i>]<br><i>(Man page name: <b>npm-run-script</b>)</i>


title: PARAMETERS
content:
<b><i>&lt;script-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the script defined in the <b>scripts</b> section of <b>package.json</b>. If omitted, <b>npm run</b> will list all available scripts.<br><br><b><b>--</b> <i>&lt;args&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special separator that indicates all subsequent arguments should be passed directly to the executed script, rather than being interpreted by <b>npm</b> itself.<br><br><b><b>--silent</b>, <b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output from npm itself (e.g., info messages, progress bars), showing only the standard output and error of the executed script.<br><br><b><b>--if-present</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If the specified script is not found in <b>package.json</b>, <b>npm run</b> will exit without an error. If the script is found, it behaves normally.<br><br><b><b>--ignore-scripts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the execution of pre- and post-lifecycle scripts that would normally run in conjunction with the specified script.<br><br><b><b>--workspace</b> <i>&lt;name&gt;</i>, <b>-w</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the script within a specific npm workspace by its name.<br><br><b><b>--workspaces</b>, <b>-ws</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the script in all configured workspaces within the current project.<br><br>


title: DESCRIPTION
content:
The <b>npm run</b> command (documented as <b>npm-run-script</b>) is a fundamental utility within the npm ecosystem for executing arbitrary commands defined in a project's <b>package.json</b> file. It allows developers to automate common tasks such as building, testing, starting development servers, linting, and more. When executed, <b>npm run</b> searches for a script with the specified name in the <b>scripts</b> object of the current <b>package.json</b>. If found, it executes the corresponding command in a subshell (e.g., <b>sh</b> on Unix-like systems, <b>cmd.exe</b> on Windows).<br><br>A key feature of <b>npm run</b> is its automatic modification of the <b>PATH</b> environment variable to include the <b>node_modules/.bin</b> directory. This means that local executables (like <b>webpack</b>, <b>eslint</b>, <b>jest</b>, etc.) installed as development dependencies can be run directly by their name without needing to specify their full path. Beyond user-defined scripts, <b>npm run</b> also handles special lifecycle scripts (like <b>preinstall</b>, <b>postinstall</b>, <b>pretest</b>, <b>postbuild</b>), ensuring that certain actions are performed before or after other npm commands or custom scripts.


title: CAVEATS
content:
Scripts executed by <b>npm run</b> are run in a subshell. This means that their behavior can differ slightly depending on the operating system and the specific shell environment (e.g., <b>bash</b> or <b>zsh</b> on Unix-like systems versus <b>cmd.exe</b> or PowerShell on Windows). Users should be aware of these shell-specific nuances, especially when writing cross-platform scripts.<br><br>It's crucial to exercise caution when running scripts from untrusted or unknown sources, as they have the capability to execute arbitrary commands on your system, potentially leading to security vulnerabilities or unintended system modifications.


title: LIFECYCLE SCRIPTS
content:
For any script named <i>&lt;script-name&gt;</i>, <b>npm</b> will automatically run a <b>pre<i>&lt;script-name&gt;</i></b> script before it and a <b>post<i>&lt;script-name&gt;</i></b> script after it (if defined in <b>package.json</b>). For example, <b>npm run build</b> would trigger <b>prebuild</b>, then <b>build</b>, then <b>postbuild</b>. This mechanism provides hooks for preparatory and cleanup tasks.


title: DEFAULT SCRIPTS
content:
Certain script names have special significance or aliases: <b>start</b> (can be run directly as <b>npm start</b>), <b>test</b> (<b>npm test</b>), <b>stop</b> (<b>npm stop</b>), and <b>restart</b> (<b>npm restart</b>). These commands are essentially shortcuts for <b>npm run &lt;script-name&gt;</b>. Additionally, if a <b>start</b> script is not defined, <b>npm start</b> defaults to running <b>node server.js</b>.


title: ENVIRONMENT VARIABLES
content:
When a script is executed, <b>npm</b> populates the environment with various variables. These include <b>npm_package_<i>&lt;field&gt;</i></b> (e.g., <b>npm_package_name</b>, <b>npm_package_version</b>, derived from <b>package.json</b> fields), and ensures that the <b>node_modules/.bin</b> directory is added to the <b>PATH</b>, allowing local binaries to be run directly by name without a full path.


title: EXIT CODES
content:
The exit code of <b>npm run</b> is typically the exit code of the executed script. If the script fails (exits with a non-zero code), <b>npm run</b> will also exit with that non-zero code, making it suitable for use in continuous integration (CI) environments or shell scripting for error handling.


title: HISTORY
content:
The <b>npm run-script</b> functionality, commonly accessed via <b>npm run</b>, has been a core and foundational feature of npm since its early versions, establishing npm as a robust task runner for Node.js projects. It quickly became the de facto standard for defining and executing project-specific commands, offering a simpler, built-in alternative to more complex external build systems or Makefiles. Its integration with <b>package.json</b> streamlined project setup and task automation, allowing developers to define and share common workflows directly within their project's metadata. Over the years, while the core functionality remained consistent, <b>npm run</b> has evolved to support modern development patterns, notably with the introduction of npm workspaces, enhancing its capability for managing scripts across monorepos and complex project structures.


title: SYNOPSIS
content:
<b>npm search</b> <i>&lt;search terms&gt;</i> [<i>&lt;options&gt;</i>]<br><b>npm search</b> [<i>&lt;@scope&gt;/</i>]<i>&lt;search terms&gt;</i> [<i>&lt;options&gt;</i>]


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output search results in <i>JSON</i> format for programmatic consumption.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display extended information for each search result.<br><br><b>--parseable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output search results in a machine-readable, tab-separated format.<br><br><b>--color <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control colorized output (e.g., <i>always</i>, <i>false</i>).<br><br><b>--search.prefer-online</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prioritize online registry over local cache for search.<br><br><b>--search.description</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package descriptions in the search criteria.<br><br><b>--search.keywords</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package keywords in the search criteria.<br><br><b>--search.author</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package author names in the search criteria.<br><br><b>--search.maintainer</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package maintainer names in the search criteria.<br><br><b>--search.homepage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package homepage URLs in the search criteria.<br><br><b>--search.repository</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package repository URLs in the search criteria.<br><br><b>--registry <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom registry URL to search against.<br><br>


title: DESCRIPTION
content:
<i>npm search</i> is a powerful command-line utility that allows developers to search the vast npm registry for JavaScript packages and modules. It facilitates the discovery of new libraries, tools, and frameworks by matching user-provided keywords against package names, descriptions, keywords, and other metadata fields. When executed, <i>npm search</i> queries the online registry, returning a list of matching packages along with their current version, a brief description, and sometimes author information. This command is invaluable for exploring the Node.js ecosystem, finding solutions to specific programming challenges, or identifying alternatives to existing dependencies. It operates by indexing package metadata, providing a fuzzy search capability that helps users find relevant results even with approximate terms. The results are typically displayed in a human-readable table, but can also be formatted as JSON or in a parseable format for scripting purposes. An active internet connection is required to use this command as it interacts directly with the npm registry.


title: CAVEATS
content:
<i>npm search</i> relies on an active internet connection to query the npm registry. The search index used by npm may not be immediately updated with the very latest package publications or metadata changes, leading to a slight delay in results. The quality and relevance of search outcomes are highly dependent on the accuracy and completeness of the metadata provided by package publishers. Search operations can sometimes be slower depending on network conditions and registry load.


title: SEARCH INDEXING
content:
<i>npm search</i> operates by querying a pre-indexed database of package metadata on the npm registry. This index is periodically updated, meaning that very recently published packages might not appear in search results immediately. The search algorithm performs a fuzzy match across various metadata fields to provide comprehensive results.


title: SEARCH SCOPE
content:
By default, <i>npm search</i> looks across all publicly available packages on the configured npm registry. It can also find packages within a specific scope (e.g., <i>@myscope/mypackage</i>) by including the scope in the search terms. The search capabilities are limited to the metadata stored in the registry and do not involve local file system scanning.


title: HISTORY
content:
The <i>npm search</i> command has been a fundamental part of the <i>npm CLI</i> since its early days, serving as the primary tool for package discovery within the Node.js ecosystem. Its core functionality has remained consistent, allowing users to efficiently find packages by keywords. Over time, improvements have focused on enhancing the search index's speed and relevance, as well as providing more granular control over search criteria through options like <i>--search.&lt;field&gt;</i>. It reflects <i>npm</i>'s commitment to making the vast collection of open-source JavaScript modules easily accessible to developers.


title: SYNOPSIS
content:
<code><b>keepnote</b></code> [<i>options</i>] [<i>notebook_path</i>]<br>The command primarily launches the KeepNote graphical user interface (GUI).


title: PARAMETERS
content:
<b><code>--help</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message outlining available command-line options and then exits.<br><br><b><code>--version</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the KeepNote application version number and then exits.<br><br><b><i>notebook_path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the file system path to a KeepNote notebook directory (e.g., <code>~/MyNotes.nb</code>) to open directly upon launching the application. If omitted, KeepNote will typically open the last used notebook or prompt the user to select or create one.<br><br>


title: DESCRIPTION
content:
KeepNote is a desktop note-taking application designed for organizing notes in a hierarchical tree structure. It supports rich-text formatting, allowing users to customize fonts, colors, and styles, and to embed images directly into notes. The application also facilitates attaching files and creating hyperlinks between notes or to external resources. Users can create multiple notebooks, each serving as a separate knowledge base.<br><br>Key features include a built-in screenshot tool, a robust full-text search capability across all notes within a notebook, automatic saving, and an incremental backup system. Notes are stored in a simple, open file format, typically as HTML or XML files within a directory structure, making them easily accessible, manageable, and portable without the KeepNote application itself. Its design emphasizes simplicity and offline usability, making it suitable for personal knowledge management.


title: CAVEATS
content:
KeepNote's development has largely stalled since the early 2010s, meaning it is not actively maintained or receiving updates for new features or security vulnerabilities. This lack of ongoing development can lead to compatibility issues with newer Python or GTK versions on modern Linux distributions, and users might find it difficult to install it from official package repositories. Due to its unmaintained status, users seeking a actively developed and supported note-taking solution are generally advised to consider more modern alternatives.


title: FILE FORMAT
content:
KeepNote stores its notes in a user-readable and open format. Each note is typically saved as an HTML or XML file, and any attached files are stored directly alongside them within a simple directory structure. This structure mirrors the hierarchical organization seen in the GUI. This design choice makes notes extremely portable, easy to back up, synchronize, and even accessible or parsable using standard file tools or web browsers without the need for the KeepNote application itself.


title: BACKUP SYSTEM
content:
One of KeepNote's notable features is its integrated incremental backup system. The application automatically saves previous versions of notes, allowing users to revert to earlier states. This robust feature provides a safeguard against accidental deletions, modifications, or data corruption, ensuring that note history is preserved.


title: HISTORY
content:
KeepNote was initially developed by Matt Rasmussen, with its first public releases emerging around 2008-2009. It was conceived as a lightweight, cross-platform (though most commonly used on Linux) tool for hierarchical note organization, prioritizing simplicity and robustness. Active development continued for several years, during which features such as rich-text editing, full-text search, and a robust incremental backup system were implemented. However, updates and active development significantly slowed down and effectively ceased around 2011-2012, leaving the project largely unmaintained in the subsequent years. Despite its unmaintained status, its simple and open file format allowed for continued usability for some time, though it has since been largely superseded by more contemporary note-taking solutions.


title: SEE ALSO
content:
<i>cherrytree(1)</i>: A hierarchical note-taking application with rich text, code highlighting, and support for various data types., <i>zim(1)</i>: A desktop wiki for note-taking, supporting multiple markups and extensibility via plugins., <i>xournal(1)</i>: For handwritten notes, sketching, and annotating PDFs., <i>grep(1)</i>: Useful for command-line searching of text patterns within KeepNote's plain-text/HTML note files.


title: PARAMETERS
content:
<b><b>-e</b>, <b>--command</b>=<i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>COMMAND</i> instead of the default shell.<br><br><b><b>-t</b>, <b>--title</b>=<i>TITLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the window title for the terminal.<br><br><b><b>-g</b>, <b>--geometry</b>=<i>GEOMETRY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial size and position of the window (e.g., <i>80x24+100+100</i>).<br><br><b><b>-s</b>, <b>--hide-tab</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides the tab bar. By default, the tab bar is shown if there's more than one tab.<br><br><b><b>-w</b>, <b>--working-directory</b>=<i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial current working directory for the terminal session to <i>DIR</i>.<br><br><b><b>--tab</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new tab in an existing <i>lxterminal</i> instance, or a new window if no instance is running.<br><br><b><b>--role</b>=<i>ROLE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the X window role property.<br><br><b><b>--session</b>=<i>SESSION_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the X session name property.<br><br><b><b>--display</b>=<i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>lxterminal</i> version information and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message with available command-line options and exits.<br><br>


title: DESCRIPTION
content:
<i>lxterminal</i> is a fast, lightweight, and tabbed terminal emulator, serving as the default for the LXDE (Lightweight X11 Desktop Environment) and often used within LXQt. It's designed to be resource-efficient, making it an excellent choice for systems with limited hardware resources or users who prefer a minimalist command-line interface.<br><br>While providing core terminal functionalities like executing commands, supporting shell interaction, and managing multiple tabs, <i>lxterminal</i> focuses on speed and low memory usage. It offers essential customization options for fonts, colors, and keybindings, ensuring a comfortable user experience without the overhead of more feature-rich alternatives. It's built using the GTK+ toolkit.


title: CAVEATS
content:
While efficient, <i>lxterminal</i> may lack advanced features such as split panes, extensive plugin architectures, or highly sophisticated scripting capabilities found in more feature-rich terminal emulators like <i>Terminator</i> or <i>Kitty</i>. Its primary focus remains on being lightweight and fast for general command-line usage within desktop environments like LXDE/LXQt.


title: CONFIGURATION FILE
content:
User-specific settings for <i>lxterminal</i> are typically stored in a configuration file, often located at <i>~/.config/lxterminal/lxterminal.conf</i>. This file contains preferences for appearance, behavior, and keybindings.


title: GUI CUSTOMIZATION
content:
Most customization options, including font, colors, scrollback buffer size, and cursor style, can be easily configured through <i>lxterminal</i>'s graphical preferences dialog, accessible from its menu.


title: HISTORY
content:
<i>lxterminal</i> was developed as an integral part of the LXDE (Lightweight X11 Desktop Environment) project, which began around 2006. Its creation was driven by the need for a terminal emulator that was both functional and exceptionally lightweight, aligning with LXDE's core philosophy of providing a fast desktop experience on older or less powerful hardware. It quickly became the default terminal for LXDE and remains a popular choice for resource-constrained systems due to its efficiency and simplicity.


title: PARAMETERS
content:
<b><I>hostname</I>|<I>ip_address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target mainframe's network address (hostname or IP address) to establish the connection.<br><br><b>-p <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the TCP port number for the connection, commonly 23 for Telnet or 3270 for TN3270 sessions.<br><br><b>-t <I>term_type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the terminal emulation type, such as <I>IBM-3278-2</I>, <I>IBM-3279-2</I>, or <I>IBM-3279-5</I>, to match the mainframe's expected display configuration.<br><br><b>-s <I>session_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a unique identifier for a particular session, useful for managing multiple connections.<br><br><b>-f <I>config_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads connection and session parameters from a specified configuration file, allowing for predefined settings.<br><br><b>-L <I>log_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables logging of session activity, including data exchanged, to the designated log file path.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and usage information.<br><br>


title: DESCRIPTION
content:
The <b>mfterm</b> command is a proprietary utility provided by Micro Focus as part of their enterprise software suite, primarily functioning as an IBM 3270 terminal emulator. Unlike standard Linux commands, it is not typically found in common operating system distributions. Its core purpose is to facilitate secure and interactive communication with IBM mainframe systems, allowing users to access applications like TSO, CICS, and IMS from a Linux environment. The command provides a character-based interface that mimics the behavior and display of an IBM 3270 series terminal. Due to its commercial and specialized nature, comprehensive public documentation (such as standard <i>man</i> pages) is scarce. Users are advised to consult the specific documentation provided with their Micro Focus product installation for definitive details on its usage, options, and capabilities.


title: CAVEATS
content:
The <b>mfterm</b> command is a proprietary component of Micro Focus software products and is not a standard, open-source, or universally available Linux utility. Its presence, behavior, and specific command-line options are entirely dependent on the Micro Focus product installation and version. Generic Linux documentation or online resources typically do not cover this command. Users should always refer to the official documentation provided by Micro Focus with their licensed software.


title: TYPICAL USAGE ENVIRONMENT
content:
<b>mfterm</b> is predominantly utilized in corporate or development environments where access to IBM mainframes is required. This often includes mainframe application developers, system administrators managing mainframe-connected resources, or end-users running specific enterprise applications. It integrates within a larger Micro Focus ecosystem, often alongside tools for application re-hosting, development, or testing.


title: HISTORY
content:
The <b>mfterm</b> utility is part of Micro Focus's historical dedication to providing robust enterprise solutions, particularly in the realm of mainframe connectivity and modernization. Its development lineage traces back to the need for reliable terminal emulation tools that could operate across various Unix and Linux environments, bridging legacy IBM mainframe systems with modern IT infrastructures. While specific version histories are tied to Micro Focus product releases, its existence reflects a long-standing requirement in corporate environments for accessing mainframe applications from diverse platforms.


title: PARAMETERS
content:
<b><b>-r</b>, <b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs raw, space-separated data, ideal for scripting.<br><br><b><b>-s</b>, <b>--summary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a human-readable summary (default output format).<br><br><b><b>-x</b>, <b>--xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates output in XML format, suitable for machine parsing.<br><br><b><b>-p</b> <I>format_string</I>, <b>--print</b> <I>format_string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows custom output formatting using specified variables. Refer to 'Format String for -p' in 'Additional Information'.<br><br><b><b>-t</b>, <b>--tags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only information related to ID3 tags (ID3v1 and ID3v2).<br><br><b><b>-F</b>, <b>--frames</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides detailed information about each MP3 frame, resulting in very verbose output.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates debug output for troubleshooting.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>mp3info</b> command is a versatile utility designed to extract and display detailed metadata from MP3 audio files. It parses both the MP3 frame headers and embedded <I>ID3 tags</I> (including ID3v1 and ID3v2), providing a comprehensive overview of a song's properties without needing to play the file.<br><br>Users can retrieve essential information such as the <I>bitrate</I>, <I>sample rate</I>, <I>channel mode</I> (stereo/mono), and <I>duration</I>. Furthermore, it can read and present standard ID3 tag fields like <I>artist</I>, <I>title</I>, <I>album</I>, <I>year</I>, <I>genre</I>, <I>comments</I>, <I>track number</I>, and <I>URL</I>.<br><br><b>mp3info</b> is invaluable for quick file inspection, batch processing, and scripting tasks, allowing users to organize or verify their MP3 collections efficiently. Its various output formats, including human-readable summary, raw data, and XML, make it adaptable to different use cases.


title: CAVEATS
content:
While highly useful, <b>mp3info</b>'s accuracy depends on the MP3 file's integrity and adherence to standards. Malformed MP3 headers or corrupt <I>ID3 tags</I> might lead to incorrect data or errors. It typically relies on the <I>id3lib</I> library, so its capabilities and <I>ID3v2</I> tag support may vary slightly with different versions of the underlying library. It might not be installed by default on all Linux distributions.


title: FORMAT STRING FOR -P
content:
The <b>-p</b> or <b>--print</b> option allows users to customize the output format using a string with special variables. Each variable represents a specific piece of information:<br><br><b>%f</b>: Filename<br><b>%a</b>: Artist<br><b>%t</b>: Title<br><b>%l</b>: Length (in seconds)<br><b>%r</b>: Bitrate (in kbps)<br><b>%g</b>: Genre<br><b>%y</b>: Year<br><b>%c</b>: Comment<br><b>%n</b>: Track Number<br><b>%u</b>: URL<br><b>%v</b>: ID3v2 tag presence (0 for no, 1 for yes)<br><b>%C</b>: Channels (e.g., Stereo, Mono)<br><b>%S</b>: Sample Rate (in Hz)<br><br>Example usage: <b>mp3info -p &quot;%f - %a - %t [%r kbps]&quot; my_song.mp3</b>


title: OUTPUT FORMATS
content:
<b>mp3info</b> offers several output formats for different needs:<br><br><I>Summary (Default)</I>: A human-readable, nicely formatted output showing key MP3 and ID3 tag information.<br><I>Raw (-r)</I>: Presents data in a space-separated format, optimized for easy parsing by scripts.<br><I>XML (-x)</I>: Provides structured output in XML, beneficial for integration with other applications or advanced scripting.<br><I>Custom (-p)</I>: Allows complete control over the output structure and content using format strings.


title: HISTORY
content:
The <b>mp3info</b> utility is a component of the <I>id3lib</I> project, which is a C++ library designed for robust reading, writing, and manipulation of both <I>ID3v1</I> and <I>ID3v2</I> tags in MP3 files. Its development paralleled the evolution of the <I>ID3 tag</I> standard, ensuring compatibility with various tag versions. It gained widespread adoption in Linux environments as a reliable command-line tool for scripting and batch processing of MP3 metadata due to its simplicity and powerful formatting options.


title: SYNOPSIS
content:
<b>mp4box</b> [<i>options</i>] [<i>input_file</i>] [<i>output_file</i>]<br><b>mp4box</b> -<i>command</i> [<i>options</i>] <i>file1</i> ... <i>fileN</i>


title: PARAMETERS
content:
<b>-add <i>file[:opt]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new media track from the specified <i>file</i> to the MP4. Options can include stream type, language, track ID, etc.<br><br><b>-cat <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Concatenates an existing MP4 <i>file</i> to the end of the current file.<br><br><b>-split <i>time</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Splits the input MP4 file into multiple files, each up to the specified <i>time</i> (in seconds).<br><br><b>-split-size <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Splits the input MP4 file into multiple files, each up to the specified <i>size</i> (in kilobytes).<br><br><b>-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the MP4 file, including track details, codecs, and metadata.<br><br><b>-hint</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hints the MP4 file for streaming over RTP/RTSP, creating dedicated hint tracks for efficient delivery.<br><br><b>-raw <i>trackID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts the raw bitstream of a specified <i>trackID</i> from the MP4 file.<br><br><b>-rem <i>trackID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified <i>trackID</i> from the MP4 file.<br><br><b>-chap <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds chapters to the MP4 file from a specified <i>file</i> (e.g., a text file with chapter markers).<br><br><b>-dash <i>file[:opt]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates MPEG-DASH (Dynamic Adaptive Streaming over HTTP) segments and manifest files for the given input MP4. Many options are available for DASH profiles, segment duration, etc.<br><br><b>-frag <i>duration</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fragments the MP4 file into movie fragments (moof atoms) of a specified <i>duration</i> (in milliseconds). Useful for progressive download and streaming.<br><br><b>-lang <i>trackID:lang</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the language code (e.g., 'eng', 'fre') for a specified <i>trackID</i>.<br><br><b>-clap <i>w:h:x:y</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the clean aperture box dimensions for a video track, specifying width, height, X offset, and Y offset.<br><br><b>-par <i>num:den</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the pixel aspect ratio (numerator:denominator) for a video track.<br><br><b>-set-MIME <i>MIME_type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the MIME type of the file. Useful for web servers.<br><br>


title: DESCRIPTION
content:
<i><b>mp4box</b></i> is a versatile command-line utility for manipulating and inspecting MP4 files, which conform to the ISO Base Media File Format. It is an integral part of the <B>GPAC</B> (Graph for Advanced Content) project, an open-source multimedia framework. <i><b>mp4box</b></i> allows users to perform a wide array of operations on MP4 files, including multiplexing raw audio/video streams (e.g., H.264, AAC) into an MP4 container, demultiplexing tracks, concatenating or splitting files, hinting files for streaming (e.g., RTP/RTSP), encrypting/decrypting tracks, and injecting metadata like chapters or pixel aspect ratios. It's widely used in multimedia development, streaming preparation, and content packaging workflows due to its robust feature set and adherence to industry standards.


title: CAVEATS
content:
<i><b>mp4box</b></i> can be memory-intensive for large files or complex operations, potentially creating large temporary files. Its command-line syntax, particularly for advanced features like DASH or encryption, can be intricate and require careful attention to options and their order. Incorrect usage can lead to corrupted or unplayable files. It's recommended to test operations on copies of original files.


title: COMMON USE CASES
content:
<ul><li><i>Preparing content for web streaming</i>: Using <code>-dash</code> or <code>-frag</code> to create fragmented MP4s and DASH manifests.</li><li><i>Multiplexing media</i>: Combining raw H.264 video and AAC audio into a single MP4 file.</li><li><i>Extracting streams</i>: Separating audio or video tracks from an existing MP4.</li><li><i>Adding metadata</i>: Injecting chapter markers, language codes, or copyright information.</li><li><i>File inspection</i>: Using <code>-info</code> to debug MP4 file structures or verify compliance.</li></ul>


title: INTEROPERABILITY
content:
<i><b>mp4box</b></i> adheres to international standards for the ISO Base Media File Format, ensuring high interoperability with other tools and platforms that support MP4. This makes it a reliable choice for workflows where compatibility across different media players, web browsers, and streaming services is crucial.


title: HISTORY
content:
<i><b>mp4box</b></i> is part of the GPAC project, which began development around 2000. It was created to provide a comprehensive toolset for working with MPEG-4 systems, including the ISO Base Media File Format (MP4). Over the years, it has evolved significantly, incorporating support for advanced features like MPEG-DASH, HEVC, and various DRM schemes, becoming a go-to tool for developers and content providers in the multimedia industry.


title: SYNOPSIS
content:
mypy [options] [files/directories ...]<br>mypy --module &lt;module_name&gt;<br>mypy --package &lt;package_name&gt;<br>mypy --command &lt;command_string&gt;


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's help message and exit.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable all strict type checking flags. This is equivalent to enabling a large set of individual strictness checks, promoting higher code quality.<br><br><b>--ignore-missing-imports</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress errors about imports that cannot be resolved. Useful for libraries without type stubs or when external dependencies are not fully typed.<br><br><b>--disallow-untyped-defs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report an error for any function that has no type annotations.<br><br><b>--no-implicit-optional</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate an error for arguments with a default value of <i>None</i> in a function if the type annotation is not <i>Optional</i>.<br><br><b>--warn-unused-ignores</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report an error if a # type: ignore comment is unnecessary.<br><br><b>--warn-return-any</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Warn whenever an explicit <i>Any</i> type is returned.<br><br><b>--config-file &lt;PATH&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read configuration from the specified file. Defaults to mypy.ini, setup.cfg, or pyproject.toml in the current directory or parent directories.<br><br><b>--pretty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use nicer error messages, such as colored output (if supported by terminal) and showing source code snippets.<br><br><b>--show-column-numbers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show column numbers in error messages.<br><br><b>--python-version &lt;X.Y&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified Python version for checking (e.g., <i>3.8</i>).<br><br><b>--install-types</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install missing type stubs for imported modules interactively.<br><br><b>--exclude &lt;PATTERN&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the given regular expression pattern.<br><br><b>--namespace-packages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable support for PEP 420 namespace packages.<br><br><b>--incremental</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable incremental checking (default). <i>mypy</i> will only re-check files that have changed, or files that depend on them.<br><br><b>--no-incremental</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable incremental checking, forcing a full re-check.<br><br><b>--cache-dir &lt;DIR&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Store and retrieve incremental build cache data from the specified directory.<br><br><b>--follow-imports &lt;MODE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;How to follow imports: <i>normal</i> (default), <i>silent</i>, <i>skip</i>, <i>error</i>.<br><br><b>--warn-no-return</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Warn if a function is not annotated as returning <i>None</i> but does not explicitly return a value.<br><br>


title: DESCRIPTION
content:
mypy is a static type checker for Python. It checks your Python code against type hints (introduced in PEP 484) to find common programming errors before your code ever runs. By analyzing your program's type annotations, <i>mypy</i> can catch issues like incorrect argument types, missing attributes, or incompatible assignments, significantly improving code reliability and maintainability. It helps developers write more robust and self-documenting code, especially in large codebases, by ensuring that functions are called with the expected types and variables are used consistently. <i>mypy</i> acts as a valuable development tool that complements unit testing and runtime checks, providing an early warning system for potential type-related bugs.


title: CAVEATS
content:
mypy can be slow on large codebases without proper caching or incremental builds. It requires type hints, which adds verbosity to code but improves clarity. It does not catch runtime errors or logic errors. Not all third-party libraries provide type stubs, potentially leading to the need for <i>--ignore-missing-imports</i> or the use of <i>Any</i> types.


title: TYPE HINTING (PEP 484)
content:
<i>mypy</i> relies heavily on type hints, which are annotations in Python code that indicate the expected types of variables, function arguments, and return values. PEP 484 formalized these hints, making them a standard part of Python syntax.


title: CONFIGURATION FILES
content:
<i>mypy</i>'s behavior can be extensively configured using files like <i>mypy.ini</i>, <i>setup.cfg</i>, or <i>pyproject.toml</i>. These files allow users to set global options, per-module options, and define custom error codes, providing fine-grained control over the type checking process.


title: INTEGRATION WITH IDES/EDITORS
content:
Many modern Integrated Development Environments (IDEs) and text editors (e.g., VS Code, PyCharm, Sublime Text) have built-in support or plugins for <i>mypy</i>, providing real-time type checking feedback as you write code, enhancing the development experience.


title: HISTORY
content:
<i>mypy</i> was initially developed by Jukka Lehtosalo at Dropbox in 2013, predating the official introduction of type hints in Python 3.5 (PEP 484) in 2015. It served as a proof of concept and a driving force behind the standardization of type hints in Python. Since then, <i>mypy</i> has become the reference implementation for static type checking in Python and is actively maintained and developed by the Python community, with contributions from various companies and individual developers. Its adoption has grown significantly, especially in large-scale Python projects, due to its ability to improve code quality and maintainability.


title: PARAMETERS
content:
<b>-o <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output file (e.g., executable, object file, or library).<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile or assemble the source files, but do not link. Output an object file (.o).<br><br><b>-I <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add directory <I>dir</I> to the list of directories to be searched for include files.<br><br><b>-L <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add directory <I>dir</I> to the list of directories to be searched for libraries.<br><br><b>-l <lib></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Link with the specified library <I>lib</I> (e.g., -lcuda, -lcudart).<br><br><b>-D <macro>[=<value>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define a preprocessor macro, optionally with a value.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate debugging information for the compiled code.<br><br><b>-O[0-3]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the optimization level. Higher levels (e.g., -O3) apply more aggressive optimizations.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the compiler version information.<br><br>


title: DESCRIPTION
content:
The command 'ncc' is <I>not a standard or widely recognized Linux command</I> or utility found in typical distributions. It most likely refers to the <B>NVIDIA Compute Compiler</B> or <B>NVIDIA C/C++ Compiler</B>, which is a component within the NVIDIA CUDA Toolkit or NVIDIA HPC SDK.<br><br>While users primarily interact with the <I>nvcc</I> driver for CUDA compilation or <I>nvc</I>/<I>nvc++</I> for host compilation in the HPC SDK, 'ncc' historically or internally might refer to a specific phase or a backend compiler for C/C++ code. It's designed to compile C and C++ source files, potentially targeting both CPU (host) architectures and NVIDIA GPU (device) architectures, depending on its specific role within the NVIDIA toolchain.<br><br>Its exact user-facing functionality, if any, is usually subsumed or orchestrated by higher-level compiler drivers.


title: CAVEATS
content:
The command 'ncc' is <B>not a standard Linux command</B> and does not have a dedicated man page in typical Linux distributions. Its direct availability and functionality as a user-invokable command are highly dependent on specific NVIDIA software installations (CUDA Toolkit, HPC SDK) and might refer to an internal component or an older/less common naming convention. Users typically interact with <I>nvcc</I> for CUDA compilation or <I>nvc</I>/<I>nvc++</I> for C/C++ host compilation provided by NVIDIA. Direct usage of 'ncc' by end-users is uncommon.


title: ROLE IN COMPILATION PIPELINE
content:
Within the NVIDIA compilation toolchain, especially for CUDA, the process involves multiple stages: preprocessing, compilation to PTX (Parallel Thread Execution) intermediate representation, assembly to SASS (Streaming Assembler) for specific GPU architectures, and linking. 'ncc' could conceptually represent a stage in this pipeline, such as compiling C/C++ host code or a specific phase of device code compilation before it's passed to other specialized tools (e.g., PTX assembler or linker). It acts as a specialized C/C++ compiler engine tailored for NVIDIA's hardware and software ecosystem.


title: HISTORY
content:
The history of 'ncc' is intertwined with the development of NVIDIA's compiler technologies for both CPUs and GPUs. As NVIDIA expanded its ecosystem for parallel computing (CUDA) and high-performance computing (HPC SDK), its suite of compilers evolved. While 'nvcc' became the primary driver for CUDA, and 'nvc'/'nvc++' for host code, the term 'ncc' might represent an earlier or internal iteration, or a specific backend component used in the compilation pipeline managed by the main driver compilers.


title: SYNOPSIS
content:
<b>ndiswrapper</b> <i>[options]</i> <i>&lt;driver&gt;</i> <i>[interface]</i><br><br>Common usage examples:<br><b>ndiswrapper</b> <b>-i</b> <i>&lt;inf_file&gt;</i><br><b>ndiswrapper</b> <b>-l</b><br><b>ndiswrapper</b> <b>-e</b> <i>&lt;driver_name&gt;</i><br><b>ndiswrapper</b> <b>-m</b><br><b>ndiswrapper</b> <b>-a</b> <i>&lt;driver&gt;</i> <i>&lt;vendor_id&gt;</i> <i>&lt;device_id&gt;</i>


title: PARAMETERS
content:
<b>-i <inf_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>I</b>nstalls a Windows driver specified by its INF file (e.g., <i>driver.inf</i>).<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>L</b>ists currently installed Windows drivers and their associated PCI IDs.<br><br><b>-e <driver_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>E</b>rases (removes) an installed Windows driver by its name.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>M</b>akes module configuration entries for <b>ndiswrapper</b> so it loads automatically on boot.<br><br><b>-a <driver> <vendor_id> <device_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>A</b>dds a PCI Vendor ID and Device ID association to an installed driver. Useful if the driver's INF file doesn't list the specific hardware.<br><br><b>-r <vendor_id> <device_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>R</b>emoves a PCI Vendor ID and Device ID association.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>v</b>ersion of <b>ndiswrapper</b>.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a <b>t</b>est on an installed driver, checking its capabilities.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>s</b>tatus of PCI IDs currently associated with <b>ndiswrapper</b>.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>K</b>ernel module management (often used for automatic module loading).<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in <b>q</b>uiet mode, suppressing non-essential output.<br><br><b>-d <driver_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <b>d</b>ebugging output for a specific driver.<br><br>


title: DESCRIPTION
content:
<b>ndiswrapper</b> is a free software driver wrapper that allows Linux users to use Windows NDIS (Network Driver Interface Specification) wireless drivers on their systems. It was developed primarily to address the historical lack of native Linux drivers for many popular wireless network adapters, especially during the early 2000s when wireless technology became widespread. By acting as an intermediary, <b>ndiswrapper</b> translates calls from the Linux kernel to the Windows driver, effectively tricking the Windows driver into thinking it's running in its native environment. This enabled many users to get their Wi-Fi cards working without waiting for or developing open-source Linux drivers. While immensely useful in its time, <b>ndiswrapper</b>'s importance has diminished significantly as Linux kernel support for wireless chipsets has matured and improved, with many formerly problematic devices now having native, robust open-source drivers.


title: CAVEATS
content:
<i>Performance & Stability:</i> Wrapped Windows drivers may not offer optimal performance or stability compared to native Linux drivers, often leading to slower speeds, dropped connections, or system freezes.<br><i>Security Risks:</i> Running closed-source Windows drivers in the kernel space can pose security risks, as their code cannot be audited for vulnerabilities.<br><i>Compatibility:</i> <b>ndiswrapper</b> might not be compatible with all Windows drivers, especially newer ones, or with very recent Linux kernel versions.<br><i>Resource Consumption:</i> It might consume more system resources than a native driver.<br><i>Deprecation:</i> With significant improvements in Linux kernel support for wireless hardware, <b>ndiswrapper</b> is less actively developed and is generally considered a legacy solution.


title: KERNEL MODULE LOADING
content:
After installing a driver with <b>ndiswrapper -i</b> and making configuration entries with <b>ndiswrapper -m</b>, you often need to load the <b>ndiswrapper</b> kernel module. This can be done with <b>sudo modprobe ndiswrapper</b>.


title: BLACKLISTING NATIVE DRIVERS
content:
If your system has a problematic native driver for your wireless card, you might need to blacklist it (prevent it from loading) before <b>ndiswrapper</b> can effectively take control of the hardware. This is typically done by creating a <i>.conf</i> file in <i>/etc/modprobe.d/</i> with an entry like <b>blacklist <i>&lt;native_driver_name&gt;</i></b>.


title: HISTORY
content:
<b>ndiswrapper</b> emerged in the early 2000s, a period when widespread adoption of wireless networking coincided with a significant gap in open-source Linux driver support for many commercially available Wi-Fi chipsets. Faced with proprietary hardware and a lack of specifications from manufacturers, the <b>ndiswrapper</b> project offered a pragmatic solution, allowing Linux users to leverage the Windows drivers provided by hardware vendors. It quickly became an essential tool for many Linux distributions and users, enabling Wi-Fi connectivity on previously unsupported hardware. Its peak usage was probably around 2005-2010. However, as the Linux kernel community worked extensively to reverse-engineer and develop native, open-source drivers, and as hardware manufacturers began providing better Linux support, the necessity for <b>ndiswrapper</b> gradually declined. While still available, its role is now largely superseded by robust native kernel modules.


title: PARAMETERS
content:
<b><b>-i</b> <I>inf_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a Windows wireless driver from the specified <I>.inf</I> file. This is typically the first step to get a driver working.<br><br><b><b>-r</b> <I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed Windows driver by its name (usually derived from the <I>.inf</I> file name).<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently installed Windows drivers and the PCI IDs of the hardware they are configured to support.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates <I>modprobe</I> configuration files (<I>ndiswrapper.conf</I>) to ensure the <I>ndiswrapper</I> kernel module is loaded automatically at boot time.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <I>ndiswrapper</I> utility.<br><br><b><b>-a</b> <I>vendor_id</I> <I>device_id</I> <I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a specific PCI Vendor ID and Device ID mapping to an installed driver, allowing <I>ndiswrapper</I> to associate it with a particular piece of hardware.<br><br><b><b>-q</b> <I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries and displays detailed information about a specific installed driver.<br><br><b><b>-e</b> <I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables an installed driver, often used when multiple drivers are installed for the same hardware type to select the active one.<br><br><b><b>-d</b> <I>driver_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables an installed driver, preventing it from being used by <I>ndiswrapper</I>.<br><br>


title: DESCRIPTION
content:
<I>ndiswrapper</I> is a free software driver wrapper that enables Linux to use Windows (NDIS) drivers for wireless network adapters. It operates by providing a Linux kernel module that implements the Windows <I>NDIS API</I>, allowing proprietary binary-only Windows wireless drivers to function within the Linux environment.<br><br>Historically, <I>ndiswrapper</I> was crucial for Linux users, especially on laptops, as many wireless chipsets lacked native Linux driver support. While its necessity has significantly decreased with the advent of more robust native Linux drivers, it still serves as a valuable tool for supporting older, obscure, or particularly challenging wireless hardware that otherwise wouldn't work on Linux.


title: CAVEATS
content:
The <I>ndiswrapper-1.9</I> version specifically is quite old and may not be compatible with modern Linux kernels or hardware. Generally, <I>ndiswrapper</I> has several limitations:<br><br>- Requires access to the original Windows <I>.inf</I> and <I>.sys</I> driver files.<br>- Not all Windows drivers will function correctly; some may cause instability or reduced performance.<br>- Performance might be inferior compared to native Linux drivers.<br>- There are potential security concerns with running proprietary binary blobs from unknown sources.<br>- Its relevance has significantly decreased due to improved native Linux driver support for most common wireless chipsets.


title: HOW IT WORKS
content:
<I>ndiswrapper</I> comprises a kernel module that acts as a compatibility layer. It translates calls from the Linux kernel's network stack into the <I>NDIS API</I> calls that the Windows driver expects, and vice-versa. This allows the Windows <I>.sys</I> driver file to be loaded into the Linux kernel space and manage the wireless hardware as if it were running on Windows.


title: PCI IDS
content:
<I>ndiswrapper</I> uses the PCI Vendor ID and Device ID (e.g., 14E4:4318) to identify specific hardware. When you install a driver, <I>ndiswrapper</I> reads these IDs from the <I>.inf</I> file and stores them, associating the Windows driver with the corresponding hardware. This allows the correct driver to be loaded when the hardware is detected.


title: HISTORY
content:
Developed in the mid-2000s, <I>ndiswrapper</I> quickly became an essential utility for Linux users struggling with unsupported wireless adapters. Version 1.9, released around 2005-2006, was one of the earlier stable releases that saw widespread adoption. Its creation filled a critical gap, making Linux viable on many laptops that would otherwise lack Wi-Fi functionality. While its importance has waned over the years as native Linux kernel support for wireless hardware improved, <I>ndiswrapper</I> remains a testament to the open-source community's ingenuity in overcoming hardware compatibility challenges.


title: SYNOPSIS
content:
<b>nc</b> [<i>options</i>] <i>hostname</i> <i>port</i><br><b>nc</b> <b>-l</b> [<i>options</i>] [<i>port</i>]


title: PARAMETERS
content:
<b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Listen mode</i>: Instructs netcat to listen for an incoming connection rather than initiating one.<br><br><b><b>-p</b> <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Local port</i>: Specifies the source port for outgoing connections or the listening port when in <i>listen mode</i> (alternative to simply providing <i>port</i> after <b>-l</b>).<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>UDP mode</i>: Uses <i>UDP</i> instead of the default <i>TCP</i> protocol.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verbose mode</i>: Provides more detailed output, useful for debugging and understanding connection status. Can be repeated (e.g., <b>-vv</b>) for even more verbosity.<br><br><b><b>-w</b> <i>timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Timeout</i>: Specifies a connection timeout in seconds. Netcat will close the connection if idle for this duration.<br><br><b><b>-z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Zero-I/O mode</i>: Performs a port scan without sending any data. Useful for quick port checking.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Keep open</i>: Forces netcat to stay listening for multiple connections after the first client has disconnected (only applicable in <i>listen mode</i> with <b>-l</b>).<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Numeric-only IP addresses</i>: Disables <i>DNS</i> lookups, forcing netcat to use only numeric IP addresses. This can speed up operations and avoid <i>DNS</i> issues.<br><br><b><b>-q</b> <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Quit after EOF on stdin</i>: Exits after <i>EOF</i> on stdin for the client. If <i>seconds</i> is specified, waits that long after <i>EOF</i> on stdin, then quits.<br><br><b><b>-4</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force IPv4</i>: Forces netcat to use <i>IPv4</i> addresses only.<br><br><b><b>-6</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force IPv6</i>: Forces netcat to use <i>IPv6</i> addresses only.<br><br>


title: DESCRIPTION
content:
Netcat, often abbreviated as <b>nc</b>, is a versatile utility designed for reading from and writing to network connections using <i>TCP</i> or <i>UDP</i> protocols.<br><br>It's widely regarded as a '<i>network Swiss army knife</i>' due to its broad range of capabilities. Users can establish arbitrary <i>TCP</i> and <i>UDP</i> connections, send raw data, listen for incoming connections, and perform various network debugging tasks.<br><br>Common applications include <i>port scanning</i> (e.g., checking if a specific service is running on a port), <i>banner grabbing</i> (retrieving initial service messages), simple <i>file transfers</i> between machines, and even basic <i>client/server</i> communication. Its simplicity combined with its powerful features makes it an indispensable tool for network administrators, security professionals, and developers for testing and debugging network-enabled applications.<br><br>While straightforward to use, its flexibility means it can also be leveraged for more advanced, and sometimes malicious, network operations.


title: CAVEATS
content:
Due to its powerful and flexible nature, <b>netcat</b> can be misused for malicious activities like creating backdoors or launching attacks. Therefore, its usage should always be within legal and ethical boundaries.<br><br>It's important to note that there are several implementations of <b>netcat</b> (e.g., <i>OpenBSD netcat</i>, <i>traditional netcat</i>, <i>GNU ncat</i>), which may have slight variations in features and command-line options. For instance, the traditional version often includes an <b>-e</b> option for program execution, which is deliberately omitted from more secure versions like <i>OpenBSD netcat</i> due to security concerns.


title: <I>COMMON USE CASES</I>
content:
<i><b>File Transfer</b>: Establish a listening <b>nc</b> on one machine (e.g., <i>nc -l -p 1234 > received_file.txt</i>) and send from another (e.g., <i>nc remote_ip 1234 < local_file.txt</i>).<br><b>Simple Chat</b>: Two users can type messages to each other after establishing a connection.<br><b>Banner Grabbing</b>: Connect to a service port (e.g., <i>nc example.com 80</i>) and press <i>Enter</i> to see the service banner (e.g., <i>HTTP server version</i>).<br><b>Port Scanning</b>: Use <b>-z</b> for quick checks (e.g., <i>nc -zv example.com 20-25</i>).<br><b>Basic Web Server/Client</b>: Serve simple <i>HTTP</i> content or make raw <i>HTTP</i> requests.</i>


title: <I>SECURITY IMPLICATIONS</I>
content:
While immensely useful, <b>netcat</b> is a powerful tool that can be exploited if not used responsibly. It's often used by attackers to create <i>bind shells</i> (where <b>netcat</b> listens for incoming connections and executes commands) or <i>reverse shells</i> (where <b>netcat</b> connects out to an attacker-controlled listener). For legitimate use, always ensure proper permissions and network security measures are in place, and be aware of which <b>netcat</b> implementation you are using, especially regarding features like <b>-e</b>.


title: HISTORY
content:
The original <b>netcat</b> was developed by <i>Hobbit</i> in 1995. It quickly gained popularity for its simplicity and power, becoming a staple in network administration and security toolkits. Over time, due to its licensing and the desire for enhanced or more secure features, various forks and reimplementations emerged. Notable versions include the widely adopted <i>OpenBSD netcat</i> (which prioritizes security and omits some features like the <b>-e</b> option), and <i>GNU ncat</i> (part of the Nmap project), which offers additional features and cross-platform compatibility. Despite these variations, the core functionality and conceptual usage remain consistent across most implementations.


title: SYNOPSIS
content:
<b>nethack-console</b> [<i>-u username</i>] [<i>-d directory</i>] [<i>-D</i>] [<i>-s</i>] [<i>-v</i>] [<i>-?</i>]


title: PARAMETERS
content:
<b><b>-u</b> <i>username</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the game for a specific <i>username</i>, overriding the default login name. This is useful for multiple players on the same system.<br><br><b><b>-d</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <i>directory</i> for saving game files and other NetHack-related data. This can be used for testing or isolating save games.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables 'explore' mode. In this mode, scores are not recorded, and players can save and restore their game without penalty, allowing for experimentation or learning without the risk of permadeath.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the scoreboard, showing the top ten (or more, depending on configuration) recorded scores without starting a new game.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>nethack-console</i> executable and then exits.<br><br><b><b>-?</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief usage message with available command-line options.<br><br>


title: DESCRIPTION
content:
<i>nethack-console</i> is the terminal-based variant of NetHack, a single-player roguelike video game. It is a descendant of the 1980 game <i>Rogue</i>. Players assume the role of a hero adventuring through a procedurally generated dungeon, fighting monsters, collecting items, and ultimately seeking the Amulet of Yendor. The game is renowned for its depth, complexity, and open-ended nature, featuring numerous character classes, races, alignments, items, spells, and monsters. Unlike graphical versions, <i>nethack-console</i> renders the entire game world using ASCII or ANSI characters, providing a minimalist yet highly functional interface. Its turn-based gameplay, permadeath (unless in exploration mode), and challenging difficulty have made it a beloved classic in the roguelike genre, offering endless replayability due to its randomized elements.


title: CAVEATS
content:
NetHack has a notoriously steep learning curve; new players may find it overwhelming. Its permadeath mechanic means a single mistake can lead to the loss of hours of progress, unless playing in explore mode. The console interface relies entirely on keyboard commands, which can be unintuitive for those accustomed to modern graphical user interfaces. It is also important to note that the game is highly complex, with many obscure interactions and hidden mechanics that often require consulting external wikis or guides.


title: GAME MECHANICS
content:
NetHack features turn-based combat, a rich inventory system, spellcasting, alignment-based gameplay affecting interactions, and a deep lore. Its procedural generation ensures each playthrough is unique. The game is notorious for its 'YASD' (Yet Another Stupid Death) moments, where unexpected circumstances lead to a player's demise, adding to its challenge and replayability.


title: ASCII GRAPHICS
content:
The console version relies on basic ASCII characters for its visual representation. For example, '@' represents the player, 'd' a dog, '$' gold, and '.' a floor tile. This design choice contributes to its classic roguelike aesthetic and allows it to run on virtually any terminal environment.


title: HISTORY
content:
NetHack was first released in 1987, evolving from the 1985 game <i>Hack</i>, which itself was inspired by the original <i>Rogue</i> (1980). It was one of the first games to introduce persistent dungeons (where a saved game's layout remains the same), a feature not present in <i>Rogue</i>. Development has been continuous by the NetHack DevTeam, a group of volunteers, making it one of the longest-supported video games. The 'console' distinction emphasizes its heritage as a terminal-based game, leveraging character graphics that preceded widespread graphical user interfaces.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits, showing available options and usage.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br><b>--api-url <URL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL endpoint of the Netris controller's API.<br><br><b>--api-key <KEY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the API key for authentication with the Netris controller.<br><br><b>--username <USER></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for authentication (if API key is not used).<br><br><b>--password <PASS></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password for authentication (if API key is not used).<br><br><b>--scenario <NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific sample scenario or task to execute from predefined options within the robot.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the actions without making any actual changes to the Netris environment.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the robot's execution and API interactions.<br><br>


title: DESCRIPTION
content:
The <i>netris-sample-robot</i> is a demonstration or template application designed to interact with the Netris network automation platform. It serves as an example for developers and network operators to understand how to build automated tasks, tests, or operational bots that leverage Netris's API. Typically, it showcases basic automation workflows such as fetching network state, applying sample configurations, or performing routine health checks.<br><br>It's not a standalone network device, but rather a client-side tool or script that executes commands and queries against a Netris controller, providing a foundational starting point for more complex custom automation scenarios tailored to specific operational needs.


title: CAVEATS
content:
This command is not a standard Linux utility but an application specific to the Netris platform. Its exact behavior, options, and arguments are entirely dependent on the specific implementation provided by Netris or a custom build. It typically requires an active Netris controller instance and proper API credentials to function correctly. Running it without understanding its specific purpose and potential impact on your Netris environment is not recommended, as it interacts directly with your network automation infrastructure.


title: COMMON USE CASES
content:
The <i>netris-sample-robot</i> is primarily used for:<br><i>1. Learning and Development:</i> Provides a hands-on example for understanding Netris API interactions and automation principles.<br><i>2. Testing and Validation:</i> Can be adapted to create automated tests for a Netris deployment or specific network configurations.<br><i>3. Starter Template:</i> Serves as a foundational script for building more complex, custom automation solutions tailored to specific operational needs.<br><i>4. Demonstrations:</i> Used to showcase Netris's automation capabilities to potential users or during training sessions.


title: HISTORY
content:
As a 'sample' application, the history of <i>netris-sample-robot</i> is typically tied to the development lifecycle of the Netris platform itself. It evolves to demonstrate new features, API capabilities, or best practices for automation with Netris. It's often updated with new Netris releases to reflect changes in the platform's API or functionalities, ensuring it remains a relevant and up-to-date example for users seeking to implement network automation.


title: SYNOPSIS
content:
<I>Disclaimer: This synopsis is illustrative, as <b>netwatch</b> is not a standard Linux command.</I><br><b>netwatch</b> [<i>OPTIONS</i>] <I>HOST</I> [<i>HOST...</i>] | -f <I>HOSTFILE</I>


title: PARAMETERS
content:
<b>-i <interval></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the interval in seconds between consecutive probes to each host. Default is typically 5 seconds.<br><br><b>-c <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of probes to send to each host before exiting. If not specified, <b>netwatch</b> would typically run indefinitely.<br><br><b>-t <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the maximum time in seconds to wait for a response to a probe. If no response is received within this time, the host is considered unreachable for that probe.<br><br><b>-f <hostfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a list of hosts to monitor from the specified file. Each host (IP address or hostname) should be on a new line.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates in quiet mode, suppressing verbose output. Only critical status changes or summaries might be displayed.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, providing more detailed information about each probe, including timestamps, latency, and status changes.<br><br><b>--logfile <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs all monitoring events and status changes to the specified file for historical analysis.<br><br><b>--no-resolve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents reverse DNS lookups for IP addresses to save time, displaying only IP addresses instead of hostnames.<br><br>


title: DESCRIPTION
content:
The command <b>netwatch</b> is not a standard, universally available Linux command found in common distributions. Instead, the name 'netwatch' often refers to custom scripts, specific third-party utilities (like those found in MikroTik RouterOS), or conceptual tools designed for network monitoring.<br><br> If a <b>netwatch</b> command were to exist as a typical Linux utility, its primary function would be to continuously monitor the connectivity and health of specified network hosts. It would likely operate by sending periodic network probes (e.g., ICMP echo requests, TCP port checks) to target IP addresses or hostnames. Its purpose would be to detect network outages, assess latency, and potentially trigger alerts or log events when host status changes. This hypothetical tool would bridge the gap between a simple <b>ping</b> command and more comprehensive monitoring systems like Nagios or Zabbix, focusing on basic reachability and uptime checks for a predefined set of targets.


title: CAVEATS
content:
The command <b>netwatch</b> is <b>not a standard utility</b> found in most Linux distributions by default. Users seeking network monitoring functionality similar to what 'netwatch' implies would typically rely on a combination of standard tools like <b>ping</b>, <b>fping</b>, custom shell scripts, or install dedicated monitoring systems (e.g., Nagios, Zabbix, Icinga). If you encounter documentation or a system mentioning 'netwatch', it likely refers to a specific, non-standard implementation or a component of a specialized network device (like MikroTik RouterOS) or a custom script developed for a particular environment. Attempting to run 'netwatch' on a typical Linux system will result in 'command not found' unless a custom version has been installed.


title: ALTERNATIVE NETWORK MONITORING APPROACHES ON LINUX
content:
Since <b>netwatch</b> is not standard, Linux users employ various methods for network host monitoring:<br><ul><li><b>Scripting with <b>ping</b>:</b> A common approach is to write a simple shell script that repeatedly runs <b>ping</b> against target hosts and parses the output for success/failure. This allows for basic uptime tracking and alerting.</li><li><b>Using <b>fping</b>:</b> The <b>fping</b> utility (often available via package managers) is designed for parallel ICMP pinging of multiple hosts, making it more efficient than scripting individual <b>ping</b> commands. It's excellent for quick reachability checks of many targets.</li><li><b>Dedicated Monitoring Systems:</b> For professional or complex environments, open-source solutions like <b>Nagios</b>, <b>Zabbix</b>, <b>Prometheus</b>, or <b>Icinga</b> provide robust frameworks. These systems offer continuous monitoring of hosts, services, network devices, and applications, including sophisticated alerting, graphing, and historical data retention capabilities.</li><li><b>Custom Python/Perl Scripts:</b> More advanced users might write scripts in languages like Python or Perl, leveraging network libraries to perform more complex checks (e.g., TCP port scans, HTTP requests) beyond simple ICMP reachability.</li></ul>


title: HISTORY
content:
Unlike core Linux utilities that have well-documented histories and consistent presence across distributions (e.g., <b>ls</b>, <b>grep</b>, <b>ping</b>), a command named <b>netwatch</b> does not have a standard development history within the GNU/Linux project or common Unix-like operating systems. Its absence implies that network monitoring functionality has historically been addressed by more specialized or modular tools. The need for continuous host monitoring is typically met by either scripting existing commands (like <b>ping</b> in a loop), using purpose-built tools like <b>fping</b> for multiple targets, or employing comprehensive network monitoring frameworks which include their own 'watchdog' components for hosts and services.


title: PARAMETERS
content:
<b>-n, --adjustment=<i>ADJUSTMENT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>ADJUSTMENT</i> to the niceness. <i>ADJUSTMENT</i> is an integer typically between -20 and 19. If omitted, the default adjustment is 10.<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:
The <i>nice</i> command is a fundamental utility in Unix-like operating systems, including Linux, used to invoke a command or program with a modified scheduling priority. This priority, known as the "niceness" value, influences how the system's CPU scheduler allocates processor time to a process. The niceness scale typically ranges from -20 (highest priority, least "nice" to other processes) to 19 (lowest priority, most "nice").<br><br>By default, most processes start with a niceness of 0. When you run a command using <i>nice</i>, you can specify an adjustment to this default value. A higher niceness value means the process is more "polite" and will yield CPU time to other processes, making it suitable for non-critical, long-running background tasks or resource-intensive computations that shouldn't hog system resources. Conversely, a lower niceness value (closer to -20) gives the process more CPU preference.<br><br>A key distinction is that <i>nice</i> is used to set the priority of a command <i>before</i> it starts executing. For adjusting the priority of an already running process, the <i>renice</i> command is used. Ordinary users are typically restricted to increasing the niceness value (making the process less demanding), while the superuser (root) can set any niceness value, including negative ones, to elevate a process's priority.


title: CAVEATS
content:
<ul><li><b>Permissions:</b> Non-root users can only increase the niceness value (make a process less prioritized) or set it to a value greater than or equal to the current niceness. Only the superuser (root) can set negative niceness values or decrease the niceness of a process to give it higher priority.</li><li><b>CPU Scheduling Only:</b> The <i>nice</i> command primarily affects CPU scheduling priority. It does not directly control I/O priority, memory usage, or network bandwidth. For I/O prioritization, the <i>ionice</i> command is typically used.</li><li><b>Not a Guarantee:</b> While <i>nice</i> provides a hint to the scheduler, the actual performance impact depends on overall system load, other running processes, and the specific scheduling algorithm implemented by the kernel (e.g., the Completely Fair Scheduler (CFS) in Linux). A very high niceness value on an otherwise idle system might not significantly reduce CPU usage.</li></ul>


title: NICENESS VALUE RANGE
content:
The niceness value typically ranges from -20 (highest priority, least nice) to 19 (lowest priority, most nice). A lower numerical value means higher priority.


title: DEFAULT NICENESS
content:
Unless specified with the <i>-n</i> option, a command invoked with <i>nice</i> will start with a default niceness adjustment of +10, meaning its actual niceness will be 10. If <i>nice</i> is run without any arguments (i.e., just `nice`), it prints the current niceness.


title: RELATIONSHIP WITH <I>RENICE</I>
content:
While <i>nice</i> sets the priority of a process as it starts, <i>renice</i> is used to modify the niceness of processes that are already running. This distinction is crucial for managing dynamic workloads.


title: HISTORY
content:
The concept of "niceness" and tools like <i>nice</i> have been integral to Unix-like operating systems since their early development. They emerged from the need to manage shared computing resources effectively, particularly CPU time, among multiple users and processes. The idea is to allow users to cooperatively yield CPU resources, ensuring that no single process monopolizes the system, especially for long-running, non-interactive tasks. This cooperative scheduling mechanism has evolved with different kernel schedulers (e.g., O(1) scheduler, CFS in Linux), but the user-facing interface via <i>nice</i> has remained consistent in its purpose: providing a simple way to adjust process priorities for better system responsiveness and resource allocation.


title: SYNOPSIS
content:
<b>nim</b> <I>[global-options]</I> <I>command</I> <I>[command-options]</I> <I>[arguments]</I><br>The command typically involves specifying a subcommand like <I>c</I> (compile), <I>r</I> (run), <I>doc</I>, or <I>install</I>, followed by options specific to that subcommand and relevant arguments (e.g., source file names).


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Nim compiler's version information.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows general help or help for a specific subcommand.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output during compilation and execution processes.<br><br><b>-d:<define></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a symbol or flag that can influence conditional compilation.<br><br><b>--fullbuild</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a complete rebuild of the project, ignoring incremental compilation caches.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles the code in debug mode, typically including debug symbols.<br><br><b>--release</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles the code in release mode, enabling optimizations for performance.<br><br><b>--os:<os></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target operating system for compilation (e.g., linux, windows, macos).<br><br><b>--cpu:<cpu></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target CPU architecture for compilation (e.g., amd64, arm64).<br><br>


title: DESCRIPTION
content:
The <I>nim</I> command is the primary tool for interacting with the Nim programming language. It serves as a comprehensive compiler, interpreter, and project management utility. Developed as a high-performance, statically-typed language that compiles to C, C++, or JavaScript, Nim aims to combine the efficiency of C with the expressiveness of Python.<br><br>The <I>nim</I> command facilitates various operations including compiling source code into executables, running Nim scripts, generating documentation, and managing project dependencies. It's an essential part of the Nim development workflow, offering a unified interface for building, testing, and deploying Nim applications across different platforms. While not a standard utility found in typical Linux distributions by default, it becomes available upon installation of the Nim programming language toolchain. Its versatility allows developers to handle everything from small scripts to large-scale systems programming projects.


title: CAVEATS
content:
The <I>nim</I> command is not a standard utility in most Linux distributions and requires the Nim programming language toolchain to be installed. Its behavior and available options can vary significantly depending on the subcommand used. Users should consult the official Nim documentation for comprehensive details on all subcommands and their specific parameters.


title: SUBCOMMANDS OVERVIEW
content:
The <I>nim</I> command operates primarily through a system of subcommands, each performing a distinct task. Common subcommands include <I>c</I> (compile a Nim source file), <I>r</I> (compile and run a Nim source file), <I>doc</I> (generate HTML documentation), <I>install</I> (install a Nim package), <I>check</I> (perform a static analysis check), and <I>build</I> (build a project). Each subcommand often has its own set of specific options.


title: PACKAGE MANAGEMENT
content:
The <I>nim</I> command integrates with Nim's built-in package manager, Nimble. Commands like <I>nimble install</I>, <I>nimble publish</I>, and <I>nimble update</I> (though often invoked directly via <I>nimble</I>, <I>nim</I> can dispatch to it) are crucial for managing external libraries and dependencies within Nim projects, mirroring similar functionalities in other modern language toolchains.


title: HISTORY
content:
The Nim programming language, and by extension its <I>nim</I> command, originated from a project known as Nimrod, started by Andreas Rumpf in 2008. The language was officially renamed to Nim in 2014. Its development has focused on creating a language that combines performance, expressiveness, and a pragmatic approach to systems programming. The <I>nim</I> command has evolved alongside the language, becoming the central unified interface for all major development tasks, from basic compilation to advanced package management and cross-platform compilation.


title: SEE ALSO
content:
gcc(1): GNU Compiler Collection, a widely used compiler for C/C++/Fortran., clang(1): A C, C++, Objective-C and Objective-C++ front-end for the LLVM compiler., python(1): An interpreted, object-oriented, high-level programming language with dynamic semantics., rustc(1): The Rust programming language compiler., go(1): The Go programming language toolchain.


title: PARAMETERS
content:
<b><b>init</b> <i>[project_name]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <i>Nimble</i> project with a basic structure.<br><br><b><b>install</b> <i>[package_name]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified package or all dependencies listed in the <i>.nimble</i> file.<br><br><b><b>update</b> <i>[package_name]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates installed packages to their latest compatible versions.<br><br><b><b>uninstall</b> <i>[package_name]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed package from the system.<br><br><b><b>build</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles the project based on the configuration in the <i>.nimble</i> file, creating an executable.<br><br><b><b>test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the project's defined tests.<br><br><b><b>publish</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes the current project as a new package to the <i>NimbleDir</i> registry.<br><br><b><b>tasks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all custom tasks defined within the project's <i>.nimble</i> file.<br><br><b><b>refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes the local package list cache from the <i>NimbleDir</i>.<br><br><b><b>search</b> <i>[keyword]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages in the <i>NimbleDir</i> registry matching the keyword.<br><br><b><b>--help</b> <i>[command]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>nimble</b> or a specific command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed <b>nimble</b> version.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output for more detailed information during execution.<br><br>


title: DESCRIPTION
content:
<b>nimble</b> is the official package manager and build tool for the <i>Nim</i> programming language. It streamlines the development workflow by managing project dependencies, allowing developers to install, update, and uninstall packages from the Nim package registry (<i>NimbleDir</i>) or other sources like Git repositories.<br><br>Beyond dependency management, <b>nimble</b> facilitates project creation, compilation, testing, and even publishing packages. It interprets a project's <i>.nimble</i> file, which defines metadata, dependencies, and custom tasks. This makes it an indispensable utility for anyone working with <i>Nim</i>, abstracting away complex build configurations and providing a consistent way to manage <i>Nim</i> projects and their external libraries. It integrates deeply with the <i>Nim</i> compiler to provide a seamless build experience.


title: CAVEATS
content:
<b>nimble</b> is specific to the <i>Nim</i> programming language ecosystem. It requires the <i>Nim</i> compiler and runtime to be installed on your system. It is not a general-purpose Linux utility like <b>ls</b> or <b>grep</b>, but rather an application-specific tool primarily for <i>Nim</i> development. Its functionality is entirely dependent on the presence and structure of a <i>.nimble</i> project file.


title: THE .NIMBLE FILE
content:
This manifest file, typically named after the project (e.g., <i>myproject.nimble</i>), is central to how <b>nimble</b> understands and manages a project. It defines project metadata, dependencies, source paths, and custom tasks, serving as the core configuration for <b>nimble</b> operations.


title: NIMBLEDIR REGISTRY
content:
By default, <b>nimble</b> fetches packages from the official <i>NimbleDir</i> registry, a centralized online repository for published <i>Nim</i> packages. Users can also specify Git URLs or local paths for packages not available in the registry.


title: HISTORY
content:
<b>nimble</b> was developed as an integral part of the <i>Nim</i> programming language project itself, evolving alongside the compiler to provide a comprehensive package management and build system. Its design was influenced by successful package managers in other ecosystems, aiming to offer a user-friendly and efficient tool for <i>Nim</i> developers. It quickly became the de-facto standard for managing <i>Nim</i> projects and dependencies within the <i>Nim</i> community.


title: SYNOPSIS
content:
nix edit [<i>GLOBAL-OPTIONS</i>] [<i>EDIT-OPTIONS</i>] [<i>ATTRIBUTE-PATH</i>]<br>nix edit [<i>GLOBAL-OPTIONS</i>] [<i>EDIT-OPTIONS</i>] --file <i>PATH</i><br>nix edit [<i>GLOBAL-OPTIONS</i>] [<i>EDIT-OPTIONS</i>] --expr <i>EXPR</i>


title: PARAMETERS
content:
<b><i>ATTRIBUTE-PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Nix expression to edit using an attribute path, e.g., <i>nixpkgs#hello</i> or <i>.#myPackage</i> within a flake. This is the most common way to target a specific package or derivation.<br><br><b>--file <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directly opens the specified Nix file <i>PATH</i> in the editor. This is useful when you already know the exact file you want to edit.<br><br><b>--expr <i>EXPR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evaluates the provided Nix expression string <i>EXPR</i> and opens its source definition. This allows for editing expressions that might not correspond directly to a file.<br><br><b>--subpath <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When opening a derivation's source, this option allows specifying a particular subpath within the derivation's source tree to open, instead of the primary Nix expression file.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate in offline mode, preventing network access for fetching Nixpkgs or flake inputs.<br><br><b>--refresh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a refresh of flake inputs and cached data, ensuring you're working with the latest versions.<br><br><b>--option <i>NAME</i> <i>VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific Nix configuration option, overriding default or system-wide settings for this command invocation (e.g., <i>--option experimental-features 'nix-commands flakes'</i>).<br><br><b>--show-trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a detailed stack trace on Nix evaluation errors, which is invaluable for debugging issues in Nix expressions.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity of output messages, providing more detailed information about the command's execution.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages, showing only critical errors. Useful for scripting or when minimal output is desired.<br><br>


title: DESCRIPTION
content:
<b>nix edit</b> is a powerful subcommand of the Nix command-line tool designed to streamline the process of inspecting and temporarily modifying Nix expressions. It allows users to quickly open the Nix source code that defines a specific Nix store path, a derivation, or an attribute from a flake. This capability is immensely useful for understanding how a package is built, debugging configuration issues, or performing rapid, non-permanent modifications to a package definition without needing to manually locate the relevant Nix expression file within the Nixpkgs source tree or a custom flake. The command intelligently determines the correct Nix file and opens it in the user's preferred text editor, as defined by the <i>EDITOR</i> or <i>VISUAL</i> environment variables.


title: CAVEATS
content:
<b>nix edit</b> requires the <i>EDITOR</i> or <i>VISUAL</i> environment variable to be set to a valid editor program (e.g., <i>nvim</i>, <i>code</i>, <i>nano</i>). If neither is set, it might default to a basic editor like <i>vi</i> or fail.<br>Editing expressions opened by <b>nix edit</b> creates a temporary file for modifications. These changes are <b>not permanent</b> and do not alter the package definition in your Nix store or cache. To apply changes, you typically need to incorporate them into your own flake, overlay, or Nixpkgs fork and then rebuild or re-instantiate the derivation.


title: <I>ENVIRONMENT VARIABLES</I>
content:
The behavior of <b>nix edit</b> is highly dependent on the <i>EDITOR</i> or <i>VISUAL</i> environment variables. These variables tell Nix which text editor to launch. For optimal user experience, it is highly recommended to set one of these variables in your shell configuration (e.g., <i>export EDITOR=nvim</i> or <i>export VISUAL=code --wait</i>).


title: <I>TEMPORARY NATURE OF EDITS</I>
content:
It is crucial to understand that when <b>nix edit</b> opens a Nix expression, it typically copies the relevant file to a temporary location for editing. Any changes you make and save are applied only to this temporary copy. This command is primarily for quick inspection, exploration, and experimental modification. To make changes persistent and globally visible to the Nix system, you must integrate them into a proper Nix project structure (like a flake or an overlay) and then build or apply those changes.


title: HISTORY
content:
The <b>nix edit</b> command is a key component of the 'new' Nix command-line interface, introduced as part of the broader effort to unify the Nix CLI and integrate Nix flakes. It aims to provide a more intuitive and user-friendly experience compared to older, more fragmented Nix commands. Its development reflects the ongoing evolution of the Nix project towards more declarative and reproducible system management, focusing on improved developer ergonomics.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>--arg</b> <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument <i>name</i> with Nix expression <i>value</i> to the evaluated Nix expression.<br><br><b><b>--argstr</b> <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument <i>name</i> with string <i>value</i> to the evaluated Nix expression.<br><br><b><b>--file</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the specified Nix file into the REPL environment upon startup. If omitted, <i>default.nix</i> in the current directory is loaded, or an empty scope is provided.<br><br><b><b>--impure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows impure operations, such as accessing arbitrary files or environment variables.<br><br><b><b>--option</b> <i>name value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a Nix configuration option for the duration of the REPL session.<br><br><b><i>path-or-expression</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. One or more paths to Nix expressions or directories to load. If a directory, <i>default.nix</i> inside it is loaded. Also can add to the Nix search path (NIX_PATH) for the session.<br><br>


title: DESCRIPTION
content:
<i>nix-repl</i> is the interactive Read-Eval-Print Loop (REPL) for the Nix expression language. It provides a powerful environment for developers to experiment with Nix code, explore the Nixpkgs set, and debug Nix expressions directly. Users can type Nix expressions at the prompt, and <i>nix-repl</i> immediately evaluates and displays the result. This interactive nature makes it an invaluable tool for understanding how Nix evaluates expressions, inspecting attribute sets, and testing package definitions without having to build them. It supports features like tab completion for attributes and paths, multiline input, and the ability to load a Nix file or context at startup, enabling rapid prototyping and iterative development within the Nix ecosystem.


title: CAVEATS
content:
The REPL operates within the Nix sandbox environment by default, which can restrict access to external files or network resources. Use <b>--impure</b> for broader access.<br>Changes made within the REPL are not persistent; they are lost once the session exits.<br>Evaluating large expressions or building complex derivations can be resource-intensive within the REPL.


title: INTERACTIVE COMMANDS
content:
<i>nix-repl</i> supports several built-in commands accessible with a colon prefix, such as <b>:l</b> <i>&lt;file&gt;</i> to load a file, <b>:cd</b> <i>&lt;dir&gt;</i> to change directory, <b>:p</b> <i>&lt;expr&gt;</i> to pretty-print an expression, <b>:t</b> <i>&lt;expr&gt;</i> to show the type, and <b>:?</b> for help. These commands significantly enhance the interactive experience beyond simple expression evaluation.


title: LOADING CONTEXT
content:
By default, <i>nix-repl</i> attempts to load <i>default.nix</i> from the current directory. If a path is provided as an argument (e.g., <b>nix-repl</b> <i>./my-nix-file.nix</i>), it loads that specific Nix expression, making it easy to jump into the context of a particular project or library or to explore specific Nixpkgs attributes.


title: HISTORY
content:
<i>nix-repl</i> is an integral part of the Nix package manager, which was first conceived by Eelco Dolstra around 2003 as a research project at Utrecht University. The REPL provides a crucial interactive component to the purely functional Nix language, allowing users to rapidly prototype and debug expressions. Its development has evolved alongside the Nix ecosystem, remaining a stable and essential tool for interacting with Nix expressions, particularly useful for exploring Nixpkgs and developing new packages. With the advent of the unified <i>nix</i> command in newer Nix versions, <i>nix-repl</i> is often invoked as <b>nix repl</b>, signifying its core role within the Nix CLI.


title: SYNOPSIS
content:
<b>nix run</b> [<i>options</i>] &lt;<i>flake-url</i>&gt;[#&lt;<i>attr</i>&gt;] [--] [<i>args...</i>]


title: PARAMETERS
content:
<b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to connect to the Nix store or the network during evaluation and building.<br><br><b><b>--refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force re-fetching of flake inputs, ignoring cached versions.<br><br><b><b>--install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;After running, install the specified executable into the user's default profile (e.g., <code>~/.nix-profile</code>).<br><br><b><b>--profile </b><i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add the specified executable to the given Nix profile path instead of the default. Similar to <b>--install</b>.<br><br><b><b>--impure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow the executed command to access environment variables and paths outside the clean Nix environment, potentially compromising reproducibility.<br><br><b><b>--extra-experimental-features </b><i>features</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable specified experimental Nix features (e.g., <code>flakes nix-command</code>).<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to separate <b>nix run</b> options from arguments that should be passed directly to the program being executed.<br><br>


title: DESCRIPTION
content:
The <b>nix run</b> command is a powerful subcommand of the Nix package manager, designed to execute applications or scripts defined in a Nix expression without requiring a permanent installation. It creates a temporary, isolated environment where the specified package and all its dependencies are made available, then runs the desired command within that sandboxed context.<br><br>This functionality is invaluable for a variety of use cases: trying out new tools or applications without cluttering your system, running one-off scripts with specific dependencies, or setting up reproducible development environments without polluting your user profile or global PATH. By leveraging Nix's content-addressable store, <b>nix run</b> efficiently fetches or builds necessary components, ensuring reproducibility and consistency across different machines.


title: CAVEATS
content:
By default, <b>nix run</b> operates in a highly isolated environment. This means the executed program will not have access to your system's default environment variables (like PATH) or user files unless specifically exposed or the <b>--impure</b> flag is used. First-time execution might be slower due to downloading or building dependencies. It requires Nix 2.4 or newer for flake support and the 'nix-command' experimental feature to be enabled.


title: FLAKES INTEGRATION
content:
<b>nix run</b> is deeply integrated with Nix Flakes. The <code>&lt;flake-url&gt;[#&lt;attr&gt;]</code> syntax allows users to reference applications or packages defined within a flake (e.g., <code>nixpkgs#hello</code>, <code>github:NixOS/nixpkgs/nixos-23.11#cowsay</code>, or <code>.#my-app</code> for local flakes), providing a consistent and reproducible way to execute specific entries from a project.


title: EPHEMERAL EXECUTION
content:
One of <b>nix run</b>'s core strengths is its ephemeral nature. Unless explicitly told to install the program (via <b>--install</b> or <b>--profile</b>), it cleans up the temporary environment after execution, leaving no lasting traces or modifications to your system's configuration. This makes it perfect for testing, quick one-off tasks, or ensuring a clean development setup.


title: HISTORY
content:
The <b>nix run</b> command emerged as part of the 'Nix command' re-architecture, which aimed to consolidate and streamline Nix's user-facing interface. Prior to its introduction (around Nix 2.4), similar functionality was often achieved by composing commands like <code>nix-shell -p &lt;pkg&gt; --run &lt;cmd&gt;</code>. <b>nix run</b> significantly simplified the 'run a single application' use case, particularly with the advent of Nix Flakes, providing a more intuitive and declarative way to specify and execute programs from Nix expressions directly.


title: SYNOPSIS
content:
<b>nix-shell</b> [<i>options...</i>] [<i>&lt;nix-file&gt;</i>]<br><b>nix-shell</b> [<i>options...</i>] <b>--packages</b> <i>&lt;pkgs...&gt;</i><br><b>nix-shell</b> [<i>options...</i>] <b>--expr</b> <i>&lt;nix-expression&gt;</i><br><b>nix-shell</b> [<i>options...</i>] <b>--run</b> <i>&lt;command&gt;</i>


title: PARAMETERS
content:
<b><b>--run</b> &lt;command&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specific command in the shell's environment instead of entering an interactive shell.<br><br><b><b>--pure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a pristine shell environment, discarding most inherited environment variables for <i>reproducibility</i>.<br><br><b><b>--keep</b> &lt;env-var&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--pure</b>, specifies environment variables from the parent shell to retain.<br><br><b><b>--ignore-environment</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores all inherited environment variables, similar to <b>--pure</b> but less strict regarding shell functions.<br><br><b><b>--attr</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific attribute path within the Nix expression to define the shell environment.<br><br><b><b>--file</b> &lt;nix-file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Nix expression file (e.g., <code>shell.nix</code>) to build the environment from. Defaults to <code>shell.nix</code> or <code>default.nix</code> in the current directory.<br><br><b><b>--expr</b> &lt;nix-expression&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a Nix expression directly on the command line to define the shell environment.<br><br><b><b>--packages</b> &lt;pkgs...&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define a shell environment by listing packages from <i>nixpkgs</i> directly, e.g., <code>nix-shell -p git hello</code>.<br><br><b><b>--arg</b> &lt;name&gt; &lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass a Nix value as an argument to the Nix expression that defines the shell.<br><br><b><b>--argstr</b> &lt;name&gt; &lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <b>--arg</b>, but ensures the value is passed as a string.<br><br><b><b>--show-trace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a detailed stack trace on Nix evaluation errors, which is useful for debugging.<br><br><b>&lt;nix-file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Positional argument for the Nix expression file (alternative to <b>--file</b>).<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options and usage.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the <b>nix-shell</b> version information.<br><br>


title: DESCRIPTION
content:
<b>nix-shell</b> is a core command from the <i>Nix package manager</i>, designed to create reproducible, isolated development or build environments on demand. It evaluates a Nix expression (typically from a file like <code>shell.nix</code> or <code>default.nix</code>) to determine the exact set of dependencies, tools, and environment variables required for a project. Instead of installing software globally, <b>nix-shell</b> provides these components temporarily within the current shell session. When the session ends, the environment disappears, leaving no lasting changes to the system. This capability makes <b>nix-shell</b> invaluable for ensuring consistent developer setups, testing software in clean environments, and quickly trying out new tools without system clutter. It leverages Nix's content-addressable store for unparalleled reproducibility.


title: CAVEATS
content:
<b>Initial Setup Time</b>: The first time a <b>nix-shell</b> environment is entered, Nix might need to build or download many dependencies, which can take considerable time and bandwidth.<br><b>Disk Usage</b>: Nix's content-addressable store can accumulate many derivations, potentially consuming significant disk space over time, though it is shared across projects.<br><b>Nix Language Learning Curve</b>: Effectively using <b>nix-shell</b> for complex projects requires a basic understanding of the Nix expression language and its ecosystem.<br><b>Impurity Challenges</b>: While striving for purity, certain operations (like network access or direct file system interactions outside the Nix store) can still introduce non-reproducibility.


title: NIXPKGS INTEGRATION
content:
<b>nix-shell</b> frequently leverages the vast <i>Nixpkgs</i> collection. By specifying packages with <b>-p</b> or by building derivations from <i>Nixpkgs</i> within a <code>shell.nix</code>, users gain access to an immense array of pre-defined software and tools, significantly simplifying environment setup.


title: REPRODUCIBILITY GUARANTEE
content:
The primary strength of <b>nix-shell</b> is its ability to create highly reproducible environments. Nix's deterministic dependency resolution and immutable build store ensure that identical <b>nix-shell</b> invocations on different machines (given the same Nix store content) will yield precisely identical development environments, virtually eliminating 'it works on my machine' issues.


title: SHELLHOOK
content:
A special feature within a Nix shell derivation is the <code>shellHook</code> attribute. This allows arbitrary shell commands to be executed automatically immediately after the shell is entered. It's commonly used for project-specific setup tasks like activating language-specific virtual environments, setting additional environment variables, or displaying custom welcome messages.


title: HISTORY
content:
<b>nix-shell</b> has been a fundamental part of the Nix package manager since its early development. It represents the original approach to creating declarative development environments within the Nix ecosystem. While the newer <b>nix shell</b> command (introduced with the <i>Nix Flakes</i> feature) offers a more streamlined, opinionated, and flake-aware experience, <b>nix-shell</b> remains widely used, especially for legacy projects, non-flake setups, or when direct interaction with traditional Nix expressions is preferred. Its design laid the groundwork for Nix's core promise of reproducible development.


title: SYNOPSIS
content:
<code>nix-store [<I>options</I>] &lt;<I>command</I>&gt; [<I>arguments</I>...]</code><br><br>Common commands include:<br><code>nix-store --add &lt;<I>path</I>&gt;</code><br><code>nix-store --query {--hash | --references | ...} &lt;<I>store-path</I>&gt;</code><br><code>nix-store --gc</code><br><code>nix-store --verify</code>


title: PARAMETERS
content:
<b>--add <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a local file or directory to the Nix store, computing its hash and registering it. Useful for adding non-Nix paths.<br><br><b>--add-fixed <hash-algo> <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a fixed-output derivation path to the store, verifying its hash against the expected one (e.g., for source tarballs).<br><br><b>--export <paths...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports specified store paths and their dependencies into a 'nar' (Nix Archive) format, typically sent to standard output.<br><br><b>--import</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports store paths from a 'nar' archive read from standard input into the Nix store.<br><br><b>--delete <paths...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes specified store paths from the database and disk. Use with extreme caution as it can break system integrity.<br><br><b>--query <sub-command> <store-path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries various information about a store path. Sub-commands include <code>--hash</code>, <code>--references</code> (what it depends on), <code>--referrers</code> (what depends on it), <code>--valid</code>, etc.<br><br><b>--gc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs garbage collection, removing store paths that are not referenced by any garbage collector roots (e.g., active user environments or profiles).<br><br><b>--verify {--all | --check-contents | ...}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the integrity of store paths, checking their hashes and cryptographic signatures. Can also repair the store if issues are found.<br><br><b>--read-log <store-path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads and prints the build log associated with a given store path, if available.<br><br><b>--print-roots</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints all currently registered garbage collector roots, which prevent specific store paths from being garbage collected.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output messages, providing more detailed information during operations.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results in JSON format where applicable, facilitating machine parsing.<br><br>


title: DESCRIPTION
content:
The <code>nix-store</code> command is a fundamental, low-level utility within the Nix package manager. It directly interacts with the <I>Nix store</I>, which is the heart of Nix's reproducibility and atomic upgrades. The store, typically located at <code>/nix/store</code>, contains all installed packages, derivations, and their dependencies, identified by unique cryptographic hashes.<br><br>This command allows advanced users and Nix's internal machinery to perform critical operations such as adding new build outputs to the store, querying information about existing store paths (like their cryptographic hash, references, or referrers), and managing garbage collection to remove unreferenced data. While higher-level Nix commands like <code>nix-build</code>, <code>nix-shell</code>, and <code>nix-env</code> abstract away most of its direct usage, <code>nix-store</code> remains indispensable for inspecting the store's state, performing manual cleanups, or diagnosing issues. It enforces the immutability and integrity of all store paths, ensuring that package builds are consistent and verifiable.


title: CAVEATS
content:
This analysis is based on the standard <code>nix-store(1)</code> man page, which describes the user-facing command. The request specifically mentioned <code>nix-store.3</code>. As a common convention, <code>.3</code> man pages refer to C library functions, which <code>nix-store</code> is not. There is no widely published <code>nix-store.3</code> man page for the utility itself. It's possible the reference was to a specific, internal, or non-standard documentation section.<br><br>Direct use of <code>nix-store</code> is generally for advanced users or debugging. Misuse, especially with commands like <code>--delete</code>, can lead to a corrupted or non-functional Nix store. Many operations require root privileges or the <code>nix-daemon</code> to be running with appropriate permissions.


title: NIX STORE PATHS
content:
All build outputs and dependencies in Nix are stored in a unique, immutable location within the Nix store (e.g., <code>/nix/store/&lt;hash&gt;-&lt;name&gt;</code>). The <code>&lt;hash&gt;</code> component is a cryptographic hash of the input derivation, ensuring reproducibility and content-addressability. This structure is fundamental to Nix's ability to provide atomic upgrades, rollbacks, and side-by-side installations of different versions of the same software.


title: GARBAGE COLLECTION (GC)
content:
The <code>nix-store --gc</code> command is used to reclaim disk space by removing 'unreachable' store paths. A path is unreachable if it is not referenced by any 'garbage collector root' (e.g., active user environments, profiles, or explicitly registered roots). This process helps maintain a clean and efficient Nix store, crucial for systems with many builds or frequent updates.


title: NIX ARCHIVE (NAR) FORMAT
content:
The Nix Archive (NAR) is a simple, self-describing, and canonical serialization format used by Nix for packaging and exchanging store paths. Commands like <code>nix-store --export</code> and <code>nix-store --import</code> leverage this format to facilitate copying store paths between different Nix installations or for backup purposes, ensuring integrity and completeness.


title: HISTORY
content:
The <code>nix-store</code> utility is an integral and foundational component of the Nix package manager, which was originally conceived and developed by Eelco Dolstra starting around 2003. Its design principles, such as content-addressable storage and immutable build outputs, were central to Nix's vision from its inception. The existence of a dedicated, low-level store manipulation tool reflects Nix's commitment to a purely functional build model. While the Nix ecosystem has grown significantly, introducing higher-level commands and concepts, the core functionality and role of <code>nix-store</code> have remained consistent, serving as the bedrock for all Nix operations.


title: SYNOPSIS
content:
<b>nix3-shell</b> [<i>flake-url</i>] [<i>options</i>] [<b>--command</b> <i>cmd</i>] [<b>--arg</b> <i>name value</i>] [<b>--argstr</b> <i>name value</i>] [<i>--</i> <i>args...</i>]


title: PARAMETERS
content:
<b><i>flake-url</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the Nix flake to build or use. This can be a local path, a GitHub URL (e.g., <i><B>github:NixOS/nixpkgs#hello</B></i>), or other flake references. If omitted, Nix will look for a <i><B>flake.nix</B></i> in the current directory or parent directories.<br><br><b><b>--command</b> <i>&lt;cmd&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the specified command <i><B>&lt;cmd&gt;</B></i> within the created shell environment instead of dropping into an interactive shell.<br><br><b><b>--arg</b> <i>&lt;name&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass an arbitrary Nix value as an argument to the flake's `shell` function, if defined.<br><br><b><b>--argstr</b> <i>&lt;name&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass a string value as an argument to the flake's `shell` function, if defined.<br><br><b><b>--input</b> <i>&lt;name&gt; &lt;flake-url&gt;</i><br><b>--override-input</b> <i>&lt;name&gt; &lt;flake-url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override a specific input of the flake. This is useful for testing local changes to dependencies or using alternative versions.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Avoid fetching new paths from the Nix store or flake inputs. Useful for reproducible builds when internet access is not guaranteed or undesirable.<br><br><b><b>--refresh</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a refresh of flake inputs before building, ensuring the latest versions are used. This updates the <i><B>flake.lock</B></i> file.<br><br><b><b>--show-trace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a detailed stack trace on Nix evaluation errors, aiding in debugging complex Nix expressions.<br><br><b><b>--print-build-logs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print build logs to standard output, even if the build succeeds, providing verbose output on the build process.<br><br>


title: DESCRIPTION
content:
<i><B>nix3-shell</B></i> (or <i><B>nix shell</B></i> in modern Nix) is a command from the Nix package manager that allows users to create isolated and reproducible development environments. Unlike <i><B>nix-shell</B></i> (the older command), <i><B>nix3-shell</B></i> is typically used in conjunction with Nix flakes, enabling a more declarative and structured way to define project dependencies. It makes specific packages available in the current shell session without installing them globally on the system, ensuring that different projects can have conflicting dependencies without interference. This command is crucial for maintaining consistent development setups across various machines and collaborators, fostering reproducibility in software development. It fetches and builds the necessary dependencies and then drops the user into a new shell where these dependencies are available in the <i><B>PATH</B></i>.


title: CAVEATS
content:
<i><B>nix3-shell</B></i> (or <i><B>nix shell</B></i>) is part of the experimental Nix 3.x command set. While stable for many uses, it might still see changes or additions. It relies heavily on Nix flakes, which are also considered experimental by default and require <i><B>experimental-features = nix-command flakes</B></i> to be enabled in your <i><B>nix.conf</B></i>. Using this command can lead to large downloads or builds if dependencies are complex or not cached in your local Nix store or binary cache.


title: NIX FLAKES INTEGRATION
content:
<i><B>nix3-shell</B></i> is primarily designed to work with Nix flakes, which provide a standardized, reproducible way to define inputs and outputs for Nix projects. This allows for precise version pinning of dependencies and consistent builds across different systems, greatly improving the reliability of development environments.


title: REPRODUCIBILITY
content:
By leveraging the declarative nature of Nix and its content-addressed store, <i><B>nix3-shell</B></i> ensures that environments are fully reproducible. This means that if a project's <i><B>flake.nix</B></i> specifies certain dependencies, anyone using <i><B>nix3-shell</B></i> with that flake will get the exact same environment, significantly reducing 'it works on my machine' issues across development teams.


title: GARBAGE COLLECTION ROOTS
content:
When you enter a <i><B>nix3-shell</B></i>, a 'garbage collection root' is typically created. This mechanism prevents the Nix garbage collector from prematurely deleting the packages and dependencies required by your active shell environment, ensuring stability and preventing unexpected breakages while you are working.


title: HISTORY
content:
The concept of <i><B>nix-shell</B></i> has existed in Nix for a long time, providing isolated development environments. With the introduction of Nix flakes and the experimental Nix 3.x command-line interface, <i><B>nix shell</B></i> (often referred to as <i><B>nix3-shell</B></i> during its early experimental phase) was designed to provide a more declarative and standardized way of managing environments, specifically integrating with flake-based projects. It aims to unify various aspects of Nix usage under a consistent CLI, moving away from the older, more ad-hoc <i><B>nix-shell</B></i> usage, especially for managing project dependencies, and providing a more reproducible and shareable development experience.


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information about the application and exits.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging messages, which can be useful for troubleshooting.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to connect to (standard GTK+/X option).<br><br>


title: DESCRIPTION
content:
<b>nm-connection-editor</b> is a graphical user interface (GUI) utility designed for robust management of network connections configured by the <b>NetworkManager</b> service. It provides an intuitive and user-friendly way for desktop users to perform a wide range of tasks, including creating new connection profiles, editing existing ones, deleting obsolete configurations, and activating or deactivating network interfaces. This versatility extends to various connection types, such as wired Ethernet, wireless Wi-Fi, mobile broadband, VPNs (Virtual Private Networks), DSL, and more.<br><br>By offering a visual interface, <b>nm-connection-editor</b> significantly simplifies complex network setup and troubleshooting, making advanced network configurations accessible to users who may not be familiar with command-line tools like <b>nmcli</b> or <b>ip</b>. It is a staple tool in most modern Linux desktop environments, including GNOME, KDE Plasma, XFCE, and MATE, where it typically integrates seamlessly with system settings and network indicator applets to provide a complete network management experience. Its primary purpose is to abstract the underlying complexities of network configuration, presenting a straightforward way to manage everything from IP addresses and DNS servers to Wi-Fi security protocols and VPN gateway details.


title: CAVEATS
content:
<ul><li>Requires a running X server or Wayland compositor and a graphical desktop environment to function.</li><li>The <b>NetworkManager</b> service must be active and running in the background for <b>nm-connection-editor</b> to manage connections.</li><li>Modifying system-wide connections may require appropriate administrative privileges.</li></ul>


title: DEPENDENCIES
content:
Requires the <b>NetworkManager</b> daemon to be running and a graphical desktop environment (e.g., GNOME, KDE, XFCE) with <b>GTK+</b> libraries for its user interface.


title: TYPICAL USAGE
content:
This tool is primarily designed for graphical interaction. It's usually launched from a desktop environment's applications menu, system settings, or a network indicator icon in the system tray. Upon launch, it presents a window allowing users to visually manage all network connections configured by <b>NetworkManager</b>, offering controls for adding new connections, editing existing ones, or deleting them.


title: HISTORY
content:
<b>nm-connection-editor</b> is an integral part of the <b>NetworkManager</b> project, which was initiated by Red Hat in 2004 with the aim of simplifying network setup and configuration for Linux desktop users, particularly those with mobile devices. As <b>NetworkManager</b> gained widespread adoption and became a standard component for network management across numerous Linux distributions, <b>nm-connection-editor</b> emerged as its primary graphical frontend. Its development is closely linked to the evolution of <b>NetworkManager</b> itself and the various desktop environments it integrates with, providing a user-friendly interface to the daemon's powerful capabilities.


title: SYNOPSIS
content:
<b>nmap</b> [<i>Scan Type(s)</i>] [<i>Options</i>] {<i>target specification</i>}<br><br><i>Examples of Target Specification:</i><br>  <i>192.168.1.1</i> (single IP)<br>  <i>scanme.nmap.org</i> (hostname)<br>  <i>192.168.1.0/24</i> (CIDR notation)<br>  <i>192.168.1.1-254</i> (range)<br>  <i>192.168.1.*</i> (wildcard)


title: PARAMETERS
content:
<b>-sS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>SYN scan (stealth scan)</i>: The default and most popular scan option. It's fast and less likely to be logged by non-full-logging firewalls.<br><br><b>-sT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>TCP connect scan</i>: Establishes a full TCP connection. Slower and more easily detected than SYN scan, but doesn't require root privileges.<br><br><b>-sU</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>UDP scan</i>: Used to find open UDP ports. Slower than TCP scans due to the connectionless nature of UDP.<br><br><b>-sV</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Version detection</i>: Determines the service and version number of applications listening on open ports.<br><br><b>-O</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>OS detection</i>: Attempts to determine the operating system and device type of the target host.<br><br><b>-sC</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Default script scan</i>: Runs a set of common and safe Nmap Scripting Engine (NSE) scripts.<br><br><b>-sn</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Ping scan (host discovery only)</i>: Disables port scanning and only performs host discovery. Useful for quickly listing live hosts on a network. (Previously -sP)<br><br><b>-PN</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>No ping (treat all hosts as online)</i>: Skips the host discovery phase. Nmap assumes all target hosts are online and attempts to scan them. (Previously -P0)<br><br><b>-p &lt;port_range&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Port specification</i>: Specifies which ports to scan (e.g., <i>-p 80,443</i>, <i>-p 1-1024</i>, <i>-p-</i> for all ports).<br><br><b>-T&lt;0-5&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Timing template</i>: Sets the aggression level (0=paranoid, 1=sneaky, 2=polite, 3=normal, 4=aggressive, 5=insane). Default is 3.<br><br><b>-iL &lt;inputfile&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Input list from file</i>: Reads target specifications from a file, with each target on a new line.<br><br><b>-oN &lt;outputfile&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Normal output</i>: Writes scan results to the specified file in a human-readable format.<br><br><b>-oX &lt;outputfile&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>XML output</i>: Writes scan results to the specified file in XML format, suitable for programmatic parsing.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increase verbosity</i>: Increases the verbosity level to provide more details about the scan progress. Use <i>-vv</i> for even more information.<br><br><b>--script &lt;script_name|category|directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Nmap Scripting Engine</i>: Runs specific Nmap scripts or categories of scripts (e.g., <i>--script http-enum</i>, <i>--script default</i>, <i>--script vuln</i>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of Nmap options and usage.<br><br>


title: DESCRIPTION
content:
<b>nmap</b> (Network Mapper) is a free and open-source utility for network discovery and security auditing. It was designed to rapidly scan large networks, though it works fine against single hosts. <i>Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics.</i><br><br>It is commonly used by network administrators for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime. Security auditors use it for vulnerability assessments and penetration testing. Nmap runs on all major operating systems and is highly flexible, supporting various scan types, evasion techniques, and a powerful scripting engine (NSE) for advanced detection and exploitation.


title: CAVEATS
content:
<b>nmap</b> is a powerful tool capable of generating significant network traffic. Many of its advanced scanning capabilities, especially those involving raw packet manipulation (e.g., SYN scans, OS detection), require root privileges (or <b>sudo</b>) to execute. Using <b>nmap</b> without explicit permission from the target network owner is illegal and unethical in most jurisdictions and can lead to legal repercussions or being blocked by network security devices. Its output, especially OS and service version detection, should be taken as an educated guess and not an absolute fact, as some factors can lead to inaccuracies.


title: NMAP SCRIPTING ENGINE (NSE)
content:
A powerful and flexible feature that allows users to write (and share) simple scripts to automate a wide variety of networking tasks. These scripts can perform vulnerability detection, backdoor detection, sophisticated discovery, and more. NSE greatly extends Nmap's capabilities beyond basic port scanning.


title: TARGET SPECIFICATION FLEXIBILITY
content:
Nmap offers versatile ways to define target hosts, including individual IP addresses, hostnames, IP ranges (e.g., <i>192.168.1.1-254</i>), CIDR notation (e.g., <i>192.168.1.0/24</i>), and even wildcards (e.g., <i>192.168.1.*</i>). This flexibility allows for efficient scanning of both small and large networks.


title: RESPONSIBLE USAGE
content:
Due to its potent capabilities, <b>nmap</b> should only be used on networks where explicit permission has been granted. Unauthorized scanning can be considered a hostile act and may lead to legal issues or network blocks. Always ensure you have proper authorization before using <b>nmap</b> on any external or production network.


title: HISTORY
content:
<b>nmap</b> was created by Gordon Lyon (who uses the pseudonym "Fyodor") and first released in September 1997 as a Linux magazine article. Initially developed for Linux, it was quickly ported to other systems including Windows, macOS, Solaris, and BSD variants. Its popularity grew rapidly within the information security community due to its power, flexibility, and the frequent inclusion of its features in popular media (like "The Matrix Reloaded"). Nmap has been continuously developed and maintained for over two decades, evolving from a simple port scanner into a comprehensive network reconnaissance suite with a modular scripting engine (NSE) that significantly extends its capabilities.


title: SYNOPSIS
content:
<b>nmcli</b> [<I>GLOBAL_OPTIONS</I>] <b>connection</b> {<I>COMMAND</I> | <I>help</I>}<br><br>Common <b>COMMAND</b>s include: <b>show</b>, <b>up</b>, <b>down</b>, <b>add</b>, <b>modify</b>, <b>delete</b>, <b>clone</b>.


title: PARAMETERS
content:
<b><b>show</b> [<I>NAME</I> | <I>ID</I> | <I>UUID</I> | <I>DEVICE</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all NetworkManager connections or displays detailed information about a specific connection identified by its name, ID, UUID, or the device it's currently active on. Useful for inspecting active and configured profiles.<br><br><b><b>up</b> <I>ID</I> | <I>UUID</I> | <I>NAME</I> | <I>DEVICE</I> [<I>OPTIONS</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specified connection. This command brings the network interface associated with the connection online, applying its configured settings like IP address, DNS servers, etc. It can also manage a specific device or bring up the best matching connection for a device.<br><br><b><b>down</b> <I>ID</I> | <I>UUID</I> | <I>NAME</I> | <I>DEVICE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates a specified connection, taking the associated network interface offline. This stops network communication through that connection.<br><br><b><b>add</b> <b>type</b> <I>TYPE</I> <b>con-name</b> <I>NAME</I> [<I>ifname</I> <I>IFNAME</I>] [<I>OPTIONS</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new connection profile. <I>TYPE</I> specifies the connection type (e.g., <b>ethernet</b>, <b>wifi</b>, <b>vpn</b>, <b>bridge</b>). <I>con-name</I> sets the unique profile name. Further <I>OPTIONS</I> configure specific settings for the chosen connection type (e.g., <b>ip4.addresses</b>, <b>wifi.ssid</b>, <b>vpn.data</b>).<br><br><b><b>modify</b> <I>ID</I> | <I>UUID</I> | <I>NAME</I> [<I>OPTIONS</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies properties of an existing connection profile. This is a very powerful and versatile command, allowing changes to virtually any connection setting, such as IP addresses, DNS servers, Wi-Fi passwords, auto-connect behavior, security protocols, and more. Use with caution as incorrect settings can disrupt network connectivity.<br><br><b><b>delete</b> <I>ID</I> | <I>UUID</I> | <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a specified connection profile from NetworkManager's configuration. Once deleted, the profile can no longer be activated unless re-added.<br><br><b><b>clone</b> <I>ID</I> | <I>UUID</I> | <I>NAME</I> <b>con-name</b> <I>NEW_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new connection profile by copying an existing one. The new profile is assigned a <I>NEW_NAME</I> and inherits all properties from the original connection, which can then be modified independently.<br><br><b><b>monitor</b> [<I>ID</I> | <I>UUID</I> | <I>NAME</I> | <I>DEVICE</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors connection activity and state changes in real-time. Can monitor all connections or a specific connection/device.<br><br><b><b>reload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads all connection profiles from their disk configuration files. This is useful if configuration files were manually edited outside of <b>nmcli</b> or <b>nmtui</b>.<br><br>


title: DESCRIPTION
content:
<b>nmcli connection</b> is a powerful subcommand of <b>nmcli</b> (NetworkManager command-line interface) used to manage NetworkManager connections.<br><br>It allows users to list, add, modify, delete, activate, and deactivate network connections. These connections define how your system connects to various networks (e.g., Wi-Fi, Ethernet, VPN, mobile broadband).<br><br>It provides a comprehensive way to configure network interfaces and their associated settings without needing a graphical user interface (GUI). This command interacts directly with the NetworkManager daemon, ensuring consistent network configuration across reboots and different network states. It's essential for server administration, scripting network setups, and troubleshooting connectivity issues on Linux systems.


title: CAVEATS
content:
<b>nmcli connection</b> generally requires root privileges (or `sudo`) to manage network connections.<br><br>The <b>add</b> and <b>modify</b> commands are highly granular, supporting hundreds of possible properties (e.g., <b>ipv4.method</b>, <b>wifi.ssid</b>, <b>vpn.data</b>). Understanding the specific properties for each connection type often requires consulting the <b>nm-settings(5)</b> man page or using <b>nmcli connection help &lt;TYPE&gt;</b> for detailed syntax.<br><br>Changes made via <b>nmcli</b> are typically persistent across reboots, as they modify the saved connection profiles.


title: CONNECTION TYPES
content:
NetworkManager supports a wide array of connection types, allowing configuration for various networking technologies. Common types include <b>ethernet</b>, <b>wifi</b>, <b>vpn</b>, <b>bridge</b>, <b>bond</b>, <b>team</b>, <b>gsm</b> (mobile broadband), <b>cdma</b>, <b>bluetooth</b>, and <b>vlan</b>. Each connection type has its own set of specific properties that can be configured via <b>nmcli connection add</b> or <b>modify</b>.


title: PROPERTY NAMING CONVENTION
content:
NetworkManager properties generally follow a `section.property-name` convention (e.g., <b>ipv4.addresses</b>, <b>wifi.ssid</b>, <b>connection.autoconnect</b>). This structured naming helps in organizing and identifying the vast number of configurable options. Sections often correspond to specific aspects like IP configuration, Wi-Fi settings, or general connection behavior.


title: PROFILE STORAGE
content:
By default, connection profiles created or modified with <b>nmcli connection</b> are saved as configuration files (typically in the 'INI' or 'keyfile' format) in the `/etc/NetworkManager/system-connections/` directory. Each file represents a single connection profile and persists across system reboots, ensuring network configurations remain active.


title: HISTORY
content:
NetworkManager was developed by Red Hat and initially released in 2004 with the primary goal of simplifying network configuration, especially for desktop users, roaming, and wireless networks. The <b>nmcli</b> command-line utility, including the powerful <b>connection</b> subcommand, was introduced later as a robust scripting and administrative interface. It gained prominence by offering parity with graphical tools and enabling comprehensive network management on headless servers. Its capabilities have steadily evolved to cover almost all NetworkManager features, making it an indispensable tool for Linux network administration.


title: SYNOPSIS
content:
node [<i>options</i>] [<i>script.js</i> | -e "<i>script_string</i>" | - ] [<i>script_arguments</i>...]<br>node [<i>options</i>] (<i>starts REPL if no script or eval provided</i>)


title: PARAMETERS
content:
<b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Node.js version.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays Node.js command-line options and usage information.<br><br><b>-e "<i>script</i>", --eval="<i>script</i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the provided JavaScript <i>script</i> string as code.<br><br><b>-p "<i>script</i>", --print="<i>script</i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the provided JavaScript <i>script</i> string and prints the result to stdout.<br><br><b>-c, --check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a syntax check on the script without executing it.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters the Node.js REPL (Read-Eval-Print Loop) after the script finishes execution.<br><br><b>-r "<i>module</i>", --require="<i>module</i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preloads the specified <i>module</i> at startup, useful for polyfills or debuggers.<br><br><b>--inspect[=[host:]port]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the Node.js inspector agent for debugging and profiling, listening on the specified host and port (default: 127.0.0.1:9229).<br><br><b>--experimental-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables experimental ECMAScript module (ESM) support.<br><br><b>--no-warnings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all Node.js process warnings.<br><br><b>--trace-warnings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints stack traces for Node.js process warnings.<br><br><b>--v8-options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints command-line options for V8, Node.js's JavaScript engine.<br><br>


title: DESCRIPTION
content:
Node.js is an <b>open-source</b>, <b>cross-platform</b> JavaScript runtime environment that executes JavaScript code outside a web browser. It leverages Google's V8 JavaScript engine, known for its high performance. Node.js empowers developers to build <b>scalable network applications</b>, commonly employed for web servers, APIs, and microservices.<br><br>Its unique <i>event-driven</i>, <i>non-blocking I/O model</i> makes it remarkably lightweight and efficient, particularly suited for data-intensive real-time applications. Node.js is complemented by a vast ecosystem of open-source libraries, primarily managed by <b>npm</b> (Node Package Manager). It provides robust support for common server-side operations, including file system access, network communication, and database interaction, making it a versatile platform for both backend development and command-line tools.


title: CAVEATS
content:
While powerful, Node.js's single-threaded event loop can become a bottleneck for CPU-bound tasks if not properly managed (e.g., by offloading to worker threads). Memory management requires careful attention in large-scale applications to prevent leaks. Compatibility issues with specific npm packages and Node.js versions can also arise, necessitating careful dependency management.


title: NPM (NODE PACKAGE MANAGER)
content:
<b>npm</b> is the default package manager for Node.js, providing access to a vast registry of open-source JavaScript libraries and tools. It simplifies dependency management, package installation, and project scaffolding for Node.js applications.


title: REPL (READ-EVAL-PRINT LOOP)
content:
Node.js includes an interactive REPL environment accessible by running `node` without arguments. This console allows users to execute JavaScript code snippets, test functionalities, and experiment with Node.js APIs directly, making it an excellent tool for learning and debugging.


title: EVENT LOOP
content:
At its core, Node.js operates on an <i>event loop</i>, which allows it to perform non-blocking I/O operations despite being single-threaded. This mechanism efficiently handles asynchronous tasks (like network requests or file operations) by offloading them and continuing with other code, then processing their results when they complete, leading to high throughput.


title: HISTORY
content:
Created by Ryan Dahl in 2009, Node.js emerged as a groundbreaking platform for server-side JavaScript, utilizing Google's V8 engine. Its innovative <i>event-driven</i>, <i>non-blocking I/O model</i> quickly gained traction for building scalable network applications. Initially Linux-centric, its support rapidly expanded to other operating systems. A significant event in its history was the 2014 fork into io.js due to governance concerns, which subsequently merged back into the Node.js project in 2015, strengthening its community and development process. Node.js continues to be a cornerstone of modern web development, maintained by the OpenJS Foundation.


title: PARAMETERS
content:
<b><I>None</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>true</b> command and the <b>:</b> (colon) command (conceptual equivalents of <b>nop</b>) take no operational parameters or arguments that alter their behavior. They always succeed and perform no actions. <br><i>Note: Standard options like <b>--help</b> or <b>--version</b> might be supported by the specific shell built-in implementation, but are not unique to its 'no-operation' function.</i><br><br>


title: DESCRIPTION
content:
The term "nop" (No OPeration) refers to an instruction or command that does nothing, literally performing a null operation. <br>Unlike many Linux commands, there is typically no standalone executable file named `<b>/bin/nop</b>`. Instead, the functionality of a no-operation is embodied by highly optimized shell built-in commands or specific CPU instructions. <br>In Unix-like shell environments, the most common commands that serve as "nop" equivalents are `<b>true</b>` and `<b>:</b>` (the colon command). <br><br>The `<b>true</b>` command always exits with a status of 0 (indicating success) and performs no action. It is extremely lightweight and fast. <br>The `<b>:</b>` command is also a null command, a shell built-in that takes arguments but ignores them, always exiting with a status of 0. It is often used as a placeholder or a very efficient way to ensure a successful exit status. <br><br>The primary utility of a no-operation command lies in scripting, where it can be used as a placeholder, to create infinite loops (`while true; do ...; done`), or to ensure a successful command chain without performing any side effects.


title: CAVEATS
content:
There is no standard standalone executable program named `<b>nop</b>` on most Linux systems. Its functionality is provided by shell built-ins (`<b>true</b>`, `<b>:</b>`) or is a concept from CPU instruction sets. <br>While `<b>true</b>` and `<b>:</b>` do 'nothing', they are still commands that the shell must parse and execute, consuming a negligible amount of CPU time and memory. They are highly optimized for this purpose and are almost instantaneous.


title: USAGE IN SCRIPTING
content:
No-operation commands like `<b>true</b>` or `<b>:</b>` are extensively used in shell scripting for various purposes:<br><br><b>1. Placeholders:</b> To reserve a spot for future code without causing syntax errors. <br>   Example: `<i>if condition; then<br>     :<br>   else<br>     # do something<br>   fi</i>`<br><br><b>2. Infinite Loops:</b> `<b>true</b>` is commonly used to create loops that run indefinitely. <br>   Example: `<i>while true; do<br>     echo 'Looping forever... Press Ctrl+C to exit.'<br>     sleep 1<br>   done</i>`<br><br><b>3. Consuming Piped Input:</b> While not their primary role, they can be used to consume input from a pipe, effectively discarding it. <br>   Example: `<i>cat /etc/passwd | :</i>`<br><br><b>4. Ensuring Success:</b> To ensure a command chain always exits successfully, especially when a command might fail but its failure shouldn't stop the script. <br>   Example: `<i>unzip archive.zip || true</i>` (attempts unzip, but if it fails, `<b>true</b>` ensures the command exits with 0).<br><br><b>5. Conditional Expressions:</b> Used in `<b>if</b>` statements or `<b>&&</b>` / `<b>||</b>` constructs. <br>   Example: `<i>[ "$DEBUG" = "true" ] && : || echo "Not in debug mode"</i>` (if DEBUG is true, do nothing, otherwise print message).


title: CPU NOP INSTRUCTION
content:
At the lowest level of computing, a CPU NOP instruction is a single machine language instruction that performs no action other than advancing the program counter. It's crucial for:<br><br><b>1. Padding:</b> Aligning code for optimal performance or patching programs without re-compilation.<br><b>2. Timing:</b> Introducing delays in real-time systems (though less common now with dedicated timers).<br><b>3. Stubs:</b> Temporarily replacing or disabling specific code sections during development or debugging.<br><b>4. Security:</b> In some exploits (e.g., NOP sleds), a sequence of NOPs can be used to reliably jump to malicious code.


title: HISTORY
content:
The concept of a 'No OPeration' instruction originates from low-level computer architecture and assembly language programming (e.g., x86 `NOP` instruction). It's a CPU instruction that tells the processor to do nothing for one clock cycle, often used for timing, memory alignment, or as a placeholder. <br><br>In the context of Unix-like operating systems and shell scripting, this concept evolved into commands like `<b>true</b>` and `<b>:</b>`. These commands serve the same high-level purpose of performing no meaningful action while still providing a successful exit status, making them invaluable for flow control and scripting logic without side effects. They have been fundamental built-ins in various shells (like sh, bash, zsh) since early Unix versions.


title: PARAMETERS
content:
<b><b>--audit-level=&lt;level&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the minimum vulnerability level to display (info, low, moderate, high, critical). Defaults to 'info'.<br><br><b><b>--production</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the audit only on production dependencies (dependencies listed in `dependencies`, not `devDependencies`).<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the audit report in JSON format.<br><br><b><b>--package-lock-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces `npm audit` to use `package-lock.json` (or `npm-shrinkwrap.json`) as the primary source of dependency information, rather than `node_modules`.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <b>npm audit fix</b>, this option forces a fix, even if it introduces breaking changes or conflicts.<br><br><b><b>--legacy-peer-deps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the installation of packages with unmet peer dependencies in `npm audit fix`.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;With <b>npm audit fix</b>, show what changes would be made without actually applying them.<br><br><b><b>--omit=&lt;type&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specific dependency types from the audit. Can be `dev` or `peer`. Can be specified multiple times.<br><br><b><b>--include=&lt;type&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly include specific dependency types. Can be `dev` or `peer`. Can be specified multiple times. Conflicts with `--omit`.<br><br>


title: DESCRIPTION
content:
<i>npm-audit</i> scans your project's dependency tree for known security vulnerabilities. It leverages a vulnerability database maintained by npm, which is populated by security researchers and companies. When you run <b>npm audit</b>, npm sends a description of your project's dependencies (from your <b>package-lock.json</b> file) to the default npm registry. The registry then responds with a report detailing any identified vulnerabilities.<br><br>The report provides information on the severity of the vulnerability, affected packages, and paths through the dependency tree. It also suggests remediation steps, often including updates to vulnerable packages. A common remediation is <b>npm audit fix</b>, which attempts to automatically resolve identified vulnerabilities by upgrading packages to non-vulnerable versions or by modifying the dependency tree. This command is crucial for maintaining the security posture of Node.js applications by proactively identifying and addressing potential security risks before they can be exploited.


title: CAVEATS
content:
While <b>npm audit</b> is a powerful tool, it's not foolproof. It relies on a known vulnerability database, meaning zero-day vulnerabilities might not be detected. <br><br>Using <b>npm audit fix --force</b> can sometimes introduce breaking changes to your project, as it might upgrade major versions of dependencies. Always test thoroughly after running `fix` commands, especially with `force`.<br><br>The audit results can sometimes include false positives or issues that are not exploitable in your specific context.


title: EXIT CODES
content:
<b>npm audit</b> exits with code 0 if no vulnerabilities are found, and a non-zero exit code if any vulnerabilities are found. This makes it suitable for use in CI/CD pipelines to enforce security checks.


title: AUTOMATIC FIXES (NPM AUDIT FIX)
content:
When run as <b>npm audit fix</b>, npm attempts to automatically resolve vulnerabilities by upgrading packages to non-vulnerable versions. It prioritizes non-breaking changes (patch and minor upgrades). If a major version upgrade is required to fix a vulnerability, it will be noted in the report but not automatically applied unless <b>--force</b> is used.


title: HISTORY
content:
The <b>npm audit</b> command was introduced in npm version 6.0.0, released in April 2018. Its introduction marked a significant step in npm's focus on security, providing developers with an integrated tool to identify and mitigate known vulnerabilities directly within their development workflow. Before its introduction, developers relied on third-party tools or manual checks to perform similar security analyses.


title: PARAMETERS
content:
<b><I>package-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Optional</I>. The name of the npm package whose homepage should be opened. If omitted, <B>npm-home</B> looks for a <I>package.json</I> file in the current directory and uses the <I>homepage</I> field from that file.<br><br>


title: DESCRIPTION
content:
<b>npm-home</b> is a utility that opens the specified npm package's homepage in your default web browser.<br><br>It's commonly installed as a global npm package, acting as a convenient wrapper around the official <I>npm home</I> command. When executed without a package name, it attempts to open the homepage for the npm package defined in the <I>package.json</I> file of the current working directory. If a package name is provided, it fetches information about that package from the npm registry and opens its declared homepage URL.<br><br>This command streamlines access to a package's primary web presence, which typically includes documentation, project information, and links to the source repository. It relies on the presence of a "homepage" field within the package's <I>package.json</I> metadata. The command delegates the task of opening the URL to the operating system's default application handler for web links.


title: CAVEATS
content:
This command requires Node.js and npm to be installed on your system.<br>It relies on the <I>homepage</I> field being present and correctly formatted in the target package's <I>package.json</I> metadata. If the field is missing or invalid, the command may fail or report an error.<br><B>npm-home</B> is often a global executable wrapper for the core <I>npm home</I> command, which is built directly into the npm CLI.<br>A default web browser must be configured on your operating system for the command to successfully open the URL.


title: <B>RELATIONSHIP WITH <I>NPM HOME</I></B>
content:
While <B>npm-home</B> functions as a standalone command, it often executes the underlying <I>npm home</I> subcommand provided by the main npm CLI. This means its core behavior and dependencies are tied to your npm installation.


title: <B>HOMEPAGE RESOLUTION</B>
content:
The command determines the homepage URL by reading the <I>homepage</I> field from the specified package's <I>package.json</I> file, either locally or fetched from the npm registry. Ensure this field is present and accurate for desired behavior.


title: <B>BROWSER INTERACTION</B>
content:
The command doesn't open a browser directly; instead, it delegates the URL opening to your operating system's default application for handling web links (e.g., <I>xdg-open</I> on Linux, <I>open</I> on macOS, <I>start</I> on Windows).


title: HISTORY
content:
The <I>npm home</I> command, which <B>npm-home</B> typically wraps, was introduced as a built-in subcommand in npm version 6.0.0. Before this, similar functionality might have been provided by standalone npm packages or by manually looking up package details. The <B>npm-home</B> package itself emerged to provide a more direct, globally executable command for this common task.


title: SYNOPSIS
content:
<b>npm list</b> [<I>package_spec</I>] [<I>options</I>]<br><br>Example: <b>npm list</b><br>Example: <b>npm list react --depth=0</b><br>Example: <b>npm list --global --json</b>


title: PARAMETERS
content:
<b><b>--depth=<n></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the depth of the dependency tree. <I>0</I> shows only top-level packages.<br><br><b><b>--global</b> / <b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists packages installed globally rather than in the current project.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the dependency tree in JSON format, useful for programmatic parsing.<br><br><b><b>--parseable</b> / <b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs a list of package paths, one per line, suitable for scripting.<br><br><b><b>--long</b> / <b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows more detailed information about each package, including licenses and repository URLs.<br><br><b><b>--prod</b> / <b>--production</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only production dependencies (excludes development dependencies).<br><br><b><b>--dev</b> / <b>--development</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only development dependencies (excludes production dependencies).<br><br><b><b>--link</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only packages that are symlinked (e.g., via <I>npm link</I>).<br><br><b><b>--omit=<type></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Omits specific types of dependencies. <I>type</I> can be <I>dev</I>, <I>optional</I>, or <I>peer</I>. Can be used multiple times.<br><br><b><b>--include=<type></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes specific types of dependencies. <I>type</I> can be <I>dev</I>, <I>optional</I>, or <I>peer</I>. Can be used multiple times.<br><br><b><b>--package-lock-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads and lists dependencies only from the <I>package-lock.json</I> (or <I>npm-shrinkwrap.json</I>) file.<br><br><b><b>--workspaces</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists dependencies for all configured workspaces in the current project.<br><br><b><b>--include-workspace-root</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <I>--workspaces</I>, includes the workspace root project's dependencies in the output.<br><br><b><b>--loglevel=<level></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the level of logging output. Common levels: <I>silent</I>, <I>error</I>, <I>warn</I>, <I>http</I>, <I>info</I>, <I>verbose</I>, <I>silly</I>.<br><br>


title: DESCRIPTION
content:
The <b>npm list</b> command (also aliased as <b>npm ls</b>) displays a tree of all installed packages in the current project, or globally if the <b>--global</b> flag is used. It shows dependencies, their versions, and their own dependencies, forming a hierarchical structure.<br><br>This command is crucial for understanding your project's dependency graph, identifying package versions, and troubleshooting dependency-related issues like conflicts or missing packages. By default, it lists top-level packages and their immediate dependencies. Options allow controlling the depth of the tree, output format (human-readable, JSON, parseable), and filtering by package type (production, development). It helps visualize the entire dependency ecosystem within a project.


title: CAVEATS
content:
Large projects with deep dependency trees can produce extremely long outputs, making it difficult to read in the terminal. Using options like <I>--depth</I>, <I>--json</I>, or <I>--parseable</I> is highly recommended for managing output.<br><br>The command might show <I>UNMET PEER DEPENDENCY</I> warnings if peer dependencies are not satisfied. These are warnings, not errors, and indicate that a package expects a certain version of another package that isn't met by your current installation.<br><br>If <I>node_modules</I> is corrupted or missing, the command might fail or show an incomplete tree. Running <I>npm install</I> beforehand can resolve this.


title: UNDERSTANDING THE OUTPUT STRUCTURE
content:
The default output of <b>npm list</b> is a graphical representation of the dependency tree, using ASCII characters to show parent-child relationships. Each line typically shows the package name, its version, and sometimes additional indicators like <I>deduped</I> or <I>linked</I>.


title: INTERACTION WITH <I>PACKAGE-LOCK.JSON</I>
content:
By default, <b>npm list</b> inspects the actual <I>node_modules</I> directory. However, when <I>--package-lock-only</I> is used, it reads the tree structure purely from the <I>package-lock.json</I> file, which reflects the exact dependency tree that <I>npm install</I> would create, without needing the <I>node_modules</I> directory to exist or be complete.


title: DEALING WITH SYMLINKS
content:
<b>npm list</b> shows symlinked packages (e.g., those installed via <I>npm link</I>) differently, often indicating them with an arrow (<I>-></I>) and their source path. The <I>--link</I> option allows filtering the output to only show these linked packages.


title: HISTORY
content:
The <b>npm list</b> command has been a fundamental part of npm since its early versions, providing core functionality for inspecting the project's dependency graph. As npm evolved, new options were added to enhance its utility, such as <I>--json</I> for programmatic interaction, <I>--depth</I> for controlling output size, and support for workspaces. Its purpose remains consistent: to offer a clear, structured view of all installed Node.js packages and their relationships within a project or globally.


title: SEE ALSO
content:
npm install(1), npm uninstall(1), npm outdated(1), npm view(1), npm ls(1), yarn why(1), pnpm list(1)


title: PARAMETERS
content:
<b>--registry=<registry url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the npm registry to log out from. If not provided, it defaults to the primary registry defined in the npm configuration.<br><br><b>--scope=<scope></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used to target credentials associated with a specific scope within a registry. While primarily used with <i><b>npm login</b></i>, it can help clarify which scoped credentials are being removed if multiple are present for a given registry.<br><br>


title: DESCRIPTION
content:
The <i><b>npm logout</b></i> command effectively terminates the current user's authenticated session with an npm registry. It removes authentication credentials, such as tokens, username, and password entries, from the user's local <i>.npmrc</i> configuration file. After logging out, subsequent npm commands requiring authentication (e.g., <i><b>npm publish</b></i> or installing private packages) will fail until the user logs in again using <i><b>npm login</b></i>. This command is crucial for security, especially when working on shared machines or switching user accounts. By default, it logs out from the default npm registry, but can be targeted to specific registries using the <i>--registry</i> option.


title: CAVEATS
content:
<i><b>npm logout</b></i> only removes authentication tokens from your local <i>.npmrc</i> configuration file(s). It does <b>not</b> invalidate or revoke the token on the registry server itself. The token remains valid on the server until it expires or is explicitly revoked via the registry's web interface (e.g., npmjs.com user settings page). If you have multiple <i>.npmrc</i> files (e.g., user, global, project), this command primarily affects the user-level <i>~/.npmrc</i> file.


title: HOW IT WORKS
content:
Upon execution, <i><b>npm logout</b></i> intelligently locates and deletes authentication-related entries (such as <i>_authToken</i>, <i>username</i>, and sometimes <i>_password</i>) from the relevant <i>.npmrc</i> file(s) for the specified or default registry. This action ensures that subsequent API requests to the registry from your machine will no longer include the necessary authentication headers, effectively 'logging you out' from a local perspective.


title: SECURITY BEST PRACTICE
content:
Using <i><b>npm logout</b></i> is a recommended security measure, especially when working on public or shared computers. It prevents unauthorized access to your npm account, safeguarding against accidental publishing or access to private packages under your credentials after you've finished your session.


title: HISTORY
content:
The <i><b>npm logout</b></i> command has been a fundamental part of the npm CLI's authentication system since its early development. Introduced to complement <i><b>npm login</b></i>, its core functionality—removing local authentication tokens—has remained consistent throughout npm's evolution. It serves as a standard and essential utility for managing user sessions with npm registries.


title: SYNOPSIS
content:
<b>npm star</b> [<I>package-spec</I>...]<br><b>npm unstar</b> [<I>package-spec</I>...]<br><b>npm star</b>


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in JSON format.<br><br><b>--long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display extended information when listing starred packages.<br><br><b>--parseable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in a parseable format, suitable for scripts.<br><br><b>--otp <code-to-enter></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a one-time password for two-factor authentication.<br><br><b>--registry <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the npm registry to use for the operation.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the command without making actual changes.<br><br><b>--loglevel <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the level of logging output (e.g., silent, warn, info, debug).<br><br><b>--silent, -s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output messages.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output except warnings and errors.<br><br><b>--workspace <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute command in a specific workspace within a monorepo.<br><br><b>--workspaces, -ws</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute command in all configured workspaces.<br><br><b>--include-workspace-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include the workspace root when executing in all workspaces.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information for the command.<br><br>


title: DESCRIPTION
content:
The <b>npm star</b> command allows users to publicly "star" npm packages they find useful or interesting. This action adds the package to the user's list of starred packages, visible on their npm profile. It also contributes to the package's overall popularity and visibility within the npm registry, potentially influencing search results and community recommendations. The command can also be used to "unstar" a previously starred package or, when invoked without arguments, to display a list of all packages the current user has starred. Starring is a simple yet effective way for the community to show appreciation and discover popular modules.


title: CAVEATS
content:
Starring or unstarring a package requires you to be authenticated and logged into the npm registry. The action of starring is public and visible on your npm profile and the package's official page.


title: PUBLIC VISIBILITY
content:
When you star a package, this action is publicly associated with your npm profile. This information is visible to others and contributes to the package's overall popularity count displayed on the npm registry.


title: COMMUNITY DISCOVERY
content:
Stars play a role in the npm ecosystem by helping other users discover popular or highly regarded packages. Higher star counts can influence search results and make packages more prominent in community-curated lists.


title: HISTORY
content:
The ability to star npm packages has been a core feature of the npm registry and CLI since its early days. It was designed to foster community engagement and provide a mechanism for users to express appreciation and track favorite modules. It has remained a consistent feature across npm versions, playing a role in community-driven package discovery.


title: PARAMETERS
content:
<b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This special parameter indicates the end of <i>npm</i> options and the beginning of arguments that should be passed directly to the script being executed. For example, <i>npm start -- --port 8080</i> would pass <i>--port 8080</i> to the <i>start</i> script, assuming the script processes such arguments.<br><br>


title: DESCRIPTION
content:
<i>npm start</i> is a convenient command provided by Node.js's package manager, <i>npm</i>. It's primarily used to execute the script named "start" defined in the <i>scripts</i> section of a project's <i>package.json</i> file. This command serves as a standardized way to kick off a project, whether it's a web server, a build process, or a development environment. When <i>npm start</i> is run, <i>npm</i> looks for the "start" entry in the <i>scripts</i> object and executes its associated value using a shell. If no "start" script is explicitly defined, <i>npm</i> has a default fallback behavior: it will attempt to run <i>node server.js</i> or <i>node index.js</i> if those files exist in the project's root directory. This makes <i>npm start</i> incredibly versatile, acting as the primary entry point for running most Node.js applications or related development tasks. It streamlines the workflow by abstracting away the underlying commands, allowing developers to remember one simple command to get their project running.


title: CAVEATS
content:
<ul><li><b>Reliance on <i>package.json</i></b>: <i>npm start</i> depends entirely on a <i>package.json</i> file existing in the current or a parent directory, and ideally, having a "start" script defined within its <i>scripts</i> section.<br></li><li><b>Script-Dependent Behavior</b>: The actual behavior of <i>npm start</i> is determined solely by the command(s) specified in the "start" script. If the script contains errors or invalid commands, <i>npm start</i> will fail accordingly.<br></li><li><b>Process Management</b>: <i>npm start</i> executes a script, but it does not inherently provide robust process management features (like monitoring, restarting, or daemonizing) out of the box. For production environments, tools like PM2, <i>systemd</i>, or Docker are often used in conjunction with or instead of directly running <i>npm start</i>.<br></li><li><b>Fallback Logic</b>: While convenient, relying on the default fallback (<i>node server.js</i> or <i>node index.js</i>) can sometimes be less explicit and harder to debug than a clearly defined "start" script.</li></ul>


title: PASSING ARGUMENTS TO THE SCRIPT
content:
When you need to pass specific arguments to the underlying script executed by <i>npm start</i>, you must use a double dash (<i>--</i>) after <i>npm start</i>. This signals to <i>npm</i> that all subsequent arguments should be treated as arguments for the script, not for <i>npm</i> itself. For example, if your <i>start</i> script is <i>node server.js</i>, you could run <i>npm start -- --port 3000</i> to pass <i>--port 3000</i> to <i>node server.js</i>.


title: DEFAULT <I>START</I> SCRIPT BEHAVIOR
content:
If no "start" script is explicitly defined in your <i>package.json</i>, <i>npm</i> will attempt to execute a default script. Specifically, it looks for <i>index.js</i> or <i>server.js</i> in the project's root directory and tries to run <i>node index.js</i> or <i>node server.js</i> respectively. This fallback provides a simple way to run basic Node.js applications without needing to configure a "start" script, though it's generally recommended to define one for clarity and control.


title: HISTORY
content:
The <i>npm</i> command-line interface, including the <i>start</i> command, has been an integral part of the Node.js ecosystem since its early days. As Node.js gained popularity, <i>npm</i> emerged as the standard package manager, and its <i>scripts</i> feature, including dedicated shortcuts like <i>start</i>, <i>test</i>, and <i>install</i>, was designed to standardize common project operations. The <i>start</i> command quickly became the de facto way to launch a Node.js application or development server, simplifying project onboarding and execution across different environments and teams. Its evolution has been tied directly to the growth and needs of the Node.js developer community, emphasizing convenience and convention over configuration.


title: PARAMETERS
content:
<b><I>script_args</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments that will be passed directly to the custom "stop" script being executed. These arguments are typically separated from <b><I>npm</I></b>'s own options by a double-hyphen (<b>--</b>) for clarity, though <b><I>npm</I></b> often passes subsequent arguments to the script even without it for lifecycle commands.<br><br><b><b>--</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A conventional separator used to distinguish options intended for the <b><I>npm</I></b> command itself from arguments intended for the underlying "stop" script. While often optional for lifecycle scripts, its use is recommended for clarity and robustness.<br><br>


title: DESCRIPTION
content:
The <b><I>npm</I> stop</b> command is a convenience alias that executes the "stop" script defined in the <b><I>scripts</I></b> section of a project's <b><I>package.json</I></b> file.<br><br>Unlike system-level commands like <b><I>systemctl stop</I></b> or <b><I>kill</I></b>, <b><I>npm stop</I></b> does not inherently know how to stop a running application or process. Instead, it relies entirely on a user-defined script that encapsulates the specific logic required to shut down the application or perform any necessary cleanup tasks.<br><br>If a "stop" script is not defined in <b><I>package.json</I></b>, running <b><I>npm stop</I></b> will typically result in a warning or an error indicating that the script was not found, and no action will be performed.


title: CAVEATS
content:
<I>Dependency on <b><I>package.json</I></b></I>: The command's functionality is entirely dependent on the presence and content of a <b><I>stop</I></b> script within the <b><I>scripts</I></b> section of the project's <b><I>package.json</I></b> file.<br><br><I>No built-in process management</I>: <b><I>npm stop</I></b> does not inherently know how to stop a running application process. It merely executes a user-defined command that *should* handle the stopping logic (e.g., using <b><I>kill</I></b>, <b><I>pkill</I></b>, sending signals, or gracefully shutting down a server).<br><br><I>Error if script missing</I>: If no <b><I>stop</I></b> script is defined, <b><I>npm</I></b> will typically exit with a warning or an error, indicating the script was not found, and no action will be performed.<br><br><I>Security Risk</I>: As the script content is user-defined, poorly written or malicious scripts could cause unintended side effects, data loss, or security vulnerabilities.


title: DEFINING THE `STOP` SCRIPT
content:
To make <b><I>npm stop</I></b> functional, you must define a <b><I>stop</I></b> script in your project's <b><I>package.json</I></b> file. Here's an example:<br><br><b><I>{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "start": "node index.js",
    "stop": "kill $(lsof -t -i:3000 || echo -1) || echo 'No process on port 3000 to stop'" 
  }
}</I></b><br><br>In this example, the <b><I>stop</I></b> script attempts to find and kill a process running on port 3000. The specific command will vary greatly depending on your application's architecture and how it's started.


title: COMMON USE CASES
content:
<b><I>npm stop</I></b> is commonly used for:<br><br><ul><li>Shutting down a running web server (e.g., Node.js server, Express app).</li><li>Terminating background processes launched by <b><I>npm start</I></b> or other scripts.</li><li>Performing cleanup tasks like removing temporary files or database connections before the application fully shuts down.</li><li>As part of a <b><I>npm restart</I></b> command, where <b><I>stop</I></b> is called before <b><I>start</I></b>.</li></ul>


title: HISTORY
content:
<b><I>npm</I></b> (Node Package Manager) introduced the concept of lifecycle scripts early in its development to standardize common project tasks. Commands like <b><I>start</I></b>, <b><I>stop</I></b>, <b><I>test</I></b>, and <b><I>install</I></b> are convenient aliases for <b><I>npm run <script-name></I></b>. This mechanism allows developers to define custom behaviors for these conventional actions, making <b><I>npm stop</I></b> a consistent way to invoke project shutdown or cleanup logic across different Node.js applications, fostering better project maintainability and reproducibility.


title: PARAMETERS
content:
<b>add <i>&lt;scope:team&gt;</i> <i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a user to a specified team within an organization.<br><br><b>create <i>&lt;scope:team&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new team within an organization.<br><br><b>destroy <i>&lt;scope:team&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Destroys (deletes) an existing team within an organization.<br><br><b>ls [<i>&lt;scope&gt;</i>|<i>&lt;scope:team&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all teams within an organization, or all members of a specific team.<br><br><b>rm <i>&lt;scope:team&gt;</i> <i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a user from a specified team within an organization.<br><br>


title: DESCRIPTION
content:
The <b>npm team</b> command is a crucial tool for managing access control and collaboration within npm organizations. It allows organization administrators to create, destroy, and modify teams, as well as add or remove users from these teams. Teams provide a granular way to assign permissions to private npm packages, ensuring that only authorized users or CI/CD systems have access to sensitive code. By structuring members into teams, administrators can efficiently manage permissions across multiple packages without individually adjusting each user's access rights. This command integrates directly with the npm registry's organization features, streamlining team-based development workflows and enhancing security for proprietary or internal package sharing. It is commonly used in enterprise and team development environments where shared private modules are prevalent.


title: CAVEATS
content:
All <b>npm team</b> operations require the user to be an administrator of the target npm organization. Authentication via <b>npm login</b> is necessary before executing commands. The specified <i>&lt;scope&gt;</i> must correspond to an existing npm organization. Team management features are specific to the npm registry and not directly applicable to other package registries without explicit support.


title: PERMISSIONS AND SCOPE
content:
All <b>npm team</b> operations require the user to be an administrator of the target npm organization. The <i>&lt;scope&gt;</i> argument refers to the organization's name (e.g., <i>@myorg</i>), and <i>&lt;team&gt;</i> refers to the team's slug within that organization (e.g., <i>developers</i>). The full team identifier is typically <i>&lt;scope&gt;:&lt;team&gt;</i>. These commands primarily interact with the npm registry, affecting permissions for private packages owned by the organization.


title: INTEGRATION WITH NPM ACCESS
content:
Teams created and managed with <b>npm team</b> can be used directly with <b>npm access</b> to grant or revoke read/write access to private packages for an entire group of users, rather than managing permissions user by user. For example, to grant a team write access to a package: <b>npm access grant read-write <i>&lt;scope:team&gt;</i> <i>&lt;package-name&gt;</i></b>.


title: HISTORY
content:
The concept of organizations and teams was introduced to the npm CLI with <b>npm@2.0.0</b>, released in October 2014. The <b>npm team</b> command was specifically designed to provide a dedicated interface for managing these new access control features, enhancing the capabilities for large-scale and enterprise development. It has since been a stable part of the npm CLI, evolving alongside other access management commands like <b>npm access</b>.


title: SYNOPSIS
content:
<code><b>npm token</b> <I>list</I></code><br><code><b>npm token</b> <I>create</I> [<I>--read-only</I>] [<I>--cidr</I> &lt;<i>ip-range</i>&gt;] [<I>--description</I> &lt;<i>text</i>&gt;]</code><br><code><b>npm token</b> <I>revoke</I> &lt;<i>token-id</i>&gt;</code>


title: PARAMETERS
content:
<b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all active authentication tokens associated with the current npm user account. It displays token IDs, creation dates, last access dates, and any associated CIDR restrictions or read-only status.<br><br><b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new authentication token. This subcommand typically prompts for a one-time password (OTP) if two-factor authentication (2FA) is enabled for the npm account.<br><br><b>--read-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Applicable to <b>create</b></i>) Creates a token that grants read-only access to the npm registry. This token can install packages but cannot publish new ones.<br><br><b>--cidr <ip-range></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Applicable to <b>create</b></i>) Restricts the newly created token's usage to a specific IP address range (e.g., <code>192.168.1.0/24</code>). Multiple <code>--cidr</code> options can be provided to specify several allowed ranges.<br><br><b>--description <text></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Applicable to <b>create</b></i>) Assigns a descriptive text to the new token, making it easier to identify its purpose later when listing tokens.<br><br><b>revoke <token-id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates and deletes a specific authentication token. The <code>token-id</code> is obtained from the output of <code>npm token list</code>. Once revoked, the token can no longer be used for authentication.<br><br>


title: DESCRIPTION
content:
The <b>npm token</b> command is a crucial utility within the Node Package Manager (npm) ecosystem for managing authentication tokens. These tokens are used to authenticate with the npm registry, enabling actions such as publishing packages, installing private packages, or accessing scoped packages. The command provides functionalities to list, create, and revoke tokens, offering granular control over access permissions. This is especially important for continuous integration (CI) environments or shared development setups where direct password-based login is less secure or practical. By using tokens, developers can ensure that automated processes or specific machines have the necessary permissions without exposing full user credentials.


title: CAVEATS
content:
<b>Security:</b> Treat npm tokens as sensitive as your password. They grant access to your npm account. Do not expose them in public repositories or insecure environments.<br><b>Revocation:</b> Always revoke tokens that are no longer needed or if you suspect they have been compromised.<br><b>2FA:</b> If you have two-factor authentication (2FA) enabled for your npm account, creating a new token will require a one-time password (OTP) during the process.<br><b>CIDR Restrictions:</b> While helpful, CIDR restrictions are based on the client's public IP address. If the client's IP changes frequently or is behind a proxy, this restriction might cause issues.


title: WHERE TOKENS ARE STORED
content:
npm tokens are typically stored securely in the <code>~/.npmrc</code> file on your local machine. However, the <code>npm token</code> command manages these on the <i>registry side</i>. When you create a token, it's generated by the registry and then saved to your <code>~/.npmrc</code>.


title: RECOMMENDED USAGE
content:
For CI/CD workflows, it's best practice to create dedicated read-only tokens or tokens with strict CIDR restrictions. Avoid using your primary login credentials or tokens with full publishing access in automated scripts or publicly accessible build environments.


title: HISTORY
content:
The concept of authentication tokens for npm gained prominence as Continuous Integration/Continuous Delivery (CI/CD) pipelines became standard practice. Earlier methods often relied on storing usernames and passwords directly, which posed significant security risks. With the introduction of granular authentication tokens, npm provided a more secure and manageable way for automated systems and shared environments to interact with the registry. This feature significantly improved security posture and operational efficiency for npm users.


title: SYNOPSIS
content:
<b>npm uninstall &lt;package-name&gt;</b><br><b>npm uninstall &lt;package-name&gt;@&lt;version&gt;</b><br><b>npm uninstall -g &lt;package-name&gt;</b><br><b>npm uninstall &lt;package-name&gt; --save-dev</b><br><b>npm un &lt;package-name&gt;</b><i> (alias)</i><br><b>npm rm &lt;package-name&gt;</b><i> (alias)</i>


title: PARAMETERS
content:
<b>-g, --global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the package from the global installation directory.<br><br><b>--save-dev, -D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the package from 'devDependencies' in package.json.<br><br><b>--save-optional, -O</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the package from 'optionalDependencies' in package.json.<br><br><b>--no-save</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents updating 'package.json' and 'package-lock.json'.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the uninstall process without making any actual changes.<br><br><b>--ignore-scripts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents preuninstall and postuninstall lifecycle scripts from running.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forcefully removes a package, even if it is a dependency of another installed package. Use with extreme caution.<br><br>


title: DESCRIPTION
content:
<i>npm uninstall</i> is a fundamental command used to remove installed <I>Node.js</I> packages from your project's <I>node_modules</I> directory, or globally from your system. When executed, it meticulously unlinks and deletes the specified package and its associated files.<br><br>For local project installations, it automatically updates your <I>package.json</I> file by removing the entry from the <I>dependencies</I>, <I>devDependencies</I>, or <I>optionalDependencies</I> section, and also updates the <I>package-lock.json</I> to reflect the new dependency tree. This ensures consistency and reproducibility of your project's environment. The command is crucial for managing project size, removing unused libraries, resolving dependency conflicts, or reverting unwanted installations. It efficiently cleans up your environment, helping maintain a tidy and performant development setup.


title: CAVEATS
content:
<i><b>Permission Issues:</b></i> Global uninstalls often require elevated privileges (e.g., <I>sudo</I> on Linux/macOS, Administrator on Windows).<br><i><b>Broken Dependencies:</b></i> Using <I>--force</I> can remove packages that other installed packages depend on, potentially breaking your project or other global tools.<br><i><b>Leftover Data:</b></i> While <I>npm uninstall</I> removes the package, it doesn't clean npm's cache. Use <I>npm cache clean --force</I> to clear it.<br><i><b>Dependency Resolution:</b></i> <I>npm uninstall</I> primarily removes the specified package. It doesn't automatically remove its own dependencies unless they are no longer required by any other package in the tree (though <I>npm prune</I> can help with extraneous packages).


title: ALIASES
content:
The <I>npm uninstall</I> command can also be invoked using its shorter aliases: <B>npm un</B> and <B>npm rm</B>.


title: LOCAL VS. GLOBAL
content:
By default, <I>npm uninstall</I> operates on packages installed locally within the current project's <I>node_modules</I> directory. To remove a package installed globally, you must use the <B>-g</B> or <B>--global</B> flag.


title: HISTORY
content:
The <I>npm uninstall</I> command has been a core part of the <I>npm</I> CLI since its early versions, evolving alongside the <I>Node.js</I> ecosystem. Initially, managing <I>package.json</I> dependencies required explicit <I>--save</I> flags. However, with <I>npm@5</I> and later, the default behavior for <I>npm install</I> became to automatically save to <I>dependencies</I>, and similarly, <I>npm uninstall</I> now defaults to removing entries from <I>package.json</I> and updating <I>package-lock.json</I>. This automation streamlined dependency management, making it more intuitive and reducing boilerplate. The introduction of <I>package-lock.json</I> further enhanced determinism in installations and uninstalls, ensuring consistent dependency trees across environments. Its functionality has remained steadfast, focusing on reliable package removal.


title: PARAMETERS
content:
<b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required to unpublish a package or version. This flag acknowledges the destructive and irreversible nature of the operation.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows what would happen without actually performing the unpublish operation. Useful for testing.<br><br><b>--registry <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the registry to unpublish from. Defaults to the configured registry.<br><br><b>--loglevel <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the level of logging output. 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>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs data in JSON format, useful for programmatic consumption.<br><br><b>--otp <otpcode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required for unpublish operations if two-factor authentication (2FA) is enabled for the account.<br><br>


title: DESCRIPTION
content:
The <i>npm unpublish</i> command removes a package or a specific version of a package from the registry. This action is typically permanent and irreversible on public registries like <i>npmjs.com</i>, with strict policies regarding package immutability. Unpublishing a package makes it unavailable for new installations or updates.<br><br>It's often used when a package was published in error, contains sensitive information, or is no longer maintained and needs to be completely withdrawn. Due to the destructive nature and potential for breaking existing projects, npm strongly discourages unpublishing, especially for packages with dependent users. For most packages on <i>npmjs.com</i>, unpublishing is only allowed within 72 hours of publication. After this period, only deprecation or removal of specific versions is generally possible via the <i>npm deprecate</i> command. The use of the <i>--force</i> flag is required for unpublishing, signifying the irreversible nature of the action.


title: CAVEATS
content:
Unpublishing a package, especially from <i>npmjs.com</i>, has significant limitations and implications:<br><br><b>Irreversibility:</b> On public registries, once a package or version is unpublished, it is generally permanent and cannot be re-published with the same name or version.<br><br><b>72-Hour Window:</b> For packages published on <i>npmjs.com</i>, unpublishing is usually only permitted within 72 hours of its initial publication. After this period, unpublishing is restricted, though specific versions might be removed under exceptional circumstances by contacting npm support.<br><br><b>Breaking Dependencies:</b> Unpublishing a package can break existing projects that rely on it, leading to build failures or runtime errors for users who attempt to install or update dependencies.<br><br><b>Discouraged Practice:</b> npm strongly discourages unpublishing. It recommends using <i>npm deprecate</i> instead to mark a package or version as deprecated, allowing users to migrate gracefully.<br><br><b>--force Requirement:</b> The <i>--force</i> flag is mandatory to execute the unpublish command, serving as an explicit acknowledgment of the operation's destructive nature.<br>


title: PACKAGE IMMUTABILITY ON NPMJS.COM
content:
For most packages on <i>npmjs.com</i>, published versions are considered immutable after 72 hours. This policy is in place to ensure the stability and reliability of the Node.js and JavaScript ecosystems. While <i>npm unpublish</i> exists, its practical use on the public registry is limited to very specific scenarios, primarily within the initial 72-hour window post-publication.


title: HISTORY
content:
The <i>npm unpublish</i> command has been a part of the npm CLI since its early versions, providing a mechanism to remove mistakenly published packages. However, its usage and the policies surrounding unpublishing have evolved significantly, particularly concerning the <i>npmjs.com</i> public registry. Initially, unpublishing was more lenient, but due to the potential for widespread breakage in the JavaScript ecosystem, npm introduced stricter policies around 2016, including the 72-hour window and the general discouragement of unpublishing in favor of deprecation. These changes aimed to ensure the stability and reliability of the npm ecosystem by making package versions effectively immutable after a short grace period. The requirement of the <i>--force</i> flag further emphasizes the deliberate and irreversible nature of the command.


title: PARAMETERS
content:
<b><i>package-name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The required name of the npm package from which to remove a star.<br><br><b><b>--registry=&lt;url&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the npm registry to use for this operation, overriding the default registry.<br><br><b><b>--loglevel=&lt;level&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity of npm logging output. Common levels include <i>silent</i>, <i>error</i>, <i>warn</i>, <i>http</i>, <i>info</i>, <i>verbose</i>, and <i>silly</i>.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format. This option can be useful for programmatic consumption of command output.<br><br><b><b>--otp=&lt;number&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Required for two-factor authentication (2FA) when performing operations on the npm registry that necessitate it.<br><br>


title: DESCRIPTION
content:
<i>npm unstar</i> is a command-line utility within the npm (Node Package Manager) ecosystem. Its primary function is to remove a "star" from an npm package that the current user had previously marked with <i>npm star</i>. Staring a package on the npm registry serves a similar purpose to liking or favoriting items on other online platforms. It allows users to bookmark packages of interest for easier retrieval later (e.g., using <i>npm star ls</i> or <i>npm stars</i>), and also acts as a public endorsement, contributing to the package's visibility and perceived popularity within the npm community.<br><br>When executed, <i>npm unstar</i> requires the name of the package as an argument. It then communicates with the npm registry to update the user's profile, removing the specified package from their list of starred items and decrementing the global star count for that package. This operation requires the user to be logged into their npm account. If not authenticated, the command will either prompt for credentials or fail. It effectively reverses the action of <i>npm star</i>, providing a simple way to manage your personal collection of favored packages or to retract a previous endorsement.


title: CAVEATS
content:
<b>Authentication Required:</b> You must be logged into an npm account (via <i>npm login</i>) to unstar a package.<br><br><b>Network Connectivity:</b> An active internet connection is necessary to communicate with the npm registry.<br><br><b>Package Existence:</b> The specified package must exist on the npm registry for the operation to succeed.<br><br><b>No Local Effect:</b> Unstarring a package only affects your registry profile; it does not modify your local <i>node_modules</i> directory or <i>package.json</i> file.


title: AUTHENTICATION REQUIREMENT
content:
Successful execution of <i>npm unstar</i> relies on proper authentication with the npm registry. If you are not currently logged in, npm will prompt you to authenticate (e.g., by running <i>npm login</i>) or the command will fail with an authentication error.


title: REGISTRY INTERACTION
content:
This command performs an operation directly on the npm registry. It does not modify any files within your local project directory, such as your <i>package.json</i>, nor does it affect your <i>node_modules</i> folder. Its scope is purely related to your user profile on the npm registry.


title: VISIBILITY OF STARS
content:
The total number of stars a package has accumulated is publicly displayed on its page on npmjs.com and can also be queried via the <i>npm view &lt;package-name&gt; stars</i> command. Unstarring a package will decrement this public count.


title: HISTORY
content:
The concept of "starring" packages, along with its counterpart "unstarring," has been a fundamental social feature of the npm registry since its early days. Introduced to provide a straightforward mechanism for users to bookmark packages of interest and express community support, <i>npm star</i> and <i>npm unstar</i> have evolved primarily as integral parts of the npm CLI itself. They represent foundational interactions within the npm ecosystem, allowing users to manage their personal package preferences directly via the command line.


title: PARAMETERS
content:
<b>--global, -g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates global packages installed on your system.<br><br><b><pkg>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more packages to update; if omitted, all dependencies are updated.<br><br><b>--save, -S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Deprecated) Historically used to save updated versions to <i>dependencies</i> in <b>package.json</b>.<br><br><b>--save-dev, -D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Deprecated) Historically used to save updated versions to <i>devDependencies</i> in <b>package.json</b>.<br><br><b>--save-exact, -E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the exact version of the updated package to <b>package.json</b>, without a version range (e.g., <i>1.2.3</i> instead of <i>^1.2.3</i>).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the update process without making any actual changes.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the update results in JSON format.<br><br><b>--audit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a security audit after the update completes (default behavior since npm 6).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses certain checks and forces fetching remote resources or installing, ignoring peer dependency conflicts.<br><br><b>--workspace <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates dependencies within a specific workspace in a monorepo.<br><br><b>--workspaces</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates dependencies within all configured workspaces in a monorepo.<br><br><b>--legacy-peer-deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores <i>peerDependencies</i> conflicts, allowing installation to proceed.<br><br><b>--no-audit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents a security audit from being performed after the update.<br><br>


title: DESCRIPTION
content:
<b>npm update</b> updates all packages listed in the <b>package.json</b> file to their latest <i>compatible</i> versions, according to the semantic versioning ranges specified. It can also update specific packages if provided as arguments. When executed without arguments, it scans the <b>node_modules</b> directory and <b>package.json</b> for all dependencies (including <i>dependencies</i>, <i>devDependencies</i>, <i>optionalDependencies</i>, and <i>peerDependencies</i>). It then attempts to download and install newer versions of these packages that satisfy the declared version ranges. This command also updates the <b>package-lock.json</b> file to reflect the new resolved dependency tree, ensuring reproducible builds. For global packages, <b>npm update -g</b> updates packages installed in the global <b>node_modules</b> directory. It's crucial for keeping project dependencies secure and up-to-date while respecting declared version constraints.


title: CAVEATS
content:
<b>npm update</b> only updates packages within the version ranges specified in <b>package.json</b>. If you want to update to a <i>major</i> new version (which often introduces breaking changes), you might need to manually edit <b>package.json</b> or use tools like <b>npm install &lt;package-name&gt;@latest</b>. It is recommended to run <b>npm outdated</b> first to see which packages are out of date and by how much. Always test your application thoroughly after running <b>npm update</b>, especially for large dependency trees, as even minor version updates can sometimes introduce subtle regressions or unexpected behavior due to complex dependency interactions.


title: SEMANTIC VERSIONING (SEMVER) AND NPM UPDATE
content:
<b>npm update</b> strictly adheres to semantic versioning rules defined in <b>package.json</b> (e.g., <i>^1.2.3</i>, <i>~1.2.3</i>). A <i>^</i> (caret) allows updates to non-breaking new versions (patches and minor releases, e.g., <i>1.x.x</i>). A <i>~</i> (tilde) allows only patch releases (e.g., <i>1.2.x</i>). This design choice aims to prevent accidental breaking changes to your project. To update to a new major version, you typically need to manually adjust the version in <b>package.json</b> or use <b>npm install &lt;package-name&gt;@latest</b>.


title: INTERACTION WITH PACKAGE-LOCK.JSON
content:
When <b>npm update</b> runs, it not only modifies the <b>node_modules</b> directory but also updates the <b>package-lock.json</b> file. This lock file records the exact version of every package in the dependency tree, ensuring that subsequent installations (e.g., <b>npm ci</b> or <b>npm install</b> on another machine) will use the identical set of dependencies, guaranteeing reproducibility across different environments. It's crucial to commit <b>package-lock.json</b> to version control.


title: HISTORY
content:
The <b>npm update</b> command has been a fundamental part of the npm CLI since its early days, evolving alongside npm itself. Its core functionality of updating dependencies within specified semantic versioning ranges has remained consistent. Significant changes primarily revolved around how npm handles <b>package-lock.json</b> (introduced in npm 5), peer dependencies (changes in npm 7), and the default behavior of running security audits (enabled by default in npm 6). Its continued development reflects npm's commitment to providing a robust and reliable package management experience for Node.js developers.


title: SYNOPSIS
content:
<b>npm version</b> [<i>&lt;newversion&gt;</i> | <i>major</i> | <i>minor</i> | <i>patch</i> | <i>premajor</i> | <i>preminor</i> | <i>prepatch</i> | <i>prerelease</i> | <i>from-git</i>] [<i>options</i>]


title: PARAMETERS
content:
<b><i>&lt;newversion&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A specific version string to set (e.g., <i>1.2.3</i>).<br><br><b><i>major</i> | <i>minor</i> | <i>patch</i> | <i>premajor</i> | <i>preminor</i> | <i>prepatch</i> | <i>prerelease</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increments the package version according to semantic versioning rules.<br><br><b><i>from-git</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the new version from the latest Git tag.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the version bump, even if the Git working directory is not clean or the version already exists.<br><br><b><b>--allow-same-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the command to succeed even if the new version is identical to the current one.<br><br><b><b>--no-git-tag-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>npm version</b> from creating a Git commit and tag.<br><br><b><b>--no-commit-hooks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses Git commit hooks (e.g., <i>pre-commit</i>) when creating the version commit.<br><br><b><b>--no-push</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the newly created commit and tag from being pushed to the remote Git repository.<br><br><b><b>--tag-version-prefix</b> <i>&lt;prefix&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a prefix for the Git tag (default is <i>v</i>, so tags are like <i>v1.0.0</i>).<br><br><b><b>--preid</b> <i>&lt;preid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identifier for a pre-release version (e.g., <i>alpha</i>, <i>beta</i>, <i>rc</i>) when using pre-release increments.<br><br><b><b>--message</b> <i>&lt;message&gt;</i>, <b>-m</b> <i>&lt;message&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Custom commit message for the version commit. The default is <i>v%s</i> where <i>%s</i> is the new version.<br><br>


title: DESCRIPTION
content:
The <b>npm version</b> command is a powerful utility for managing the version of a Node.js package, as defined in its <i>package.json</i> file. It allows developers to increment the package's version according to semantic versioning rules (major, minor, patch, pre-release) or set a specific version string. <br><br>Beyond simply updating the <i>package.json</i>, <b>npm version</b> deeply integrates with Git. By default, it performs a sequence of actions: it updates the version in <i>package.json</i>, creates a Git commit for this change, and then creates a Git tag with the format <i>v<version></i> (e.g., <i>v1.0.0</i>). Optionally, it can also push these changes, including the new commit and tag, to the remote Git repository. <br><br>This automated workflow streamlines the release process, ensuring consistency between the package's declared version and its corresponding Git tag, which is crucial for reproducible builds and clear release history. It also supports custom commit messages and allows for hooks to run scripts at different stages of the versioning process.


title: CAVEATS
content:
The command requires a Git repository to be initialized and accessible for its default Git integration features. It modifies <i>package.json</i> and <i>package-lock.json</i> directly. For best practice, ensure your working directory is clean (no uncommitted changes) before running <b>npm version</b>, unless explicitly using <b>--force</b>.


title: GIT INTEGRATION
content:
By default, <b>npm version</b> performs a Git commit and creates a Git tag. This behavior ensures that your package's version in <i>package.json</i> is always aligned with a corresponding Git tag, facilitating release management. Options like <b>--no-git-tag-version</b>, <b>--no-commit-hooks</b>, and <b>--no-push</b> provide fine-grained control over this integration.


title: LIFECYCLE SCRIPTS
content:
<b>npm version</b> executes specific lifecycle scripts defined in <i>package.json</i> around the versioning process:<br><i>preversion</i>: Runs before the version is bumped.<br><i>version</i>: Runs after the version is bumped, but before the commit.<br><i>postversion</i>: Runs after the commit and tag are created.<br>These scripts are useful for automating tasks like building assets, running tests, or performing cleanup operations during a release.


title: HISTORY
content:
The <b>npm version</b> command has been a core part of the npm CLI since its early days, evolving to support modern semantic versioning practices and tighter integration with Git workflows. Its functionality has remained consistently focused on automating release versioning and Git tagging.


title: SYNOPSIS
content:
<b><I>npm view</I></b> <I>&lt;package-spec&gt;</I> [<I>&lt;field&gt;...</I>] [<I>--json</I>] [<I>--registry &lt;url&gt;</I>] [<I>--otp &lt;code&gt;</I>]


title: PARAMETERS
content:
<b><I>&lt;package-spec&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the package to query. Can include a version or tag, e.g., <b><I>react</I></b> or <b><I>lodash@4.17.21</I></b>.<br><br><b><I>&lt;field&gt;...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more specific fields to display from the package metadata. This can be a top-level field like <b><I>version</I></b>, <b><I>dependencies</I></b>, <b><I>license</I></b>, or a nested field like <b><I>repository.url</I></b>. Special fields like <b><I>versions</I></b> (to list all versions) or <b><I>dist-tags</I></b> are also supported.<br><br><b><b><I>--json</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the package metadata in JSON format. This is useful for programmatic parsing of the information.<br><br><b><b><I>--registry &lt;url&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom npm registry URL to fetch package information from, overriding the default configured registry.<br><br><b><b><I>--otp &lt;code&gt;</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a one-time password for authenticated requests, typically when accessing private packages or performing operations that require user verification.<br><br><b><b><I>--color</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control color output in the terminal. Set to <b><I>false</I></b> to disable color (e.g., <b><I>--no-color</I></b>).<br><br>


title: DESCRIPTION
content:
The <b><I>npm view</I></b> command (also aliased as <b><I>npm info</I></b>) fetches and displays detailed metadata about a specified package from the npm registry.<br><br>It's commonly used by developers to quickly access information such as available versions, dependencies, license, author, and other descriptive fields for a package without installing it. You can query for the latest version's information, a specific version, or even a particular field within a package's metadata. This command is invaluable for understanding package details, debugging dependency issues, or simply exploring the npm ecosystem.


title: CAVEATS
content:
<b><I>npm view</I></b> relies on network access to the npm registry. Without connectivity, it cannot retrieve package information. For private packages, appropriate authentication (like login credentials or OTP) may be required. The specific fields available can vary between packages.


title: COMMON USAGE PATTERNS
content:
<ul><li><b><I>npm view <package-name></I></b>: Displays general information about the latest version of a package.</li><li><b><I>npm view <package-name> versions</I></b>: Lists all published versions of a package.</li><li><b><I>npm view <package-name> homepage</I></b>: Shows the homepage URL specified in the package.json.</li><li><b><I>npm view <package-name> repository.url</I></b>: Retrieves the repository URL.</li><li><b><I>npm view <package-name> --json</I></b>: Gets all available metadata for a package in JSON format.</li></ul>


title: DATA SOURCE
content:
Information is fetched directly from the npm registry (or a configured private registry), not from your local <b><I>node_modules</I></b> directory. This ensures you're always viewing the most up-to-date published information.


title: HISTORY
content:
The <b><I>npm view</I></b> command has been a fundamental part of the npm CLI since its early versions, providing a core utility for inspecting package details. It is an alias to <b><I>npm info</I></b>, which also performs the same function. Its consistent presence highlights its importance in the npm ecosystem for both developers and automated tooling to gather package metadata.


title: PARAMETERS
content:
<b><i>--registry &lt;registry URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the npm registry to use for this command. Useful if you're interacting with a private registry different from your default.<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the result in JSON format. When this option is used, the username is returned as a JSON object, e.g., <b>{"username": "your-username"}</b>.<br><br>


title: DESCRIPTION
content:
<b>npm-whoami</b>, often invoked simply as <b>npm whoami</b>, is a fundamental command within the Node.js package manager (npm) ecosystem. Its primary purpose is to display the username associated with the currently logged-in npm user on the active npm registry. This command is invaluable for verifying your authentication status, particularly when working with private npm registries, scoped packages, or when troubleshooting publishing and installation issues.<br><br>It retrieves the username from the npm configuration, which typically stores authentication tokens. The output is a simple string containing the username, making it easy to parse or use in scripts. Unlike the system's <b>whoami</b> command, which shows the operating system username, <b>npm whoami</b> specifically interacts with your npm credentials. It's a quick and reliable way to confirm which account npm is operating under at any given moment.


title: CAVEATS
content:
If no user is logged in for the current registry, <b>npm whoami</b> will typically output nothing or an empty string, or it might result in an error message indicating no user is logged in. It does not explicitly state "not logged in."<br><br>The command relies on credentials stored in your <i>.npmrc</i> configuration file. If these credentials are invalid or missing, the command will not return a valid username.<br><br>It only displays the username and does not provide information about the associated email or other profile details. For more profile details, use <b>npm profile get</b>.


title: OUTPUT FORMAT
content:
By default, <b>npm whoami</b> outputs only the username as plain text to standard output, followed by a newline. This simplicity makes it ideal for use in shell scripts.


title: CONFIGURATION SOURCE
content:
The command retrieves the username by checking the authentication token (e.g., <i>_authToken</i>) stored in your <i>.npmrc</i> file, which can be located in your user's home directory or project-specific directories.


title: REGISTRY CONTEXT
content:
The username displayed is specific to the active npm registry. If you switch registries (e.g., using <i>--registry</i>), the <b>whoami</b> command will attempt to retrieve the username for that particular registry.


title: HISTORY
content:
The <b>npm whoami</b> command has been a core part of the Node.js package manager (npm) command-line interface since its early development. It leverages a common Unix-like pattern of having a <b>whoami</b> command to identify the current user context, adapted specifically for the npm ecosystem. Its function has remained largely consistent, serving as a straightforward utility to confirm the authenticated npm user, an essential aspect for package publishing and private package access.


title: PARAMETERS
content:
<b><I>&lt;package-name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the npm package whose dependency path you wish to investigate. This can be any package found within your project's <I>node_modules</I> directory.<br><br>


title: DESCRIPTION
content:
The <B>npm-why</B> command is a specialized utility designed to help developers understand the dependency chain that leads to a specific package being present in their project's <I>node_modules</I> directory. Unlike the more general <B>npm list</B> command, which can provide an overwhelming tree of all dependencies, <B>npm-why</B> focuses on a single package, tracing its lineage back to the root of the project. It identifies whether the package is a direct dependency declared in <I>package.json</I> or a transitive dependency brought in by another package. This command is invaluable for debugging dependency conflicts, optimizing bundle sizes by identifying unwanted transitive dependencies, or simply gaining a clearer understanding of a complex project's dependency graph. It helps answer the fundamental question: <I>"Why is this package here?"</I> by showing the path from your top-level dependencies down to the queried package.


title: CAVEATS
content:
The <B>npm-why</B> command is <B>not</B> an official built-in npm command; it is a third-party utility that must be installed separately (e.g., via <I>npm install -g @linclark/npm-why</I>). It relies on the presence of a populated <I>node_modules</I> directory, meaning <I>npm install</I> must have been run previously. The output can be verbose for deeply nested dependencies, although it's always focused on the specified package's path. It might not fully account for complex dependency resolution strategies or package aliasing if not implemented within its logic.


title: INSTALLATION
content:
Since <B>npm-why</B> is a third-party tool, it needs to be installed globally or locally within your project. The most common way to install it is globally using npm:<br><br><B>npm install -g @linclark/npm-why</B><br><br>This makes the <B>npm-why</B> command available directly from your terminal in any project directory.


title: OUTPUT STRUCTURE
content:
The output of <B>npm-why</B> typically displays a tree-like structure, showing the direct and transitive dependencies that lead to the specified package. It clearly indicates the parent-child relationships, helping to visualize the exact path through the dependency graph. For example, if <I>package-A</I> depends on <I>package-B</I>, and <I>package-B</I> depends on <I>package-C</I>, querying for <I>package-C</I> would show the path: <I>root -> package-A -> package-B -> package-C</I>. This visual clarity is one of its primary strengths.


title: HISTORY
content:
The <B>npm-why</B> utility was created by Lin Clark, a well-known figure in the web development community. Its development was driven by the common developer frustration with deciphering large and complex dependency trees generated by tools like <B>npm list</B>. It aimed to provide a more targeted and intuitive way to understand specific package origins, quickly gaining traction for its simplicity and effectiveness in addressing a frequent pain point in npm-based workflows. It fills a crucial gap for dependency introspection.


title: PARAMETERS
content:
<b>-all, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the number of installed (configured) processors. This might include CPUs that are offline or reserved, differing from the default 'online' count.<br><br><b>-ignore=N, --ignore=N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Subtract N from the number of processors reported. Useful for reserving cores for other tasks or for systems with known performance bottlenecks.<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:
The <b><I>nproc</I></b> command in Linux is a utility designed to print the number of processing units available to the current process or system. It serves as a straightforward way to query system hardware capabilities, particularly useful in scripting and automation where the number of available CPU cores dictates optimal parallelism. <br><br>By default, <b><I>nproc</I></b> reports the number of "online" processors, which are those currently active and available for use by the operating system. This is typically what applications and build systems need for dynamic resource allocation. For instance, a common use case is with the <b><I>make</I></b> command, where `make -j$(nproc)` automatically sets the number of parallel jobs to the available processor count, significantly speeding up compilation times. <br><br>The command derives its information from kernel interfaces, such as `sysconf(_SC_NPROCESSORS_ONLN)` or `sysconf(_SC_NPROCESSORS_CONF)`, rather than parsing files like `/proc/cpuinfo` directly, which makes it more robust and portable across different Linux distributions and kernel versions. This abstraction simplifies resource discovery for developers and system administrators, allowing them to write more adaptable scripts and programs that can optimize their performance based on the underlying hardware. <br><br>While <b><I>nproc</I></b> primarily focuses on logical processors (including hyper-threading cores), it offers an option to report the total number of installed processors, which might include those currently offline or reserved. It's an indispensable tool for efficient resource management in parallel computing environments.


title: CAVEATS
content:
<b><I>nproc</I></b> typically reports the number of <i>logical</i> processors, which includes hyper-threading cores. For instance, a 4-core CPU with hyper-threading enabled will often report 8 processors. <br><br>In containerized environments (e.g., Docker, Kubernetes) or virtual machines, the reported number of processors reflects the CPU resources allocated to the container/VM, which may be less than the host's physical cores. <br><br>Using the `--ignore=N` option with a large value of N can result in a non-positive (zero or negative) number of processors being reported, which might cause issues for scripts expecting a positive count.


title: DEFAULT BEHAVIOR
content:
By default, <b><I>nproc</I></b> outputs the number of <i>online</i> (available) processors, which are those currently active and available to the operating system and typically what applications use for parallel execution.


title: LOGICAL VS. PHYSICAL PROCESSORS
content:
The output of <b><I>nproc</I></b> typically represents <i>logical</i> processors (CPU threads). For example, a CPU with 4 physical cores and 2 threads per core (like Intel Hyper-Threading) would usually report 8 logical processors. Use `lscpu` for more detailed physical CPU topology.


title: COMMON USE IN SCRIPTING
content:
<b><I>nproc</I></b> is most famously used in `Makefile`s (e.g., `make -j$(nproc)`), where it dynamically configures the number of parallel compilation jobs to match the system's available CPU resources, significantly improving build times and system utilization.


title: HISTORY
content:
The <b><I>nproc</I></b> command is part of the GNU Core Utilities (coreutils) package, a fundamental collection of tools for GNU/Linux operating systems. It was introduced to provide a standardized and portable way to determine the number of available processors. Prior to its widespread adoption, developers often had to resort to parsing `/proc/cpuinfo` directly or using less specific commands like `getconf NPROCESSORS_ONLN`, which could be more prone to parsing errors or less intuitive for general use. <b><I>nproc</I></b> offers a simpler, dedicated interface, streamlining resource discovery in shell scripts and build systems, reflecting the ongoing evolution of Linux utilities towards greater user-friendliness and robustness.


title: SYNOPSIS
content:
<b>npx</b> [options] &lt;command&gt; [arguments...]<br>
<b>npx</b> [options] -p|--package &lt;package&gt; &lt;command&gt; [arguments...]<br>
<b>npx</b> [options] -- &lt;command&gt; [arguments...] (to run a command with the same name as an npx option)


title: PARAMETERS
content:
<b><b>--package</b> &lt;package&gt; / <b>-p</b> &lt;package&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a package to install before executing the command. This is useful when the command name differs from the package name, or when you want to execute a specific version.<br><br><b><b>--yes</b> / <b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically confirm all prompts, assuming "yes" for any questions.<br><br><b><b>--no-install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>npx</i> from installing the package if it's not found locally. If the package isn't present, the command will fail.<br><br><b><b>--ignore-existing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>npx</i> to fetch and use the latest version of the package from the registry, even if a local version is already installed.<br><br><b><b>--npm</b> &lt;npm-client&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which <i>npm</i> client (e.g., <i>npm</i>, <i>yarn</i>, <i>pnpm</i>) to use for installing packages.<br><br><b><b>--node-arg</b> &lt;arg&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes an argument directly to the Node.js executable that <i>npx</i> uses to run the script.<br><br><b><b>--call</b> &lt;command-string&gt; / <b>-c</b> &lt;command-string&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the provided string as a shell command. This is useful for complex commands or piped commands.<br><br><b><b>--shell</b> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the shell to use for executing the command. By default, <i>npx</i> uses your default shell.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>npx</i> version number.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help information for <i>npx</i>.<br><br>


title: DESCRIPTION
content:
<i>npx</i> (Node Package eXecutor) is a command-line tool that comes bundled with <i>npm</i> (since version 5.2.0). It allows you to execute Node.js package binaries, typically command-line interface (CLI) tools, directly from the npm registry without needing to install them globally on your system or even locally in your project's <i>node_modules</i> directory. This is particularly useful for one-off commands, scaffolding new projects (like <i>npx create-react-app</i>), or trying out new tools without cluttering your global package space. <i>npx</i> intelligently checks if the package exists locally or in your cache; if not, it temporarily downloads it, executes the command, and then removes the temporary files. This ensures you're always using the latest version of a tool and helps maintain a clean development environment by avoiding global package pollution and version conflicts.


title: CAVEATS
content:
<i>npx</i> requires an active internet connection to download packages if they are not already cached or locally installed.<br>While <i>npx</i> handles temporary installations, large packages can still take time to download, impacting execution speed for first-time runs.<br>Be cautious when executing arbitrary commands from the internet using <i>npx</i>, as they run with your user's permissions and could potentially be malicious. Always ensure you trust the source package.


title: TEMPORARY EXECUTION
content:
<i>npx</i> prioritizes running locally installed executables. If not found, it temporarily downloads the package to a cache, runs the command, and then cleans up the temporary files, ensuring a clean system.


title: SCAFFOLDING TOOLS
content:
<i>npx</i> is commonly used for scaffolding new projects with tools like <i>create-react-app</i>, <i>vue-cli</i>, or <i>next</i> which are designed for one-time use during project initialization.


title: HISTORY
content:
<i>npx</i> was introduced with <i>npm</i> version 5.2.0 in July 2017. Before its introduction, developers often had to either globally install CLI tools (leading to version conflicts and system clutter) or add them as local <i>devDependencies</i> and then use <i>npm run</i> scripts to execute them. <i>npx</i> aimed to solve these problems by providing a straightforward way to execute Node.js binaries directly, enhancing developer workflow and improving dependency management practices by promoting local, temporary execution over global installations.


title: SYNOPSIS
content:
<b>nrm</b> <i>&lt;command&gt;</i> [<i>&lt;options&gt;</i>]<br><b>nrm</b> <i>&lt;command&gt;</i> [<i>&lt;arguments&gt;</i>]


title: PARAMETERS
content:
<b><b>ls</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available npm registries, highlighting the currently active one.<br><br><b><b>use</b> <i>&lt;registry_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the current npm registry to the specified <i>&lt;registry_name&gt;</i>.<br><br><b><b>add</b> <i>&lt;name&gt; &lt;url&gt;</i> [<i>&lt;home_url&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new custom npm registry with the given <i>&lt;name&gt;</i> and <i>&lt;url&gt;</i>. An optional <i>&lt;home_url&gt;</i> can be provided.<br><br><b><b>del</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a custom npm registry specified by <i>&lt;name&gt;</i>.<br><br><b><b>test</b> [<i>&lt;registry_name&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests the response time of all available registries or a specific <i>&lt;registry_name&gt;</i> if provided.<br><br><b><b>current</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the name of the currently active npm registry.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed version of <b>nrm</b>.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>nrm</b> or a specific subcommand.<br><br>


title: DESCRIPTION
content:
The <b>nrm</b> (npm registry manager) command-line utility is a powerful tool for Node.js developers, designed to simplify the process of switching between different npm registries. In environments where access to the default npm registry (registry.npmjs.org) might be slow, restricted, or when working with private or mirror registries, <b>nrm</b> provides an efficient solution.<br><br>Instead of manually editing <i>.npmrc</i> configuration files, <b>nrm</b> allows users to list available registries, quickly switch to a preferred one, add custom registries, and even test their response times. It comes pre-configured with several common registries like npm, cnpm, taobao, and others, offering out-of-the-box flexibility. This makes it particularly useful for developers in regions with unreliable network access to the global npm registry or for those needing to integrate with internal corporate registries.<br><br><b>nrm</b> is not a core Linux command but a Node.js package, installed globally via <i>npm</i>. It alters the global <i>npm</i> configuration, ensuring that subsequent <i>npm install</i> or <i>npm publish</i> commands interact with the currently selected registry.


title: CAVEATS
content:
<b>nrm</b> is a Node.js package and requires Node.js and <i>npm</i> to be installed on your system. It is typically installed globally using <i>npm install -g nrm</i>.<br><br>Changes made by <b>nrm</b> affect the global npm configuration (<i>~/.npmrc</i> or equivalent), meaning all subsequent <i>npm</i> commands will use the selected registry. Exercise caution when adding or using untrusted registries, as this could have security implications for your package installations.


title: INSTALLATION
content:
To install <b>nrm</b>, ensure Node.js and <i>npm</i> are installed, then run: <i>npm install -g nrm</i>


title: CONFIGURATION
content:
<b>nrm</b> stores its configuration, including custom registries, in a file typically located at <i>~/.nrmrc</i> on Unix-like systems. This file is automatically managed by <b>nrm</b> commands.


title: HISTORY
content:
<b>nrm</b> was created by Pana Wang (Pana) to address the common pain point of managing multiple npm registries. It emerged as a pragmatic solution for developers, especially those facing network latency to the official npm registry or working within corporate environments requiring specific internal registries. Its open-source nature and straightforward functionality have contributed to its widespread adoption within the Node.js community as a de facto standard for registry switching.


title: PARAMETERS
content:
<b><b>-T</b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output device or terminal type (e.g., <i>lp</i>, <i>300</i>, <i>latin1</i>, <i>utf8</i>). This option largely dictates how the output is rendered.<br><br><b><b>-o</b><i>list</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only the specified pages from the document. <i>list</i> can be a comma-separated range (e.g., <i>1,3-5,7</i>).<br><br><b><b>-s</b><i>n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops processing and prompts for continuation every <i>n</i> pages, useful for printing on physical printers.<br><br><b><b>-r</b><i>aN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the numeric register <i>a</i> to the value <i>N</i>. Registers are internal variables used for formatting control.<br><br><b><b>-u</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the emboldening factor to <i>N</i>, controlling the number of times characters are overstruck to simulate bold text.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads standard input after processing all specified input files, allowing for piped input.<br><br><b><b>-z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output, primarily useful for checking syntax errors in the input files without displaying the formatted result.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses tab characters instead of multiple spaces in the output where possible, which can save bandwidth and improve rendering on some terminals.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces equally-spaced words in the output, striving for a more justified appearance.<br><br><b><b>-m</b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prepends the macro file `/usr/lib/tmac/tmac.<i>name</i>` (or similar path) to the input files, loading specific macro packages like <i>man</i>, <i>ms</i>, or <i>mm</i>.<br><br>


title: DESCRIPTION
content:
<b>nroff</b> (New ROFF) is a venerable and powerful text formatting program, historically a cornerstone of the Unix operating system for producing readable documents on character-oriented display devices such as terminals and line printers. It processes input files containing plain text interspersed with special formatting requests and macro calls. These instructions control various aspects of document layout, including font styles (though often rendered as overstriking or bold on terminals), spacing, pagination, and structural elements. Unlike its sibling, <b>troff</b>, which targets high-resolution typesetters, <b>nroff</b> is optimized for plain text output, making it the primary engine behind the display of manual pages (man pages) on virtually all Unix-like systems. It supports various macro packages like <i>-man</i>, <i>-ms</i>, and <i>-mm</i> to simplify complex document creation.


title: CAVEATS
content:
In modern Linux distributions, the functionality of <b>nroff</b> is largely provided by the <b>groff</b> (GNU <b>roff</b>) project. When you invoke <b>nroff</b>, it typically executes <b>groff</b> with options configured for terminal output. Consequently, direct usage of <i>nroff</i> is less common for new document creation, but it remains critical for viewing existing formatted documents like manual pages. Its capabilities are limited to character-based rendering, meaning it cannot produce complex graphics, true scalable fonts, or advanced typographical effects common in graphical word processors.


title: <B>MACRO PACKAGES</B>
content:
<b>nroff</b>'s power lies in its extensive support for macro packages (e.g., <i>man</i>, <i>ms</i>, <i>mm</i>). These packages are collections of predefined formatting requests that abstract away low-level commands, allowing users to focus on document structure and content rather than intricate typesetting details. For instance, the <i>man</i> macros are specifically designed for formatting manual pages.


title: <B>UNIX PHILOSOPHY AND PIPELINING</B>
content:
True to the Unix philosophy, <b>nroff</b> is often used as part of a toolchain. It can process output from specialized preprocessors like <b>tbl</b> (for tables), <b>eqn</b> (for equations), and <b>pic</b> (for diagrams), and its output can then be further refined by post-processors like <b>col</b> for optimal terminal display. This modular approach allows for flexible and powerful document processing.


title: HISTORY
content:
<b>nroff</b> emerged from Bell Labs in the early 1970s as a descendant of the original <i>roff</i> (Run Off) text formatting system. It was specifically developed to produce formatted output on line printers and character-oriented terminals, making it a pivotal tool for generating documentation, particularly the manual pages, for the nascent Unix operating system. Its development ran parallel to <b>troff</b>, which was designed for high-resolution phototypesetters. Although the original <b>nroff</b> implementation has been largely superseded by the open-source <b>groff</b> (GNU <b>roff</b>) project, <b>groff</b> meticulously maintains backward compatibility, ensuring that historical documents and the fundamental mechanism for displaying <i>man</i> pages continue to function seamlessly across Unix-like systems today.


title: PARAMETERS
content:
<b><b>-t</b>, <b>--target</b> <i>&lt;PID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target process ID whose namespaces will be entered. This is a mandatory option for most common use cases.<br><br><b><b>-m</b>, <b>--mount</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the mount namespace of the target process. Optionally, specify a path to a mount namespace file (e.g., <i>/proc/&lt;PID&gt;/ns/mnt</i>) instead of the target PID's default.<br><br><b><b>-u</b>, <b>--uts</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the UTS (hostname/domain name) namespace of the target process. Optionally, specify a path to a UTS namespace file.<br><br><b><b>-i</b>, <b>--ipc</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the IPC (Inter-Process Communication) namespace of the target process. Optionally, specify a path to an IPC namespace file.<br><br><b><b>-n</b>, <b>--network</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the network namespace of the target process. Crucial for debugging network configurations within isolated environments. Optionally, specify a path to a network namespace file.<br><br><b><b>-p</b>, <b>--pid</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the PID namespace of the target process. This means the newly executed command will have a PID within that namespace, potentially different from its host PID. Optionally, specify a path to a PID namespace file.<br><br><b><b>-C</b>, <b>--cgroup</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the Cgroup namespace of the target process. Optionally, specify a path to a Cgroup namespace file.<br><br><b><b>-U</b>, <b>--user</b>[=<i>&lt;file&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enter the user namespace of the target process. This changes the user ID and group ID mappings for the new process, which can make it appear as root (UID 0) inside the target namespace. Optionally, specify a path to a user namespace file.<br><br><b><b>-S</b>, <b>--setid</b> <i>&lt;uid&gt;</i> <i>&lt;gid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the user ID and group ID for the command executed inside the namespace. This is applied <i>after</i> entering the user namespace (if <b>-U</b> is used).<br><br><b><b>-r</b>, <b>--root</b>[=<i>&lt;directory&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the root directory for the command. Similar to <i>chroot</i>, but can be combined with namespace entry. If no directory is specified, it defaults to the target process's root.<br><br><b><b>-w</b>, <b>--wd</b>[=<i>&lt;directory&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the working directory for the command. If no directory is specified, it defaults to the target process's current working directory.<br><br><b><b>-F</b>, <b>--no-fork</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fork a new process before executing the command. This means <i>nsenter</i> itself will be replaced by the command, which can affect signal handling.<br><br><b><b>-Z</b>, <b>--follow-context</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the SELinux context for the command according to the target process's context.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br>


title: DESCRIPTION
content:
<i>nsenter</i> is a powerful utility from the <i>util-linux</i> package that allows an administrator to run a program within the context of specific namespaces of another running process. Linux namespaces provide isolation for various system resources, including Process IDs (PID), network interfaces, mount points, Inter-Process Communication (IPC), UTS (hostname/domain name), Cgroup, and user IDs.<br><br>This command is exceptionally valuable for debugging and managing containerized applications. It enables users to "step inside" a container's isolated environment without relying on the container runtime's specific `exec` commands (like `docker exec`). By targeting a process's PID, <i>nsenter</i> can attach to its pre-existing namespaces and then execute a command, effectively making the command operate as if it were running within that isolated environment. This provides a low-level, flexible, and powerful way to inspect, configure, and troubleshoot issues within isolated Linux environments from the host system.


title: CAVEATS
content:
<b>Privileges:</b> <i>nsenter</i> generally requires root privileges or the <i>CAP_SYS_ADMIN</i> capability to attach to other process's namespaces.<br><br><b>Target Process:</b> The target process (specified by PID) must be actively running for <i>nsenter</i> to successfully join its namespaces.<br><br><b>PID Namespace:</b> Entering a PID namespace (<i>-p</i>) does not automatically make your command PID 1 within that namespace. The command will receive a new PID within the target namespace, but its parent will still be the original <i>nsenter</i> process from the host's PID namespace.<br><br><b>User Namespace Complexity:</b> When entering a user namespace (<i>-U</i>), your user ID and group ID mappings will change according to that namespace's configuration. You might appear as root (UID 0) within the target namespace, even if you're a non-root user on the host.


title: CORE FUNCTIONALITY
content:
At its core, <i>nsenter</i> leverages the <i>setns(2)</i> system call, which allows a process to reassociate itself with a specified namespace. This is how it 'jumps' into the environment of another process.


title: COMMON USE CASES
content:
Beyond general system debugging, <i>nsenter</i> is heavily used in container troubleshooting. For instance, an administrator might use it to:<br><b>-</b> Inspect network configurations inside a container's network namespace.<br><b>-</b> Debug issues with mount points by entering a container's mount namespace.<br><b>-</b> Run a diagnostic command that isn't present in the container's image.


title: FINDING TARGET PID
content:
To use <i>nsenter</i>, you often need to find the PID of a process running within the target environment (e.g., a container). Tools like <i>docker inspect</i> (for Docker) or <i>ps aux</i> on the host combined with <i>grep</i> can help identify the main process PID of a container.


title: HISTORY
content:
<i>nsenter</i> is a relatively modern addition to the <i>util-linux</i> project, which provides a comprehensive suite of essential system utilities for Linux. Its emergence is closely tied to the increasing adoption and sophistication of Linux container technologies like Docker and Kubernetes. As namespaces became fundamental for process isolation in these environments, there was a growing need for a direct, low-level tool to inspect and interact with these isolated contexts. <i>nsenter</i> fills this gap, offering a powerful alternative to container-runtime-specific `exec` commands for advanced debugging and system administration tasks within isolated environments.


title: SYNOPSIS
content:
<b>seq</b> [<i>OPTION</i>]... <i>LAST</i><br><b>seq</b> [<i>OPTION</i>]... <i>FIRST LAST</i><br><b>seq</b> [<i>OPTION</i>]... <i>FIRST INCREMENT LAST</i>


title: PARAMETERS
content:
<b><i>LAST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The final number in the sequence. If only one number is provided, the sequence starts from 1.<br><br><b><i>FIRST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The starting number of the sequence. Default is 1 if omitted.<br><br><b><i>INCREMENT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The step value between consecutive numbers. Can be positive or negative. Default is 1 if omitted.<br><br><b><b>-f</b>, <b>--format</b>=<i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a <b>printf</b>-style <i>FORMAT</i> string for outputting each number. Useful for custom padding or prefixes.<br><br><b><b>-s</b>, <b>--separator</b>=<i>STRING</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <i>STRING</i> to separate numbers. The default separator is a newline character (\n).<br><br><b><b>-w</b>, <b>--equal-width</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pads numbers with leading zeros to ensure all numbers have the same width as the widest number in the sequence. Affects both <i>FIRST</i>, <i>INCREMENT</i>, and <i>LAST</i>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>seq</b> command (assumed to be the intended command, as 'nseq.1s' is not standard) is a command-line utility used to generate sequences of numbers. It prints each number on a separate line by default, but this behavior can be customized. Users can specify a single <i>LAST</i> number to generate a sequence from 1 up to <i>LAST</i>, or provide <i>FIRST</i> and <i>LAST</i> numbers for a specific range. For more control, an <i>INCREMENT</i> value can be included to define the step size between numbers, allowing for arithmetic sequences (increasing or decreasing). <br><br><b>seq</b> is highly versatile, supporting floating-point numbers for <i>FIRST</i>, <i>INCREMENT</i>, and <i>LAST</i>. It can also format the output using <b>printf</b>-style format strings, pad numbers with leading zeros to equalize width, and customize the separator between numbers. This utility is a staple in shell scripting for tasks requiring iteration, generating lists of numbers, creating test data, or automating repetitive operations.


title: CAVEATS
content:
The command 'nseq.1s' is not a standard, recognized Linux command or man page section. This analysis is based on the assumption that the user intended to inquire about the 'seq(1)' command, which is a common utility for generating number sequences. The suffix '.1s' is not a standard man page section indicator; standard sections typically consist of a single digit (e.g., '.1' for user commands, '.3' for library functions). If 'nseq' refers to a custom script or an obscure utility, its functionality would differ from this description.


title: HISTORY
content:
The <b>seq</b> command is a fundamental utility included in GNU Core Utilities, a standard suite of essential commands found in Unix-like operating systems, especially Linux distributions. Its development aimed to provide a straightforward and efficient way to generate numerical sequences, a common requirement in shell scripting and automated tasks. Prior to <b>seq</b>, generating such sequences often involved more complex shell arithmetic or loops. Its integration into core utilities underscores its importance and widespread adoption since the early days of modern Unix-like systems, ensuring consistent behavior across various environments.


title: SYNOPSIS
content:
<b>nslookup</b> [<i>options</i>] [<i>hostname</i> | <i>IP-address</i>] [<i>server</i>]<br><b>nslookup</b> [<i>options</i>] [<i>server</i>] (<i>interactive mode</i>)


title: PARAMETERS
content:
<b>-query=<type> or -type=<type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of resource record to query. Common types include <i>A</i> (IP address), <i>MX</i> (mail exchange), <i>NS</i> (name server), <i>PTR</i> (pointer for reverse lookups), <i>CNAME</i> (canonical name), and <i>ANY</i> (all available records).<br><br><b>-class=<class></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the query class. The default is <i>IN</i> (Internet).<br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns on debugging output, showing more details about the query and response.<br><br><b>-vc</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always use a virtual circuit (TCP) for queries, even for non-zone transfers. By default, UDP is used unless the response is truncated.<br><br><b>-port=<port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number of the DNS server to use. The default is 53.<br><br><b>-timeout=<seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial number of seconds to wait for a reply from the DNS server.<br><br><b>-retry=<count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of times to retry a query if no response is received.<br><br><b>-domain=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default domain name to append to unqualified hostnames.<br><br><b>-search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends the domain search list to the query if it contains at least one dot.<br><br><b>-fail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits if a DNS server returns an error (e.g., NXDOMAIN).<br><br><b>-d2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns on exhaustive debugging, providing even more verbose output than <i>-debug</i>.<br><br><b>-set <keyword>[=<value>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows setting various internal options for the lookup. Examples include <i>set all</i> to view current options, <i>set type=mx</i>, <i>set timeout=10</i>.<br><br>


title: DESCRIPTION
content:
<b>nslookup</b> is a command-line utility used for querying the Domain Name System (DNS) to obtain domain name or IP address mapping or other DNS records. It allows users to perform interactive queries or direct lookups for specific information.<br><br>While once widely used, it has largely been superseded by tools like <b>dig</b> and <b>host</b> for modern DNS troubleshooting and scripting due to its non-standard behavior and less predictable output. However, it remains available on most systems and can be useful for quick, basic DNS queries.<br><br>It can operate in two modes: non-interactive mode for a single query, and interactive mode for multiple queries, allowing users to specify different query types (e.g., A, MX, NS, PTR) and DNS servers. This makes it a foundational tool for network administrators and developers to diagnose DNS resolution issues and verify DNS configurations. Its primary function is to translate domain names to IP addresses (forward lookup) and IP addresses to domain names (reverse lookup).


title: CAVEATS
content:
<b>nslookup</b> is considered <i>deprecated</i> by the Internet Systems Consortium (ISC), the developers of BIND. While still widely available, it is not recommended for scripting due to its inconsistent output format and non-standard behavior. Newer tools like <i>dig</i> and <i>host</i> are preferred for robust DNS troubleshooting and automation tasks. Its behavior can sometimes vary subtly between different versions and operating systems.


title: INTERACTIVE VS. NON-INTERACTIVE MODE
content:
<b>nslookup</b> can be used in two modes. In <i>non-interactive</i> mode, you specify the hostname or IP address directly on the command line (e.g., <i>nslookup google.com</i>). In <i>interactive</i> mode, you launch <b>nslookup</b> without arguments or with a server argument (<i>nslookup server_ip</i>), and then enter queries at the <b>></b> prompt. Interactive mode allows setting various options (<i>set type=mx</i>, <i>set server=8.8.8.8</i>) before performing multiple lookups.


title: COMMON USE CASES
content:
<b>nslookup</b> is frequently used to:<br>- Resolve a domain name to an IP address (e.g., <i>nslookup example.com</i>).<br>- Perform a reverse DNS lookup (IP to domain) (e.g., <i>nslookup 192.0.2.1</i>).<br>- Query specific record types like MX records for email servers (e.g., <i>nslookup -type=mx example.com</i>).<br>- Test a specific DNS server's resolution (e.g., <i>nslookup example.com 8.8.8.8</i>).


title: HISTORY
content:
<b>nslookup</b> was historically included as part of the BIND (Berkeley Internet Name Domain) distribution. It was one of the earliest and most widely available tools for querying DNS. Its usage was prevalent in the early days of the internet for diagnosing DNS issues. However, over time, its limitations became apparent, leading to the development of more robust alternatives like <b>dig</b>. Despite its deprecation by ISC, it remains a commonly found utility on Linux, Unix, and Windows systems, often included for backward compatibility and basic troubleshooting.


title: DESCRIPTION
content:
The <b>nsnake</b> command launches a simple, yet addictive, terminal-based implementation of the classic Snake game. Utilizing the <i>ncurses</i> library, it provides a retro text-based graphical interface for playing. The objective is to control a growing snake to eat 'food' items, which increases its length. Players must navigate the snake around the screen, avoiding collisions with the boundaries of the play area and its own ever-lengthening tail. As the snake grows, the game typically increases in speed, raising the challenge. It's a lightweight, fun way to pass time directly within your command-line environment, perfect for quick breaks or demonstrating basic terminal capabilities.


title: CAVEATS
content:
Due to its text-based nature, <b>nsnake</b>'s appearance and responsiveness can be affected by the terminal emulator used, its font settings, and the terminal window size. A sufficiently large terminal window is recommended for optimal display. If the terminal is too small, the game might not render correctly or may truncate the display. Exiting the game is usually done by pressing 'q' or 'Ctrl+C'.


title: CONTROLS
content:
Gameplay in <b>nsnake</b> is controlled using the standard arrow keys:<br><i>Up Arrow</i>: Move snake upwards<br><i>Down Arrow</i>: Move snake downwards<br><i>Left Arrow</i>: Move snake left<br><i>Right Arrow</i>: Move snake right<br>To quit the game, typically press 'q' or 'Ctrl+C'.


title: GAMEPLAY
content:
The game starts with a short snake on a grid. Scattered randomly is a 'food' item. Guide the snake to consume the food, which makes the snake grow longer and earns points. New food appears after each consumption. The challenge increases as the snake gets longer and sometimes faster, requiring more precise movements. The game ends when the snake collides with the terminal boundaries or with its own body.


title: HISTORY
content:
<b>nsnake</b> was developed by Alexandre Dantas as a straightforward and portable ncurses-based game. It became a popular package in various Linux distributions due to its simplicity, small footprint, and adherence to the classic Snake gameplay. Its development focuses on providing a clean, functional terminal game without complex features, making it a stable and widely available utility for casual entertainment on the command line.


title: SYNOPSIS
content:
<pre><b>nsupdate</b> [<I>options</I>] [<I>filename</I>]<br></pre><br><i>Example usage:</i><br><pre><b>nsupdate</b> <I>-k Kexample.com.+157+12345.key</I><br><b>update add</b> <I>host.example.com 300 A 192.0.2.1</I><br><b>send</b><br></pre>


title: PARAMETERS
content:
<b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output. This provides more detailed information about the update process.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable even more debug output. Provides maximum debugging information.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use TCP (virtual circuit) for sending update requests. By default, UDP is used unless the request is too large.<br><br><b><b>-y</b> <I>keyname:secret</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a TSIG (Transaction Signature) key directly using its name and base64-encoded secret. For example, <i>-y host.example.com:ABCDEF...</i><br><br><b><b>-k</b> <I>keyfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing a TSIG key. This file is typically generated by <b>dnssec-keygen</b> and follows a specific format (e.g., <i>Khost.example.com.+alg+id.key</i>).<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use GSS-API (Kerberos) for authentication. This requires Kerberos credentials and configuration.<br><br><b><b>-o</b> <I>GSS-API-options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide additional GSS-API options. Consult Kerberos documentation for available options.<br><br><b><b>-t</b> <I>timeout</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the total timeout for the update request in seconds.<br><br><b><b>-u</b> <I>udp-timeout</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the timeout for UDP queries in seconds. This applies to individual UDP packets, not the total transaction.<br><br><b><b>-r</b> <I>attempts</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of UDP query retries.<br><br><b><b>-R</b> <I>retries</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the total number of retries for the entire update operation.<br><br><b><b>-p</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the port number of the DNS server to send updates to. Default is 53.<br><br><b><b>-P</b> <I>local_port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the local port number to bind to for sending updates.<br><br><b><b>-V</b> <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging verbosity level for <b>nsupdate</b>. Higher numbers mean more verbose output.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send commands from standard input as a single batch transaction. This ensures all commands are sent as one atomic update.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print all commands to standard output before sending them to the name server. Useful for debugging scripts.<br><br><b><i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read update commands from the specified file instead of standard input. If not provided, commands are read from stdin.<br><br>


title: DESCRIPTION
content:
<b>nsupdate</b> is a command-line utility used to send dynamic DNS update requests to a name server, in accordance with RFC 2136. It allows administrators and automated systems to programmatically add, delete, or modify DNS resource records directly on a DNS server. This is particularly useful for scenarios like DHCP servers updating A and PTR records when IP addresses are leased, or for scripts managing host entries. <b>nsupdate</b> operates by sending a series of update commands, which can be read from standard input or a specified file. To ensure secure updates, especially in production environments, <b>nsupdate</b> supports authentication methods such as TSIG (Transaction Signature) and GSS-API (Kerberos), which are crucial for preventing unauthorized modifications to DNS zones. The changes are typically batched and committed to the server with a <i>send</i> command, allowing for atomic updates.


title: CAVEATS
content:
Using <b>nsupdate</b> requires that the target DNS server (<I>named</I>) is configured to accept dynamic updates for the specific zone(s) you wish to modify. This configuration typically involves enabling 'allow-update' directives and specifying update policies, often leveraging TSIG keys or IP addresses for security. <br>Without proper authentication (e.g., TSIG or GSS-API), update requests will likely be rejected, or worse, could pose a significant security risk if the server is misconfigured to accept unauthenticated updates. <br>Changes made via <I>nsupdate</I> are not immediate on all DNS caches globally; propagation follows standard DNS practices.


title: COMMON UPDATE COMMANDS
content:
Within an <b>nsupdate</b> session (interactive or file-based), specific commands are used to define the update transaction:<br><b>server</b> <I>ip-address</I>: Specifies the target DNS server. If omitted, <b>nsupdate</b> attempts to determine it.<br><b>zone</b> <I>domain.com</I>: Specifies the zone to be updated. Essential for non-standard zone-finding.<br><b>key</b> <I>keyname secret</I> or <b>key</b> <I>alg:keyname secret</I>: Specifies a TSIG key inline.<br><b>update add</b> <I>name ttl type data</I>: Adds a new resource record.<br><b>update delete</b> <I>name [type [data]]</I>: Deletes records matching the criteria. If <i>type</i> or <i>data</i> are omitted, all records for <i>name</i> are deleted.<br><b>prereq nxdomain</b> <I>name</I>: Pre-requisite: requires that <i>name</i> does not exist.<br><b>prereq yxdomain</b> <I>name</I>: Pre-requisite: requires that <i>name</i> exists.<br><b>prereq nxrrset</b> <I>name type</I>: Pre-requisite: requires that no resource record of <i>type</i> exists for <i>name</i>.<br><b>prereq yxrrset</b> <I>name type [data]</I>: Pre-requisite: requires that a resource record of <i>type</i> exists for <i>name</i> (optionally with specific <i>data</i>).<br><b>send</b>: Commits all preceding update and prerequisite commands as a single transaction to the server.<br><b>show</b>: (Interactive mode) Shows the current message buffer to be sent.<br><b>quit</b>: Exits <b>nsupdate</b>.


title: SECURITY CONSIDERATIONS (TSIG/GSS-API)
content:
For any production environment, it is strongly recommended to use authenticated updates with <b>nsupdate</b>. The most common methods are:<br><b>TSIG (Transaction Signature)</b>: This uses symmetric key cryptography to sign each update message, ensuring authenticity and integrity. Keys are typically generated using <b>dnssec-keygen</b> and shared securely between the <b>nsupdate</b> client and the <b>named</b> server. This is specified using the <b>-k</b> or <b>-y</b> options.<br><b>GSS-API (Generic Security Service Application Programming Interface)</b>: This typically refers to Kerberos authentication. It allows <b>nsupdate</b> to participate in a Kerberos realm, authenticating with a Kerberos principal. This is specified using the <b>-g</b> option.


title: HISTORY
content:
The <b>nsupdate</b> utility is an integral part of the BIND (Berkeley Internet Name Domain) software suite, which has been the predominant DNS server implementation for decades. Its functionality is based on RFC 2136, 'Dynamic Updates in the Domain Name System (DNS UPDATE)', published in April 1997. Since its inception, <b>nsupdate</b> has evolved alongside BIND, incorporating features like TSIG authentication and GSS-API support to meet growing security demands and enterprise integration needs, making it a robust tool for automated DNS management.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Auto-reload images when they change on disk.</i><br><br><b>-b <<i>pixels</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set border width around images.</i><br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Copy currently viewed file's path to clipboard.</i><br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start in fullscreen mode.</i><br><br><b>-g <<i>GEOMETRY</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set window position and size (e.g., 1024x768+0+0).</i><br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Invert image colors.</i><br><br><b>-o <<i>COMMAND</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Open current image with a specified command.</i><br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress warnings.</i><br><br><b>-s <<i>MODE</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set image scaling mode (e.g., 'f' for fit, 'F' for fill, 'w' for width).</i><br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start in thumbnail mode.</i><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print version information and exit.</i><br><br><b>-z <<i>FACTOR</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set initial zoom factor (e.g., 0.5 for 50%).</i><br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable external script execution.</i><br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable EXIF tag display in the status bar.</i><br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Always play videos/GIFs with the external player instead of displaying them natively.</i><br><br><b>-T <<i>DIR</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an alternative thumbnail cache directory.</i><br><br>


title: DESCRIPTION
content:
<br><i>nsxiv</i> is a highly customizable and fast image viewer for X, forked from <i>sxiv</i> (Simple X Image Viewer). It extends its predecessor's capabilities by adding crucial features such as native video playback (leveraging external players like <i>mpv</i> or <i>mplayer</i>), animated GIF and APNG support, and enhanced thumbnail generation. <br>It maintains the minimalist design and responsiveness of <i>sxiv</i>, focusing on speed and efficiency, making it ideal for quickly browsing large collections of images and videos.<br><i>nsxiv</i> is designed to be scriptable, allowing users to define custom actions for images and videos through external scripts, integrating seamlessly into workflows. Its keyboard-driven interface, inspired by <i>Vim</i>, provides efficient navigation and manipulation without relying on mouse input.<br>The viewer also supports displaying EXIF metadata, offers various scaling modes, and allows for extensive customization via Xresources or a configuration file, making it a versatile tool for both casual browsing and more advanced media management.


title: CAVEATS
content:
<br><i>nsxiv</i> is an Xorg-dependent application, meaning it requires an X server to run and cannot be used in a purely console environment. <br>Video and animated GIF/APNG playback functionality relies on external programs like <i>mpv</i> or <i>mplayer</i> being installed and properly configured, as <i>nsxiv</i> itself does not embed media codecs. <br>Performance with extremely large image collections in thumbnail mode might vary based on system resources and configuration.


title: KEYBINDINGS
content:
<br><i>nsxiv</i> features a Vim-like keybinding system for efficient navigation and control. Common actions include 'h', 'j', 'k', 'l' for navigation, '+' and '-' for zooming, 'r' for rotating, and 'q' to quit. These are highly configurable via the configuration file.


title: CONFIGURATION
content:
<br>Configuration is primarily handled through Xresources or a dedicated configuration file (e.g., <i>~/.config/nsxiv/config</i>). This allows users to customize aspects like default scaling, border width, thumbnail dimensions, keybindings, and external command behaviors.


title: SCRIPTING
content:
<br>A core feature of <i>nsxiv</i> is its robust scripting interface. Users can define external scripts that execute actions on the currently viewed image or video, triggered by custom keybindings. This enables powerful integrations for tasks like file management, image manipulation, or sharing to online services.


title: HISTORY
content:
<br><i>nsxiv</i> originated as a community-driven fork of <i>sxiv</i> (Simple X Image Viewer). While <i>sxiv</i> focuses purely on image viewing with a minimalist design, users desired additional features like video playback, animated GIF support, and more robust scripting capabilities. <br><i>nsxiv</i> was created to fulfill these needs, integrating advanced functionalities while striving to maintain the core principles of speed, simplicity, and efficiency that define its predecessor. It has evolved to become a popular choice for users seeking a powerful yet lightweight media viewer with extensive customization options.


title: PARAMETERS
content:
<b>-o <I>option</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify mount options. Multiple options can be comma-separated.<br><br><b>-o defaults</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use default mount options.<br><br><b>-o ro</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount the file system in read-only mode.<br><br><b>-o rw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount the file system in read-write mode (this is the default).<br><br><b>-o uid=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ownership of all files and directories to the specified user ID.<br><br><b>-o gid=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ownership of all files and directories to the specified group ID.<br><br><b>-o umask=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the umask for all files and directories. Permissions are ORed with 022 by default.<br><br><b>-o fmask=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the umask for files only.<br><br><b>-o dmask=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the umask for directories only.<br><br><b>-o locale=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the locale to be used for filename encoding and decoding.<br><br><b>-o remove_hiberfile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the hibernation file. Use with caution if Windows is hibernated.<br><br><b>-o force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force mount, even if the file system is inconsistent or a hibernation file exists.<br><br><b>-o noatime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not update file access times (atime) on the file system.<br><br><b>-o relatime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update access times relative to modification or change times. (Default on many Linux systems).<br><br><b>-o windows_names</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forbid characters invalid in Windows filenames (e.g., :, *, ?, <, >, |).<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version and copyright information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfs-3g</i> is a stable, open-source driver that enables Linux, macOS, and other Unix-like operating systems to read and write to Microsoft Windows NTFS formatted partitions. It provides full read and write access, including creating, deleting, renaming, and moving files and directories, as well as managing file permissions and ownership. Unlike older drivers that offered limited or read-only support, <i>ntfs-3g</i> was specifically developed to handle complex NTFS features like journal replay, access control lists (ACLs), and data streams robustly, making it a reliable solution for interoperability between Windows and Linux environments.<br><br>It typically uses FUSE (Filesystem in Userspace) to operate in user space, enhancing stability and security. It is the de-facto standard for NTFS support on Linux systems.


title: CAVEATS
content:
If a Windows system is hibernated (or has 'Fast Startup' enabled), mounting the NTFS partition in read-write mode without the <I>remove_hiberfile</I> or <I>force</I> option can lead to data loss or corruption on the NTFS volume, as the file system is not properly unmounted. Always ensure Windows is fully shut down before mounting with read/write access. Default mount options might not preserve full NTFS permissions or ownership, often presenting all files as owned by the mounting user/group; use <I>uid</I>, <I>gid</I>, <I>umask</I> or <I>permissions</I> options for more granular control.


title: AUTOMATIC MOUNTING WITH /ETC/FSTAB
content:
To automatically mount an NTFS partition at boot time, you can add an entry to the <I>/etc/fstab</I> file. A typical entry would look like:<br><br><code><I>device</I> <I>mount_point</I> ntfs-3g defaults 0 0</code><br><br>Replace <I>device</I> with the partition's UUID or path (e.g., <code>/dev/sda1</code>) and <I>mount_point</I> with the desired directory (e.g., <code>/mnt/windows</code>). You can also include specific options like <code>uid=1000,gid=1000,umask=0022</code> to set permissions.


title: PERFORMANCE CONSIDERATIONS
content:
While <i>ntfs-3g</i> offers excellent compatibility and stability, performance might be slightly lower compared to native Linux file systems (like Ext4) due to the overhead of running in user space via FUSE. For typical daily usage, this difference is often negligible, but for extremely I/O intensive tasks, a native Linux file system might be preferred if interoperability is not a strict requirement.


title: HISTORY
content:
<i>ntfs-3g</i> was initially developed by Szabolcs Szakacsits and first released in 2006. It quickly gained popularity due to its robust read/write capabilities for NTFS, which was a significant improvement over previous, more limited drivers. It rapidly became the de-facto standard for NTFS support in Linux, often bundled as a default component in most major distributions. Its reliance on the FUSE (Filesystem in Userspace) architecture allowed it to develop rapidly and independently of the kernel, providing a safer user-space environment for complex file system operations while maintaining high stability.


title: PARAMETERS
content:
<b><i>&lt;device&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device containing the NTFS filesystem to probe (e.g., <i>/dev/sda1</i>).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force probing even if the device is already mounted. Use with caution.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output; rely solely on the exit status for scripting.<br><br><b><b>-r</b>, <b>--read-only-state</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with status 0 if the partition can be mounted read-only, 1 otherwise.<br><br><b><b>-u</b>, <b>--hibernation-state</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with status 0 if the partition is hibernated, 1 otherwise.<br><br><b><b>-w</b>, <b>--windows-shutdown-state</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit with status 0 if Windows was not properly shut down (i.e., Fast Startup or dirty flag is set), 1 otherwise.<br><br>


title: DESCRIPTION
content:
<i>ntfs-3g.probe</i> is a diagnostic utility included with the <b>ntfs-3g</b> driver suite, designed to inspect the state of an NTFS filesystem on a specified block device. Its primary function is to determine if the NTFS partition is in a clean state, suitable for mounting and modification without risking data corruption.<br><br>The command checks for critical conditions such as <b>Windows hibernation</b>, <b>Fast Startup</b> (a feature in Windows 8/10/11 that uses a form of hibernation), and a <b>"dirty" filesystem flag</b>. If the partition is hibernated or Fast Startup is active, <i>ntfs-3g.probe</i> will advise against mounting and writing to the partition from Linux, as this could lead to data loss or corruption when Windows next boots. A dirty filesystem flag similarly indicates inconsistencies that should be resolved by booting Windows and performing a proper shutdown or running <i>chkdsk</i>.<br><br>While often called implicitly by <i>ntfs-3g</i> or the <i>mount</i> command before an NTFS filesystem is mounted, <i>ntfs-3g.probe</i> can also be run manually to pre-check a filesystem's health and readiness, aiding in scripting and ensuring data integrity.


title: CAVEATS
content:
<i>ntfs-3g.probe</i> only reports the state of the NTFS partition; it does not fix any issues. If the partition is reported as hibernated or affected by Fast Startup, you must boot into Windows and perform a full shutdown (or disable Fast Startup) for safe read-write access from Linux. A 'dirty' flag requires running <i>chkdsk</i> on Windows. While <i>ntfs-3g</i> often calls <i>probe</i> internally, manual use is primarily for advanced scripting or troubleshooting.


title: EXIT STATUS
content:
The exit status of <i>ntfs-3g.probe</i> is crucial for scripting:<br><b>0</b>: Success, or the specific condition checked by <b>-u</b>, <b>-w</b>, or <b>-r</b> was met.<br><b>1</b>: The condition checked by <b>-u</b>, <b>-w</b>, or <b>-r</b> was not met, or a general failure occurred.<br><b>&gt;1</b>: An error occurred during execution.


title: WINDOWS FAST STARTUP & HIBERNATION
content:
These Windows features leave the NTFS filesystem in a state that is unsafe for write operations from other operating systems like Linux. <i>ntfs-3g.probe</i> explicitly warns about these conditions. To safely modify an NTFS partition from Linux, you must disable Fast Startup in Windows power options and ensure a full shutdown (not a restart or hibernate).


title: HISTORY
content:
<i>ntfs-3g.probe</i> is an integral part of the <b>ntfs-3g</b> project, which began as a FUSE-based driver aimed at providing robust and full read-write support for NTFS filesystems on Linux. Developed to overcome the limitations of earlier, often read-only, NTFS drivers, the <i>ntfs-3g</i> suite, including <i>ntfs-3g.probe</i>, evolved to handle the complexities introduced by modern Windows features like hibernation and Fast Startup, ensuring data integrity across dual-boot environments.


title: PARAMETERS
content:
<b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays verbose output, providing more detailed information about the audit process and any discrepancies found.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the raw security descriptors found on the NTFS volume in hexadecimal format, useful for low-level analysis.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the parsed Access Control Lists (ACLs) for each file or directory, presenting the individual Access Control Entries (ACEs).<br><br><b><device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the NTFS volume or partition to be audited (e.g., <b>/dev/sda1</b>). This is a mandatory argument.<br><br>


title: DESCRIPTION
content:
<i>ntfs-3g.secaudit</i> is a utility from the <b>ntfs-3g</b> suite designed to audit and verify the consistency of security permissions on an NTFS volume. It plays a crucial role in ensuring that the security descriptors (Windows ACLs) stored on the NTFS filesystem are correctly reflected in the Linux permission model and extended attributes after being mounted by <b>ntfs-3g</b>.<br><br>The command primarily checks for discrepancies between the actual NTFS Access Control Lists (ACLs) and how they are represented by the Linux file permissions (mode bits) and the <i>security.ntfs_acl</i> extended attribute, if used. This audit is vital for maintaining security integrity, especially in environments where files might be accessed from both Windows and Linux systems, or when specific Windows-compatible security settings are expected to persist. It helps identify situations where the Linux-side representation of permissions might not accurately mirror the underlying NTFS ACLs, potentially leading to unintended access or security vulnerabilities.<br><br>It provides verbose output options to detail any findings and can display raw security descriptors or parsed ACLs for deeper investigation, but it does not modify the filesystem; it only reports.


title: CAVEATS
content:
The <i>ntfs-3g.secaudit</i> command is an auditing tool only; it does not fix or modify any permissions or security descriptors on the NTFS volume. Any discrepancies found must be addressed manually or by remounting with appropriate <b>ntfs-3g</b> options.<br><br>While it performs a read-only audit, it's generally recommended to ensure the volume is not actively being written to during the audit to avoid potential inconsistencies if data changes mid-scan. The accuracy of the audit regarding Linux permissions relies on the <b>ntfs-3g</b> mount having stored the Windows ACLs in extended attributes (e.g., using <i>acl</i> or <i>xattr</i> mount options). Without these, the Linux-side representation might not fully reflect the NTFS ACLs, leading to potentially incomplete or misleading audit results.


title: EXIT STATUS
content:
The command provides a clear exit status to indicate the audit result:<br><ul><li><b>0</b>: No discrepancies were found, indicating that the security permissions are consistent.</li><li><b>1</b>: Discrepancies were detected, meaning there are inconsistencies between the NTFS ACLs and their Linux representation.</li><li><b>2</b>: An error occurred during the audit process, preventing a complete report.</li></ul>


title: INTEGRATION WITH EXTENDED ATTRIBUTES
content:
<i>ntfs-3g.secaudit</i> heavily relies on and checks the <i>security.ntfs_acl</i> extended attribute. When <b>ntfs-3g</b> is mounted with <i>acl</i> or <i>xattr</i> options, it attempts to store a binary representation of the Windows security descriptor as an extended attribute on files and directories. This utility compares the content of this <i>security.ntfs_acl</i> xattr (if present) with the actual security descriptor parsed directly from the NTFS volume, along with verifying the standard Linux mode bits against the effective permissions derived from the NTFS ACL. This feature is fundamental for preserving and auditing rich Windows permissions on a Linux system.


title: HISTORY
content:
The <i>ntfs-3g.secaudit</i> utility is an integral part of the <b>ntfs-3g</b> project, which began development in 2006 to provide robust read-write access to NTFS filesystems from Linux and other Unix-like operating systems. As <b>ntfs-3g</b> evolved to support more advanced NTFS features, including Windows security descriptors and Access Control Lists (ACLs), tools like <i>ntfs-3g.secaudit</i> became necessary to verify the correctness and consistency of these complex permission mappings. It addresses the critical need for administrators to audit whether the Linux-exposed permissions and extended attributes accurately reflect the underlying NTFS security model, bridging the gap between Windows and Linux security paradigms. Its development paralleled the improvements in <b>ntfs-3g</b>'s <i>xattr</i> and <i>acl</i> support, which are crucial for preserving Windows ACLs.


title: SYNOPSIS
content:
<b>ntfs-3g.usermap</b> [<i>options</i>] <i>&lt;ntfs-source&gt;</i> [<i>&lt;mapping-file-path&gt;</i>]<br><b>ntfs-3g.usermap</b> [<i>options</i>] <b>-</b> [<i>&lt;mapping-file-path&gt;</i>]


title: PARAMETERS
content:
<b><i>&lt;ntfs-source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The NTFS device (e.g., <i>/dev/sdb1</i>), mount point (e.g., <i>/mnt/ntfs</i>), or <b>-</b> to read SIDs from standard input.<br><br><b><i>&lt;mapping-file-path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The path to the mapping file to be created or updated. If omitted, the output is printed to standard output.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b><b>-c</b>, <b>--create-mapping</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new mapping file, overwriting any existing one at the specified path.<br><br><b><b>-a</b>, <b>--append</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends new mappings to an existing mapping file. This is the default behavior if <b>-c</b> is not used and the file exists.<br><br><b><b>-p</b>, <b>--permissions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes full permission mapping, allowing for a more accurate translation of NTFS permissions. This option often requires root privileges.<br><br><b><b>-u</b>, <b>--user-mapping</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes user mapping. This option is implied by <b>-p</b>.<br><br><b><b>-g</b>, <b>--group-mapping</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes group mapping. This option is implied by <b>-p</b>.<br><br><b><b>-e</b>, <b>--everyone</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a mapping for the Windows 'Everyone' SID to a specified Linux UID/GID. Useful for general access.<br><br><b><b>-o</b>, <b>--owner</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maps the owner of the NTFS device (the user who mounted it) to a specific Windows SID. This is useful for consistent ownership.<br><br><b><b>-s</b> <i>SID</i>, <b>--sid</b> <i>SID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular Windows SID to be mapped.<br><br><b><b>-U</b> <i>UID</i>, <b>--uid</b> <i>UID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular Linux UID to map to a given SID or to be included in the mapping.<br><br><b><b>-G</b> <i>GID</i>, <b>--gid</b> <i>GID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular Linux GID to map to a given SID or to be included in the mapping.<br><br>


title: DESCRIPTION
content:
The <b>ntfs-3g.usermap</b> command is a utility provided by the <b>ntfs-3g</b> project, designed to facilitate proper file ownership and permissions when interacting with NTFS filesystems from Linux. Its primary function is to create and manage a mapping file that translates Windows Security Identifiers (SIDs) to Linux User IDs (UIDs) and Group IDs (GIDs).<br><br>This mapping is crucial for <b>ntfs-3g</b> to correctly interpret and enforce file access controls. When an NTFS partition is mounted with options like <i>permissions</i> or <i>acl</i>, <b>ntfs-3g</b> relies on this mapping file to present NTFS file ownership and permissions in a way that is understandable and manageable by the Linux kernel and userland tools. Without a proper mapping, all files might appear to be owned by a single user (e.g., root) or the user mounting the filesystem, losing granular permission control. The command can read SIDs from an NTFS device or a specific file, generate a new mapping file, append to an existing one, or manage individual SID-UID/GID entries.


title: CAVEATS
content:
Using <b>ntfs-3g.usermap</b> effectively often requires a good understanding of both Windows SIDs and Linux UIDs/GIDs. Generating a comprehensive mapping can be complex, especially in environments with many users or dynamically changing SIDs. Incorrect mappings can lead to unexpected permission issues. For accurate permission translation, the command often needs to be run with root privileges. The generated mapping file must be placed in a location where <b>ntfs-3g</b> can find it (e.g., <i>/etc/ntfs-3g.usermap</i> or specified via the <i>usermap=</i> mount option) and must be consistent with the actual users/groups on the Linux system.


title: MAPPING FILE FORMAT AND LOCATION
content:
The mapping file generated by <b>ntfs-3g.usermap</b> is a plain text file, typically located at <i>/etc/ntfs-3g.usermap</i>, though its path can be specified during mounting using the <i>usermap=</i> option. Each line in the file represents a mapping, usually in the format '<i>SID:UID:GID</i>' or '<i>SID:UID</i>' or '<i>SID:GID</i>'. It is crucial for <b>ntfs-3g</b> to find this file during the mount process to correctly apply permissions and ownership to files and directories on the NTFS filesystem.


title: INTEGRATION WITH NTFS-3G MOUNT OPTIONS
content:
The full power of <b>ntfs-3g.usermap</b> is realized when mounting an NTFS partition with specific options in <b>ntfs-3g</b>. The most relevant options are <i>permissions</i> (or <i>acl</i>), which instructs <b>ntfs-3g</b> to honor NTFS permissions and use the mapping file, and <i>usermap=</i><i>path/to/usermap</i>, which explicitly points to the mapping file. Without these options, <b>ntfs-3g</b> often defaults to simpler ownership rules (e.g., all files owned by the mounting user), making the usermap less critical.


title: HISTORY
content:
The <b>ntfs-3g.usermap</b> utility is an integral part of the <b>ntfs-3g</b> project, which began development around 2006. <b>ntfs-3g</b> aimed to provide a robust, reliable, and performant read-write NTFS driver for Linux, a significant improvement over earlier, often experimental, NTFS support. As the project matured, features like accurate permission handling became essential, leading to the creation of utilities like <b>ntfs-3g.usermap</b> to bridge the inherent differences between Windows and Linux security models. Its development has been driven by the need for seamless interoperability between the two operating systems, particularly in dual-boot or shared storage environments.


title: PARAMETERS
content:
<b><I>&lt;device_or_image&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the raw NTFS block device (e.g., <I>/dev/sda1</I>) or a disk image file containing the NTFS filesystem from which to read.<br><br><b><I>&lt;ntfs_path_to_file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The full path to the file or directory within the NTFS filesystem that you wish to read or list. Paths are typically case-insensitive on NTFS, but specific implementations of this script might require particular casing.<br><br><b>-o <I>&lt;output_file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional) Redirects the content of the read file to the specified <I>&lt;output_file&gt;</I> instead of standard output. If this option is not used, the content will be printed to stdout.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional) Enables verbose output, providing more detailed information about the script's operations and the NTFS parsing process, useful for debugging or understanding data extraction.<br><br>


title: DESCRIPTION
content:
The <B>ntfs-read.py</B> command is a Python script designed to read specific files or directories from an NTFS (New Technology File System) partition or disk image, bypassing the need to mount the filesystem. It operates at a low level, directly interpreting the NTFS structures to locate and extract data. This makes it particularly useful in scenarios where the filesystem might be corrupted and unmountable, or for forensic analysis where mounting could alter the evidence. It's often found as part of NTFS utility collections or as a standalone script used for data recovery or educational purposes to demonstrate direct filesystem access.<br><br>Unlike standard commands that operate on mounted filesystems, <B>ntfs-read.py</B> requires direct access to the block device (e.g., <I>/dev/sda1</I>) or a disk image file (e.g., <I>ntfs_image.img</I>). It takes the internal NTFS path to the desired file as an argument and typically outputs the file's content to standard output, which can then be redirected to a file. Its capabilities are often limited to reading, not writing, protecting the integrity of the source data.


title: CAVEATS
content:
The <B>ntfs-read.py</B> script is not a standard, officially maintained Linux command and its exact features, options, and stability can vary significantly depending on its specific version or source. It often serves as a demonstration or forensic tool rather than a robust, production-ready utility. Direct access to block devices typically requires root privileges. While primarily read-only, using it incorrectly on a live filesystem could potentially interfere with other operations, though it's designed to be non-destructive. It may lack comprehensive error handling compared to more mature filesystem tools.


title: TYPICAL USE CASES
content:
<B>ntfs-read.py</B> is commonly utilized for:<br><ul><li><I>Data Recovery:</I> Extracting files from NTFS partitions that are damaged, corrupted, or unmountable by standard means.</li><li><I>Digital Forensics:</I> Examining the contents of specific files on an NTFS disk image without mounting the filesystem, thus preserving the integrity of the original evidence.</li><li><I>Filesystem Analysis:</I> Providing a practical way to understand the internal structure of the NTFS filesystem and how data is stored and retrieved at a low level.</li></ul>


title: PREREQUISITES
content:
To effectively use <B>ntfs-read.py</B>, you generally need:<br><ul><li>A Python interpreter installed on your system (typically Python 2 or 3, depending on the script's version).</li><li>Necessary Python libraries for low-level disk I/O and NTFS parsing. These libraries are usually bundled with the script or can be installed via pip (e.g., a Python-ntfs library, though specific dependencies vary by script).</li><li>Root privileges are required for direct access to block devices like <I>/dev/sda1</I>, as standard users do not have permission to read raw disk sectors.


title: HISTORY
content:
The concept of directly parsing NTFS filesystems using scripting languages like Python emerged alongside the development of open-source NTFS drivers and forensic tools. <B>ntfs-read.py</B> (or similar scripts) typically originated as educational examples or specialized utilities to demonstrate low-level NTFS structure parsing. These scripts are often developed by individuals or communities involved in filesystem development, data recovery, or digital forensics, rather than being part of a single, officially maintained project with a formal version history.


title: PARAMETERS
content:
<b><i>DEVICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device containing the NTFS filesystem (e.g., <i>/dev/sda1</i>).<br><br><b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file on the NTFS filesystem, or its inode number when used with <b>-i</b>.<br><br><b><b>-a</b>, <b>--attribute</b> <i>ATTR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the specified attribute type (e.g., <i>$DATA</i>, <i>$FILE_NAME</i>). Uses <i>$DATA</i> by default. See also <b>-t</b>.<br><br><b><b>-b</b>, <b>--byte-range</b> <i>RANGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only dump the specified byte range of the file. <i>RANGE</i> can be <i>OFFSET-LENGTH</i> or <i>OFFSET..END</i>.<br><br><b><b>-F</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forcefully access the filesystem, even if it's marked dirty or has inconsistencies.<br><br><b><b>-H</b>, <b>--no-action</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not perform any action. Just print information about the command's intended operation and the file.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command options and exit.<br><br><b><b>-i</b>, <b>--inode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret <i>FILE</i> as an inode number instead of a path.<br><br><b><b>-l</b>, <b>--log-level</b> <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging level. Common levels include <i>none</i>, <i>error</i>, <i>warning</i>, <i>info</i>, <i>debug</i>, <i>all</i>.<br><br><b><b>-n</b>, <b>--named-attribute</b> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the contents of the named attribute <i>NAME</i> instead of the default unnamed data attribute. Useful for accessing Alternate Data Streams.<br><br><b><b>-o</b>, <b>--output</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the file contents to <i>FILE</i> instead of standard output.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose messages and warnings, printing only critical errors.<br><br><b><b>-s</b>, <b>--sector-size</b> <i>SIZE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the size of sectors on the device in bytes. This is usually detected automatically.<br><br><b><b>-S</b>, <b>--start-sector</b> <i>SECTOR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the start sector on the device where the NTFS partition begins. Useful for embedded NTFS volumes.<br><br><b><b>-t</b>, <b>--type</b> <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the specified attribute type by its numeric type ID or name (e.g., <i>0x80</i> or <i>$DATA</i>). See also <b>-a</b>.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>ntfscat</b> command is a utility designed to read and dump the contents of a specified file from an NTFS filesystem directly to standard output. Unlike typical file utilities that operate on mounted filesystems, <b>ntfscat</b> works on the raw block device (e.g., <i>/dev/sda1</i>) containing the NTFS volume. This makes it particularly useful for scenarios where the NTFS filesystem is unmountable, corrupted, or when you need to access files without mounting the partition.<br><br>It can retrieve data from both the default unnamed data stream and named data streams (Alternate Data Streams) associated with a file. Its primary use cases include data recovery from damaged volumes, forensic analysis, or simply accessing files from an NTFS partition in a Linux environment without full mount permissions or stability concerns. It can also output directly to a file instead of stdout.


title: CAVEATS
content:
<b>ntfscat</b> has several known limitations. It may not correctly handle:<br>Files with non-resident attribute lists (complex file structures).<br>Compressed files (data will likely be dumped in its compressed form).<br>Encrypted files (dumped as raw encrypted data).<br>Sparse files (may dump full allocated space, not just actual data).<br>Files with reparse points (symbolic links, junction points, mount points).<br>For complex or unusual NTFS structures, results may be unreliable or incomplete.


title: DEVICE ARGUMENT
content:
The <i>DEVICE</i> argument must refer to the raw block device (e.g., <i>/dev/sda1</i>, <i>/dev/nvme0n1p3</i>) where the NTFS filesystem resides, not a mounted directory. Running <b>ntfscat</b> on a mounted partition is generally safe for read operations, but it's best practice to unmount the filesystem before using block-level tools to avoid potential inconsistencies, especially if the filesystem is actively being written to by another process.


title: FILE PATH AND INODE
content:
The <i>FILE</i> argument specifies the path to the file within the NTFS filesystem (e.g., <i>/path/to/document.docx</i>). Alternatively, if you know the file's inode number, you can use the <b>-i</b> option to specify the inode directly. This is particularly useful in recovery scenarios where the file's path might be corrupted or unknown.


title: HISTORY
content:
The <b>ntfscat</b> utility is part of the <i>ntfsprogs</i> suite, a collection of command-line tools for managing and accessing NTFS filesystems from Linux and other Unix-like operating systems. Originally developed by Anton Altaparmakov and a team of contributors, <i>ntfsprogs</i> aimed to provide robust support for read-write operations on NTFS before the widespread adoption of the more comprehensive <i>ntfs-3g</i> driver. While <i>ntfs-3g</i> provides full filesystem mounting capabilities, tools like <b>ntfscat</b> remain valuable for direct disk access and forensic purposes.


title: SYNOPSIS
content:
<b>ntfsclone</b> [<i>OPTIONS</i>] <i>SOURCE</i> [<i>DESTINATION</i>]<br><br><b>Examples:</b><br><b>ntfsclone</b> <i>/dev/sda1</i> <i>image.img</i><br><b>ntfsclone</b> <i>image.img</i> <i>/dev/sdb1</i><br><b>ntfsclone</b> <i>/dev/sda1</i> <i>/dev/sdb1</i>


title: PARAMETERS
content:
<b><b>-o</b>, <b>--output-file</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file to write the image to when cloning from a device.<br><br><b><b>-r</b>, <b>--restore-image</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restore the image from <i>SOURCE</i> (a file) to <i>DESTINATION</i> (a device or file). This is the default if <i>SOURCE</i> is a file and <i>DESTINATION</i> is a device.<br><br><b><b>-s</b>, <b>--rescue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore read errors and continue cloning. Useful for damaged partitions or forensic imaging.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the operation, e.g., overwrite an existing destination file or partition without prompting.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output and show only critical messages.<br><br><b><b>-p</b>, <b>--percent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a progress bar showing the percentage of the cloning process completed.<br><br><b><b>-L</b>, <b>--label</b> <i>NEW_LABEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a new volume label for the NTFS filesystem during restoration.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfsclone</i> is a powerful and efficient command-line utility for cloning or restoring NTFS partitions. Unlike generic block-level cloning tools like <i>dd</i>, <i>ntfsclone</i> intelligently copies only the allocated blocks of an NTFS filesystem, including all metadata, making it significantly faster and more space-efficient, especially for partitions with a lot of free space. It can create an exact image of an NTFS partition into a file or directly clone it to another partition. This tool is part of the <i>ntfs-3g</i> project, which provides robust NTFS filesystem support for Linux. It is widely used for creating backups of Windows partitions, migrating systems to new drives, or for forensic imaging, all without requiring a Windows environment.


title: CAVEATS
content:
The source NTFS partition must be unmounted before cloning to ensure data consistency.<br>The destination partition or file system must be large enough to accommodate all allocated blocks of the source NTFS partition. While <i>ntfsclone</i> copies only used blocks, it does not inherently resize partitions. Resizing usually needs to be done with tools like <i>ntfsresize</i> or <i>GParted</i> after restoration.<br>It is specifically designed for NTFS filesystems; it cannot be used with other filesystem types.


title: HISTORY
content:
<i>ntfsclone</i> originated as part of the <i>ntfsprogs</i> project, a suite of utilities for manipulating NTFS filesystems from Linux. This project later merged with <i>NTFS-3G</i>, an open-source driver providing read-write NTFS support. The development focused on creating robust, reliable, and efficient tools that could safely interact with NTFS, filling a critical gap in Linux's capabilities for Windows-compatible disk management. Its design, specifically copying only used blocks, was a significant advancement over generic sector-by-sector copying for NTFS.


title: PARAMETERS
content:
<b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output during the scan, showing only essential information.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <b>ntfscluster</b> to run even if the volume is marked dirty, has a reparse point, or is hibernated. Use this option with extreme caution as it may lead to data inconsistencies or incorrect results if the volume is not in a consistent state.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit, showing available options and their brief descriptions.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information, copyright, and license details, then exit.<br><br>


title: DESCRIPTION
content:
<b>ntfscluster</b> is a utility from the <I>ntfsprogs</I> suite designed to identify which files on an NTFS volume occupy one or more specified cluster numbers. This command is particularly useful for debugging and forensic purposes when filesystem errors are reported by tools like <b>ntfsfix</b> or <b>chkdsk</b>, pinpointing corruption to specific clusters. By providing the device path of the NTFS volume and the cluster numbers, <b>ntfscluster</b> scans the Master File Table (MFT) to map these clusters back to the files that own them.<br><br>It helps administrators and data recovery specialists understand the extent of data corruption or to trace specific data blocks to their associated files, aiding in recovery or detailed analysis of the filesystem state. Its primary function is to resolve cluster numbers to filenames, providing crucial information for diagnosing NTFS volume issues.


title: CAVEATS
content:
Accessing raw disk devices typically requires root privileges. Using the <b>--force</b> option on a dirty or hibernated NTFS volume can potentially lead to inconsistencies or incorrect results if the volume is not in a stable state. Always ensure the volume is unmounted or in a consistent state before performing operations unless absolutely necessary with <b>--force</b>.


title: ARGUMENTS
content:
In addition to the options, <b>ntfscluster</b> requires the following arguments for its operation:<br><ul><li><I>device</I>: The path to the NTFS volume (e.g., <code>/dev/sda1</code>). This specifies which disk partition to analyze.</li><li><I>cluster_number</I>: One or more cluster numbers to search for. These are typically block addresses reported by other filesystem utilities or error messages, indicating specific data locations on the volume.</li></ul>


title: EXIT CODES
content:
The command can return the following exit codes to indicate the result of its execution:<br><ul><li><b>0</b>: Success. The command completed its operation without errors.</li><li><b>1</b>: Failure (e.g., syntax or usage error, an invalid device was specified, or a filesystem error prevented proper operation).</li><li><b>2</b>: An internal error occurred within the program itself, indicating an unexpected condition.</li></ul>


title: USAGE EXAMPLES
content:
To identify files using cluster 12345 on the NTFS partition <code>/dev/sda1</code>:<br><code><b>ntfscluster</b> /dev/sda1 12345</code><br><br>To check multiple clusters at once, simply list them after the device path:<br><code><b>ntfscluster</b> /dev/sda1 12345 12346 12347</code>


title: HISTORY
content:
<b>ntfscluster</b> is a utility developed by Anton Altaparmakov and is part of the <I>ntfsprogs</I> (now often distributed as part of <I>ntfs-3g</I>) suite. This suite provides a collection of robust tools for interacting with NTFS filesystems on Linux, including read, write, and repair functionalities. Its development has been crucial for robust NTFS support in the Linux ecosystem, allowing for detailed analysis and manipulation of Microsoft's proprietary filesystem.


title: PARAMETERS
content:
<b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output; only set the exit status.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare all MFT records, including currently unused ones. Default is only used records.<br><br><b><b>-A</b>, <b>--attribute-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare all attribute records, including unused ones. Default is only used records.<br><br><b><b>-b</b>, <b>--bad-sectors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare bad sector data structures.<br><br><b><b>-B</b>, <b>--boot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare boot sectors.<br><br><b><b>-d</b>, <b>--data</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare data streams of files. This implies <b>-m</b> and <b>-D</b>.<br><br><b><b>-D</b>, <b>--directory</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare directory structures. This implies <b>-m</b>.<br><br><b><b>-f</b>, <b>--file</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare file content, which implies <b>-d</b>.<br><br><b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare filesystem information like volume serial, version, etc.<br><br><b><b>-I</b>, <b>--index</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare index buffers.<br><br><b><b>-J</b>, <b>--logjournal</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare logjournal (USN Journal).<br><br><b><b>-m</b>, <b>--mft</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare MFT records.<br><br><b><b>-M</b>, <b>--mft-mirror</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare MFT mirror.<br><br><b><b>-s</b>, <b>--security</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare security descriptors.<br><br><b><b>-S</b>, <b>--sector</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compare raw sectors directly. This can be very slow for large disks.<br><br><b><b>-u</b>, <b>--unused</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Also show differences in unused MFT records.<br><br><b><b>-U</b>, <b>--unused-clusters</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show differences in unused clusters.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print more detailed information about differences found.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfscmp</i> is a utility from the <i>ntfs-3g</i> project designed to compare two NTFS filesystems residing on different block devices or image files. It examines various aspects of the filesystems to detect discrepancies, including boot records, MFT (Master File Table) entries, file attributes, directory structures, and even raw sector data. <br><br>This command is invaluable for verifying the integrity of cloned drives, validating backups against live systems, or identifying silent data corruption. It operates in a read-only manner, ensuring no modifications are made to the filesystems being compared. Users can specify which components to compare using various options, allowing for granular control over the comparison process, from high-level filesystem information to detailed file content and unused clusters.


title: CAVEATS
content:
<i>ntfscmp</i> requires direct access to the block devices or image files. It does not modify the filesystems being compared, operating in a purely read-only mode. When comparing file content (<b>-f</b> or <b>-d</b>) on large filesystems, the operation can be time-consuming and resource-intensive. It is designed for comparing entire filesystems, not individual files within them. <br><br>Ensure that the filesystems are unmounted or not in use by other processes to get a consistent comparison, especially when comparing live systems.


title: EXIT STATUS
content:
The command returns <b>0</b> if the two filesystems are identical. It returns <b>1</b> if differences are found between the filesystems. An exit status of <b>2</b> indicates an error occurred during execution.


title: TYPICAL USAGE
content:
This tool is most often used after cloning an NTFS drive to verify the integrity of the clone, or to periodically check a backup volume against a primary volume for any unexpected changes or data degradation. It's also useful for forensic analysis or debugging filesystem issues by comparing a suspect volume with a known good image.


title: HISTORY
content:
<i>ntfscmp</i> is part of the <i>ntfs-3g</i> project, an open-source initiative that provides a robust and full-featured read-write NTFS driver for Linux, macOS, FreeBSD, NetBSD, Solaris, and other operating systems. The utilities bundled with <i>ntfs-3g</i>, including <i>ntfscmp</i>, are designed to extend the functionality and management capabilities for NTFS volumes beyond basic mounting, focusing on data integrity and advanced operations.


title: SYNOPSIS
content:
<b>ntfscp</b> [<i>OPTIONS</i>] <i>SOURCE</i> <i>DESTINATION</i><br><b>ntfscp</b> [<i>OPTIONS</i>] <i>SOURCE...</i> <i>DIRECTORY</i>


title: PARAMETERS
content:
<b>-a, --archive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve all attributes, including permissions, timestamps, ownership, and extended attributes. This option implies <i>-dRPr</i> and <i>-t</i>.<br><br><b>-d, --no-dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not dereference symbolic links. Copy the symbolic link itself rather than the file it points to.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing files in the destination without prompting.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt before overwriting an existing file.<br><br><b>-p, --preserve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve file mode (permissions), ownership, and timestamps.<br><br><b>-r, -R, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy directories and their contents recursively.<br><br><b>-t, --alternate-data-streams</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy alternate data streams (ADS) to separate files. For example, <i>file:stream</i> will be copied as <i>file.stream</i>.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explain what is being done during the copy process.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfscp</i> is a utility from the <i>ntfs-3g</i> project designed for copying files and directories <b>from</b> an NTFS volume to a Linux filesystem. Unlike standard <i>cp</i>, <i>ntfscp</i> is specifically tailored to handle the complexities of NTFS, including preserving file permissions, timestamps, alternate data streams (ADS), hard links, and reparse points (such as symbolic links and junctions).<br><br>It aims to provide a more faithful copy when migrating data from an NTFS volume, ensuring that NTFS-specific metadata is either preserved or correctly translated to the target Linux filesystem where possible. This makes it particularly useful for backup or migration scenarios where maintaining data integrity and attributes from the NTFS source is crucial. It requires the NTFS volume to be mounted, typically using <i>ntfs-3g</i>.


title: CAVEATS
content:
<i>ntfscp</i> requires the NTFS volume to be mounted, typically using the <i>ntfs-3g</i> driver.<br>It is designed to copy files <b>from</b> an NTFS volume, not <b>to</b> an NTFS volume.<br>Not all NTFS-specific features (e.g., specific NTFS ACLs, encrypted files) can be perfectly translated or preserved on all Linux filesystems.<br>Alternate data streams are converted to separate files on the target filesystem, which might not be the desired behavior in all scenarios.<br>The target Linux filesystem should ideally support features like extended attributes, symbolic links, and hard links to fully leverage <i>ntfscp</i>'s preservation capabilities.


title: USAGE CONTEXT
content:
<i>ntfscp</i> is most valuable when performing data migration or backups from Windows systems where NTFS is the primary filesystem. Its strength lies in preserving NTFS-specific attributes and metadata, which is crucial for the integrity and functionality of the copied data on a Linux system, especially when dealing with complex file structures or applications.


title: HISTORY
content:
<i>ntfscp</i> is an integral part of the <i>ntfs-3g</i> project, which began development in the early 2000s to provide robust read-write support for NTFS filesystems on Linux and other Unix-like operating systems. It was developed to address the limitations of earlier, less stable NTFS drivers.<br><br><i>ntfscp</i> specifically emerged as a tool to correctly handle the intricacies of copying files <b>from</b> NTFS, ensuring that metadata fidelity was maintained beyond what a standard <i>cp</i> command could offer, given the fundamental differences between NTFS and POSIX filesystems. Its development has paralleled the continuous improvements in <i>ntfs-3g</i>'s ability to interpret and manage NTFS attributes, making it a reliable choice for data migration from Windows environments.


title: SYNOPSIS
content:
<b>ntfsfix</b> [<i>options</i>] <i>device</i><br><br>Example: <b>ntfsfix</b> /dev/<i>sda1</i><br>Example: <b>ntfsfix</b> -n /dev/<i>sdb2</i>


title: PARAMETERS
content:
<b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Clears</i> the <i>bad sectors list</i> on the <i>NTFS</i> partition.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables</i> all repair and check operations; instead, it <i>dumps</i> the <i>boot sector</i> information of the specified <i>device</i>.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Forces</i> the <i>clearing</i> of the <i>journal file</i>, even if it appears clean. This is usually done automatically if the journal is dirty.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <i>help message</i> with available options and exits.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a <i>dry run</i>. It shows what <b>ntfsfix</b> <i>would do</i> without actually writing any changes to the <i>device</i>. Useful for testing.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>version information</i> of <b>ntfsfix</b> and exits.<br><br><b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the <i>NTFS partition</i> to be checked or repaired (e.g., <i>/dev/sda1</i>, <i>/dev/nvme0n1p3</i>).<br><br>


title: DESCRIPTION
content:
<b>ntfsfix</b> is a utility from the <b>ntfs-3g</b> suite designed to resolve common inconsistencies and errors within <i>NTFS</i> filesystems. It's often used to repair minor issues that might prevent an <i>NTFS</i> volume from being mounted correctly on <i>Linux</i>. <br><br> The command performs several operations: it checks the <i>NTFS</i> boot sector, attempts to clear the journal file (if it's marked dirty), and resets the bad sector list. It's crucial to understand that <b>ntfsfix</b> is <i>not</i> a full replacement for <i>Microsoft Windows' <b>chkdsk</b></i> utility. It can fix basic errors but will not repair complex filesystem corruption or structural damage. For severe problems, using <b>chkdsk</b> on a <i>Windows</i> system is the recommended course of action. It's generally safe for minor repairs and an essential tool for <i>Linux</i> users working with <i>NTFS</i> partitions.


title: CAVEATS
content:
<b>ntfsfix</b> is <i>not</i> a comprehensive filesystem repair tool like <i>Windows' <b>chkdsk</b></i>. It only handles minor inconsistencies and aims to get the filesystem mountable. For severe corruption, <i><b>chkdsk</b></i> on <i>Windows</i> is the proper utility to use. <br><br> Always ensure the <i>NTFS</i> partition is <i>unmounted</i> before running <b>ntfsfix</b> to prevent data corruption. While generally safe for its intended purpose, it's always advisable to <i>back up critical data</i> before attempting any disk repair operations.


title: USAGE NOTES
content:
Always ensure the <i>NTFS</i> partition is <i>unmounted</i> before running <b>ntfsfix</b> to prevent data corruption. You can unmount a partition using the <b>umount</b> command (e.g., <b>umount</b> /dev/<i>sda1</i>). After running <b>ntfsfix</b>, attempt to mount the partition again to verify the repair.


title: HISTORY
content:
<b>ntfsfix</b> is an integral part of the <b>ntfs-3g</b> project, an open-source initiative that began to provide robust read and write capabilities for <i>NTFS</i> filesystems on <i>Linux</i> and other <i>Unix-like</i> operating systems. It was developed to address common issues that would prevent a clean mount of <i>NTFS</i> volumes, focusing on safety and minimal, targeted interventions. Its development reflects the ongoing effort to enhance <i>Linux's</i> interoperability with <i>Microsoft Windows</i> filesystems.


title: SYNOPSIS
content:
<b>ntfsinfo</b> [<i>options</i>] <i>device</i><br><b>ntfsinfo</b> [<i>options</i>] <i>device path</i>


title: PARAMETERS
content:
<b>-m, --mft-record <I>MFT_RECORD_NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the contents of a specific MFT record by its number. Useful for examining file system metadata directly.<br><br><b>-i, --inode <I>INODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information about a specific file or directory identified by its inode number. This provides details like file size, attributes, and security IDs.<br><br><b>-s, --security-id <I>SID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a security descriptor by its security ID. This allows inspection of access control lists associated with security objects.<br><br><b>-a, --attribute <I>MFT_RECORD_NUMBER</I>:<I>ATTR_TYPE</I>:<I>ATTR_NAME</I>:<I>ATTR_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inspect a specific attribute of an MFT record. Requires detailed knowledge of NTFS attribute types for precise use.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output, showing only essential information.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more detailed output, showing additional file system and debugging information.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>ntfsinfo</b> command is a utility from the <b>ntfs-3g</b> project, designed to display comprehensive information about an NTFS file system or specific files and directories residing on an NTFS volume. It allows users to inspect low-level details such as the volume's boot sector, file system version, cluster size, Master File Table (MFT) record size, and total MFT records. For individual files or directories, <b>ntfsinfo</b> can provide details like their inode number, size, attributes, security IDs, and data streams. This tool is invaluable for forensic analysis, troubleshooting NTFS volumes, or simply understanding the underlying structure of an NTFS partition on a Linux system. It operates in a read-only manner, ensuring data integrity during inspection.


title: CAVEATS
content:
<b>ntfsinfo</b> typically requires root privileges to access block devices directly (e.g., <i>/dev/sda1</i>). While it is a read-only tool and safe for inspection, incorrect interpretation of its low-level output without proper understanding of the NTFS file system can be misleading. It is strictly for NTFS volumes; it will not work with other file systems like ext4 or XFS.


title: COMMON USAGE PATTERNS
content:
To inspect the boot sector and general volume information of an NTFS partition, you would typically run <code><b>ntfsinfo</b> <i>/dev/sdXN</i></code>, where <i>/dev/sdXN</i> is your NTFS partition. <br><br>To get information about a specific file or directory on a mounted NTFS volume, you would use <code><b>ntfsinfo</b> <i>/dev/sdXN /path/to/file</i></code>. Remember that the path must be relative to the root of the NTFS partition if the partition is not mounted, or the full path if mounted.


title: LOW-LEVEL ANALYSIS
content:
One of the key strengths of <b>ntfsinfo</b> is its ability to delve into low-level NTFS structures. Options like <code>--mft-record</code> and <code>--attribute</code> are particularly useful for forensic investigators or developers who need to understand the precise layout and contents of the Master File Table (MFT) and its associated attributes, which define files, directories, and their metadata.


title: HISTORY
content:
<b>ntfsinfo</b> is an integral part of the <b>ntfs-3g</b> project, which began development in the early 2000s to provide robust and reliable read/write support for NTFS file systems on Linux and other Unix-like operating systems. Prior to <b>ntfs-3g</b>, NTFS support on Linux was often limited to read-only capabilities or unstable write support. <b>ntfsinfo</b>, along with other utilities like <b>ntfsfix</b> and <b>ntfsundelete</b>, was developed to give users comprehensive tools for managing and diagnosing NTFS volumes, filling a critical gap in Linux's file system utility suite.


title: SYNOPSIS
content:
<b>ntfslabel</b> [<i>options</i>] <i>device</i> [<i>new-label</i>]<br><br><i>device</i>: The path to the NTFS partition (e.g., <i>/dev/sda1</i>).<br>[<i>new-label</i>]: The optional new volume label to set. If omitted, the current label is displayed.


title: PARAMETERS
content:
<b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force operation.</i> Overrides some checks, such as if the volume is mounted. Use with extreme caution as it can lead to data loss if the filesystem is in use.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Quiet mode.</i> Suppresses most output messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verbose mode.</i> Displays more detailed information about the operation.<br><br><b>-n, --no-action</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Test mode.</i> Performs a dry run without actually writing any changes to the device. Useful for verifying the command's behavior.<br><br><b>-U, --uuid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display or set UUID.</i> When used alone, it displays the current UUID. When combined with an argument, it attempts to set the UUID to the provided value.<br><br><b>--new-uuid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generate new UUID.</i> Generates a new random UUID for the volume.<br><br><b>--set-uuid <i>UUID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set specific UUID.</i> Sets the volume's UUID to the specified <i>UUID</i> string.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display help.</i> Shows a summary of command usage and options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display version.</i> Shows the version information for <b>ntfslabel</b>.<br><br>


title: DESCRIPTION
content:
<b>ntfslabel</b> is a command-line utility used to display or modify the volume label of an NTFS (New Technology File System) partition. It is part of the <i>ntfsprogs</i> suite, which provides various tools for managing NTFS filesystems on Linux, often bundled with or built upon the <i>ntfs-3g</i> user-space driver. The primary purpose of <b>ntfslabel</b> is to provide a human-readable name for an NTFS volume, making it easier to identify in various contexts, such as file managers, mount points, or boot menus. This is particularly useful in multi-boot environments or when dealing with external USB drives.<br><br>When invoked without a new label, <b>ntfslabel</b> reads and displays the current label assigned to the specified device. If a new label is provided as an argument, the command attempts to write this new label directly to the NTFS boot sector of the partition. This operation requires root privileges, as it directly modifies a critical part of the filesystem structure. It's crucial to unmount the NTFS partition before attempting to change its label to prevent data corruption, although a <i>--force</i> option exists to bypass this check (use with extreme caution). In addition to setting a textual label, <b>ntfslabel</b> can also display or manage the Universal Unique Identifier (UUID) of an NTFS volume, offering another persistent method for identifying the filesystem. Understanding and utilizing <b>ntfslabel</b> is fundamental for effective management of NTFS volumes on Linux systems.


title: CAVEATS
content:
<b>Root Privileges:</b> <b>ntfslabel</b> requires root (superuser) privileges to modify the volume label or UUID, as it directly alters the filesystem's metadata.<br><b>Unmount Before Modifying:</b> It is highly recommended to unmount the NTFS partition before attempting to change its label or UUID. Modifying a mounted filesystem can lead to data corruption or loss. The <i>--force</i> option should only be used as a last resort and with a clear understanding of the risks.<br><b>Label Length:</b> NTFS volume labels are Unicode and have a maximum length of 32 characters. Longer labels will be truncated.<br><b>Character Set:</b> While NTFS supports Unicode, certain special characters or encodings might not display correctly across all operating systems or locales.<br><b>UUIDs vs. Labels:</b> UUIDs provide a truly unique, immutable identifier for a filesystem, whereas labels are human-readable names that can be changed. For scripting or system-level identification (e.g., in <i>/etc/fstab</i>), UUIDs are generally preferred for their robustness.


title: PERMISSIONS
content:
To read an NTFS volume's label or UUID, read access to the device file (e.g., <i>/dev/sda1</i>) is sufficient, though typically only root has direct access.<br>To write a new label or UUID, root privileges are strictly required.


title: ERROR HANDLING
content:
If the specified device is not an NTFS filesystem, <b>ntfslabel</b> will return an error.<br>Attempts to write to a mounted filesystem without <i>--force</i> will also result in an error, prompting the user to unmount the volume first.


title: HISTORY
content:
<b>ntfslabel</b> originated as part of the <i>ntfsprogs</i> project, a collection of open-source tools developed to enable Linux systems to interact with Microsoft's proprietary NTFS filesystem. Initially, Linux had limited native NTFS support, primarily read-only. The <i>ntfsprogs</i> suite, which later became integrated with and heavily relies on the <i>ntfs-3g</i> project, was crucial in providing robust read/write capabilities for NTFS. <b>ntfslabel</b> specifically addressed the need for users to easily identify and manage their NTFS volumes by assigning meaningful names, a common feature in other filesystem utilities (like <b>e2label</b> for ext filesystems). Its development has been driven by the ongoing need for seamless interoperability between Linux and Windows environments, making it an indispensable tool for dual-boot systems and external NTFS storage devices.


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not hide entries starting with '.' (dot).<br><br><b>-l, --long-listing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a long listing format, showing file details including NTFS attributes.<br><br><b>-d, --directory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List directory entries themselves, not their contents.<br><br><b>-F, --classify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append an indicator ('*', '/', '=', '>', '@', '|') to entries based on type.<br><br><b>-p, --pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pipe output to a pager (e.g., <b>less</b>).<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override some safety checks during operation.<br><br><b>-i, --inode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List inode (MFT record) numbers for each file.<br><br><b>-k, --kilobytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report allocated sizes in kilobytes.<br><br><b>-R, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List subdirectories recursively.<br><br><b>-s, --size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the allocated size of each file in blocks.<br><br><b>-S, --sort-by-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort entries by size, largest first.<br><br><b>-t, --sort-by-time</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort entries by modification time, newest first.<br><br><b>-r, --reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse the order of the sort.<br><br><b>-u, --access-time</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use access times for sorting (with <i>-t</i>) and long listing (with <i>-l</i>).<br><br><b>-c, --change-time</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use ctime (status change time) for sorting (with <i>-t</i>) and long listing (with <i>-l</i>).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce more verbose output.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfsls</i> is a utility from the <b>ntfs-3g</b> project designed to list the contents of directories on NTFS file systems. Unlike the standard <b>ls</b> command, <i>ntfsls</i> operates directly on an unmounted or mounted NTFS volume specified by its device path (e.g., <i>/dev/sda1</i>), providing a direct view of the NTFS metadata. It offers similar functionality to <b>ls</b>, including long listing formats, recursive directory traversal, and sorting options, but it displays NTFS-specific attributes like hidden, system, compressed, or encrypted flags where applicable, rather than traditional Unix permissions. This command is invaluable for examining the structure and contents of Windows partitions from a Linux environment without requiring the partition to be fully mounted, making it a powerful diagnostic and inspection tool for mixed-OS systems or data recovery scenarios.


title: CAVEATS
content:
<i>ntfsls</i> operates directly on the NTFS file system structure, requiring the target partition to be specified by its device node (e.g., <i>/dev/sda1</i>). It does not interact with the Linux VFS (Virtual File System) layer in the same way <b>ls</b> does for mounted file systems. Therefore, it won't reflect Linux-specific permissions or ownership, but rather NTFS attributes like archive, hidden, system, or encrypted flags. Ensure the device is not heavily in use or corrupted before running, though it's generally a read-only operation.


title: DIRECT DEVICE ACCESS
content:
<i>ntfsls</i> requires direct access to the NTFS device (e.g., <i>/dev/sdb1</i>), not a mount point. This allows inspection of partitions even if they cannot be mounted due to errors or if you wish to avoid altering the file system state.


title: NTFS ATTRIBUTE DISPLAY
content:
When using the long listing format (<i>-l</i>), <i>ntfsls</i> displays NTFS-specific file attributes (e.g., <i>A</i> for Archive, <i>H</i> for Hidden, <i>S</i> for System, <i>C</i> for Compressed, <i>E</i> for Encrypted) instead of standard Unix permissions, providing insight into the Windows-native file properties.


title: HISTORY
content:
The <i>ntfsls</i> command is an integral part of the <b>ntfs-3g</b> project, an open-source, GPL-licensed NTFS driver for Linux and other Unix-like operating systems. Initiated to provide robust read/write support for Microsoft Windows NTFS file systems, <b>ntfs-3g</b> filled a critical gap in Linux's ability to seamlessly interact with Windows partitions. <i>ntfsls</i> was developed as a complementary utility, offering a familiar <b>ls</b>-like interface specifically tailored for inspecting the contents of NTFS volumes, even when they are not mounted or are in a potentially problematic state. Its existence simplifies diagnostics and data access for users operating in dual-boot environments or needing to recover data from Windows systems.


title: SYNOPSIS
content:
<i>ntfsprogs</i> is a <b>package</b> containing a suite of utilities; there is no single <i>ntfsprogs</i> command invocation. Instead, individual utilities are invoked as follows:<br><br><b>mkntfs</b> [<i>options</i>] <i>device</i><br><b>ntfsfix</b> [<i>options</i>] <i>device</i><br><b>ntfsresize</b> [<i>options</i>] <i>device</i><br>...<br><br>Each utility has its own specific set of options and arguments. Consult the man page for each individual utility (e.g., <b>man ntfsfix</b>) for detailed syntax and usage.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the specific utility and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of the utility and exits.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation, even if the filesystem is dirty or marked as inconsistent. Use with extreme caution.<br><br><b>-n, --no-action, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run, showing what would be done without actually making any changes. Useful for testing.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, providing more details about the operation.<br><br>


title: DESCRIPTION
content:
<i>ntfsprogs</i> is a comprehensive suite of command-line utilities designed for creating, checking, resizing, and managing NTFS filesystems from Linux. It provides essential tools for interacting with partitions commonly used by Microsoft Windows, offering functionalities like fixing inconsistencies, resizing partitions, cloning, and recovering data. The suite is built upon the <i>libntfs</i> library, enabling robust and reliable operations on NTFS volumes. Key utilities include <b>mkntfs</b> (to create NTFS filesystems), <b>ntfsfix</b> (to fix common NTFS problems), <b>ntfsresize</b> (to change filesystem size), and <b>ntfsclone</b> (to clone or backup NTFS partitions). This package is crucial for system administrators and users who need to perform low-level maintenance or data recovery on NTFS volumes without relying on a Windows operating system. It ensures interoperability and provides powerful diagnostic and repair capabilities for NTFS.


title: CAVEATS
content:
<i>ntfsprogs</i> utilities operate at a low level on filesystems and can potentially lead to data loss if misused. It is crucial to:<br><b>Backup Data</b>: Always back up important data before performing any operations like resizing or fixing.<br><b>Unmount Filesystem</b>: The target NTFS partition should ideally be unmounted before running most <i>ntfsprogs</i> utilities to prevent data corruption. Operations on a mounted filesystem can lead to severe data loss.<br><b>Root Privileges</b>: Most operations require root privileges.<br><b>Dirty Filesystems</b>: Be cautious when operating on filesystems marked as 'dirty'; running <b>ntfsfix</b> is often the first step, but it's not a guarantee against data loss for severe issues.


title: KEY UTILITIES OVERVIEW
content:
Here is a brief overview of some of the most frequently used utilities within the <i>ntfsprogs</i> suite:<br><br><b>mkntfs</b>: Creates an NTFS filesystem on a specified device.<br><b>ntfsfix</b>: Fixes common NTFS problems and forces Windows to check the filesystem on next boot.<br><b>ntfsresize</b>: Resizes an NTFS filesystem without data loss, allowing for flexible partition management.<br><b>ntfsclone</b>: Efficiently clones, backs up, restores, or converts NTFS filesystems.<br><b>ntfsinfo</b>: Dumps detailed information about an NTFS volume or a specific file within it.<br><b>ntfslabel</b>: Displays or sets the NTFS volume label.<br><b>ntfscat</b>: Displays the contents of files stored on an NTFS volume without mounting it.


title: HISTORY
content:
The <i>ntfsprogs</i> suite originated as part of the Linux-NTFS project, which aimed to provide full read/write support for the NTFS filesystem within the Linux kernel. Initial efforts focused on reverse-engineering the NTFS format. Over time, the project evolved to include a comprehensive set of userspace tools built upon the <i>libntfs</i> library, allowing for advanced filesystem management, repair, and data recovery tasks. These tools became indispensable for Linux users needing robust interaction with Windows partitions, filling a critical gap in native Linux filesystem utilities. Development has continued, ensuring compatibility with newer NTFS versions and improving stability and feature sets.


title: PARAMETERS
content:
<b>-s, --size <SIZE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the new size of the NTFS filesystem. <SIZE> can be followed by K, M, G, T, P for kilobytes, megabytes, gigabytes, terabytes, petabytes respectively. Default unit is bytes.<br><br><b>-i, --info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about the NTFS filesystem (current size, minimum possible size) without performing any resize operation.<br><br><b>-P, --no-progress-bar</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the display of the progress bar during the operation.<br><br><b>-n, --no-action</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run. Do not write any changes to the device, just show what <i>ntfsresize</i> would do.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <i>ntfsresize</i> to run even if the NTFS filesystem is dirty, inconsistent, or seems to be hibernated. <b>Use with extreme caution, as it can lead to data loss.</b><br><br><b>--force-min-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to shrink the filesystem to the absolute minimum possible size, even if it might fail due to fragmentation.<br><br><b>--bad-sectors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable checking for bad sectors during the operation.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output except error messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed information about the operation steps.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfsresize</i> is a command-line utility for non-destructively resizing NTFS filesystems. It is a vital component of the <i>ntfs-3g</i> project, offering robust read-write support for NTFS partitions. This tool enables users to shrink or enlarge an existing NTFS filesystem without data loss, making it indispensable for disk management scenarios such as dual-booting Windows and Linux, or managing virtual machine disks. It operates by modifying the NTFS metadata to reflect the new size and <b>must be used on an unmounted partition</b>. After <i>ntfsresize</i> adjusts the filesystem, a partition editor (e.g., <i>parted</i> or <i>fdisk</i>) is typically required to adjust the partition table entry to match the filesystem's new dimensions.


title: CAVEATS
content:
<b><i>Unmounted Partition Required:</i></b> The NTFS filesystem <b><i>must be unmounted</i></b> before running <i>ntfsresize</i>. Operating on a mounted filesystem can lead to severe data corruption. <br><b><i>Separate Partition Table Adjustment:</i></b> <i>ntfsresize</i> only modifies the filesystem size; it <b>does not</b> change the partition table. After resizing the filesystem, you <b>must</b> use a partition editor (e.g., <i>fdisk</i>, <i>parted</i>, <i>gparted</i>) to adjust the partition entry in the partition table to match the new filesystem size. <br><b><i>Windows Hibernation/Fast Startup:</i></b> If Windows was hibernated or has 'Fast Startup' enabled, the NTFS filesystem may be in an inconsistent (dirty) state. <i>ntfsresize</i> will refuse to operate by default. Ensure Windows is fully shut down, or use the <i>-f</i> (force) option with extreme caution. <br><b><i>Fragmentation:</i></b> High fragmentation on the NTFS volume can prevent shrinking to the desired size, as <i>ntfsresize</i> cannot move data beyond the specified new end. Defragmenting the volume in Windows beforehand can help. <br><b><i>Backup Data:</i></b> Always back up important data before performing any disk resizing operations.


title: DEPENDENCIES
content:
<i>ntfsresize</i> is typically provided as part of the <i>ntfs-3g</i> package or similar <i>ntfs-utils</i> on most Linux distributions. Ensure this package is installed to use the command.


title: UNMOUNTING PROCEDURE
content:
Before any resize operation, verify the target partition is <b>not</b> mounted. You can check its status using the <i>mount</i> command and unmount it using <i>sudo umount /dev/sdXN</i> (replace <i>/dev/sdXN</i> with your partition's device path).


title: HISTORY
content:
<i>ntfsresize</i> originated as part of the <i>ntfsprogs</i> project, which aimed to provide userspace utilities for NTFS on Linux. This project was later largely integrated into and superseded by <i>ntfs-3g</i>, a more robust and actively developed driver and suite of tools providing full read-write support for NTFS. <i>ntfsresize</i> is now commonly bundled with <i>ntfs-3g</i> and is maintained as a critical component for managing NTFS partitions in a Linux environment. Its development has focused on ensuring data integrity and compatibility with various Windows NTFS versions.


title: SYNOPSIS
content:
<b>ntfsundelete</b> [OPTIONS] <device><br><b>ntfsundelete</b> -p [OPTIONS] <device><br><b>ntfsundelete</b> -u <inode_number> [OPTIONS] <device>


title: PARAMETERS
content:
<b>-p, --progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preview mode; list deleted files without attempting recovery. Shows information about deleted files like inode number, size, and deletion time.<br><br><b>-u, --undelete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undelete a specific file identified by its inode number. This option must be used with <b>-i</b> or directly specify the inode after <b>-u</b>.<br><br><b>-i <inode_number>, --inode <inode_number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the inode number of the file to be undeleted. This is typically found using the <b>-p</b> (preview) option.<br><br><b>-d <directory>, --dest <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination directory where recovered files will be written. If not specified, files are recovered to the current working directory.<br><br><b>-s <pattern>, --search <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for deleted files whose names match the given pattern. The pattern can include wildcards like <i>*</i> and <i>?</i>.<br><br><b>-t <time>, --time <time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter results by deletion time. Time can be a specific date/time (e.g., YYYY-MM-DD HH:MM:SS) or relative (e.g., -24h for last 24 hours).<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force operations, potentially overriding safety checks. Use with caution.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the process.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>ntfsundelete</i> is a command-line utility designed to assist in the recovery of deleted files from NTFS (New Technology File System) partitions. It is part of the <i>ntfs-3g</i> suite of tools, which provides robust read/write support for NTFS filesystems on Linux. The command works by scanning the NTFS change journal and the Master File Table (MFT) for entries corresponding to files that have been marked as deleted but whose data blocks may still be intact.<br><br>While it offers a valuable chance at data recovery, its success heavily depends on whether the disk blocks occupied by the deleted file's data have been overwritten by new data. For optimal recovery chances, the partition should ideally be unmounted or mounted read-only before attempting recovery.


title: CAVEATS
content:
<b><I>Data Overwrite Risk:</I></b> The most significant limitation is that file recovery is only possible if the data blocks of the deleted file have not been overwritten by new data. Continuous use of the filesystem after deletion significantly reduces recovery chances.<br><b><I>Filesystem State:</I></b> For best results, the NTFS partition should be unmounted or mounted read-only before attempting recovery. Mounting it read/write can lead to further data corruption or overwriting.<br><b><I>Partial Recovery:</I></b> Even if a file's inode is found, it might be possible to recover only a part of the file if some of its data blocks have been reused.<br><b><I>No Guarantee:</I></b> <i>ntfsundelete</i> is a best-effort tool and does not guarantee successful recovery of all deleted files.<br><b><I>Permissions:</I></b> The command often requires root privileges to access the raw device.


title: HOW IT WORKS
content:
<i>ntfsundelete</i> operates by scanning the Master File Table (MFT) for records of deleted files. When a file is deleted on NTFS, its MFT entry is marked as unused, but the data clusters themselves might remain untouched until new data is written over them. The command tries to reconstruct the file's metadata (name, size, cluster allocation) and then read the data from the identified clusters.


title: TYPICAL USAGE FLOW
content:
A typical usage involves first using the <b>-p</b> (preview) option to list potential deleted files and identify their inode numbers. Once the desired file's inode is known, the <b>-u</b> (undelete) option is then used with the inode number to recover the file to a specified destination directory, preferably on a different partition to avoid overwriting the source.


title: HISTORY
content:
<i>ntfsundelete</i> is part of the <i>ntfsprogs</i> suite (now largely integrated into the <i>ntfs-3g</i> project for user-space tools and kernel driver). The development of <i>ntfsprogs</i> began in the early 2000s to provide robust Linux support for Microsoft's NTFS filesystem, which was becoming increasingly prevalent. <i>ntfsundelete</i> specifically addresses the critical need for data recovery on these partitions, leveraging the structure of NTFS's MFT and change journal. Its existence significantly enhanced the practical usability of NTFS partitions within the Linux environment, reducing reliance on Windows-specific recovery tools.


title: SYNOPSIS
content:
The <i>ntfy</i> command-line client provides modes for publishing, subscribing, and listening.<br><br><code>ntfy [<i>OPTIONS</i>] &lt;<i>TOPIC</i>&gt; [<i>MESSAGE</i>]</code><br><i>(Default to publish mode)</i><br><br><code>ntfy <B>publish</B> [<i>OPTIONS</i>] &lt;<i>TOPIC</i>&gt; [<i>MESSAGE</i>]</code><br><i>(Explicitly publish a message)</i><br><br><code>ntfy <B>subscribe</B> [<i>OPTIONS</i>] &lt;<i>TOPIC</i>&gt;</code><br><i>(Subscribe to a topic and receive messages)</i><br><br><code>ntfy <B>listen</B> [<i>OPTIONS</i>]</code><br><i>(Listen to all messages on a server)</i>


title: PARAMETERS
content:
<b><code>-t</code>, <code>--topic &lt;TOPIC&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <B>topic</B> to publish to or subscribe from. Topics are case-sensitive.<br><br><b><code>-m</code>, <code>--message &lt;MESSAGE&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The message body for a publication. If omitted, <i>ntfy</i> reads from <i>stdin</i>.<br><br><b><code>-T</code>, <code>--title &lt;TITLE&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom <B>title</B> for the notification.<br><br><b><code>-p</code>, <code>--priority &lt;LEVEL&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the notification <B>priority</B> from 1 (min) to 5 (max). Higher priority notifications may alert users more prominently.<br><br><b><code>-g</code>, <code>--tag &lt;TAG&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <B>tags</B> to the notification for filtering or grouping. Can be specified multiple times.<br><br><b><code>-a</code>, <code>--attach &lt;FILE_PATH&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a <B>file</B> to the notification. The file content is base64 encoded and sent along with the message.<br><br><b><code>--filename &lt;NAME&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <B>filename</B> for the attached file, overriding the original filename.<br><br><b><code>--json &lt;JSON&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes a message using <B>raw JSON</B> payload, allowing for advanced message customization.<br><br><b><code>-s</code>, <code>--server &lt;URL&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <B>ntfy server URL</B> to use (e.g., <code>https://ntfy.sh</code>).<br><br><b><code>-u</code>, <code>--user &lt;USER&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the <B>username</B> for basic HTTP authentication.<br><br><b><code>-P</code>, <code>--password &lt;PASS&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the <B>password</B> for basic HTTP authentication.<br><br><b><code>-A</code>, <code>--auth &lt;TOKEN&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a <B>bearer token</B> for authentication.<br><br><b><code>--config &lt;PATH&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom <B>configuration file</B> path.<br><br><b><code>--since &lt;TIME|ID&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For subscriptions, receive messages <B>since a specific time</B> (e.g., <code>1h</code>, <code>2023-01-01</code>) or message ID.<br><br>


title: DESCRIPTION
content:
<i>ntfy</i> is a simple <B>HTTP-based publish-subscribe notification service</B>. It allows you to send push notifications to any device via a command-line interface or a web UI. It supports various platforms including Android, iOS, and web browsers, without requiring an account or exposing your private information. You can use a public server or <B>self-host your own</B>. It's ideal for scripting, monitoring, and general alerting, providing a robust and easy-to-use notification solution.


title: CAVEATS
content:
The <i>ntfy</i> command-line client requires an <B>ntfy server</B> to operate, either a publicly available instance or a self-hosted one. Public servers may enforce <B>rate limits</B> and have <B>data retention policies</B>. While designed for security, sensitive information should still be handled with care, especially when using public servers. Notifications might be subject to network latency and reliability depends on the server's uptime.


title: <B>AUTHENTICATION</B>
content:
<i>ntfy</i> supports various authentication methods including basic HTTP authentication (using <code>--user</code> and <code>--password</code>) and <B>bearer tokens</B> (with <code>--auth</code>). This allows securing topics and controlling who can publish or subscribe to messages on your <i>ntfy</i> server.


title: <B>SELF-HOSTING</B>
content:
One of <i>ntfy</i>'s core strengths is the ease of <B>self-hosting your own server</B>. This provides complete control over your notifications, data, and privacy, making it particularly suitable for sensitive internal alerts or environments with strict data governance policies.


title: <B>INTEGRATION</B>
content:
<i>ntfy</i> is designed for <B>easy integration</B> into scripts and applications. Its simple HTTP API and intuitive command-line interface make it an ideal choice for sending alerts from cron jobs, CI/CD pipelines, monitoring systems, or custom applications. It facilitates robust notification capabilities with minimal setup overhead.


title: HISTORY
content:
<i>ntfy</i> was created by <B>Philipp C. Heckel</B> and released as an open-source project. It quickly gained traction as a simple, privacy-friendly, and <B>self-hostable notification solution</B>, offering an alternative to more complex or proprietary services. Its development is active on GitHub, continuously adding features and improving reliability, making it a popular choice for developers and system administrators seeking a straightforward way to send push notifications.


title: SYNOPSIS
content:
ntfyme [OPTIONS] <TOPIC> [MESSAGE]<br>ntfyme [OPTIONS] send <TOPIC> [MESSAGE]<br>ntfyme [OPTIONS] listen <TOPIC><br>ntfyme [OPTIONS] shell


title: PARAMETERS
content:
<b><TOPIC></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target topic to which the message will be published or from which messages will be listened.<br><br><b>[MESSAGE]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The content of the notification message. If omitted, ntfyme will read from standard input.<br><br><b>-t, --title <title></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the title of the notification message.<br><br><b>-p, --priority <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the priority of the notification. Common levels include 'min', 'low', 'default', 'high', 'urgent'.<br><br><b>-s, --tag <tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds one or more tags to the notification (comma-separated for multiple tags). Tags can be used for filtering.<br><br><b>-c, --click <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a URL that will be opened when the notification is clicked.<br><br><b>-x, --attach <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a file to the notification. The file will be uploaded to the ntfy.sh server and a download link included.<br><br><b>-a, --action <label:url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an actionable button to the notification, allowing users to perform an action (e.g., open a URL) directly from the notification.<br><br><b>-b, --base-url <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default ntfy.sh server URL, useful for self-hosted instances.<br><br><b>-u, --user <user>[:<pass>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies credentials for authenticating with the ntfy.sh server.<br><br><b>--firebase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Firebase Cloud Messaging (FCM) push, ensuring reliable delivery to Android and iOS devices.<br><br><b>--browser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the ntfy.sh topic page in the default web browser after sending a message.<br><br>


title: DESCRIPTION
content:
ntfyme is a command-line client for the <I>ntfy.sh</I> push notification service, providing a simple yet powerful way to send instant alerts from your Linux terminal, scripts, or automated tasks. It allows users to publish messages to specific 'topics' hosted on an <I>ntfy.sh</I> server, which are then immediately delivered to subscribed devices like smartphones or desktops. This makes it an ideal tool for monitoring long-running processes, build statuses, system events, or any situation requiring timely notifications without complex configurations.<br><br>The client supports a rich set of features, including setting message titles, priorities (e.g., urgent, high, default), adding tags for filtering, and embedding clickable URLs. It can also attach files or define actionable buttons that users can tap directly from the notification. Beyond sending messages, <I>ntfyme</I> can also act as a subscriber, listening to topics and displaying incoming notifications directly in the terminal, useful for debugging or monitoring server-side events. Its flexibility and ease of integration make <I>ntfyme</I> a popular choice for developers, system administrators, and anyone needing a quick and reliable notification mechanism.


title: CAVEATS
content:
Requires connection to an <I>ntfy.sh</I> server (public or self-hosted).<br>Notifications are dependent on network connectivity.<br>For private or sensitive topics, it's crucial to use unique, unguessable topic names and/or authentication, as topic names are public by default on shared servers.<br><I>ntfyme</I> is a client application; it does not host the notification service itself.


title: CONFIGURATION
content:
<I>ntfyme</I> can be configured via environment variables (e.g., <B>NTFY_TOPIC</B>, <B>NTFY_BASE_URL</B>, <B>NTFY_USER</B>, <B>NTFY_PASS</B>) or a configuration file, typically located at <I>~/.config/ntfy/config.yml</I>. This allows for persistent settings and credentials without specifying them on the command line every time.


title: TOPICS AND SECURITY
content:
Notifications are sent to specific <I>topics</I> which are essentially simple labels or paths on the <I>ntfy.sh</I> server. While simple, it's important to note that anyone knowing a topic name can publish to or subscribe from it on a public server. Therefore, using long, random, or authenticated topic names is highly recommended for sensitive information or private alerts.


title: SELF-HOSTING
content:
For complete control over data privacy and security, the <I>ntfy.sh</I> server software is open-source and can be self-hosted on a private server. This provides the same functionality as the public service but within a user's own infrastructure, ideal for enterprise environments or strict privacy requirements.


title: HISTORY
content:
The <I>ntfy.sh</I> project, including its command-line client <I>ntfyme</I>, was created by Philipp C. Heckel. It emerged as a modern, lightweight, and open-source alternative to more complex push notification solutions, aiming to simplify sending alerts from scripts and servers. Its development began around 2021, and it quickly gained traction due to its ease of use, HTTP-based API, and the availability of a free public server. The project continues to be actively developed on GitHub, with ongoing improvements and new features being added by its community.


title: SYNOPSIS
content:
As "nth" is not a standard command, there is <I>no defined synopsis</I> for it. Operations typically implied by 'nth' are achieved through complex piping and combination of standard Linux commands.


title: DESCRIPTION
content:
The command "nth" is <I>not a standard or recognized standalone utility</I> in most common Linux and Unix-like operating systems. When users refer to the 'nth' item, line, or occurrence, they typically mean using existing powerful text processing utilities to extract or manipulate data based on its numerical position. Common methods involve combining commands such as <B>head</B>, <B>tail</B>, <B>sed</B>, <B>awk</B>, <B>cut</B>, and <B>sort</B> to achieve the desired 'n-th' functionality. For instance, getting the 5th line of a file, the 3rd word on a line, or the 2nd occurrence of a pattern are all 'nth' operations performed by these other tools, rather than a single 'nth' command.


title: CAVEATS
content:
It is crucial to understand that "nth" as a direct command does not exist. Attempting to execute "nth" will result in a '<I>command not found</I>' error. Users should clarify what specific 'n-th' operation they intend to perform (e.g., n-th line, n-th field, n-th occurrence) and then seek the appropriate combination of standard Linux text processing utilities.


title: COMMON 'NTH' OPERATIONS AND HOW TO ACHIEVE THEM
content:
1. <B>Get the Nth line of a file:</B><br>  Use <B>sed</B>: <I>sed -n 'N p' filename</I><br>  Use <B>awk</B>: <I>awk 'NR == N' filename</I><br>  Use <B>head</B> and <B>tail</B> (less efficient for large N): <I>head -n N filename | tail -n 1</I><br><br>2. <B>Get the Nth word/field on a line:</B><br>  Use <B>awk</B>: <I>echo "line with words" | awk '{print $N}'</I><br>  Use <B>cut</B>: <I>echo "line with fields" | cut -d'DELIMITER' -f N</I><br><br>3. <B>Get the Nth match of a pattern:</B><br>  This often involves piping <B>grep</B> with <B>head</B> or <B>sed</B>:<br>  <I>grep 'pattern' filename | head -n N | tail -n 1</I><br>  For a more efficient Nth match using <B>awk</B>:<br>  <I>awk '/pattern/{count++; if (count == N) {print; exit}}' filename</I>


title: HISTORY
content:
There is <I>no history</I> or development lineage for a standard "nth" command because it is not a recognized part of core Unix/Linux utilities. The concept of addressing 'n-th' elements has always been handled by the flexible and composable design of Unix tools, allowing users to build solutions for specific 'n-th' requirements.


title: SYNOPSIS
content:
<I>N/A - Command not found</I><br>As <b>ntl</b> is not a standard executable, a general synopsis cannot be provided. If it exists in your environment, its synopsis would depend entirely on its custom implementation.


title: DESCRIPTION
content:
The command <b>ntl</b> is <I>not a standard or commonly recognized utility</I> across most mainstream Linux distributions. Unlike commands such as <b>ls</b>, <b>grep</b>, or <b>cd</b>, there is no official man page, widely known functionality, or established purpose associated with a direct <b>ntl</b> executable in typical system environments. Its absence from standard utility sets, POSIX specifications, and common software repositories indicates it is not a part of the fundamental Linux command-line toolkit.<br><br>It is highly probable that <b>ntl</b> refers to a <I>typo</I> (e.g., for <b>ntp</b>, <b>netstat</b>, <b>nmap</b>, or <b>ntlm_auth</b>), a <I>custom-defined alias</I>, a <I>shell script</I> specific to a particular user's environment, or a <I>component of a very niche or proprietary software package</I> that is not generally installed or documented. Therefore, without specific contextual information, it is impossible to provide accurate details regarding its intended use, options, or behavior. Users encountering this command should verify its source and purpose within their specific system context, as its existence and functionality would be entirely bespoke.


title: CAVEATS
content:
Attempting to execute <b>ntl</b> on most Linux systems will result in a <I>"command not found"</I> error, indicating that the shell cannot locate a program with that name in the system's PATH. <br>Even if a program named <b>ntl</b> exists in a specific environment, its behavior and security implications would be entirely dependent on its custom implementation and should be investigated carefully before execution.


title: POSSIBLE EXPLANATIONS
content:
If you encountered <b>ntl</b>, consider the following:<br>1. <I>Typo</I>: The most common reason. Double-check the command name you intended.<br>2. <I>Custom Script/Alias</I>: Your system or a user might have created a custom script or alias named <b>ntl</b>.<br>3. <I>Proprietary Software</I>: It could be a command from a specific, less common software package not widely distributed.<br>4. <I>Library Reference</I>: Sometimes 'ntl' refers to the <I>NTL (Number Theory Library)</I> C++ library, but this is not a direct command-line executable and has no direct shell command equivalent.


title: HISTORY
content:
There is <I>no documented history</I> for a standard <b>ntl</b> Linux command. It does not appear in historical Unix releases, POSIX standards, or common GNU/Linux utility sets. Any usage of <b>ntl</b> likely stems from custom development, specific niche applications, or common typos.


title: SEE ALSO
content:
<I>ntp(8)</I> - Network Time Protocol daemon/utility (commonly confused typo), <I>netstat(8)</I> - Print network connections, routing tables, interface statistics, etc. (another common typo source), <I>ntlm_auth(1)</I> - Samba utility for NTLM authentication (shares 'ntl' substring, but different command)


title: SYNOPSIS
content:
<b>ntopng</b> [<I>options</I>]<br><br>Common usage examples:<br><b>ntopng -i <I>eth0</I> -w <I>3000</I></b><br><b>ntopng -r <I>capture.pcap</I></b>


title: PARAMETERS
content:
<b><I>-i <interface_or_file></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface(s) to monitor (e.g., <i>eth0</i>, <i>bond0</i>) or a PCAP file to read traffic from (e.g., <i>/path/to/capture.pcap</i>). Can be specified multiple times.<br><br><b><I>-w <port></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the HTTP web server port for accessing the <i>ntopng</i> interface (default: 3000). Use <i>0</i> to disable the web server.<br><br><b><I>-L</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables logging to syslog instead of standard output.<br><br><b><I>-d <path></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the data directory where <i>ntopng</i> stores its internal files and RRD historical data.<br><br><b><I>-u <user></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops privileges and runs <i>ntopng</i> as the specified user after initialization.<br><br><b><I>-g <group></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drops privileges and runs <i>ntopng</i> as the specified group after initialization.<br><br><b><I>-A</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts for setting up an administrator password for the web interface, securing access.<br><br><b><I>-F <filter></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a BPF (Berkeley Packet Filter) capture filter to limit the collected traffic.<br><br><b><I>-q</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing output to standard output.<br><br><b><I>-v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, providing more detailed logging output.<br><br><b><I>-Z</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the creation and storage of historical data, reducing disk I/O.<br><br>


title: DESCRIPTION
content:
<i>ntop</i> (Network TOP) is a command-line tool that acts as a network probe, providing a web-based interface for monitoring and analyzing network traffic. It is designed to show network usage in a way similar to how the <b>top</b> command shows CPU usage.<br><br>While the original <i>ntop</i> has been around for many years, its modern successor, <i>ntopng</i> (ntop Next Generation), is the actively maintained and recommended version. <i>ntopng</i> offers improved performance, scalability, and features, leveraging technologies like Redis for data storage.<br><br>It captures network traffic from specified interfaces, organizes it, and presents detailed statistics on network bandwidth utilization, active hosts, top talkers, protocols used, and overall network health. This allows administrators to identify network bottlenecks, detect abnormal behavior, and understand network flow patterns through a user-friendly web browser interface.


title: CAVEATS
content:
<b>ntopng</b>, the modern successor to <b>ntop</b>, is the recommended version to use. The original <b>ntop</b> is largely deprecated and may not be actively maintained.<br><br>Running <b>ntopng</b> typically requires root privileges to capture network traffic from interfaces, though it's recommended to drop privileges using the <i>-u</i> and <i>-g</i> options once initialization is complete.<br><br>On high-traffic networks, <b>ntopng</b> can consume significant system resources (CPU, memory, disk I/O) due to extensive data processing and storage. Ensure adequate resources are available.


title: WEB INTERFACE-CENTRIC OPERATION
content:
Unlike many other Linux network tools that operate directly in the terminal, <b>ntop</b> and <b>ntopng</b> primarily expose their functionality and collected data through a powerful web-based interface. Users interact with the tool and view statistics by navigating to its configured IP address and port in a web browser (e.g., <i>http://localhost:3000</i>).


title: RICH DATA & PROTOCOL SUPPORT
content:
<b>ntopng</b> provides extensive information about network traffic, including detailed statistics per host, protocol (e.g., HTTP, DNS, SSL), and application layer. It identifies top talkers, monitors bandwidth usage in real-time, tracks flow information, and offers historical data for trend analysis.


title: PLUGIN ARCHITECTURE
content:
<b>ntopng</b> features a flexible plugin architecture that allows for extending its capabilities, such as integrating with external services or adding support for new protocols and data sources.


title: HISTORY
content:
The original <b>ntop</b> project was started by Luca Deri in 1998 at the University of Pisa, aiming to provide a 'top' like view for network traffic. It quickly gained popularity for its ability to offer insights into network usage.<br><br>Recognizing the limitations and challenges of the original C-based architecture, especially with increasing network speeds and data volumes, Luca Deri initiated the <b>ntopng</b> (ntop Next Generation) project. Released in 2012, <b>ntopng</b> was a complete rewrite in C++ and Lua, leveraging modern technologies like Redis for persistent data storage and a more scalable design. <b>ntopng</b> superseded the original <b>ntop</b> and is now the actively developed and widely used version.


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short, important summary of the synchronization status. This option is useful for quick checks and scripting.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output. This provides more detailed information about the daemon's operation and status, aiding in debugging.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current synchronization status, including peer information, stratum, clock offset, and polling intervals.<br><br><b><b>monitor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a continuous, real-time update of the synchronization status, typically refreshing every few seconds. Similar to running 'ntpctl -s' repeatedly in a loop.<br><br><b><b>set hipe (on|off)</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable High Precision Event Timer (HIPE) support. HIPE leverages high-resolution timers in modern hardware for more precise timekeeping. This can improve time synchronization accuracy.<br><br><b><b>set rts (on|off)</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable Real-Time Scheduling (RTS) support. RTS can provide more consistent time synchronization by giving <i>OpenNTPD</i> higher scheduling priority, reducing latency and jitter.<br><br>


title: DESCRIPTION
content:
<i>ntpctl</i> is a utility designed to query and control the <i>OpenNTPD</i> daemon, which is OpenBSD's secure and lightweight Network Time Protocol implementation. It allows administrators to check the current synchronization status of the system clock, including which remote peer the daemon is currently synchronized with, the stratum level, the clock's estimated offset from the peer, and details about the clock's accuracy and adjustments. Beyond status monitoring, <i>ntpctl</i> can also be used to modify certain operational parameters of <i>OpenNTPD</i>, such as enabling or disabling High Precision Event Timer (HIPE) and Real-Time Scheduling (RTS) features, which can significantly impact time synchronization performance and precision. It provides both a static, point-in-time status report and a dynamic, real-time monitoring view, making it an indispensable tool for managing time synchronization on systems running <i>OpenNTPD</i>.


title: CAVEATS
content:
<i>ntpctl</i> is specifically designed for and works only with the <i>OpenNTPD</i> daemon. It is not compatible with the <i>ntpd</i> daemon from the NTPsec or legacy NTP project, which uses <i>ntpq</i> for control and querying. Users should ensure they are running <i>OpenNTPD</i> if they intend to use <i>ntpctl</i>.


title: HIPE AND RTS FEATURES
content:
<b>HIPE</b> (High Precision Event Timer) and <b>RTS</b> (Real-Time Scheduling) are advanced features that can be enabled or disabled via <i>ntpctl</i>.<br><br><b>HIPE</b> leverages high-resolution timers in modern hardware for more precise timekeeping. It is crucial for achieving optimal synchronization accuracy, especially on systems with suitable hardware.<br><br><b>RTS</b> allows the <i>OpenNTPD</i> process to run with elevated priority, reducing latency and jitter in time synchronization updates, especially on busy systems where other processes might compete for CPU time. Enabling these features typically requires appropriate system capabilities and root privileges for <i>ntpctl</i> to modify the daemon's runtime configuration.


title: HISTORY
content:
<i>ntpctl</i> was developed as part of the <i>OpenNTPD</i> project, which originated from OpenBSD. <i>OpenNTPD</i> aims to provide a simpler, more secure, and robust NTP implementation compared to the traditional NTP daemon. <i>ntpctl</i> was created to be the dedicated command-line interface for <i>OpenNTPD</i>, providing a straightforward way to manage its operation and observe its synchronization state. Its development parallels the evolution of <i>OpenNTPD</i> itself, with a focus on clarity and essential functionality.


title: SYNOPSIS
content:
<b>ntpd</b> [<i>options</i>]<br><b>ntpd</b> [<i>-c config_file</i>] [<i>-f drift_file</i>] [<i>-gq</i>] [<i>-d</i>]


title: PARAMETERS
content:
<b>-c <config_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate NTP configuration file path instead of the default <i>/etc/ntp.conf</i>.<br><br><b>-f <drift_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate NTP drift file path to store clock frequency offset.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs an initial clock synchronization, even if the offset is large, then exits if <i>-q</i> is also specified.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries servers and sets the time, then exits. Useful for one-time synchronization.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging mode. Output is sent to standard error, and the daemon does not fork.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>ntpd</b> from forking into the background. It runs in the foreground.<br><br><b>-u <user>[:group]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user and optional group to which <b>ntpd</b> should switch after initialization for security.<br><br>


title: DESCRIPTION
content:
<b>ntpd</b> is the reference implementation of the Network Time Protocol (NTP), a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.<br>It runs as a daemon, continuously adjusting the system clock to synchronize with remote NTP servers, ensuring highly accurate timekeeping.<br><br>Accurate system time is critical for a multitude of reasons, including correct logging, secure authentication (e.g., Kerberos), data consistency in distributed systems, and proper functioning of cron jobs and certificate validation. <b>ntpd</b> achieves this by using complex algorithms to select the best time sources, minimize network latency effects (jitter), and precisely compensate for local clock drift.<br><br>Typically, <b>ntpd</b> is configured via the <i>/etc/ntp.conf</i> file, which specifies NTP servers, access restrictions, and logging options. It can operate in various modes: as a client requesting time from servers, as a server providing time to clients, or as both. It can also manage a local clock source (e.g., GPS receiver) and operate in a peer-to-peer fashion. <b>ntpd</b> is fundamental for maintaining time accuracy across networks, from small local area networks to the global internet.


