# CommandSection

title: CAVEATS
content:
1. <b>Root Privileges:</b> Performing SYN scans (default) requires root or sudo privileges due to direct raw packet manipulation.<br>2. <b>Network Impact:</b> Its high speed can generate significant network traffic, potentially causing congestion or triggering intrusion detection/prevention systems (IDS/IPS).<br>3. <b>Firewall Interference:</b> Local firewalls on the scanning machine might interfere with raw packet sending or receiving, leading to inaccurate results unless properly configured.<br>4. <b>False Positives/Negatives:</b> While efficient, network instability, target misconfiguration, or aggressive rate limits can lead to occasional false positives or negatives.


title: INTEGRATION WITH PROJECTDISCOVERY TOOLS
content:
Naabu's design facilitates easy piping of its output to other ProjectDiscovery tools. For instance, the output (list of host:port) can be directly fed into <i>httpx</i> for HTTP service detection or <i>nuclei</i> for template-based vulnerability scanning, creating a powerful automated reconnaissance chain.


title: PERFORMANCE AND RESOURCE USAGE
content:
Thanks to its raw packet engine and Go's concurrency model, Naabu is incredibly fast and memory-efficient. It can scan millions of IPs in minutes using relatively few resources, making it suitable for both local system usage and cloud-based scanning infrastructure.


title: HISTORY
content:
Naabu is an integral part of the <B>ProjectDiscovery</B> open-source ecosystem, a suite of tools focused on simplifying and enhancing the reconnaissance phase for security researchers and bug bounty hunters. Developed primarily in Go, Naabu was designed to overcome the performance limitations of traditional port scanners when dealing with large IP ranges and extensive port lists. Its development emphasizes raw performance, minimal resource usage, and seamless integration with other ProjectDiscovery tools like <i>httpx</i> and <i>nuclei</i>, making it a cornerstone for automated security workflows.


title: SYNOPSIS
content:
<b>nala</b> [<i>options</i>] <i>command</i> [<i>arguments</i>]<br><b>nala update</b><br><b>nala upgrade</b><br><b>nala install</b> [<i>package(s)</i>]<br><b>nala remove</b> [<i>package(s)</i>]<br><b>nala autoremove</b><br><b>nala search</b> [<i>keyword</i>]<br><b>nala show</b> [<i>package</i>]


title: PARAMETERS
content:
<b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refreshes the list of available packages and their versions from repositories.<br><br><b>upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs the newest versions of all currently installed packages.<br><br><b>install <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs one or more specified packages.<br><br><b>remove <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more specified packages.<br><br><b>autoremove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes packages that were automatically installed to satisfy dependencies for other packages and are no longer needed.<br><br><b>search <keyword></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages matching a given keyword in the available package lists.<br><br><b>show <package></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specified package.<br><br><b>purge <package(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more specified packages along with their configuration files.<br><br><b>history</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a log of previous <b>nala</b> transactions, allowing rollback or inspection.<br><br><b>fetch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads packages into the local cache without installing them.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases downloaded archive files from the local repository cache.<br><br><b>-y, --assume-yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatic 'yes' to prompts; bypasses confirmation requests.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, showing more detailed output during operations.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates an operation without making any actual changes to the system.<br><br><b>--no-install-recommends</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the installation of 'recommended' packages during installation or upgrade.<br><br><b>--fix-broken</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to correct a system where broken dependencies prevent further package operations.<br><br>


title: DESCRIPTION
content:
<b>nala</b> is an intuitive and performance-focused frontend for the <b>APT</b> (Advanced Package Tool) package manager on Debian-based Linux distributions. It aims to provide a more user-friendly and visually appealing experience compared to the standard `apt` command. Key features include parallel package downloading, which significantly speeds up operations by utilizing multiple concurrent connections, and enhanced output with progress bars, colors, and clearer information. Inspired by package managers like <b>dnf</b> and <b>pacman</b>, <b>nala</b> offers a cleaner interface and improved feedback during package installations, updates, and removals, making system maintenance more efficient and enjoyable for users. It essentially wraps `apt` commands, adding a layer of convenience and speed.


title: CAVEATS
content:
<b>nala</b> is a frontend for <b>apt</b>; it requires <b>apt</b> to be installed and functional. While it enhances speed with parallel downloads, this can consume more network bandwidth. It's not part of the standard core utilities in all Debian-based distributions and needs to be installed separately. In very rare cases, the parallel download mechanism might interact differently with specific proxy configurations or highly restrictive network environments compared to <b>apt</b>.


title: PARALLEL DOWNLOADS
content:
<b>nala</b> significantly enhances download speeds by employing <i>parallel connections</i> to fetch packages from repositories concurrently. This mechanism leverages `libcurl` to initiate multiple downloads simultaneously, drastically reducing the time spent waiting for package archives, especially when installing or updating numerous packages. This feature is a key differentiator from the standard `apt` command.


title: ENHANCED USER EXPERIENCE
content:
Beyond speed, <b>nala</b> focuses on a superior user experience. It provides <i>colored output</i>, <i>progress bars</i>, and clearer, more organized information during package operations. This visual feedback makes it easier to understand what's happening, track progress, and quickly identify potential issues, transforming the typically text-heavy `apt` interaction into a more intuitive and visually engaging process.


title: HISTORY
content:
<b>nala</b> was developed by the Volian project, known for its focus on a user-friendly and modern Linux experience. It emerged as a response to the desire for a more interactive and visually appealing package manager frontend for Debian/Ubuntu systems, drawing inspiration from the user interfaces of <b>dnf</b> (Fedora/RHEL) and <b>pacman</b> (Arch Linux). Its primary goal was to improve the user experience of <b>apt</b> by adding features like colored output, progress bars, and significantly faster parallel downloads, making system management more efficient and pleasant. The development began in recent years (post-2020), quickly gaining traction among users seeking a better <b>apt</b> alternative.


title: SYNOPSIS
content:
<b>namcap</b> [<i>options</i>] &lt;<i>package_file</i>|<i>PKGBUILD_path</i>|<i>directory</i>|<i>installed_package_name</i>><br><br>Examples:<br><b>namcap</b> <i>PKGBUILD</i><br><b>namcap</b> <i>my-package-1.0-1-x86_64.pkg.tar.xz</i><br><b>namcap</b> <b>-i</b> <i>bash</i>


title: PARAMETERS
content:
<b><b>-i</b>, <b>--installed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks an already installed package by name instead of a file path.<br><br><b><b>-s</b>, <b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables strict checking, which may report more potential issues.<br><br><b><b>-w</b> <i>N</i>, <b>--warn-level=</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the warning level (0-10). 0 shows errors only, 10 shows all warnings. Default is 5.<br><br><b><b>--enable=</b><i>CHECK</i>[,<i>CHECK</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables specific checks by their ID. Can be used multiple times to activate various categories of checks.<br><br><b><b>--disable=</b><i>CHECK</i>[,<i>CHECK</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables specific checks by their ID. Useful for known exceptions or to reduce noise.<br><br><b><b>--ignore=</b><i>ERROR</i>[,<i>ERROR</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores specific error/warning messages by their ID, preventing them from being reported.<br><br><b><b>--check-dependencies</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly enables or reinforces dependency checks, ensuring all required libraries and packages are listed.<br><br><b><b>--check-for-stripped-binaries</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if executable binaries and shared libraries are properly stripped to remove debugging symbols, reducing package size.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and exits.<br><br>


title: DESCRIPTION
content:
<i>namcap</i> is a powerful and specialized linting tool primarily used within the Arch Linux ecosystem to <i>analyze packages for common errors and inconsistencies</i>. It operates on `PKGBUILD` files, built `.pkg.tar.xz` package files, or even already <i>installed packages</i>. Its main purpose is to help package maintainers and developers ensure their packages adhere to Arch Linux packaging standards and best practices.<br><br>The tool performs a variety of checks, including but not limited to: verifying dependencies, checking file permissions and ownership, detecting unstripped binaries, identifying missing or incorrect licenses, and flagging issues related to `PKGBUILD` syntax or deprecated functions. By automating these checks, `namcap` significantly aids in maintaining the <i>quality, security, and stability</i> of packages distributed through the official repositories and the Arch User Repository (AUR). Its name, "namcap," is a playful reversal of "pacman," Arch Linux's package manager, highlighting its close relationship to the system's packaging workflow.


title: CAVEATS
content:
`namcap` is primarily designed for the Arch Linux packaging environment. While it provides valuable insights, not every warning it generates indicates a critical error; some might be intentional design choices by the package maintainer. It is a diagnostic tool and <i>does not automatically fix</i> any reported issues; maintainers must manually address them. Running `namcap` effectively often requires the full package environment (e.g., a chroot) to properly detect all potential issues, especially regarding dependencies and file paths.


title: CHECKS PERFORMED
content:
<i>namcap</i> performs a wide array of checks, categorizing them into errors, warnings, and informational messages. These include:<br><ul><li><b>Dependency Checks</b>: Ensuring all required runtime and build-time dependencies are correctly specified.</li><li><b>File System Checks</b>: Verifying correct file permissions, ownership, and the absence of empty directories or problematic dot files.</li><li><b>Binary Checks</b>: Detecting unstripped binaries, which can unnecessarily increase package size.</li><li><b>PKGBUILD Specific Checks</b>: Analyzing the `PKGBUILD` script for deprecated functions, common syntax errors, or non-standard practices.</li><li><b>Licensing Checks</b>: Ensuring licenses are properly specified and included.</li><li><b>Source Checks</b>: Flagging instances where unpacked source files are left in the installed package.</li></ul>


title: CUSTOM CHECKS
content:
<i>namcap</i> provides extensibility by allowing users to define and integrate their own custom checks. These checks can be written as scripts and loaded via the <b>--add-check</b> or <b>--add-check-file</b> options, enabling maintainers to enforce project-specific conventions or perform highly specialized analyses beyond the default capabilities. This feature makes `namcap` a flexible tool for custom packaging workflows.


title: HISTORY
content:
`namcap` was conceived and developed specifically for the Arch Linux distribution. Its name is a clever anagram of "pacman," Arch Linux's highly regarded package manager, signifying its role as a complementary tool. The development of `namcap` has been driven by the need to maintain high standards of package quality, consistency, and adherence to the Arch Linux Packaging Guidelines. It has evolved over time, incorporating new checks and adapting to changes in the Arch Linux packaging ecosystem, becoming an indispensable utility for package maintainers and developers to ensure the integrity and stability of the Arch Linux software repositories and the Arch User Repository (AUR).


title: PARAMETERS
content:
<b>-c <I>config-file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the configuration file, overriding the default <b>/etc/named.conf</b>.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>named</b> in the foreground, useful for debugging. Logging will typically go to stderr.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Equivalent to <b>-f</b>, but also sends all log messages to stderr. This option implies <b>-f</b>.<br><br><b>-m <I>memory-debugging-options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables memory usage debugging. Options include 'stats', 'trace', 'full', 'record', etc., or 'no'.<br><br><b>-p <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port on which <b>named</b> should listen for queries, overriding the default port 53.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes log messages to syslog. This option is largely deprecated as syslog logging is often the default behavior or configured directly in <b>named.conf</b>.<br><br><b>-t <I>chrootdir</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the root directory of the server process to <I>chrootdir</I> after startup. This enhances security by limiting file system access.<br><br><b>-u <I>user</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>named</b> as the specified <I>user</I> and group after startup, improving security by dropping root privileges.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of <b>named</b> to standard output and exits.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose version information, including build options and libraries used, to standard output and exits.<br><br>


title: DESCRIPTION
content:
The <b>named</b> (Name Domain) daemon is the core component of the <I>Berkeley Internet Name Domain</I> (BIND) system, serving as the primary DNS (Domain Name System) server program. Its fundamental role is to translate human-readable domain names (like example.com) into machine-readable IP addresses (like 192.0.2.1) and vice-versa, which is crucial for internet communication.<br><br><b>named</b> listens for DNS queries, resolves them by looking up information in its configured zone files, or by recursively querying other DNS servers. It can operate in various modes: as an <I>authoritative server</I> for zones it masters, a <I>recursive resolver</I> that finds answers for clients, or a <I>caching server</I> to speed up future queries. It typically listens on UDP port 53 for standard queries and TCP port 53 for zone transfers and larger responses. Configuration is primarily managed via the <b>named.conf</b> file, which defines its operational behavior, zones, logging, and security settings, including support for DNSSEC.


title: CAVEATS
content:
Configuring <b>named</b> requires a deep understanding of DNS concepts, zone files, and security best practices. Misconfigurations can lead to significant issues, including DNS resolution failures, security vulnerabilities (e.g., DNS amplification attacks, cache poisoning), or high resource consumption. Implementing DNSSEC correctly also adds a layer of complexity.<br><br>While <b>named</b> is robust, it can be resource-intensive, particularly under heavy query loads or with large numbers of zones. Regular monitoring and careful tuning are essential for production environments.


title: CONFIGURATION FILE
content:
The primary configuration for <b>named</b> is stored in the <b>named.conf</b> file (default: <b>/etc/named.conf</b>). This file defines global settings, logging, access control lists (ACLs), and most importantly, the zones that <b>named</b> is authoritative for or that it will recursively resolve queries for.


title: ZONE FILES
content:
For domains where <b>named</b> acts as an authoritative server, the actual DNS records (A, AAAA, MX, NS, CNAME, SOA, PTR, etc.) are stored in separate <I>zone files</I>. These files are referenced within <b>named.conf</b> and contain the mappings between domain names and IP addresses or other resources.


title: OPERATION MODES
content:
<b>named</b> can be configured to operate in several ways:<br><br><I>Authoritative-only</I>: Serves DNS records for zones it masters, but does not perform recursive queries for clients.<br><br><I>Recursive-only (Caching Resolver)</I>: Primarily performs recursive lookups for clients, caching responses to improve performance, but does not host its own zones.<br><br><I>Combined</I>: Acts as both an authoritative server for some zones and a recursive resolver for clients. This is a common setup for enterprise networks.


title: DNSSEC SUPPORT
content:
One of <b>named</b>'s critical features is its comprehensive support for <I>DNS Security Extensions</I> (DNSSEC). DNSSEC adds cryptographic signatures to DNS data, allowing DNS resolvers to verify the authenticity and integrity of responses, thereby protecting against cache poisoning and other forms of DNS manipulation.


title: HISTORY
content:
<b>named</b> originated from the <I>Berkeley Internet Name Domain</I> (BIND) software, which was developed at the University of California, Berkeley, in the 1980s. It became a fundamental component of the internet's infrastructure, initially distributed with BSD Unix. Over decades, <b>named</b> has undergone significant evolution through various major versions (e.g., BIND 4, BIND 8, BIND 9). BIND 9, released in 2000, represented a major rewrite focused on scalability, security (with robust DNSSEC support), and advanced features. It remains the most widely used DNS server software globally, continuously updated by the Internet Systems Consortium (ISC) to address performance, security, and protocol standard enhancements.


title: PARAMETERS
content:
<b><b>-l</b>, <b>--long</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a long listing format, similar to <i>ls -l</i>, showing more details like device, inode, permissions, link count, UID, GID, size, and last modification time.<br><br><b><b>-m</b>, <b>--mounts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays mount point information for directories that are mount points.<br><br><b><b>-n</b>, <b>--no-stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>namei</b> from stopping at the first non-existent file or directory component. It continues processing the rest of the path, if possible.<br><br><b><b>-o</b>, <b>--offset=<I>NUMBER</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts resolving the path from the <I>NUMBER</I>th character of the given pathname.<br><br><b><b>-p</b>, <b>--parent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints each parent directory as it is encountered during the path traversal, showing the full hierarchy.<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;Prints version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>namei</b> command is a utility used to traverse a given pathname, resolving symbolic links and reporting the type of each component encountered along the way. It's particularly useful for understanding how the kernel resolves a file path, especially when dealing with nested directories, symbolic links, or mount points. <br><br> For each component of the path, <b>namei</b> prints an indicator (e.g., 'f:' for regular file, 'd:' for directory, 'l:' for symbolic link), followed by the component's name. If a symbolic link is encountered, it also shows where the link points. This detailed output helps in debugging 'file not found' errors, understanding complex file system structures, or verifying the true target of symbolic links. Unlike commands like <i>ls</i> or <i>stat</i> that focus on the final target, <b>namei</b> provides a step-by-step breakdown of the entire path resolution process. It's a powerful diagnostic tool for system administrators and developers.


title: CAVEATS
content:
<b>namei</b> only reports on the path resolution process and does not modify the file system. <br>Its output can become very verbose for deeply nested paths or long chains of symbolic links. <br>By default, it stops processing a path as soon as a non-existent component is found, unless <b>-n</b> is used.


title: OUTPUT INTERPRETATION
content:
The output of <b>namei</b> uses specific prefixes to denote the type of each path component:<br> <i>f:</i> - regular file<br> <i>d:</i> - directory<br> <i>l:</i> - symbolic link (followed by '->' and the link target)<br> <i>b:</i> - block device<br> <i>c:</i> - character device<br> <i>s:</i> - socket<br> <i>p:</i> - named pipe (FIFO)<br> <i>?:</i> - non-existent component or error<br> <i>(mount point)</i> - indicates a directory is a mount point (when using <b>-m</b>)


title: HISTORY
content:
The <b>namei</b> command is a long-standing utility within the <i>util-linux</i> project, a collection of essential userspace utilities for Linux. Its primary purpose has always been to provide a detailed, step-by-step trace of how the kernel resolves a file path, making it an invaluable diagnostic tool since early Linux distributions. It has maintained its core functionality over time, focusing on path resolution and symbolic link following, making it a reliable component for system debugging and understanding file system intricacies.


title: SYNOPSIS
content:
<b>nameif</b> [ <i>-s</i> ] [ <i>config_file</i> | <i>config_directory</i> ]<br><br><i>Example usage:</i><br><b>nameif</b> <i>/etc/sysconfig/network-scripts/ifcfg-eth0</i><br><b>nameif</b> <i>-s /etc/sysconfig/network-scripts/</i>


title: PARAMETERS
content:
<b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan a specified directory for network configuration files (e.g., <i>ifcfg-*</i> files) and apply naming rules based on their contents. If no directory is specified, it typically defaults to a standard location like <i>/etc/sysconfig/network-scripts/</i>.<br><br><b><i>config_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process a single network configuration file. <i>nameif</i> will extract the hardware address (<i>HWADDR</i>) from this file and attempt to rename the corresponding network interface based on its MAC address.<br><br><b><i>config_directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process all network configuration files within the specified directory. This is typically used with the <i>-s</i> option.<br><br>


title: DESCRIPTION
content:
<i>nameif</i> is a utility designed to ensure that network interfaces on a Linux system are assigned consistent device names (e.g., <i>eth0</i>, <i>eth1</i>) across reboots, regardless of the order in which the kernel detects them. It achieves this by matching the network interface's <b>MAC address</b> (hardware address) to a <i>HWADDR</i> entry specified in a network configuration file, typically found in <i>/etc/sysconfig/network-scripts/ifcfg-<b>*</b></i>.<br><br>Historically, systems sometimes faced an issue where network interfaces would swap names (e.g., what was <i>eth0</i> might become <i>eth1</i> after a reboot) if the kernel initialized them in a different order. This could break network configurations that relied on specific device names. <i>nameif</i> was developed to solve this problem by providing a mechanism to enforce persistent naming. Although it was a crucial tool in older Linux distributions (like Red Hat Enterprise Linux 5 and 6), its functionality has largely been superseded by more modern and robust mechanisms such as <b>udev</b> rules and <b>systemd.link</b> files, which handle device naming and persistence directly within the kernel device manager.


title: CAVEATS
content:
Primarily used in older Linux distributions (e.g., RHEL/CentOS 5, 6).<br>Largely deprecated in modern systems due to the adoption of <b>udev</b> and <b>systemd.link</b> for consistent network device naming.<br>Requires network configuration files to contain a <b>HWADDR</b> entry for proper functioning.<br>May require <b>root</b> privileges to execute and modify interface names.


title: INTERACTION WITH IFCFG FILES
content:
<i>nameif</i> relies heavily on the <i>HWADDR</i> directive within network configuration files, such as those found in <i>/etc/sysconfig/network-scripts/ifcfg-<b><interface_name></b></i>. This directive specifies the MAC address that the corresponding interface should have. If a match is found, <i>nameif</i> renames the interface to <i><b><interface_name></b></i>.


title: BOOT-TIME USAGE
content:
Historically, <i>nameif</i> was often invoked early in the boot process (e.g., by init scripts or <i>udev</i> rules) to ensure network interfaces were correctly named before network services were brought online. This guaranteed that <i>ifcfg-eth0</i> always configured the intended physical network card.


title: HISTORY
content:
The <i>nameif</i> command was part of the <i>net-tools</i> or <i>initscripts</i> package, which provided essential networking utilities for Linux systems. Its development was driven by the need for persistent and predictable network interface naming during system boot, a common challenge before the widespread adoption of dynamic device management systems like <b>udev</b>. While critical for maintaining network stability in older environments, its importance has diminished significantly with the evolution of Linux's device management architecture.


title: SEE ALSO
content:
<b>udev(7)</b>, <b>systemd.link(5)</b>, <b>ip(8)</b>, <b>ifconfig(8)</b> <i>(legacy)</i>, <b>net-tools(7)</b>


title: SYNOPSIS
content:
<b>nano</b> [<i>options</i>] [<i>filename(s)</i>]<br><b>nano</b> <i>-h</i> | <i>--help</i><br><b>nano</b> <i>-v</i> | <i>--version</i>


title: PARAMETERS
content:
<b><i>-A</i>, <i>--smarthome</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the 'smart home' key behavior, where pressing <i>Home</i> once moves to the start of the line's text, and again to the true start of the line.<br><br><b><i>-B</i>, <i>--backup</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates backup files of the original content when saving modifications. Backups are typically saved with a '.bak' suffix.<br><br><b><i>-c</i>, <i>--constantshow</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Constantly displays the current line, column, and character position in the status bar.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b><i>-i</i>, <i>--autoindent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables auto indentation for new lines, inheriting the indentation level from the previous line.<br><br><b><i>-L</i>, <i>--linenumbers</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays line numbers in the left margin of the editor window.<br><br><b><i>-m</i>, <i>--mouse</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables mouse support, allowing clicking to position the cursor and selecting text.<br><br><b><i>-S</i>, <i>--smooth</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables smooth scrolling, making the text scroll gradually instead of jumping line by line.<br><br><b><i>-T &lt;cols&gt;</i>, <i>--tabsize=&lt;cols&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the displayed width of a tab character to <i>&lt;cols&gt;</i> columns (default is 8).<br><br><b><i>-U</i>, <i>--multibuffer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the multiple file buffer feature, allowing the user to switch between editing different files within the same <b>nano</b> session.<br><br><b><i>-V</i>, <i>--view</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified file(s) in read-only view mode, preventing accidental modifications.<br><br><b><i>-v</i>, <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current <b>nano</b> version information and exits.<br><br><b><i>-w</i>, <i>--nowrap</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables soft wrapping of long lines, causing them to extend horizontally beyond the screen width.<br><br>


title: DESCRIPTION
content:
<b>nano</b> is a user-friendly command-line text editor for Unix-like operating systems. It was designed to be an easy-to-use replacement for the <i>Pico</i> editor, making it particularly popular among beginners due to its intuitive interface. Unlike more complex editors like <i>Vim</i> or <i>Emacs</i>, <b>nano</b> focuses on simplicity and ease of learning, making it ideal for quick edits of configuration files, scripts, or plain text.<br><br>Its interface displays common commands at the bottom of the screen, reducing the learning curve significantly. Key features include syntax highlighting for various file types, efficient search and replace functionality (with regular expression support), spell checking, automatic indentation, and support for multiple buffers (editing several files simultaneously). Its straightforward keybindings, often involving the <i>Ctrl</i> key, contribute to its accessibility, allowing users to quickly perform common tasks without extensive training.


title: CAVEATS
content:
While <b>nano</b> excels in simplicity and ease of use, it lacks the advanced scripting, macro capabilities, and highly customizable environments found in more powerful editors like <i>Vim</i> or <i>Emacs</i>. This can limit its efficiency for complex programming tasks or large-scale file manipulations. Users accustomed to traditional command-line navigation might find its reliance on <i>Ctrl</i> key combinations less efficient than modal editing paradigms. Also, certain advanced terminal features might not always be fully supported across all environments.


title: KEYBINDINGS AND INTERFACE
content:
<b>nano</b>'s keybindings are typically displayed at the bottom of the screen, making it easy for new users to discover commands. Commands are prefixed with <i>'^'</i> (representing the <i>Ctrl</i> key) or <i>'M-'</i> (representing the <i>Alt</i> or <i>Meta</i> key). For example, <i>^X</i> means <i>Ctrl+X</i> (Exit), and <i>^O</i> means <i>Ctrl+O</i> (WriteOut/Save). This direct display of common shortcuts is a core part of its beginner-friendly design, enabling users to perform tasks without memorizing complex commands.


title: CONFIGURATION FILE
content:
Users can customize <b>nano</b>'s behavior and default settings through a personal configuration file, typically located at <i>~/.nanorc</i>. This file allows for persistent options such as enabling syntax highlighting for specific file types, setting default behaviors like line numbering or soft wrapping, and even defining custom keybindings or aliases for frequently used commands. This allows for personalization while retaining <b>nano</b>'s core simplicity.


title: HISTORY
content:
<b>GNU nano</b> was originally created in 1999 by Chris Allegretta as a free software replacement for the <i>Pico</i> editor. <i>Pico</i>, part of the <i>Pine</i> email client, was not free software, leading to a demand for an open-source alternative with similar ease of use. Initially named <i>TIP</i> (<i>TIP isn't Pico</i>), it was renamed to <i>nano</i> in 2000 to avoid a naming conflict with another Unix utility. Since then, it has been officially adopted by the GNU Project and has continuously evolved, focusing on maintaining its user-friendly interface while adding useful features like syntax highlighting and regular expression search, establishing itself as a popular choice for quick and simple text editing.


title: SYNOPSIS
content:
<i><b>nasm</b> [<i>options</i>] <i>&lt;input_file&gt;</i> [<b>-o</b> <i>&lt;output_file&gt;</i>]<br></i><br><i>To compile an assembly file:</i><br><i><b>nasm</b> <b>-f</b> <i>elf</i> <i>mycode.asm</i> <b>-o</b> <i>mycode.o</i></i><br><i>To link the object file (using ld):</i><br><i><b>ld</b> <b>-m</b> <i>elf_i386</i> <i>mycode.o</i> <b>-o</b> <i>myprogram</i></i>


title: PARAMETERS
content:
<b><b>-o</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the name of the output file. If omitted, NASM attempts to guess a name based on the input filename and selected format, or defaults to <i>a.out</i>.</i><br><br><b><b>-f</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Selects the output file format. Common formats include <i>bin</i> (flat binary), <i>elf</i> (ELF object file), <i>a.out</i>, <i>coff</i>, <i>macho</i>, <i>win32</i>, etc. The default is <i>bin</i>.</i><br><br><b><b>-l</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a listing file, useful for debugging, showing source code, corresponding machine code, and symbol addresses.</i><br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Produces debugging information in the output file, often in DWARF or STABS format, enabling symbolic debugging with tools like GDB.</i><br><br><b><b>-D</b> <i>&lt;macro&gt;[=&lt;value&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines a preprocessor macro. Similar to <i>#define</i> in C, allowing conditional assembly or constant definitions directly from the command line.</i><br><br><b><b>-U</b> <i>&lt;macro&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Undefines a previously defined preprocessor macro, overriding any <b>-D</b> options or built-in definitions.</i><br><br><b><b>-I</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds a directory to the include file search path, where NASM looks for files specified by the <i>%include</i> directive.</i><br><br><b><b>-M</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a Makefile-compatible dependency file to standard output, listing all source and include files.</i><br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints the NASM version number and exits.</i><br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Causes NASM to be silent, suppressing all output except critical error messages.</i><br><br><b><b>-w+</b><i>&lt;warning&gt;</i> | <b>-w-</b><i>&lt;warning&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables or disables specific warnings by category (e.g., <i>-w+macro-params</i>). Use <i>-w help</i> to see all warning categories.</i><br><br><b><b>-Z</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Redirects error messages to the specified file instead of standard error.</i><br><br><b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Only preprocesses the input file and prints the result to standard output, without performing assembly.</i><br><br>


title: DESCRIPTION
content:
<i>NASM, the Netwide Assembler, is a popular open-source assembler primarily used for the Intel x86 and x64 instruction set architectures. It functions as a powerful tool for translating human-readable assembly language source code into machine code, which computers can directly execute. Unlike some other assemblers, NASM is designed to be highly portable, running on various operating systems including Linux, Windows, and macOS, and supports numerous output formats such as ELF, a.out, COFF, Mach-O, and flat binary files.</i><br><br><i>Its two-pass design efficiently handles forward references, making it robust for complex assembly projects. Programmers often choose NASM for low-level system programming tasks, including developing bootloaders, operating system kernels, device drivers, and performance-critical routines where direct hardware control and optimization are paramount. NASM distinguishes itself with its straightforward Intel-style syntax, offering a clean and predictable way to write assembly code, making it a favorite for both beginners and experienced assembly programmers seeking precise control over generated machine code.</i>


title: CAVEATS
content:
<i>NASM primarily supports Intel-style syntax, which differs significantly from AT&T syntax used by GNU Assembler (<b>as</b>). This means code written for one assembler is generally not directly compatible with the other. Additionally, NASM is an assembler, not a linker; it produces object files which typically require a separate linking step with a linker like <b>ld</b> to create an executable program. It focuses on the x86/x64 instruction set and does not support other architectures directly.</i>


title: <B>INTEL SYNTAX FOCUS</B>
content:
<i>NASM strictly adheres to Intel assembly syntax (e.g., 'MOV dest, src'), which is prevalent in many operating system development contexts and direct hardware interactions, distinguishing it from AT&T syntax used by GNU Assembler (<b>as</b>) where 'MOV src, dest' with register prefixes is common.</i>


title: <B>TWO-PASS DESIGN</B>
content:
<i>NASM employs a two-pass assembly process. The first pass determines the size and position of all instructions and data, resolving forward references (symbols defined later in the code). The second pass then generates the actual machine code and fills in all addresses and values, ensuring efficient handling of complex assembly programs.</i>


title: <B>MACRO PREPROCESSOR</B>
content:
<i>Beyond basic assembly, NASM includes a powerful built-in macro preprocessor, similar to C's preprocessor. It supports directives like <i>%define</i>, <i>%include</i>, <i>%if</i>, <i>%ifdef</i>, and <i>%macro</i>, allowing for code reusability, conditional assembly, and creation of complex, parameterized assembly routines, significantly enhancing code modularity and maintainability.</i>


title: HISTORY
content:
<i>NASM was initially conceived and developed by <i>Simon Tatham</i>, with the first public release in 1996. The project's goal was to create a highly portable and flexible x86 assembler, overcoming limitations and quirks found in existing assemblers like MASM or TASM, especially regarding their reliance on specific operating systems. Its commitment to a clean, Intel-style syntax and support for numerous output formats quickly made it a popular choice, particularly in the open-source community for developing operating systems and low-level utilities. Over the years, maintenance and development have been taken over by various contributors, ensuring its continued relevance and adaptation to new x86 architecture features.</i>


title: PARAMETERS
content:
<b><I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL of the web page or application to be converted into a desktop app. This is a mandatory argument.<br><br><b>--name <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the generated desktop application. Defaults to the website's title.<br><br><b>--icon <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the application icon. Supports .png, .icns, or .ico file formats. Accepts a local file path or a URL.<br><br><b>--width <I>pixels</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the default width of the application window in pixels.<br><br><b>--height <I>pixels</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the default height of the application window in pixels.<br><br><b>--full-screen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the application in full-screen mode by default.<br><br><b>--maximize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the application with the window maximized by default.<br><br><b>--user-agent <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom user-agent string for the web view, useful for sites that require a specific browser identification.<br><br><b>--internal-urls <I>regex</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A regular expression for URLs that should be kept within the application window. URLs not matching this regex will open in the default system browser.<br><br><b>--disable-dev-tools</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the developer tools (e.g., F12 or Ctrl+Shift+I) within the application, preventing users from inspecting web content.<br><br><b>--tray</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the application minimized to the system tray (where applicable) instead of opening a window.<br><br><b>--single-instance</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that only a single instance of the application can run at a time. Attempts to launch a second instance will focus the existing one.<br><br><b>--inject <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Injects a local CSS or JavaScript file into the web page. Useful for custom styling or behavior. Can be specified multiple times.<br><br><b>--electron-version <I>version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular version of Electron to use for building the application, e.g., '16.0.0'.<br><br><b>--portable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a portable version of the application that does not require installation and can be run from a USB drive.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides more detailed output during the build process, useful for debugging.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, listing all available options and their usage.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed nativefier version and exits.<br><br>


title: DESCRIPTION
content:
<b>nativefier</b> is a powerful command-line tool that allows users to easily convert any web page or web application into a standalone desktop application. It achieves this by leveraging the <i>Electron</i> framework (formerly Atom Shell), which enables the development of desktop GUI applications using web technologies like HTML, CSS, and JavaScript.<br><br>The resulting application behaves like a native desktop client, featuring its own dedicated window, icon, and independent process. This is particularly useful for web services that lack official desktop clients, providing a seamless way to access them directly from the desktop without needing a web browser.<br><br><b>nativefier</b> offers extensive customization options, including setting the application's name, icon, default window dimensions, user agent, and rules for internal URL navigation. It supports building cross-platform executables for Linux, macOS, and Windows from a single command, making it a versatile tool for creating tailored desktop experiences from existing web content.


title: CAVEATS
content:
<b>nativefier</b> requires <i>Node.js</i> and <i>npm</i> to be installed on your system to function. The generated applications can be relatively large in size due to bundling the entire Electron runtime. While providing a native-like experience, some complex web applications might not behave identically as in a standard browser, and performance can vary based on the web content and system resources.


title: INSTALLATION
content:
<b>nativefier</b> can be easily installed globally via <i>npm</i> (Node Package Manager) using the command: <br><code>npm install -g nativefier</code><br>Ensure you have Node.js and npm properly set up on your system before attempting installation.


title: CORE FUNCTIONALITY
content:
At its core, <b>nativefier</b> downloads the specified Electron version, bundles it with your target URL and any custom assets (like icons or injected scripts), and then creates an executable application bundle tailored for your operating system. This package includes everything needed for the web page to run as a standalone desktop application, independent of a web browser installation.


title: TYPICAL USE CASES
content:
<ul><li>Creating dedicated desktop apps for web-based instant messaging services.</li><li>Wrapping project management tools or internal dashboards for quick access.</li><li>Providing a 'single-purpose browser' for specific web applications.</li><li>Turning any web site into a more integrated part of your desktop environment.</li></ul>


title: HISTORY
content:
Developed and open-sourced by <I>Jia Hao</I> in 2015, <b>nativefier</b> quickly gained popularity as a simple yet effective tool for creating desktop wrappers for web-based services like WhatsApp Web and Slack, often before official desktop clients were widely available or preferred. It's built upon the Electron framework, which was initially released by GitHub as Atom Shell in 2013. The project continues to be actively maintained, adapting to new Electron versions and community contributions.


title: PARAMETERS
content:
<b><i>URIS...</i> or <i>PATHS...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more directories or files to open. If no URI or path is given, <i>Nautilus</i> will open a new window in the user's home directory.<br><br><b><b>--new-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new <i>Nautilus</i> window. This is commonly used when <i>Nautilus</i> is already running and you want a fresh instance, rather than reusing an existing window.<br><br><b><b>--browser</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new browser-style window. While still listed in some manuals, this option's behavior may be deprecated or absorbed by <b>--new-window</b> in recent versions, as <i>Nautilus</i> primarily operates in a browser-like mode by default.<br><br><b><b>--no-desktop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>Nautilus</i> from managing the desktop background and icons. This option is typically used in environments where another application or component handles the desktop, or when you specifically want <i>Nautilus</i> to not interfere with desktop rendering.<br><br><b><b>--quit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces all running instances of <i>Nautilus</i> to exit. This will close all open <i>Nautilus</i> windows and terminate the background process if it's running.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of <i>Nautilus</i> and exits immediately.<br><br>


title: DESCRIPTION
content:
<i>Nautilus</i>, commonly known as <b>Files</b>, is the default file manager for the GNOME desktop environment. It provides a user-friendly graphical interface for navigating and managing files and directories on your computer, as well as network resources.<br><br>Users can perform common file operations such as creating, copying, moving, deleting, and renaming files and folders. Key features include tabbed browsing, bookmarks for quick access to frequently used locations, powerful search capabilities, and the ability to connect to remote servers using various protocols like SFTP, FTP, SMB, and WebDAV.<br><br>Beyond basic file management, <i>Nautilus</i> also serves as the GNOME desktop shell, handling desktop icons, background, and providing an integrated experience for launching applications and managing the desktop environment. It is designed to be intuitive and efficient for both novice and experienced Linux users.


title: CAVEATS
content:
<i>Nautilus</i> often runs as a background process to manage the desktop environment, which means simply closing all its windows may not fully terminate the application. For a complete exit, especially for scripting, use <b>nautilus --quit</b>. Also, its role in managing desktop icons has evolved significantly across GNOME versions; newer versions might require specific GNOME Shell extensions to enable desktop icon functionality.


title: DESKTOP INTEGRATION EVOLUTION
content:
For many years, <i>Nautilus</i> was solely responsible for drawing the desktop background, icons, and handling drag-and-drop operations on the desktop. However, starting with GNOME 3.28, this responsibility largely shifted to <i>GNOME Shell</i> itself. Desktop icon support, while initially removed, has since been re-introduced via a separate, official GNOME Shell extension, often bundled with the desktop environment.


title: EXTENSIBILITY THROUGH PLUGINS
content:
<i>Nautilus</i> is highly extensible through its plugin system. Developers can write extensions, typically in Python or C, to add new functionalities, custom context menu actions, or integrate <i>Nautilus</i> with other applications and services. This allows users to tailor the file manager to their specific workflows and needs.


title: HISTORY
content:
Initially released in 2001 as part of GNOME 1.4, <i>Nautilus</i> replaced <i>GMC</i> (GNOME Midnight Commander) as the default GNOME file manager. It was designed from the ground up to be modern and user-friendly, supporting features like spatial browsing, and integrating desktop management. Over time, its interface and feature set have evolved, including a significant redesign in GNOME 3 to align with the new GNOME Shell paradigm. In many distributions, it was eventually rebranded as 'Files' to reflect its primary function more directly and intuitively.


title: PARAMETERS
content:
<b><i>--query &lt;query&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prefills the interactive search with a specific query string, filtering cheatsheets.<br><br><b><i>--path &lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies additional directories where <i>navi</i> should look for cheatsheet files.<br><br><b><i>--finder &lt;cmd&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the external fuzzy finder command to be used (e.g., <i>fzf</i>, <i>skim</i>).<br><br><b><i>--print</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the selected command to standard output instead of executing it.<br><br><b><i>--exec</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately executes the chosen command after selection (this is the default behavior).<br><br><b><i>--copy-to-clipboard</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies the selected command to the system clipboard.<br><br><b><i>--edit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the <i>navi</i> cheatsheet directory in the default text editor for quick modification.<br><br><b><b>repo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A subcommand for managing cheatsheet repositories (add, browse, update, remove).<br><br><b><b>search</b> <i>&lt;query&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a non-interactive search for commands matching the provided query.<br><br><b><b>info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive information about <i>navi</i>'s configuration and paths.<br><br>


title: DESCRIPTION
content:
<i>navi</i> is an intuitive and interactive command-line interface (CLI) tool designed to help users quickly find, browse, and execute commands from curated cheatsheets. It aims to reduce the need for constant web searches or memorizing complex command syntax. <i>navi</i> integrates seamlessly with popular fuzzy finders like <i>fzf</i> or <i>skim</i>, providing a highly efficient search experience. Users can define their own custom cheatsheets in a simple plaintext format, or pull from publicly available repositories, including community-driven ones. This extensibility makes it a versatile tool for both individual command recall and team-wide knowledge sharing. Beyond just searching, <i>navi</i> allows for direct execution of selected commands, optionally filling in placeholder values interactively, thereby streamlining workflow and improving productivity for developers, system administrators, and anyone frequently using the terminal. Written in Rust, it offers fast performance and a robust user experience.


title: CAVEATS
content:
While powerful, <i>navi</i> requires an external fuzzy finder like <i>fzf</i> or <i>skim</i> to be installed and accessible. The utility's effectiveness heavily relies on the quality and comprehensiveness of the cheatsheet files, which are often community-contributed or user-defined. For seamless execution of selected commands directly into the current shell, specific shell integration (e.g., functions in <i>.bashrc</i> or <i>.zshrc</i>) is typically required. Users should exercise caution when executing commands from untrusted cheatsheets due to potential security implications.


title: CHEATSHEET FORMAT
content:
<i>navi</i> uses a simple, human-readable plaintext format for its cheatsheets. Each entry typically starts with a comment line prefixed with '<i>#</i>', followed by a description line prefixed with '<i>%</i>', and then the command itself. Parameters within commands can be marked with '<i>&lt;param&gt;</i>', which <i>navi</i> prompts the user to fill interactively.


title: SHELL INTEGRATION
content:
For the most fluid workflow, <i>navi</i> benefits from shell integration. This involves adding specific functions to your shell's configuration file (e.g., <i>~/.bashrc</i>, <i>~/.zshrc</i>). These functions allow <i>navi</i> to capture the chosen command from its interactive interface and execute it directly in your current terminal session, rather than just printing it.


title: HISTORY
content:
<i>navi</i> emerged as a modern solution to the common problem of remembering complex command-line syntax. Written in Rust, it leverages the language's performance and safety features. Its development was driven by the desire for an interactive, flexible cheatsheet tool that goes beyond simple shell aliases or basic text files. Since its inception, it has seen active development on platforms like GitHub, accumulating a strong user base due to its intuitive interface, extensibility, and integration capabilities with popular fuzzy finders, making it a prominent tool in the CLI productivity ecosystem.


title: SYNOPSIS
content:
<br><b>nb</b> [<b>-h</b>|<b>--help</b>] [<b>-v</b>|<b>--version</b>] <i>&lt;command&gt;</i> [<i>arguments...</i>]<br>Example usage:<br><b>nb new</b> "<i>My new project ideas</i>"<br><b>nb list</b> <b>-t</b> <i>work,todo</i><br><b>nb search</b> "<i>important function</i>"


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>nb</b> command or a specific subcommand.<br>Usage: <b>nb help</b> <i>&lt;command&gt;</i> or <b>nb</b> <i>&lt;command&gt;</i> <b>--help</b><br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version number of the <b>nb</b> utility.<br><br>


title: DESCRIPTION
content:
<b>nb</b> is a minimalist command-line utility designed for efficient management of personal notes and code snippets. It leverages the power of Git, storing all notes as plain text files within a local Git repository. This design provides built-in version control, easy synchronization across devices, and robust backup capabilities. Users can create, edit, list, search, and delete notes directly from the terminal, making it ideal for developers, writers, or anyone who frequently works in a command-line environment. Its features include support for tags for better organization, powerful search capabilities using <b>grep</b>, and seamless integration with your preferred text editor via the <b>$EDITOR</b> environment variable. <b>nb</b> embodies the Unix philosophy, focusing on simplicity, plain text, and composability with other tools.


title: CAVEATS
content:
*   Requires <b>Git</b> to be installed and configured on your system, as it relies heavily on Git for note storage, versioning, and synchronization.<br>*   Notes are stored as plain text files, typically Markdown, within a local Git repository. While flexible, this means rich text formatting is dependent on your viewer/editor.<br>*   The <b>new</b> and <b>edit</b> commands depend on the <b>$EDITOR</b> environment variable being set to your preferred text editor (e.g., <b>vim</b>, <b>nano</b>, <b>code --wait</b>).<br>*   Primarily designed for Unix-like operating systems (Linux, macOS).


title: KEY COMMANDS
content:
<b>nb</b> operates primarily through subcommands, each performing a specific action:<br><b><I>new</I></b> <i>[title]</i>: Creates a new note. If a title is provided, it's used; otherwise, a timestamp is used. Opens the note in <b>$EDITOR</b>.<br><b><I>edit</I></b> <i>&lt;query&gt;</i>: Opens an existing note matching the query in <b>$EDITOR</b>.<br><b><I>list</I></b> <i>[-t &lt;tags&gt;] [-l &lt;limit&gt;]</i>: Lists notes, optionally filtered by tags or limited in number.<br><b><I>search</I></b> <i>&lt;query&gt; [-t &lt;tags&gt;]</i>: Searches note content and titles for the given query.<br><b><I>tags</I></b>: Lists all unique tags used across your notes.<br><b><I>show</I></b> <i>&lt;query&gt;</i>: Displays the content of a note directly in the terminal.<br><b><I>delete</I></b> <i>&lt;query&gt;</i>: Deletes a note matching the query.<br><b><I>sync</I></b>: Pushes and pulls changes to/from the remote Git repository, synchronizing your notes.


title: CONFIGURATION
content:
The primary configuration for <b>nb</b> is done via environment variables:<br><b><I>NB_PATH</I></b>: Specifies the directory where your <b>nb</b> Git repository is located. Defaults to <i>~/.nb</i>.<br><b><I>$EDITOR</I></b>: Used by <b>new</b> and <b>edit</b> commands to determine which text editor to open notes with (e.g., <i>export EDITOR=vim</i>).<br>For Git synchronization, ensure your <b>NB_PATH</b> directory is initialized as a Git repository and has a remote configured.


title: HISTORY
content:
The <b>nb</b> command-line notebook tool was created by <i>xwmx</i> with the aim of providing a simple, robust, and Git-backed solution for managing notes from the terminal. Its development began around 2017, focusing on adherence to the Unix philosophy: do one thing well, work with plain text, and compose well with other tools. The design emphasizes speed, ease of use, and leveraging existing, powerful tools like Git and standard text editors rather than reinventing core functionalities. It has seen continuous development and maintenance, building a small but dedicated community of users who appreciate its minimalist approach and reliability.


title: SEE ALSO
content:
<b>git(1)</b>: Essential for version control and synchronization., <b>vim(1)</b> or <b>nano(1)</b>: Common text editors used with <b>nb</b>., <b>grep(1)</b>: Utilized by <b>nb</b> for powerful text searching within notes., <b>t(1)</b> (todo.txt-cli): Another command-line tool for task management, similar in philosophy., <b>jrnl(1)</b>: A simple command-line journal application.


title: PARAMETERS
content:
<b><i>hostname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The IP address or network hostname of the machine acting as the game server. This argument is used by the client player to connect to the server.<br><br>


title: DESCRIPTION
content:
<i>nbbattleship</i> is a classic, text-based, two-player implementation of the popular Battleship board game, designed to be played over a network connection within the Linux terminal. Players strategically place their fleet of ships on a hidden grid and then take turns firing 'shots' at their opponent's board, attempting to locate and sink all enemy vessels. One player assumes the role of the server, initiating the game and waiting for a connection, while the other acts as the client, connecting to the server's machine using its hostname or IP address. The game renders the grid, ship placements, and shot outcomes using simple ASCII characters, providing a nostalgic and engaging multiplayer experience for command-line enthusiasts. It's a testament to the simplicity and power of terminal-based network applications.


title: CAVEATS
content:
This game requires two players for network play, one acting as a server and the other as a client. Network connectivity is essential. As a terminal-based game, it lacks graphical user interface elements. It may not be pre-installed on all systems and might require installing a specific game package (e.g., 'nbbattleship' or 'nethack-console' on Debian/Ubuntu-based systems).


title: GAMEPLAY MODES
content:
The game can be played in two primary modes: as a server (simply run <b>nbbattleship</b> without arguments) or as a client (run <b>nbbattleship</b> <i>hostname</i>). Solo play might also be available with a basic 'AI' opponent depending on the specific version.


title: SERVER AND CLIENT ROLES
content:
To initiate a network game, one player executes <b>nbbattleship</b> to become the server; their IP address will be displayed. The second player then connects as the client by running <b>nbbattleship</b> followed by the server's IP address or hostname.


title: HISTORY
content:
<i>nbbattleship</i> is a long-standing command-line game, typically found within game packages or distributed through Linux distribution repositories. Its straightforward design, leveraging basic TCP/IP networking, reflects common practices for early network-enabled applications and simple client-server architectures in terminal environments. While not tied to a specific major project's history, its presence in various `games` directories across distributions indicates its stable and enduring appeal as a simple, recreational utility.


title: SYNOPSIS
content:
<b>nbcheckers</b> [<i>options</i>]<br><br>Common usage examples:<br><i>/usr/openv/netbackup/bin/nbcheckers</i> [<b>-i</b> | <b>-u</b> | <b>-r</b>] [<b>-v</b>]<br><i>/usr/openv/netbackup/bin/nbcheckers</i> <b>-m</b> [<b>-v</b>]<br><i>/usr/openv/netbackup/bin/nbcheckers</i> <b>-d</b> [<b>-v</b>]<br><i>/usr/openv/netbackup/bin/nbcheckers</i> <b>-c</b> <i>&lt;client_name&gt;</i> [<b>-v</b>]


title: PARAMETERS
content:
<b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs checks specifically for a NetBackup installation process.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs checks specifically for a NetBackup upgrade process.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs general readiness or pre-flight checks for NetBackup operations.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes checks relevant to a NetBackup master server role.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes checks relevant to a NetBackup media server role.<br><br><b><b>-c</b> <i>&lt;client_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs checks on a specified NetBackup client, typically requiring a client name.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information and progress during checks.<br><br>


title: DESCRIPTION
content:
<i>nbcheckers</i> is a diagnostic utility used within the Veritas NetBackup environment. Its primary function is to perform a series of pre-installation, pre-upgrade, or general health checks on a NetBackup server (master or media server) or client. It verifies various critical aspects of the system, including: <b>Disk space availability</b> for installation, logs, and catalogs; <b>Network connectivity</b> and name resolution (DNS/hosts file entries); <b>User/group permissions</b>; <b>Kernel parameters</b>; <b>Firewall settings</b>; <b>NTP synchronization</b>; and <b>Specific NetBackup configuration files and directories</b>.<br><br>The tool helps identify potential issues that could hinder NetBackup operations or lead to failed installations/upgrades, allowing administrators to remediate problems proactively. It provides detailed output, often suggesting corrective actions. It's an essential tool for ensuring a healthy NetBackup infrastructure.


title: CAVEATS
content:
<b>Requires NetBackup Installation:</b> This command is not a standard Linux utility; it is specific to Veritas NetBackup software and must be run from a system with NetBackup installed.<br><b>Path Dependency:</b> It's typically located in the NetBackup installation path (e.g., <i>/usr/openv/netbackup/bin/</i>). Running it without the full path or without adding the path to <i>PATH</i> might fail.<br><b>Root Privileges:</b> Many checks performed by <i>nbcheckers</i> require root privileges to access system resources, kernel parameters, and sensitive configuration files.<br><b>Version Specificity:</b> Its exact behavior, available options, and scope of checks can vary slightly between different versions of NetBackup. Always consult the Veritas NetBackup documentation for the specific version in use.<br><b>Diagnostic Only:</b> It's a diagnostic tool; it identifies problems but does not fix them automatically. Administrators must manually address any issues reported.


title: OUTPUT INTERPRETATION
content:
<i>nbcheckers</i> typically provides clear, often color-coded (on a terminal) output, indicating <b>PASSED</b>, <b>WARNING</b>, or <b>FAILED</b> for each check. Failed checks usually include specific reasons and sometimes recommended actions to remediate the issue.


title: LOG FILES
content:
The detailed output of <i>nbcheckers</i> is often logged to a file, which is crucial for post-execution analysis, auditing, and troubleshooting. The log file location is usually within the NetBackup logs directory (e.g., <i>/usr/openv/netbackup/logs/nbcheckers</i> or a subdirectory within <i>/usr/openv/netbackup/logs/</i>).


title: HISTORY
content:
<i>nbcheckers</i> has been a part of Veritas (formerly Symantec) NetBackup for many years, evolving alongside the product. Its role has consistently been to serve as a pre-flight checklist tool, particularly emphasized for major upgrades or installations to minimize common deployment issues. Over time, its capabilities have expanded to include checks for more complex environments, such as cluster readiness, cloud integration prerequisites, and specific performance-related parameters. Its continuous development reflects the growing complexity of enterprise backup environments and the need for robust validation steps.


title: PARAMETERS
content:
<b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display active NBPv15 configurations currently in use.<br><br><b>-s, --set <PARAM>=<VALUE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific NBPv15 parameter to a given value.<br><br><b>-c, --clear <PARAM></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear or reset a specific NBPv15 parameter to its default.<br><br><b>-D, --daemon-mode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the utility in a continuous monitoring daemon mode.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's version information and then exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display this help message and exit gracefully.<br><br><b>--buffer-id <ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom buffer identifier (default is 15).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate command execution without applying any changes.<br><br>


title: DESCRIPTION
content:
The <i>nbfifteen</i> command provides a suite of tools for inspecting, configuring, and maintaining parameters associated with a hypothetical 'Network Buffer Protocol Version 15' (NBPv15) within a Linux system. It allows administrators to view current buffer states, adjust buffer sizes, enable or disable specific NBPv15 features, and troubleshoot related network performance issues. This utility is particularly useful in environments where fine-grained control over network buffering for a specific protocol version is required to optimize throughput and minimize latency. Its design focuses on providing both an overview of the NBPv15 subsystem and granular control over individual buffer characteristics. Common use cases include optimizing real-time data streams, reducing packet loss in high-bandwidth applications, and diagnosing buffer-related network bottlenecks. The command aims to abstract the complexity of low-level kernel network settings, offering a user-friendly interface for critical network tuning.


title: CAVEATS
content:
This command interacts with low-level kernel network settings; incorrect usage may lead to network instability or performance degradation.<br>Requires root privileges for most operations.<br>Configuration changes made by <i>nbfifteen</i> might not persist across reboots unless configured via system service management (e.g., systemd).


title: EXAMPLES
content:
<b>nbfifteen --list</b><br><i>List all current NBPv15 configurations and their statuses.</i><br><br><b>nbfifteen --set buffer_size=1024K --buffer-id 15</b><br><i>Set the buffer size for NBPv15 ID 15 to 1024KB.</i><br><br><b>nbfifteen --daemon-mode</b><br><i>Start the nbfifteen monitoring daemon in the background.</i>


title: HISTORY
content:
The hypothetical <i>nbfifteen</i> command was initially developed as an internal tool within a large enterprise to manage specific network buffer parameters optimized for their proprietary protocol, which leveraged 'version 15' of a common network buffering scheme. It was later open-sourced to allow broader community contributions and integration with various Linux distributions. Early versions focused primarily on read-only status displays, with comprehensive configuration capabilities added in later major releases (e.g., 2.0.0 onwards) to provide full management functionality. Its development prioritizes performance and stability for critical network environments.


title: PARAMETERS
content:
<b>-id <I>block_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information for a specific NetBackup shared memory block identified by its unique <I>block_id</I>. If omitted, the command lists all active NetBackup shared memory blocks.<br><br><b>-r <I>block_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>(Caution: Use with extreme care!)</b> Attempts to release (detach and remove) a specific NetBackup shared memory block identified by its <I>block_id</I>. Improper use of this option can lead to NetBackup process instability, crashes, or data corruption. It should only be used under direct guidance from Veritas Support.<br><br>


title: DESCRIPTION
content:
<code>nbmemoblocks</code> is a specialized diagnostic utility bundled with Veritas NetBackup. Its primary function is to display information about shared memory segments, often referred to as "memo blocks," that are currently in use by various NetBackup processes and daemons.<br><br>This command is invaluable for NetBackup administrators and support personnel who need to troubleshoot performance issues, memory leaks, or understand resource utilization within a NetBackup environment. The output typically includes details such as the unique ID of each shared memory block, its size in bytes, and the number of NetBackup processes currently attached to it. By providing insight into the shared memory landscape, <code>nbmemoblocks</code> helps in diagnosing issues where NetBackup processes might be consuming excessive memory or or failing to release shared resources properly. It is a critical tool for maintaining the stability and efficiency of NetBackup operations.


title: CAVEATS
content:
<code>nbmemoblocks</code> is specific to the Veritas NetBackup software suite and will not function outside of a NetBackup installation. The <code>-r</code> (release) option is highly destructive and should only be used by experienced administrators under explicit guidance from Veritas technical support, as it can cause severe disruption to NetBackup operations. The command only displays shared memory segments managed or utilized by NetBackup processes, not all shared memory on the system. The output format and available options might subtly change across different versions of NetBackup.


title: USAGE CONTEXT
content:
This command is primarily a diagnostic tool intended for use by NetBackup administrators, database administrators, and Veritas support personnel to analyze and troubleshoot memory-related issues within the NetBackup environment. It is not a general-purpose Linux utility.


title: OUTPUT INTERPRETATION
content:
When run without arguments, <code>nbmemoblocks</code> typically provides a columnar output listing shared memory segments. Key columns usually include:<br><ul><li><b>ID</b>: The unique identifier for the shared memory segment.</li><li><b>SIZE</b>: The allocated size of the memory block in bytes.</li><li><b>ATTACH</b>: The number of NetBackup processes currently attached to this block.</li></ul>Analyzing this output can help identify large memory segments, segments that are not being properly released, or those with an unexpected number of attachments.


title: PRIVILEGES
content:
Executing <code>nbmemoblocks</code> and obtaining complete information, especially related to shared memory segments, typically requires root or equivalent administrator privileges on the system where NetBackup is installed.


title: HISTORY
content:
<code>nbmemoblocks</code> has been an integral diagnostic component of the Veritas (formerly Symantec) NetBackup software suite for many years, dating back to its earlier versions. It was developed to provide administrators with a low-level view into the shared memory resources used by NetBackup's complex multi-process architecture, aiding in troubleshooting and performance tuning specific to the product's internal operations. Its design reflects the need for specialized tools to manage and monitor proprietary system components.


title: SYNOPSIS
content:
<I><b>nbmines</b> [-h] [-v] [-d <I>DIFFICULTY</I>] [-r <I>ROWS</I>] [-c <I>COLS</I>] [-n <I>MINES</I>]</I>


title: PARAMETERS
content:
<b><I><b>-h</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Displays a help message and exits.</I><br><br><b><I><b>-v</b></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Shows version information and exits.</I><br><br><b><I><b>-d</b> <I>DIFFICULTY</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets the game's difficulty level. Common values include <b>easy</b>, <b>medium</b>, and <b>hard</b>, which configure predefined board sizes and mine counts.</I><br><br><b><I><b>-r</b> <I>ROWS</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the number of rows for the custom game board. Must be a positive integer.</I><br><br><b><I><b>-c</b> <I>COLS</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the number of columns for the custom game board. Must be a positive integer.</I><br><br><b><I><b>-n</b> <I>MINES</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the total number of mines to be placed on the board. Must be a positive integer less than the total number of squares (<I>ROWS</I> * <I>COLS</I>).</I><br><br>


title: DESCRIPTION
content:
<I><b>nbmines</b> is a faithful, terminal-based implementation of the classic Minesweeper puzzle game. Leveraging the ncurses library, it provides a graphical user interface within your command-line environment, offering a nostalgic and challenging experience for users who prefer console applications.<br><br>Players navigate a grid of hidden squares using keyboard controls, aiming to uncover all non-mine squares while avoiding detonation. The game allows for custom board dimensions and mine counts, or players can opt for predefined difficulty levels. It's a lightweight yet engaging way to pass the time directly in your shell.</I>


title: CAVEATS
content:
<I><b>nbmines</b> requires a terminal emulator with ncurses support. Its interface is entirely keyboard-driven, which might require a brief learning curve for controls (e.g., arrow keys for movement, 'f' to flag, 'enter' to reveal). It is not suitable for touch-only environments.</I>


title: <I>GAMEPLAY CONTROLS</I>
content:
<I>Within the game, typical controls include:<br><b>Arrow Keys</b>: Move cursor.<br><b>'f'</b> or <b>Spacebar</b>: Flag/unflag a potential mine.<br><b>Enter</b> or <b>'c'</b>: Clear (reveal) the current square.<br><b>'q'</b>: Quit the game.</I>


title: HISTORY
content:
<I><b>nbmines</b> is a relatively widespread open-source project, often included in standard Linux distribution repositories. While a detailed specific development history is not widely documented, it represents a common genre of terminal-based games designed to bring classic experiences to the command line environment using the ncurses library. Its existence is a testament to the versatility of terminal applications.</I>


title: DESCRIPTION
content:
<i>nbpipes</i> is not a standard, general-purpose Linux command. Instead, it is an executable program integral to <B>Veritas NetBackup</B> software. Its primary function is to manage and control <B>named pipes</B> (FIFOs), which serve as temporary, in-memory buffers for data streams during various NetBackup operations such as backup, restore, or replication.<br><br>These pipes are crucial for facilitating efficient and high-performance communication and data transfer between different NetBackup processes. For instance, they can buffer data flowing from a client machine to a media server, or between storage units for optimized duplication. By using named pipes, NetBackup can stream large volumes of data without requiring intermediate disk I/O, thereby improving performance and resource utilization. Users typically do not invoke <i>nbpipes</i> directly; it is invoked and managed internally by NetBackup daemons and processes to ensure reliable data flow within the complex backup architecture.


title: CAVEATS
content:
<i>nbpipes</i> is specific to <B>Veritas NetBackup</B> and is not a part of standard Linux distributions.<br>It is primarily an <B>internal component</B> of NetBackup and is not intended for direct manual invocation by system administrators.<br>Improper manual use or manipulation of <i>nbpipes</i> could potentially disrupt NetBackup operations and data transfers.


title: INTERNAL FUNCTIONALITY
content:
Within the NetBackup environment, <i>nbpipes</i> handles the creation, management, and removal of temporary named pipes. These pipes act as conduits for data streams between various NetBackup processes (e.g., between the <i>bpcd</i> client daemon and the <i>bptm</i> media server daemon). This allows NetBackup to process data in a streaming fashion, avoiding the overhead of writing data to temporary files on disk, which is essential for large-scale backup and restore operations.


title: TYPICAL USAGE CONTEXT
content:
While <i>nbpipes</i> is an executable, it's rarely, if ever, directly invoked by a NetBackup administrator. Its operations are orchestrated by NetBackup's internal logic, policy configurations, and daemon processes. For example, during an optimized duplication or an <B>Auto Image Replication (AIR)</B> operation, NetBackup might leverage named pipes managed by <i>nbpipes</i> to streamline the data movement between different storage locations or NetBackup domains.


title: HISTORY
content:
<i>nbpipes</i> has been a foundational component of <B>Veritas NetBackup</B> (and its predecessors under Symantec and now Veritas again) for many years. Its existence reflects the software's long-standing design principle of leveraging named pipes for efficient inter-process communication and high-speed data streaming, a crucial requirement for enterprise-level data protection solutions. Its development and usage have evolved alongside NetBackup's architecture, adapting to new data types, storage technologies, and performance demands.


title: DESCRIPTION
content:
nbreversi is a classic text-based implementation of the popular board game Reversi, also known as Othello. It provides a simple yet engaging user interface entirely within the terminal, utilizing the <I>ncurses</I> library for rendering the game board and interactions. Players can enjoy a turn-based game against a computer opponent, placing their pieces on the 8x8 grid to outmaneuver and flip the opponent's pieces. The game typically features a basic AI for the computer player, making it suitable for casual play. Its lightweight nature and dependency solely on a text interface make it accessible across various Linux environments, even those without a graphical desktop.<br><br>While nbreversi offers a straightforward gameplay experience, it lacks advanced features such as difficulty settings, two-player modes, or extensive configuration options from the command line. Interactions, including moves and game restart, are handled directly within the game's interactive terminal interface. It serves as an excellent example of <I>ncurses</I> applications and a nostalgic nod to early text-mode games.


title: CAVEATS
content:
nbreversi is a very basic implementation of Reversi. It typically offers no command-line options for configuration, AI difficulty, or starting player. All interactions are handled within the game's curses interface. It usually supports only a single-player mode against a simple AI. Its graphical capabilities are limited to ASCII/UTF-8 characters, common for terminal applications.


title: INTERACTIVE CONTROLS
content:
Movement and game actions within <I>nbreversi</I> are typically controlled using keyboard inputs, often arrow keys for selection and Enter for confirmation. The game usually provides on-screen prompts or a simple help display for in-game commands.


title: EXITING THE GAME
content:
Users can typically exit <I>nbreversi</I> by pressing 'q' (quit) or 'Ctrl+C' (interrupt) during gameplay.


title: HISTORY
content:
nbreversi is often distributed as part of the <I>ncurses</I> examples or a similar package that bundles simple console games demonstrating the <I>ncurses</I> library's capabilities. It represents a common practice of creating text-based games in Unix-like environments, a tradition that dates back to the early days of computing before widespread graphical interfaces. Its development history is tied to the <I>ncurses</I> project itself, serving as a functional, albeit minimalistic, example of what can be built with the library. It has been included in many Linux distributions' default repositories for decades.


title: PARAMETERS
content:
<b>collect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gathers a comprehensive set of diagnostic information, logs, and configuration files, typically packaged into an archive for support analysis.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the operational status of various system components and services relevant to NetBackup.<br><br><b>network</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides detailed network-related diagnostics, including interface configurations, routing, and connectivity tests.<br><br><b>logs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages or collects specific NetBackup and system logs for troubleshooting purposes.<br><br><b>appliance_info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gathers information specific to NetBackup appliances, such as hardware details, software versions, and disk usage.<br><br><b>vmware_config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collects VMware-related configuration details and logs pertinent to NetBackup's virtual machine backup operations.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general usage information for <b>nbsos</b> or specific help for a subcommand.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the <b>nbsos</b> utility.<br><br>


title: DESCRIPTION
content:
The <b>nbsos</b> command is a specialized diagnostic utility bundled with Veritas NetBackup. Its primary purpose is to assist NetBackup administrators and Veritas Support in collecting comprehensive operating system and NetBackup environment-specific information for troubleshooting, health checks, and support cases.<br><br>It consolidates various diagnostic tasks, automating the collection of data that would otherwise require running numerous separate Linux commands and navigating complex log directories. This includes details on networking, storage, CPU, memory, OS configuration, and specific NetBackup component states.<br><br>Particularly crucial in Veritas NetBackup Appliance environments, where direct OS-level access is often restricted, <b>nbsos</b> provides a controlled and efficient interface for gathering critical system insights. It streamlines the data collection process, enabling quicker problem identification and resolution.


title: CAVEATS
content:
<b>nbsos</b> is a Veritas NetBackup utility, not a standard Linux command. It requires a NetBackup installation to be present.<br><br>Its availability, exact functionality, and subcommands can vary significantly across different NetBackup versions and appliance models.<br><br>Running <b>nbsos</b>, especially the 'collect' subcommand, often requires root privileges or elevated permissions to gather all necessary system data.<br><br>The data collected by the 'collect' subcommand can be extensive and may take a considerable amount of time and disk space.<br><br>It is primarily intended for diagnostic purposes and is often run under the guidance of Veritas Support personnel.


title: USAGE CONTEXT
content:
<b>nbsos</b> is frequently invoked within the NetBackup Appliance shell menu or directly from the command line on NetBackup master or media servers. It forms a crucial part of the diagnostic workflow, often initiated when troubleshooting specific issues or performing health checks, usually under the direction of Veritas Support.


title: DATA COLLECTION AND SUBMISSION
content:
The <b>nbsos collect</b> subcommand is particularly significant. It generates a compressed archive (e.g., <i>.tar.gz</i> or <i>.zip</i>) containing a wealth of diagnostic data. This archive includes NetBackup logs, operating system logs, configuration files, outputs of standard Linux commands (like <i>vmstat</i>, <i>iostat</i>, <i>df</i>), and various NetBackup-specific configuration details. This packaged data is then typically uploaded to Veritas for in-depth analysis to aid in problem resolution.


title: HISTORY
content:
The <b>nbsos</b> utility was developed by Veritas (now part of Broadcom) as a critical tool for simplifying and standardizing the collection of diagnostic data in complex NetBackup environments. Its inception was driven by the need to efficiently gather system-level insights that are vital for troubleshooting and support cases, reducing the manual effort involved in collecting disparate logs and system outputs.<br><br>Over time, as NetBackup evolved and appliances became a significant part of its ecosystem, <b>nbsos</b> became even more pivotal. For NetBackup Appliances, where the underlying OS is locked down, <b>nbsos</b> provides a controlled and secure interface for administrators and support teams to perform necessary diagnostics without compromising system integrity. It continues to evolve with new NetBackup versions, incorporating new diagnostic capabilities relevant to the latest features and architectures.


title: DESCRIPTION
content:
<i>nbsudoku</i> is a lightweight, interactive Sudoku puzzle game designed for the command-line interface. Built using the <b>ncurses</b> library, it provides a text-based graphical interface for playing Sudoku directly within your terminal emulator. Users can navigate the grid, enter numbers, clear cells, generate new puzzles, and even reveal the solution. Its simplicity makes it a quick and accessible option for Sudoku enthusiasts who prefer a minimalist, keyboard-driven experience without needing a full graphical desktop environment. It's often included as an example program within <b>ncurses-examples</b> or similar ncurses development packages, showcasing the library's capabilities for creating interactive terminal applications.


title: CAVEATS
content:
As a terminal-based application, <i>nbsudoku</i> requires a compatible terminal emulator. It does not offer features like saving game progress, undo/redo history, or varying difficulty levels directly through command-line options. Interaction is purely via keyboard inputs within the game's interface.


title: IN-GAME CONTROLS
content:
Once launched, <i>nbsudoku</i> is controlled entirely via keyboard:<br><ul><li><b>Arrow keys</b> or <b>h, j, k, l</b>: Navigate the grid.</li><li><b>1-9</b>: Enter a number into the selected cell.</li><li><b>0</b>, <b>.</b>, or <b>Space</b>: Clear the selected cell.</li><li><b>s</b>: Show the solution to the current puzzle.</li><li><b>n</b>: Generate a new Sudoku puzzle.</li><li><b>q</b>: Quit the game.</li><li><b>?</b>: Display brief help (if implemented in specific versions).</li></ul>


title: AVAILABILITY
content:
<i>nbsudoku</i> is commonly found in Linux distributions as part of the <b>ncurses-examples</b> or <b>ncurses-bin</b> package. It can usually be installed via the system's package manager (e.g., <code>sudo apt install ncurses-examples</code> on Debian/Ubuntu, or <code>sudo dnf install ncurses-examples</code> on Fedora).


title: HISTORY
content:
<i>nbsudoku</i> is typically distributed as part of the <b>ncurses-examples</b> package, which contains various small programs demonstrating the capabilities of the <b>ncurses</b> library. Its primary purpose is to serve as an illustrative example of how to build interactive applications with a text-based user interface, rather than being a standalone, extensively developed game. Its presence reflects the utility of ncurses for creating simple, functional terminal games.


title: SYNOPSIS
content:
<b>nbtscan</b> [<i>options</i>] <i>&lt;ip_range | hostname | file&gt;</i><br>Examples:<br><i>nbtscan 192.168.1.0/24</i><br><i>nbtscan 192.168.1.1-254</i><br><i>nbtscan -f ip_list.txt</i>


title: PARAMETERS
content:
<b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Scan local network using ARP. Requires root privileges for ARP scans.</i><br><br><b>-s <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Save output to the specified file.</i><br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print host names retrieved by reverse lookups if possible.</i><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable verbose output, showing more details during the scan process.</i><br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Read IP addresses or ranges from the specified file, one per line.</i><br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable pinging hosts before scanning, potentially speeding up scans on unresponsive networks.</i><br><br><b>-T <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the initial timeout for NetBIOS queries in milliseconds. Default is 200 ms.</i><br><br><b>-W <workgroup></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Filter results to only show hosts belonging to the specified workgroup.</i><br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Include MAC addresses in the output.</i><br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disable name resolution; display IP addresses only.</i><br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable debug mode, showing internal program messages.</i><br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List local NetBIOS names.</i><br><br><b>-t <retries></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the number of retries for each query. Default is 2 retries.</i><br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Perform an ARP scan instead of a NetBIOS scan. Requires root privileges.</i><br><br><b>-B</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Attempt to grab banner information from discovered hosts (e.g., SMB banner).</i><br><br><b>-p <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use a specific UDP port for NetBIOS queries (default is 137).</i><br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Perform reverse DNS lookups on discovered IP addresses.</i><br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print program version and exit.</i><br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List all local IP addresses that can be used for scanning.</i><br><br><b>-i <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the network interface to use for scanning (e.g., eth0).</i><br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress banner information during startup.</i><br><br>


title: DESCRIPTION
content:
<i>nbtscan</i> is a powerful command-line tool designed for network reconnaissance. It efficiently scans a range of IP addresses for NetBIOS name service information, which is primarily used by Windows-based systems. By sending UDP queries to port 137 (NetBIOS Name Service), <i>nbtscan</i> can discover hosts, their NetBIOS names, workgroup/domain names, user names, and even MAC addresses. This makes it invaluable for network administrators and security professionals looking to quickly map out Windows machines on a network, identify potential targets, or assess network configurations. Its output provides a concise overview of active NetBIOS services, aiding in tasks such as inventory management, vulnerability assessment, and troubleshooting.


title: CAVEATS
content:
<i>nbtscan</i> relies on the NetBIOS over TCP/IP (NBT) protocol, specifically querying UDP port 137. Many modern Windows operating systems might have NetBIOS disabled, filtered by a firewall, or use different discovery mechanisms (e.g., WS-Discovery). Consequently, <i>nbtscan</i> might not provide a comprehensive view of all Windows machines on a highly secured or modern network. It can also be quite 'noisy' on the network, making its activity noticeable.


title: COMMON OUTPUT COLUMNS
content:
When <i>nbtscan</i> successfully identifies a host, its default output typically includes columns such as: <b>IP address</b>, <b>NetBIOS Name</b>, <b>User Name</b>, <b>Server</b> (indicating if it's a server), and <b>MAC Address</b> (if requested with <i>-m</i>). This structured output provides immediate insights into the nature of the discovered device.


title: USAGE CONSIDERATIONS
content:
For best results, <i>nbtscan</i> is often used with an IP address range (e.g., CIDR notation like 192.168.1.0/24 or a dash-separated range like 192.168.1.1-254). Running <i>nbtscan</i> on a broad range or across slow networks might require adjusting the <b>-T</b> (timeout) and <b>-t</b> (retries) parameters for optimal performance.


title: HISTORY
content:
<i>nbtscan</i> is an open-source utility that was originally developed by Stephen Schmidt. It gained popularity as a quick and effective tool for network reconnaissance, particularly in environments with a significant presence of Windows machines. Its straightforward usage and clear output made it a staple in many network administration and security toolkits. While newer discovery methods exist, <i>nbtscan</i> remains relevant for legacy systems and specific network auditing tasks.


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


title: PARAMETERS
content:
<b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listen mode. For inbound connects.<br><br><b><b>-p</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the local port for outgoing connections.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use UDP instead of the default TCP.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output. Provides more information about connections and errors.<br><br><b><b>-w</b> <I>timeout</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connection timeout. Specifies how long to wait for a connection to establish.<br><br><b><b>-z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zero-I/O mode. Only scan for listening daemons, without sending any data. Useful for port scanning.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not do DNS lookups. Speeds up operations when dealing with IP addresses.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <b>nc</b> to stay listening for another connection after its current client disconnects. Only valid with <b>-l</b>.<br><br><b><b>-4</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <b>nc</b> to use IPv4 addresses only.<br><br><b><b>-6</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <b>nc</b> to use IPv6 addresses only.<br><br>


title: DESCRIPTION
content:
The <b>nc</b> (or <b>netcat</b>) command is a powerful networking utility that reads and writes data across network connections, using the TCP/IP or UDP protocols. Often referred to as the "TCP/IP swiss army knife", it's incredibly versatile for various tasks.<br><br>It can be used for port scanning, file transfers, simple chat applications, network debugging, and even as a backdoor. It can act as both a client (connecting to a remote host and port) and a server (listening on a specified port for incoming connections). Its simplicity and raw data handling make it an essential tool for network administrators, developers, and security professionals.


title: CAVEATS
content:
While extremely powerful, <b>nc</b> sends data in plain text by default, making it unsuitable for transferring sensitive information without additional encryption (e.g., via a VPN or SSH tunnel). Its simplicity also means it lacks advanced features like authentication or robust error handling, which are present in more specialized tools. It's often misused in malicious contexts due to its ability to create simple backdoors or listener services.


title: COMMON USE CASES
content:
<ul><li><I>Port Scanning:</I> <b>nc -zv <I>target</I> <I>port</I></b> checks if a port is open.</li><li><I>File Transfer:</I> Server: <b>nc -l -p <I>port</I> > <I>file</I></b>; Client: <b>nc <I>server_ip</I> <I>port</I> < <I>file</I></b>.</li><li><I>Simple Chat:</I> Server: <b>nc -l -p <I>port</I></b>; Client: <b>nc <I>server_ip</I> <I>port</I></b> (type messages and press Enter).</li><li><I>Debugging:</I> Test connectivity to services or send raw HTTP requests.</li></ul>


title: HISTORY
content:
The original <b>Netcat</b> program was written by <I>Hobbit</I> in 1995. It quickly gained popularity as a versatile command-line networking tool. Due to its utility, various implementations have emerged, including GNU Netcat, OpenBSD Netcat (which is often symlinked as <b>nc</b> on many Linux systems), and Ncat (part of the Nmap suite). While their core functionality remains similar, subtle differences in options and behavior exist between these versions.


title: PARAMETERS
content:
<b>-4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>nc_openbsd</I> to use <I>IPv4</I> addresses only.<br><br><b>-6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>nc_openbsd</I> to use <I>IPv6</I> addresses only.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <I>help</I> message and exits.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the server to stay <I>listening</I> for another connection after the current client disconnects. Used with <B>-l</B>.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets <I>nc_openbsd</I> into <I>listen mode</I>, acting as a server.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shutdown the network socket after <I>EOF</I> on standard input, rather than waiting for remote shutdown.<br><br><b>-p <source_port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <I>source port</I> to use for outgoing connections.<br><br><b>-U</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <I>Unix domain sockets</I> instead of network sockets.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <I>UDP</I> instead of <I>TCP</I> for connections.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <I>verbose</I> output, providing more information during operation.<br><br><b>-w <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a <I>timeout</I> for connection attempts and idle connections, in seconds.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets <I>nc_openbsd</I> to <I>zero-I/O mode</I>, primarily used for efficient port scanning without sending data.<br><br>


title: DESCRIPTION
content:
<B>nc_openbsd</B> is the OpenBSD variant of the widely-used <I>netcat</I> network utility, renowned for its simplicity and versatility. Often called the "TCP/IP Swiss Army knife," it's a fundamental tool for network debugging, testing, and administration.<br><br>It allows users to establish and manage both <I>TCP</I> and <I>UDP</I> connections, acting as either a client connecting to a remote host or a simple server listening for incoming connections. Its capabilities extend to port scanning, file transfer, and even simple proxying or shell binding.<br><br>While <B>nc_openbsd</B> primarily works by reading data from standard input and writing it to a network connection, and vice-versa, its command-line options unlock a myriad of use cases. It's an invaluable tool for network engineers, developers, and system administrators for quick diagnostics and custom network operations, often used within scripts for automation.


title: CAVEATS
content:
<B>nc_openbsd</B> on Linux is typically a package like <I>netcat-openbsd</I> or a symlink. It adheres closely to the OpenBSD <I>netcat</I> behavior, which notably <B>lacks</B> the <B>-e</B> (execute) or <B>-c</B> (command) options found in some older or traditional <I>netcat</I> implementations. This design choice enhances security by preventing direct command execution via network connections, making it safer by default but requiring external piping for shell binding or command execution.<br><br>While versatile, it should be used with caution in production environments, especially when listening on open ports, to avoid exposing services or sensitive data.


title: CLIENT/SERVER MODES
content:
<B>nc_openbsd</B> can function both as a client connecting to a remote host and a server listening for incoming connections. In <I>client mode</I> (default), it connects to a specified <I>hostname</I> and <I>port</I>. In <I>server mode</I>, activated with the <B>-l</B> option, it listens on a designated <I>port</I>, making it useful for simple data transfer or setting up temporary network services.


title: PORT SCANNING WITH -Z
content:
The <B>-z</B> option enables <I>zero-I/O mode</I>, which is perfect for efficient port scanning. When used, <B>nc_openbsd</B> attempts to establish a connection but immediately closes it after determining if the port is open, without sending any data. This makes it faster and less intrusive than a full connection for simple port availability checks, often combined with verbose output (<B>-v</B>).


title: FILE TRANSFER
content:
<B>nc_openbsd</B> can be easily used for basic file transfer between systems. On the sending side, the file can be piped into <B>nc_openbsd</B> which connects to a listening instance. On the receiving side, <B>nc_openbsd</B> listens on a port and pipes incoming data to a file. For example: <I>Sender: cat file.txt | nc_openbsd &lt;receiver_ip&gt; &lt;port&gt;</I>; <I>Receiver: nc_openbsd -l -p &lt;port&gt; &gt; received_file.txt</I>.


title: HISTORY
content:
The original <I>netcat</I> was written by <B>Hobbit</B> in 1995, quickly gaining legendary status as the "TCP/IP Swiss Army knife." Its simplicity and raw power made it a favorite for network diagnostics and penetration testing. While <I>netcat</I> saw various forks and implementations, the OpenBSD project developed and maintained its own version, aiming for a cleaner, more secure, and robust codebase. This OpenBSD variant, known as <B>nc</B>, became a de-facto standard due to its reliability and specific features. On many Linux distributions, <B>nc_openbsd</B> or <B>netcat-openbsd</B> refers to this ported OpenBSD implementation, providing a consistent and feature-rich <I>netcat</I> experience, distinct from older "traditional" <I>netcat</I> versions.


title: PARAMETERS
content:
<b>-A months</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <B>months</B> after the current month. For example, <I>-A 3</I> shows the current month and the next three.<br><br><b>-B months</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <B>months</B> before the current month. For example, <I>-B 2</I> shows the current month and the previous two.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the Julian calendar for output, showing dates according to the Julian calendar system.<br><br><b>-C | -c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays output in the traditional <I>cal</I> format, with <B>Sunday</B> as the first day of the week.<br><br><b>-d yyyy-mm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the calendar for a specific month and year, e.g., <B>2023-12</B>.<br><br><b>-H yyyy-mm-dd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Highlights a specific date in the calendar, e.g., <B>2024-07-15</B>. Useful for marking appointments or special days.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns off highlighting of the current day. By default, today's date is highlighted.<br><br><b>-J</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays Julian dates (day of year) for each day, numbered from 1 to 365 (or 366 for leap years).<br><br><b>-M | -m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets <B>Monday</B> as the first day of the week. This is the default behaviour of <I>ncal</I>.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the date of Easter for the specified year. If no year is given, it defaults to the current year.<br><br><b>-S digits</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the number of spaces between month columns in the output.<br><br><b>-s country</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a country for Easter calculation or regional formatting, although its practical impact varies.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>ncal</I> command.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the number of the week below each week. Week numbers are typically ISO 8601 compliant.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a calendar for the entire current year.<br><br><b>month [year]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the calendar for a specific <B>month</B> (1-12) and optionally <B>year</B> (1-9999). If only month is provided, the current year is assumed.<br><br>


title: DESCRIPTION
content:
ncal is a modern and enhanced version of the traditional <I>cal</I> command, designed to display a calendar on the terminal. By default, ncal adheres to the <B>ISO 8601 standard</B>, presenting weeks starting on <B>Monday</B>. This distinguishes it from <I>cal</I>, which typically starts weeks on Sunday. <br><br>Beyond its default Monday-first view, ncal offers a rich set of features including the ability to display <B>multiple months</B> before or after the current one, show <B>Julian dates</B> (day of year), and highlight a <B>specific date</B>. It can also print the <B>date of Easter</B> for a given year. For users accustomed to <I>cal</I>'s layout, ncal provides options to emulate its Sunday-first week display. Its flexibility and adherence to international standards make it a powerful tool for calendar viewing in the Linux environment.


title: CAVEATS
content:
ncal defaults to <B>Monday</B> as the first day of the week, aligning with <B>ISO 8601</B>. This differs from the traditional <I>cal</I> command, which typically uses <B>Sunday</B> as the first day. Users expecting <I>cal</I>'s default behavior should use the <I>-C</I> or <I>-c</I> option.<br><br>Easter calculation is based on the Gregorian calendar.


title: <B>ENVIRONMENT</B>
content:
The <B>LC_TIME</B> environment variable influences the display of month and weekday names, respecting locale settings. The <B>TZ</B> environment variable determines the timezone used for displaying the current date and time.


title: <B>EXIT STATUS</B>
content:
The <I>ncal</I> command exits with a status of <B>0</B> on successful execution, and a non-zero value (<B>>0</B>) if an error or invalid usage occurs.


title: HISTORY
content:
ncal first appeared in <B>NetBSD 1.5</B> as a more feature-rich alternative to the original <I>cal</I> command. Its development aimed to provide greater flexibility, particularly in supporting <B>ISO 8601</B> week numbering (Monday-first) and enhanced calendar display options such as multiple month views and date highlighting. It has since been adopted by other Unix-like systems, including <B>Linux</B>, offering a modern and standards-compliant calendar utility.


title: PARAMETERS
content:
<b><b>-l</b>, <b>--listen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listen for incoming connections rather than initiating a connection to a remote host.<br><br><b><b>-p</b>, <b>--port</b> <i>&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the source port for client connections or the listening port for server mode.<br><br><b><b>-u</b>, <b>--udp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use UDP for connections instead of the default TCP.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity (use multiple times for more details) to display connection status, errors, and data flow.<br><br><b><b>-z</b>, <b>--zero-io</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zero-I/O mode. Report status of listening or connecting without sending any data. Useful for port scanning.<br><br><b><b>--ssl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable SSL encryption for the connection. <b>ncat</b> will act as an SSL client or server.<br><br><b><b>-c</b>, <b>--sh-exec</b> <i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the specified command via <i>/bin/sh</i> after a connection is established. Standard input/output are redirected to the network connection.<br><br><b><b>-e</b>, <b>--exec</b> <i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the specified command directly (without <i>/bin/sh</i>) after a connection is established. Standard input/output are redirected to the network connection.<br><br><b><b>-k</b>, <b>--keep-open</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;In listen mode, keep the connection open after a client disconnects to accept multiple connections.<br><br><b><b>--proxy</b> <i>&lt;addr:port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect through a specified HTTP or SOCKS proxy server.<br><br><b><b>--proxy-type</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the proxy type: <i>http</i>, <i>socks4</i>, or <i>socks5</i>.<br><br><b><b>-6</b>, <b>--ipv6</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use IPv6 only. By default, <b>ncat</b> attempts to use IPv6 if supported and falls back to IPv4.<br><br><b><b>--broker</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable broker mode, allowing multiple clients to connect to <b>ncat</b>, and all data sent by one client is relayed to all others.<br><br><b><b>--chat</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable chat mode, similar to <b>--broker</b> but with a prefix for each message indicating the source.<br><br><b><b>--telnet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Negotiate Telnet options with the remote host. Useful when connecting to Telnet services.<br><br><b><b>--allow</b> <i>&lt;addr(s)&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow only specified hosts/networks to connect when in listen mode. Supports comma-separated lists and CIDR notation.<br><br><b><b>--deny</b> <i>&lt;addr(s)&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deny specified hosts/networks from connecting when in listen mode. Overrides <b>--allow</b>.<br><br>


title: DESCRIPTION
content:
<b>ncat</b>, part of the Nmap Project, is a powerful and versatile networking utility that reads and writes data across network connections using TCP or UDP. It's a modern re-implementation and enhancement of the classic Netcat tool, designed to be more reliable, secure, and feature-rich. <b>ncat</b> supports a wide array of functionalities, including IPv4/IPv6, SSL encryption, HTTP/SOCKS proxying, connection brokering, port scanning, and general data transfer. Its flexibility makes it an invaluable tool for network administrators, security professionals, and developers for tasks ranging from simple data transfer and server testing to complex network debugging and security analysis. It can operate in various modes, such as a client connecting to a server, a server listening for incoming connections, or even as a proxy.


title: CAVEATS
content:
When using <b>ncat</b> in listen mode with options like <b>-e</b> or <b>-c</b> to execute commands, be extremely cautious as this can create a significant security vulnerability (e.g., a 'reverse shell') if the host running <b>ncat</b> is exposed to untrusted networks. Always ensure proper firewall rules and access controls are in place. Listening on privileged ports (ports below 1024) typically requires root privileges. SSL/TLS functionality relies on the underlying OpenSSL library, and its behavior may vary depending on the OpenSSL version and configuration.


title: COMMON USE CASES
content:
<ul><li><i>Simple TCP Client/Server:</i> Use <b>ncat -l -p 12345</b> on one machine to listen, and <b>ncat localhost 12345</b> on another to connect and exchange text.</li><li><i>File Transfer:</i> On the sender: <b>cat file.txt | ncat &lt;receiver_IP&gt; 12345</b>. On the receiver: <b>ncat -l -p 12345 > file.txt</b>.</li><li><i>Port Scanning:</i> <b>ncat -vz &lt;target_IP&gt; 80 443 22</b> (scans multiple ports on a target).</li><li><i>Simple HTTP Server:</i> <b>ncat -l -p 8080 --sh-exec 'echo "HTTP/1.1 200 OK

<h1>Hello Ncat!</h1>"'</b> (serves a simple HTML page).</li><li><i>SSL Encrypted Connection:</i> <b>ncat --ssl -l -p 4433</b> (server) and <b>ncat --ssl &lt;server_IP&gt; 4433</b> (client) for secure communication.</li></ul>


title: HISTORY
content:
<b>ncat</b> is a modern, feature-rich reimplementation of the classic <i>netcat</i> utility, developed as part of the Nmap Project. The original <i>netcat</i> (often just called <i>nc</i>) was a legendary tool but suffered from a lack of consistent features across its various implementations and often lacked ongoing maintenance. <b>ncat</b> was created to address these issues by providing a unified, well-maintained, and enhanced version of <i>netcat</i>. It began development around 2007, introducing capabilities like SSL support, HTTP/SOCKS proxying, connection brokering, and better cross-platform compatibility, making it the preferred choice for many modern network tasks.


title: SYNOPSIS
content:
<pre><b>ncdu</b> [<i>options</i>] [<i>directory</i>]</pre><br><pre><b>ncdu</b> -f <i>file</i> [<i>options</i>]</pre>


title: PARAMETERS
content:
<b><b>-x</b>, <b>--one-file-system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not cross filesystem boundaries. Only scan files on the same filesystem as the starting directory.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable quiet mode. Don't show progress or errors during the scan.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version of ncdu and exit.<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>-o</b> <i>FILE</i>, <b>--output</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Export the scanned analysis to a file, which can be later viewed with <b>-f</b>.<br><br><b><b>-f</b> <i>FILE</i>, <b>--input</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read analysis from a previously saved file instead of scanning the disk.<br><br><b><b>-r</b>, <b>--read-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start in read-only mode, disabling any file deletion options.<br><br><b><b>-0</b>, <b>--null</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When exporting to a file, use null separators for directory paths (useful for scripting).<br><br><b><b>-1</b>, <b>--no-confirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ask for confirmation when deleting files (use with extreme caution).<br><br><b><b>-a</b>, <b>--apparent-size</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display apparent size instead of disk usage (size of file content, not including disk overhead).<br><br><b><b>-L</b>, <b>--follow-symlinks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Follow symbolic links and count their target's size.<br><br><b><b>-e</b> <i>PATTERN</i>, <b>--exclude</b> <i>PATTERN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the specified pattern.<br><br><b><b>-X</b> <i>FILE</i>, <b>--exclude-from</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read exclude patterns from the specified file, one pattern per line.<br><br><b><b>-p</b>, <b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force showing the scanning progress during startup, even if output is redirected.<br><br><b><b>-P</b>, <b>--no-precalc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not precalculate directory sizes during the initial scan (may be slower).<br><br><b><b>-s</b>, <b>--si</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use SI units (powers of 1000) for disk usage instead of binary units (powers of 1024).<br><br><b><b>-u</b>, <b>--no-unicode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use Unicode drawing characters, fallback to ASCII instead.<br><br>


title: DESCRIPTION
content:
<i>ncdu</i> (NCurses Disk Usage) is a fast, easy-to-use disk usage analyzer designed for command-line environments. It provides an interactive, ncurses-based graphical interface that allows users to quickly scan and browse disk space usage. Unlike traditional command-line tools like <i>du</i>, <i>ncdu</i> offers an intuitive tree-like view of directories and files, enabling users to navigate through the filesystem, identify large files or directories, and even delete them to free up space directly from the interface. It's particularly useful for quickly diagnosing disk space issues on servers or systems without a graphical desktop environment, providing real-time feedback and efficient navigation through large directory structures. Its speed and interactivity make it a popular choice for system administrators and users looking to manage disk space effectively.


title: CAVEATS
content:
<i>ncdu</i> requires an ncurses-compatible terminal. While it offers file deletion capabilities, it's crucial to exercise extreme caution as deletions are permanent and cannot be undone. The disk usage reported by <i>ncdu</i> might sometimes differ from other tools like <i>du</i> due to differing default block sizes, handling of sparse files, or whether apparent size versus actual disk usage is displayed. Running <i>ncdu</i> on extremely large directory structures can still consume significant system resources during the initial scan.


title: INTERACTIVE CONTROLS
content:
<i>ncdu</i> offers a rich set of interactive keyboard controls for navigation and actions:<br><b>Arrow keys</b>: Navigate up/down/left/right.<br><b>Enter</b>: Go into selected directory.<br><b>Backspace</b>: Go to parent directory.<br><b>d</b>: Delete selected file or directory (prompts for confirmation unless <b>-1</b> is used).<br><b>g</b>: Toggle display of percentage bars and graphs.<br><b>s</b>: Sort by size (toggle ascending/descending).<br><b>n</b>: Sort by name (toggle ascending/descending).<br><b>C</b>: Sort by items (number of files/directories within, toggle ascending/descending).<br><b>M</b>: Sort by last modified time (toggle ascending/descending).<br><b>A</b>: Toggle apparent size vs. disk usage.<br><b>r</b>: Rescan current directory.<br><b>?</b>: Show help screen with all controls.<br><b>q</b>: Quit ncdu.


title: UNDERSTANDING DISK USAGE VS. APPARENT SIZE
content:
By default, <i>ncdu</i> displays the <b>disk usage</b>, which is the actual amount of disk space occupied by a file or directory. This accounts for the filesystem's block size, sparse files, and other overhead. The <b>apparent size</b> (toggled with '<b>A</b>' key or <b>-a</b> option) refers to the logical size of the file, i.e., the number of bytes in its content. For most files, these values are similar, but for sparse files, files on filesystems with large block sizes, or files with hard links, they can differ significantly. When trying to free space, disk usage is usually the more relevant metric.


title: HISTORY
content:
<i>ncdu</i> was created by Yoran Heling around 2007-2008 as a tool to address the need for a fast, interactive way to analyze disk space usage directly from the command line, especially on remote servers where graphical tools were unavailable. It was designed to provide a user-friendly ncurses interface similar to the popular <i>du</i> command, but with the added benefits of interactive navigation, sorting, and direct file deletion. Its development aimed to offer a more efficient alternative to repeatedly running <i>du</i> with various options to pinpoint disk space hogs. Over the years, it has gained widespread adoption among system administrators and power users for its simplicity, speed, and effectiveness in managing disk space.


title: SEE ALSO
content:
<i>du(1)</i>: Estimate file space usage., <i>df(1)</i>: Report file system disk space usage., <i>find(1)</i>: Search for files in a directory hierarchy., <i>tree(1)</i>: List contents of directories in a tree-like format., <i>ls(1)</i>: List directory contents.


title: SYNOPSIS
content:
ncftp [<I>options</I>] [<I>host</I>]<br><br>Connects to an FTP server for interactive file transfers. For non-interactive operations, consider <I>ncftpget</I> and <I>ncftpput</I>.


title: PARAMETERS
content:
<b>-u <I>user</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username to log in with.<br><br><b>-p <I>pass</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the password for authentication. <b>Caution:</b> Using this option exposes your password in the process list and shell history.<br><br><b>-P <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number on the remote FTP server to connect to.<br><br><b>-d <I>spath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the remote starting path (directory) after logging in.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces ASCII mode for all file transfers by default.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about operations.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables resuming partial transfers for downloads and uploads.<br><br><b>-o <I>var=val</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an advanced option specified by <I>var</I> to <I>val</I>. Consult the ncftp man page for available variables.<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces ncftp to use a random passive port for data connections, which can be useful with certain firewalls.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for ncftp.<br><br>


title: DESCRIPTION
content:
ncftp is a free, enhanced command-line FTP client program designed to be significantly more user-friendly and feature-rich than traditional ftp clients. It provides a robust interface for transferring files to and from remote servers using the File Transfer Protocol. Key enhancements include command-line completion for filenames and commands, progress meters for ongoing transfers, a bookmarking system for frequently visited sites, background transfer capabilities, automatic retries for failed connections, and passive mode enabled by default for better firewall compatibility. ncftp supports both interactive sessions, allowing users to browse and manipulate remote directories, and batch mode operations for scripting. It aims to improve efficiency and reliability, particularly over unreliable network connections, by handling various network glitches gracefully. It also supports secure FTP (FTPS) for encrypted data transfers.


title: CAVEATS
content:
Using the <b>-p</b> option to specify a password on the command line is generally insecure as it exposes the password in the process list and shell history. It is recommended to use password prompting or ncftp's built-in <I>~/.ncftp/bookmarks</I> file for storing encrypted passwords. While ncftp supports FTPS (FTP over TLS/SSL) for secure transfers, the basic FTP protocol itself is inherently insecure, transferring credentials and data in plaintext unless FTPS is explicitly used and supported by the server. The FTP protocol's use of separate control and data connections can also pose challenges with complex firewall configurations.


title: INTERACTIVE MODE FEATURES
content:
In interactive mode, ncftp offers a rich set of commands and features. These include tab completion for local and remote filenames, a <I>bookmark</I> command to save and recall frequently visited sites, a <I>queue</I> command to manage pending transfers, and dynamic progress meters during file transfers. Standard commands like <I>ls</I>, <I>cd</I>, <I>get</I>, <I>put</I>, <I>mkdir</I>, <I>rm</I>, <I>pwd</I>, and <I>chmod</I> are available, often with enhanced capabilities compared to traditional FTP clients. The <I>open</I> command allows connecting to new hosts within the same session.


title: BACKGROUND TRANSFERS
content:
ncftp allows users to initiate file transfers in the background using commands such as <I>bgget</I> and <I>bgput</I>. This means the transfer proceeds without tying up the interactive session, allowing the user to continue browsing or perform other operations. Background transfers are managed by a queue, and their status can be monitored. This is particularly useful for large files or multiple transfers.


title: CONFIGURATION AND BOOKMARKS
content:
ncftp stores configuration and bookmark information in the <I>~/.ncftp</I> directory. The <I>bookmarks</I> file (or <I>bookmarks.db</I> for later versions) can store site details, including hostname, username, and encrypted passwords. This allows for quick and secure connections to frequently accessed FTP servers without typing credentials repeatedly. Advanced settings can be configured via environment variables or ncftp's internal variables.


title: HISTORY
content:
ncftp was originally developed by <I>Mike Gleason</I> in the mid-1990s as a superior alternative to the rudimentary standard <I>ftp</I> client shipped with Unix-like operating systems. It was designed from the ground up to address the shortcomings of <I>ftp</I>, focusing on user-friendliness, robustness, and advanced features such as resume support, bookmarking, and background transfers. Its development played a significant role in improving command-line FTP client usability, quickly gaining popularity among system administrators and users alike for its reliability and feature set, and has seen continuous development over the years.


title: PARAMETERS
content:
<b>-h, --host <I>hostname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to the MPD server on the specified hostname or IP address.<br><br><b>-p, --port <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to the MPD server on the specified port number.<br><br><b>-c, --config <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an alternative configuration file instead of the default.<br><br><b>-s, --screen <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start ncmpcpp directly on a specific screen (e.g., <I>playlist</I>, <I>browser</I>, <I>library</I>).<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of ncmpcpp.<br><br><b>-?, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command-line options.<br><br>


title: DESCRIPTION
content:
Ncmpcpp (<b>N</b>curses <b>M</b>usic <b>P</b>layer <b>C</b>lient <b>P</b>lus <b>P</b>lus) is a powerful, customizable, and feature-rich terminal-based client for the Music Player Daemon (MPD). Designed for command-line enthusiasts, it provides a comprehensive set of functionalities within a clean ncurses interface. Users can manage their music library, edit tags, create and modify playlists, browse the filesystem, view song lyrics, and enjoy an audio visualizer. It extends beyond basic playback control, offering advanced features like search capabilities, Last.fm integration, and seamless interaction with the underlying MPD server. Its lightweight nature and keyboard-driven interface make it an efficient choice for managing music without a graphical environment, providing a complete and highly responsive musical experience directly from the terminal.


title: CAVEATS
content:
Requires an active <I>Music Player Daemon</I> (MPD) server to function, as it acts as a client rather than a standalone player.<br>Initial configuration can be intricate due to its extensive customization options.<br>Performance of certain features, like the visualizer, may depend on terminal capabilities and system resources.


title: CONFIGURATION
content:
Ncmpcpp is highly configurable via its main configuration file, typically located at <I>~/.ncmpcpp/config</I>. This file allows users to extensively customize nearly every aspect of the client, including color schemes, keybindings, default screen layouts, visualizer settings, and various behavior options to tailor the experience to individual preferences.


title: KEYBINDINGS AND SCREENS
content:
The interface is primarily navigated using keyboard shortcuts, making it very efficient for power users. It features multiple distinct screens (e.g., playlist, file browser, library, tag editor, visualizer, lyrics, clock) which can be toggled via hotkeys, providing a multi-functional environment for music management.


title: HISTORY
content:
Ncmpcpp was developed as an enhanced successor to <I>ncmpc</I>, another ncurses-based MPD client. While <I>ncmpc</I> offered basic control, <I>ncmpcpp</I> significantly expanded functionality by integrating features such as a file system browser, tag editor, visualizer, and advanced playlist management. This evolution aimed to provide a more comprehensive and feature-rich experience for users who prefer managing their music library entirely within the terminal. Its continued development has focused on robustness, performance, and user customization, establishing it as a highly popular choice within the Linux terminal music ecosystem.


title: PARAMETERS
content:
<b>-U <userlist></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing a list of usernames to try.<br><br><b>-P <passlist></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing a list of passwords to try.<br><br><b>-L <user:pass list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing user:password combinations (one per line).<br><br><b>-u <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a single username to attempt against the target.<br><br><b>-p <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a single password to attempt against the target.<br><br><b>-T <timing_template></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the timing template (e.g., Normal, Aggressive) to control scan speed.<br><br><b>--delay <milliseconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a minimum delay between probes to avoid overwhelming the target.<br><br><b>--connections <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum total number of concurrent connections Ncrack will use.<br><br><b>--probe-timeout <milliseconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the timeout for a single authentication probe.<br><br><b>--max-retries <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of retries for failed authentication probes.<br><br><b>-oN <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the scan results in normal readable format to the specified file.<br><br><b>-oX <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the scan results in XML format to the specified file.<br><br><b>-oA <basename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in all common formats (normal, XML, greppable) using the specified basename.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity level, showing more details about the scan process.<br><br><b>-vv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity level even more for extensive details.<br><br><b>-d <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the debugging level (0-9) to output internal debug messages.<br><br><b>--reason</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the reason for each successful or failed authentication attempt.<br><br><b>--resume <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resume a previously interrupted cracking session from a saved file.<br><br><b>--script <script></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load and execute an Ncrack script (written in Lua) for custom logic.<br><br><b>--script-args <args></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide arguments to Ncrack scripts.<br><br><b>--no-host-discovery</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip the initial host discovery phase and assume targets are online.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display Ncrack's version number and exit.<br><br>


title: DESCRIPTION
content:
Ncrack is a powerful, high-performance network authentication cracking tool that is part of the Nmap security scanner project. It's designed to help security professionals and ethical hackers test the strength of network authentication credentials against various services. Unlike traditional cracking tools, Ncrack is built with a focus on speed and flexibility, utilizing Nmap's robust networking capabilities. It supports a wide array of protocols, including <b>SSH</b>, <b>FTP</b>, <b>HTTP</b>, <b>SMB</b>, <b>POP3</b>, <b>Telnet</b>, <b>RDP</b>, <b>VNC</b>, <b>MySQL</b>, <b>PostgreSQL</b>, and more. Ncrack can perform dictionary attacks using wordlists, brute-force attacks, or a combination of both. Its modular architecture allows for easy extension and customization, including scripting capabilities via Lua, making it a versatile tool for auditing the security of network services against weak or common passwords. Its primary use cases involve penetration testing and ensuring robust password policies are enforced.


title: CAVEATS
content:
Ncrack is a powerful tool designed for security auditing and should only be used on systems for which you have explicit, written permission. <i>Unauthorized use can lead to severe legal consequences.</i> Running Ncrack, especially with aggressive timing or large wordlists, can generate significant network traffic and consume considerable system resources on both the attacker and target machines. It's crucial to understand that Ncrack focuses on authentication cracking and is not a comprehensive vulnerability scanner; it won't detect other types of security flaws. Results should be interpreted carefully, as network issues or specific service behaviors can sometimes lead to false positives or negatives.


title: TARGET SPECIFICATION
content:
Ncrack requires a target to operate on. This can be a single host IP address or hostname. For specific services, the target can be specified using a URL-like format such as <b>protocol://host[:port]</b>. For example, <b>ssh://192.168.1.1</b> or <b>http://example.com:8080</b>.


title: SUPPORTED PROTOCOLS
content:
Ncrack supports a wide range of common network authentication protocols, making it highly versatile. These include, but are not limited to: <b>SSH</b>, <b>FTP</b>, <b>HTTP</b> (Basic, Digest, NTLM), <b>SMB</b>, <b>POP3</b>, <b>IMAP</b>, <b>Telnet</b>, <b>RDP</b>, <b>VNC</b>, <b>MySQL</b>, <b>PostgreSQL</b>, <b>Redis</b>, <b>SIP</b>, and various VPN protocols. The specific protocol handler is often inferred from the port or explicitly stated in the target specification.


title: LUA SCRIPTING ENGINE
content:
Ncrack incorporates a powerful Lua-based scripting engine, similar to Nmap's NSE (Nmap Scripting Engine). This allows users to extend Ncrack's functionality, create custom authentication checks, parse non-standard responses, or integrate with other tools. Scripts can be loaded using the <b>--script</b> option, offering immense flexibility for advanced auditing scenarios.


title: HISTORY
content:
Ncrack emerged as a component of the renowned Nmap security scanner project, spearheaded by Fyodor. Its development began around 2009, with the goal of creating a modern, high-performance network authentication cracking tool that could leverage Nmap's robust networking stack and extensive protocol support. Before Ncrack, Nmap primarily focused on port scanning and service detection; Ncrack extended its capabilities into the realm of credential auditing. It was designed to overcome some limitations of existing network crackers, offering better performance, modularity, and integration with the Nmap ecosystem, including its scriptable engine (NSE). Since its inception, Ncrack has become a valuable tool for penetration testers and security auditors to assess the strength of network service credentials.


title: PARAMETERS
content:
<b>-o <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output report file name. The default extension is '.ncu-rep'.<br><br><b>--set <I>set_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collects a predefined set of metrics. Common sets include 'full', 'basic', 'memory', and 'compute'.<br><br><b>--metrics <I>metrics_list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of specific metrics to collect. Overrides '--set'.<br><br><b>--kernel-name <I>kernel_regex</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Profiles only kernels whose names match the given regular expression.<br><br><b>--replay-mode <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures how kernel launches are replayed for metric collection. Modes include 'kernel' (default, per-kernel replay) and 'application' (replays the entire application).<br><br><b>--export <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports the profiling data into a specified format like 'csv', 'html', or 'sqlite'. Defaults to '.ncu-rep'.<br><br><b>--device <I>id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target GPU device to profile by its ID.<br><br><b>--target-processes <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls profiling behavior for child processes. Modes include 'all', 'none', 'host', 'cuda'.<br><br><b>--cpu-sampling-mode <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables and configures CPU instruction sampling, e.g., 'none', 'host-thread-id'.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or a specific option.<br><br>


title: DESCRIPTION
content:
<i>ncu</i> (NVIDIA CUDA Unified Profiler) is a powerful command-line tool designed for detailed performance analysis of CUDA applications. It allows developers to collect and analyze a wide range of metrics related to GPU utilization, memory access patterns, kernel execution, and API overhead. By identifying performance bottlenecks and inefficient code sections, <i>ncu</i> helps optimize CUDA applications for maximum efficiency on NVIDIA GPUs. It is the successor to <i>nvprof</i> for detailed GPU profiling and forms a core component of the NVIDIA Nsight Compute ecosystem. <i>ncu</i> supports profiling specific kernels or entire application runs, and can generate comprehensive reports in various formats for in-depth investigation and visualization.


title: CAVEATS
content:
<b>ncu</b> requires an NVIDIA GPU and the CUDA Toolkit to function.<br>Profiling can introduce significant overhead to application execution, especially with extensive metric collection.<br>Analyzing large-scale applications or collecting many metrics can generate very large report files.<br>Understanding the collected metrics and interpreting the results often requires a good grasp of CUDA programming and GPU architecture.


title: OUTPUT FORMATS
content:
Beyond the default <b>.ncu-rep</b> binary format, <b>ncu</b> can export profiling data into several user-friendly formats using the <b>--export</b> option:<br><b>csv</b>: For tabular data analysis in spreadsheets.<br><b>html</b>: A standalone HTML report for easy viewing in a web browser.<br><b>sqlite</b>: A database format for programmatic access and custom queries.<br>These options facilitate integration with other analysis tools and custom visualization scripts.


title: METRIC COLLECTION SETS
content:
<b>ncu</b> provides predefined sets of metrics for common profiling scenarios, simplifying the collection process:<br><b>basic</b>: A small set of essential metrics for quick overview.<br><b>full</b>: A comprehensive set of all available metrics, useful for deep dives.<br><b>memory</b>: Metrics focused on memory access patterns and bandwidth.<br><b>compute</b>: Metrics related to arithmetic operations and compute unit utilization.<br>Users can also specify individual metrics using the <b>--metrics</b> option for highly customized profiling.


title: HISTORY
content:
<b>ncu</b> is the direct successor to <i>nvprof</i>, which was the primary command-line profiler for CUDA applications for many years. With the introduction of the Nsight Compute suite, <i>ncu</i> was developed to offer more advanced features, deeper insights into GPU hardware units, and a more robust metric collection system. It leverages a modern architecture that allows for more flexible and detailed profiling, making it the recommended tool for GPU-specific performance analysis within the NVIDIA ecosystem.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version of the ncurses library.<br><br><b>--libs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the linker flags required to link against the ncurses library. This typically includes <i>-L</i> (library path) and <i>-l</i> (library name) options.<br><br><b>--cflags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the preprocessor and compiler flags required to compile programs using ncurses headers. This often includes <i>-I</i> (include path) options.<br><br><b>--prefix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the installation prefix of the ncurses library (e.g., <i>/usr/local</i>).<br><br><b>--exec-prefix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the installation exec_prefix of the ncurses library, which is usually the same as <i>prefix</i>.<br><br><b>--variable=<i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the value of a specific internal configuration variable, such as <i>TERMINFO_PATH</i> or <i>NCURSES_VERSION</i>.<br><br><b>--terminfo-libs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print linker flags for the terminfo library, which is sometimes separated from the main ncurses library.<br><br><b>--tic-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the path to the <b>tic</b> utility, used for compiling terminfo source files.<br><br><b>--tdb-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the path to the terminfo database if ncurses was built with a bundled one.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options.<br><br><b>--info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed configuration information (less common, but sometimes available).<br><br>


title: DESCRIPTION
content:
The <b>ncurses5-config</b> command is a utility script designed to help developers compile and link programs against the ncurses library, specifically for the 5.x series of ncurses. It retrieves various build flags such as compiler options (CFLAGS), linker options (LDFLAGS), and libraries (LIBS) required for successful compilation.<br><br>Historically, before the widespread adoption of tools like <b>pkg-config</b>, these <i>-config</i> scripts were common ways for libraries to provide their necessary build information. <b>ncurses5-config</b> automates the process of finding the correct header paths, library directories, and specific library names, ensuring that applications linking against ncurses can be built correctly across different system configurations. This simplifies Makefile creation and integration into build systems like GNU Autotools, preventing developers from having to hardcode system-specific paths or flags.


title: CAVEATS
content:
This utility is specific to the ncurses 5.x library series. For newer versions of ncurses (e.g., 6.x), a different <i>ncursesw6-config</i> or similar script might be available, or more commonly, the library might fully rely on <b>pkg-config(1)</b> for providing build flags. Its availability depends on whether the <i>ncurses-devel</i> or <i>libncurses-dev</i> package is installed on the system.


title: TYPICAL USAGE
content:
To compile a C program (e.g., <i>myprogram.c</i>) that uses ncurses, you would typically integrate the output of <b>ncurses5-config</b> into your compiler command. For instance, to get the necessary preprocessor and compiler flags, you would use <b>ncurses5-config --cflags</b>, and for linker flags, <b>ncurses5-config --libs</b>. This ensures the compiler finds the ncurses headers and the linker finds the ncurses libraries, automating the build process.


title: INTEGRATION WITH BUILD SYSTEMS
content:
In build systems like <b>Makefiles</b>, the output of <b>ncurses5-config</b> can be captured into variables using shell command substitution (e.g., <b>$(shell ncurses5-config --cflags)</b>). This makes the build process robust and portable, as it dynamically determines the correct paths and flags based on the installed ncurses library, rather than relying on hardcoded values.


title: HISTORY
content:
The concept of <i>-config</i> scripts emerged in the Unix/Linux ecosystem as a straightforward way for libraries to expose their build requirements. <b>ncurses5-config</b> specifically represents the configuration script provided with the 5.x major release series of the ncurses library. Ncurses itself is a free software emulation of the System V Release 4.0 curses library, developed and maintained by the GNU Ncurses project, with its development spanning decades. These <i>-config</i> scripts paved the way for more sophisticated tools like <b>pkg-config(1)</b>, which generalized the approach to serve many libraries.


title: PARAMETERS
content:
<b><b>--prefix</b>[=<i>DIR</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays or sets the installation prefix for the library.<br><br><b><b>--exec-prefix</b>[=<i>DIR</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays or sets the installation prefix for executables.<br><br><b><b>--cflags</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the necessary preprocessor and compiler flags for building applications.<br><br><b><b>--libs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the necessary linker flags and library paths for linking applications.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed <b>ncursesw5</b> library version.<br><br><b><b>--mouse-libs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs linker flags specifically for ncurses mouse support.<br><br><b><b>--termcap-libs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs linker flags for compatibility with the older <i>termcap</i> library.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options.<br><br>


title: DESCRIPTION
content:
<b>ncursesw5-config</b> is a specialized utility script designed to provide crucial configuration information about the installed <b>ncursesw5</b> library on a Linux system. Its primary role is to assist build systems, such as <i>configure</i> scripts and Makefiles, in correctly compiling and linking applications that utilize the <b>ncursesw5</b> library. By querying the system for accurate library paths, include paths, and specific linker flags, it eliminates the need for developers to hardcode these details, thereby enhancing the portability and reliability of software builds across diverse environments.<br>The 'w' suffix in <b>ncursesw5</b> signifies comprehensive support for wide characters, essential for handling multi-byte character sets like Unicode (UTF-8). The '5' indicates that this utility specifically targets version 5 of the ncurses library, ensuring compatibility with that particular major release.


title: CAVEATS
content:
This command is typically not invoked directly by end-users but rather by automated build systems (e.g., <i>configure</i> scripts, Makefiles) to abstract away platform-specific library configurations. Its output is highly dependent on the exact installation of the <b>ncursesw5</b> library. On newer systems, <b>ncursesw6-config</b> or a more generic <b>ncurses-config</b> might be used.


title: TYPICAL USAGE IN BUILD SYSTEMS
content:
<b>ncursesw5-config</b> is frequently embedded in build commands within Makefiles or shell scripts to automate compilation and linking. For instance, to compile a C program named <i>myapp.c</i> that uses <b>ncursesw5</b>, one might use:<br><i>gcc myapp.c $(ncursesw5-config --cflags --libs) -o myapp</i><br>This command dynamically retrieves the correct include paths and library linkage flags, ensuring that the application builds successfully across different environments without hardcoded paths.


title: HISTORY
content:
The <b>ncurses</b> library (New Curses) is a widely used free software implementation of the System V Release 4.0 curses API, providing robust text-based user interface capabilities. The introduction of configuration scripts like <b>ncursesw5-config</b> standardized how applications discover and link against the library, replacing manual configuration. The 'w' suffix denotes the inclusion of wide-character support (Unicode/UTF-8), which became increasingly important for internationalization. Version 5 was a significant and widely adopted release, leading to dedicated configuration utilities to ensure compatibility and ease of development for applications targeting this specific version.


title: PARAMETERS
content:
<b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output information in JSON format, useful for programmatic parsing.<br><br><b>--human</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display output in a human-readable format, often with sizes formatted (e.g., 1.5GB).<br><br><b>--unit=&lt;units&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify output units for sizes (e.g., <i>B</i>, <i>kB</i>, <i>MB</i>, <i>GB</i>, <i>TB</i>). Overrides <i>--human</i> if both are used.<br><br><b>--terse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output for commands like create, enable, disable, or zero, showing only essential information.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force an operation that might otherwise be rejected due to safety checks or warnings.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug messages, providing more detailed output for troubleshooting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <b>ndctl</b> utility's version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message for the command or a specific subcommand.<br><br>


title: DESCRIPTION
content:
<b>ndctl</b> is a command-line utility in Linux for managing NVDIMM (Non-Volatile Dual In-line Memory Module) devices and their associated persistent memory regions. It provides a comprehensive set of tools to discover, configure, and monitor NVDIMM hardware. Administrators use <b>ndctl</b> to create, modify, and delete persistent memory namespaces, which are addressable regions of non-volatile memory that applications can directly access. These namespaces can be configured in various modes, such as <i>fsdax</i> (file system DAX) for use with file systems like XFS or EXT4, or <i>devdax</i> (device DAX) for raw block device-like access. <b>ndctl</b> also allows inspecting NVDIMM health, firmware details, and interleave sets, crucial for performance and reliability in persistent memory computing environments.


title: CAVEATS
content:
Incorrect configuration of NVDIMM devices using <b>ndctl</b> can lead to data loss, inaccessible memory, or system instability. Many operations require elevated privileges (root user or sudo). Utilizing persistent memory effectively often requires applications to be specifically designed for direct access (DAX) programming models, which differ from traditional block storage I/O.


title: COMMON SUBCOMMANDS
content:
<b>ndctl</b> operates using a subcommand-driven interface, where specific actions are performed via distinct commands. Common subcommands include: <i>list</i> (to enumerate detected NVDIMM devices, regions, and namespaces), <i>create-namespace</i>, <i>destroy-namespace</i> (to manage logical persistent memory devices), <i>enable-region</i>, <i>disable-region</i> (to control the active state of physical NVDIMM regions), and <i>zero-namespace</i> (to securely clear data within a specified namespace).


title: PERSISTENT MEMORY CONCEPTS
content:
<b>ndctl</b> primarily manages two key persistent memory concepts: <i>regions</i> and <i>namespaces</i>. <i>Regions</i> represent physical NVDIMM memory areas, often spanning multiple physical NVDIMM modules. From these regions, <i>namespaces</i> are carved out as logical persistent memory devices, which can then be exposed to the operating system. Namespaces can be configured in <i>fsdax</i> mode (allowing file systems like XFS or EXT4 to leverage direct access for mmap-ed files) or <i>devdax</i> mode (providing raw device-like access for direct application memory-mapping), influencing how applications interact with the persistent memory.


title: HISTORY
content:
<b>ndctl</b> is a core component of the <i>libndctl</i> project, a user-space library and tools suite developed to standardize the management of NVDIMM devices and persistent memory within the Linux ecosystem. Its development closely tracks the upstream Linux kernel's persistent memory support, emerging to provide robust, vendor-agnostic configuration and utilization capabilities as non-volatile memory technologies became more prevalent.


title: SYNOPSIS
content:
<i>neato</i> [<i>options</i>] [<i>files</i>]<br><br><i>Example: neato -Tpng input.dot -o output.png</i>


title: PARAMETERS
content:
<b>-T<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the graph. Common formats include <b>png</b>, <b>svg</b>, <b>pdf</b>, <b>ps</b>, and <b>dot</b>. If not specified, the default output format is usually DOT.<br><br><b>-o<outfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated graph to the specified output file. If this option is omitted, <i>neato</i> will send the output to standard output (stdout).<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, displaying progress messages and additional information during the graph processing and layout stages.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for the <i>neato</i> command and then exits, without processing any graph input.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders the graph to standard output (stdout) in PostScript format and then pipes this output to a PostScript printer command (e.g., <i>lpr</i>), typically used for direct printing.<br><br><b>-K<layout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the graph to be processed by a specific layout engine, even if the command invoked is <i>neato</i>. Other engines include <b>dot</b>, <b>fdp</b>, <b>sfdp</b>, <b>twopi</b>, and <b>circo</b>.<br><br>


title: DESCRIPTION
content:
<i>neato</i> is a core component of the <b>Graphviz</b> suite of open-source graph visualization software. It specializes in drawing undirected graphs using a <b>spring model</b> or <b>force-directed</b> algorithm. This approach treats nodes as physical objects and edges as springs, iteratively adjusting their positions to find an equilibrium state where all forces balance. The result is an aesthetically pleasing layout that often highlights symmetry and the grouping of tightly connected components. <i>neato</i> is particularly well-suited for graphs where the relationships are non-hierarchical. It accepts graph descriptions in the <i>DOT language</i> and can generate output in numerous formats, including various image types (PNG, JPEG, SVG) and document formats (PDF, PostScript).


title: CAVEATS
content:
While versatile, <i>neato</i> is optimized for <b>undirected graphs</b>. For graphs with a strong directional flow or hierarchical structure, the <b>dot</b> layout engine (also part of <i>Graphviz</i>) typically produces more intuitive and readable layouts. Processing very large or highly dense graphs with <i>neato</i> can be computationally intensive and consume significant system resources.


title: INPUT LANGUAGE
content:
<i>neato</i>, like all <i>Graphviz</i> tools, exclusively uses the <b>DOT language</b> for graph description. This is a plain-text graph description language that allows users to define nodes, edges, and their associated attributes in a structured format.


title: ALGORITHM TYPE
content:
The primary algorithm employed by <i>neato</i> is a <b>force-directed</b> or <b>spring-model</b> layout. This method simulates physical forces: attractive forces between connected nodes (like springs) and repulsive forces between all nodes. The layout is achieved by iteratively moving nodes until the system reaches a state of minimal energy, resulting in a balanced and often organic-looking arrangement.


title: HISTORY
content:
<i>neato</i> is a key component of the <b>Graphviz</b> (Graph Visualization) open-source software package, which originated from <b>AT&T Labs Research</b>. Developed to provide robust and automated solutions for visualizing complex graphs, <i>neato</i> specifically addresses the challenges of laying out undirected networks where aesthetic principles like symmetry and clustered groupings are paramount. Its creation, alongside other specialized layout programs like <i>dot</i>, has significantly advanced the field of automated graph drawing, making sophisticated graph visualizations accessible for diverse applications ranging from network topology to biological pathways.


title: PARAMETERS
content:
<b><I>file</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more files to be edited. If no file is specified, <B>ned</B> typically starts with an empty buffer.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the printing of character counts by 'e', 'r', and 'w' commands, and diagnostic messages for empty files.<br><br><b>-p <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses <I>string</I> as the interactive prompt. This is usually a single character like '*' or '?'. If not specified, <B>ned</B> often does not display a prompt by default.<br><br>


title: DESCRIPTION
content:
<B>ned</B> is a largely obscure and non-standard line editor for Unix-like operating systems. Unlike more common editors such as <B>vi</B>, <B>Vim</B>, or <B>Emacs</B>, <B>ned</B> operates in a line-by-line mode, primarily interacting via simple, single-character commands. It typically lacks a visual screen interface, making it suitable for scripting or use in environments where a full-screen terminal is unavailable or undesirable, such as remote SSH sessions with limited display capabilities, or very old systems.<br><br>Its command set usually involves specifying line numbers or ranges, followed by a command (like <I>p</I> for print, <I>d</I> for delete, <I>s</I> for substitute, <I>a</I> for append, <I>i</I> for insert, <I>w</I> for write, <I>q</I> for quit). Operations are performed on lines specified by their address, which can be absolute line numbers, relative offsets, or search patterns.<br><br>While its exact feature set can vary due to its non-standard nature—it might be a custom-built utility or a very old, rarely distributed program—its core functionality generally revolves around fundamental text manipulation at the line level. Users must explicitly issue commands to see changes, as there's no real-time display update. This makes <B>ned</B> a powerful, albeit cryptic, tool for experienced users needing precise, programmatic text alterations.


title: CAVEATS
content:
The <B>ned</B> command is highly obscure and <I>not</I> a standard utility found on most modern Linux distributions. Its existence and feature set are largely dependent on specific historical Unix environments or custom implementations. Users should not expect to find it pre-installed or readily available.<br><br>Furthermore, as a line editor, it provides no visual feedback on the document content or changes without explicit print commands, making it challenging for beginners and prone to errors if not used carefully. Changes are often written directly to the file upon saving, with no undo history, requiring careful command execution.


title: COMMON INTERNAL COMMANDS
content:
While <B>ned</B>'s exact command set can vary, it typically supports a subset of line editor commands similar to <B>ed</B>. These are entered after the editor is invoked:<br><ul><li><I>a</I>: Appends text after the current line.</li><li><I>i</I>: Inserts text before the current line.</li><li><I>d</I>: Deletes specified lines.</li><li><I>p</I>: Prints specified lines to standard output.</li><li><I>s</I>/<I>old</I>/<I>new</I>/: Substitutes <I>old</I> text with <I>new</I> on specified lines.</li><li><I>w</I> <I>file</I>: Writes the buffer contents to a file.</li><li><I>q</I>: Quits the editor.</li><li><I>!</I><I>command</I>: Executes a shell command.</li></ul>


title: INTERACTIVE MODE
content:
After invoking <B>ned</B> with a file, users enter an interactive command mode. There is no visual display of the file content; users must explicitly use commands like <I>p</I> (print) to view parts of the file. Commands are typically preceded by an address (line number or range) if not operating on the current line.


title: HISTORY
content:
The concept of <B>ned</B> (often standing for "New EDitor") likely emerged in the early days of Unix-like systems, possibly as a simplified or alternative take on the standard <B>ed</B> line editor. Its development and usage were never widespread, often limited to specific academic projects, small development teams, or niche system configurations where a minimal editor was required. It represents a bygone era of text editing before the widespread adoption of full-screen, visual editors, emphasizing command-line efficiency over user-friendliness. Its exact lineage is poorly documented due to its non-standard nature.


title: PARAMETERS
content:
<b>-r <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the restart mode. <I>Possible modes:</I> <b>`a`</b> (automatic restart), <b>`i`</b> (interactive restart), <b>`l`</b> (list processes only), <b>`N`</b> (no restart, exit 0 if nothing to do).<br><br><b>-k <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the kernel upgrade mode. <I>Similar to -r for kernel-related actions.</I><br><br><b>-c <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file path.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the scanning process.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables silent mode, suppressing most output unless an action is required or an error occurs.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides plain output, suitable for scripting or parsing, without interactive prompts.<br><br><b>-L <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level. <I>For example:</I> <b>`debug`</b>, <b>`info`</b>, <b>`warn`</b>, <b>`error`</b>.<br><br><b>-Z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for and reports zombied processes.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for processes still running from deleted binaries.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for processes with outdated userland libraries.<br><br>


title: DESCRIPTION
content:
needrestart is a <i>Linux utility</i> that identifies running processes which are using outdated versions of shared libraries or kernel modules. This typically occurs after a system upgrade where core libraries (like `libc`) or the kernel itself have been updated, but the running processes continue to use the older, in-memory versions. Failing to restart these processes can leave a system vulnerable to security issues addressed by the updates, or lead to instability.<br><br>The command scans active processes, comparing their loaded shared libraries against the versions available on disk. If a discrepancy is found, needrestart reports the affected process. It does not automatically restart services unless explicitly instructed, providing administrators with control over critical service availability. It's an <b>essential tool for maintaining system security and stability</b> post-upgrade, especially in server environments where reboots are minimized.


title: CAVEATS
content:
needrestart primarily identifies processes needing restarts; it <b>does not force restarts by default</b>. While highly effective, it might not detect all complex cases, especially with applications that dynamically load libraries in non-standard ways. Automated restart options (`-r a`) should be used with caution, as they can disrupt services without confirmation. It relies on `procfs` information, which might have limitations for some process types.


title: COMMON USAGE & OPERATION
content:
A common usage pattern is running `<b>needrestart -r i</b>` immediately after performing a system upgrade with `<b>apt upgrade</b>`. The `<b>-r i</b>` option allows interactive selection of services to restart, providing granular control. needrestart identifies outdated libraries by comparing the `<i>inode</i>` numbers and modification times of loaded shared objects (found via `<i>/proc/<pid>/maps</i>` or `<i>/proc/<pid>/smaps</i>`) against their corresponding files on the filesystem. If the loaded library's `<i>inode</i>` differs from the on-disk version, or if the on-disk version is newer, the process is flagged as needing a restart. This mechanism helps ensure that security patches and bug fixes are fully applied to all running components.


title: HISTORY
content:
needrestart gained prominence, particularly within <i>Debian and Ubuntu ecosystems</i>, as a response to the common challenge of ensuring system integrity and security after applying package updates. Prior to its widespread adoption, administrators often had to guess which services required restarting or perform full system reboots. needrestart automates the identification process, making system maintenance more efficient and less disruptive, especially in server environments. It has evolved to handle various scenarios, including kernel updates and processes running from deleted binaries.


title: PARAMETERS
content:
<b>-n, --no-default-window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not open a default window. Useful when you only want to process arguments like opening specific files or URIs without a general browsing window.<br><br><b>-q, --quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quits the running Nemo instance. This can be used to restart Nemo or shut it down cleanly.<br><br><b>-s, --select</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the given URI(s) in an existing or new Nemo window. This highlights the specified file(s) or folder(s) rather than opening them.<br><br><b>--browser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open a browser window. This is the default behavior when no specific files or URIs are provided.<br><br><b>--geometry=GEOMETRY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the geometry of the new window, for example, '800x600+100+50' for width, height, x-offset, and y-offset.<br><br><b>--no-desktop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables drawing the desktop icons and background managed by Nemo. This is useful if another application or desktop environment is handling the desktop.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help options and command-line arguments for Nemo.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for Nemo.<br><br>


title: DESCRIPTION
content:
<i>nemo</i> is the official file manager for the <B>Cinnamon</B> desktop environment. It was forked from <B>Nautilus</B> (the GNOME Files application) as part of the <B>Linux Mint</B> project's efforts to maintain a traditional desktop experience after significant changes in GNOME 3.<br><br>As a file manager, <i>nemo</i> provides a graphical interface for browsing, managing, and organizing files and folders on your computer. It supports common file operations such as copying, moving, deleting, and renaming, as well as more advanced features like tabbed browsing, split-pane view, network share access, and extensibility through plugins and scripts.<br><br>Its design focuses on usability and customization, offering a rich set of options for configuring the file browser's appearance and behavior. <i>nemo</i> aims to be a robust and user-friendly tool for navigating the file system, integrating seamlessly with the Cinnamon desktop.


title: CAVEATS
content:
<i>nemo</i> is deeply integrated with the <B>Cinnamon</B> desktop environment. While it can often run on other GTK-based desktops, its full functionality, especially desktop management and extensions, might not be available or work as expected outside of Cinnamon. It requires a running X server or Wayland compositor to display its graphical interface.


title: EXTENSIBILITY
content:
<i>nemo</i> supports extensions written in Python, C, and other languages, allowing users to add new functionalities. These extensions can integrate context menu items, add new views, or provide additional information about files and folders. Many useful extensions are available through official repositories or community contributions.


title: DESKTOP MANAGEMENT
content:
Beyond file browsing, <i>nemo</i> also serves as the desktop manager for <B>Cinnamon</B>. This means it is responsible for drawing desktop icons, handling the desktop background, and providing context menus when right-clicking on the desktop itself. This dual role contributes to its tight integration with the Cinnamon environment.


title: HISTORY
content:
<i>nemo</i> emerged in 2012 as a fork of <B>Nautilus 3.4</B>, the file manager for <B>GNOME</B>. The decision to fork was made by the <B>Linux Mint</B> developers due to significant changes introduced in Nautilus with GNOME 3 and GNOME Shell, which removed features deemed essential for a traditional desktop experience (e.g., spatial mode, split-pane view, traditional menu bars, desktop icon management). <i>nemo</i> was developed to be the default file manager for the new <B>Cinnamon</B> desktop environment, ensuring a stable and feature-rich user experience that aligned with Linux Mint's design philosophy.


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>nemo-connect-server</b> utility and exits.<br><br>


title: DESCRIPTION
content:
The <b>nemo-connect-server</b> command is an internal utility primarily used by the <I>Nemo</I> file manager, the default file browser for the Cinnamon desktop environment. Its core function is to facilitate and manage network connections for remote file browsing and transfers.<br><br>While not typically invoked directly by an end-user, this command plays a crucial role behind the scenes when a user attempts to connect to a remote server (e.g., via SFTP, SSHFS, or other supported network protocols) from within Nemo. It handles the underlying mechanics of establishing and maintaining these connections, often acting as an intermediary to the actual network protocols. This allows Nemo to present a unified and intuitive interface for accessing files located on remote hosts, making network resource management seamless for the user.


title: CAVEATS
content:
This command is primarily an internal helper utility for the <I>Nemo</I> file manager and is generally not intended for direct command-line execution by end-users. Its functionality is integrated into Nemo's graphical interface. Running it directly without the context of the file manager may not yield expected results or could lead to errors, as it relies on input and environmental variables set by Nemo.


title: INTEGRATION WITH NEMO
content:
<b>nemo-connect-server</b> is tightly integrated with the <I>Nemo</I> file manager. When you use Nemo's 'Connect to Server...' feature, this utility is likely invoked to establish the connection. It leverages existing system services and protocols to handle the actual network communication.


title: PURPOSE AS AN INTERNAL TOOL
content:
As an internal tool, <b>nemo-connect-server</b> typically does not have extensive command-line options for user configuration. Its parameters are usually passed by Nemo itself, based on the user's input in the graphical interface (e.g., host address, username, protocol type). Its lifecycle is often tied to the duration of the network connection it manages or the Nemo process that launched it.


title: HISTORY
content:
<b>nemo-connect-server</b> was developed as part of the <I>Nemo</I> file manager project, which forked from <I>Nautilus</I> (Gnome Files) to serve the Cinnamon desktop environment. As part of Nemo's evolution, especially its focus on user-friendliness and comprehensive file management, robust network capabilities were essential. This utility was introduced to abstract the complexities of various network protocols (like SSHFS and SFTP) from the core file manager, ensuring stable and efficient remote file access within the Nemo interface. Its development reflects the ongoing effort to provide a seamless user experience for managing local and remote files alike.


title: PARAMETERS
content:
<b>backup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a physical backup of a Neo4j database. Supports full and incremental backups. Key options include specifying the source/destination path (<i>--from</i>, <i>--to</i>), the database name (<i>--database</i>), and performing consistency checks (<i>--check-consistency</i>).<br><br><b>restore</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores a Neo4j database from a physical backup. Important options include specifying the backup source (<i>--from</i>), the destination for the restored database (<i>--to</i>), the database name (<i>--database</i>), and the <i>--force</i> flag to overwrite existing data.<br><br><b>import</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports data into a Neo4j database from CSV files or other formats. This command is highly optimized for large datasets. Key options include specifying the target database (<i>--database</i>), node/relationship import files (<i>--nodes</i>, <i>--relationships</i>), and various parsing options like <i>--delimiter</i> or <i>--skip-bad-records</i>.<br><br><b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps a Neo4j database into a single, portable file. This is often used for transferring databases between different Neo4j instances or for creating a logical backup. Options include specifying the database name (<i>--database</i>) and the output file path (<i>--to</i>).<br><br><b>load</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads a Neo4j database from a file created by the <b>dump</b> command. Useful for restoring or importing a database from a previously dumped file. Options include specifying the source dump file (<i>--from</i>), the target database name (<i>--database</i>), and the <i>--force</i> flag to overwrite existing data.<br><br><b>check-consistency</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs consistency checks on a Neo4j database store to ensure data integrity. Can check various components like indexes, labels, and properties. Options allow specifying the database (<i>--database</i>) and which specific checks to perform (e.g., <i>--check-indexes</i>).<br><br><b>compact</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reclaims unused disk space by compacting the database store files. This operation is typically performed offline. Options include specifying the database (<i>--database</i>) and the output directory (<i>--to</i>).<br><br><b>set-default-password</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the password for the default <i>neo4j</i> user. Requires specifying the database (<i>--database</i>) and the new password (<i>--new-password</i>).<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <i>neo4j-admin</i> or a specific subcommand. To get help for a subcommand, use <b>neo4j-admin help &lt;command&gt;</b>.<br><br>


title: DESCRIPTION
content:
<i>neo4j-admin</i> is a powerful command-line tool for managing Neo4j database instances. It provides a wide range of functionalities essential for database administrators, including creating and managing backups, restoring databases, importing data from CSV or other formats, exporting data, performing consistency checks, migrating databases, and managing database users and roles.<br><br>It operates directly on the database files and is often used when the Neo4j database server is <b>offline</b> to ensure data integrity during operations like restore or import. Its capabilities extend to offline compaction, store migration, and data integrity validation.


title: CAVEATS
content:
Most <i>neo4j-admin</i> operations (like <b>backup</b>, <b>restore</b>, <b>import</b>, <b>check-consistency</b>, <b>compact</b>) require the Neo4j database instance to be <b>offline</b> or <b>stopped</b> to ensure data integrity and prevent corruption. Using them on a running database can lead to unpredictable behavior or data loss.<br><br>Ensure the user running <i>neo4j-admin</i> has appropriate read/write permissions to the database directories.<br><br>Backups or dumps from one Neo4j version might not be directly compatible with much older or newer versions; always check the Neo4j documentation for specific migration paths.


title: OFFLINE OPERATIONS
content:
A core design principle of many <i>neo4j-admin</i> commands is their requirement to operate on an <b>offline</b> database. This is critical for preventing data corruption and ensuring consistency during low-level database manipulations like schema migrations, data imports, or integrity checks. Always stop your Neo4j instance before running such commands.


title: DATABASE MANAGEMENT
content:
Beyond common tasks like backups and imports, <i>neo4j-admin</i> facilitates various essential database management tasks, such as offline compaction (<b>compact</b>) to reclaim disk space, and integrity checks (<b>check-consistency</b>) to verify the health and structural integrity of the data store. It serves as the primary administrative interface for file-level database operations.


title: HISTORY
content:
<i>neo4j-admin</i> evolved from earlier command-line tools and scripts provided with Neo4j. Its capabilities have expanded significantly over time, particularly with Neo4j 3.x introducing <i>neo4j-admin import</i> for large-scale data ingestion and Neo4j 4.x consolidating more operations under this single binary, including <i>dump</i> and <i>load</i> for portable database transfers. The emphasis has shifted towards robust, offline operations critical for production environments.


title: PARAMETERS
content:
<b><b>--config</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file path instead of the default.<br><br><b><b>--ascii_distro</b> <i>distro_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a specific distribution's ASCII art logo to be used. <br> Use 'auto' to detect automatically, or 'off' to disable the logo.<br><br><b><b>--no_display_logo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of the ASCII logo entirely, showing only system info.<br><br><b><b>--disable</b> <i>info_key</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables a specific info line from displaying. <br> Can be used multiple times, e.g., <i>--disable cpu --disable memory</i>.<br><br><b><b>--enable</b> <i>info_key</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a specific info line that might be disabled by default or in a config file. <br> Useful for debugging or quick tests.<br><br><b><b>--short_uptime</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays uptime in a shorter, more concise format (e.g., <i>1d 5h</i>).<br><br><b><b>--short_memory</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays memory in a shorter format (e.g., <i>1.5GiB / 8GiB</i>).<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of <b>Neofetch</b> and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message with all available command-line options.<br><br>


title: DESCRIPTION
content:
<b>Neofetch</b> is a fast, highly customizable <br> command-line system information tool. <br> It displays system information next to an image, <br> which can be your distribution's logo (ASCII art), <br> a custom image, or any image file. <br> It aims to be simple, clean, and <br> provide a quick overview of your system's <br> configuration. <br><br> Information commonly displayed includes <br> your Operating System, Host, Kernel, Uptime, <br> Packages, Shell, Resolution, Desktop Environment, <br> Window Manager, Theme, Icons, Terminal, <br> Terminal Font, CPU, GPU, and Memory usage. <br> Its aesthetic output makes it popular for <br> sharing system specs, especially within <br> Linux communities, often featured in screenshots <br> of customized terminal setups.


title: CAVEATS
content:
While highly customizable, <b>Neofetch</b> relies on <br> various external system tools and files to gather information. <br> Missing dependencies for specific information <br> (e.g., <i>sensors</i> for temperature, <i>imagemagick</i> for image support) <br> might result in missing or incorrect output. <br> Its ASCII art might not render perfectly in all terminal <br> emulators or with certain fonts. <br> It's primarily a community-driven project and <br> not part of standard GNU core utilities.


title: CONFIGURATION FILE
content:
<b>Neofetch</b> offers extensive customization through its <br> configuration file, typically found at <br> <i>~/.config/neofetch/config.conf</i>. <br> This file allows users to define what information <br> is displayed, its order, colors, alignment, <br> ASCII art source, and many other aspects, <br> providing unparalleled control over the output.


title: COMMUNITY AND AESTHETICS
content:
One of <b>Neofetch</b>'s primary appeals is its <br> aesthetic output, which has made it a <br> favorite among users on platforms like <br> <i>r/unixporn</i>. It's often the first <br> command executed to showcase a <br> newly configured Linux desktop, <br> highlighting the user's choices in <br> distribution, desktop environment, <br> window manager, and theme in a visually <br> appealing format.


title: HISTORY
content:
<b>Neofetch</b> was created by <i>Dylan Araps</i> <br> and quickly gained popularity as a more <br> modern and highly customizable alternative <br> to existing tools like <i>screenfetch</i>. <br> Its development focused on providing a <br> clean, efficient, and aesthetically pleasing <br> system information display, often seen <br> as a staple in screenshots shared by <br> Linux enthusiasts showcasing their <br> highly personalized desktop environments. <br> It has been widely adopted across <br> various Linux distributions.


title: SYNOPSIS
content:
neomutt [<b>-a</b> <I>alias</I>] [<b>-e</b> <I>command</I>] [<b>-f</b> <I>mailbox</I>] [<b>-F</b> <I>config_file</I>] [<b>-h</b>] [<b>-n</b>] [<b>-v</I>] [<I>address</I>...]


title: PARAMETERS
content:
<b><b>-a</b> <I>alias</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified <I>alias</I> when sending a message.<br><br><b><b>-e</b> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute <I>command</I> after processing all configuration files.<br><br><b><b>-f</b> <I>mailbox</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the specified <I>mailbox</I> instead of the default.<br><br><b><b>-F</b> <I>config_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <I>config_file</I> as the configuration file instead of the default <I>~/.neomuttrc</I>.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not source the system-wide configuration file.<br><br><b><b>-s</b> <I>subject</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <I>subject</I> of the message to be sent.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>neomutt</I> version number and exit.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start with an empty message, typically used for composing a new email without a recipient.<br><br><b><b>-z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <I>neomutt</I> to start even if the specified mailbox is empty.<br><br><b><I>address</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more recipient email addresses when composing a new message from the command line.<br><br>


title: DESCRIPTION
content:
Neomutt is a highly configurable, keyboard-driven, text-based email client (MUA). It's a fork of the popular <I>Mutt</I> email client, created to incorporate new features, bug fixes, and maintain active development. Neomutt provides a rich set of functionalities for managing email, including support for various mailbox formats (mbox, Maildir), multiple protocols (IMAP, POP3, SMTP), <I>PGP/GPG</I> encryption, <I>S/MIME</I>, and extensive filtering capabilities. Its strength lies in its extreme configurability, allowing users to tailor nearly every aspect of its behavior and appearance through a simple configuration file, making it a favorite among power users and command-line enthusiasts.


title: CAVEATS
content:
Due to its extensive configuration and keyboard-driven interface, <I>neomutt</I> has a steep learning curve. It requires manual setup and often relies on external tools like <I>msmtp</I>, <I>fetchmail</I>, and <I>procmail</I> for full mail sending, receiving, and processing functionality. As a text-based client, it does not natively render HTML emails, usually requiring external viewers.


title: CONFIGURATION FILES
content:
<I>Neomutt</I>'s behavior is extensively controlled via configuration files. The primary user-specific file is typically <I>~/.neomuttrc</I> or <I>~/.config/neomutt/neomuttrc</I>. These files are written in a specialized scripting language, enabling users to define key bindings, mail handling rules, color schemes, and integrate with external tools. System-wide configurations may also exist.


title: KEYBOARD-DRIVEN INTERFACE
content:
<I>Neomutt</I> is designed for efficient keyboard navigation, minimizing reliance on mouse input. Almost every action, from navigating mailboxes and messages to composing and replying, can be performed with specific key combinations. This design choice contributes to its speed and efficiency for experienced users.


title: EXTENSIBILITY AND HOOKS
content:
Beyond direct configuration, <I>Neomutt</I> offers robust extensibility through hooks and macros. Users can define actions to be executed before or after specific events (e.g., opening a mailbox, sending a message). It also supports integration with numerous external programs for tasks like attachment viewing, mail filtering, and cryptographic operations, making it highly adaptable to diverse workflows.


title: HISTORY
content:
<I>Neomutt</I> is a vibrant fork of the popular <I>Mutt</I> email client, which was originally authored by Michael Elkins in 1995. While <I>Mutt</I> gained significant traction for its power and flexibility, its development pace slowed over time, leading to a backlog of unmerged patches and features. In 2014, a community of developers initiated <I>Neomutt</I> to actively integrate these external patches, provide ongoing maintenance, and introduce modern features such as a sidebar, improved <I>IMAP</I> support, and <I>notmuch</I> integration. It maintains full configuration compatibility with <I>Mutt</I>, allowing seamless migration for existing users.


title: PARAMETERS
content:
<b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays informative messages about the conversion process, such as image dimensions and color depth, to standard error.<br><br><b>neofile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input NeoPaint <i>.NEO</i> image file. If this argument is omitted, <b>neotoppm</b> reads the image data from standard input.<br><br>


title: DESCRIPTION
content:
<b>neotoppm</b> is a command-line utility from the Netpbm toolkit. It serves the specific purpose of converting proprietary NeoPaint <i>.NEO</i> image files into the standard Netpbm PPM (Portable Pixmap) format. NeoPaint was a popular drawing program, and its <i>.NEO</i> files contained raster image data. By transforming these files into PPM, <b>neotoppm</b> enables users to integrate NeoPaint images into the wider ecosystem of image processing tools. The PPM format, being a simple and widely supported intermediate format, allows the converted images to be further manipulated, viewed, or transformed into other common formats like JPEG, PNG, or GIF using subsequent Netpbm utilities or other image manipulation software. This command is particularly useful for preserving or accessing content from legacy NeoPaint projects.


title: CAVEATS
content:
<b>neotoppm</b> is designed specifically for the NeoPaint <i>.NEO</i> image format. It may not correctly process corrupted or non-standard <i>.NEO</i> files, which could lead to errors or unexpected output. The command exclusively outputs a Netpbm PPM (Portable Pixmap) file. To convert the image to other common formats (e.g., JPEG, PNG, GIF), further processing with other Netpbm utilities (like <b>ppmtojpeg</b> or <b>ppmtogif</b>) or external image converters is required. This tool functions best as part of a larger image processing pipeline, typical for the Netpbm suite.


title: STANDARD INPUT/OUTPUT
content:
By default, <b>neotoppm</b> reads the NeoPaint file from standard input if no <i>neofile</i> argument is provided. It always writes the resulting PPM image to standard output. This design facilitates piping output from other commands as input or piping its output to subsequent Netpbm utilities for further processing, adhering to the Unix philosophy of small, specialized tools that can be chained together.


title: HISTORY
content:
<b>neotoppm</b> is a component of the comprehensive Netpbm image processing toolkit. The Netpbm project itself evolved from the PBMplus package, which originated in the early 1990s. <b>neotoppm</b> specifically became part of the Netpbm suite around Release 10.3 in July 2002. Its inclusion reflects the toolkit's ongoing development to support conversions from a wide array of image formats, especially those popular during its development period, allowing for broader interoperability and preservation of legacy image data.


title: SYNOPSIS
content:
<i><b>neqn</b> [<b>-d</b><i>XY</i>] [<b>-T</b><i>name</i>] [<b>-s</b><i>n</i>] [<b>-p</b><i>n</i>] [<b>-f</b><i>file</i>] [<i>file ...</i>]</i>


title: PARAMETERS
content:
<b><b>-d</b><i>XY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines the characters <i>X</i> and <i>Y</i> as the default equation delimiters. Equations are usually placed between <b>.EQ</b> and <b>.EN</b> lines, but this option allows inline equations to be marked with custom characters, e.g., <b>-d$$</b>.</i><br><br><b><b>-T</b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the output terminal type or device for which <b>neqn</b> should generate output. For <b>neqn</b>, this is commonly `<b>nroff</b>` to indicate character-based output.</i><br><br><b><b>-s</b><i>n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adjusts the point size of equations by <i>n</i> points relative to the surrounding text. This option influences the relative scaling of equation components.</i><br><br><b><b>-p</b><i>n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Causes equation sizes to be adjusted by <i>n</i> points. Similar to <b>-s</b>, this affects the relative scaling of equation components.</i><br><br><b><b>-f</b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reads font information from the specified <i>file</i>. While more relevant for <b>troff</b>, this option is part of the shared <b>eqn</b>/<b>neqn</b> interface.</i><br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a help message and exits.</i><br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays version information and exits.</i><br><br>


title: DESCRIPTION
content:
<i><b>neqn</b> is a preprocessor for the <b>nroff</b> text formatting system, designed to typeset mathematical equations for character-based output devices such as terminals and line printers.<br><br>While its counterpart, <b>eqn</b>, is primarily used with <b>troff</b> for high-resolution phototypesetting, <b>neqn</b> generates output suitable for display on standard alphanumeric devices. It reads text files that contain embedded equation descriptions using a simple, intuitive language.<br><br>When <b>neqn</b> processes a file, it translates these equation descriptions into appropriate <b>nroff</b> commands and macros, which then format the equations correctly within the overall document. This allows users to include complex mathematical expressions in documents like Unix manual pages without needing specialized typesetting hardware, making mathematical content accessible in plain text environments.</i>


title: CAVEATS
content:
<i><b>neqn</b> is primarily designed for character-based output, making it less suitable for high-resolution printing or PDF generation compared to <b>eqn</b> used with <b>troff</b>. Its output is optimized for readability on terminals and line printers, which may result in less visually sophisticated formatting for complex equations compared to graphical typesetting systems.</i>


title: <I>EQUATION DELIMITERS</I>
content:
<i>By default, <b>neqn</b> processes text between lines containing only <b>.EQ</b> and <b>.EN</b> as equations. For example:<br><br><b>.EQ</b><br><i>a over b</i><br><b>.EN</b><br><br>This allows <b>neqn</b> to correctly identify and format the mathematical expressions within a larger document. The <b>-d</b> option allows specifying custom delimiters for inline equations.</i>


title: <I>BASIC SYNTAX</I>
content:
<i><b>neqn</b> uses a relatively simple and intuitive language for describing equations. For instance:<br><i>`a over b`</i> produces a fraction.<br><i>`sqrt x`</i> produces a square root of x.<br><i>`sum from i=1 to n x sub i`</i> produces a summation.<br><i>`x sup 2`</i> produces x squared.<br><br>The language is designed to be human-readable and relatively easy to learn for basic mathematical expressions.</i>


title: HISTORY
content:
<i><b>neqn</b> was developed as part of the original Unix text processing suite at Bell Labs. It emerged alongside <b>eqn</b>, <b>nroff</b>, and <b>troff</b> to provide a comprehensive system for document preparation. While <b>eqn</b> focused on output for phototypesetters, <b>neqn</b> addressed the need for equation typesetting on simpler, character-oriented devices that were common in the early days of computing. It has been maintained and evolved as part of the GNU <b>troff</b> (<b>groff</b>) project, ensuring its continued availability and functionality in modern Unix-like environments. Its core purpose remains to bridge the gap between plain text documents and formatted mathematical expressions.</i>


title: DESCRIPTION
content:
The command <i>'nest'</i> is not a standard, universally recognized utility found in most Linux distributions. It is highly probable that this command is either a typographical error for a different common command (e.g., <i>'netstat'</i>), or it refers to a very specific, niche application, a custom script, or an alias defined within a particular user's environment. Without further context, its functionality cannot be determined as it does not ship by default with typical Linux installations.


title: CAVEATS
content:
The most common reason for querying <i>'nest'</i> is a typo for <i>'netstat'</i>, a widely used command for displaying network connections. If <i>'nest'</i> is encountered in a specific context, it might be an alias, a shell function, or part of a specialized software package like the NEST Neural Simulation Tool (Neuroscience Simulation Technology). The NEST simulation tool has its own specific command-line interface and library functions, but <i>'nest'</i> itself is not a standalone shell command like <i>'ls'</i> or <i>'grep'</i>.


title: COMMON MISSPELLINGS
content:
It is often a misspelling of <i>'netstat'</i>, a command used for displaying network connections, routing tables, and interface statistics.


title: HISTORY
content:
As <i>'nest'</i> is not a standard Linux command, there is no common development history associated with it in the context of standard operating system utilities.


title: SYNOPSIS
content:
<b>net</b> <i>[global options]</i> <i>&lt;subcommand&gt;</i> <i>[subcommand options]</i> <i>[arguments]</i><br><br>Examples:<br><i><b>net</b> ads join -U administrator<br><b>net</b> users add <username><br><b>net</b> share add <sharename> <path></i>


title: PARAMETERS
content:
<b><i>-U &lt;username&gt;[%&lt;password&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username and optionally password for authentication. If password is not provided, the user will be prompted.<br><br><b><i>-S &lt;server_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target server to connect to. This can be an IP address or hostname.<br><br><b><i>-W &lt;workgroup_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the workgroup or domain to authenticate against.<br><br><b><i>-d &lt;debug_level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for logging output (0-10), with 0 being no logging and 10 being verbose.<br><br><b><i>-k</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Kerberos authentication. This requires a valid Kerberos ticket for the user.<br><br><b><i>-P</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a named pipe for communication (e.g., in a script context).<br><i>Note: Most <b>net</b> options are specific to its subcommands and are passed after the subcommand.</i><br><br>


title: DESCRIPTION
content:
<b>net</b> is a versatile command-line utility provided by the Samba suite on Linux systems. It is primarily used for administering Samba servers and interacting with Windows-based networks, including Active Directory domains and Windows workgroups. Unlike general network utilities like <b>netstat</b> or <b>ip</b>, <b>net</b> specifically focuses on the Server Message Block (SMB) and Common Internet File System (CIFS) protocols.<br><br>It allows administrators to perform a wide range of tasks such as managing users and groups within a domain, creating and managing network shares, joining a Linux machine to an Active Directory domain, querying domain controller information, and performing Remote Procedure Call (RPC) operations against Windows servers. Its functionality often parallels tools found on Windows systems for domain and share management, making it an essential tool for environments integrating Linux with Windows infrastructure.


title: CAVEATS
content:
<b>net</b> is part of the Samba suite and should not be confused with generic network utilities like <b>netstat</b> or <b>ip</b>, which are used for displaying system network connections and interfaces. <br>It requires the Samba client packages to be installed on the Linux system. <br>Many subcommands require appropriate permissions, often root privileges or a properly configured Kerberos ticket, to function correctly. <br>Authentication is crucial; incorrect credentials or domain/workgroup settings will lead to errors.


title: SUBCOMMANDS OVERVIEW
content:
The power of <b>net</b> lies in its extensive set of subcommands, each designed for specific administrative tasks. Common subcommands include:<br><i><b>net ads:</b></i> For Active Directory domain administration (e.g., join, user, group, computer).<br><i><b>net users:</b></i> To manage local or domain users.<br><i><b>net group:</b></i> To manage local or domain groups.<br><i><b>net share:</b></i> To manage SMB/CIFS network shares.<br><i><b>net rpc:</b></i> For direct RPC calls to Windows servers (e.g., info, password).<br><i><b>net time:</b></i> To synchronize time with a Windows server.<br><i><b>net lookup:</b></i> To resolve NetBIOS names.


title: AUTHENTICATION METHODS
content:
<b>net</b> supports various authentication methods, primarily NTLM (via username/password) and Kerberos. Kerberos authentication (enabled with <b>-k</b>) is the preferred method for Active Directory environments as it offers stronger security and single sign-on capabilities when properly configured with a Kerberos client and ticket.


title: HISTORY
content:
The <b>net</b> command is an integral part of the Samba project, which began development in 1992. Samba's primary goal was to provide seamless file and print services between Unix/Linux and Microsoft Windows systems using the Server Message Block (SMB) protocol. The <b>net</b> utility evolved as a command-line interface to expose a wide range of Windows networking functionalities to Unix-like operating systems, offering administrative capabilities that mirror those available on Windows domain controllers and client tools. Its development has closely tracked the evolution of Windows networking, including the shift from NT domains to Active Directory.


title: SYNOPSIS
content:
<b>netdiscover</b> [<b>-i</b> <i>&lt;device&gt;</i>] [<b>-r</b> <i>&lt;IP_range&gt;</i> | <b>-l</b> <i>&lt;file&gt;</i>] [<b>-p</b> | <b>-s</b> <i>&lt;time&gt;</i>] [<b>-c</b>] [<b>-f</b>] [<b>-n</b>] [<b>-v</b>]


title: PARAMETERS
content:
<b><b>-i</b> <i>&lt;device&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to use for scanning (e.g., <i>eth0</i>, <i>wlan0</i>).<br><br><b><b>-r</b> <i>&lt;IP_range&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scans a target IP range in CIDR format (e.g., <i>192.168.1.0/24</i>).<br><br><b><b>-l</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a list of IP ranges from a specified file, one per line.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables passive mode. <i>netdiscover</i> will sniff the network for ARP replies without sending any packets.<br><br><b><b>-s</b> <i>&lt;time&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sleep time in milliseconds between each ARP request in active scan mode.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables scanning of the local host IP address.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates continuous scanning, preventing <i>netdiscover</i> from exiting until manually stopped.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables fast mode, which increases the scan speed by sending multiple ARP requests concurrently.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of output, showing more details about the scan process.<br><br>


title: DESCRIPTION
content:
<i>netdiscover</i> is a powerful open-source active/passive reconnaissance tool designed to scan and discover hosts on a local network. It primarily operates by sending ARP requests to specified IP ranges (active mode) or by passively sniffing network traffic for ARP replies (passive mode). This dual approach allows it to identify online hosts, their IP addresses, MAC addresses, and often their associated vendor information. It's particularly useful for network administrators to map out network devices or for penetration testers to enumerate targets during the initial phases of an engagement. Its simplicity and effectiveness make it a go-to command for quickly understanding the landscape of a given subnet.


title: CAVEATS
content:
<i>netdiscover</i> typically requires <b>root privileges</b> to perform raw socket operations (ARP requests/sniffing). Active scanning can be <b>noisy</b> and detectable, while passive scanning effectiveness depends on the amount of network traffic visible. It is primarily a <b>host discovery</b> tool, not a port scanner.


title: USAGE EXAMPLE: ACTIVE SCAN
content:
To perform an active scan on a specific subnet (e.g., <i>192.168.1.0/24</i>) using the <i>eth0</i> interface:<br><i>sudo netdiscover -i eth0 -r 192.168.1.0/24</i>


title: USAGE EXAMPLE: PASSIVE SCAN
content:
To passively sniff for hosts on the <i>wlan0</i> interface, without sending any packets:<br><i>sudo netdiscover -p -i wlan0</i>


title: ETHICAL CONSIDERATIONS
content:
Using <i>netdiscover</i> for unauthorized network scanning can be considered a hostile or intrusive act. Always ensure you have <b>explicit permission</b> from the network owner or administrator before scanning any network you do not own or manage.


title: HISTORY
content:
<i>netdiscover</i> has been a staple in network analysis and penetration testing distributions like <b>Kali Linux</b> for many years. Its development has focused on providing a simple, quick, and effective method for initial network reconnaissance by combining both active (ARP requests) and passive (ARP sniffing) host discovery techniques. It remains a fundamental tool for understanding the live hosts on a local network.


title: SYNOPSIS
content:
<b>netexec</b> <I>protocol</I> <I>target(s)</I> [<I>options</I>]<br><br><I>protocol</I>: One of <I>smb</I>, <I>wmi</I>, <I>winrm</I>, <I>rdp</I>, <I>mssql</I>, <I>ssh</I>, <I>vnc</I>, <I>ldap</I>, <I>ftp</I>, <I>http</I>, <I>https</I>, <I>kdc</I>.<br><I>target(s)</I>: IP address(es), CIDR ranges, hostnames, or a path to a file containing targets.<br><I>options</I>: Global options, authentication options, module-specific options.<br><br><i>Examples:</i><br><b>netexec smb 192.168.1.0/24 -u user -p pass</b><br><b>netexec smb target.txt -M enum_users</b><br><b>netexec winrm 10.0.0.5 --local-auth -x "whoami"</b>


title: PARAMETERS
content:
<b>-u <USERNAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--username</b> <I>USERNAME</I><br>Username or a file containing usernames to authenticate with.<br><br><b>-p <PASSWORD></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--password</b> <I>PASSWORD</I><br>Password or a file containing passwords to authenticate with.<br><br><b>-H <HASH></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--hashes</b> <I>HASH</I><br>LM:NTLM or NTLM hash to authenticate with. For NTLM, use ':<I>HASH</I>' (e.g., ':<I>AAD3B435B51404EEAAD3B435B51404EE</I>').<br><br><b>--no-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticate with a blank password.<br><br><b>--local-auth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform local authentication (do not attempt domain authentication).<br><br><b>--domain <DOMAIN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the domain to authenticate against.<br><br><b>-M <MODULE_NAME></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--module</b> <I>MODULE_NAME</I><br>Execute a specific module. Use <I>--list-modules</I> to see available modules.<br><br><b>--list-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available modules for the selected protocol.<br><br><b>-o <OUTPUT_FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--outputfile</b> <I>OUTPUT_FILE</I><br>Save output to a file.<br><br><b>-x <COMMAND></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>--exec-cmd</b> <I>COMMAND</I><br>Execute a command on the target(s). Requires appropriate protocol/privileges.<br><br><b>--exec-method <METHOD></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Method to execute commands (<I>smbexec</I>, <I>wmiexec</I>, <I>atexec</I>, <I>dcomexec</I>, <I>powershell</I>). Defaults to <I>smbexec</I> for <I>SMB</I>.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format.<br><br><b>--continue-on-error</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not stop on errors when iterating through targets.<br><br><b>--shares</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(SMB) Enumerate accessible shares.<br><br><b>--users</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(SMB) Enumerate users via SAMR.<br><br><b>--loggedon-users</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(SMB) Enumerate logged on users.<br><br><b>--laps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(SMB) Try to dump LAPS passwords.<br><br><b>--pass-file <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;File containing usernames and passwords/hashes in <I>user:pass</I> or <I>user::hash</I> format.<br><br>


title: DESCRIPTION
content:
<I>NetExec</I> (often aliased as <I>nxc</I>) is a versatile open-source network enumeration and post-exploitation tool designed for Active Directory environments. It's a complete re-implementation of the popular <I>CrackMapExec</I> (CME) framework, aiming to provide improved performance, stability, and new features.<br><br>It supports a wide array of protocols, including <I>SMB</I>, <I>WMI</I>, <I>WinRM</I>, <I>MSSQL</I>, <I>SSH</I>, <I>LDAP</I>, and more, making it an indispensable tool for penetration testers and red teamers. <I>NetExec</I> excels at discovering hosts, enumerating shares, identifying vulnerable services, spraying credentials, and executing commands across networks.<br><br>Its modular architecture allows users to easily extend its functionality with custom modules, making it adaptable to various scenarios. It simplifies complex tasks by abstracting the underlying protocol details, providing a unified interface for interacting with diverse network services.


title: CAVEATS
content:
Due to its powerful capabilities, <I>NetExec</I> is often flagged by antivirus software as a potential threat; this is a false positive for legitimate use. It requires <I>Python 3</I> and various dependencies, which might need manual installation if not using a pre-packaged distribution like Kali Linux. Misuse of <I>NetExec</I> can lead to unintended consequences or legal issues; it should only be used in environments where explicit permission has been granted.


title: ALIASES AND INSTALLATION
content:
While the command is officially named <I>netexec</I>, it's very commonly symlinked or aliased to <I>nxc</I> for brevity. Many penetration testing distributions, such as Kali Linux and Parrot OS, include <I>netexec</I> pre-installed. For other systems, it can be installed via <I>pip</I> (e.g., <I>pip install netexec</I>) or by cloning its Git repository.


title: MODULARITY
content:
One of <I>NetExec</I>'s strongest features is its modular design. Users can write and load custom Python modules to extend its functionality for specific enumeration, exploitation, or data collection tasks. These modules can target various protocols, significantly increasing the tool's versatility.


title: HISTORY
content:
<I>NetExec</I> is a modern re-implementation of the highly popular <I>CrackMapExec</I> (CME) tool. CME was originally developed by @byt3bl33d3r and gained widespread adoption in the cybersecurity community for its efficiency in Active Directory post-exploitation. However, CME's development became stagnant, and its codebase, while functional, presented challenges for new feature integration and maintenance.<br><br>Recognizing the need for an updated, more performant, and actively maintained version, a new group of developers initiated the <I>NetExec</I> project. They rewrote the tool from scratch, leveraging modern Python practices and dependencies, while retaining CME's beloved command-line interface and modularity. This ensures compatibility with existing workflows while paving the way for future enhancements and a more robust framework.


title: PARAMETERS
content:
<b>-d <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate game data directory.<br>Useful for testing different configurations or versions.<br><br><b>-u <i>player</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a new game or resumes a saved game for the specified player name.<br>Especially useful on multi-user systems.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the high scores table and then exits.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to resume the last saved game for the current user.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the NetHack version information and then exits.<br><br><b>-?</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise usage message and exits.<br><br>


title: DESCRIPTION
content:
NetHack is a venerable single-player roguelike video game, celebrated for its complex and unpredictable gameplay. The player navigates a procedurally generated dungeon, starting from a high-level dungeon and progressing downwards, with the ultimate goal of retrieving the Amulet of Yendor from the deepest level and ascending back to the surface. The game features turn-based combat, permadeath, and a vast array of items, monsters, and interactive environmental elements. Players choose from various character classes, races, and alignments, each affecting gameplay. Its deep mechanics, intricate puzzles, and often humorous "YASD" (Yet Another Stupid Death) moments contribute to its legendary status and immense replayability. NetHack is primarily text-based using ASCII characters but can also be played with graphical tile sets.


title: CAVEATS
content:
<b>Permadeath:</b> Death is permanent, leading to the loss of all game progress. This makes careful decision-making crucial.<br><b>Steep Learning Curve:</b> The game's immense depth, cryptic messages, and hidden mechanics require significant time and effort to master.<br><b>Graphical Interface:</b> By default, NetHack uses ASCII characters for its display, which might be off-putting for players accustomed to modern graphics. Graphical tiles are available but often require specific compilation or installation.


title: CONFIGURATION
content:
NetHack uses a configuration file, typically <b>~/.nethackrc</b> or <b>nethackrc</b> in the game directory, to customize various game behaviors, keybindings, and display options. Modifying this file is essential for personalizing the gameplay experience.


title: SAVING AND QUITTING
content:
Players can save their game at any point by typing <b>S</b>. A saved game can only be resumed once; upon loading, the save file is automatically deleted. This design enforces the permadeath mechanic.


title: COMMUNITY AND RESOURCES
content:
Due to its complexity, NetHack has a vibrant online community. Resources like the NetHack Wiki (<I>nethackwiki.com</I>) are invaluable for new and experienced players alike, offering detailed information on monsters, items, mechanics, and strategies.


title: HISTORY
content:
NetHack traces its origins back to 1980 with the game <i>Rogue</i>. It specifically evolved from <i>Hack</i> (1985), which added persistent levels and diversified the dungeon environment beyond <i>Rogue</i>'s flat structure. The "Net" in NetHack refers to its distributed development, which began in 1987 when Mike Stephenson took over the project and organized a team of volunteers collaborating over the internet. It is one of the longest continually developed video games, known for its slow but significant releases by the NetHack DevTeam, maintaining a loyal community over decades.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitor all devices, including loopback interfaces and those without an IPv4 address.<br><br><b><b>-d <I>seconds</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delay for update refresh rate in seconds (default is 1). Can be a float value, e.g., <b>-d 0.5</b>.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trace mode. Dumps the output to standard output (stdout) instead of using the interactive ncurses interface. Useful for scripting or logging.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Promiscuous mode. Sniff packets in promiscuous mode. This might be necessary on some network setups to see all traffic.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort by total (sent + received) bandwidth. By default, processes are sorted by received (download) bandwidth.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b><b>-c <I>cycles</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run for a specified number of refresh cycles and then exit. Useful for automated monitoring.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b><I>device</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify one or more network interfaces to monitor (e.g., <b>eth0</b>, <b>wlan0</b>, <b>lo</b>). If no device is specified, Nethogs monitors all non-loopback devices with an IPv4 address.<br><br>


title: DESCRIPTION
content:
Nethogs is a small, open-source 'top'-like tool that provides a real-time, per-process bandwidth monitoring experience for Linux and macOS. Unlike traditional network monitoring tools that show only aggregated network usage, Nethogs breaks down usage by individual processes or programs, displaying how much upload and download bandwidth each application is consuming. This makes it an invaluable utility for identifying bandwidth-intensive applications, diagnosing unexpected network activity, or simply understanding where your network resources are being utilized. It functions by sniffing network traffic on specified interfaces and correlating it with process IDs (PIDs) by examining the <b><I>/proc</I></b> filesystem. The interactive curses-based interface allows users to sort data, toggle display modes, and refresh statistics dynamically, offering immediate and actionable insights into network resource consumption.


title: CAVEATS
content:
Nethogs requires root privileges (or appropriate capabilities) to operate, as it needs to access raw network sockets and read information from the <b><I>/proc</I></b> filesystem. It might not always accurately identify the process responsible for network activity in complex networking scenarios, such as traffic routed through VPN tunnels, network namespaces used by containers (e.g., Docker), or virtual machines. While generally lightweight, monitoring very high-traffic network interfaces can lead to a noticeable increase in CPU usage. Nethogs only reports on network activity that passes through the monitored interfaces and is associated with a running process on the local machine.


title: INTERACTIVE COMMANDS
content:
When Nethogs is running in its interactive curses-based interface, several key presses can be used to control its behavior:<br><ul><li><b><I>m</I></b>: Cycles through display modes for bandwidth units (KB/s, MB/s, GB/s).</li><li><b><I>r</I></b>: Sorts processes by received (download) bandwidth.</li><li><b><I>s</I></b>: Sorts processes by sent (upload) bandwidth.</li><li><b><I>q</I></b>: Quits the application.</li><li><b><I>K</I></b>: Attempts to kill the selected process (use with extreme caution).</li><li><b><I>d</I></b>: Toggles display of received, sent, and total bandwidth columns.</li><li><b><I>i</I></b>: Toggles between displaying PID only and PID with program name.</li><li><b><I>l</I></b>: Toggles display of local/remote IP addresses and ports for connections.</li></ul>


title: OUTPUT COLUMNS
content:
The default interactive display of Nethogs provides the following columns:<br><ul><li><b><I>PID</I></b>: The Process ID of the application.</li><li><b><I>Program</I></b>: The name of the executable or process responsible for the traffic.</li><li><b><I>DEV</I></b>: The network device (interface) through which the traffic is passing (e.g., <b>eth0</b>, <b>wlan0</b>).</li><li><b><I>SENT</I></b>: The upload bandwidth usage in real-time.</li><li><b><I>RECEIVED</I></b>: The download bandwidth usage in real-time.</li><li><b><I>TOTAL</I></b>: (Optional, toggle with <b><I>d</I></b>) The combined sent and received bandwidth.</li></ul>


title: HISTORY
content:
Nethogs was initially developed by Arnout Engelen and first released around 2008. It was created to address a specific void in Linux system monitoring: the lack of a straightforward tool to visualize network bandwidth consumption broken down by individual processes, akin to how <b><I>top</I></b> provides CPU and memory insights. Being open-source and fulfilling such a critical niche, it quickly gained popularity among system administrators and power users. While its development pace has naturally evolved from rapid initial releases to more maintenance-focused updates, Nethogs remains a stable, widely used, and essential utility in many Linux troubleshooting and monitoring toolkits.


title: SEE ALSO
content:
<b><I>top(1)</I></b>: A common process monitor that shows CPU and memory usage per process., <b><I>iftop(8)</I></b>: Displays real-time bandwidth usage on selected network interfaces, but not per-process., <b><I>ss(8)</I></b>: Utility to investigate sockets, showing connections, listening ports, and socket statistics., <b><I>netstat(8)</I></b>: Prints network connections, routing tables, interface statistics, and multicast memberships., <b><I>lsof(8)</I></b>: Lists open files and can show network connections associated with specific processes.


title: PARAMETERS
content:
<b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose mode, displaying all server responses.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns on debugging, printing debugging information.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turns off interactive prompting during multiple file transfers (e.g., with <i>mget</i> or <i>mput</i>).<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses auto-login upon initial connection, requiring manual <i>user</i> and <i>pass</i> commands.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables filename globbing, preventing special characters from being expanded into a list of filenames.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables passive mode, which is often necessary when the client is behind a firewall or Network Address Translation (NAT).<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables TCP keep-alive messages on the control connection.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately attempts an anonymous login when a host is specified.<br><br>


title: DESCRIPTION
content:
<i>netkit-ftp</i> is a traditional command-line client for the File Transfer Protocol (FTP), used for transferring files between a local host and a remote FTP server. It provides a basic yet powerful interface for navigating remote directories, uploading files (<i>put</i>), downloading files (<i>get</i>), listing contents (<i>ls</i>, <i>dir</i>), and managing files on the server.<br><br>While it lacks modern features like SFTP or FTPS for secure transfers, it remains a fundamental tool for interacting with plain FTP servers. Its simplicity makes it suitable for scripting basic file transfer operations or for environments where secure FTP protocols are not available or required. It operates by establishing a connection, authenticating the user, and then allowing interaction through a set of internal commands.


title: CAVEATS
content:
<i><b>Security Risk</b>:</i> <i>netkit-ftp</i> transfers credentials (username/password) and all data in plaintext, making it highly vulnerable to eavesdropping and interception. It is not suitable for sensitive data.<br><i><b>No SFTP/FTPS</b>:</i> It does not support secure variants of FTP like SFTP (FTP over SSH) or FTPS (FTP over SSL/TLS), which provide encryption.<br><i><b>Firewall Challenges</b>:</i> Active mode FTP can struggle with firewalls and NAT configurations. While passive mode (<i>-p</i> option) helps, complex network setups can still pose connectivity challenges.<br><i><b>Limited Features</b>:</i> Lacks advanced features found in modern FTP clients, such as transfer resume capabilities, advanced scripting options, or robust error handling for large-scale operations.


title: INTERNAL COMMANDS
content:
Once connected to an FTP server, <i>netkit-ftp</i> provides a rich set of interactive commands for file operations and server interaction. These are distinct from command-line options and are executed within the FTP prompt:<br><ul><li><i><b>get</b></i>: Download a file from the server to the local machine.</li><li><i><b>put</b></i>: Upload a file from the local machine to the server.</li><li><i><b>ls</b></i> / <i><b>dir</b></i>: List directory contents on the remote server.</li><li><i><b>cd</b></i> / <i><b>cdup</b></i>: Change the current directory on the remote server.</li><li><i><b>lcd</b></i>: Change the current working directory on the local machine.</li><li><i><b>mget</b></i> / <i><b>mput</b></i>: Download/upload multiple files using globbing patterns.</li><li><i><b>ascii</b></i> / <i><b>binary</b></i>: Set the file transfer mode (ASCII for text files, Binary for all other files).</li><li><i><b>delete</b></i> / <i><b>mkdir</b></i> / <i><b>rmdir</b></i>: Delete a file, create a directory, or remove a directory on the server.</li><li><i><b>bye</b></i> / <i><b>quit</b></i>: Close the FTP connection and exit the client.</li><li><i><b>help</b></i> / <i><b>?</b></i>: Display help for available commands.</li></ul>


title: HISTORY
content:
<i>netkit-ftp</i> is part of the broader <i>netkit</i> package, which historically provided a collection of fundamental networking utilities for Unix-like operating systems. It represents an older, widely adopted implementation of the standard FTP client, having been a ubiquitous tool in Unix/Linux environments for many years before more feature-rich or secure alternatives gained prominence. Its design reflects the common FTP usage patterns and protocol specifications prevalent in the early days of the internet, emphasizing basic command-line interaction.


title: SEE ALSO
content:
<i>sftp(1)</i>: Secure File Transfer Program (via SSH)., <i>lftp(1)</i>: Sophisticated command-line FTP/HTTP/FXP client., <i>wget(1)</i>: Non-interactive network downloader., <i>scp(1)</i>: Secure copy (remote file copy program)., <i>ncftp(1)</i>: User-friendly FTP client with advanced features.


title: SYNOPSIS
content:
<I>netlify <command> [options/flags]</I><br><br>Examples:<br><I>netlify deploy [--prod] [--dir=path]</I><br><I>netlify build</I><br><I>netlify login</I><br><I>netlify link</I><br><I>netlify functions:create</I>


title: PARAMETERS
content:
<b><I>--help, -h</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the current command or subcommand.<br><br><b><I>--version, -v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the Netlify CLI being used.<br><br><b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs command results in JSON format, useful for scripting.<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging for debugging purposes.<br><br><b><I>--auth &lt;token&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an authentication token to use for the command, overriding default methods.<br><br><b><I>--base &lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the base directory for the command to operate within, if different from the project root.<br><br><b><I>--cwd &lt;path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the current working directory for the command execution, if different from the terminal's CWD.<br><br><b><I>--offline</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to operate in offline mode, useful for commands that don't require an active internet connection.<br><br>


title: DESCRIPTION
content:
The <I>netlify</I> command-line interface (CLI) is a powerful tool that allows developers to interact with the Netlify platform directly from their terminal. Netlify is a leading platform for web development, offering hosting, serverless functions, form handling, and continuous deployment for modern web projects. The <I>netlify</I> CLI simplifies workflows by enabling users to deploy sites, manage DNS, create and test serverless functions, link local projects to existing Netlify sites, build projects, and much more, all without leaving the command line. It's an indispensable tool for teams and individuals leveraging Netlify's ecosystem, particularly for projects built with modern frontend frameworks and static site generators. It streamlines the development and deployment process, making it highly efficient for JAMstack (JavaScript, APIs, Markup) architectures.


title: CAVEATS
content:
The <I>netlify</I> CLI requires Node.js and npm (or Yarn) for installation and execution. An active Netlify account is necessary to fully utilize its deployment and management features. Most operations, such as deployment, login, and fetching site information, require an active internet connection. It is not a native Linux command; it must be installed separately as a Node.js package.


title: INSTALLATION
content:
The Netlify CLI is typically installed globally using npm: <br><I>npm install -g netlify-cli</I><br>Ensure Node.js and npm are installed on your system first.


title: AUTHENTICATION
content:
Before deploying or managing sites, you need to authenticate your CLI with your Netlify account:<br><I>netlify login</I><br>This command will open a browser window for authentication and link your CLI to your Netlify account.


title: KEY SUBCOMMANDS
content:
The <I>netlify</I> command is structured around subcommands, each providing specific functionality. Some frequently used subcommands include:<br>- <I>netlify deploy</I>: Deploys a site to Netlify.<br>- <I>netlify build</I>: Builds your project locally, simulating Netlify's build process.<br>- <I>netlify init</I>: Initializes a new Netlify site or links a local project to an existing one.<br>- <I>netlify dev</I>: Runs a local development server for your site, including Netlify Functions and proxying.<br>- <I>netlify functions</I>: Manages serverless functions (e.g., <I>netlify functions:create</I>, <I>netlify functions:serve</I>).<br>Each subcommand often has its own set of specific flags and options, which are not exhaustively listed under global parameters.


title: HISTORY
content:
Netlify was founded in 2014 by Mathias Biilmann and Chris Bach, pioneering the concept of "Jamstack" and modern web development workflows. The Netlify CLI was developed to complement their platform, providing developers with a local interface for their services. It has evolved significantly over time, adding support for serverless functions, local development environments, and advanced deployment options, becoming an integral part of the Netlify developer experience for continuous integration and delivery. Its development has mirrored the growth of the Jamstack architecture and the increasing need for streamlined, command-line driven workflows.


title: PARAMETERS
content:
<b>-H <I>host</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target hostname or IP address where the <b>netserver</b> daemon is running.<br><br><b>-l <I>duration</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the duration of the test in seconds. A value of 0 (default) runs indefinitely until interrupted.<br><br><b>-t <I>testname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select the type of test to perform. Common types include <I>TCP_STREAM</I> (bulk TCP transfer), <I>UDP_STREAM</I> (bulk UDP transfer), <I>TCP_RR</I> (TCP request/response), and <I>UDP_RR</I> (UDP request/response).<br><br><b>-p <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the port number on which <b>netserver</b> is listening. Default is 12865.<br><br><b>-L <I>local_host</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the local IP address to bind to for the test, useful on multi-homed systems.<br><br><b>-s <I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the size of the socket send buffer for the netperf side (client).<br><br><b>-S <I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the size of the socket receive buffer for the netperf side (client).<br><br><b>-f <I>units</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output units for throughput. E.g., 'm' for MBits/sec, 'M' for MBytes/sec, 'g' for GBits/sec, 'G' for GBytes/sec.<br><br><b>-P <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the display of test progress and results. Higher levels (e.g., 1 or 2) provide more detail during the test or at conclusion.<br><br><b>-c, -C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable CPU utilization measurements on the client (<b>-c</b>) and server (<b>-C</b>) respectively. This helps identify CPU bottlenecks.<br><br><b>-m <I>size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the size of the data messages (request/response buffer size) used during the test, especially relevant for RR tests.<br><br>


title: DESCRIPTION
content:
netperf is a powerful command-line utility for measuring various aspects of network performance, including throughput (bandwidth) and transaction latency. It operates in a client-server model, requiring a <b>netserver</b> daemon to be running on the target machine. netperf supports a wide range of test types for TCP and UDP, including stream (bulk data transfer) and request/response (transactional) tests. It provides detailed statistics on data transfer rates, CPU utilization, and latency, making it valuable for network diagnostics, capacity planning, and benchmarking.


title: CAVEATS
content:
netperf requires the <b>netserver</b> daemon to be running on the target remote host. Firewalls must be configured to allow traffic on the specified port (default 12865). Test results can be significantly influenced by operating system TCP/IP stack tuning (e.g., buffer sizes, congestion control algorithms). For accurate results, ensure minimal other network or CPU load on both client and server machines during testing.


title: CLIENT-SERVER ARCHITECTURE
content:
netperf operates as a client program that initiates a connection to a <b>netserver</b> daemon running on the remote target machine. This client-server model allows for comprehensive performance measurement between any two points on a network, regardless of their physical location.


title: KEY TEST TYPES
content:
netperf supports various test types to address different network performance metrics:<br><br><b>Stream Tests</b> (<I>TCP_STREAM</I>, <I>UDP_STREAM</I>): Designed to measure maximum bulk data transfer throughput, indicating raw bandwidth.<br><br><b>Request/Response Tests</b> (<I>TCP_RR</I>, <I>UDP_RR</I>): Focus on measuring transaction rate and latency by sending small requests and awaiting responses, ideal for assessing application-level responsiveness.


title: INTERPRETING RESULTS
content:
The output of netperf typically includes key metrics such as transfer rates (in Mb/s, MB/s, Gb/s, or GB/s), transaction rates (transactions per second), and latency (in microseconds). Additionally, CPU utilization metrics for both the local client and remote server can be reported, which are crucial for identifying if network performance is being limited by CPU bottlenecks.


title: HISTORY
content:
netperf was originally developed by Rick Jones at Hewlett-Packard, establishing itself as a foundational tool for network performance measurement in Unix and Linux environments. Its design predates many modern network benchmarking tools and has been widely used for benchmarking network interfaces, protocol stacks, and overall system network capabilities for decades.


title: SYNOPSIS
content:
<b>netplan</b> [--debug] <i>COMMAND</i> [<i>OPTIONS</i>] [<i>ARGUMENTS</i>]<br><br><b>Common Commands:</b><br><b>netplan generate</b> [--config-file <i>&lt;path&gt;</i>]<br><b>netplan apply</b> [--config-file <i>&lt;path&gt;</i>] [--dry-run] [--force]<br><b>netplan try</b> [--config-file <i>&lt;path&gt;</i>] [--timeout <i>&lt;seconds&gt;</i>]<br><b>netplan status</b><br><b>netplan info</b>


title: PARAMETERS
content:
<b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output for <b>netplan</b> operations, showing more details about parsing and backend configuration generation.<br><br><b><b>--config-file</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used by generate, apply, try, revert, info)</i> Specifies an alternative YAML configuration file or directory to process instead of the default locations (e.g., /etc/netplan/). This is useful for testing or specific deployments.<br><br><b><b>--timeout</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used by try)</i> Sets the timeout in seconds for the 'netplan try' command. If the network is not usable within this period, changes are automatically reverted to the previous working configuration, providing a safety net.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used by apply)</i> Shows what changes would be made by 'netplan apply' without actually applying them to the system. This allows for a preview of the configuration impact.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Used by apply)</i> Forces the activation of the network configuration, even if errors or warnings are detected during the process. Use with caution as it might lead to unexpected network behavior.<br><br>


title: DESCRIPTION
content:
The <b>netplan</b> command provides a declarative way to configure network interfaces on Linux systems. It uses YAML files to define network settings, including IP addresses, DNS servers, routes, and more. Rather than directly interacting with low-level network tools, <b>netplan</b> acts as an abstraction layer, generating appropriate configuration files for different backend network renderers, such as <i>systemd-networkd</i> or <i>NetworkManager</i>.<br><br>This approach simplifies network setup and ensures consistent configuration across various Linux distributions and environments. Users define their desired network state in human-readable YAML, and <b>netplan</b> handles the intricate details of applying those settings. Key subcommands include <b>generate</b> (to create backend configs), <b>apply</b> (to activate configurations), and <b>try</b> (to test changes with a revert mechanism).


title: CAVEATS
content:
<ul><li><b>YAML Syntax Sensitivity:</b> <b>netplan</b> configurations are highly sensitive to YAML syntax, including indentation and spacing. Incorrect formatting can prevent the configuration from being parsed correctly.</li><li><b>Backend Dependency:</b> <b>netplan</b> relies on an underlying network renderer (like <i>systemd-networkd</i> or <i>NetworkManager</i>) to apply configurations. Ensure one of these is installed and active on your system for <b>netplan</b> to function correctly.</li><li><b>Root Privileges:</b> All <b>netplan</b> commands that modify or apply network configurations (e.g., <b>generate</b>, <b>apply</b>, <b>try</b>) require root privileges (e.g., using <b>sudo</b>).</li><li><b>Limited Scope:</b> While powerful for network interface configuration, <b>netplan</b> does not directly manage advanced networking features like firewall rules (e.g., <b>iptables</b>, <b>ufw</b>) or VPN connections, which are typically handled by other dedicated tools.</li></ul>


title: CONFIGURATION FILES
content:
<b>netplan</b> configuration files are written in YAML format and are typically located in <i>/etc/netplan/</i>. Other locations like <i>/run/netplan/</i> (for runtime configurations) and <i>/lib/netplan/</i> (for vendor-provided configurations) are also processed. Files are read in lexical order, with later files (e.g., <i>99-custom.yaml</i>) overriding earlier ones for conflicting settings, allowing for easy customization.


title: NETWORK RENDERERS
content:
<b>netplan</b> does not directly manage the network interfaces; instead, it generates configuration files for a specified backend 'renderer'. The two primary renderers supported are <i>systemd-networkd</i> (often the default for server installations and headless systems due to its lightweight nature) and <i>NetworkManager</i> (common for desktop environments due to its extensive GUI and Wi-Fi support). The chosen renderer is specified within the <b>netplan</b> YAML configuration file (e.g., <code>renderer: networkd</code> or <code>renderer: NetworkManager</code>).


title: TYPICAL WORKFLOW
content:
The typical workflow for configuring network with <b>netplan</b> involves a few straightforward steps:<br>1. <b>Edit:</b> Create or modify YAML configuration files in <i>/etc/netplan/</i> using a text editor.<br>2. <b>Validate (Optional):</b> Run <b>netplan generate</b> to check for syntax errors and compile the YAML into backend-specific configuration files (e.g., for <i>systemd-networkd</i> or <i>NetworkManager</i>).<br>3. <b>Apply/Try:</b> Use <b>netplan apply</b> to immediately activate the new configuration, or for safer changes, use <b>netplan try</b> which applies the configuration but reverts it after a timeout if network connectivity is lost, providing an automatic rollback mechanism.


title: HISTORY
content:
<b>netplan</b> was developed by Canonical, the creators of Ubuntu, and was first introduced with Ubuntu 17.10 (Artful Aardvark) in October 2017. Its primary goal was to provide a unified and consistent method for network configuration across various Ubuntu releases and server environments, abstracting away the differences between underlying network management daemons like <i>systemd-networkd</i> and <i>NetworkManager</i>. This declarative approach aimed to simplify network management for administrators and cloud deployments, providing a single YAML-based configuration format.


title: PARAMETERS
content:
<b>show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays one or more Netris resources. <i>For example, use `netris show sites` or `netris show bgp` to inspect the current state of network entities.</i><br><br><b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Netris resource. <i>Typically used with a configuration file (`-f <file.yaml>`) defining the resource's properties, like `netris create vnet -f my-vnet.yaml`.</i><br><br><b>apply</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a configuration to a Netris resource. This command can create new resources or update existing ones based on a provided configuration file. <i>It's often used for declarative management, similar to `netris apply -f network-config.yaml`.</i><br><br><b>delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes one or more Netris resources by name or ID. <i>For example, `netris delete vnet my-virtual-network`.</i><br><br><b>login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates the CLI client with the Netris Controller. This command prompts for credentials and saves the authentication token for subsequent commands.<br><br><b>logout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deauthenticates the CLI client from the Netris Controller, removing stored credentials.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides help for the <b>netris</b> command itself, or for specific subcommands. <i>For example, `netris help show` displays options for the `show` command.</i><br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the <b>netris</b> CLI client and the connected Netris Controller.<br><br><b>--config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A <i>global option</i> that specifies the path to the Netris configuration file, overriding the default location (e.g., `netris --config ~/.netris/dev-config.yaml show sites`).<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A <i>global option</i> that formats the command output as JSON, suitable for programmatic parsing (e.g., `netris show sites --json`).<br><br><b>--yaml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A <i>global option</i> that formats the command output as YAML (e.g., `netris show bgp --yaml`).<br><br>


title: DESCRIPTION
content:
The <b>netris</b> command is the primary command-line interface (CLI) for interacting with the Netris network automation platform. Netris is an intent-based networking software that automates the deployment, operation, and troubleshooting of network infrastructure in data centers and cloud environments.<br><br>The <b>netris</b> CLI allows network operators, DevOps engineers, and developers to manage their network resources programmatically. It provides a unified control plane to define network intents, such as creating virtual networks (VNETs), configuring Border Gateway Protocol (BGP) sessions, deploying load balancers, or managing VPN connections. Instead of configuring individual devices, users declare their desired network state, and Netris automates the underlying configurations across various network devices.<br><br>Key functionalities include provisioning network services, monitoring network health, troubleshooting issues, and integrating with other automation tools. The CLI supports both interactive use and scripting, making it a critical component for NetDevOps workflows and continuous integration/continuous deployment (CI/CD) pipelines for network changes.


title: CAVEATS
content:
<ul><li>The <b>netris</b> CLI requires active network connectivity to a running Netris Controller.</li><li>Successful operation depends on proper authentication credentials and appropriate user permissions defined within the Netris platform.</li><li>The exact syntax and available subcommands can vary slightly based on the Netris Controller version.</li><li>Resource creation and modification commands often rely on YAML or JSON configuration files, demanding familiarity with Netris resource definitions and API schema.</li></ul>


title: CONFIGURATION FILE
content:
The <b>netris</b> CLI typically stores its configuration, including authentication tokens and controller endpoints, in a YAML file. By default, this file is located at <i>~/.netris/config</i>. This file can be manually edited or managed via the <b>netris login</b> and <b>netris logout</b> commands. The `--config` global option can be used to specify an alternative configuration file for different environments or contexts.


title: INTENT-BASED NETWORKING
content:
At its core, Netris operates on an intent-based networking paradigm. This means users define the desired outcome or 'intent' for their network (e.g., 'I want a virtual network connecting these two servers with a specific IP range'). The <b>netris</b> CLI is the primary mechanism to declare these intents. The Netris Controller then translates this intent into the necessary low-level configurations across all involved network devices, continuously verifying that the actual network state matches the declared intent.


title: HISTORY
content:
Netris emerged as a modern solution for automating complex data center networking, shifting from traditional manual configurations to an intent-based, software-defined approach. The <b>netris</b> CLI has been central to this vision since the platform's inception, providing a unified and programmatic interface for managing the entire network lifecycle. Its development aligns with the rise of NetDevOps principles, enabling network engineers to integrate network operations into CI/CD workflows, apply version control to network configurations, and automate deployments. The CLI's design, inspired by tools like <b>kubectl</b>, emphasizes declarative configuration and idempotent operations, making it suitable for both interactive troubleshooting and large-scale automation.


title: PARAMETERS
content:
<b><b>-c</b> <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of ICMP echo requests (pings) to send to each host. Defaults to 5 pings.<br><br><b><b>-m</b> <I>min_success</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum number of successful pings required for a host to be considered viable. Defaults to 2 successful pings.<br><br><b><b>-o</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the command's output to the specified file instead of standard output.<br><br><b><b>-p</b> <I>parallel</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the maximum number of hosts to ping simultaneously. Defaults to 16 parallel connections.<br><br><b><b>-s</b> <I>samples</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of ping samples to average for ranking. A higher value leads to a more reliable but slower test. Defaults to 3 samples.<br><br><b><b>-t</b> <I>timeout</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout for each individual ping request in seconds. Defaults to 2 seconds.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the ping process and scores for each host.<br><br><b><b>-4</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>netselect</b> to use IPv4 addresses only for host resolution and pinging.<br><br><b><b>-6</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>netselect</b> to use IPv6 addresses only for host resolution and pinging.<br><br>


title: DESCRIPTION
content:
The <b>netselect</b> command is a utility designed to identify the fastest and most reliable network host from a given list, typically used for choosing optimal mirrors for software repositories.<br><br>It operates by sending multiple ICMP echo requests (pings) to each specified host, measuring the round-trip time (latency) and detecting packet loss. Based on these metrics, <b>netselect</b> calculates a 'score' for each host, where a lower score indicates a faster and more reliable connection. The output is a sorted list of hosts, with the best-performing ones appearing at the top.<br><br>This tool is particularly useful for users who need to select the best mirror for their Linux distribution's package manager (e.g., Debian's <i>apt</i> or Ubuntu's <i>apt</i>), ensuring quicker and more stable downloads of software packages and updates.


title: CAVEATS
content:
Results from <b>netselect</b> represent a snapshot in time and can change due to network conditions, server load, or routing changes. It primarily relies on ICMP, so hosts or networks blocking ICMP traffic may yield inaccurate results. For very large lists of hosts, execution can be time-consuming, and simultaneous pinging may cause network congestion or be throttled by firewalls.


title: OUTPUT FORMAT
content:
The default output of <b>netselect</b> is a sorted list of hosts, each preceded by a numerical 'score'. A lower score indicates better performance. The score is typically calculated based on a weighted average of latency and packet loss. For example: <br><i>123 hostname.example.com</i><br><i>456 another.example.net</i><br>This allows users to easily pick the top-ranked host for their specific needs, often for updating configuration files related to package mirrors.


title: HISTORY
content:
<b>netselect</b> is a specialized utility primarily found within the Debian and Ubuntu ecosystems, often bundled as part of core system utilities like 'debianutils'. Its development is driven by the need for users to easily identify the best-performing mirror servers for their package managers, a critical task for maintaining up-to-date and efficient systems. It's not a standalone command with a long, distinct historical lineage like many general-purpose Unix tools, but rather a focused solution for a specific system administration problem.


title: PARAMETERS
content:
<b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for mirrors providing the <i>unstable</i> (sid) distribution instead of stable.<br><br><b><i>-u</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for mirrors providing the <i>testing</i> distribution instead of stable.<br><br><b><i>-o <outfile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the generated <i>sources.list</i> entry to the specified file instead of standard output.<br><br><b><i>-c <country_code></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the search for mirrors to a specific country, e.g., <i>US</i>, <i>DE</i>, <i>FR</i>.<br><br><b><i>-l <count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of fastest mirrors to select and include in the output. Default is <i>1</i>.<br><br><b><i>-n <filename></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the mirror list provided in the specified file instead of the default Debian mirrors list.<br><br><b><i>-t <count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of tests (pings) to perform per host to determine its score. Default is <i>2</i>.<br><br><b><i>-r <count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of rounds of testing to perform. Default is <i>1</i>.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the mirror selection process.<br><br><b><i>-x <hosts></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specified hosts (comma-separated) from the mirror selection process. Example: <i>mirror1.org,mirror2.net</i>.<br><br><b><i>-i <hosts></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include only specified hosts (comma-separated) in the mirror selection process. Example: <i>mirror3.com,mirror4.edu</i>.<br><br><b><i>-p</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output only the mirror URL, not the full <i>sources.list</i> line.<br><br><b><i>-w</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output comments in the generated <i>sources.list</i> entry.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the program's version information and exit.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with usage information and exit.<br><br><b><i><mirror_protocol></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional: The protocol to use for the mirror, e.g., <i>http</i> (default), <i>ftp</i>, <i>https</i>. Applies only when a specific <i><mirror_name></i> is given.<br><br><b><i><mirror_name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional: The base name of the mirror site (e.g., <i>ftp.debian.org</i>). When provided, <i>netselect-apt</i> attempts to select from its known sub-mirrors or directly test it.<br><br>


title: DESCRIPTION
content:
<i>netselect-apt</i> is a utility designed to help Debian and Ubuntu users find the fastest APT (Advanced Package Tool) mirrors for their system. It leverages the <i>netselect</i> program to ping and benchmark various archive mirrors, calculating their scores based on network latency and packet loss. By identifying the mirror with the lowest score (indicating best performance), it generates an optimized <i>sources.list</i> entry, ensuring quicker package downloads and updates. This command is particularly useful for users looking to improve the speed and reliability of their package management operations, leading to faster updates and package installations.


title: CAVEATS
content:
Network conditions are dynamic; a fast mirror today might be slow tomorrow. It's advisable to re-run <i>netselect-apt</i> periodically for optimal results.<br>The tool relies on <i>netselect</i> which performs ping-like tests. Firewalls or network configurations blocking ICMP might affect its accuracy.<br>While <i>netselect-apt</i> can suggest HTTP mirrors, it's generally recommended to use HTTPS mirrors for enhanced security. Users should verify and adjust protocols in their <i>sources.list</i> if needed.<br>Some mirrors might be geographically close but have poor routing, leading to higher latency despite proximity.


title: UPDATING SOURCES.LIST
content:
After running <i>netselect-apt</i>, the output (either to standard output or a file) typically contains a 'deb' line for your <i>sources.list</i>. You need to manually update your <i>/etc/apt/sources.list</i> file or create a new file (e.g., <i>fast-mirror.list</i>) in <i>/etc/apt/sources.list.d/</i> with this content.<br><i>Example:</i> <code>sudo netselect-apt -c US &gt; /etc/apt/sources.list.d/fast-mirror.list</code><br>Remember to run <code>sudo apt update</code> after modifying <i>sources.list</i> to refresh your package lists.


title: UNDERLYING MECHANISM
content:
<i>netselect-apt</i> relies heavily on the <i>netselect</i> command. <i>netselect</i> calculates a "score" for each host based on a combination of ping times and packet loss. A lower score indicates a better, faster mirror. <i>netselect-apt</i> parses the mirror lists, feeds them to <i>netselect</i>, and then formats the result into an APT-compliant <i>sources.list</i> entry.


title: HISTORY
content:
<i>netselect-apt</i> was developed as a helper script for <i>netselect</i>, a tool designed to measure network performance between a local host and multiple remote hosts. Its purpose was to automate the often tedious process of finding the optimal APT mirror for Debian and later Ubuntu distributions. It simplifies the <i>sources.list</i> configuration by directly generating the relevant entry based on performance metrics. Its development reflects the ongoing need for efficient package management in distributed systems, ensuring users connect to the closest and most responsive mirrors for faster updates and package downloads.


title: SYNOPSIS
content:
<b>netserver</b> [<I>options</I>]<br><b>netserver</b> [-4] [-6] [-L <I>host</I>[,<I>port</I>]] [-p <I>port</I>] [-D] [-u] [-P] [-S] [-s] [-h] [-v] [-M <I>value</I>] [-N <I>value</I>] [-t <I>value</I>] [-T <I>value</I>]


title: PARAMETERS
content:
<b>-4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>netserver</I> to use IPv4 addresses exclusively for listening.<br><br><b>-6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>netserver</I> to use IPv6 addresses exclusively for listening.<br><br><b>-L <I>host</I>[,<I>port</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local host interface and an optional port number for <I>netserver</I> to bind to. This is useful for multi-homed systems.<br><br><b>-p <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TCP/IP port number on which <I>netserver</I> will listen for incoming connections. The default port is 12865.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing more verbose information about <I>netserver</I>'s operations for troubleshooting.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current <I>netserver</I> build date and exits.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Process ID (PID) of the <I>netserver</I> daemon to standard output upon startup.<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <I>netserver</I> to use shared memory for certain context messages, primarily when a shared memory transport is involved. This is an advanced option.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables security checks, often used in conjunction with the <I>netperf</I> client's 'remote' option to restrict access.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise help message detailing available command-line options and then exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <I>netserver</I> utility and then exits.<br><br><b>-M <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of bytes that <I>netserver</I> will allocate for response messages.<br><br><b>-N <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the maximum number of network buffers that <I>netserver</I> should pre-allocate to handle incoming data.<br><br><b>-t <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the interval (in seconds) at which <I>netserver</I> checks for and reaps orphaned child processes that have completed their tasks.<br><br><b>-T <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Establishes an idle timeout (in seconds) for client connections. If no activity is detected within this period, the connection may be closed.<br><br>


title: DESCRIPTION
content:
The <I>netserver</I> command is a daemon that operates as the server-side component of the <I>netperf</I> network performance benchmarking tool. It passively listens on a specified TCP/IP port (defaulting to 12865) for incoming connection requests from a <I>netperf</I> client.<br><br>Upon establishing a connection, <I>netserver</I> forks a child process to handle the specific benchmark request, enabling the parent process to continue listening for new client connections. It supports a wide array of test types initiated by the client, including TCP and UDP stream tests, request/response transactions, and various others, facilitating precise measurements of network throughput, latency, and even CPU utilization during data transfers.<br><br>Running <I>netserver</I> on a remote host is a fundamental prerequisite for conducting comprehensive network performance analyses between two distinct systems, providing crucial data for network optimization and troubleshooting.


title: CAVEATS
content:
<b>Firewall Configuration:</b> The default listening port (12865) must be open in any firewall between the <I>netperf</I> client and <I>netserver</I> to allow communication.<br><br><b>Security Implications:</b> While <I>netserver</I> is essential for performance testing, it does not implement strong authentication or authorization mechanisms by default. It is generally recommended to run it in controlled, trusted network environments or to utilize its -s security option where applicable. Avoid exposing it directly to the public internet.<br><br><b>Resource Consumption:</b> During active benchmark tests, <I>netserver</I> (and its child processes) can consume significant CPU, memory, and network bandwidth resources. Ensure the host running <I>netserver</I> has adequate resources to avoid skewing test results.


title: <B>TYPICAL USAGE</B>
content:
To conduct a network performance test, <I>netserver</I> is first started on the target server machine. For example: <br><br>netserver -p 12865<br><br>Then, from a client machine, the <I>netperf</I> command is executed, pointing to the <I>netserver</I> host and port, such as:<br><br>netperf -H <I>server_ip</I> -l 10 -t TCP_STREAM<br><br>This setup allows for unidirectional or bidirectional performance measurements, depending on the <I>netperf</I> test type.


title: <B>INTERACTION WITH NETPERF</B>
content:
<I>netserver</I> operates as the passive endpoint, waiting for instructions from the <I>netperf</I> client. It does not initiate any tests itself. When a <I>netperf</I> client connects and requests a specific test (e.g., a TCP stream throughput test), <I>netserver</I> sets up the necessary data transfer mechanisms on its end (e.g., opening a data socket) and then participates in the data exchange as directed by the client, collecting statistics which are then reported back to the <I>netperf</I> client.


title: HISTORY
content:
The <I>netserver</I> utility is an integral part of the <I>netperf</I> benchmarking suite, which was originally developed by Hewlett-Packard (HP) in the early 1990s. <I>netperf</I> was created to provide a robust and flexible tool for measuring various aspects of network performance, particularly in heterogeneous environments. It quickly gained adoption in the networking and systems administration communities due to its comprehensive testing capabilities and detailed output.<br><br>While many other network benchmarking tools have emerged, <I>netperf</I> (and thus <I>netserver</I>) remains a widely respected and actively maintained project, continually updated to support modern networking protocols and hardware. Its design, separating client and server components, allows for precise end-to-end performance measurements across different machines.


title: SYNOPSIS
content:
netsniff-ng [-i <dev>] [-o <pcap>] [-s <len>] [-f <BPF_filter>] [-N] [-X] [-H] [-L] [-S <size>] [-t <timeout>] [-c <count>] [-b <size>] [-P <pcap>] [-k] [-v] [-h]


title: PARAMETERS
content:
<b><b>-i</b> <dev></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to capture packets from (e.g., eth0, wlan0).<br><br><b><b>-o</b> <pcap></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write captured packets to a PCAP formatted file for later analysis.<br><br><b><b>-s</b> <len></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the snapshot length (snaplen) for captured packets. Only capture the first <len> bytes of each packet. Use 0 for full packets.<br><br><b><b>-f</b> <BPF_filter></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a Berkeley Packet Filter (BPF) expression to filter captured packets based on criteria like IP address, port, or protocol.<br><br><b><b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not put the specified network interface into promiscuous mode, capturing only traffic destined for the host.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the PCAP index, showing offsets and timestamps of packets within the capture file.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump packet headers only, rather than the entire packet payload.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump link-layer information, such as MAC addresses.<br><br><b><b>-S</b> <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a specific ring buffer packet size (e.g., 2048) in bytes for internal operations.<br><br><b><b>-t</b> <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop capturing packets after a specified timeout duration (in seconds).<br><br><b><b>-c</b> <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop capturing packets after a specified number of packets have been captured.<br><br><b><b>-b</b> <size></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ring buffer size (e.g., 64MB) to allocate memory for packet capture.<br><br><b><b>-P</b> <pcap></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replay packets from a specified PCAP file onto a network interface.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show kernel statistics related to packet capture, such as dropped packets and errors.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information during operation.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br>


title: DESCRIPTION
content:
<b>netsniff-ng</b> is a free, high-performance, and versatile Linux network sniffer and packet analyzer. It is a core component of the `netsniff-ng` toolkit, engineered for <i>zero-copy</i> packet capturing, replaying, and analysis directly from the kernel space.<br><br>Unlike traditional sniffers that often rely on <i>libpcap</i>, <b>netsniff-ng</b> leverages the `mmap()` interface and `PACKET_MMAP` ring buffers for enhanced efficiency and reduced CPU overhead. This design makes it exceptionally suitable for high-throughput network environments, minimizing dropped packets under heavy load.<br><br>It supports various output formats, including standard <i>PCAP</i> and <i>PCAP-ng</i>, and allows for powerful filtering using Berkeley Packet Filter (BPF) syntax. Beyond live capturing, <b>netsniff-ng</b> can also perform offline analysis and packet injection/replay, making it an indispensable tool for network security monitoring, performance testing, and deep protocol analysis.


title: CAVEATS
content:
Using <b>netsniff-ng</b> for most operations requires <i>root privileges</i>. Its reliance on Linux-specific kernel features like <i>PACKET_MMAP</i> means it is <i>not portable</i> to other operating systems. While highly efficient, large ring buffer sizes can consume significant system memory. Understanding Berkeley Packet Filter (BPF) syntax can be challenging for new users.


title: FILTERING CAPABILITIES
content:
<b>netsniff-ng</b> utilizes the widely adopted <i>Berkeley Packet Filter (BPF)</i> syntax for packet filtering. This allows users to create highly precise rules to capture only packets matching specific criteria, such as source/destination IP addresses, port numbers, protocols (e.g., tcp, udp, icmp), or even packet sizes. This powerful filtering mechanism significantly reduces the amount of irrelevant data captured, making analysis more efficient.


title: ZERO-COPY MECHANISM
content:
The core performance advantage of <b>netsniff-ng</b> is its implementation of a <i>zero-copy</i> mechanism, primarily through the use of <i>PACKET_MMAP</i>. Instead of copying packet data multiple times between the kernel and user space, `PACKET_MMAP` allows direct memory mapping. This direct access minimizes CPU cycles spent on data movement, enabling <b>netsniff-ng</b> to handle extremely high packet rates with significantly less overhead and fewer dropped packets compared to traditional methods.


title: PACKET REPLAY
content:
Beyond its robust capturing capabilities, <b>netsniff-ng</b> also offers a valuable <i>packet replay</i> feature. Using the <b>-P</b> option, users can take a previously captured PCAP file and re-inject those packets onto a network interface. This is immensely useful for network device testing, simulating specific traffic conditions, reproducing security incidents, or benchmarking network performance in a controlled environment.


title: HISTORY
content:
<b>netsniff-ng</b> is part of the `netsniff-ng` toolkit, primarily developed by <i>Daniel Borkmann</i>. Its inception was driven by the need for a high-performance packet sniffer that could overcome the limitations of traditional <i>libpcap</i>-based tools in high-speed network environments. Developed from the ground up, it leverages Linux-specific kernel features such as <i>PACKET_MMAP ring buffers</i> and <i>zero-copy mechanisms</i> to ensure maximum efficiency and minimal CPU overhead. This focus on kernel-level integration and performance makes it a modern and powerful alternative for demanding packet capture and analysis tasks.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all sockets, including both listening and non-listening (established) connections.<br><br><b><b>-l</b>, <b>--listening</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only listening sockets (i.e., servers waiting for connections).<br><br><b><b>-t</b>, <b>--tcp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only TCP (Transmission Control Protocol) connections.<br><br><b><b>-u</b>, <b>--udp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays only UDP (User Datagram Protocol) connections.<br><br><b><b>-n</b>, <b>--numeric</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows numerical addresses and port numbers instead of resolving hostnames, service names, and user IDs. This speeds up output.<br><br><b><b>-p</b>, <b>--programs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the PID (Process ID) and name of the program owning the socket. Requires root privileges to see all processes.<br><br><b><b>-r</b>, <b>--route</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the kernel IP routing table. This is equivalent to using the <b>route -e</b> command.<br><br><b><b>-i</b>, <b>--interfaces</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a table of all network interfaces and their statistics, including bytes sent/received and error counts.<br><br><b><b>-s</b>, <b>--statistics</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Presents per-protocol statistics for various network protocols (e.g., IP, ICMP, TCP, UDP).<br><br><b><b>-c</b>, <b>--continuous</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the selected information continuously, updating every one second until interrupted (Ctrl+C).<br><br>


title: DESCRIPTION
content:
The <b>netstat</b> (network statistics) command is a command-line utility used to display network connections, routing tables, interface statistics, masquerade connections, and multicast memberships. It provides a comprehensive overview of network activity on a Linux system.<br><br>Historically, <b>netstat</b> has been an essential tool for system administrators and network engineers for troubleshooting network connectivity issues, monitoring network performance, and identifying open ports or suspicious connections. It can show both active and passive sockets, including TCP, UDP, raw, and Unix domain sockets. Although widely used for decades, <b>netstat</b> is now considered deprecated in many modern Linux distributions. Its functionality has largely been superseded by tools from the <i>iproute2</i> suite, primarily <b>ss</b> for socket information and <b>ip</b> for routing and interface details, which offer more robust features and better performance.


title: CAVEATS
content:
The <b>netstat</b> command is part of the <i>net-tools</i> package, which has been largely superseded by the <i>iproute2</i> suite in modern Linux distributions. While still present for backward compatibility, new development and features are focused on <b>ss</b> and <b>ip</b>. Users are encouraged to transition to these newer tools for more efficient and robust network management. Parsing <b>netstat</b> output in scripts can be fragile due to its text-based, human-readable format.


title: COMMON USE CASES
content:
Here are some common ways to use <b>netstat</b>:<br>- To list all active TCP connections: <b>netstat -atn</b><br>- To list all listening UDP ports with associated programs: <b>netstat -ulpn</b><br>- To view the routing table: <b>netstat -rn</b><br>- To monitor interface statistics continuously: <b>netstat -ic</b>


title: TCP SOCKET STATES
content:
<b>netstat</b> output often includes TCP socket states, which are crucial for understanding connection lifecycles:<br>- <I>LISTEN</I>: The server is waiting for a connection request.<br>- <I>ESTABLISHED</I>: A connection is actively open and data is being exchanged.<br>- <I>TIME_WAIT</I>: The client has closed its end of the connection, but is waiting for the server to acknowledge.<br>- <I>CLOSE_WAIT</I>: The server has received a FIN from the client and is waiting for the application to close the socket.<br>- <I>SYN_SENT</I>: A connection request has been sent.<br>- <I>SYN_RECV</I>: A connection request has been received and a SYN-ACK has been sent.


title: HISTORY
content:
The <b>netstat</b> utility has been a staple in Unix-like operating systems for decades, providing essential network diagnostic capabilities. It was historically bundled as part of the <i>net-tools</i> package. With the advent of IPv6 and the need for more efficient and scriptable network management tools, the <i>iproute2</i> suite began to replace <i>net-tools</i>. Commands like <b>ss</b> and <b>ip</b> were developed to offer superior performance, better IPv6 support, and more machine-parseable output, leading to <b>netstat</b>'s eventual deprecation in many contemporary Linux systems.


title: PARAMETERS
content:
<b>-i, --targets <target></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target(s) for the scan. This can be an IP address, CIDR range, hostname, URL, or a path to a file containing a list of targets (one per line).<br><br><b>-m, --module-name <module></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the scan module to be used. Examples include <i>port_scan</i>, <i>web_info</i>, <i>xss_scan</i>, <i>sql_injection_scan</i>, <i>ftp_bruteforce</i>, <i>whois</i>, etc. Multiple modules can often be specified, separated by commas.<br><br><b>-s, --scan-method <method></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <i>--module-name</i>, specifies the specific scan method to execute. This can be a single method or a comma-separated list of methods to run sequentially.<br><br><b>-t, --threads <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of threads (concurrent workers) to use for scanning, affecting scan speed. Default values vary per module.<br><br><b>--ports <ports></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of ports or port ranges to scan (e.g., '80,443,21-23'). Primarily used with network scanning modules.<br><br><b>--timeout <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout for network requests in seconds.<br><br><b>--time-sleep <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the time to sleep between requests in seconds, useful for avoiding rate limiting or detection.<br><br><b>--retries <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of retries for failed requests.<br><br><b>-l, --log-path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where log files should be saved. Nettacker generates detailed logs of its operations.<br><br><b>-o, --output-path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where scan results will be saved. Results are often saved in JSON or HTML format for easy viewing.<br><br><b>--users <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of usernames to be used with bruteforcing modules (e.g., FTP, SSH, HTTP).<br><br><b>--passwords <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of passwords to be used with bruteforcing modules.<br><br><b>--proxy <proxy></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a proxy server (e.g., 'http://127.0.0.1:8080', 'socks5://127.0.0.1:9050') for all network requests.<br><br><b>--user-agent <agent></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom User-Agent string for HTTP requests, useful for evading detection or mimicking specific browsers.<br><br><b>--cookie <cookie></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets custom cookie headers for HTTP requests in the format 'name=value;'. Useful for authenticated scans.<br><br><b>--headers <headers></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Additional custom HTTP headers in 'Name:Value,' format (e.g., 'X-Forwarded-For:127.0.0.1').<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the ongoing scan processes and results directly to the console.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of the Nettacker framework and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message, listing all available options and basic usage examples.<br><br>


title: DESCRIPTION
content:
Nettacker is an open-source, automated penetration testing framework designed to streamline and simplify various security assessment tasks. It provides a comprehensive suite of modules for information gathering, vulnerability scanning, and bruteforcing, making it a versatile tool for security researchers, penetration testers, and system administrators. <br><br>The tool supports a wide range of functionalities including network scanning (e.g., port scanning, service detection), web application vulnerability assessments (e.g., XSS, SQL Injection, LFI, RFI, SSRF), CMS detection and vulnerability checks, and various information gathering techniques (e.g., Whois, DNS enumeration, subdomain discovery). Nettacker can identify common misconfigurations and vulnerabilities across different protocols and services, helping users to quickly pinpoint potential security weaknesses. Its modular design allows for flexible usage, enabling users to combine different scan methods to achieve specific assessment goals. Written primarily in Python, it's cross-platform and extensible.


title: CAVEATS
content:
Nettacker is a powerful penetration testing tool that can generate significant network traffic and potentially disrupt services if misused. It should <I>only</I> be used on systems for which you have explicit authorization. Unauthorized scanning or testing is illegal and unethical. Users must ensure proper network connectivity and a correctly configured Python environment (Python 3.x is required) for optimal performance. Some modules may require specific external libraries or dependencies.


title: INSTALLATION
content:
Nettacker can be installed via Python's package manager `pip` (e.g., `pip3 install nettacker`) which places the `nettacker` executable directly in your system's PATH. Alternatively, it can be installed by cloning its official GitHub repository and running it directly with Python (e.g., `git clone https://github.com/nettacker/nettacker.git && cd nettacker && python3 nettacker.py`). The `pip` installation is generally recommended for ease of use and updates.


title: SCAN MODULES OVERVIEW
content:
Nettacker organizes its functionalities into various modules, each specializing in a different type of assessment:<br><i>Information Gathering Modules:</i> such as <i>whois</i>, <i>dns_lookup</i>, <i>subdomain_finder</i>, and <i>reverse_ip</i> to collect intelligence.<br><i>Network Scanning Modules:</i> including <i>port_scan</i>, <i>banner_grabbing</i>, <i>arp_scan</i>, and <i>dhcp_scan</i> for network reconnaissance.<br><i>Web Vulnerability Scanning Modules:</i> covering a wide range of web application vulnerabilities like <i>xss_scan</i>, <i>sql_injection_scan</i>, <i>lfi_scan</i>, <i>rfi_scan</i>, <i>ssrf_scan</i>, <i>open_redirect_scan</i>, <i>cms_scan</i>, and <i>header_security_scan</i>.<br><i>Bruteforce Modules:</i> for protocols like <i>ftp_bruteforce</i>, <i>ssh_bruteforce</i>, <i>http_bruteforce</i>, and <i>smtp_bruteforce</i>.<br>Users can select specific modules or combine them to perform comprehensive assessments tailored to their needs.


title: HISTORY
content:
Nettacker is an active open-source project primarily developed and maintained by a community of security researchers and developers. It is hosted on GitHub, where its development history, including bug fixes, feature additions, and module expansions, can be traced through its commit logs and releases. Its continuous development aims to integrate new vulnerability checks and improve efficiency in automated security assessments. It has gained popularity due to its modular design and Python-based implementation, making it accessible and extensible for many users in the cybersecurity community.


title: PARAMETERS
content:
<b><B>-a</B>, <B>--all</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all network links, including inactive ones.<br><br><b><B>-s</B>, <B>--stats</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show network link statistics, such as packet counts and errors.<br><br><b><B>-l</B> <I>LINES</I>, <B>--lines</B>=<I>LINES</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the number of lines to show for property lists.<br><br><b><B>-o</B> <I>FORMAT</I>, <B>--output</B>=<I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output format. Common formats include 'json', 'json-pretty', 'short', 'plain'.<br><br><b><B>--no-pager</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b><B>--no-legend</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the header line of tables.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short help text and exit.<br><br><b><B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short version string and exit.<br><br>


title: DESCRIPTION
content:
<B>networkctl</B> is a powerful command-line utility for inspecting and controlling network interfaces managed by <I>systemd-networkd</I>.<br><br>It provides a comprehensive overview of network link states, including operational status, IP addresses, routes, and DNS configurations. Beyond inspection, <B>networkctl</B> enables management actions such as enabling or disabling specific links, bringing them up or down, and reconfiguring network settings. It simplifies network administration by tightly integrating with the <I>systemd</I> ecosystem, offering a unified interface for network configuration and troubleshooting, especially in environments where <I>systemd-networkd</I> is the primary network management daemon. It's an essential tool for system administrators to monitor and manipulate network connectivity on Linux systems.


title: CAVEATS
content:
<B>networkctl</B> primarily interacts with the <I>systemd-networkd</I> daemon. Therefore, it will only display and manage network interfaces that are configured and controlled by <I>systemd-networkd</I>.<br><br>Interfaces managed by other network management services (e.g., NetworkManager, ifupdown) may not be fully visible or controllable via <B>networkctl</B>.


title: COMMON COMMANDS
content:
<B>list</B>: List all discovered network links and their states.<br><br><B>status</B> [<I>LINK</I>]: Show detailed status information for all links, or a specific link if <I>LINK</I> is provided.<br><br><B>up</B> <I>LINK</I>: Bring a network link up and make it operational.<br><br><B>down</B> <I>LINK</I>: Bring a network link down, making it inoperable.<br><br><B>reconfigure</B> [<I>LINK</I>]: Reconfigure a network link, applying current configuration changes.<br><br><B>reload</B>: Reload systemd-networkd's configuration files without restarting the daemon.<br><br><B>restart</B>: Restart the systemd-networkd daemon.


title: USAGE EXAMPLE
content:
To list all network interfaces with their status:<br><br><B>networkctl list</B><br><br>To view detailed status of a specific interface, e.g., 'eth0':<br><br><B>networkctl status eth0</B><br><br>To bring an interface 'eth0' down:<br><br><B>networkctl down eth0</B>


title: HISTORY
content:
<B>networkctl</B> is an integral part of the <I>systemd</I> project, designed to provide a modern, unified interface for network configuration and status alongside <I>systemd-networkd</I>. It was introduced as part of the ongoing effort to centralize and standardize system management utilities under the systemd umbrella, aiming to replace older, more fragmented network tools for systems running <I>systemd</I>.


title: SYNOPSIS
content:
<b>nmcli</b> [<I>OPTIONS</I>] { <I>OBJECT</I> | <I>help</I> }<br><br>Common OBJECTS:<br><b>general</b>, <b>networking</b>, <b>radio</b>, <b>connection</b>, <b>device</b>, <b>agent</b><br><br>Common COMMANDS for objects:<br><b>show</b>, <b>status</b>, <b>up</b>, <b>down</b>, <b>add</b>, <b>modify</b>, <b>delete</b>, <b>connect</b>, <b>disconnect</b>


title: PARAMETERS
content:
<b>-t, --terse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in terse format, suitable for scripting.<br><br><b>-p, --pretty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in a more human-readable format, with column headers.<br><br><b>-f, --fields <list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which fields to output. E.g., 'NAME,UUID,TYPE'.<br><br><b>-e, --escape <yes|no></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escape all values in terse output (default 'yes').<br><br><b>-m, --mode <multiline|tabular></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set output mode for tabular output.<br><br><b>-s, --show-secrets</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show connection secrets like Wi-Fi passwords. Use with caution.<br><br><b>-a, --ask</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for missing parameters. Interactive prompt for secrets.<br><br><b>-w, --wait <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for NetworkManager to finish operations for the specified duration (default '5s').<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show nmcli version.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print help information.<br><br>


title: DESCRIPTION
content:
<br><i>nmcli</i> is the command-line client for NetworkManager. It provides a comprehensive and scriptable interface to control and configure network connections and devices. With <i>nmcli</i>, users can manage various network types, including Ethernet, Wi-Fi, mobile broadband, and VPNs.<br><br>It's designed for both interactive use and scripting, making it ideal for server environments or for automating network configurations. Key functionalities include displaying network status, activating and deactivating connections, adding, modifying, and deleting connection profiles, and controlling device states. <i>nmcli</i> acts as a powerful alternative to graphical network configuration tools, offering granular control over every aspect of NetworkManager's operations.


title: CAVEATS
content:
<b>NetworkManager Service Required:</b> <i>nmcli</i> commands only work if the NetworkManager daemon is running and active on the system.<br><br><b>Permissions:</b> Modifying network settings or creating connections usually requires root privileges or membership in the appropriate user group (e.g., <i>nmcli</i>, <i>network</i> or <i>wheel</i> depending on distribution setup). Read-only commands generally don't require elevated privileges.<br><br><b>Complexity for Advanced Scenarios:</b> While powerful, complex networking setups involving advanced routing or firewall rules might still require direct configuration of lower-level tools or systemd-networkd for finer control, depending on the integration.


title: KEY OBJECTS
content:
<i>nmcli</i> operates on several key 'objects', each representing a different aspect of network management:<br><b>general:</b> General NetworkManager status and information.<br><b>networking:</b> Global networking enable/disable and connectivity status.<br><b>radio:</b> Control of Wi-Fi and WWAN radios.<br><b>connection:</b> Management of connection profiles (e.g., <i>MyHomeWifi</i>, <i>VPN_Work</i>). This is where you add, modify, delete, activate, or deactivate connections.<br><b>device:</b> Management of network interfaces (e.g., <i>eth0</i>, <i>wlan0</i>). You can display device status, connect/disconnect, or scan for Wi-Fi.<br><b>agent:</b> Allows registering as a NetworkManager secret agent (e.g., for VPN passwords).


title: COMMON USE CASES
content:
<i>nmcli</i> is frequently used for:<br><b>Connecting to Wi-Fi:</b> <br><b>nmcli device wifi connect SSID password "your_password"</b><br><b>Listing Connections:</b> <br><b>nmcli connection show</b><br><b>Bringing a Connection Up/Down:</b> <br><b>nmcli connection up "Connection Name"</b> / <b>nmcli connection down "Connection Name"</b><br><b>Adding a New Ethernet Connection:</b> <br><b>nmcli connection add type ethernet con-name my-eth ifname eth0 ip4 192.168.1.100/24 gw4 192.168.1.1</b><br><b>Displaying Device Status:</b> <br><b>nmcli device status</b>


title: HISTORY
content:
NetworkManager was initiated by Red Hat in 2004 with the goal of making network setup and configuration easier for users, particularly for mobile and wireless networking. It aimed to automatically switch between network connections and manage their states. <br><br>The <i>nmcli</i> utility was developed as a modern, scriptable command-line interface to NetworkManager, providing a robust alternative to legacy network configuration scripts (like those used with <i>ifup/ifdown</i>) and complementing graphical tools. Its development focused on offering full control over NetworkManager's capabilities via the terminal, enabling easier integration into scripts and server automation workflows.


title: PARAMETERS
content:
<b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a login shell. This means it reads the user's startup files (like .profile, .bashrc) as if they were logging in, which might reset some environment variables.<br><br><b><i>group</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the group to switch to. If omitted, it defaults to the user's login group as defined in <i>/etc/passwd</i>.<br><br>


title: DESCRIPTION
content:
<i>newgrp</i> is used to change the current effective group ID of the user. It executes a new shell with the user's new primary group or an additional group specified. This command is typically used to gain access to files that are restricted to members of a particular group.<br><br>Unlike <i>sg</i> (which changes the <b>effective</b> group for a single command), <i>newgrp</i> starts a new login shell environment where the new group becomes the <b>primary</b> group for that session. The user must be a member of the target group. If no group is specified, it defaults to the user's login group. It's important to note that <i>newgrp</i> changes the <b>primary</b> group and creates a new session, so it doesn't affect the parent shell.


title: CAVEATS
content:
<i>newgrp</i> executes a new shell. Changes made in the new shell (like group ID) do <b>not</b> affect the parent shell from which <i>newgrp</i> was invoked.<br>The user must be a member of the target <i>group</i> in <i>/etc/group</i> (or equivalent system database) to successfully switch.<br><i>newgrp</i> changes the <b>primary</b> group of the new session, not just adds it to the list of supplementary groups.<br>Unlike <i>su</i> or <i>sudo</i>, <i>newgrp</i> does <b>not</b> require the user's password, only that the user is a member of the group.


title: ENVIRONMENT
content:
When <i>newgrp</i> starts a new shell, it typically passes the environment variables from the calling shell. However, if the <i>-l</i> option is used, it often resets some environment variables as a login shell would, ensuring a cleaner session environment.


title: GROUP MEMBERSHIP
content:
For a user to successfully use <i>newgrp</i>, they must already be listed as a member of the target group in the system's group database (commonly <i>/etc/group</i>). This command does not grant group membership but rather activates an existing one for the session.


title: HISTORY
content:
<i>newgrp</i> has been a standard Unix/Linux command for a long time, providing a fundamental way for users to switch their primary group identity within a session. Its functionality is crucial for managing permissions and access rights in multi-user environments. It contrasts with <i>su</i> (switch user) and <i>sg</i> (switch group for a single command) by creating a new shell session with a persistent primary group change.


title: PARAMETERS
content:
<b><b>-e, --environment</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a Postman environment JSON file to use for the run.<br><br><b><b>-g, --globals</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a Postman globals JSON file to use for the run.<br><br><b><b>-d, --iteration-data</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a JSON or CSV file containing iteration data for the collection.<br><br><b><b>-n, --iteration-count</b> <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of times to run the collection.<br><br><b><b>-r, --reporters</b> <I>reporter_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify reporter(s) to use (e.g., <i>cli</i>, <i>json</i>, <i>html</i>, <i>junit</i>). Multiple reporters can be comma-separated.<br><br><b><b>--folder</b> <I>folder_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run only a specific folder or folders from the collection. Multiple folders can be comma-separated.<br><br><b><b>--insecure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable SSL certificate validation for HTTPS requests.<br><br><b><b>--delay-request</b> <I>delay_ms</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a delay (in milliseconds) between requests in the collection run.<br><br><b><b>--bail</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop the collection run on the first test failure.<br><br><b><b>--suppress-exit-code</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent Newman from exiting with a non-zero code even if tests fail, useful for CI/CD integration.<br><br>


title: DESCRIPTION
content:
Newman is a powerful and versatile command-line collection runner specifically designed for Postman. It enables developers and testers to execute Postman collections directly from the terminal, making it an indispensable tool for automating API tests and integrating them into Continuous Integration (CI) and Continuous Delivery (CD) workflows. By allowing the execution of comprehensive API test suites without the need for Postman's graphical user interface, Newman streamlines the testing process. It efficiently processes Postman collection JSON files, along with associated environment and global variables, and supports a wide array of reporting formats to output detailed test results, facilitating quick analysis and feedback on API health.


title: CAVEATS
content:
Newman requires Node.js and npm to be installed on the system, as it is a Node.js package and not a native Linux utility. It operates exclusively on Postman collection JSON files, environment files, and data files, meaning it's highly specialized for API testing workflows within the Postman ecosystem. While powerful for automation, it doesn't provide a graphical interface for debugging requests or building collections, relying on the Postman desktop application for those tasks.


title: REPORTERS
content:
Newman supports various built-in and external reporters to output test results in different formats. Common built-in reporters include <i>cli</i> (default console output), <i>json</i>, <i>html</i>, and <i>junit</i>. Custom reporters can also be developed and integrated, providing flexibility in how test outcomes are presented.


title: USAGE WITH CI/CD
content:
Newman's primary strength lies in its seamless integration into CI/CD pipelines. By automating Postman collection runs, Newman allows for immediate and consistent feedback on API health and functionality during development and deployment cycles, ensuring API reliability and performance before reaching production environments.


title: HISTORY
content:
Newman was developed by Postman to extend the functionality of the Postman desktop application into command-line environments. Its introduction significantly facilitated automated API testing and integration into Continuous Integration/Continuous Delivery (CI/CD) pipelines, enabling developers and testers to run Postman collections as part of their build and deployment processes. It has evolved alongside the Postman application, adding support for new features like various reporting formats and improved error handling, becoming an integral part of modern API development workflows.


title: PARAMETERS
content:
<b><b>-d</b> <i>&lt;DIR&gt;</i>, <b>--data-dir</b> <i>&lt;DIR&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory for Newsboat to store its data files, such as cache and database.<br><br><b><b>-c</b> <i>&lt;FILE&gt;</i>, <b>--config-file</b> <i>&lt;FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a different configuration file than the default one, allowing for multiple configurations.<br><br><b><b>-r</b>, <b>--refresh-on-start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically refreshes all configured feeds upon Newsboat's startup, fetching the latest articles.<br><br><b><b>-e</b>, <b>--export-to-opml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports the list of subscribed feeds to standard output in OPML (Outline Processor Markup Language) format.<br><br><b><b>-x</b> <i>&lt;CMD&gt;</i>, <b>--execute</b> <i>&lt;CMD&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specific Newsboat command. This is particularly useful for scripting and automation of tasks.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays Newsboat's version information and then exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a brief help message with available command-line options and then exits.<br><br>


title: DESCRIPTION
content:
Newsboat is a fast and highly configurable text-mode RSS/Atom feed reader for Unix-like operating systems. It enables users to subscribe to various news feeds, browse articles, and manage their subscriptions directly from the command line interface. <br><br>Designed for efficiency and keyboard-only navigation, Newsboat offers features such as tagging, powerful searching, filtering capabilities, and seamless integration with external programs for tasks like opening links in a web browser or downloading enclosures. It serves as a continuation of the popular <I>newsbeuter</I> project, maintaining its core philosophy of being a robust, terminal-centric tool for managing news feeds.


title: CAVEATS
content:
Newsboat is a terminal-based application, which means it requires users to be comfortable with command-line interfaces. Its extensive customization options are primarily managed by editing plain text configuration files, which may present a learning curve for users preferring graphical interfaces. It does not natively display rich media content directly.


title: CUSTOMIZATION VIA CONFIGURATION FILES
content:
Newsboat's behavior, appearance, and key bindings are highly customizable through several plain text files, typically located in <I>~/.newsboat/</I>. Key configuration files include: <br> <I>config</I> (main settings), <br> <I>urls</I> (list of RSS/Atom feed URLs), and <br> <I>keymap</I> (custom keyboard shortcuts and commands).


title: OPML IMPORT/EXPORT
content:
Newsboat provides robust support for importing and exporting feed subscriptions using the OPML (Outline Processor Markup Language) standard. This feature simplifies the process of migrating feed lists to and from other feed readers or for backup purposes.


title: HISTORY
content:
Newsboat is a direct and active fork of <I>newsbeuter</I>, a popular text-mode RSS/Atom feed reader whose development ceased. Newsboat emerged to continue the project's legacy, providing ongoing maintenance, bug fixes, and introducing new features while strictly adhering to the original application's core design and philosophy of a fast, keyboard-driven feed reader. It has effectively become the spiritual and technical successor to <I>newsbeuter</I>.


title: PARAMETERS
content:
<b>-S, --stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads user definitions from standard input instead of a specified file. Each line should contain the data for one user according to the expected format.<br><br>


title: DESCRIPTION
content:
The <b>newusers</b> command is part of the <i>shadow-utils</i> suite, designed for creating multiple user accounts in a batch-processing manner.  Instead of interactively adding one user at a time with tools like <i>useradd</i>, <b>newusers</b> reads user definitions from a specified file or standard input.  Each line in the input file typically represents a new user, with fields like username, password (often encrypted), UID, GID, comment, home directory, and shell, separated by colons.  This utility is particularly useful for system administrators who need to provision many user accounts simultaneously, such as in educational institutions or large enterprise environments.  It automates the process of adding entries to <i>/etc/passwd</i>, <i>/etc/shadow</i>, <i>/etc/group</i>, and <i>/etc/gshadow</i>, as well as creating home directories for new users.


title: CAVEATS
content:
The <b>newusers</b> command requires <i>root privileges</i> to execute successfully.<br>The input file format is crucial; incorrect formatting can lead to errors or unexpected user configurations. Passwords in the input file are typically expected to be already <i>encrypted</i> (e.g., using <i>openssl passwd</i>, <i>mkpasswd</i>, or similar methods) to avoid storing plain-text passwords directly. While powerful for batch operations, it offers less granularity and interactivity than <i>useradd</i> for individual user management.


title: INPUT FILE FORMAT
content:
The <i>USER_DEFINITION_FILE</i> or standard input typically expects each line to contain colon-separated fields representing a user. The common fields, in order, are: <i>username</i>:<i>encrypted_password</i>:<i>UID</i>:<i>GID</i>:<i>comment</i>:<i>home_directory</i>:<i>shell</i>. For example, a line might look like: <i>johndoe:encrypted_hash_here:1001:100:John Doe,,,:/home/johndoe:/bin/bash</i>. The exact number and order of fields, as well as the expected format for fields like the comment, can vary slightly depending on the system's configuration and the specific version of <b>newusers</b>. It is essential to consult your system's man page (e.g., <i>man newusers</i>) for the precise format expected.


title: HISTORY
content:
<b>newusers</b> is a long-standing component of the <i>shadow-utils</i> package, which provides utilities for managing user and group accounts and their respective password files (<i>/etc/passwd</i>, <i>/etc/shadow</i>, <i>/etc/group</i>, <i>/etc/gshadow</i>). Its design emphasizes batch processing, making it a valuable tool in environments requiring bulk account provisioning. While other tools and configuration management systems have emerged, <b>newusers</b> remains a direct and efficient way to create multiple accounts from a structured data source.


title: SEE ALSO
content:
useradd(8), groupadd(8), usermod(8), userdel(8), passwd(1), group(5), passwd(5), shadow(5), pwconv(8), grpconv(8)


title: SYNOPSIS
content:
<I>next</I> [<B>-f</B> <I>file</I>] [<B>-d</B> <I>directory</I>] [<B>-s</B> <I>state_file</I>] [<B>-r</B>] [<B>-c</B>] [<B>-n</B> <I>N</I>] [<B>-l</B>] [<B>-h</B>] [<B>-v</B>]


title: PARAMETERS
content:
<b><b>-f</b> <I>file</I>, <b>--file</b>=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an input <I>file</I> whose lines will be used as the sequence of items to iterate through. Each line is considered a distinct item.<br><br><b><b>-d</b> <I>directory</I>, <b>--directory</b>=<I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Iterates through the files within the specified <I>directory</I> (lexicographically by default). Useful for processing a batch of files one by one.<br><br><b><b>-s</b> <I>state_file</I>, <b>--state</b>=<I>state_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages the command's persistent state (e.g., the last processed item or index) in the specified <I>state_file</I>. If not provided, state is managed in a temporary file or is session-dependent.<br><br><b><b>-r</b>, <b>--reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the internal counter or state, causing the next invocation to output the first item in the sequence.<br><br><b><b>-c</b>, <b>--current</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the current item without advancing the internal state. Useful for re-processing or verifying the current position.<br><br><b><b>-n</b> <I>N</I>, <b>--advance</b>=<I>N</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Advances the state by <I>N</I> items without outputting them. If <I>N</I> is 0, it behaves like <B>--current</B>.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all items in the configured sequence without advancing the state or outputting a single 'next' item.<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;Outputs version information and exits.<br><br>


title: DESCRIPTION
content:
The <I>next</I> command provides a simple yet powerful mechanism for iterating through a predefined sequence of items, such as lines in a file, files in a directory, or custom lists. It is designed to maintain state across invocations, allowing users and scripts to easily retrieve the "next" item in a series without complex manual tracking.<br><br>When invoked, <I>next</I> reads from a specified input source (e.g., a file, standard input, or a list defined in a state file), identifies the item immediately following the last one processed (or the first if starting fresh), and outputs it to standard output. It then updates its internal state to mark the newly outputted item as the "current" one. This makes <I>next</I> ideal for automating sequential tasks, processing large datasets incrementally, or managing a queue of jobs where each invocation handles the subsequent task. Its ability to persist progress makes it robust against interruptions.


title: CAVEATS
content:
When using a shared <I>state_file</I> across multiple processes or scripts, consider potential race conditions. It is recommended to implement external locking mechanisms if concurrent access is critical.<br><br>The behavior when reaching the end of the sequence depends on the implementation; typically, <I>next</I> might exit with a non-zero status, or output nothing further.


title: RETURN CODES
content:
<I>next</I> typically returns 0 on success, 1 if no more items are available in the sequence, and 2 for general errors (e.g., file not found, invalid options).


title: CONFIGURATION
content:
By default, <I>next</I> may look for a default state file in <I>~/.next_state</I> or a temporary directory. This behavior can be overridden by the <B>-s</B> option.


title: INPUT PRIORITIZATION
content:
If both <B>-f</B> and <B>-d</B> are specified, <B>-f</B> (file input) usually takes precedence. If neither is specified, <I>next</I> might read from standard input, treating each line as an item until EOF.


title: HISTORY
content:
The concept of <I>next</I> emerged from the need for simpler iteration management in shell scripting, particularly in environments where complex loops with manual index tracking became cumbersome. It was first proposed as a core utility to abstract the "what's next?" logic, especially for long-running batch processes or task queues that might be paused and resumed. Early implementations focused on file line processing, later expanding to directory contents and arbitrary lists with persistent state, providing a robust solution for sequential job execution.


title: SYNOPSIS
content:
<b>nextclade</b> <i>&lt;command&gt;</i> [<i>&lt;options&gt;</i>]<br><br>Common commands:<br><b>nextclade run</b> [<i>&lt;options&gt;</i>] <i>&lt;input_sequences.fasta&gt;</i><br><b>nextclade dataset get</b> [<i>&lt;options&gt;</i>] <i>&lt;dataset_name&gt;</i><br><b>nextclade --help</b><br><b>nextclade</b> <i>&lt;command&gt;</i> <b>--help</b>


title: PARAMETERS
content:
<b><b>--input-fasta</b> <i>&lt;path&gt;</i> or <b>-i</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input FASTA file containing sequences to be analyzed by <i>nextclade run</i>.<br><br><b><b>--input-dataset</b> <i>&lt;path&gt;</i> or <b>-d</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a local <i>Nextclade</i> dataset directory or a dataset name (e.g., <i>sars-cov-2</i>) to be used for analysis.<br><br><b><b>--output-json</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output JSON file containing detailed analysis results for each sequence.<br><br><b><b>--output-tsv</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output TSV file (tab-separated values) with tabular results.<br><br><b><b>--output-csv</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output CSV file (comma-separated values) with tabular results.<br><br><b><b>--output-fasta</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output FASTA file containing aligned sequences after processing.<br><br><b><b>--output-tree</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output Newick tree file, if tree building or placement is part of the dataset's configuration.<br><br><b><b>--output-dir</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory where all generated output files will be saved.<br><br><b><b>--jobs</b> <i>&lt;number&gt;</i> or <b>-j</b> <i>&lt;number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of parallel jobs (CPU cores) to utilize for processing, speeding up analysis for large inputs.<br><br><b><b>--verbose</b> or <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed progress information during execution.<br><br><b><b>--dataset-name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <i>nextclade dataset get</i>) Specifies the name of the dataset to download (e.g., <i>sars-cov-2</i>, <i>flu</i>).<br><br><b><b>--dataset-tag</b> <i>&lt;tag&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For <i>nextclade dataset get</i>) Specifies a particular version tag for the dataset to download, allowing for reproducible analysis.<br><br>


title: DESCRIPTION
content:
<i>nextclade</i> is a bioinformatics tool designed for rapid, robust, and reproducible analysis of viral genome sequences. Developed as part of the <i>Nextstrain</i> project, it performs tasks such as phylogenetic placement, clade assignment, mutation calling, and quality control on input sequences.<br><br>It aligns sequences against a user-specified reference dataset (which includes a reference sequence, gene map, phylogenetic tree, and quality control configuration) and outputs detailed reports on mutations, amino acid changes, deletions, insertions, and potential quality issues. This tool is crucial for tracking the evolution and spread of rapidly evolving pathogens, providing insights for public health surveillance and research.


title: CAVEATS
content:
Requires a compatible dataset: <i>nextclade</i> heavily relies on pre-built datasets (reference sequence, gene map, phylogenetic tree, QC parameters). These must be obtained (e.g., via <b>nextclade dataset get</b>) and specifically match the target pathogen for accurate analysis.<br><br>Performance: Can be memory and CPU intensive for very large input files or complex datasets, although it supports parallel processing with the <b>--jobs</b> option.<br><br>Data Specificity: Primarily designed and optimized for viral sequences due to its integration with specific datasets and reference-based analysis, and less suitable for bacterial or eukaryotic genomes without custom dataset preparation.


title: DATASET STRUCTURE
content:
<i>nextclade</i> datasets are critical for its operation. They package a reference sequence, gene annotations, a phylogenetic tree, quality control rules, and primerset definitions, enabling specialized analysis for specific pathogens. Users often download these using the <b>nextclade dataset get</b> command.


title: OUTPUT FORMATS
content:
The tool produces a variety of output formats, including detailed JSON reports (ideal for programmatic access), TSV/CSV for spreadsheet analysis, and FASTA for aligned sequences, facilitating integration into diverse bioinformatics workflows.


title: HISTORY
content:
<i>nextclade</i> emerged from the <i>Nextstrain</i> project, an open-source initiative providing real-time tracking of pathogen evolution. It was developed to streamline the process of assigning viral sequences to clades, identifying mutations, and performing quality control, complementing the broader phylogenetic analysis capabilities of <i>Nextstrain</i>. Its development has been driven by the need for rapid and consistent genomic surveillance, particularly evident during public health crises like the COVID-19 pandemic.


title: SYNOPSIS
content:
<b>nextcloudcmd</b> <i>[OPTIONS]</i> <i><local_path></i> <i><remote_url></i><br><br><i>Note:</i> <i><local_path></i> is the path to the local directory or file to synchronize.<br><i>Note:</i> <i><remote_url></i> is the URL of the Nextcloud server and the target path within it, e.g., <code>https://your-nextcloud.com/remote.php/webdav/path/to/folder</code>.


title: PARAMETERS
content:
<b><b>-u</b>, <b>--user</b> <i><username></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the username for authentication with the Nextcloud server.<br><br><b><b>-p</b>, <b>--password</b> <i><password></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for the specified user. <i>(Warning: Using this directly in scripts is insecure. Consider environment variables or config files.)</i><br><br><b><b>-n</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run, simulating the synchronization process without making actual changes. Useful for testing.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>nextcloudcmd</i> client.<br><br><b><b>-s</b>, <b>--skip-existing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips synchronization for files that already exist on the server.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces overwriting of existing files on the server with local versions.<br><br><b><b>-d</b>, <b>--delete</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes local files that have been removed on the Nextcloud server.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages during synchronization.<br><br><b><b>-c</b>, <b>--config</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use.<br><br><b><b>--exclude</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files or directories matching the given pattern from synchronization. Can be used multiple times.<br><br><b><b>--include</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes files or directories matching the given pattern, overriding <i>--exclude</i>. Can be used multiple times.<br><br><b><b>--non-interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables interactive prompts, making the command suitable for automated scripts.<br><br><b><b>--trust</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Trusts all SSL certificates without validation. <i>(Warning: Highly insecure and should be avoided in production environments.)</i><br><br><b><b>--exclude-file</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads exclusion patterns from the specified file, one pattern per line.<br><br><b><b>--cacert</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a custom CA certificate bundle for SSL/TLS validation.<br><br>


title: DESCRIPTION
content:
<i>nextcloudcmd</i> is a robust command-line interface tool designed for synchronizing local files and directories with a Nextcloud server.<br><br>As an integral component of the Nextcloud Desktop Client suite, it provides a powerful, non-graphical alternative for users and administrators to manage their Nextcloud data. This utility is especially valuable for automation tasks, such as scripting routine backups, deploying files to multiple servers, or performing synchronization on environments without a graphical user interface, like headless servers or CI/CD pipelines.<br><br>It offers comprehensive control over the synchronization process, supporting diverse authentication methods and featuring options for simulating operations (dry-runs), enforcing file overwrites, specifying inclusion and exclusion patterns for precise control over what gets synced, and enabling non-interactive execution for automated workflows. Its flexibility makes it a key tool for integrating Nextcloud into server-side operations and custom scripts.


title: CAVEATS
content:
<b>Security Warning:</b> Providing passwords directly via the <code>-p</code> option is insecure. Consider using environment variables, configuration files, or interactive prompts where possible.<br><br><b>SSL/TLS Validation:</b> The <code>--trust</code> option disables crucial security checks and should never be used in production environments. Always prefer proper SSL certificate validation using <code>--cacert</code> or system trust stores.<br><br><b>Performance:</b> For very large datasets, the command-line client might be less performant or feature-rich compared to the graphical desktop client which maintains a local database of synced files.


title: ENVIRONMENT VARIABLES
content:
The command can utilize environment variables for sensitive information like passwords, e.g., <code>NEXTCLOUD_PASSWORD</code>, to avoid exposing them in command history or process listings.


title: EXIT CODES
content:
<i>nextcloudcmd</i> typically returns an exit code of <code>0</code> on successful synchronization and a non-zero value for errors, which is useful for scripting and error handling.


title: WEBDAV URL STRUCTURE
content:
The <i><remote_url></i> typically follows the format: <code>https://your-nextcloud.com/remote.php/webdav/</code> followed by the desired path within your Nextcloud instance. Ensure the path is correct for successful synchronization.


title: HISTORY
content:
<i>nextcloudcmd</i> is an integral part of the Nextcloud Desktop Client, which originated from the ownCloud Desktop Client. As ownCloud forked into Nextcloud, the client application and its command-line component evolved alongside the Nextcloud server, providing consistent and reliable file synchronization capabilities for users and administrators. Its development focuses on extending the desktop client's features to non-GUI environments, ensuring broad utility across different computing setups.


title: SYNOPSIS
content:
<pre><b>nextflow</b> <I>&lt;command&gt;</I> [<I>&lt;options&gt;</I>] [<I>&lt;arguments&gt;</I>]<br><b>nextflow run</b> <I>&lt;pipeline&gt;</I> [<I>&lt;options&gt;</I>] [<I>&lt;params&gt;</I>]</pre>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the command or global options.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the Nextflow version number.<br><br><b><b>-C</b> <I>&lt;file&gt;</I>, <b>--config</b> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads an additional configuration file for the pipeline execution.<br><br><b><b>-bg</b>, <b>--background</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the Nextflow pipeline execution in the background.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages, showing only warnings or errors.<br><br><b><b>-ansi</b> <I>&lt;mode&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables ANSI console output colors (e.g., 'true', 'false', 'auto').<br><br><b><b>-r</b> <I>&lt;revision&gt;</I>, <b>--revision</b> <I>&lt;revision&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the pipeline version to execute (e.g., Git branch, tag, or commit ID).<br><br><b><b>-profile</b> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more configuration profiles to apply (e.g., 'docker', 'conda', 'slurm').<br><br><b><b>-params-file</b> <I>&lt;file&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads pipeline parameters from a YAML or JSON file.<br><br><b><b>-entry</b> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the entry point (workflow) to execute within the pipeline.<br><br><b><b>-resume</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resumes a previous pipeline execution from the last successful checkpoint.<br><br><b><b>-w</b> <I>&lt;dir&gt;</I>, <b>--work-dir</b> <I>&lt;dir&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the pipeline's work directory where intermediate files are stored.<br><br><b><b>-name</b> <I>&lt;name&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a custom name to the pipeline execution, useful for tracking.<br><br><b><b>-latest</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the download of the latest revision of the pipeline from a repository.<br><br><b><b>-offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables internet access for pipeline execution (e.g., no Git fetch or container pull).<br><br><b><b>-stub</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates empty stub output files for processes, useful for testing pipeline logic.<br><br><b><b>-with-docker</b> <I>&lt;image&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes processes using the specified Docker image for containerization.<br><br><b><b>-with-singularity</b> <I>&lt;image&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes processes using the specified Singularity image for containerization.<br><br><b><b>-with-conda</b> <I>&lt;env&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Conda environment management for process dependencies.<br><br><b><b>-with-tower</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables monitoring and logging of the pipeline execution with Nextflow Tower.<br><br><b><b>--container-engine</b> <I>&lt;engine&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the container engine to use (e.g., 'docker', 'singularity', 'podman').<br><br>


title: DESCRIPTION
content:
Nextflow is an open-source workflow management system designed for building and deploying complex computational pipelines. It excels at handling large-scale data processing in a reproducible and portable manner across various computing environments. Built on the reactive programming paradigm, Nextflow simplifies the development of parallel and distributed processes. It manages dependencies, tracks outputs, and automatically retries failed tasks, ensuring robust execution. A core feature is its ability to seamlessly integrate with container technologies like Docker and Singularity, and resource managers such as Slurm, SGE, Kubernetes, and AWS Batch, enabling pipelines to run consistently from a local machine to a high-performance computing cluster or cloud environment. It's widely adopted in bioinformatics for its efficiency and reproducibility.


title: CAVEATS
content:
While powerful, Nextflow has a learning curve, especially when writing complex pipelines or debugging issues related to executor and container environments. Resource management and optimization can require significant effort to get optimal performance on diverse infrastructures. The DSL2 (Domain Specific Language 2) for pipeline definition, while expressive, requires familiarity with Groovy-like syntax and concepts.


title: NEXTFLOW DSL2 AND MODULES
content:
Nextflow pipelines are defined using a Groovy-based Domain Specific Language (DSL). DSL2, introduced in Nextflow version 20.07.0, revolutionized pipeline development by enabling the creation of modular components (processes and workflows) that can be easily shared, reused, and composed into larger pipelines. This greatly enhances pipeline organization, maintainability, and collaboration.


title: CONFIGURATION FILES
content:
Nextflow uses a powerful configuration system, primarily via <I>.config</I> files. These files allow users to define various settings like executor types, container images, resource requests (CPU, memory), and custom parameters. Configurations can be layered, with system-wide, project-specific, and user-specific settings overriding each other, providing immense flexibility for different execution environments.


title: CHANNELS
content:
The core mechanism for data flow in Nextflow is the "channel." Channels are asynchronous queues that connect processes, allowing them to exchange data without direct file system interaction. This reactive data-flow model is fundamental to Nextflow's ability to parallelize tasks efficiently and manage dependencies.


title: HISTORY
content:
Nextflow was initially developed by Paolo Di Tommaso at the Centre for Genomic Regulation (CRG) in Barcelona, Spain, and publicly released in 2013. It emerged from the need for a more robust and reproducible way to manage complex data analysis pipelines in genomics. Its key innovation was the adoption of a reactive, data-flow programming model, inspired by functional programming, which made pipeline parallelization and error handling more intuitive. The introduction of DSL2 in recent years significantly improved pipeline modularity and reusability, further solidifying its position as a leading tool in scientific computing, particularly in bioinformatics and life sciences.


title: SYNOPSIS
content:
<i><b>nf-core</b></i> <command> [options] [arguments]<br><br>Common Usage Examples:<br><i><b>nf-core</b></i> list<br><i><b>nf-core</b></i> download <pipeline> [version]<br><i><b>nf-core</b></i> create pipeline<br><i><b>nf-core</b></i> launch <pipeline_dir> --id <session_id>


title: PARAMETERS
content:
<b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available <i><b>nf-core</b></i> pipelines and modules, with optional filters for keywords or specific versions.<br><br><b>download</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads a specified <i><b>nf-core</b></i> pipeline or module version to a local directory, preparing it for execution.<br><br><b>create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new pipeline, module, or subworkflow project from the official <i><b>nf-core</b></i> template, facilitating rapid development.<br><br><b>launch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively guides the user through pipeline parameter input, then generates and optionally executes the Nextflow command.<br><br><b>lint</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks a local pipeline directory against the extensive <i><b>nf-core</b></i> best practice guidelines, identifying deviations and suggesting fixes.<br><br><b>modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages <i><b>nf-core</b></i> DSL2 modules, allowing users to pull, create, update, and lint individual modular components.<br><br><b>subworkflows</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages <i><b>nf-core</b></i> DSL2 subworkflows, providing similar functionality to modules for larger, reusable workflow blocks.<br><br><b>sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes a local pipeline with the latest changes from the official <i><b>nf-core</b></i> template, applying updates while preserving local modifications.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates a downloaded <i><b>nf-core</b></i> pipeline to its latest official release, ensuring users benefit from the most recent features and bug fixes.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed version of the <i><b>nf-core</b></i> command-line tool.<br><br>


title: DESCRIPTION
content:
<i><b>nf-core</b></i> is a community-driven initiative that provides a collection of standardized, high-quality, and reproducible Nextflow pipelines for bioinformatics. The <i><b>nf-core</b></i> command-line tool serves as the primary interface for interacting with this ecosystem. It significantly simplifies the process of finding, downloading, validating, and launching these complex pipelines.<br><br>Users leverage <i><b>nf-core</b></i> to ensure their bioinformatics analyses adhere to community best practices, fostering easier collaboration and consistent results. The tool also streamlines pipeline development, offering features for creating new pipelines, modules, and subworkflows from templates, alongside robust linting capabilities to enforce adherence to the <i><b>nf-core</b></i> guidelines. This standardization greatly enhances pipeline maintainability, scalability, and reusability across diverse computational environments.


title: CAVEATS
content:
Running <i><b>nf-core</b></i> pipelines requires a separate installation of <i><b>Nextflow</b></i>. While <i><b>nf-core</b></i> streamlines setup, actual pipeline execution can still be computationally intensive and may require careful configuration for specific high-performance computing (HPC) environments or cloud platforms. The full benefits of <i><b>nf-core</b></i>'s linting and syncing features are primarily for pipelines developed adhering to the <i><b>nf-core</b></i> guidelines.


title: COMMUNITY AND SUPPORT
content:
<i><b>nf-core</b></i> boasts an active Slack community and extensive, well-maintained documentation, offering comprehensive support for both users and developers alike.


title: REPRODUCIBILITY
content:
All <i><b>nf-core</b></i> pipelines are rigorously tested and leverage containerization technologies (Docker/Singularity) to ensure consistent and reproducible results across diverse computational environments.


title: MODULARITY (DSL2)
content:
Leveraging <i><b>Nextflow</b></i>'s DSL2, <i><b>nf-core</b></i> pipelines are built from highly modular components (modules and subworkflows), which simplifies pipeline construction, maintenance, and reuse.


title: HISTORY
content:
The <i><b>nf-core</b></i> project was initiated in 2018 by Phil Ewels and others, born from a growing need for standardized, high-quality, and reproducible bioinformatics pipelines using <i><b>Nextflow</b></i>. It rapidly evolved into a thriving open-source community, providing not just pipelines but also the <i><b>nf-core</b></i> command-line interface tool to facilitate their management. The project's development has closely mirrored advancements in <i><b>Nextflow</b></i>, particularly the adoption of DSL2, which significantly enhanced pipeline modularity and maintainability.


title: SYNOPSIS
content:
The functionality represented by <i>nfnl_osf</i> is typically invoked indirectly through Netfilter firewall utilities, not as a direct command.<br><br><b><i>iptables</i> usage:</b><br><b>iptables</b> -A <i>&lt;chain&gt;</i> -m osf [--genre <i>&lt;name&gt;</i>[,<i>&lt;name&gt;</i>...]] [--log <i>&lt;prefix&gt;</i>] [--ttl <i>&lt;value&gt;</i>] [--fuzzy] -j <i>&lt;target&gt;</i><br><br><b><i>nftables</i> usage:</b><br><b>nft</b> add rule <i>&lt;table_family&gt;</i> <i>&lt;chain&gt;</i> osf genre <i>&lt;name&gt;</i> [log <i>&lt;prefix&gt;</i>] <i>&lt;action&gt;</i>


title: PARAMETERS
content:
<b><b>`--genre <I>name</I>[,<I>name</I>...]`</b> (<i>iptables</i>) / <b>`genre <I>name</I>`</b> (<i>nftables</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches packets whose operating system fingerprint belongs to the specified genre(s). Genres are usually broader categories like "Linux", "Windows", "FreeBSD", "Cisco", etc. For <i>iptables</i>, multiple genres can be specified separated by commas. A special genre `*` can be used to match any identified OS.<br><br><b><b>`--log <I>prefix</I>`</b> (<i>iptables</i>) / <b>`log <I>prefix</I>`</b> (<i>nftables</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the kernel to log matching packets to the kernel log, prepending the specified `prefix` to the log message. This is useful for debugging or monitoring detected OS types.<br><br><b><b>`--ttl <I>value</I>`</b> (<i>iptables</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches packets with an initial Time-To-Live (TTL) value that falls within a certain range or exactly matches the specified value. This option helps refine the fingerprint match by considering the packet's initial hop count, which can sometimes be indicative of the OS.<br><br><b><b>`--fuzzy`</b> (<i>iptables</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables fuzzy matching. This option allows the module to match packets even if an exact fingerprint is not found, by considering approximate similarities to known fingerprints. This can be useful for detecting variants or less common OS builds where an exact match might not exist in the database.<br><br>


title: DESCRIPTION
content:
<i>nfnl_osf</i> refers to the Netfilter OS Fingerprinting (OSF) module, a core component within the Linux kernel's networking stack. It is not a standalone user-space command but rather a kernel-level mechanism that provides capabilities for passively detecting the operating system of a remote host based on its TCP/IP packet characteristics.<br><br>This functionality is primarily exposed and utilized through advanced firewall tools like <i>iptables</i> and <i>nftables</i>, where it's accessed via the <i>osf</i> match extension. The module meticulously inspects attributes such as TCP options (e.g., Window Scale, SACK, Timestamps), initial TCP window sizes, IP ID field behavior, and Time-To-Live (TTL) values from incoming packets, particularly during the TCP handshake (SYN and SYN-ACK packets).<br><br>By comparing these collected signatures against a pre-compiled database of known OS fingerprints (typically located at <i>/etc/iproute2/nfnl_osf.db</i>), <i>nfnl_osf</i> can infer the operating system. This enables network administrators to implement highly granular firewall rules, such as blocking traffic from specific OS types, prioritizing traffic from trusted systems, or identifying unexpected network behavior based on mismatched OS signatures, thereby enhancing network security and control.


title: CAVEATS
content:
<i>nfnl_osf</i> is a kernel module, not a standalone user-space command. Its functionality is integrated into firewall tools like <i>iptables</i> and <i>nftables</i> via the <i>osf</i> match extension.<br><br>OS fingerprinting is not foolproof; advanced users or malicious actors can spoof TCP/IP stack characteristics to evade detection or impersonate other operating systems.<br><br>The accuracy of fingerprinting heavily relies on an up-to-date and comprehensive fingerprint database. An outdated database may lead to misidentification or failure to identify newer OS versions.<br><br>Deep packet inspection for OS fingerprinting can introduce a minor performance overhead, particularly on high-traffic interfaces, though it's generally optimized for efficiency within the kernel.


title: DATABASE LOCATION
content:
The <i>nfnl_osf</i> module relies on a database of known OS fingerprints for its operations. On most Linux distributions, this database is typically found at <i>/etc/iproute2/nfnl_osf.db</i>. This text-based file contains definitions for various operating systems and their unique TCP/IP stack signatures. Users can update or customize this file to add new fingerprints or modify existing ones.


title: HOW IT WORKS
content:
The core mechanism of <i>nfnl_osf</i> involves analyzing the initial packets of a TCP connection, primarily the SYN and SYN-ACK packets. It extracts specific features such as the order and presence of TCP options (e.g., Window Scale, SACK Permitted, Timestamps, NOPs), the initial TCP window size, the behavior of the IP ID field (e.g., sequential, random), and the initial Time-To-Live (TTL) value. These attributes collectively form a unique 'fingerprint' which is then compared against the patterns stored in its database to identify the sending operating system.


title: HISTORY
content:
The concept of passive OS fingerprinting predates <i>nfnl_osf</i>, with user-space tools like <i>p0f</i> being early pioneers in this field. The integration of OS fingerprinting into the Linux kernel via Netfilter was a significant step, providing a high-performance, kernel-level solution for traffic classification. The <i>osf</i> match module was introduced to <i>iptables</i> to directly leverage this kernel capability within firewall rules.<br><br>As the Netfilter project evolved and <i>nftables</i> emerged as the modern successor to <i>iptables</i>, the <i>osf</i> functionality was ported and made available within the <i>nftables</i> framework, albeit with syntax adaptations. The development of <i>nfnl_osf</i> is closely tied to the continuous enhancement of the Linux networking stack and the Netfilter project's efforts to provide robust and intelligent packet filtering capabilities.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports statistics for all RPC calls. By default, only read and write calls are reported.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports NFS RPC calls (operations per second and average latency) in addition to traditional throughput and latency statistics.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays statistics in kilobytes per second instead of blocks per second.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays statistics about all mounted NFS filesystems. This is often the default behavior or implied when no specific mount point is given.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty-prints the output, often showing a more human-readable and organized format.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports RPC statistics, specifically operations per second and average latency for each NFS RPC call.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a timestamp with each report generated.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for the <b>nfsiostat</b> command.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message, summarizing command usage and options.<br><br><b>interval</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the time in seconds between each report. If specified without <i>count</i>, <b>nfsiostat</b> reports continuously.<br><br><b>count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of reports to generate. This option is only valid when an <i>interval</i> is also specified.<br><br>


title: DESCRIPTION
content:
<b>nfsiostat</b> is a powerful command-line utility for monitoring Network File System (NFS) client-side I/O performance. It's part of the <i>sysstat</i> package and provides detailed statistics on NFS operations, throughput, and latency for mounted NFS filesystems.<br><br>This tool helps system administrators identify and troubleshoot performance bottlenecks on Linux systems that heavily rely on NFS mounts. It can report a snapshot of current activity or continuously monitor NFS I/O over specified intervals, showing metrics like operations per second, kilobytes transferred per second, and average latency for various NFS RPC calls (e.g., read, write, getattr, open). By analyzing <b>nfsiostat</b> output, users can gain insights into their NFS client's behavior and optimize their storage infrastructure.


title: CAVEATS
content:
<b>nfsiostat</b> relies on kernel-provided statistics, typically accessed via `/proc/net/rpc/nfs` or `/proc/self/mountstats`. <br> The availability and granularity of these statistics can vary across different Linux kernel versions. <br> Elevated privileges (root) may be required to access some of these kernel statistics comprehensively. <br> It exclusively reports client-side NFS statistics; for server-side NFS performance metrics, other tools like <b>nfsstat</b> are typically used.


title: OUTPUT INTERPRETATION
content:
The output of <b>nfsiostat</b> typically includes columns such as:<br><i>Mount Point</i>: The path where the NFS filesystem is mounted.<br><i>ops/s</i>: Total NFS operations per second.<br><i>kB_read/s</i> and <i>kB_wrtn/s</i>: Kilobytes read from and written to the NFS mount per second.<br><i>avg_rq_sz</i>: Average request size in kilobytes.<br><i>avg_rd_lat</i>, <i>avg_wr_lat</i>: Average read and write latency in milliseconds.<br><br>When `-r` or `-a` options are used, it also displays detailed statistics for individual NFS RPC calls (e.g., <i>getattr</i>, <i>lookup</i>, <i>open</i>, <i>read</i>, <i>write</i>), showing their operations per second and average latency.


title: COMMON USAGE EXAMPLES
content:
To get a single report for all mounted NFS filesystems:<br><code>nfsiostat -m</code><br><br>To monitor NFS I/O every 2 seconds, for 5 reports:<br><code>nfsiostat 2 5</code><br><br>To get detailed RPC call statistics and latencies every 3 seconds continuously:<br><code>nfsiostat -rd 3</code>


title: HISTORY
content:
<b>nfsiostat</b> is an integral part of the <i>sysstat</i> package, a well-established suite of performance monitoring tools for Linux systems. The <i>sysstat</i> project, maintained by Sebastien Godard, has a long history of providing robust system performance insights.<br><br><b>nfsiostat</b> specifically evolved to leverage the growing NFS client-side statistics exported by the Linux kernel, enabling more granular monitoring of distributed file system performance over time. Its development has mirrored improvements in kernel-level NFS statistics reporting.


title: SYNOPSIS
content:
`nft [options] command [arguments...]`<br><br>Common commands:<br><I>nft list [family] {tables | table <name> [chain <name>] | chains | rulesets}</I><br><I>nft add [family] {table | chain | rule} ...</I><br><I>nft delete [family] {table | chain | rule} ...</I><br><I>nft flush [family] {tables | table <name> | chain <name>}</I><br><I>nft monitor [subsystem]</I><br><I>nft -f <filename> [--check]</I><br><I>nft help [command]</I><br><I>nft version</I>


title: PARAMETERS
content:
<b>-f, --file <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads and executes commands from the specified file.<br><br><b>-c, --check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the syntax of commands in the file without applying them. Often used with <I>-f</I>.<br><br><b>-a, --atomic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures all changes are applied as a single, atomic transaction.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the `nft` version information.<br><br><b>-s, --stats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows packet and byte counters for rules.<br><br><b>-t, --trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Traces packets matching specific rules, providing detailed debug information.<br><br><b>-e, --echo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Echos the rule back as it is parsed, useful for debugging.<br><br><b>-D, --debug <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for `nft` internal operations.<br><br><b>-I, --include <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a directory to the include path for file imports.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists existing tables, chains, and rules.<br><br><b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds new tables, chains, or rules to the nftables configuration.<br><br><b>delete</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes specified tables, chains, or rules.<br><br><b>flush</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flushes (deletes all contents from) a table or chain.<br><br><b>monitor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors nftables events as they occur in real-time.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides help on `nft` commands and options.<br><br>


title: DESCRIPTION
content:
`nft` is the command-line utility for <I>nftables</I>, a modern packet filtering framework provided by the Linux kernel's <I>Netfilter</I> project.<br><br>It is designed to replace the legacy <I>iptables</I>, <I>ip6tables</I>, <I>arptables</I>, and <I>ebtables</I> tools with a single, unified syntax. <I>nftables</I> offers several advantages, including a simpler, more expressive rule language, atomic rule set updates, enhanced performance due to its bytecode-based engine, and support for complex data structures like sets and maps directly within the kernel.<br><br>Users can define tables, chains, and rules to filter, modify, and route network packets based on various criteria, such as source/destination IP addresses, ports, protocols, and interface names. `nft` allows for both interactive command-line operations and script-based configuration via input files.


title: CAVEATS
content:
`nft` operates on the live kernel firewall configuration and requires root privileges for most operations.<br><br>Incorrect or poorly constructed rules can immediately disconnect your system from the network, making it inaccessible. Always test changes carefully, especially in remote environments, and consider using <I>nft -f <file> --check</I> before applying complex scripts. Atomic operations (<I>--atomic</I>) help prevent partial rule sets from being installed if an error occurs.


title: <I>RULE LANGUAGE SYNTAX</I>
content:
`nftables` utilizes a powerful, expressive rule language. Rules are composed of expressions and statements, allowing for complex matching and action definitions. It supports various data types, sets, and maps, making it highly flexible for diverse firewall requirements.<br><br>Examples: `add rule filter input ip saddr 192.168.1.1 drop`, `add rule filter output tcp dport { 80, 443 } accept`.


title: <I>TABLES AND CHAINS</I>
content:
Rules are organized within chains, which are themselves contained within tables. Tables are isolated containers for sets of chains and rules, typically categorized by address family (e.g., <I>ip</I>, <I>ip6</I>, <I>inet</I>, <I>bridge</I>) and purpose (e.g., <I>filter</I>, <I>nat</I>, <I>route</I>).<br><br>Chains can be base chains (attached to Netfilter hooks) or regular chains (jump targets).


title: <I>ATOMIC OPERATIONS</I>
content:
A key feature of `nftables` is its support for atomic rule set updates. This means an entire set of changes is either applied completely or rolled back entirely if any error occurs. This prevents a broken or incomplete firewall configuration from being active, improving system stability and security.


title: HISTORY
content:
`nftables` and its associated `nft` command were developed as the successor to the aging <I>x_tables</I> framework (used by <I>iptables</I>, <I>ip6tables</I>, etc.). The project aimed to address limitations of the older tools, such as scattered utilities for different protocols and a less flexible rule language.<br><br>Development began in 2008, with the first stable release in 2014. Many modern Linux distributions now use `nftables` as their default firewall backend, although <I>iptables</I> compatibility layers often exist to ease migration.


title: SYNOPSIS
content:
<b>ng</b> &lt;command&gt; [options]<br><b>ng</b> &lt;collection&gt;:&lt;schematic&gt; [options]<br><br>Examples:<br><I>ng new my-app</I><br><I>ng serve --open</I><br><I>ng generate component user-profile</I><br><I>ng build --prod</I>


title: PARAMETERS
content:
<b>new</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Angular workspace and application with a specified project name.<br><br><b>generate (or g)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates and/or modifies files based on an Angular schematic (e.g., component, service, module).<br><br><b>serve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds and serves the application, rebuilding on file changes, typically for development.<br><br><b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compiles an Angular application into an output directory for deployment.<br><br><b>test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs unit tests configured for the project.<br><br><b>e2e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs end-to-end tests for the application.<br><br><b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds support for an external library to your project.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates your application and its dependencies, including the Angular framework itself.<br><br><b>deploy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes a builder to deploy your application to a specified target.<br><br><b>lint</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs linting tools on your application code to enforce coding standards.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manipulates Angular configuration values within the workspace or project.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the Angular CLI version and relevant details like Node.js and OS versions.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help for a given command or the top-level commands.<br><br>


title: DESCRIPTION
content:
The <b>ng</b> command is the fundamental interface for the <I>Angular CLI</I> (Command Line Interface), a powerful tool for developing <I>Angular</I> applications. While <b>ng</b> runs on Linux, it is crucial to understand that it is not a native Linux utility but a Node.js application installed via <I>npm</I> (Node Package Manager). Its primary purpose is to streamline the development workflow by automating common tasks, from project creation to deployment. Developers use <b>ng</b> to scaffold new projects, generate application components, services, and modules, run development servers, build applications for production, execute tests, and manage project dependencies and configurations. It enforces best practices and ensures consistency across Angular projects, significantly enhancing developer productivity and efficiency within the <I>Angular</I> ecosystem.


title: CAVEATS
content:
<b>ng</b> is not a pre-installed or native Linux command; it requires Node.js and <I>npm</I> to be installed globally on your system. Its functionality is entirely dependent on the Angular ecosystem, making it distinct from traditional shell commands. Each subcommand of <b>ng</b> has its own extensive set of options, which can be explored using <I>ng &lt;command&gt; --help</I>.


title: CONTEXT
content:
The command 'ng' primarily refers to the <B>Angular CLI</B> (Command Line Interface), a powerful set of tools used for developing and managing applications built with the Angular framework. It is not a standard, pre-installed Linux operating system command but rather a JavaScript application executed via Node.js.


title: SUBCOMMAND STRUCTURE
content:
The <b>ng</b> command typically operates using a subcommand structure (e.g., <I>ng &lt;command&gt;</I>). Many commands also have aliases (e.g., <I>ng generate</I> can be shortened to <I>ng g</I>). Options are then appended to the subcommand, allowing for fine-grained control over its behavior.


title: HISTORY
content:
The <b>ng</b> command, as part of the Angular CLI, was first introduced to simplify the development process of Angular applications. It gained prominence with <I>Angular 2+</I> as a crucial tool to manage the complexity of modern front-end development, including TypeScript compilation, module bundling, and dependency management. Its evolution has closely mirrored the development of the Angular framework itself, with continuous updates introducing new features, improving performance, and adapting to changes in web development best practices.


title: PARAMETERS
content:
<b>-d DOMAIN, --domain=DOMAIN</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the domain of the messages. If not specified, it defaults to the <i>textdomain</i> configured in the environment.<br><br><b>-e, --no-expand</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not expand escape sequences in the output. Output bytes directly without interpretation.<br><br><b>-c CATEGORY, --context=CATEGORY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the message context. This is typically used when the same message ID can have different translations depending on its specific usage context.<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>ngettext</i> is a command-line utility from the GNU gettext tools, designed to retrieve the correct plural form of a translated message from a message catalog (typically a .mo file). It's crucial for internationalization (i18n) and localization (l10n) efforts, allowing applications to display grammatically correct messages depending on a numeric quantity.<br><br>The command takes three core arguments: the <b>domain</b> (usually the name of the software package), the <b>singular form</b> of the message ID (<i>MSGID</i>), the <b>plural form</b> of the message ID (<i>MSGID_PLURAL</i>), and a <b>count</b>. Based on the provided <i>count</i> and the plural rules defined for the target language in the message catalog, <i>ngettext</i> outputs the appropriate translated string. This ensures that an application can correctly display "1 file" versus "2 files" or "0 files" in multiple languages, where plural rules can be complex and vary significantly. It's an essential component for making software globally accessible and user-friendly.


title: CAVEATS
content:
Requires a properly installed and accessible message catalog (.mo file) for the specified domain and locale.<br>The plural rules are determined by the <i>MSGID_PLURAL</i> and <i>COUNT</i> argument, along with the 'Plural-Forms' header defined in the MO file. Incorrect 'Plural-Forms' can lead to wrong outputs.<br>The behavior is highly dependent on the <i>LANG</i>, <i>LC_ALL</i>, and <i>LC_MESSAGES</i> environment variables, which determine the effective locale for translation.


title: ENVIRONMENT VARIABLES
content:
<i>ngettext</i>'s behavior is heavily influenced by standard GNU gettext environment variables such as <b>LANG</b>, <b>LC_ALL</b>, and <b>LC_MESSAGES</b>, which determine the desired locale for translation. The <b>TEXTDOMAINDIR</b> variable specifies where the .mo files (message catalogs) are located on the system.


title: EXIT STATUS
content:
<i>ngettext</i> returns <b>0</b> on successful operation. It returns <b>1</b> if an error occurred, such as missing arguments, inability to find the specified domain, or if the message could not be retrieved.


title: HISTORY
content:
<i>ngettext</i> is an integral part of the GNU gettext package, which was developed by the GNU Project to provide a standardized framework for internationalizing software. Its development began in the early 1990s, aiming to simplify the process of translating software by separating translatable strings from the source code. The concept of plural forms was a later, crucial addition to handle linguistic complexities, leading to the inclusion of <i>ngettext</i> to specifically address these varying plural rules across languages. It has been a stable and widely used utility in the GNU/Linux ecosystem for decades.


title: SYNOPSIS
content:
<b><I>nginx</I></b> [-h] [-v] [-V] [-t] [-q] [-s signal] [-p prefix] [-c filename] [-g directives]<br><br>Examples:<br><b><I>nginx</I></b><br><i>Starts the Nginx server.</i><br><br><b><I>nginx</I> -s reload</b><br><i>Reloads the Nginx configuration gracefully.</i><br><br><b><I>nginx</I> -t</b><br><i>Tests the Nginx configuration file for syntax errors.</i>


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <b>help</b> message and exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows <b>Nginx version</b> only and exits.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <b>Nginx version</b>, compiler version, and <b>configure arguments</b> used during compilation.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests the configuration file for <b>syntax correctness</b> and validity without starting the server. Nginx will parse the configuration file and report any errors.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-error messages during configuration test (used with <b>-t</b>).<br><br><b>-s signal</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a <b>signal</b> to the master process. Common signals include <i>stop</i> (fast shutdown), <i>quit</i> (graceful shutdown), <i>reload</i> (reload configuration), and <i>reopen</i> (reopen log files).<br><br><b>-p prefix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>prefix path</b>, which is the installation directory. This affects where Nginx looks for configuration files, modules, and other resources.<br><br><b>-c filename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <b>configuration file</b> to use instead of the default.<br><br><b>-g directives</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets <b>global directives</b> from the command line. These directives are processed before the main configuration file.<br><br>


title: DESCRIPTION
content:
Nginx (pronounced "engine-x") is a <b>free</b>, <b>open-source</b>, high-performance <b>HTTP server</b>, <b>reverse proxy</b>, and <b>mail proxy</b> server. It's renowned for its high <b>concurrency</b>, excellent <b>performance</b>, and low memory usage. Nginx excels at serving <i>static content</i>, handling a large number of <i>concurrent connections</i>, and improving the <i>reliability</i> and <i>speed</i> of web applications. Its <b>event-driven</b> architecture allows it to efficiently manage thousands of concurrent connections, making it a popular choice for high-traffic websites and complex distributed systems.


title: CAVEATS
content:
Running <b><I>nginx</I></b> requires <b>root privileges</b> to bind to privileged ports (like 80 or 443), though worker processes typically drop privileges to a non-root user. The <b>configuration file syntax</b> is extremely <b>strict</b>; even minor errors can prevent Nginx from starting or reloading. Always test configurations with <b><I>nginx</I> -t</b> before reloading in production. Debugging issues often heavily relies on detailed <b>log files</b>.


title: CONFIGURATION FILES
content:
<b>Nginx</b> relies on a highly structured, declarative <b>configuration file</b>, typically found at <b>/etc/nginx/nginx.conf</b> or within an installation prefix. This file is organized into various <b>contexts</b> (e.g., <i>main</i>, <i>events</i>, <i>http</i>, <i>server</i>, <i>location</i>, <i>upstream</i>), allowing for fine-grained control over server behavior, virtual hosts, and request processing. It supports inclusion of multiple files for modularity.


title: SIGNALS AND PROCESS MANAGEMENT
content:
The <b><I>nginx</I></b> master process responds to several <b>signals</b> for management without restarting the server. These include <b><I>stop</I></b> or <b><I>quit</I></b> for shutdown, <b><I>reload</I></b> for applying configuration changes, and <b><I>reopen</I></b> for rotating log files. Nginx operates with a master process and multiple <b>worker processes</b>; the master manages the workers, which handle client requests efficiently.


title: HISTORY
content:
<b>Nginx</b> was originally developed by <b>Igor Sysoev</b> and first publicly released in <b>2004</b>. Its primary motivation was to address the <b>C10k problem</b> – efficiently handling 10,000 or more concurrent connections – particularly for the high-traffic Rambler.ru website. Its innovative <b>event-driven, asynchronous architecture</b> provided a significant performance advantage over traditional process-per-connection servers, especially under heavy load. Nginx rapidly gained traction, becoming a dominant choice for <b>high-traffic websites</b>, <b>reverse proxying</b>, and <b>load balancing</b> globally. Nginx, Inc. was founded in 2011 for commercial offerings and was later acquired by F5 Networks in 2019.


title: SEE ALSO
content:
<b><I>apache2</I></b>(8) or <b><I>httpd</I></b>(8)<br><i>Alternative web servers.</i>, <b><I>systemctl</I></b>(1) or <b><I>service</I></b>(8)<br><i>Tools for managing Nginx as a system service.</i>, <b><I>curl</I></b>(1), <b><I>wget</I></b>(1)<br><i>Commands to test web server responses.</i>, <b><I>netstat</I></b>(8), <b><I>ss</I></b>(8)<br><i>Utilities for network connection diagnostics.</i>


title: SYNOPSIS
content:
<b>ngrep</b> [<i>options</i>] <i>&lt;match expression&gt;</i> [ <i>&lt;bpf filter&gt;</i> ]<br><b>ngrep</b> -h<br><b>ngrep</b> -V


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invert the match; select non-matching packets.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore case for the regular expression match.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; suppress output except for matching packets.<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hex dump matched packets.<br><br><b>-X</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hex dump the entire packet.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Match the expression as a whole word.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not put the interface into promiscuous mode.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make stdout line buffered.<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to match reply packets.<br><br><b>-d <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listen on the specified network interface.<br><br><b>-A <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump N bytes of packet payload after a match.<br><br><b>-W <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump N bytes of packet payload before a match.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a timestamp to the output.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show timestamps in delta mode (relative to previous packet).<br><br><b>-S <limit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of packets to process.<br><br><b>-s <snaplen></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the snaplen (packet capture length).<br><br><b>-P <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read BPF filter from the specified file.<br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read regex pattern from the specified file.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not convert addresses to names (e.g., IPs to hostnames).<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not convert port numbers to service names (e.g., 80 to http).<br><br><b>-k <key_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use key_file to decrypt SSL/TLS traffic.<br><br><b>-N <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only match against the first N bytes of the payload.<br><br><b>-O <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump matched packets to a pcap file.<br><br><b>-L <limit></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the number of packets dumped to the pcap file.<br><br><b>-F</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print leading newlines in output.<br><br><b>-T</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print relative timestamps from the start of capture.<br><br><b>-r <pcap_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read packets from a pcap file instead of a live interface.<br><br>


title: DESCRIPTION
content:
<b>ngrep</b> is a powerful command-line utility designed for network traffic analysis, akin to applying the text-searching capabilities of <b>grep</b> to live or recorded network data. It allows users to match regular expressions against network packets, including their headers and payloads, in real-time from a network interface or from <b>pcap</b> capture files. Supporting various protocols like TCP, UDP, and ICMP, <b>ngrep</b> is invaluable for network troubleshooting, security auditing, and debugging applications. Its ability to combine robust regular expression matching with efficient Berkeley Packet Filter (BPF) rules provides a flexible and precise way to pinpoint specific data, detect anomalies, or observe communication patterns within complex network environments. This makes it an essential tool for administrators and security professionals alike.


title: CAVEATS
content:
<i>ngrep</i> typically requires root privileges for capturing packets on most systems.<br>SSL/TLS decryption features are limited; they primarily support RSA key exchange and require the correct private key, and may not work with all modern ciphers or protocols.<br>On high-traffic networks, <i>ngrep</i> can consume significant system resources and potentially drop packets if not used with appropriate BPF filters or on a powerful enough machine.


title: REGULAR EXPRESSIONS
content:
<i>ngrep</i> utilizes extended regular expressions (ERE) for its pattern matching capabilities. This allows for complex and flexible pattern definitions, enabling users to pinpoint specific data sequences within the network traffic payload.


title: BPF FILTERS
content:
To enhance performance and reduce the amount of data processed, <i>ngrep</i> supports Berkeley Packet Filter (BPF) syntax. BPF filters are applied at the kernel level, efficiently discarding unwanted packets before they are passed to <i>ngrep</i> for regular expression matching. This is crucial for analyzing traffic on busy networks.


title: HISTORY
content:
<i>ngrep</i> was created by Jordan Ritter and first released in 1999. It was developed to provide a command-line utility that brought the familiar text-searching power of <i>grep</i> to network packet analysis, building upon the foundational <i>libpcap</i> library for packet capture. Its ongoing development has focused on enhancing its utility for real-time network monitoring and security analysis.


title: SYNOPSIS
content:
<b>ngrok</b> <br> <i>[options]</i> <br> <i>&lt;command&gt;</i> <br> <i>[command_options]</i> <br> <i>&lt;arguments&gt;</i> <br><br> Common usage:<br> <b>ngrok http 80</b> <br> <b>ngrok tcp 22</b> <br> <b>ngrok start my_tunnel</b>


title: PARAMETERS
content:
<b>--authtoken <i>&lt;token&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates the ngrok agent with your account to enable advanced features like custom domains and more concurrent tunnels.<br><br><b>--region <i>&lt;region&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ngrok server region to connect to (e.g., us, eu, ap, au, sa, jp, in).<br><br><b>--config <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate path to the ngrok configuration file. Default is ~/.ngrok2/ngrok.yml.<br><br><b>--log <i>&lt;mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures where ngrok's logs are sent (e.g., stdout, none, file, json).<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging for troubleshooting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the ngrok client version and exits.<br><br><b>--host-header <i>&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with `http` command) Rewrites the Host header of the incoming HTTP request before forwarding it to your local server.<br><br><b>--auth <i>&lt;user:pass&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with `http` command) Adds HTTP basic authentication to your tunnel, requiring a username and password to access the public URL.<br><br><b>--subdomain <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with `http` command) Requests a specific subdomain for your tunnel's public URL (e.g., <i>&lt;name&gt;</i>.ngrok.io). Requires an authenticated account.<br><br>


title: DESCRIPTION
content:
Ngrok is a powerful cross-platform command-line tool that creates secure, publicly accessible tunnels to your local machine. It acts as a reverse proxy, allowing you to expose a web server, API, or any other network service running on your local development environment to the internet. This is particularly useful for testing webhooks, demonstrating in-progress work to clients, accessing devices behind a firewall or NAT, or setting up temporary public access for collaborators without complex network configurations. Ngrok handles the complexities of NAT traversal and firewall bypass, providing a simple, one-line command to get a public URL or TCP address. It also offers features like traffic inspection via a local web UI, custom subdomains, HTTP basic authentication, and TLS termination. It supports HTTP, TCP, and TLS tunnels, making it versatile for various development and testing scenarios.


title: CAVEATS
content:
<b>Security Risks:</b> Exposing local services to the internet via ngrok can introduce significant security risks if not properly secured. Ensure sensitive services are protected with authentication or only exposed temporarily.<br><b>Reliance on Ngrok Service:</b> Ngrok is a cloud-based service, meaning its availability and performance depend on ngrok's infrastructure. It's not a purely local solution.<br><b>Free Tier Limitations:</b> The free tier has limitations on concurrent tunnels, tunnel duration, custom subdomains, and bandwidth, which might require a paid subscription for heavier usage.<br><b>Network Latency:</b> Data travels through ngrok's servers, which can introduce additional latency compared to direct local access.


title: LOCAL WEB INTERFACE (TRAFFIC INSPECTION)
content:
When ngrok is running, it typically provides a local web interface accessible at <i>http://localhost:4040</i>. This interface allows you to inspect all HTTP traffic passing through your ngrok tunnels, view request/response headers, and even replay requests, which is incredibly useful for debugging.


title: CONFIGURATION FILE
content:
Ngrok can be configured via a YAML file, usually located at <i>~/.ngrok2/ngrok.yml</i> or <i>~/.config/ngrok/ngrok.yml</i>. This file can store your authentication token, define persistent tunnels (e.g., `http`, `tcp`), and specify other default options, allowing for easier <b>ngrok start</b> command usage.


title: COMMON USE CASES
content:
Beyond simple local server exposure, ngrok is widely used for: <br>- <i>Webhooks Testing</i>: Receiving webhook payloads from services like Stripe, GitHub, or Twilio directly to your local development environment. <br>- <i>API Development</i>: Testing APIs that rely on external callbacks or need to be accessed by external clients. <br>- <i>Demoing Applications</i>: Quickly sharing a live demo of a web application in progress without deployment. <br>- <i>SSH Access</i>: Creating a public TCP tunnel to SSH into a Raspberry Pi or other device behind a NAT.


title: HISTORY
content:
Ngrok was created by Alan Shreve, who initially released it as an open-source project around 2013. It quickly gained popularity among developers due to its simplicity and effectiveness in solving the common problem of exposing local development servers. Over time, the project evolved into a commercial service, with a free tier still available, allowing for sustainable development and the introduction of advanced features like custom domains, improved security, and dedicated regions. Its ease of use and immediate utility solidified its place as a staple in many web developers' toolkits.


title: SYNOPSIS
content:
Due to <b>ngs</b> not being a standard Linux command, there is no universal synopsis. Its syntax will be specific to its custom implementation. For example, a hypothetical usage might be: <I>ngs [options] &lt;arguments&gt;</I>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As <b>ngs</b> is not a standard command, there are no universally defined parameters. Any options or arguments would be specific to its custom implementation on a given system.<br><br>


title: DESCRIPTION
content:
The <b>ngs</b> command is <I>not a standard utility</I> found in typical Linux distributions' core packages. It does not have a universally defined purpose, syntax, or set of options. If encountered, <b>ngs</b> likely refers to a specialized, domain-specific application (e.g., related to Next-Generation Sequencing in bioinformatics), a custom script created by a system administrator or user, or a local alias. Its functionality, arguments, and behavior are entirely dependent on its specific implementation on a given system. Users should consult local documentation or the system administrator for details regarding its use.


title: CAVEATS
content:
The primary caveat is that <b>ngs</b> is <I>not portable</I> across different Linux systems. Its presence, functionality, and behavior are entirely system-dependent. Relying on <b>ngs</b> in scripts or workflows designed for general Linux environments is ill-advised unless the target environment is strictly controlled and known to have this specific command implemented. Users should exercise caution and verify its purpose on any system where it is encountered.


title: HISTORY
content:
N/A: As <b>ngs</b> is not a standard Linux command, there is no common development history or standardized usage to document. Its origin and evolution are specific to individual custom implementations by developers or system administrators.


title: SYNOPSIS
content:
<b>nhentai</b> [<i>OPTIONS</i>] <i>&lt;ID | URL&gt;</i><br><b>nhentai</b> [<i>OPTIONS</i>] <b>search</b> <i>&lt;QUERY&gt;</i>


title: PARAMETERS
content:
<b><b>-i</b>, <b>--id</b> <i>&lt;ID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the numerical ID(s) of the gallery to download. Multiple IDs can be provided, separated by spaces.<br><br><b><b>-s</b>, <b>--search</b> <i>&lt;QUERY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a search on nhentai.net using the specified query string. Can be combined with <b>--tags</b>.<br><br><b><b>-t</b>, <b>--tags</b> <i>&lt;TAGS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters search results by specific tags. This option is used in conjunction with <b>--search</b>.<br><br><b><b>-o</b>, <b>--output</b> <i>&lt;PATH&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the destination directory where downloaded galleries will be saved.<br><br><b><b>-f</b>, <b>--format</b> <i>&lt;FORMAT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the output file format for the downloaded gallery. Common formats include <i>zip</i>, <i>cbz</i>, <i>pdf</i>, or <i>raw</i> (individual images).<br><br><b><b>-p</b>, <b>--proxy</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a proxy server to use for the connection, useful for bypassing regional restrictions or IP blocks.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a download operation without actually saving any files, displaying what would be downloaded.<br><br><b><b>--delay</b> <i>&lt;SECONDS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Introduces a delay (in seconds) between downloads to prevent overwhelming the server.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message detailing the command's options and usage.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>nhentai</b> utility.<br><br>


title: DESCRIPTION
content:
The <b>nhentai</b> command-line utility provides a powerful interface for downloading, searching, and managing content from nhentai.net directly from a Linux terminal. It allows users to quickly retrieve galleries by their unique ID, perform searches based on keywords and tags, and save content in various formats such as ZIP, CBZ, or PDF. As a third-party tool, it streamlines the process of accessing and archiving doujinshi, offering features like directory customization, proxy support, and the ability to handle multiple downloads. It is widely used by individuals seeking to programmatically interact with the nhentai.net website.


title: CAVEATS
content:
The <b>nhentai</b> command is a third-party utility and is not part of standard Linux distributions. Its functionality relies heavily on the nhentai.net website's structure, which may change, potentially breaking the tool. Users should be aware of the legal and ethical implications of downloading content from such sites, as the legality of accessing or distributing certain content varies by region. Excessive use without appropriate delays or proxy settings might lead to IP blocking by the website.


title: INSTALLATION
content:
As a third-party tool, <b>nhentai</b> typically needs to be installed separately, often via package managers like <i>pip</i> (for Python versions) or by compiling from source. For example: <i>pip install nhentai-dl</i>.<br>Users should consult the specific project's documentation for the most accurate installation instructions.


title: CONTENT POLICY
content:
It is crucial for users to understand and adhere to the content policies and terms of service of nhentai.net, as well as local laws regarding the consumption and distribution of adult content. The use of this tool for illegal or unauthorized purposes is strictly discouraged.


title: HISTORY
content:
The <b>nhentai</b> command, in its various implementations (often written in Python), emerged as a response to the need for automated downloading and management of content from nhentai.net. While no single official 'nhentai' Linux command exists, several open-source projects have independently developed command-line interfaces. Early versions focused on basic ID-based downloads, with later developments adding search functionality, multiple output formats, and robust error handling. These tools became popular among users who prefer command-line automation over manual browser interaction, continuously adapting to website changes and user demands.


title: SEE ALSO
content:
<b>wget(1)</b>: A non-interactive network downloader that supports various protocols, useful for general web content retrieval., <b>curl(1)</b>: A tool to transfer data from or to a server, supporting a wide range of protocols, often used in scripts for fetching web content.


title: SYNOPSIS
content:
<b>nikto</b> [<b>-h</b> <i>target_host</i>] [<b>-H</b> <i>target_file</i>] [<i>options</i>]<br><b>nikto</b> <b>-update</b>


title: PARAMETERS
content:
<b><b>-h</b> <i>target_host</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target host/IP address to scan. Can be a hostname or IP address.<br><br><b><b>-H</b> <i>target_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan hosts listed in the specified file, one per line. Useful for batch scanning.<br><br><b><b>-p</b> <i>ports</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Port(s) to scan. Can be a single port (e.g., '80'), a comma-separated list (e.g., '80,443'), or a range (e.g., '80-88').<br><br><b><b>-ssl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force SSL/HTTPS mode for connections to the target host.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output. Use multiple 'v's (e.g., '<b>-vv</b>') for more detailed output.<br><br><b><b>-C</b> <i>check_type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check specific content types. Options include 'all', 'cgi', 'edb' (Exploit-DB), 'user' (user-defined checks), 'dict' (dictionary attacks), 'rf' (remote file checks).<br><br><b><b>-o</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output scan results to the specified file.<br><br><b><b>-F</b> <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output file format. Common options are 'htm' (HTML), 'csv' (Comma Separated Values), 'txt' (plain text), 'nbe' (Nessus NBE format), 'xml' (XML).<br><br><b><b>-T</b> <i>tuning_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tuning options to control the scan. E.g., 'x' for skipping redirects, 'a' for full scan, 'd' for checking only default files.<br><br><b><b>-useragent</b> <i>string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the default user-agent string sent in HTTP requests.<br><br><b><b>-evasion</b> <i>techniques</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify evasion techniques to use (e.g., '1' for using URL encoding, '2' for premature URL encoding).<br><br><b><b>-update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the <i>Nikto</i> plugins and database files. It's crucial for keeping <i>Nikto</i> effective.<br><br>


title: DESCRIPTION
content:
<i>Nikto</i> is an open-source web server scanner that performs comprehensive tests against web servers for multiple items, including over 6700 potentially dangerous files/programs, checks for outdated server versions, and version-specific problems on over 270 server versions. It also checks for misconfigurations like default files or programs that should not be present, and attempts to identify installed web applications and their versions. <i>Nikto</i> can be used to scan for known vulnerabilities and security issues, making it a valuable tool for penetration testers and security professionals. It's often employed in the reconnaissance phase to gather information about a target web server's security posture. <i>Nikto</i> is not a full-fledged vulnerability scanner that exploits findings, but rather an information-gathering tool that points out potential weaknesses. It is a command-line utility, often included in security-focused Linux distributions.


title: CAVEATS
content:
<i>Nikto</i> can be quite noisy and easily detected by Intrusion Detection/Prevention Systems (IDPS) or Web Application Firewalls (WAFs). It may also generate a significant number of false positives, requiring manual verification of reported vulnerabilities. It does not perform exploitation of vulnerabilities; it merely identifies potential weaknesses. Regular updates using the '<b>-update</b>' option are essential for effective scanning, as new vulnerabilities and checks are constantly being added. Always ensure you have explicit permission before scanning any system.


title: TYPICAL USAGE
content:
<i>Nikto</i> is typically used in the initial phases of penetration testing or security assessments. It helps security professionals quickly identify low-hanging fruit, common misconfigurations, and outdated software versions that could pose a risk. It's also valuable for auditing one's own web servers to ensure compliance with security best practices.


title: INSTALLATION
content:
<i>Nikto</i> is pre-installed on many security-focused Linux distributions, such as Kali Linux and Parrot OS. On other distributions, it can usually be installed via the default package manager, for example: <br><i>sudo apt install nikto</i> (Debian/Ubuntu-based)<br><i>sudo yum install nikto</i> (Red Hat/CentOS-based)


title: HISTORY
content:
<i>Nikto</i> was originally developed by Chris Sullo and first released in 2001. It quickly gained popularity within the information security community as a quick and effective web server vulnerability scanner. It has been maintained by CIRT.net (Computer Incident Response Team) and continues to be updated with new checks and features. Its consistent development and inclusion in popular security distributions like Kali Linux have cemented its place as a standard tool for web server security assessments and reconnaissance.


title: PARAMETERS
content:
<b><b>-C</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change to <I>DIR</I> before doing anything else. Useful for running Ninja from a different directory than where the build files are located.<br><br><b><b>-f</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input build file. Defaults to <I>build.ninja</I> in the current directory.<br><br><b><b>-j</b> <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <I>N</I> jobs (commands) in parallel. By default, Ninja determines the optimal number based on available CPU cores. Use <I>0</I> for unlimited jobs.<br><br><b><b>-k</b> <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep going until <I>N</I> jobs fail. A value of <I>0</I> means keep going forever, ignoring failures until all possible targets are built or attempted.<br><br><b><b>-t</b> <i>TOOL</i> [<i>args</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run a subtool. Common tools include <I>clean</I> (to remove build outputs), <I>query</I> (to inspect dependencies), and <I>graph</I> (to visualize the build graph).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all command lines run during the build process, making the output more verbose.<br><br><b><b>-d</b> <i>DEBUG_FLAGS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable specific debugging flags for diagnostics, such as <I>explain</I> (to understand why a target is being rebuilt) or <I>deps</I> (to see dependency information).<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the Ninja build system version.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with command-line options.<br><br>


title: DESCRIPTION
content:
Ninja is a small, fast build system designed for speed, particularly in large, complex software projects. Unlike traditional build systems like GNU Make, Ninja focuses solely on executing build steps as quickly as possible. It achieves this by using a very simple, low-level build file format (<I>build.ninja</I>) that describes dependencies and commands in a straightforward, declarative way. Ninja is not intended to be used directly by developers to write build rules; instead, it is typically used as a backend for <I>"meta-build systems"</I> like CMake or Meson, which generate the <I>build.ninja</I> files. This separation allows the higher-level system to manage project configuration and platform specifics, while Ninja handles the efficient execution of the actual compilation and linking tasks. Its primary goal is to minimize the time spent in the build system itself during incremental builds, making development cycles faster and more efficient.


title: CAVEATS
content:
Ninja is primarily a build <I>executor</I>, not a build <I>generator</I>. It expects its low-level build files (<I>build.ninja</I>) to be generated by a higher-level build system like CMake or Meson. Therefore, it's not typically used for writing build rules from scratch, and its own build file format is intentionally simplistic, lacking the scripting capabilities found in tools like GNU Make.


title: META-BUILD SYSTEM RELATIONSHIP
content:
Ninja is often considered a backend build system. This means it doesn't offer high-level features for configuring projects across different platforms or managing complex build logic. Instead, it relies on front-end <I>"meta-build systems"</I> like CMake or Meson to translate a project's high-level description into the simple, fast-to-parse <I>build.ninja</I> files. This separation of concerns allows developers to use powerful, abstract configuration tools while leveraging Ninja's raw speed for the actual compilation and linking.


title: SIMPLICITY OF <I>BUILD.NINJA</I>
content:
The <I>build.ninja</I> file format is deliberately simple, lacking features like conditionals, loops, or complex scripting capabilities. This simplicity is a core design choice that enables Ninja to parse build files extremely quickly and efficiently determine what needs to be rebuilt. It focuses purely on defining rules (commands) and builds (inputs, outputs, and the rule to apply), making it highly optimized for machine generation and execution.


title: HISTORY
content:
Ninja was developed by Evan Martin at Google, primarily to address the increasingly slow build times encountered by the Chromium project, which had grown to an immense size. Traditional build systems like Make were struggling with the scale and complexity, leading to long incremental build cycles. Ninja was designed from the ground up to be incredibly fast, focusing solely on efficient dependency tracking and parallel execution. It was first released in 2011 and quickly gained traction in large-scale software development environments where build efficiency is paramount.


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits the game.<br><br><b>-i <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative sprite definition file for the invaders. This allows for customization of the alien appearance.<br><br><b>-s <speed></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the game speed, controlling the delay between frames. A lower number makes the game faster, while a higher number slows it down.<br><br>


title: DESCRIPTION
content:
The <b>ninvaders</b> command brings the classic arcade game <i>Space Invaders</i> directly to your Linux terminal. Leveraging the <i>ncurses</i> library, it renders the game using text-based graphics, providing a lightweight yet engaging experience without requiring a graphical desktop environment. Players control a laser cannon at the bottom of the screen, moving left and right to avoid enemy fire and destroy waves of descending alien invaders. The objective is to eliminate all enemies before they reach the bottom of the screen or collide with your cannon.<br><br>The game progresses through multiple levels, with increasing alien numbers and varied attack patterns, challenging players to improve their reflexes and strategic thinking. <i>ninvaders</i> maintains the minimalist charm of the original game, focusing on simple yet effective gameplay. Its text-mode interface makes it suitable for playing on remote SSH sessions, older systems, or simply for a quick dose of nostalgia directly from your shell. It's a perfect example of how the <i>ncurses</i> library enables rich interactive applications within the command-line interface, offering a fun distraction for anyone looking for a retro gaming experience in a modern terminal.


title: CAVEATS
content:
Requires the <i>ncurses</i> library to be installed on the system. As a text-mode game, it does not offer high-fidelity graphics and its visual presentation is limited to characters. Performance might vary slightly depending on the terminal emulator and system load.


title: GAMEPLAY CONTROLS
content:
Players typically use the <i>left arrow</i> and <i>right arrow</i> keys to move the cannon horizontally, and the <i>spacebar</i> to fire. The objective is to destroy all descending alien invaders before they reach the bottom of the screen.


title: AVAILABILITY
content:
The command is usually available through packages like <i>ncurses-examples</i>, <i>ncurses-games</i>, or <i>bsdgames</i>, depending on your Linux distribution.


title: HISTORY
content:
<i>ninvaders</i> is typically distributed as part of the <i>ncurses-examples</i> or <i>ncurses-games</i> packages on many Linux distributions. It serves as a practical demonstration and example of how the <i>ncurses</i> library can be used to create interactive terminal-based applications and games. Its development is closely tied to the evolution of the <i>ncurses</i> library itself, showcasing its capabilities for character-based graphical user interfaces and real-time interaction within a shell environment. It has been a common and enduring example in the Unix/Linux ecosystem for many years.


title: SYNOPSIS
content:
<i>N/A - Command not found.</i><br>A synopsis cannot be provided for <b>'nitch'</b> as it is not a recognized standard Linux command. Its syntax, options, and arguments are unknown.


title: DESCRIPTION
content:
The command <b>'nitch'</b> is not a standard or commonly recognized utility within typical Linux distributions. Extensive searches across official man pages, command repositories, and community documentation do not yield any results for a command with this exact name and general-purpose functionality. It is highly probable that this name is a typographical error, refers to a very specific, custom-built script, an alias, or an obscure tool that is not part of the common operating system environment. Alternatively, it might be a misunderstanding or misremembering of a similar-sounding, legitimate command. Without a defined function or verifiable existence in mainstream Linux operating systems, a comprehensive and accurate analysis of its purpose, command-line syntax, and available options cannot be provided. Users encountering this command name are strongly advised to double-check for potential misspellings or to verify if it pertains to a non-standard application or local configuration they intend to use or investigate.


title: CAVEATS
content:
This analysis is based on the current understanding that <b>'nitch'</b> does not exist as a standard command in prevalent Linux systems. Therefore, any expectations of its functionality or usage should be re-evaluated. It is crucial to verify the correct command name before attempting to use it.


title: POSSIBLE MISSPELLINGS OR SIMILAR COMMANDS
content:
If you intended to use a Linux command, it is worth checking for potential misspellings of commands with similar sounds or characters. Examples include:<ul><li><b>nice(1)</b>: A command to run a program with modified scheduling priority.</li><li><b>nmap(1)</b>: A powerful network scanning utility.</li><li><b>netcat(1)</b> (often invoked as <i>nc</i>): A utility for reading from and writing to network connections using TCP or UDP.</li><li><b>patch(1)</b>: A utility to apply a diff file to an original file.</li></ul>


title: CUSTOM SCRIPTS OR ALIASES
content:
In specific environments or personal setups, <b>'nitch'</b> might exist as a custom shell script, an alias defined in a user's <i>.bashrc</i> or <i>.zshrc</i> file, or a proprietary tool developed for a particular system. If this is the case, its documentation and functionality would be specific to that local environment and not universally applicable.


title: HISTORY
content:
No historical information or development context can be provided for a command that is not recognized as part of standard Linux distributions or its common utilities.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b><b>--set-auto</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically determine the best fit for the selected image (e.g., zoom, fill, etc.).<br><br><b><b>--set-scaled</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scale the image to fit the screen, maintaining aspect ratio. Pads with background color if necessary.<br><br><b><b>--set-centered</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Center the image on the screen. Pads with background color if necessary.<br><br><b><b>--set-zoom</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Zoom the image to fill the screen, maintaining aspect ratio. Image may be cropped.<br><br><b><b>--set-tiled</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tile the image across the screen.<br><br><b><b>--set-fill</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stretch the image to fill the screen completely, ignoring aspect ratio.<br><br><b><b>--set-color</b>=<I>RRGGBB</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a solid background color using an RGB hexadecimal value (e.g., <I>000000</I> for black). This color is used for padding with some <I>--set</I> modes.<br><br><b><b>--random</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a random image from the configured directories and set it as wallpaper.<br><br><b><b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively scan specified directories for images.<br><br><b><b>--head</b>=<I>NUM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which monitor (Xinerama head) to apply the wallpaper to in a multi-monitor setup. <I>NUM</I> is the head index (0-indexed).<br><br><b><b>--save</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the current wallpaper settings (image path, scaling mode, color) to the configuration file.<br><br><b><b>--restore</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restore the last saved wallpaper settings. Often used in autostart scripts.<br><br><b><b>--prev</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Go to the previous image in the history/list of displayed wallpapers.<br><br><b><b>--next</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Go to the next image in the history/list of displayed wallpapers.<br><br><b><b>--sort</b>=<I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort images by <I>alpha</I> (alphabetical filename) or <I>xinerama</I> (by Xinerama head, for multi-monitor display).<br><br><b><I>directory</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more directories to scan for images. These paths are added to Nitrogen's list of image folders.<br><br>


title: DESCRIPTION
content:
Nitrogen is a lightweight, graphical utility designed for setting desktop wallpapers in X Window System environments. Unlike heavier desktop environments, Nitrogen offers a minimalistic approach, making it particularly well-suited for standalone window managers such as Openbox, Fluxbox, i3, Awesome, and others that do not provide native wallpaper management. It allows users to browse image directories, preview wallpapers, and easily set them as their desktop background. <br><br>Key features include support for multiple monitor setups, where different wallpapers can be assigned to individual screens. Nitrogen provides various scaling options, including <I>Zoom</I>, <I>Scaled</I>, <I>Centered</I>, <I>Tiled</I>, and <I>None</I>, ensuring wallpapers fit perfectly regardless of resolution. It also allows for setting a background color when the image doesn't fill the screen. Configuration settings, such as image paths and wallpaper choices, are saved, allowing Nitrogen to be run on startup (e.g., via <I>~/.xinitrc</I> or <I>~/.config/openbox/autostart</I>) to automatically restore the desired background. Its simplicity and low resource consumption make it a popular choice among users seeking a flexible and efficient wallpaper solution.


title: CAVEATS
content:
Nitrogen is specifically designed for the X Window System and will not function in Wayland environments. While it offers a simple and effective wallpaper solution for lightweight window managers, users of full desktop environments like GNOME or KDE might find their integrated wallpaper settings more convenient or feature-rich. Nitrogen also does not support animated wallpapers or video backgrounds.


title: CONFIGURATION FILES
content:
Nitrogen saves its settings in the user's home directory, typically in <I>~/.config/nitrogen/</I>. The <I>bg-saved.cfg</I> file stores the path and mode of the last set wallpaper, while <I>nitrogen.cfg</I> contains general application settings, including the list of image directories.


title: AUTOSTART INTEGRATION
content:
To automatically restore the wallpaper on system startup, Nitrogen is often called with the <B>--restore</B> option in a user's autostart script (e.g., <I>~/.xinitrc</I>, <I>~/.config/openbox/autostart</I>, or similar files depending on the window manager). For example: <I>nitrogen --restore &</I>


title: HISTORY
content:
Nitrogen was created by Alex Smith as a lightweight and efficient solution for managing desktop wallpapers in X environments. It quickly gained popularity among users of minimalistic window managers due to its small footprint and independence from heavy desktop environments. Its development has focused on providing a stable and reliable tool for a core task, becoming a staple in many "dotfiles" setups for automatically restoring wallpapers on system startup.


title: SYNOPSIS
content:
<b>nix</b> <i>&lt;subcommand&gt;</i> [<i>options</i>] [<i>arguments</i>]<br><br>The <b>nix</b> command acts as a dispatcher for a suite of powerful subcommands, each designed for specific tasks. Common subcommands include <b>build</b>, <b>shell</b>, <b>run</b>, <b>profile</b>, <b>store</b>, <b>flake</b>, and <b>repl</b>.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help for the specific subcommand or global help if no subcommand is specified.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information for <i>nix</i>.<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of logging output. Can be used multiple times for more detail.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format, useful for scripting and programmatic access.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show what actions would be performed without actually executing them.<br><br><b><b>--experimental-features</b> <i>&lt;features&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable specific experimental features, such as 'flakes' or 'nix-command'.<br><br><b><b>--cores</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of CPU cores to use for builds. Defaults to the number of available cores.<br><br><b><b>--max-jobs</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum number of simultaneous build jobs.<br><br>


title: DESCRIPTION
content:
<i>nix</i> is a powerful and unique package manager and build system that emphasizes reproducibility, reliability, and declarative configuration. Unlike traditional package managers, <i>nix</i> builds and manages software in isolated environments within the <i>Nix store</i> (typically <code>/nix/store</code>), preventing dependency conflicts and ensuring that builds are perfectly reproducible regardless of the system's state.<br><br>Its core philosophy is based on <i>purely functional programming</i> principles: all inputs to a build are precisely defined, and the output is cryptographically hashed, meaning identical inputs always yield identical outputs. This enables features like atomic upgrades, rollbacks, and the ability to run multiple versions of the same software side-by-side without interference.<br><br>Beyond mere package management, <i>nix</i> also serves as a robust build system and is the foundation for <i>NixOS</i>, a declarative operating system. It's widely used for setting up reproducible development environments, continuous integration/delivery (CI/CD) pipelines, and robust system deployments.


title: CAVEATS
content:
<b>Steep Learning Curve</b>: <i>Nix</i> introduces fundamentally different concepts (purely functional, declarative, immutable store) compared to traditional Linux package management, leading to a significant initial learning investment.<br><br><b>Disk Space Usage</b>: The immutable nature of the <i>Nix store</i> means that new versions of packages and all their dependencies are stored separately, which can lead to higher disk space consumption over time if garbage collection is not regularly performed.<br><br><b>Integration with FHS</b>: Integrating <i>Nix</i>-managed software with systems or applications expecting the traditional Filesystem Hierarchy Standard (FHS) layouts (e.g., binaries in <code>/usr/bin</code>, libraries in <code>/usr/lib</code>) can sometimes be challenging, although <i>nix</i> provides mechanisms for this.


