# CommandSection

title: TEST RESULTS AND REPORTING
content:
By default, <b>dotnet test</b> outputs results to the console. However, for structured reporting and integration with CI/CD systems, using the <b>--logger</b> option is common. The <i>TRX</i> format (specified with <b>--logger trx</b>) is widely supported by tools like <i>Azure DevOps</i>, <i>Jenkins</i>, and <i>TeamCity</i> for displaying detailed test results, including stack traces for failed tests.<br><br>The <b>--results-directory</b> option allows specifying where these report files are saved, making it easier to collect them for analysis or archiving.


title: INTEGRATION WITH CI/CD
content:
<b>dotnet test</b> is a fundamental command in automated CI/CD pipelines. Its command-line nature makes it easy to script and integrate into various build servers and orchestrators, promoting a robust <i>DevOps</i> culture by providing immediate feedback on code quality and regressions.


title: HISTORY
content:
The <b>dotnet test</b> command is a cornerstone of the .NET Core CLI, which was introduced to provide a unified, cross-platform command-line experience for .NET development. It emerged as part of the broader effort to modernize .NET and move away from Windows-specific tooling (like MSBuild directly from Visual Studio) towards a more flexible and platform-agnostic approach.<br><br>Since its inception with .NET Core 1.0, <b>dotnet test</b> has continuously evolved with each subsequent .NET release (e.g., .NET Core 2.x, 3.x, and now .NET 5, 6, 7, 8). It standardized the process of running unit, integration, and functional tests across different test frameworks, becoming the de facto command for automated testing in the .NET ecosystem. Its development has focused on improving performance, adding more filtering capabilities, enhancing logging, and integrating with advanced testing features like data collection and run settings.


title: SEE ALSO
content:
<b>dotnet build</b>: Compiles source code into executable binaries or libraries., <b>dotnet restore</b>: Downloads and restores NuGet packages that a project depends on., <b>dotnet run</b>: Executes a .NET application from source code., <b>dotnet publish</b>: Publishes a .NET application and its dependencies to a folder for deployment., <b>dotnet new</b>: Creates new .NET projects, solutions, or configuration files from templates.


title: SYNOPSIS
content:
<b>dotnet tool</b> &lt;<I>COMMAND</I>&gt; [<i>options</i>] [<i>arguments</i>]<br><br><b>Available Commands:</b><br>&nbsp;&nbsp;<b>install</b> &lt;<I>PACKAGE_ID</I>&gt; [<i>options</i>]<br>&nbsp;&nbsp;<b>update</b> &lt;<I>PACKAGE_ID</I>&gt; [<i>options</i>]<br>&nbsp;&nbsp;<b>uninstall</b> &lt;<I>PACKAGE_ID</I>&gt; [<i>options</i>]<br>&nbsp;&nbsp;<b>list</b> [<i>options</i>]<br>&nbsp;&nbsp;<b>run</b> &lt;<I>TOOL_COMMAND_NAME</I>&gt; [<i>arguments</i>]<br>&nbsp;&nbsp;<b>search</b> &lt;<I>SEARCH_TERM</I>&gt; [<i>options</i>]


title: PARAMETERS
content:
<b><b>install</b> &lt;<I>PACKAGE_ID</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a .NET tool specified by its NuGet package ID from NuGet.org or a custom NuGet source.<br><br><b><b>update</b> &lt;<I>PACKAGE_ID</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an already installed .NET tool to its latest stable version or a specified version.<br><br><b><b>uninstall</b> &lt;<I>PACKAGE_ID</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an installed .NET tool from the system or project.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all currently installed .NET tools, either global or local, based on the provided options.<br><br><b><b>run</b> &lt;<I>TOOL_COMMAND_NAME</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a local tool. The <I>TOOL_COMMAND_NAME</I> is the command alias of the tool as defined in its package or manifest.<br><br><b><b>search</b> &lt;<I>SEARCH_TERM</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for .NET tools available on NuGet.org that match the specified search term.<br><br><b><b>-g</b>, <b>--global</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the operation applies to <I>global tools</I>, which are available across the system.<br><br><b><b>-l</b>, <b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies that the operation applies to <I>local tools</I>, managed within a project's context via a tool manifest file.<br><br><b><b>--tool-path</b> &lt;<I>PATH</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a custom directory where global tools should be installed or found. If used, the tool is only accessible via this path.<br><br><b><b>--add-source</b> &lt;<I>SOURCE</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an additional NuGet package source to be used during tool installation or search operations.<br><br><b><b>--configfile</b> &lt;<I>FILE</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a custom NuGet configuration file (e.g., <i>nuget.config</i>) to be used.<br><br><b><b>--framework</b> &lt;<I>FRAMEWORK</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target framework for which the tool should be installed (e.g., <i>net6.0</i>, <i>net8.0</i>).<br><br><b><b>--version</b> &lt;<I>VERSION</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the exact version of the tool to install or update to. Accepts NuGet version ranges.<br><br><b><b>--verbosity</b> &lt;<I>LEVEL</I>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity level of the command's output. Options include <i>q[uiet]</i>, <i>m[inimal]</i>, <i>n[ormal]</i>, <i>d[etailed]</i>, and <i>diag[nostic]</i>.<br><br><b><b>--no-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents caching of packages and HTTP requests, forcing a fresh download.<br><br><b><b>--prerelease</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows installation or search to include prerelease versions of tools.<br><br>


title: DESCRIPTION
content:
The <b>dotnet tool</b> command is an integral part of the .NET SDK, designed to manage <I>.NET tools</I>. A .NET tool is essentially a special NuGet package containing a console application, extending the capabilities of the .NET CLI. These tools can be custom-developed or community-contributed utilities that simplify various development and operational tasks.<br><br>Tools can be installed in two primary ways: as <I>global tools</I>, making them available system-wide via the shell's PATH, or as <I>local tools</I>, which are scoped to a specific project directory and managed through a <I>tool manifest file</I> (<i>dotnet-tools.json</i>). The <b>dotnet tool</b> command provides the necessary functionalities to install, update, uninstall, list, run, and search for these tools, thereby enhancing developer productivity and ensuring consistent development environments.


title: CAVEATS
content:
<ul><li>Installing <I>global tools</I> might require elevated permissions (e.g., <i>sudo</i>) if the default installation directory (often <i>~/.dotnet/tools</i> on Linux/macOS) is not user-writable or if a custom <b>--tool-path</b> outside user control is specified.</li><li>For global tools to be directly executable by their command name, the tool installation directory must be included in your system's PATH environment variable.</li><li>Operations involving <I>local tools</I> (using <b>--local</b>) require a <i>dotnet-tools.json</i> manifest file. If it doesn't exist, <b>dotnet tool install --local</b> will create one in the current directory.</li><li>Command name conflicts can occur if multiple global tools or a global and a local tool share the same command alias. Careful management of installation scopes or aliases might be necessary.</li></ul>


title: TOOL MANIFESTS
content:
<I>Tool manifests</I> are JSON files, typically named <i>dotnet-tools.json</i>, that reside in a project's root or a parent directory. They serve as a declarative list of <I>local tools</I> and their specific versions required for that project. When you install a local tool, this file is updated. Running <b>dotnet tool restore</b> reads this manifest and installs all listed tools, ensuring everyone working on the project uses the exact same versions of development utilities.


title: DEFAULT TOOL LOCATION
content:
By default, <I>global tools</I> are installed into a user-specific directory. On Linux and macOS, this location is commonly <i>~/.dotnet/tools</i>. For these tools to be callable directly from any directory, this path must be added to the system's PATH environment variable. The .NET SDK installer usually attempts to configure this environmental variable automatically during installation.


title: HISTORY
content:
The concept of .NET tools was first introduced with <b>.NET Core 2.1</b>, primarily supporting <I>global tools</I>. A significant enhancement arrived with <b>.NET Core 3.0</b>, which added support for <I>local tools</I> and the associated <I>tool manifest</I> (<i>dotnet-tools.json</i>). This crucial development aimed to make tool dependencies more consistent and reproducible across different development environments and team members, mimicking similar patterns found in other language ecosystems like npm or pipenv. Subsequent .NET versions have continued to refine the tool management experience, focusing on reliability and performance.


title: SYNOPSIS
content:
<b>dovecot</b> [<b>-F</b>] [<b>-c</b> <i>config_file</i>] [<b>-C</b> <i>config_dir</i>] [<b>-n</b>] [<b>-v</b>] [<b>-h</b>] [<b>-V</b>]


title: PARAMETERS
content:
<b><b>-F</b>, <b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the Dovecot daemon in the foreground, without detaching. Useful for debugging or containerized environments.<br><br><b><b>-c</b> <i>config_file</i>, <b>--config=</b><i>config_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative main configuration file to load instead of the default.<br><br><b><b>-C</b> <i>config_dir</i>, <b>--config-dir=</b><i>config_dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory containing Dovecot configuration files. All files ending with .conf in this directory are loaded.<br><br><b><b>-n</b>, <b>--check-config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the syntax and validity of the configuration files and exits. This does not start the server.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables more verbose logging output during startup and operation, providing more detailed information for troubleshooting.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message explaining the command-line options and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Dovecot version information and exits.<br><br>


title: DESCRIPTION
content:
<i>Dovecot</i> is a widely-used, free, and open-source IMAP and POP3 server designed for Unix-like operating systems. Its primary goal is to provide a highly secure, reliable, and high-performance mail delivery agent (MDA) for end-users to access their emails. Known for its ease of setup and minimal administration, <i>Dovecot</i> supports various mail storage formats, including Maildir, mbox, and its own optimized dbox format, which offers superior performance and crash recovery capabilities. <br><br>Key features include robust SSL/TLS support for secure communication, a flexible authentication framework supporting PAM, LDAP, SQL databases, and more. It also provides advanced features like server-side mail filtering via Sieve, efficient indexing for fast searches, and a robust architecture that minimizes the risk of security vulnerabilities. <i>Dovecot</i> is widely deployed by ISPs and large enterprises due to its reliability and scalability, making it a cornerstone for modern email infrastructure.


title: CAVEATS
content:
While <i>Dovecot</i> is designed for security, improper configuration, especially regarding authentication mechanisms, SSL/TLS certificates, or permissions on mail directories, can introduce significant security risks. <br>Advanced deployments, such as clustering, load balancing, or integration with complex authentication backends (e.g., Active Directory with Kerberos), can be intricate and require in-depth knowledge of both <i>Dovecot</i> and the integrated systems. <br>Performance tuning on very high-volume servers is crucial and may involve optimizing OS-level settings, mail storage, and <i>Dovecot</i>'s internal parameters.


title: COMMON SUBCOMMANDS AND UTILITIES
content:
The <i>dovecot</i> binary often acts as a dispatcher for various internal utilities and subcommands that perform specific tasks. These are invoked as <b>dovecot</b> <i>subcommand</i> [<i>args</i>]:<br><ul><li><b>dovecot dsync</b>: Synchronizes mailboxes between servers, commonly used for replication or migration.</li><li><b>dovecot stats</b>: Provides real-time statistics about <i>Dovecot</i>'s performance and resource usage.</li><li><b>dovecot log</b>: Helps in querying and analyzing <i>Dovecot</i>'s logs.</li><li><b>dovecot config</b>: Allows inspecting the parsed configuration, useful for debugging configuration issues.</li><li><b>dovecot auth</b>: A utility for testing authentication against <i>Dovecot</i>'s authentication backends.</li></ul>


title: HISTORY
content:
<i>Dovecot</i> was initially released in 2002, developed primarily by Timo Sirainen. It emerged as a modern alternative to existing IMAP/POP3 servers like UW-IMAP, with a strong emphasis on security, performance, and ease of administration. Its innovative features, such as the optimized dbox mail storage format and robust authentication framework, quickly made it a popular choice. Over its development history, <i>Dovecot</i> has continuously evolved, introducing features like director (for load balancing), replication, and comprehensive Sieve support, solidifying its position as a leading open-source mail server component.


title: SYNOPSIS
content:
<b>doxygen</b> [<i>options</i>] [<i>configuration_file</i>]<br><b>doxygen</b> <b>-g</b> [<i>configuration_file</i>]<br><b>doxygen</b> <b>-u</b> [<i>configuration_file</i>]<br><b>doxygen</b> <b>-x</b> <i>file</i><br><b>doxygen</b> <b>-v</b>


title: PARAMETERS
content:
<b><i>configuration_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Doxygen configuration file (<i>Doxyfile</i>) to be used. If omitted, doxygen looks for a <i>Doxyfile</i> in the current directory.<br><br><b><b>-g</b> [<i>configuration_file</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new, default configuration file (<i>Doxyfile</i>) at the specified path or in the current directory if no path is given. This is often the first step in setting up doxygen for a project.<br><br><b><b>-u</b> [<i>configuration_file</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an existing configuration file. This is useful for adding new configuration options introduced in newer doxygen versions to an older <i>Doxyfile</i>.<br><br><b><b>-x</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts documentation from a single source file and prints it to standard output. This mode is useful for quickly previewing how doxygen interprets comments in a specific file.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs doxygen in quiet mode, suppressing most informational messages and warnings. Useful for scripting or automated build processes where only errors are of interest.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the doxygen executable and exits.<br><br>


title: DESCRIPTION
content:
Doxygen is a comprehensive documentation system widely used in software development to generate API documentation directly from commented source code. It supports numerous programming languages, including <i>C++</i>, <i>C</i>, <i>Java</i>, <i>Objective-C</i>, <i>Python</i>, <i>PHP</i>, <i>C#</i>, <i>Fortran</i>, and others. The primary purpose of doxygen is to keep documentation closely integrated with the code itself, ensuring it stays up-to-date as the codebase evolves.<br><br>Developers embed special documentation blocks within their source files, which doxygen then parses. These blocks typically contain descriptions for classes, functions, variables, and parameters, often using specific commands like <b>@param</b> or <b>@return</b> for structured information. Doxygen can output documentation in various popular formats, such as <i>HTML</i> (for browsing), <i>LaTeX</i> (for high-quality printouts, which can then be converted to <i>PDF</i>), <i>man pages</i>, <i>RTF</i>, and <i>XML</i>. Additionally, if the Graphviz tool is installed, doxygen can automatically generate visual diagrams, including inheritance hierarchies, collaboration graphs, and call graphs, which significantly enhance understanding of the code's structure and relationships. This makes doxygen an invaluable tool for maintaining clear, comprehensive, and accessible project documentation.


title: CAVEATS
content:
Doxygen relies heavily on its configuration file, typically named <i>Doxyfile</i>. Misconfigurations can lead to incomplete or incorrect documentation. Achieving optimal output often requires significant tuning of this file.<br><br>For generating visual diagrams (e.g., call graphs, inheritance charts), the external <i>Graphviz</i> tool must be installed and accessible in the system's PATH. Without it, doxygen will not be able to produce these graphical outputs.<br><br>While highly versatile, doxygen's best results are obtained when source code comments adhere to its specific formatting conventions. Non-standard or poorly structured comments may be ignored or not parsed correctly, leading to missing documentation.<br><br>Processing very large codebases can be time-consuming and resource-intensive, potentially impacting build times in continuous integration environments.


title: THE <I>DOXYFILE</I> CONFIGURATION
content:
The behavior of doxygen is controlled by a configuration file, typically named <i>Doxyfile</i>. This file contains hundreds of configurable options, allowing users to specify input directories, output formats, styling, diagram generation settings, and much more. It is crucial for tailoring doxygen's output to specific project needs. A default <i>Doxyfile</i> can be generated using the <b>doxygen -g</b> command and then edited manually or through a GUI tool like <i>doxywizard</i> (often distributed with doxygen).


title: DOXYGEN SPECIAL COMMANDS
content:
Within the special documentation blocks (e.g., <b>/** ... */</b> in C++), doxygen recognizes various special commands, prefixed with a backslash (<b>\</b>) or an 'at' symbol (<b>@</b>). These commands provide structured information. Examples include <b>\brief</b> or <b>@brief</b> for a short summary, <b>\param</b> or <b>@param</b> for function parameters, <b>\return</b> or <b>@return</b> for return values, and <b>\see</b> or <b>@see</b> for cross-references. Using these commands correctly allows doxygen to parse and present the documentation in a consistent and organized manner across different output formats.


title: HISTORY
content:
Doxygen was created by <i>Dimitri van Heesch</i>, with its first public release in <i>1997</i>. Its inception was largely driven by the desire to have a documentation system for C++ that was similar in functionality to <i>Javadoc</i> for Java, but specifically tailored for C++ and capable of understanding its intricate language features. Over time, doxygen expanded its language support significantly, becoming a leading documentation generator not just for C++, but also for C, Objective-C, Python, PHP, and many other languages.<br><br>It quickly gained popularity in the open-source community and among developers for its ability to integrate documentation directly into the source code, promoting "self-documenting" code. Its continuous development has added numerous features, including advanced output formats, diagram generation, and extensive configuration options, cementing its position as a robust and widely adopted tool for API documentation.


title: PARAMETERS
content:
<b><b>setup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes any existing swap file and creates a new one according to <i>CONF_SWAPSIZE</i> in <i>/etc/dphys-swapfile</i>, then activates it.<br><br><b><b>swapon</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the existing swap file. Does not create or resize it.<br><br><b><b>swapoff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates the current swap file, removing it from active swap space.<br><br><b><b>auto</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs 'setup' if <i>CONF_SWAPSIZE</i> is greater than zero; otherwise, performs 'swapoff'. This is typically used by system init scripts.<br><br>


title: DESCRIPTION
content:
<i>dphys-swapfile</i> is a lightweight script designed to simplify the creation and management of a swap file on Linux systems. It's particularly prevalent in embedded environments like the Raspberry Pi, where it provides an easy way to configure swap space without needing a dedicated swap partition. The utility reads its configuration, primarily the desired swap file size and location, from the <i>/etc/dphys-swapfile</i> configuration file. <br><br>When invoked, <i>dphys-swapfile</i> automates the process of allocating space (using <i>fallocate</i> or <i>dd</i>), formatting it as swap (<i>mkswap</i>), and activating/deactivating it (<i>swapon</i>/<i>swapoff</i>). It integrates well with system startup scripts, often configured to run automatically during boot to ensure the system has adequate virtual memory.


title: CAVEATS
content:
The primary configuration for <i>dphys-swapfile</i> resides in <i>/etc/dphys-swapfile</i>. Changing the <i>CONF_SWAPSIZE</i> variable requires running <b>sudo dphys-swapfile setup</b> or rebooting the system for the changes to take effect. <br><br>While convenient, using a swap file on flash-based storage (like SD cards in Raspberry Pi) can lead to reduced performance due to slower I/O speeds and increased wear on the flash media, potentially shortening its lifespan.


title: CONFIGURATION FILE: /ETC/DPHYS-SWAPFILE
content:
This file contains the key variables that control <i>dphys-swapfile</i> behavior:<br><ul><li><b>CONF_SWAPFILE</b>: The full path to the swap file (e.g., <i>/var/swap</i>).</li><li><b>CONF_SWAPSIZE</b>: The desired size of the swap file in megabytes (MB). A value of 0 effectively disables swap.</li><li><b>CONF_MAXSWAP</b>: (Optional) The maximum allowed swap size, in MB, which can prevent accidental creation of excessively large swap files.</li></ul>


title: TYPICAL USAGE
content:
To change the swap file size, edit <i>/etc/dphys-swapfile</i> and modify the <b>CONF_SWAPSIZE</b> variable (e.g., <i>CONF_SWAPSIZE=2048</i> for 2GB). After saving, run <b>sudo dphys-swapfile setup</b> to apply the changes immediately, or simply reboot your system.


title: HISTORY
content:
<i>dphys-swapfile</i> was developed to simplify swap space management on Linux systems, particularly gaining prominence within the Raspberry Pi ecosystem (Raspberry Pi OS, formerly Raspbian). It emerged as a user-friendly abstraction over more complex low-level utilities like <i>fallocate</i>, <i>dd</i>, <i>mkswap</i>, <i>swapon</i>, and <i>swapoff</i>. Its design aims to provide a consistent and easy way to configure and manage swap files, especially beneficial for single-board computers where dedicated swap partitions are less common.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a help message and exits.</i><br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the version information and exits.</i><br><br><b>-s, --size-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints only the size of packages in kilobytes, omitting their names.</i><br><br><b>-n N, --most-relevant=N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the top <I>N</I> packages by disk usage. Defaults to 10.</i><br><br><b>-H, --no-headers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Omits the column headers (e.g., 'Size', 'Package') from the output.</i><br><br><b>-k, --kilobytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs sizes in kilobytes. This is the default unit for displaying sizes.</i><br><br><b>-m, --megabytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs sizes in megabytes, rounding appropriately.</i><br><br><b>-g, --gigabytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs sizes in gigabytes, rounding appropriately.</i><br><br><b>-G, --generates-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses the 'Installed-Size' value reported by <b>dpkg-query</b> (typically in KiB) instead of summing the actual file sizes on disk. This value represents the uncompressed size of the installed files.</i><br><br><b>--virtual-size</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Equivalent to <b>--generates-size</b>. Uses the 'Installed-Size' reported by <b>dpkg-query</b>.</i><br><br><b>-S, --source</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the source package name instead of the binary package name.</i><br><br>


title: DESCRIPTION
content:
<b>dpigs</b> is a utility included in the <i>debianutils</i> package that analyzes the disk space consumed by installed Debian packages. It queries the <b>dpkg</b> database to identify all installed packages and then calculates their disk usage. By default, it sums the sizes of all files belonging to each package to get an accurate representation of on-disk consumption. The command then lists these packages, sorted by their disk space usage in descending order, making it easy to identify which packages are taking up the most room on a system. This tool is invaluable for disk space management, system analysis, and identifying potential candidates for removal when trying to free up space on Debian-based distributions.


title: CAVEATS
content:
<b>dpigs</b> relies on information from the <b>dpkg</b> database. While generally accurate, the reported sizes might not perfectly match the absolute disk space due to factors like filesystem block sizes, sparse files, or if files are shared between packages. The <b>--generates-size</b> (or <b>--virtual-size</b>) option uses a size reported by <b>dpkg-query</b> which might not reflect actual disk usage if the package's files are heavily compressed on disk or if some package components are not fully accounted for by <b>dpkg</b>. <b>dpigs</b> is specific to Debian's package management system (APT/dpkg) and will not work on other Linux distributions using different package formats (e.g., RPM).


title: CALCULATION METHODS
content:
By default, <b>dpigs</b> calculates package size by summing the actual disk usage of all files associated with an installed package. This provides a realistic estimate of the disk space consumed. <br>Alternatively, when using the <b>--generates-size</b> or <b>--virtual-size</b> option, <b>dpigs</b> uses the 'Installed-Size' value reported by <b>dpkg-query</b>. This value represents the uncompressed size of the package as declared in its control file. While useful for understanding the logical size, it might not always precisely reflect the physical disk space occupied due to filesystem overhead or compression methods.


title: USE CASES
content:
<b>dpigs</b> is primarily used for disk space management, helping users identify which installed packages are consuming the most disk space. This is particularly useful on systems with limited storage or when trying to troubleshoot why disk space is dwindling. It can also help in deciding which packages to uninstall if freeing up space becomes necessary, or simply to understand the overall package footprint on a system.


title: HISTORY
content:
<b>dpigs</b> is a long-standing utility that forms part of the <i>debianutils</i> package, a collection of essential utilities for Debian systems. It has been available in Debian distributions for many years, providing a simple yet effective way for administrators and users to gain insight into package disk consumption, evolving with the Debian ecosystem to remain a relevant tool for system analysis and maintenance.


title: SYNOPSIS
content:
<b>dpkg</b> [<i>option</i>...] <i>command</i><br><b>dpkg</b> {<i>-S | -L | -l | -s | -c | -I | --field | --compare-versions</i>} [<i>package_name</i> | <i>file_path</i> | <i>.deb_file</i>]


title: PARAMETERS
content:
<b><b>-i</b>, <b>--install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install a .deb package archive.<br><br><b><b>-r</b>, <b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove an installed package, leaving configuration files behind.<br><br><b><b>-P</b>, <b>--purge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove an installed package completely, including configuration files.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all installed packages with their status.<br><br><b><b>-s</b>, <b>--status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed status information for an installed package.<br><br><b><b>-L</b>, <b>--listfiles</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all files installed by a given package.<br><br><b><b>-S</b>, <b>--search</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages that own a specific file.<br><br><b><b>--configure</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure an unpacked but unconfigured package.<br><br><b><b>-I</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show information from a .deb package archive.<br><br><b><b>-c</b>, <b>--contents</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents (files) of a .deb package archive.<br><br><b><b>--get-selections</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Get list of package selections for dpkg.<br><br><b><b>--set-selections</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set package selections from a file or standard input.<br><br><b><b>--audit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for broken packages on the system.<br><br>


title: DESCRIPTION
content:
<b>dpkg</b> is the fundamental package management system for Debian-based Linux distributions, including Ubuntu and Linux Mint. It operates at a low level, directly handling the installation, removal, and querying of individual <i>.deb</i> package files. Unlike higher-level tools such as <b>apt</b> or <b>apt-get</b>, <b>dpkg</b> does <i>not</i> automatically resolve or manage package dependencies. This means that if a package you're installing with <b>dpkg</b> requires other packages, you must install those dependencies manually beforehand. This characteristic makes <b>dpkg</b> a powerful but potentially challenging tool if used without care, especially for systems with complex dependency trees.<br><br>While <b>apt</b> is generally preferred for everyday package management due to its dependency resolution capabilities, <b>dpkg</b> remains essential for scenarios like installing a locally downloaded <i>.deb</i> file, querying detailed information about installed packages, or troubleshooting package issues. It provides the core mechanisms upon which higher-level tools are built, making it indispensable for understanding the Debian package ecosystem.


title: CAVEATS
content:
<b>dpkg</b> <i>does not</i> automatically handle package dependencies. Installing a package with <b>dpkg -i</b> that has unmet dependencies will result in a broken package state, requiring manual resolution, often with <b>apt --fix-broken install</b>. Using <b>dpkg</b> directly for significant system changes without understanding dependencies can lead to an unstable system. Most operations require root privileges.


title: <B>PACKAGE STATES</B>
content:
When listing packages with <b>dpkg -l</b> or checking status with <b>dpkg -s</b>, you'll encounter various two-letter codes indicating the package's desired and current state. Common states include:<br><i>ii</i>: (install ok installed) - package is successfully installed.<br><i>rc</i>: (remove ok config-files) - package has been removed, but configuration files remain.<br><i>pn</i>: (purge not-installed) - package has been purged, it's not installed, and no config files remain.<br><i>ri</i>: (remove installed) - package marked for removal, but still installed (broken state).<br><i>un</i>: (unknown not-installed) - package is not installed and its status is unknown.


title: <B>LOCAL .DEB INSTALLATION</B>
content:
<b>dpkg -i <i>/path/to/package.deb</i></b> is the command to install a package downloaded from outside official repositories. Remember to resolve any dependencies manually or use <b>sudo apt --fix-broken install</b> afterwards if dependencies are missing.


title: HISTORY
content:
<b>dpkg</b> is the original package management system for Debian GNU/Linux, developed shortly after the project's inception in the early 1990s. It was designed to manage individual <i>.deb</i> packages. Its core functionality provided the foundation for Debian's robust software ecosystem. The <b>apt</b> (Advanced Package Tool) suite was later developed and introduced to address <b>dpkg</b>'s limitation regarding automatic dependency resolution, making package management much more user-friendly and efficient for complex systems. Despite <b>apt</b>'s widespread use, <b>dpkg</b> remains the underlying engine, essential for low-level package operations and system integrity checks.


title: SEE ALSO
content:
<b>apt(8)</b>, <b>apt-get(8)</b>, <b>dpkg-reconfigure(8)</b>, <b>dpkg-deb(1)</b>, <b>dpkg-query(1)</b>, <b>deb(5)</b>, <b>dselect(8)</b>


title: SYNOPSIS
content:
<I>dpkg-deb</I> <B>command</B> [<I>options</I>]<br><br>Common commands:<br>  <B>dpkg-deb --build</B> <I>directory</I> [<I>archive</I> | <I>directory</I>]<br>  <B>dpkg-deb --extract</B> <I>archive</I> <I>directory</I><br>  <B>dpkg-deb --info</B> <I>archive</I> [<I>control-field</I>...]<br>  <B>dpkg-deb --contents</B> <I>archive</I><br>  <B>dpkg-deb --control</B> <I>archive</I> [<I>directory</I>]


title: PARAMETERS
content:
<b><B>--build</B> <I>directory</I> [<I>archive</I> | <I>directory</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds a Debian package archive from the given <I>directory</I>. The <I>archive</I> argument specifies the output file, or if a <I>directory</I> is given, the package will be placed in that directory with a generated filename.<br><br><b><B>--extract</B> <I>archive</I> <I>directory</I> (or <B>-x</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts all files from <I>archive</I> into the specified <I>directory</I>, preserving ownership and permissions.<br><br><b><B>--x-extract</B> <I>archive</I> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to <B>--extract</B>, but does not preserve file ownership or permissions (i.e., it doesn't chown or chmod extracted files).<br><br><b><B>--info</B> <I>archive</I> [<I>control-field</I>...] (or <B>-I</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information from the control file of <I>archive</I> (e.g., Package, Version, Description). Specific control fields can be requested.<br><br><b><B>--contents</B> <I>archive</I> (or <B>-c</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the files contained within the <I>archive</I> and their permissions, ownership, and size.<br><br><b><B>--control</B> <I>archive</I> [<I>directory</I>] (or <B>-e</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts the control files (e.g., control, preinst, postinst) from the <I>archive</I> into the specified <I>directory</I> (defaults to the current directory).<br><br><b><B>--fsys-tarfile</B> <I>archive</I> (or <B>-f</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extracts the filesystem tarfile portion of the <I>archive</I> to standard output. This is the tarball containing the package's actual data.<br><br><b><B>--conffiles</B> <I>archive</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the conffiles (configuration files) from the <I>archive</I> that are managed by <I>dpkg</I>.<br><br><b><B>--deb-version</B> <I>archive</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Debian package version string from the <I>archive</I> to standard output.<br><br><b><B>--show</B> <I>archive</I> (or <B>-S</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays single-line information about the package: its name, version, and architecture.<br><br><b><B>--showformat</B> <I>format</I> (or <B>-s</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format for the <B>--show</B> command. Uses a printf-like syntax with various item fields.<br><br><b><B>-z</B><I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the compression level (0-9) for the data and control tarfiles when building new packages with <B>--build</B>.<br><br><b><B>-Z</B><I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the compression type for the data and control tarfiles when building new packages with <B>--build</B> (e.g., gzip, xz, zstd, lzma, none).<br><br><b><B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output, providing more verbose information about <I>dpkg-deb</I>'s operations.<br><br><b><B>--root-owner-group</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When extracting files, set the owner and group of extracted files to root. This overrides the original ownership in the archive.<br><br><b><B>--no-ownership</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When extracting files, do not preserve the original owner of extracted files, setting them to the user running the command instead.<br><br><b><B>--no-permissions</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When extracting files, do not preserve the original permissions of extracted files, setting them to the user's umask.<br><br>


title: DESCRIPTION
content:
<I>dpkg-deb</I> is a low-level tool used to manipulate Debian package archives (<I>.deb</I> files). It can build new packages from a package directory, extract files from an existing package, list its contents, or display control information. It acts as an interface to the underlying <I>ar</I> and <I>tar</I> commands, which actually perform the archiving and compression. While <I>dpkg</I> is the primary tool for installing, removing, and managing packages, <I>dpkg-deb</I> is crucial for developers and those needing to inspect or create <I>.deb</I> files directly, offering fine-grained control over the package structure and contents.


title: CAVEATS
content:
<I>dpkg-deb</I> is a low-level utility and does not handle package dependencies or interact with the installed package database. It simply processes the <I>.deb</I> archive file itself. Using it to extract or modify packages requires a good understanding of the Debian package format, and incorrect manipulation can lead to corrupted packages or system instability if not handled carefully. It is typically used by package maintainers or for advanced debugging, not for general package installation or removal.


title: DEBIAN PACKAGE FORMAT
content:
A Debian binary package (<I>.deb</I> file) is essentially an <I>ar</I> archive containing three required members:<br>  1.  A <I>debian-binary</I> file: Contains the version number of the Debian binary package format.<br>  2.  A <I>control.tar</I> archive (can be compressed, e.g., <I>control.tar.xz</I>): Contains control information about the package, such as metadata (name, version, dependencies) and maintainer scripts (preinst, postinst, prerm, postrm).<br>  3.  A <I>data.tar</I> archive (can be compressed, e.g., <I>data.tar.gz</I>): Contains the actual filesystem hierarchy that the package installs.


title: COMPRESSION SUPPORT
content:
<I>dpkg-deb</I> supports various compression methods for the control and data tarballs within a <I>.deb</I> archive. When building packages, the compression type can be specified using the <B>-Z</B> option (e.g., <B>gzip</B>, <B>xz</B>, <B>zstd</B>, <B>lzma</B>, <B>none</B>), and the compression level using the <B>-z</B> option. This flexibility allows package maintainers to balance package size and decompression speed.


title: HISTORY
content:
<I>dpkg-deb</I> is a fundamental component of the Debian packaging system, dating back to its early days. It was designed as a core utility to implement the low-level operations for creating and inspecting <I>.deb</I> files, which serve as the standard package format for Debian and its derivatives like Ubuntu. Its development has closely mirrored the evolution of the Debian project, ensuring strict adherence to the evolving <I>.deb</I> format specification and supporting new compression methods and package features as they were introduced.


title: SYNOPSIS
content:
<b>dpkg-divert</b> [<i>option</i>...] {<i>command</i>}<br><br><i>Commands:</i><br>  <b>--add</b> <i>file</i> [<b>--local</b>] [<b>--divert</b> <i>divert-file</i>]<br>  <b>--remove</b> <i>file</i><br>  <b>--list</b> [<i>file</i>]<br>  <b>--rename</b> <i>old-file</i> <i>new-file</i>


title: PARAMETERS
content:
<b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path to the file that is to be diverted, removed, or listed.<br><br><b><b>--add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new diversion for the specified <i>file</i>. If <b>--divert</b> is not used, the file will be diverted to <i>file</i>.diverted in the same directory.<br><br><b><b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an existing diversion for the specified <i>file</i> from the <i>dpkg</i> database.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently active diversions, or only those for the specified <i>file</i> if provided.<br><br><b><b>--rename</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renames an existing diversion entry from <i>old-file</i> to <i>new-file</i> in the <i>dpkg</i> database and renames the physical diverted file if it exists.<br><br><b><b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--add</b>, marks the diversion as 'local'. This means <i>dpkg</i> will not be aware of the original path, treating the diverted path as the only one it knows for the package's file.<br><br><b><b>--divert</b> <i>divert-file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--add</b>, explicitly specifies the full path to which the file should be diverted. If omitted, the default is to append '.diverted' to the original filename.<br><br><b><b>--no-act</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run. Show what actions would be taken without actually making any changes to the system or <i>dpkg</i> database.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational output, showing only errors or warnings.<br><br>


title: DESCRIPTION
content:
The <b>dpkg-divert</b> command allows a system administrator to override the default location where files are installed by <i>dpkg</i>, the Debian package manager. This is particularly useful for maintaining local versions of files, such as configuration files or binaries, that would otherwise be overwritten by package installations or upgrades. By diverting a file, <b>dpkg-divert</b> instructs <i>dpkg</i> to install the package's version of that file to a different, specified path, leaving the original file at its intended location untouched. It records these diversions in the <i>dpkg</i> status database, ensuring that future package operations respect the diversion. This mechanism helps prevent conflicts and data loss for customized system components, offering flexibility in system configuration management.


title: CAVEATS
content:
<i>Manual File Movement:</i> When adding a diversion for an existing file, <b>dpkg-divert</b> only registers the diversion; you must manually move the existing file to its new diverted path (e.g., from <code>/usr/bin/foo</code> to <code>/usr/bin/foo.diverted</code>). Similarly, removing a diversion does not move the file back.<br><br><i>Critical Files:</i> Exercise extreme caution when diverting critical system files or binaries, as incorrect usage can lead to system instability or breakage.<br><br><i>Global vs. Local:</i> Understand the implications of <b>--local</b> diversions. A 'global' diversion (default) tells <i>dpkg</i> to install to the new path and consider the original path as 'owned' by the system. A 'local' diversion means <i>dpkg</i> will install to the new path, leaving the original path entirely unmanaged by <i>dpkg</i> and free for local use without conflicts.


title: USAGE EXAMPLE
content:
Consider a scenario where you have a customized /etc/bash.bashrc file and wish to prevent a package update from overwriting it:<br><br><i>1. Add a diversion:</i><br>sudo dpkg-divert --local --add /etc/bash.bashrc<br>This command registers a diversion for /etc/bash.bashrc. The package's version will now be installed at /etc/bash.bashrc.diverted. You must then manually move your existing customized file to /etc/bash.bashrc (if it was already there) or keep it at the original location while the package version goes to the diverted path.<br><br><i>2. List diversions:</i><br>dpkg-divert --list /etc/bash.bashrc<br>This will show the active diversion for /etc/bash.bashrc.<br><br><i>3. Remove the diversion:</i><br>sudo dpkg-divert --remove /etc/bash.bashrc<br>This removes the diversion entry from the <i>dpkg</i> database. Note that the diverted file (e.g., /etc/bash.bashrc.diverted) is <b>not</b> automatically moved back to its original path by this command.


title: HISTORY
content:
<b>dpkg-divert</b> is an integral part of the <i>dpkg</i> suite, which has been the foundational package management system for Debian-based distributions since the mid-1990s. The concept of file diversion was introduced early in <i>dpkg</i>'s development to address the need for system administrators to maintain local modifications or alternative versions of files that are also managed by packages, preventing overwrites during upgrades. Its core functionality has remained consistent, evolving primarily through minor enhancements and integration within the broader <i>dpkg</i> ecosystem.


title: PARAMETERS
content:
<b><i>--root=dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate root directory. For internal use by dpkg only, e.g., when building images.<br><br><b><i>rm_conffile old-conffile [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an old conffile (configuration file). This command handles scenarios where a conffile might have been removed or renamed in a new package version. It safely removes the file if it's no longer managed by the package or if it's no longer needed after a specified version. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional removal.<br><br><b><i>mv_conffile old-conffile new-conffile [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Moves an old conffile to a new path. This is crucial when a configuration file changes its location between package versions. It ensures that user modifications are preserved by moving the existing conffile, rather than overwriting it. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional moves.<br><br><b><i>rm_links link-or-dir ... [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes symbolic links that were previously managed by the package but are no longer needed. It can also remove directories that were managed via symlinks. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional removal.<br><br><b><i>rm_diversion diversion-file [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a dpkg diversion. This is used when a package no longer needs to divert a specific file. It ensures the diversion is correctly removed from dpkg's state. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional removal.<br><br><b><i>rm_symlink_to_dir symlink-to-dir [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a symbolic link that points to a directory. This is a specialized version of <i>rm_links</i> for directory symlinks, often used when a directory previously represented by a symlink becomes a real directory. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional removal.<br><br><b><i>install_alternatives alternative-name [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs or updates a symlink managed by the 'alternatives' system. This helps ensure that the package's alternative symlink is correctly set up, especially during upgrades. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional operations.<br><br><b><i>run_command command ... [package-version] [arch]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes an arbitrary command. This command acts as a wrapper, primarily useful for allowing maintainer scripts to run commands conditionally based on package version or architecture. The <i>package-version</i> and <i>arch</i> arguments are optional and used for conditional execution.<br><br>


title: DESCRIPTION
content:
<b>dpkg-maintscript-helper</b> is a utility designed to simplify and standardize common operations within Debian package maintainer scripts (e.g., <i>postinst</i>, <i>prerm</i>, <i>postrm</i>). Its primary goal is to help maintainers manage tasks like moving or removing configuration files, symbolic links, or diversions safely and robustly during package upgrades or removals. <br><br>Before its introduction, maintainers often had to write complex and error-prone shell logic to handle various upgrade scenarios, leading to potential package breakage or orphaned files. This helper provides idempotent commands that check the current state before performing actions, ensuring that operations are carried out only when necessary and can be safely re-run multiple times (e.g., during re-installation or interrupted upgrades). <br><br>By standardizing these common routines, <b>dpkg-maintscript-helper</b> significantly reduces the complexity and error rate of maintainer scripts, making Debian packages more reliable and easier to upgrade for users. It is an essential tool for robust package maintenance in the Debian ecosystem.


title: CAVEATS
content:
<I>Idempotency is Key</I>: All commands provided by <b>dpkg-maintscript-helper</b> are designed to be idempotent. This means they can be safely called multiple times without adverse effects, even if the desired state has already been achieved. Maintainer scripts should leverage this property and not add complex checks to avoid re-running commands.<br><br><I>Context of Use</I>: This utility is strictly intended for use within Debian package maintainer scripts (e.g., <i>postinst</i>, <i>prerm</i>, <i>postrm</i>). It relies on the environment and state managed by <i>dpkg</i> during package operations.<br><br><I>Version Argument Usage</I>: When specifying <i>package-version</i> and <i>arch</i>, these arguments are used to make operations conditional. The action will only be performed if the installed version of the package (or the old version during removal) is less than or equal to the <i>package-version</i> provided. This is crucial for handling staggered upgrades across different package versions.<br><br><I>Error Handling</I>: The command exits with a non-zero status if an error occurs. Maintainer scripts should check the exit status and handle errors appropriately.<br><br><I>Integration with dpkg</I>: Be cautious when mixing <b>dpkg-maintscript-helper</b> calls with direct <b>dpkg-divert</b> or <b>update-alternatives</b> calls, as the helper aims to provide a safer, version-aware wrapper for some of those functionalities.


title: VERSION ARGUMENTS EXPLAINED
content:
Most sub-commands accept optional <i>package-version</i> and <i>arch</i> arguments. When provided, the command will only execute if the currently installed package version (or the original package version during a removal) is less than or equal to the specified <i>package-version</i>. This allows maintainer scripts to apply changes incrementally across different package versions, ensuring that an operation for an older version is not accidentally applied to a system that has already passed that version, or vice-versa. The <i>arch</i> argument provides an additional layer of conditionality based on architecture, useful for multi-arch packages.


title: ROLE IN MAINTAINER SCRIPTS
content:
<b>dpkg-maintscript-helper</b> is primarily invoked from within the <i>postinst</i>, <i>prerm</i>, and <i>postrm</i> scripts of a Debian package. For instance, <i>rm_conffile</i> is typically called in <i>postinst</i> during an upgrade to clean up old conffiles, or in <i>postrm</i> during removal to ensure a clean uninstall. The helper handles the complexities of <i>dpkg</i>'s internal state and ensures that operations are performed correctly based on the upgrade scenario (e.g., install, upgrade, remove, purge).


title: HISTORY
content:
<b>dpkg-maintscript-helper</b> was introduced to address common challenges and pitfalls faced by Debian package maintainers when writing maintainer scripts. Historically, operations like migrating configuration files or removing old symlinks required maintainers to write complex, error-prone shell logic to handle various upgrade paths, including interrupted upgrades or downgrades. This often led to orphaned files, broken packages, or inconsistent system states. <br><br>By providing a set of standardized, idempotent, and version-aware sub-commands, <b>dpkg-maintscript-helper</b> significantly simplified script development and improved the robustness of package upgrades across the Debian distribution. Its development was driven by the need to reduce common bugs and ensure smoother transitions between package versions, making the Debian packaging ecosystem more reliable.


title: SYNOPSIS
content:
`dpkg-preconfigure [options] package...`<br><br><i>Note: Most configuration behavior is controlled via debconf environment variables rather than direct command-line options for `dpkg-preconfigure` itself.</i>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
dpkg-preconfigure is a utility used within the Debian package management system to interact with <i>debconf</i>. Its primary purpose is to ask configuration questions for packages <b>before</b> their installation or upgrade. This is crucial for enabling non-interactive installations, particularly in automated environments or scripts.<br><br>When a package is installed, it may need user input for various settings (e.g., time zone, default services, network configurations). <i>debconf</i> handles these questions using templates defined by the package. dpkg-preconfigure orchestrates this process: it reads these templates, presents the questions via a chosen frontend (e.g., dialog, readline, noninteractive), and stores the answers in the <i>debconf</i> database. This pre-configuration ensures that the actual `dpkg` installation step does not halt waiting for user input, making the entire process smoother and scriptable. It is typically called by higher-level tools like `apt` or `apt-get` as part of their installation routines.


title: CAVEATS
content:
dpkg-preconfigure relies heavily on the <i>DEBIAN_FRONTEND</i> environment variable to determine how it interacts with the user (e.g., `noninteractive`, `dialog`, `readline`). If <i>DEBIAN_FRONTEND</i> is set to `noninteractive`, <i>debconf</i> will use default answers or previously stored answers, leading to fully automated installations.<br><br>It only preconfigures packages that haven't been configured before or whose configuration templates have changed. It won't re-ask questions if satisfactory answers are already stored in the <i>debconf</i> database.<br><br>This command does <b>not</b> install the packages; it only performs the configuration questioning phase. The actual installation is handled by `dpkg`.


title: ENVIRONMENT VARIABLES
content:
The behavior of `dpkg-preconfigure` is largely influenced by <i>debconf</i> environment variables:<br><i>DEBIAN_FRONTEND</i>: Controls the type of user interface <i>debconf</i> uses. Common values include `dialog` (default interactive text-based), `readline` (more basic text input), `noninteractive` (no prompts, uses defaults or pre-existing answers), `gnome`, `kde`, `newt`, `web`. Setting this to `noninteractive` is vital for unattended installations.<br><i>DEBCONF_NONINTERACTIVE_SEEN</i>: Can be set to 'true' to indicate that <i>debconf</i> should suppress certain warnings or interactive prompts related to non-interactive mode. Typically used in conjunction with <i>DEBIAN_FRONTEND=noninteractive</i>.


title: TYPICAL WORKFLOW
content:
While you can run `dpkg-preconfigure` manually, it's most commonly invoked automatically by `apt` or `apt-get`. When you run `apt-get install mypackage`, `apt-get` often performs these steps internally (simplified):<br>1. Calls `dpkg-preconfigure mypackage` to collect configuration answers.<br>2. Calls `dpkg --install mypackage.deb` using the pre-configured answers.<br>This ensures a seamless installation without interruptions, even if `mypackage` requires input.


title: HISTORY
content:
dpkg-preconfigure emerged as a crucial component of the Debian package management ecosystem alongside <i>debconf</i>. <i>debconf</i> was introduced to standardize and streamline package configuration, moving away from disparate shell scripts for prompting users. dpkg-preconfigure specifically addressed the need to collect configuration answers <b>before</b> the package installation process itself, enabling robust automation and consistent deployment, especially in server environments where interactive prompts are undesirable. Its role has remained consistent since its inception as a bridge between the high-level package management tools (`apt`, `apt-get`) and the low-level <i>debconf</i> configuration system.


title: SYNOPSIS
content:
<i><code>dpkg-query</code></i> [<I>option</I> ...] [<I>package-name-pattern</I> ...]<br><br>Common usage patterns include:<br><i><code>dpkg-query -l</code></i> [<I>package-name-pattern</I> ...]<br><i><code>dpkg-query -s</code></i> <I>package-name-pattern</I> ...<br><i><code>dpkg-query -L</code></i> <I>package-name</I> ...<br><i><code>dpkg-query -S</code></i> <I>filename-pattern</I> ...<br><i><code>dpkg-query -W</code></i> [<I>package-name-pattern</I> ...]<br><i><code>dpkg-query -f</code></i> <I>format</I>


title: PARAMETERS
content:
<b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all known packages, or those matching the pattern, with their status (e.g., installed, removed).<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -l.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed status information for the specified packages, including version, architecture, and description.<br><br><b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -s.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the files installed by the specified package(s). Requires exact package names.<br><br><b>--listfiles</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -L.<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages that own files matching the given pattern(s). Useful for identifying which package provided a specific file.<br><br><b>--search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -S.<br><br><b>-W</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the package name and version for packages matching the pattern. Offers a more concise output than -l.<br><br><b>--show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -W.<br><br><b>-f <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for --show or --status using printf-like syntax and field names.<br><br><b>--showformat=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Long form of -f. Allows custom output.<br><br><b>--searchformat=<format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to --showformat, but for --search output.<br><br><b>--admindir=<directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the administrative directory where dpkg's database files are stored. Defaults to <i>/var/lib/dpkg</i>.<br><br><b>--root=<directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the root directory for all operations. This can be used to query packages on a different system or chroot.<br><br>


title: DESCRIPTION
content:
<i>dpkg-query</i> is a command-line utility integral to the Debian package management system. It provides a robust interface for querying information about packages installed on a system managed by <i>dpkg</i>. Unlike <i>dpkg</i> itself, <i>dpkg-query</i> is primarily used for <b>reading</b> information from the package database, meaning it doesn't modify the system's package state. This makes it a safe and frequently used tool for scripts and users needing to ascertain package presence, retrieve version numbers, list files belonging to an installed package, or identify which package owns a specific file. It's an indispensable component for system administrators and developers working within Debian-based environments, offering detailed insights into the installed software landscape without the overhead of higher-level tools like <i>apt</i>.


title: CAVEATS
content:
<i>dpkg-query</i> operates solely on the local dpkg database (typically found in <i>/var/lib/dpkg</i>). It does not consult APT's caches, nor does it interact with remote package repositories. Therefore, it cannot list packages that are available but not installed, or provide information about package dependencies unless those dependencies are explicitly listed in the package's control file data within the local database. Its output relies entirely on the integrity and currency of the local dpkg database.


title: PACKAGE STATUS CODES
content:
When using <i>-l</i> or <i>-s</i>, <i>dpkg-query</i> displays status flags. The first three characters indicate the desired, current, and installed status respectively.<br><br><b>Desired State:</b><br><i>u</i> = Unknown<br><i>i</i> = Install<br><i>h</i> = Hold<br><i>r</i> = Remove/Purge<br><br><b>Current State:</b><br><i>n</i> = Not installed<br><i>i</i> = Installed<br><i>c</i> = Config-files (only config files exist)<br><i>u</i> = Unpacked<br><i>f</i> = Half-configured<br><i>h</i> = Half-installed<br><i>w</i> = Work-queue (awaiting processing)<br><br><b>Error State:</b><br><i>R</i> = Reinst-required (package broken, needs reinstallation)


title: EXIT STATUS
content:
<i>dpkg-query</i> returns an exit status of <i>0</i> on success. An exit status of <i>1</i> indicates that no packages matched the specified patterns or some requested information could not be retrieved. A status of <i>2</i> signifies a fatal error, such as invalid command line options or an inability to access the dpkg database.


title: HISTORY
content:
<i>dpkg-query</i> is a core utility within the <i>dpkg</i> package management system, which was originally created for Debian GNU/Linux in 1993 by Ian Murdock and others. As Debian's foundational package tool, <i>dpkg</i> and its sub-utilities like <i>dpkg-query</i> have continuously evolved. <i>dpkg-query</i> was designed to provide a robust and efficient way to read the package database without altering its state, a functionality crucial for both system scripts and interactive user queries. Its development has focused on enhancing output flexibility (e.g., with <i>--showformat</i>) and improving query performance, ensuring it remains a staple for package information retrieval in Debian and its derivatives.


title: SYNOPSIS
content:
<b>dpkg-reconfigure</b> [<I>option</I>...] <I>package</I>...<br><br>Common options:<br><b>--frontend=</b><I>frontend-name</I><br><b>--priority=</b><I>priority</I><br><b>--no-defaults</b><br><b>--force</b>


title: PARAMETERS
content:
<b>package...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more names of installed packages to reconfigure. These are the packages whose configuration scripts will be re-executed.<br><br><b><b>--frontend=</b><I>frontend-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <I>debconf</I> frontend to use for presenting questions. Popular choices include <I>dialog</I> (default, curses-based), <I>readline</I> (command-line), <I>noninteractive</I> (uses defaults without interaction), <I>editor</I> (opens questions in an editor), and <I>gnome</I>/<I>kde</I> (graphical).<br><br><b><b>--priority=</b><I>priority</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the minimum priority of questions to display. Valid priorities are <I>low</I>, <I>medium</I>, <I>high</I>, and <I>critical</I>. By default, only important questions (<I>high</I> priority) are shown, suppressing less critical or trivial prompts.<br><br><b><b>--no-defaults</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <I>debconf</I> to not use the default answers for questions. This forces the user to explicitly answer every question, even if a sensible default exists.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force reconfiguration even if <I>debconf</I> thinks the package is already configured, or if there are warnings during the process.<br><br><b><b>-p</b>, <b>--priority=</b><I>priority</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shorthand alias for <b>--priority</b>.<br><br><b><b>-f</b>, <b>--frontend=</b><I>frontend-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shorthand alias for <b>--frontend</b>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information and exit.<br><br>


title: DESCRIPTION
content:
<b>dpkg-reconfigure</b> is a utility that allows system administrators to reconfigure an already installed Debian package. When a package is installed, its <I>postinst</I> script (post-installation script) often uses the <I>debconf</I> system to ask questions and configure various settings, such as network interfaces, service ports, or timezone information.<br><br><b>dpkg-reconfigure</b> essentially re-runs this configuration step for the specified package(s), presenting the same questions as during the initial installation. This is useful for changing settings after installation, recovering from a corrupted <I>debconf</I> database, or automating configuration in scripts by combining it with <I>debconf-set-selections</I>. It provides a consistent interface for adjusting package-specific options without needing to reinstall the package or manually edit configuration files. It is an integral part of the <I>dpkg</I> suite of tools, deeply integrated with <I>debconf</I>.


title: CAVEATS
content:
<ul><li>Requires root privileges (or <I>sudo</I>) to execute, as it modifies system-wide package configurations.</li><li>Only works for packages that are already installed on the system. It cannot install, upgrade, or remove packages.</li><li>Relies heavily on the <I>debconf</I> system. If a package's post-installation script does not utilize <I>debconf</I> for configuration, <b>dpkg-reconfigure</b> may have no effect or offer no interactive questions.</li><li>Some packages may not have any configurable options or may configure themselves automatically without user intervention, even if they use <I>debconf</I>.</li><li>It does not guarantee that all configuration files will be automatically updated; some manual intervention might still be required for complex changes not covered by <I>debconf</I> questions.</li></ul>


title: INTERACTION WITH DEBCONF
content:
<b>dpkg-reconfigure</b> primarily acts as a wrapper around a package's configuration script, which is typically its <I>postinst</I> script. This script, when executed by <b>dpkg-reconfigure</b>, interacts with the <I>debconf</I> system. <I>debconf</I> is responsible for presenting questions to the user (via the chosen frontend), storing the answers, and providing them back to the configuration script. This separation allows for flexible configuration (interactive, non-interactive, pre-seeded) and ensures consistency.


title: COMMON USE CASES
content:
This command is frequently used for:<br><ul><li>Changing the timezone (e.g., <I>sudo dpkg-reconfigure tzdata</I>).</li><li>Reconfiguring locales (e.g., <I>sudo dpkg-reconfigure locales</I>).</li><li>Adjusting keyboard layouts (e.g., <I>sudo dpkg-reconfigure keyboard-configuration</I>).</li><li>Modifying critical server settings (e.g., for <I>postfix</I>, <I>apache2</I>, <I>mysql-server</I>) after initial setup.</li><li>Repairing a configuration where <I>debconf</I> state might be inconsistent or corrupted.</li></ul>


title: HISTORY
content:
<b>dpkg-reconfigure</b> is an essential component of the Debian package management system, <I>dpkg</I>, which was first developed in the mid-1990s as the foundational tool for managing <I>.deb</I> packages. While <I>dpkg</I> itself handles the low-level package installation and removal, the need for a standardized, user-friendly way to configure packages post-installation led to the development of <I>debconf</I> in the early 2000s. <b>dpkg-reconfigure</b> was specifically designed to leverage <I>debconf</I>, providing a convenient interface to re-run the configuration scripts of installed packages. Its functionality has remained largely consistent since its introduction, serving as a critical utility for system administrators to adjust package settings without needing to reinstall or manually edit numerous configuration files, thereby standardizing the configuration process across the Debian ecosystem.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--deb-args</b> <i>&lt;arguments&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Pass additional arguments directly to the <b>dpkg-deb</b> command.</i><br><br><b><b>-a</b>, <b>--arch</b> <i>&lt;architecture&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the detected architecture for the package. Useful for cross-architecture scenarios.</i><br><br><b><b>-m</b>, <b>--maintainer</b> <i>&lt;email&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the maintainer email address in the package's control file.</i><br><br><b><b>-r</b>, <b>--root</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an alternative root directory from which to extract files (e.g., for a chroot environment).</i><br><br><b><b>-s</b>, <b>--section</b> <i>&lt;section&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the package's section (e.g., "utils", "net") in the control file.</i><br><br><b><b>-p</b>, <b>--priority</b> <i>&lt;priority&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Override the package's priority (e.g., "optional", "extra") in the control file.</i><br><br><b><b>--md5sums</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force the generation of <b>md5sums</b> in the package's control file, even if <b>dpkg-deb</b> might skip it.</i><br><br><b><b>--no-md5sums</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevent the generation of <b>md5sums</b>. This is often the default behavior for newer <b>dpkg-deb</b> versions.</i><br><br><b><b>--generate-control</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Only generate the control file for the package; do not create the full <b>.deb</b> archive. Useful for debugging.</i><br><br><b><b>--tag</b> <i>&lt;tag-string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Add a custom tag string to the generated <b>.deb</b> filename (e.g., <b>package_tag.deb</b>).</i><br><br><b><b>--confdir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an alternative directory for <b>dpkg-repack</b>'s configuration files.</i><br><br><b><b>--excludes</b> <i>&lt;patterns&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>A comma-separated list of shell patterns for files or directories to exclude from the generated package.</i><br><br><b><b>--keep-extras</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not delete temporary extra files created in the control archive after package creation.</i><br><br><b><b>--extra-dist-files</b> <i>&lt;files&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>A comma-separated list of additional files to include in the <b>debian/dist</b> directory within the package.</i><br><br><b><b>--no-conf-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not include conffiles (configuration files) in the generated package.</i><br><br><b><b>--tmpdir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an alternative temporary directory for <b>dpkg-repack</b>'s operations.</i><br><br><b><b>--list-installed-packages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List all installed packages on the system and exit.</i><br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display version information for <b>dpkg-repack</b>.</i><br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display a help message and exit.</i><br><br>


title: DESCRIPTION
content:
<b>dpkg-repack</b> is a powerful utility that allows you to recreate a Debian package (a <i>.deb</i> file) from a package that is already installed on your system. This command is invaluable in scenarios where the original <i>.deb</i> file has been lost, but you need to reinstall the package, transfer it to another machine, or simply create a backup. <br><br>It works by inspecting the files currently installed on the filesystem that belong to the specified package, along with the package's metadata stored in <b>dpkg</b>'s status database. It then bundles these components into a new <i>.deb</i> archive, closely resembling the original package. While it recreates the package, it's important to note that it packages the *currently installed state*, including any modifications made to non-conffiles. It does not re-resolve dependencies, but rather includes the dependency information as it was recorded for the installed package. <br><br>The generated <i>.deb</i> file typically includes the package's binaries, libraries, documentation, and configuration files (conffiles), making it a self-contained unit for reinstallation.


title: CAVEATS
content:
<b>dpkg-repack</b> recreates a package based on its *current* installed state. This means if any files belonging to the package have been modified (e.g., config files not properly marked as conffiles, or manual changes to binaries), those modifications will be included in the new <i>.deb</i>. <br><br>It does not attempt to resolve or verify dependencies during repackaging; it simply carries over the dependency information from the original package's control file. <br><br>While generally robust, it may encounter issues with very complex packages that rely heavily on pre/post-installation scripts, specific kernel modules, or intricate hooks that are not easily reproducible through file extraction alone. It relies on a healthy <b>dpkg</b> status database for accurate package information.


title: USAGE EXAMPLES
content:
To repackage a single installed package, run: <br><code>sudo dpkg-repack <i>&lt;package-name&gt;</i></code><br><br>For example: <br><code>sudo dpkg-repack apache2</code><br><br>To repackage multiple packages: <br><code>sudo dpkg-repack apt firefox-esr</code><br><br>The generated <i>.deb</i> files will typically be placed in the current working directory from where the command was executed.


title: OUTPUT FILE NAMING
content:
The recreated <i>.deb</i> file will follow the standard Debian naming convention: <i>packagename_version_architecture.deb</i>. For instance, repackaging 'apache2' might result in a file named <i>apache2_2.4.52-1ubuntu4.7_amd64.deb</i>.


title: HISTORY
content:
<b>dpkg-repack</b> has been a long-standing utility in the Debian/Ubuntu ecosystem, designed to address the practical need for creating distributable <i>.deb</i> archives from installed software. It's written in Perl and maintained as part of the Debian project's toolchain. Its development has focused on maintaining compatibility with evolving <b>dpkg</b> standards and improving its robustness in handling various package types and system configurations. Its core functionality of snapshotting an installed package into a portable <i>.deb</i> file has remained consistent since its inception.


title: SYNOPSIS
content:
<b>dpkg-split</b> [<i>option</i>...] <i>command</i><br><b>dpkg-split --split</b> [<i>option</i>...] <i>binary-package</i> [<i>output-part-name</i>...]<br><b>dpkg-split --merge</b> [<i>option</i>...] <i>input-part</i>...


title: PARAMETERS
content:
<b><b>--split</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the command to split a binary package into multiple parts.<br><br><b><b>--merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the command to merge parts of a binary package back into a complete binary package.<br><br><b><b>-S</b> <i>size</i>, <b>--part-size</b> <i>size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum size for each output part. The <i>size</i> can be specified with optional suffixes like 'K', 'M', or 'G' for kilobytes, megabytes, or gigabytes, respectively.<br><br><b><b>-o</b> <i>directory</i>, <b>--output</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output directory where the split parts will be saved or where the merged <i>.deb</i> file will be created.<br><br><b><b>-a</b>, <b>--auto</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When splitting, automatically determines the base name for the output parts. When merging, automatically finds all necessary parts based on the metadata in the <i>.info</i> file.<br><br><b><b>-b</b> <i>name</i>, <b>--base-name</b> <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the base name to be used for the generated split parts. This option overrides the default base name derived from the input package.<br><br><b><b>--msdos</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses MS-DOS compatible file naming conventions for the split parts and info file, useful when transferring to or from DOS/Windows systems.<br><br><b><b>--large-file</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permits handling of files larger than 2GB. This option is largely deprecated as modern systems typically support large files by default.<br><br><b><b>--info-file</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the path to the <i>.info</i> file for merging. Usually, this is implicitly found when using <b>--auto</b> or providing part names.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br>


title: DESCRIPTION
content:
<b>dpkg-split</b> is a utility included with the <b>dpkg</b> package management system, primarily used in Debian-based Linux distributions. Its core function is to divide large Debian binary package files (with the <i>.deb</i> extension) into smaller, more manageable parts, and conversely, to reassemble these parts back into the original <i>.deb</i> file.<br><br>This command is particularly useful in scenarios where the original package file is too large to be easily transferred across networks with bandwidth limitations, stored on certain types of removable media (historically, floppy disks), or when dealing with file system limitations on size. When splitting, <b>dpkg-split</b> intelligently names the output parts (e.g., <i>package.deb.1of3</i>, <i>package.deb.2of3</i>) and generates a crucial <i>.info</i> file that contains metadata necessary for successful reconstruction. The process is designed to maintain the integrity of the package across its split parts. For merging, users provide the split parts and the <i>.info</i> file, allowing <b>dpkg-split</b> to meticulously reconstruct the complete <i>.deb</i> file. It's a specialized tool for <i>.deb</i> archives, not a general-purpose file splitter.


title: CAVEATS
content:
<ul><li><b>dpkg-split</b> is a specialized tool for Debian <i>.deb</i> packages. It is not a general-purpose file splitting utility; for splitting arbitrary files, consider using the <b>split(1)</b> and <b>cat(1)</b> commands.</li><li>Both splitting and merging operations require sufficient free disk space, as they temporarily duplicate the package data during processing.</li><li>The <i>.info</i> file generated during the splitting phase is critical for successful merging. Loss or corruption of this file will likely prevent proper reassembly of the package.</li><li>When splitting, carefully choose the <i>part-size</i> to ensure the resulting segments fit the target storage medium or meet network transfer requirements.</li></ul>


title: HISTORY
content:
<b>dpkg-split</b> is an integral component of the <b>dpkg</b> suite, the foundational package management system for Debian and its derivatives. Its development emerged from the practical challenges of distributing large software packages in earlier computing eras, particularly when storage media like floppy disks imposed severe size constraints. The utility's design emphasizes robust package integrity across multiple physical parts, a critical requirement for a reliable package management system. While the original drivers for its use (e.g., floppy disk distribution) have largely faded, <b>dpkg-split</b> remains valuable for specific modern scenarios, such as transferring exceptionally large packages over unreliable networks, or accommodating storage systems with restrictive file size limitations.


title: SYNOPSIS
content:
<b>dpkg-statoverride</b> [<i>option...</i>] <i>command</i><br><b>dpkg-statoverride --list</b><br><b>dpkg-statoverride --add</b> <i>&lt;owner&gt; &lt;group&gt; &lt;mode&gt; &lt;file&gt;</i><br><b>dpkg-statoverride --del</b> <i>&lt;file&gt;</i><br><b>dpkg-statoverride --force --add</b> <i>&lt;owner&gt; &lt;group&gt; &lt;mode&gt; &lt;file&gt;</i>


title: PARAMETERS
content:
<b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists</i> all current stat overrides that are registered with <b>dpkg</b>.<br><br><b><b>--add</b> <i>&lt;owner&gt; &lt;group&gt; &lt;mode&gt; &lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new stat override for the specified <i>&lt;file&gt;</i>. <i>&lt;owner&gt;</i> can be a numeric UID or user name, <i>&lt;group&gt;</i> a numeric GID or group name, and <i>&lt;mode&gt;</i> an octal permission mode (e.g., <i>0755</i>).<br><br><b><b>--del</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the stat override entry for the specified <i>&lt;file&gt;</i> from the list.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--add</b> to force the addition of an override even if an entry for the specified <i>&lt;file&gt;</i> already exists, overwriting the old one.<br><br><b><i>&lt;owner&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired owner for the <i>&lt;file&gt;</i>. Can be a username or a numeric UID.<br><br><b><i>&lt;group&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired group for the <i>&lt;file&gt;</i>. Can be a group name or a numeric GID.<br><br><b><i>&lt;mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired permission mode for the <i>&lt;file&gt;</i>, expressed in octal notation (e.g., <i>0644</i> for rw-r--r--).<br><br><b><i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path to the file for which the override should be applied or removed.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the program version and exits.<br><br>


title: DESCRIPTION
content:
<b>dpkg-statoverride</b> is a utility within the <i>Debian package management system</i> (<b>dpkg</b>) used to manage a persistent list of file permission and ownership overrides. When a package is installed or upgraded, <b>dpkg</b> checks this list. If a file owned by the package matches an entry in the <i>statoverride list</i>, <b>dpkg</b> will apply the specified owner, group, and permission mode to that file, rather than using the default values defined by the package itself.<br><br>This is particularly useful for system administrators who need to customize file permissions for security reasons or specific system configurations without having their changes reverted during package updates. It ensures that local modifications to critical file attributes are maintained across package operations. The command allows adding, deleting, and listing these overrides.


title: CAVEATS
content:
Overrides are applied by <b>dpkg</b> only when a package <i>modifies</i> or <i>installs</i> the specified file. If a file is not touched by a package operation, the override will not be re-applied. <br>Careless use can lead to security vulnerabilities or system instability if incorrect permissions are set. <br>The <i>statoverride</i> list is stored in <b>/var/lib/dpkg/statoverride</b> and should <i>not</i> be manually edited; <b>dpkg-statoverride</b> is the designated tool for its management.


title: CONFIGURATION FILE
content:
All stat override entries are persistently stored in the file <b>/var/lib/dpkg/statoverride</b>. It is crucial to manage this file exclusively using the <b>dpkg-statoverride</b> command to ensure its integrity and prevent corruption of the override database.


title: APPLICATION TIMING
content:
The specified overrides are not applied immediately upon creation with <b>dpkg-statoverride</b>. Instead, they are applied by the <b>dpkg</b> daemon when it processes package files that match an override entry during installation, upgrade, or unpacking operations. This ensures that the correct permissions and ownership are set when the files are deployed or updated.


title: HISTORY
content:
<b>dpkg-statoverride</b> is an integral part of the <b>dpkg</b> package management suite, primarily used in Debian-based operating systems. Its functionality has been stable for a significant period, addressing the long-standing need for system administrators to maintain specific file attribute customizations (ownership and permissions) across package installations and upgrades, preventing their local changes from being inadvertently overwritten by package defaults.


title: SYNOPSIS
content:
<b>dpkg-trigger</b> [<i>option</i>...] <i>trigger-name</i><br><b>dpkg-trigger</b> [<i>option</i>...] <b>--trigger-file=</b><i>trigger-file</i><br><b>dpkg-trigger</b> <b>--help</b> | <b>--version</b>


title: PARAMETERS
content:
<b><b>--by-package=</b><i>&lt;package-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Associates the triggered event with a specific package. This is commonly used by maintainer scripts to declare which package is 'responsible' for triggering the event.<br><br><b><b>--no-act</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run; do not actually trigger anything, but show what would be done if the command were executed normally.<br><br><b><b>--admindir=</b><i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the administrative directory where <i>dpkg</i> stores its state information. Defaults to <i>/var/lib/dpkg</i>.<br><br><b><b>--root=</b><i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a different root directory. This makes <i>dpkg-trigger</i> behave as if <i>directory</i> were the system's root directory.<br><br><b><b>--trigger-file=</b><i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of specifying a trigger name (which implies an 'interest' trigger), provide the full path to a specific trigger file to be activated. This is generally used for 'activate' triggers.<br><br><b><b>--activate-awfully</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force trigger activation, even if dependencies or other conditions are not met. Use with extreme caution as this can lead to system inconsistencies.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the operations being performed.<br><br><b><b>-?</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <i>dpkg-trigger</i> version information and exit.<br><br>


title: DESCRIPTION
content:
<i>dpkg-trigger</i> is a utility within the <i>dpkg</i> package management system, designed to allow programs to manually activate <i>dpkg</i> triggers. <i>dpkg</i> triggers are a mechanism used by packages to declare that certain actions (e.g., updating font caches, rebuilding initramfs images, generating menu files) should be performed after specific events, often involving other packages or system state changes.<br><br>While <i>dpkg</i> automatically handles these triggers during package installation, removal, or configuration, <i>dpkg-trigger</i> provides a direct interface to signal such events. This is particularly useful for package maintainer scripts that might perform operations affecting other packages or requiring a trigger to run outside the standard <i>dpkg</i> transaction flow. By allowing explicit triggering of events, <i>dpkg-trigger</i> helps ensure system consistency and correct post-installation behavior, even when manual interventions or complex interactions between packages occur.


title: CAVEATS
content:
Requires sufficient privileges (typically root) to modify <i>dpkg</i>'s administrative files.<br><br>Misuse can lead to an inconsistent package database or unexpected system behavior, especially when using <b>--activate-awfully</b>.<br><br>Primarily intended for use by package maintainer scripts or system administrators debugging package-related issues, not for routine end-user interaction.


title: TRIGGER TYPES
content:
<i>dpkg</i> triggers operate on two main types: <b>interest</b> and <b>activate</b>. <b>Interest</b> triggers are declared by packages that are 'interested' in a specific event or file change (e.g., <i>interest-noawait fontconfig</i>). When such an event occurs (often signaled by another package's maintainer script using <i>dpkg-trigger</i>), <i>dpkg</i> notes this interest. Later, when <i>dpkg</i> processes triggers, it runs those that have been marked as 'interested'. <b>Activate</b> triggers are direct calls to run a specific trigger file, often used for critical system-wide operations that need immediate attention or specific handling.


title: EXIT STATUS
content:
<i>dpkg-trigger</i> exits with 0 on success. Any other exit code indicates an error, such as invalid arguments, insufficient permissions, or internal processing failures.


title: HISTORY
content:
The concept of triggers was introduced to <i>dpkg</i> to provide a more robust and flexible mechanism for post-installation/removal actions compared to simple maintainer script dependencies. <i>dpkg-trigger</i> emerged as a dedicated tool to allow precise and programmatic interaction with this trigger system, enabling maintainer scripts to signal events that might require other packages' triggers to run. Its development paralleled the refinement of the <i>dpkg</i> trigger mechanism itself, making it an integral part of complex package interactions in Debian-based systems.


title: PARAMETERS
content:
<b>-H, --host-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates an <i>initramfs</i> image specifically for the current host's hardware, including only modules and files needed for the running system. This typically results in a smaller image.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>dracut</b> to overwrite an existing <i>initramfs</i> image with the same name.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output during the image generation process, showing more details about what <b>dracut</b> is doing.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output from <b>dracut</b>, only showing critical errors or warnings.<br><br><b>-k, --kver &lt;kernel_version&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the kernel version for which the <i>initramfs</i> image should be built. If omitted, it defaults to the currently running kernel version.<br><br><b>-o, --omit &lt;modules&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of <b>dracut</b> modules to explicitly omit from the generated <i>initramfs</i>, even if they would normally be included.<br><br><b>-a, --add &lt;modules&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of <b>dracut</b> modules to explicitly add to the generated <i>initramfs</i>, even if not automatically detected.<br><br><b>-N, --no-compress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the compression of the resulting <i>initramfs</i> image. This results in a larger file but can sometimes speed up boot times by avoiding decompression overhead.<br><br><b>--list-modules</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a list of all available <b>dracut</b> modules along with a brief description for each.<br><br><b>--regenerate-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to regenerate all <i>initramfs</i> images found in <i>/boot</i> for all installed kernel versions.<br><br>


title: DESCRIPTION
content:
The <b>dracut</b> command is a utility used to create an <i>initramfs</i> (initial RAM filesystem) image. This image is a compressed archive containing a minimal root filesystem and essential kernel modules, tools, and scripts. It is loaded by the Linux kernel very early in the boot process, allowing the system to access and mount the actual root filesystem, especially when it's located on complex storage setups like LVM, encrypted volumes, software RAID, or network-based storage (e.g., iSCSI, NFS).<br><br><b>dracut</b> is designed to be highly modular and uses shell scripts for its functionality, making it flexible and extensible. It automatically detects the necessary kernel modules and components required for the specific host system, thereby creating an <i>initramfs</i> image tailored to that machine. This modular approach replaced older tools like <b>mkinitrd</b> in many modern Linux distributions, including Fedora, RHEL, and CentOS, providing a more robust and maintainable solution for boot-time setup.


title: CAVEATS
content:
Improper use of <b>dracut</b>, such as omitting critical drivers or misconfiguring paths, can render a system unbootable. While <i>--host-only</i> is recommended for smaller images, it means the <i>initramfs</i> is tied to specific hardware; changes in hardware (e.g., migrating a virtual machine to a different hypervisor) might require regenerating the image. Large <i>initramfs</i> images can increase boot time and memory consumption during the early boot phase.


title: DRACUT MODULES
content:
The core of <b>dracut</b>'s flexibility comes from its module system. These modules are self-contained directories or scripts that provide specific functionalities, drivers, or tools to be included in the <i>initramfs</i>. Examples include modules for managing LVM, decrypting encrypted volumes (cryptsetup), setting up network booting (NFS, iSCSI), or integrating with <b>systemd</b>. Users can also develop custom modules to add highly specific boot-time requirements.


title: DEFAULT IMAGE LOCATION
content:
By default, <b>dracut</b> places the generated <i>initramfs</i> image in the <i>/boot</i> directory, typically named <i>initramfs-&lt;kernel_version&gt;.img</i>. The bootloader (like GRUB) is then configured to load this specific image along with the kernel during startup.


title: HISTORY
content:
<b>dracut</b> was developed by Harald Hoyer of Red Hat and first introduced around 2009. It emerged as a modern, modular, and more flexible successor to the traditional <b>mkinitrd</b> utility. Its design emphasizes simplicity, auto-detection of necessary components, and a highly modular, script-based approach to building the <i>initramfs</i>. This made it easier to manage and extend across various Linux distributions and hardware configurations, leading to its widespread adoption in distributions like Fedora, RHEL, and CentOS.


title: SYNOPSIS
content:
<i>drawing</i> [<b>--help</b>] [<b>--version</b>] [<b>--display=</b><i>DISPLAY</i>] [<i>FILE...</i>]<br>Invokes the graphical drawing application, optionally opening specified image files.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options for launching the application.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the application's version information.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for the application, relevant in X Window System environments.<br><br><b><i>FILE...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more image files to open when the application starts, such as .png, .jpg, or .svg files.<br><br>


title: DESCRIPTION
content:
The 'drawing' command on Linux typically refers to a user-friendly graphical application designed for creating and editing digital images. It often supports both pixel-based (raster) and vector graphics, allowing users to draw freehand, create shapes, add text, and apply colors. Unlike command-line utilities, its primary interaction is through a graphical user interface (GUI) with tools, menus, and canvases. It's often used for quick sketches, diagrams, simple image editing, and educational purposes, providing a less complex alternative to professional suites like GIMP or Inkscape. Its simplicity makes it accessible for everyday drawing tasks without requiring extensive technical knowledge.


title: CAVEATS
content:
The 'drawing' command primarily launches a graphical application. It is not a command-line utility for performing drawing operations directly within the terminal or via scripting. Its main functionality is accessed through its graphical user interface. Command-line options are usually limited to launching the application, opening files, or displaying meta-information rather than controlling drawing operations themselves.


title: GRAPHICAL NATURE
content:
It is crucial to understand that 'drawing' is a GUI application. This means user interaction primarily involves a mouse, keyboard, and graphical elements on the screen, rather than typing commands into a terminal for direct image manipulation.


title: COMMON USE CASES
content:
Often used for annotating screenshots, creating simple diagrams, brainstorming visual ideas, or basic image manipulation for non-professional users. It provides a straightforward interface for common drawing tasks, making it ideal for quick visual communication.


title: HISTORY
content:
While specific 'drawing' applications like GNOME Drawing (a prominent example) are relatively modern (e.g., GNOME Drawing started around 2017), the concept of simple graphical drawing tools on Linux dates back to early desktop environments like KDE and GNOME. These tools provide basic paint-like functionality, aiming to fill the gap between complex professional software and the need for quick, accessible image creation and annotation for general users. They represent a continuous effort to provide user-friendly graphics capabilities on Linux desktops.


title: PARAMETERS
content:
<b><b>-i</b> <i><interface></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to listen on (e.g., <i>eth0</i>, <i>wlan0</i>). This option is usually mandatory for capturing traffic.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to render all images, even those with MIME types that are not recognized by <i>driftnet</i>.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fork into the background. Useful for debugging or when running <i>driftnet</i> as part of a script.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message outlining command usage and options, then exit.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not put the network interface into promiscuous mode. This means <i>driftnet</i> will only see packets destined for its own host, which might limit its effectiveness on switched networks.<br><br><b><b>-s</b> <i><directory></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save detected images into the specified directory rather than displaying them in a graphical window.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitor for MPEG audio streams and attempt to play them.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not update the displayed image if it's already being shown. This prevents redundant display of the same image.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output; <i>driftnet</i> will print more information about the packets it processes.<br><br><b><i><filter expression></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A <i>pcap</i>-compatible filter expression (e.g., '<i>tcp port 80</i>') to narrow down the captured traffic, focusing only on relevant packets.<br><br>


title: DESCRIPTION
content:
<i>driftnet</i> is a command-line tool for passively observing network traffic. It sniffs TCP streams, specifically looking for and extracting common image formats (like JPEG, GIF, PNG) and sometimes audio files. Once detected, these media files are either displayed in a dedicated graphical window or saved to a specified directory. It operates by capturing raw packets using the <i>libpcap</i> library and then intelligently reassembling the TCP streams to identify and reconstruct the embedded media content.<br><br>While often employed for entertainment or to highlight network security vulnerabilities (e.g., unencrypted HTTP traffic), <i>driftnet</i> serves as a powerful illustration of privacy risks on unencrypted networks, especially public Wi-Fi. It's a 'listen-only' tool and does not inject or alter network traffic. Its effectiveness largely depends on the type of unencrypted traffic traversing the network segment it's monitoring and the network topology (e.g., shared medium vs. switched network). This tool remains a classic example of passive network sniffing.


title: CAVEATS
content:
<b>Root Privileges:</b> <i>driftnet</i> typically requires root privileges to put the network interface into promiscuous mode and capture raw packets.<br><br><b>Privacy & Legality:</b> Using <i>driftnet</i> on networks you do not own or have explicit permission to monitor can be illegal and unethical. It exposes unencrypted data and can lead to severe privacy breaches.<br><br><b>Performance:</b> On busy networks, <i>driftnet</i> can consume significant CPU and memory resources, especially when saving many images to disk.<br><br><b>Limited Scope:</b> <i>driftnet</i> can only process unencrypted traffic (e.g., HTTP, FTP). It cannot decrypt or display content from encrypted protocols like HTTPS, SSH, or VPN tunnels.<br><br><b>Network Topology:</b> It is most effective on shared network mediums (like older Wi-Fi or hubs). On modern switched networks, it might only see traffic directed to or from the host, unless advanced techniques like ARP spoofing or port mirroring are employed (which <i>driftnet</i> itself does not perform).


title: GRAPHICAL DISPLAY REQUIREMENT
content:
When not using the <b>-s</b> option, <i>driftnet</i> opens a dedicated graphical window to display captured images. This means it requires an X server environment to function correctly. If run in a console-only environment (e.g., via SSH without X forwarding), it will fail to display images unless directed to save them.


title: FILTER EXPRESSIONS
content:
Users can apply powerful <i>tcpdump</i>-style filter expressions to narrow down the traffic sniffed. For example, '<i>port 80</i>' will limit capturing to HTTP traffic only, which can significantly reduce noise and improve performance on busy networks by focusing on specific protocols or hosts.


title: HISTORY
content:
<i>driftnet</i> was created by Ethan "ewhac" Bradford. It emerged during a period when a significant portion of internet traffic, particularly on public Wi-Fi hotspots, was unencrypted. This made <i>driftnet</i> a stark and immediate demonstration of how easily sensitive data, such as images browsed on a website, could be intercepted on a shared network. Its development prioritized simplicity and direct visual feedback, making it an impactful educational tool for illustrating fundamental network security and privacy issues. While its development is no longer actively maintained, its core functionality remains a classic example of passive network sniffing and a reminder of the importance of encryption.


title: SYNOPSIS
content:
<b>drill</b> [<i>OPTIONS</i>] <i>name</i> [<i>TYPE</i>] [<i>CLASS</i>] <br><b>drill</b> [-<b>DDKLSVdfgkoTrst</b>] [-<b>p</b> <I>port</I>] [-<b>o</b> <I>query-option...</I>] [-<b>s</b> <I>address</I>] [-<b>q</b> <I>name</I>] [-<b>i</b> <I>filename</I>] [-<b>y</b> <I>keyname:keyalgo:keydata</I> | <I>keyfile</I>] [<I>name</I>] [<I>@server</I>] [<I>type</I>] [<I>class</I>]


title: PARAMETERS
content:
<b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables displaying the full DNSSEC validation path.<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows DNSSEC security status, including Authenticated Data (AD) or Checking Disabled (CD) flags.<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the DNS query over HTTPS (DoH) for enhanced privacy.<br><br><b>-T</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the DNS query over TLS (DoT) for enhanced privacy.<br><br><b>-s <address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the IP address or hostname of the DNS server to query instead of the default.<br><br><b>-p <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the destination port number for the DNS query (default is 53).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of TCP for the DNS query instead of the default UDP.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables recursion, setting the RD (Recursion Desired) bit to 0 in the query.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <I>drill</I> and exits.<br><br><b>-o <option></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a flexible way to add specific query options. Common options include <I>rd</I> (recursion desired), <I>no-rd</I>, <I>short</I> (minimal output), <I>noshort</I>, <I>aa</I> (authoritative answer), etc.<br><br><b>-y <key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a TSIG (Transaction Signature) key for authenticated DNS queries or updates. Format can be <I>keyname:keyalgo:keydata</I> or a <I>keyfile</I>.<br><br><b>name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The domain name or IP address to resolve (e.g., example.com).<br><br><b>type</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The type of DNS record to query (e.g., A, AAAA, MX, NS, SOA, PTR, SRV). Defaults to A if omitted.<br><br><b>class</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The DNS class of the query (e.g., IN for Internet, CH for Chaos). Defaults to IN if omitted.<br><br>


title: DESCRIPTION
content:
<i>drill</i> is a command-line utility from the <I>ldns</I> library suite, designed for performing DNS queries. It serves as a modern, lightweight, and often preferred alternative to traditional tools like <I>dig</I>, offering a cleaner and more parseable output format. <br><br>It supports a wide range of DNS record types, including A, AAAA, MX, NS, SOA, PTR, SRV, and numerous others. A key strength of <I>drill</I> lies in its robust support for DNSSEC (DNS Security Extensions), allowing users to validate DNS responses and inspect the DNSSEC chain. Furthermore, recent versions include support for encrypted DNS protocols such as DNS over TLS (DoT) and DNS over HTTPS (DoH), enhancing privacy and security for DNS lookups. Its simplicity in usage combined with advanced features makes it an invaluable tool for network administrators, security professionals, and developers.


title: CAVEATS
content:
While <i>drill</i> offers a cleaner interface and strong DNSSEC support, its output format is distinct from <i>dig</i>, which might require a learning curve for users accustomed to traditional DNS tools. The availability of advanced features like DNS over TLS (DoT) and DNS over HTTPS (DoH) depends on the version of the <I>ldns</I> library it was compiled against, and may not be present in older distributions.


title: DNSSEC FOCUS
content:
One of <i>drill</i>'s primary design goals was to provide robust and native support for DNSSEC, allowing users to easily inspect and validate the authenticity and integrity of DNS responses. It can display the entire DNSSEC validation path, including DS, DNSKEY, RRSIG, and NSEC/NSEC3 records, which is crucial for troubleshooting DNSSEC deployments and understanding the trust chain.


title: CLEANER OUTPUT
content:
Compared to <I>dig</I>, <i>drill</i> typically produces a more concise and parseable output by default. This makes it particularly well-suited for integration into scripts and automated systems, as it simplifies the programmatic processing of DNS query results. While it offers options for more verbose output, its default behavior prioritizes clarity and essential information.


title: HISTORY
content:
<i>drill</i> was developed by NLnet Labs as a core component of the <I>ldns</I> library project, an initiative to create a modern, lightweight, and secure DNS library. It emerged as a response to the growing need for a robust command-line DNS tool capable of natively handling DNSSEC validation and providing clearer output than its predecessors. Its evolution has focused on enhancing DNS security and privacy, incorporating features like comprehensive DNSSEC support and, in more recent iterations, encrypted DNS protocols such as DoT and DoH. <I>drill</I> has steadily gained traction among users who prioritize security and a streamlined command-line experience for their DNS lookup needs.


title: SYNOPSIS
content:
<b>dropbearconvert</b> <i>&lt;format_in&gt; &lt;format_out&gt; &lt;key_in&gt; &lt;key_out&gt;</i><br>Alternatively, options can be used: <b>dropbearconvert</b> <i>[-i &lt;key_in_format&gt;] [-o &lt;key_out_format&gt;] [-f &lt;file_in&gt;] [-e &lt;file_out&gt;] [-t &lt;key_type&gt;] [-s &lt;passphrase&gt;] [-S &lt;passphrase&gt;]</i>


title: PARAMETERS
content:
<b><i>&lt;format_in&gt;</i> | <b>-i</b> <i>&lt;key_in_format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the format of the input key. Options are <b>openssh</b> (for private keys) or <b>openssh_public</b> (for public keys).<br><br><b><i>&lt;format_out&gt;</i> | <b>-o</b> <i>&lt;key_out_format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired output key format. Options include <b>dropbear</b> (for private keys), <b>dropbear_public</b> (for public keys), or <b>dropbear_authorized_keys</b> (for an <i>authorized_keys</i> entry).<br><br><b><i>&lt;key_in&gt;</i> | <b>-f</b> <i>&lt;file_in&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input key file (OpenSSH format).<br><br><b><i>&lt;key_out&gt;</i> | <b>-e</b> <i>&lt;file_out&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the converted key will be saved (Dropbear format).<br><br><b><b>-t</b> <i>&lt;key_type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies the type of the key if it cannot be inferred (e.g., <b>rsa</b>, <b>dss</b>, <b>ecdsa</b>, <b>ed25519</b>).<br><br><b><b>-s</b> <i>&lt;passphrase&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the passphrase for the input key if it is encrypted.<br><br><b><b>-S</b> <i>&lt;passphrase&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a passphrase for the output key. Note that Dropbear private keys are typically not encrypted by default.<br><br>


title: DESCRIPTION
content:
<i>dropbearconvert</i> is a utility designed to facilitate the conversion of SSH keys between the widely used OpenSSH format and the native format utilized by the Dropbear SSH server and client. This tool is essential for environments where Dropbear is deployed, such as embedded systems or routers, as Dropbear often requires its own key format for proper authentication and operation.<br><br>It supports converting both <b>private</b> and <b>public</b> keys of various types, including <b>RSA</b>, <b>DSS</b>, <b>ECDSA</b>, and <b>Ed25519</b>, from OpenSSH to Dropbear's format. Additionally, it can convert OpenSSH public keys directly into the Dropbear <i>authorized_keys</i> format, which is crucial for managing remote access. The command offers flexibility by allowing specification of input and output formats and file paths, along with options to handle encrypted input keys and set passphrases for output keys.


title: CAVEATS
content:
When converting private keys, exercise caution as this involves handling sensitive cryptographic material. While <i>dropbearconvert</i> supports setting a passphrase for the output key, Dropbear's native private key format is often unencrypted. Ensure proper file permissions (e.g., 600 for private keys) on the output file to prevent unauthorized access. The command specifically supports OpenSSH <b>version 2</b> key formats.


title: KEY FORMAT DIFFERENCES
content:
Dropbear uses a slightly different internal representation for SSH keys compared to OpenSSH. This conversion utility resolves this incompatibility, allowing keys generated by <i>ssh-keygen</i> (part of OpenSSH) to be used with Dropbear, and vice-versa (though direct Dropbear key generation is done via <i>dropbearkey</i>).


title: COMMON USE CASES
content:
A frequent use case is converting an OpenSSH private key (e.g., <i>id_rsa</i>) into a Dropbear private key for use with a Dropbear server, or converting an OpenSSH public key (e.g., <i>id_rsa.pub</i>) into an entry suitable for Dropbear's <i>authorized_keys</i> file on a server.


title: HISTORY
content:
<i>dropbearconvert</i> is an integral part of the Dropbear SSH project. Dropbear was developed as a lightweight, small, and efficient SSH 2 server and client, primarily for embedded systems and other resource-constrained environments. <i>dropbearconvert</i> emerged as a necessary tool to bridge the compatibility gap between Dropbear's specific key format and the more commonly used OpenSSH key format, enabling seamless key management across different SSH implementations.


title: SYNOPSIS
content:
<b>dropbearkey</b> <b>-t</b> <i>&lt;type&gt;</i> <b>-f</b> <i>&lt;filename&gt;</i> [<b>-s</b> <i>&lt;bits&gt;</i>] [<b>-y</b>]


title: PARAMETERS
content:
<b><b>-t</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of key to generate. Supported types include: <i>rsa</i>, <i>dss</i> (for DSA), <i>ecdsa</i>, and <i>ed25519</i>. Ed25519 is generally recommended for new keys due to its security and performance characteristics.<br><br><b><b>-f</b> <i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path and filename where the generated private key will be saved. For host keys, common paths are <i>/etc/dropbear/dropbear_dss_host_key</i>, <i>/etc/dropbear/dropbear_rsa_host_key</i>, etc.<br><br><b><b>-s</b> <i>&lt;bits&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the size of the key in bits. This option is applicable for RSA, DSS, and ECDSA keys. For Ed25519, the key size is fixed and this option is ignored. Common sizes include 2048 or 4096 for RSA, and 256 or 384 for ECDSA.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the public key to standard output (stdout) immediately after the private key has been generated and saved. The public key is typically presented in an OpenSSH-compatible format, suitable for adding to <i>authorized_keys</i> files.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces overwrite of an existing key file if it already exists at the specified <b>-f</b> path. Use with caution.<br><br>


title: DESCRIPTION
content:
<i>dropbearkey</i> is a utility bundled with the Dropbear SSH server and client suite, designed for generating cryptographic key pairs. These key pairs consist of a private key and a public key, which are fundamental for secure communication in SSH. The primary purpose of <i>dropbearkey</i> is to create host keys for the Dropbear SSH server (<i>dropbear</i>) to identify itself to clients, and user keys for clients (<i>dbclient</i>) to authenticate themselves to servers.<br><br>It supports various modern and legacy cryptographic algorithms, including RSA, DSS (DSA), ECDSA, and Ed25519. While the private keys are stored in a format optimized for Dropbear's lightweight design, the public keys can be easily outputted in a format compatible with OpenSSH, making them suitable for use in <i>~/.ssh/authorized_keys</i> files or for server host key verification.<br><br><i>dropbearkey</i> is particularly valuable in embedded systems, routers, and low-resource environments where the full OpenSSH suite might be too large or resource-intensive. It provides the essential key management capabilities needed for Dropbear to function securely.


title: CAVEATS
content:
Private keys generated by <i>dropbearkey</i> are in a specific format tailored for Dropbear and are not directly interchangeable with OpenSSH private keys. However, public keys can be outputted in OpenSSH format for compatibility. As with any cryptographic key, the generated private key file must be kept secure with appropriate file permissions (e.g., 600 for user keys, 600 or 640 for host keys accessible only by the Dropbear server process) to prevent unauthorized access.


title: KEY TYPES AND RECOMMENDATIONS
content:
When generating keys, selecting the appropriate type is crucial. <i>RSA</i> and <i>DSS</i> (DSA) are older standards, with <i>RSA</i> still widely used but often requiring larger key sizes (e.g., 4096 bits) for strong security. <i>ECDSA</i> (Elliptic Curve Digital Signature Algorithm) offers strong security with smaller key sizes and is more performant. <i>Ed25519</i> is generally considered the most modern and recommended key type, offering excellent security, speed, and resistance to certain types of cryptographic attacks, making it the preferred choice for new key generation.


title: USING THE PUBLIC KEY
content:
After generating a private key (e.g., <i>id_ed25519</i>), the corresponding public key (e.g., <i>id_ed25519.pub</i>) can be extracted using <i>dropbearkey -y -f &lt;private_key_file&gt;</i>. This public key is then used for different purposes:<br><ul><li>For host keys: it's typically shared with clients or stored in <i>~/.ssh/known_hosts</i> files on clients to verify the server's identity.</li><li>For user keys: it's placed in the <i>~/.ssh/authorized_keys</i> file on the server to allow the corresponding private key holder to authenticate without a password.</li></ul>


title: HISTORY
content:
Dropbear was created by Matt Johnston in 2003 as a lightweight SSH server and client, specifically targeting embedded systems and environments with limited resources. <i>dropbearkey</i> has been an integral part of the Dropbear suite from its early development, providing the necessary functionality to generate host and user keys. Over time, it has evolved to support newer, more secure cryptographic algorithms like ECDSA and Ed25519, aligning with advancements in cryptography and security best practices while maintaining its minimal footprint.


title: PARAMETERS
content:
<b><b>dbname</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>The name of the database to be dropped.</I><br><br><b><b>-h</b> <I>host</I>, <b>--host=</b><I>host</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the host name of the machine on which the server is running.</I><br><br><b><b>-p</b> <I>port</I>, <b>--port=</b><I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the TCP port or local Unix domain socket file extension the server is listening on.</I><br><br><b><b>-U</b> <I>username</I>, <b>--username=</b><I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>User name to connect as.</I><br><br><b><b>-W</b>, <b>--password</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Forces dropdb to prompt for a password before connecting to a database.</I><br><br><b><b>-e</b>, <b>--echo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Echoes the SQL commands that dropdb generates and sends to the server.</I><br><br><b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prompts for confirmation before actually destroying the database.</I><br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not display a response. This option suppresses success messages.</I><br><br><b><b>--if-exists</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not throw an error if the database does not exist. A notice is issued in this case.</I><br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force connections to the target database to be terminated. This option ensures the drop succeeds even if active sessions exist.</I><br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Shows the commands that dropdb would execute, but does not actually run them.</I><br><br>


title: DESCRIPTION
content:
dropdb is a utility for removing existing PostgreSQL databases. It is a wrapper around the SQL command <I>DROP DATABASE</I>.<br><br>When executed, dropdb connects to the PostgreSQL server (typically the 'postgres' database by default, unless specified) and issues the <I>DROP DATABASE</I> command for the specified database name. This action permanently deletes all data, tables, indexes, functions, and other objects within that database.<br><br>Due to its destructive nature, dropdb requires appropriate superuser or database owner privileges on the PostgreSQL server. It's crucial to ensure that no active connections exist to the target database during the drop operation, as PostgreSQL will prevent the drop if there are active sessions, unless the <I>--force</I> option is used. It's an essential administrative tool for database lifecycle management, allowing administrators to clean up old or unnecessary databases.


title: CAVEATS
content:
dropdb is a highly destructive command.<br><br><b>Irreversible Data Loss</b>: Dropping a database permanently deletes all its data and objects. There is no undo mechanism.<br><br><b>Permissions</b>: You must have superuser privileges or be the owner of the database to drop it.<br><br><b>Active Connections</b>: By default, you cannot drop a database if there are active connections to it. Use the <I><b>--force</b></I> option with extreme caution to terminate connections, as this can disrupt other users.<br><br><b>System Databases</b>: Do not attempt to drop <I>template0</I> or <I>template1</I> unless you know exactly what you are doing, as these are critical for PostgreSQL's operation.


title: CONNECTION DATABASE
content:
dropdb connects to the 'postgres' database by default when dropping another database. If the 'postgres' database does not exist, it connects to 'template1'.


title: ENVIRONMENTAL VARIABLES
content:
dropdb uses the environment variables <I>PGHOST</I>, <I>PGPORT</I>, <I>PGUSER</I>, <I>PGPASSWORD</I>, and <I>PGDATABASE</I> for default connection parameters. If <I>PGPASSWORD</I> is set, dropdb will use it, potentially overriding <I><b>-W</b></I>.


title: SECURITY
content:
Always be mindful of the database name when using dropdb. Double-check before executing, especially in production environments. Using <I><b>-i</b></I> for interactive confirmation or <I><b>--dry-run</b></I> for testing is highly recommended.


title: HISTORY
content:
dropdb has been a fundamental utility in the PostgreSQL ecosystem since its early versions. It provides a simple command-line interface for performing the <I>DROP DATABASE</I> SQL operation, simplifying database administration tasks by wrapping complex SQL commands in a user-friendly tool. Its design reflects PostgreSQL's commitment to robust and accessible database management.


title: PARAMETERS
content:
<b><b><path></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The specific file or directory path to analyze. If omitted, it typically checks the current working directory or attempts to auto-discover the Drupal root.<br><br><b><b>-c</b>, <b>--config</b>=<I>CONFIG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom path to a PHPStan configuration file (e.g., <I>phpstan.neon</I>) to tailor the analysis rules.<br><br><b><b>-r</b>, <b>--drupal-root</b>=<I>DRUPAL-ROOT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets the path to the Drupal root directory. Useful when running <I>drupal-check</I> from a subdirectory or non-standard project structure.<br><br><b><b>-D</b>, <b>--deprecations</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows deprecation issues (this is the default behavior).<br><br><b><b>-n</b>, <b>--no-deprecations</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the reporting of deprecation issues, focusing only on other general static analysis findings.<br><br><b><b>-a</b>, <b>--analysis</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables additional general static analysis checks, which might include potential bugs or code smells beyond just deprecations.<br><br><b><b>--triggered-deprecation-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only shows deprecations that are actively triggered (require actual execution of the code path to be found), potentially reducing noise from unused code.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the analysis results in JSON format, suitable for programmatic consumption or CI/CD pipelines.<br><br><b><b>--error-format</b>=<I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for errors, e.g., <I>pretty</I> (default, human-readable), <I>raw</I>, or <I>checkstyle</I> (for integration with tools like Jenkins).<br><br><b><b>--memory-limit</b>=<I>LIMIT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the PHP memory limit for the command, useful for large codebases (e.g., <I>2G</I> or <I>-1</I> for no limit).<br><br><b><b>-v</b>, <b>-vv</b>, <b>-vvv</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of messages. <I>-vvv</I> provides maximum verbosity, including debugging information.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message for the command.<br><br>


title: DESCRIPTION
content:
<i>drupal-check</i> is a command-line tool that performs static analysis on Drupal projects, primarily to identify deprecated code usage and compatibility issues when upgrading between Drupal versions (e.g., Drupal 8 to 9, or 9 to 10). It leverages <I>PHPStan</I> along with Drupal-specific rules to scan your codebase without executing it.<br><br>The tool helps developers proactively find and fix code that will become incompatible or throw errors in newer Drupal versions, significantly aiding in the upgrade process. It checks for API changes, function removals, class deprecations, and other architectural shifts, providing actionable feedback. It's an essential tool for maintaining modern and upgrade-ready Drupal applications and can be integrated into development workflows and CI/CD pipelines.


title: CAVEATS
content:
While powerful, <I>drupal-check</I> performs static analysis, meaning it only inspects code structure and patterns, not runtime behavior. Therefore, it may produce false positives or miss issues that only manifest during execution. It's not a substitute for comprehensive testing (unit, integration, functional). Large codebases might require significant memory and processing time. Requires PHP (typically 7.4+ for modern Drupal) and Composer for installation and execution.


title: INSTALLATION
content:
<I>drupal-check</I> is typically installed via <B>Composer</B> within your Drupal project to ensure version compatibility with your project's dependencies:<br><br><code>composer require --dev mglaman/drupal-check</code><br><br>Alternatively, for global access across multiple projects, you can install it globally, though this is less common for Drupal-specific tools due to potential dependency conflicts:<br><br><code>composer global require mglaman/drupal-check</code>


title: TYPICAL USAGE
content:
After installation, you can run <I>drupal-check</I> from your Drupal root. To check a specific custom module, for example:<br><br><code>./vendor/bin/drupal-check web/modules/custom/mymodule</code><br><br>To analyze the entire codebase (including contributed modules and core), you might need to adjust your PHPStan configuration (e.g., in <I>phpstan.neon</I> or <I>phpstan.neon.dist</I>) to include or exclude specific paths and define analysis levels. It's highly recommended to integrate <I>drupal-check</I> into CI/CD pipelines to catch deprecations and compatibility issues early in the development cycle.


title: HISTORY
content:
<I>drupal-check</I> was developed by <B>Matt Glaman</B> as a vital tool to assist with the significant upgrade paths between major Drupal versions, starting notably with Drupal 8 to 9. It grew out of the need for an efficient way to identify and address deprecated code patterns introduced by Drupal's continuous improvement and API changes. Its development is closely tied to the evolving needs of the Drupal community for smoother and more reliable upgrade processes, becoming an indispensable part of a Drupal developer's toolkit.


title: SYNOPSIS
content:
<b>drush</b> [<i>options</i>] <<i>command</i>> [<i>arguments</i>]<br>Example: <b>drush status</b><br>Example: <b>drush pm:enable my_module --yes</b><br>Example: <b>drush updatedb</b>


title: PARAMETERS
content:
<b>--root=&lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the absolute path to the Drupal installation directory.<br><br><b>--uri=&lt;uri&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URI of the Drupal site to operate on, crucial for multi-site setups.<br><br><b>--yes (-y)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically confirms any prompt, useful for scripting non-interactive operations.<br><br><b>--no (-n)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically declines any prompt, useful for preventing accidental changes.<br><br><b>--verbose (-v)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of Drush output, providing more detailed information.<br><br><b>--alias=&lt;alias_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command on a site defined by a Drush alias, enabling remote or multi-site management.<br><br><b>--user=&lt;id_or_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command as a specific user ID or name, useful for permissions-related tasks.<br><br>


title: DESCRIPTION
content:
Drush (Drupal Shell) is a command-line interface (CLI) for Drupal. It provides a powerful set of commands that allow developers and site administrators to interact with their Drupal sites from the terminal, automating many common tasks. Drush streamlines operations such as installing Drupal, managing modules and themes, running database updates, clearing caches, generating content, and executing site migrations. By eliminating the need to navigate the administrative interface for routine tasks, Drush significantly improves productivity and efficiency, making it an indispensable tool for Drupal development and maintenance workflows. It integrates deeply with Drupal's APIs, providing robust and reliable functionality.


title: CAVEATS
content:
<b>Context Dependency</b>: Drush commands often rely on being executed within a Drupal site's root directory or explicitly specifying it with <i>--root</i>.<br><b>Version Compatibility</b>: Ensure your Drush version is compatible with your Drupal version. Incompatibility can lead to errors or unexpected behavior.<br><b>Environment Differences</b>: Behavior might vary slightly between different server environments (e.g., local, staging, production) due to PHP configurations, pathing, or user permissions.<br><b>Database Backups</b>: Always back up your database before running significant Drush commands like <i>updatedb</i> or <i>config:import</i>, as they can alter data irreversibly.


title: SITE ALIASES
content:
Drush aliases (typically defined in <i>~/.drush/sites/</i> or within Drupal projects) allow defining connection details for local, remote, or multiple Drupal sites, simplifying command execution across different environments without needing to specify <i>--root</i> or <i>--uri</i> each time.


title: EXTENSION SYSTEM
content:
Drush is highly extensible; custom Drush commands can be created within Drupal modules or standalone projects to automate specific site-specific functionalities, integrating deeply with Drupal's API and extending Drush's capabilities.


title: HISTORY
content:
Drush was created by Arto Bendiken in 2007. It quickly became an essential tool for Drupal developers due to its ability to streamline common tasks. Over the years, it has evolved significantly, adopting a command-line application structure based on Symfony Console in Drush 8, and later moving to Composer-based distribution. Drush 9 and subsequent versions (currently Drush 12) require Composer for installation and have refined its command structure, aligning more closely with modern PHP development practices. Its continuous development reflects the changing landscape of Drupal and its ecosystem.


title: SYNOPSIS
content:
<b><code>dsa.1s</code></b> [<i>OPTIONS</i>] [<i>COMMAND</i>] [<i>ARGUMENTS</i>]<br><br><I>Hypothetical command for Digital Signature Algorithm key and signature management.</I>


title: PARAMETERS
content:
<b><b>-genkey</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a new DSA key pair (private and public keys).<br><br><b><b>-paramgen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate DSA parameters (P, Q, G) suitable for key generation.<br><br><b><b>-sign</b> <i>&lt;input_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sign the specified input data or file using a DSA private key.<br><br><b><b>-verify</b> <i>&lt;input_file&gt; &lt;signature_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verify a digital signature against an input file using a DSA public key.<br><br><b><b>-inkey</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input private key file for signing operations.<br><br><b><b>-pubin</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input public key file for verification operations.<br><br><b><b>-out</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file for generated keys, parameters, or signatures.<br><br><b><b>-passin</b> <i>&lt;arg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Source for the pass phrase of an encrypted input private key (e.g., 'pass:password', 'env:VAR', 'file:path').<br><br><b><b>-passout</b> <i>&lt;arg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Source for the pass phrase to encrypt an output private key.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<b><code>dsa.1s</code></b> is not a recognized standard Linux command or a conventional man page section (like <code>man(1)</code> or <code>man(8)</code>). The suffix ".1s" is atypical for executables, suggesting it might be a custom script, an internal utility, or potentially an error in transcription.<br><br>If "dsa" refers to the <I>Digital Signature Algorithm</I> (DSA), a widely used public-key cryptographic algorithm for digital signatures, then a hypothetical <b><code>dsa.1s</code></b> command would likely facilitate operations such as:<br><ul><li>Generating DSA key pairs (private and public keys).</li><li>Generating DSA parameters (P, Q, G values) for key derivation.</li><li>Signing data or files using a DSA private key.</li><li>Verifying digital signatures against data or files using a DSA public key.</li></ul><br>Such a utility would be crucial for establishing authenticity and integrity in digital communications and software distribution, similar to functionalities provided by standard cryptographic suites like OpenSSL or GnuPG.


title: CAVEATS
content:
The command <b><code>dsa.1s</code></b> is <I>not a standard or widely recognized Linux command</I>. Its presence on a system would indicate a highly specialized, custom, or internally developed utility. Users are strongly advised to verify its existence and specific purpose within their particular computing environment, as its functionality is entirely speculative based on the interpretation of "dsa" as <I>Digital Signature Algorithm</I> and common command-line utility patterns.


title: MAN PAGE NAMING CONVENTIONS
content:
Standard Linux man pages typically use section numbers (1-8) without additional alphabetical suffixes (e.g., <code>ls(1)</code>, <code>syscalls(2)</code>). The ".1s" suffix is highly unusual and might indicate a custom or legacy system's documentation convention, or perhaps refer to a specific type of script (e.g., a 'shell script' in section 1).


title: DIGITAL SIGNATURE ALGORITHM (DSA)
content:
DSA is a Federal Information Processing Standard (FIPS) for digital signatures, FIPS 186-4. It relies on the mathematical difficulty of computing discrete logarithms in a finite field. While robust and widely used, DSA is generally considered less efficient than RSA for signing operations and has been increasingly superseded by ECDSA (Elliptic Curve Digital Signature Algorithm) in many modern cryptographic applications due to its smaller key sizes and improved performance.


title: HISTORY
content:
As a non-standard command, <b><code>dsa.1s</code></b> lacks a publicly documented history of development and usage. If it pertains to the <I>Digital Signature Algorithm</I>, its theoretical foundations trace back to the algorithm proposed by the U.S. National Institute of Standards and Technology (NIST) in 1991 for inclusion in the Digital Signature Standard (DSS). The DSA algorithm was officially published as FIPS 186 in 1994. Any specific <b><code>dsa.1s</code></b> utility would be a modern implementation or wrapper built upon these cryptographic principles, likely tailored for specific application needs or a particular organizational workflow.


title: SYNOPSIS
content:
<b>dsaparam</b> [-in <i>filename</i>] [-out <i>filename</i>] [-text] [-noout] [-inform <i>format</i>] [-outform <i>format</i>] [-C] [-genkey] [-rand <i>file(s)</i>] [-new] [<i>num_bits</i>]


title: PARAMETERS
content:
<b>-in <i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file for DSA parameters. If not specified, standard input is used.<br><br><b>-out <i>filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file for DSA parameters. If not specified, standard output is used.<br><br><b>-text</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the DSA parameters in a human-readable text format.<br><br><b>-noout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the output of the encoded version of the parameters. Useful when only printing text or verifying.<br><br><b>-inform <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input format of the parameters. Valid formats are <i>PEM</i> (default) and <i>DER</i>.<br><br><b>-outform <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format of the parameters. Valid formats are <i>PEM</i> (default) and <i>DER</i>.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the DSA parameters in C source code format, suitable for embedding in applications.<br><br><b>-genkey</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a DSA private key using the specified parameters and outputs it.<br><br><b>-rand <i>file(s)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more files to seed the random number generator, enhancing security.<br><br><b>-new</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a new set of DSA parameters. This option requires specifying the bit length.<br><br><b><i>num_bits</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using the <b>-new</b> option, this argument specifies the desired number of bits for the prime <i>p</i> parameter (e.g., 1024, 2048, 3072). Larger values provide stronger security but take longer to generate.<br><br>


title: DESCRIPTION
content:
The <b>dsaparam</b> command is a utility within the OpenSSL toolkit used for generating, managing, and verifying DSA (Digital Signature Algorithm) parameters.<br><br>DSA requires a set of shared global parameters (<i>p</i>, <i>q</i>, <i>g</i>) that are fundamental for creating and verifying DSA signatures. These parameters ensure the cryptographic strength and interoperability of DSA keys within a system. <b>dsaparam</b> can generate new sets of these parameters, print existing ones in various formats (e.g., PEM, DER), or verify their correctness.<br><br>It is commonly used as a foundational step before generating DSA private and public keys, as the parameters define the mathematical group within which DSA operations occur.


title: CAVEATS
content:
DSA, while still supported, is less commonly used for new cryptographic deployments compared to modern alternatives like RSA or ECC.<br><br>Generating large DSA parameters can be computationally intensive and time-consuming, requiring significant processing power. The security of generated parameters relies heavily on the quality and entropy of the random number generator used. Reusing well-known or compromised parameters can severely compromise the security of any associated DSA keys.


title: SECURITY CONSIDERATIONS
content:
The security of DSA signatures depends critically on the quality and strength of the generated parameters. Using sufficiently large parameters (e.g., 2048 bits or more as recommended by NIST) and a cryptographically secure random number generator is paramount to prevent various cryptographic attacks.


title: TYPICAL USAGE FLOW
content:
A common workflow involves first generating DSA parameters using <b>dsaparam -new <i>num_bits</i> -out parameters.pem</b>. Subsequently, a DSA private key can be generated using these parameters (e.g., with <b>openssl dsa -in parameters.pem -genkey -out privatekey.pem</b> or via <b>dsaparam -genkey</b>). These parameters are then often distributed or used internally to ensure interoperability among parties using DSA keys.


title: HISTORY
content:
The DSA (Digital Signature Algorithm) was first specified by the National Institute of Standards and Technology (NIST) in FIPS 186 in 1991. The <b>dsaparam</b> command has been a fundamental part of the OpenSSL cryptographic toolkit since its early versions, providing the necessary tools to generate and manage the global parameters required for DSA key generation and signature operations. Its usage reflects the continued importance of DSA in various cryptographic standards and applications.


title: PARAMETERS
content:
<b>delay</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The delay in seconds between each update. If not specified, defaults to 1 second. Can be a float (e.g., 0.5).<br><br><b>count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The number of updates to display before <b>dstat</b> exits. If not specified, <b>dstat</b> runs indefinitely until interrupted.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables CPU statistics (user, system, idle, wait, steal, guest).<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables disk I/O statistics (read/write, requests).<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables network statistics (receive/send).<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables page statistics (page-in/page-out).<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables load average statistics.<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables memory statistics (used, buffer, cache, free).<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables process statistics (running, blocked, new processes).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables swap statistics (used, free).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows time/date column.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows full detail for disk and network, instead of aggregated totals.<br><br><b>-D &lt;device&gt;[,&lt;device&gt;...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes specific disk devices in the output (e.g., <i>-D sda,sdb</i>).<br><br><b>-N &lt;interface&gt;[,&lt;interface&gt;...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes specific network interfaces in the output (e.g., <i>-N eth0,lo</i>).<br><br><b>--output &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes all output to a CSV or JSON file instead of the console. The format is determined by the file extension (.csv or .json).<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available plugins that can be used with <b>dstat</b>.<br><br><b>--plugin &lt;plugin_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specific plugin (e.g., <i>--plugin tcp,socket</i>).<br><br>


title: DESCRIPTION
content:
<b>dstat</b> is a powerful and versatile command-line tool designed for generating <i>real-time</i> system resource statistics. It uniquely consolidates information typically provided by disparate tools like <i>vmstat</i>, <i>iostat</i>, <i>netstat</i>, and <i>ifstat</i> into a single, comprehensive output stream. This integrated approach eliminates the need to run multiple commands simultaneously, significantly simplifying system monitoring and analysis.<br><br><b>dstat</b> provides immediate insights into critical metrics such as CPU utilization, disk I/O, network traffic, memory usage, paging activity, and various other system statistics. Its columnar output is highly readable and extensively configurable, empowering users to tailor the displayed information precisely to their specific needs. Written in Python, it boasts a flexible plugin architecture, allowing for easy extensibility to monitor custom or application-specific metrics. It is an invaluable tool for performance analysis, troubleshooting bottlenecks, and gaining a deeper understanding of system behavior under various loads.


title: CAVEATS
content:
While powerful, <b>dstat</b> can consume system resources itself, especially if many plugins are enabled or the update frequency is very high. Its output, when not filtered, can be overwhelming due to the sheer volume of metrics. <b>dstat</b> relies on Linux kernel interfaces (primarily <i>/proc</i> and <i>sysfs</i>), making it largely Linux-specific and not directly portable to other Unix-like systems without compatibility layers. For comprehensive system-wide monitoring, it often requires <i>root</i> privileges or execution with <i>sudo</i> to access all necessary statistics, particularly for network and process details.


title: <I>PLUGIN ARCHITECTURE</I>
content:
The true power of <b>dstat</b> lies in its sophisticated Python-based plugin system. This architecture allows users to easily extend <b>dstat</b>'s capabilities by writing custom plugins. These plugins can monitor specific applications, databases, custom hardware metrics, or any other data source not covered by default. This makes <b>dstat</b> incredibly adaptable and flexible for diverse and highly specialized monitoring scenarios, moving beyond generic system metrics.


title: <I>OUTPUT FORMATS</I>
content:
Beyond its default human-readable terminal output, <b>dstat</b> offers robust options for exporting data. It can write all collected statistics directly to comma-separated values (CSV) or JavaScript Object Notation (JSON) files. This functionality is invaluable for scripting automation, performing offline data analysis, and integrating <b>dstat</b>'s rich dataset with other monitoring dashboards, graphing tools, or log management systems for long-term trending and historical analysis.


title: <I>TYPICAL USE CASES</I>
content:
<b>dstat</b> is commonly employed during system troubleshooting to quickly identify bottlenecks (e.g., high CPU wait times, excessive disk I/O, network saturation, memory leaks). It's also widely used during performance testing to observe real-time resource consumption patterns and validate system behavior under stress. Furthermore, it serves as an excellent tool for quick system health checks and for gaining an immediate, comprehensive overview of an active Linux system's state, making it indispensable for interactive diagnostics.


title: HISTORY
content:
<b>dstat</b> was created by Dag Wieërs, primarily to overcome limitations and combine features of existing system monitoring tools like <i>vmstat</i>, <i>iostat</i>, and <i>netstat</i>. The motivation was to provide a more comprehensive, human-readable, and flexible real-time monitoring solution within a single command. Its development began in the early 2000s, with a strong emphasis on ease of use and extensibility through its Python-based plugin system. It quickly gained popularity among Linux administrators and performance engineers due to its consolidated output and user-friendly interface, becoming a staple troubleshooting tool. Continuous development ensures it adapts to evolving Linux kernel metrics and system architectures, maintaining its relevance in modern system diagnostics.


title: SEE ALSO
content:
<i>vmstat(8)</i>: Report virtual memory statistics., <i>iostat(1)</i>: Report CPU utilization and I/O statistics for devices., <i>netstat(8)</i>: Print network connections, routing tables, interface statistics. (Often superseded by <i>ss(8)</i> or <i>ip(8)</i>), <i>sar(1)</i>: Collect, report, or save system activity information., <i>mpstat(1)</i>: Report per-processor or per-CPU utilization., <i>top(1)</i>: Display Linux processes., <i>htop(1)</i>: Interactive process viewer.


title: PARAMETERS
content:
<b><b>-I</b> <i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input format. Common formats include <b>dts</b> (Device Tree Source), <b>dtb</b> (Device Tree Blob), <b>fs</b> (Flattened Structure), <b>dts.txt</b> (plain text DTS).<br><br><b><b>-O</b> <i><format></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format. Common formats include <b>dtb</b> (Device Tree Blob), <b>dts</b> (Device Tree Source), <b>asm</b> (assembly code).<br><br><b><b>-o</b> <i><outfile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output file. If not provided, <b>dtc</b> prints to standard output.<br><br><b><b>-b</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output <b>boot_cpuid_phys</b> property for a given CPU ID. Used for creating <b>dtb</b> files for specific CPUs in a multi-CPU system.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwrite of the output file if it already exists.<br><br><b><b>-R</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a reserve map entry, useful for specifying memory regions for bootloaders.<br><br><b><b>-S</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pad the output <b>.dtb</b> file to a minimum size of <i><num></i> bytes.<br><br><b><b>-p</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pad the output <b>.dtb</b> file to a multiple of <i><num></i> bytes (e.g., a page size).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>dtc</b> version information and exits.<br><br><b><b>-V</b> <i><level></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbosity level for output messages. Higher levels provide more detailed information.<br><br><b><b>-H</b> <i><level></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum header output level (for warnings and errors).<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort nodes and properties in the output DTS for consistent formatting.<br><br><b><b>-W</b> <i><warning></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable specific warnings by name (e.g., <b>-W no-superfluous-labels</b>).<br><br><b><b>-E</b> <i><error></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable or disable specific errors by name (e.g., <b>-E no-unit-address-vs-reg</b>).<br><br><b><b>-d</b> <i><depfile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a dependency file similar to <b>gcc -M</b>, listing all included files.<br><br><b><b>-@</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an <b>__symbols__</b> node to the output <b>.dtb</b>, mapping labels to their paths. Useful for debugging and tools.<br><br>


title: DESCRIPTION
content:
The <b>dtc</b> (<i>Device Tree Compiler</i>) command is a crucial utility in the Linux ecosystem, especially for embedded systems development. It serves as a bridge between the human-readable <i>Device Tree Source</i> (<b>.dts</b>) files and the binary <i>Device Tree Blob</i> (<b>.dtb</b>) format that the Linux kernel consumes at boot time.<br><br>A Device Tree is a data structure used to describe hardware components of a system that are not discoverable by the operating system, such as interrupt controllers, GPIOs, and peripheral devices. This abstraction allows the kernel to be more generic, reducing the need for hardcoded board-specific information within the kernel source itself.<br><br><b>dtc</b> can compile a <b>.dts</b> file into a <b>.dtb</b> file, which is then passed to the kernel by the bootloader. Conversely, it can decompile a binary <b>.dtb</b> file back into its source <b>.dts</b> representation, which is invaluable for debugging, analysis, or reverse-engineering existing Device Trees.<br><br>It supports various input and output formats beyond just <b>.dts</b> and <b>.dtb</b>, including <b>.dts.txt</b> (raw text) and <b>.fs</b> (flattened structure).


title: CAVEATS
content:
<b>dtc</b> is primarily a developer tool used in the context of embedded Linux kernel development. It is not a command typically used by general Linux users for system administration or daily tasks.<br><br>Understanding its use requires familiarity with Device Trees and the specifics of hardware description. Incorrect usage or malformed Device Tree source can lead to unbootable systems or hardware not being recognized correctly by the kernel.


title: DEVICE TREE FORMATS
content:
<b>dtc</b> supports several input and output formats:<br><i>Input</i>: <b>dts</b> (Device Tree Source), <b>dtb</b> (Device Tree Blob), <b>fs</b> (Flattened Structure), <b>dts.txt</b> (plain text DTS, useful for debugging).<br><i>Output</i>: <b>dtb</b> (binary blob for kernel), <b>dts</b> (source form for human readability), <b>asm</b> (assembly code for the blob).


title: ROLE IN EMBEDDED SYSTEMS
content:
For embedded Linux, <b>dtc</b> is indispensable. It allows hardware designers and kernel developers to describe complex board layouts and peripheral configurations in a standardized, external data structure. This greatly simplifies the process of porting the Linux kernel to new hardware platforms, as board-specific code is replaced by a simple <b>.dtb</b> file loaded at boot.


title: HISTORY
content:
The <b>dtc</b> utility emerged as an essential component of the Linux kernel's Device Tree project. The concept of Device Trees originated with Open Firmware and gained significant traction in the Linux kernel starting with ARM architecture support, where it became a mandatory part of the ARM boot process from kernel version 3.7 onwards. <b>dtc</b> was developed to manage the compilation and decompilation of these critical hardware description files, evolving alongside the Device Tree Specification to support new features and address complexities in hardware representation.


title: SEE ALSO
content:
<b>make</b>(1), <b>kexec</b>(8), <b>device-tree</b>(7), <b>bootloader</b> (e.g., U-Boot, GRUB, often loads <b>.dtb</b>)


title: PARAMETERS
content:
<b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively extract archives found within other archives.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents of the specified archive(s) without extracting them.<br><br><b>-o <directory>, --output <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract all archives into the specified output directory.<br><br><b>-N, --always-directory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always create a new subdirectory for the extracted contents, even if there's only one file or if the archive name is not generic.<br><br><b>-M, --no-directory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Never create a new subdirectory for the extracted contents. Files will be placed directly in the current working directory or the specified output directory.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing files without prompting for confirmation.<br><br><b>-n, --noninteractive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for any user input. This implies '-f' and assumes 'yes' to all questions.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages during extraction.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity of output messages, showing more details about the extraction process.<br><br><b>-s, --sudo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>sudo</i> when invoking external extraction programs, useful for extracting archives with root-owned contents.<br><br><b>-i, --ignore-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue processing other archives even if one archive fails to extract.<br><br>


title: DESCRIPTION
content:
<i>dtrx</i>, short for <b>"Do The Right Extraction"</b>, is a powerful and convenient command-line utility designed to simplify archive extraction on Linux and Unix-like systems. It acts as a universal frontend for various specialized extractors like <i>tar</i>, <i>unzip</i>, <i>unrar</i>, <i>7z</i>, and many others, intelligently determining the archive type and invoking the appropriate tool. <br><br>Its primary goal is to make archive handling straightforward by automating common decisions, such as whether to create a new subdirectory for extracted contents, handling multiple archives, and dealing with conflicting filenames. <i>dtrx</i> minimizes the need for users to remember specific commands or complex options for different archive formats, offering a consistent and user-friendly experience across the board.


title: CAVEATS
content:
<i>dtrx</i> relies heavily on the availability of underlying extraction programs (e.g., <i>tar</i>, <i>unzip</i>, <i>unrar</i>, <i>7z</i>). If these tools are not installed on your system for a specific archive type, <i>dtrx</i> will not be able to extract that format. Its 'intelligent' default behavior, while convenient, can sometimes be overridden by explicit options if a user prefers more manual control over directory creation.


title: INTERACTIVE PROMPTS
content:
A core feature of <i>dtrx</i> is its interactive nature. By default, if there are multiple options for where to place the extracted files (e.g., current directory or a new subdirectory), or if a file conflict arises, <i>dtrx</i> will prompt the user for input. This behavior can be altered using options like <i>-n</i> (non-interactive) or <i>-f</i> (force overwrite).


title: DEPENDENCIES
content:
<i>dtrx</i> acts as a wrapper. It does not contain built-in extraction logic for every format. Instead, it detects the archive type and then calls the appropriate system utility (like <i>tar</i> for .tar.gz, <i>unzip</i> for .zip, etc.). This means that the user must have the necessary underlying tools installed for <i>dtrx</i> to function correctly with all archive types.


title: HISTORY
content:
Developed by Ben Cohen, <i>dtrx</i> was created to address the common frustration of remembering myriad archive commands and their specific flags. It aimed to provide a single, consistent interface for handling nearly all archive formats. While an exact historical timeline is elusive, it gained popularity in the Linux community for its convenience and has been maintained and used for over a decade as a go-to extraction utility.


title: PARAMETERS
content:
<b>-h, --human-readable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display sizes in human-readable format (e.g., 1K, 234M, 2G).<br><br><b>-s, --summarize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only a total for each argument, rather than individual entries.<br><br><b>-c, --total</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce a grand total of all arguments processed.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write counts for all files, not just directories.<br><br><b>-x, --one-file-system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip directories on different file systems.<br><br><b>--max-depth=<i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the total for a directory (or file) only if it is <i>N</i> or fewer levels below the command line argument. `--max-depth=0` is equivalent to `-s`.<br><br>


title: DESCRIPTION
content:
The <b>du</b> command, which stands for <i>disk usage</i>, is a standard Unix/Linux utility used to estimate file space usage. It summarizes the disk usage of the set of files or directories specified, recursively traversing subdirectories by default. This makes it an invaluable tool for identifying which files or directories are consuming significant amounts of disk space on a system. By default, <b>du</b> reports sizes in 1KB blocks, but it offers options to display sizes in more human-readable units like kilobytes, megabytes, or gigabytes.<br><br>Unlike <b>df</b>, which reports free disk space on file systems, <b>du</b> focuses on the actual space consumed by files and their contents, including allocated blocks for directories themselves. It provides a granular view of storage consumption, helping system administrators and users manage disk space efficiently. The command calculates usage by inspecting the directory entries and inode information for files and directories within the specified path.


title: CAVEATS
content:
<b>du</b> reports the space <i>allocated</i> on disk, which might be larger than the actual logical size of a file (e.g., for sparse files).<br>By default, <b>du</b> counts disk space in 1KB blocks, which can be confusing without the <i>-h</i> (human-readable) option.<br>It can be slow on very large directory trees due to extensive file system traversal.<br>Finally, it only shows space used by files and directories accessible to the user running the command, respecting file system permissions.


title: DU VS. DF
content:
While <b>du</b> reports the disk space used by specific files or directories, <b>df</b> reports the free disk space on mounted file systems. <b>du</b> traverses the file system to sum up sizes, while <b>df</b> reads file system metadata directly.


title: COMMON USAGE EXAMPLES
content:
<b>Common Usage Examples</b>:<br>To get the total size of the current directory in human-readable format:<br><i>du -sh .</i><br><br>To list human-readable sizes of all files and first-level subdirectories within <i>/var/log</i>:<br><i>du -ah --max-depth=1 /var/log</i><br><br>To list human-readable sizes of all items in the current directory, sorted by size (largest first):<br><i>du -sh * | sort -rh</i>


title: HISTORY
content:
The <b>du</b> command is a fundamental utility that has been a part of Unix-like operating systems since their early days, originating from the AT&T Unix System III development. It has been a staple in almost every Unix distribution and its derivatives, including Linux. The version commonly found on Linux systems is part of the GNU Core Utilities, which provide robust and feature-rich implementations of standard Unix commands. Its core functionality of reporting disk usage has remained consistent, with enhancements over time focusing on additional options for output formatting and control over recursion depth.


title: SYNOPSIS
content:
<B>dua</B> [OPTIONS] [PATH ...]<br><B>dua</B> <B>interact</B> [OPTIONS] [PATH ...]<br><B>dua</B> <B>estimate</B> [OPTIONS] [PATH ...]<br><B>dua</B> <B>diff</B> [OPTIONS] &lt;PATH_A&gt; &lt;PATH_B&gt;


title: PARAMETERS
content:
<b><B>-a</B>, <B>--apparent-size</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display apparent size (actual bytes) instead of disk usage (allocated blocks).<br>This shows the logical size of files, ignoring sparse file optimizations or block allocation details.<br><br><b><B>-H</B>, <B>--human-readable</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print sizes in human readable format (e.g., 1K, 234M, 2G).<br><br><b><B>-L</B>, <B>--dereference</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dereference all symbolic links, counting the size of the target file/directory rather than the link itself.<br><br><b><B>-x</B>, <B>--no-cross-device</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not cross filesystem boundaries when traversing directories. This means it will only scan files on the same device as the starting path.<br><br><b><B>-s</B>, <B>--summarize</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only a total for each argument, rather than listing every entry (similar to <B>du -s</B>).<br><br><b><B>-d</B> &lt;N&gt;, <B>--depth</B> &lt;N&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the depth of the directory tree to N levels in non-interactive modes.<br><br><b><B>--disable-delete</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<B>interact</B> mode) Disable the ability to delete files or directories directly from the interactive interface, providing a safer browsing experience.<br><br><b><B>--no-progress</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<B>interact</B> mode) Do not show scanning progress, which can sometimes be useful for scripting or when output clarity is preferred over real-time updates.<br><br>


title: DESCRIPTION
content:
<I>dua</I> is a powerful command-line utility for analyzing disk usage, serving as a modern alternative to traditional tools like <I>du</I> and <I>ncdu</I>. Written in Rust, it excels in performance, offering exceptional speed for scanning large file systems. <br><br>It provides two primary modes of operation: a non-interactive mode similar to <I>du</I> (accessible via the <B>estimate</B> subcommand or as default for simple output), and an interactive terminal user interface (TUI) mode (via the <B>interact</B> subcommand or default if no specific subcommand is given and output is to a terminal).<br><br>The interactive TUI is <I>dua</I>'s flagship feature, providing a responsive, graphical tree-like view of disk space consumption. Users can navigate directories, inspect file sizes, and even delete files or directories directly within the interface, making it incredibly efficient for identifying and managing disk space hogs. Its intuitive design and performance make it a popular choice for system administrators and users seeking to free up disk space.


title: CAVEATS
content:
When using the interactive TUI, be extremely cautious with the delete functionality, as it can permanently remove files and directories. Always double-check your selection before confirming any deletion. <B>dua</B> can be I/O intensive on systems with slow disks or when scanning extremely large file systems with millions of small files.


title: INTERACTIVE MODE
content:
<B>dua</B>'s interactive mode (accessed via <B>dua interact</B> or often just <B>dua</B>) is its most prominent feature. It provides a real-time, hierarchical, and color-coded view of disk space. Users can navigate using arrow keys, collapse/expand directories, and perform actions like deleting selected items. This visual representation makes it significantly easier to pinpoint disk space bottlenecks than traditional command-line output.


title: SUBCOMMANDS
content:
<B>dua</B> structures its functionalities around subcommands:<br><B>estimate</B>: The default non-interactive behavior, similar to <B>du</B>, for calculating and printing disk usage.<br><B>interact</B>: Launches the interactive TUI for exploring and managing disk space.<br><B>diff</B>: A unique subcommand that allows comparing the disk usage of two specified paths, highlighting differences in size.


title: PERFORMANCE
content:
Due to its implementation in Rust and efficient file system traversal algorithms, <B>dua</B> is often cited for its remarkable speed. It leverages parallel processing to scan directories quickly, making it a superior choice for analyzing very large or complex file systems where other tools might be slow or cumbersome.


title: HISTORY
content:
<B>dua</B> emerged as a modern utility built with Rust, a language known for its performance and memory safety. It was developed to address some limitations and offer a more intuitive experience compared to older disk usage tools. While specific historical dates are not always widely publicized for open-source projects, its initial development and first stable releases generally fall into the late 2010s to early 2020s, quickly gaining traction within the Linux community for its speed and interactive capabilities.


title: SYNOPSIS
content:
<b>dub</b> [<I>GLOBAL_OPTIONS</I>...] <I>COMMAND</I> [<I>COMMAND_OPTIONS</I>...] [<I>ARGS</I>...]<br><br>Common Commands:<br>  <b>dub</b> <I>init</I>: Initialize a new DUB package.<br>  <b>dub</b> <I>build</I>: Build the current DUB package.<br>  <b>dub</b> <I>run</I>: Build and run the current DUB package.<br>  <b>dub</b> <I>test</I>: Build and run unit tests for the current DUB package.<br>  <b>dub</b> <I>fetch</I> [<I>package-name</I>]: Fetch remote dependencies.<br>  <b>dub</b> <I>clean</I>: Clean build artifacts.<br>  <b>dub</b> <I>add-local</I>: Add a local package to the DUB package list.


title: PARAMETERS
content:
<b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for detailed information during operations.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output, showing only essential information or errors.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force an action, such as overwriting existing files or rebuilding when not strictly necessary.<br><br><b><b>--compiler</b>=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the D compiler to use (e.g., <I>dmd</I>, <I>ldc2</I>, <I>gdc</I>).<br><br><b><b>--config</b>=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a particular build configuration defined in <I>dub.json</I> or <I>dub.sdl</I>.<br><br><b><b>--build</b>=<I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the build type (e.g., <I>debug</I>, <I>release</I>, <I>unittest</I>, <I>profile</I>).<br><br><b><b>--arch</b>=<I>arch</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target architecture (e.g., <I>x86</I>, <I>x86_64</I>).<br><br><b><b>--os</b>=<I>os</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target operating system (e.g., <I>linux</I>, <I>windows</I>, <I>osx</I>).<br><br><b><b>--platform</b>=<I>platform</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target platform (a combination of OS and architecture).<br><br><b><b>--root</b>=<I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the root directory of the package to operate on.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <I>dub</I> version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a general help message or command-specific help.<br><br>


title: DESCRIPTION
content:
<b>dub</b> is the official, comprehensive build tool and package manager for the <I>D programming language</I>. It significantly streamlines the development workflow by handling crucial aspects of project management, from <I>initialization</I> to <I>deployment</I>.<br><br>At its core, <b>dub</b> automates dependency management, fetching and resolving packages from the DUB package registry (code.dlang.org/packages) or local paths. It orchestrates the compilation process, invoking the appropriate D compiler (such as <I>dmd</I>, <I>ldc2</I>, or <I>gdc</I>) based on project configurations and user settings. <b>dub</b> supports various project types, including <I>executables</I>, <I>static libraries</I>, <I>shared libraries</I>, and <I>DUB packages</I> themselves. It also facilitates running applications, executing unit tests, generating project descriptions, and cleaning build artifacts. Through its <I>dub.json</I> or <I>dub.sdl</I> project definition files, <b>dub</b> provides a consistent and reproducible build environment for D projects across different systems, making it an indispensable tool for D developers.


title: CAVEATS
content:
The <b>dub</b> command is specifically designed for the <I>D programming language</I> ecosystem and is not a generic Linux utility. Its functionality relies on the presence of a D compiler (like <I>dmd</I>, <I>ldc2</I>, or <I>gdc</I>) and a properly defined <I>dub.json</I> or <I>dub.sdl</I> package file. Fetching external dependencies requires network access to the DUB package registry.


title: PROJECT DEFINITION FILES
content:
<b>dub</b> projects are configured using either a <I>dub.json</I> or <I>dub.sdl</I> file located at the package root. These files define project metadata, dependencies, source files, build configurations, and various other settings crucial for <b>dub</b>'s operation.


title: DUB PACKAGE REGISTRY
content:
The <I>DUB Package Registry</I> (accessible via <I>code.dlang.org/packages</I>) is the central repository for publicly available D packages. <b>dub</b> interacts with this registry to fetch and manage project dependencies, enabling easy sharing and reuse of D code.


title: HISTORY
content:
<b>dub</b> emerged as an essential tool to address the growing need for robust <I>dependency management</I> and <I>build automation</I> within the D programming language community. Initially developed independently, it rapidly gained traction and became the <B>official</B> and de facto standard package manager and build system for D projects. Its continuous development reflects the evolving needs of the D ecosystem, providing a stable and feature-rich foundation for D software development since its early adoption.


title: SYNOPSIS
content:
<i><b>duc</b> &lt;command&gt; [options] [arguments]</i><br><i>Common commands include:</i><br><i><b>duc index</b> [options] &lt;path&gt; [&lt;path&gt; ...]</i><br><i><b>duc ls</b> [options] &lt;path&gt;</i><br><i><b>duc ui</b> [options] &lt;path&gt;</i><br><i><b>duc gui</b> [options] &lt;path&gt;</i>


title: PARAMETERS
content:
<b><b>-x</b>, <b>--one-file-system</b> (for <b>index</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not cross filesystem boundaries during indexing.</i><br><br><b><b>-f</b>, <b>--force</b> (for <b>index</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force re-indexing of an already indexed path, discarding old data.</i><br><br><b><b>-p</b>, <b>--progress</b> (for <b>index</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Show indexing progress.</i><br><br><b><b>-l</b>, <b>--level &lt;N&gt;</b> (for <b>ls</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display directory contents up to N levels deep.</i><br><br><b><b>-t</b>, <b>--threshold &lt;SIZE&gt;</b> (for <b>ls</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Only show items larger than the specified SIZE (e.g., 1G, 500M).</i><br><br><b><b>-s</b>, <b>--size-only</b> (for <b>ls</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display only the size, without names or path information.</i><br><br><b><b>-H</b>, <b>--http &lt;PORT&gt;</b> (for <b>gui</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start an HTTP server for the web GUI on the specified PORT.</i><br><br><b><b>-d</b>, <b>--database &lt;PATH&gt;</b> (general)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an alternative database file path instead of the default (~/.duc.db).</i><br><br><b><b>-h</b>, <b>--help</b> (general)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display help message for a command or subcommand.</i><br><br>


title: DESCRIPTION
content:
<i><b>duc</b> is a command-line tool that provides a fast and efficient way to analyze disk usage. Unlike traditional tools like <b>du</b>, <b>duc</b> builds a database of file system statistics, which allows for extremely rapid queries and updates. It can show disk usage of directories and files, offering different views including a summary, a tree view, and an interactive curses-based browser (similar to <b>ncdu</b>). Additionally, <b>duc</b> can generate static HTML reports or even serve a dynamic web interface for exploring disk usage. Its database-driven approach makes it particularly useful for large file systems where repeated <b>du</b> scans would be slow. It supports indexing multiple file systems and provides various options for filtering and displaying information.</i>


title: CAVEATS
content:
<i><br>Initial indexing can take a significant amount of time for very large file systems.<br>The <b>duc</b> database can grow large depending on the amount of indexed data, potentially consuming considerable disk space.<br>File system changes (additions, deletions, size changes) are not reflected until <b>duc index</b> is run again for the affected paths.</i>


title: DATABASE LOCATION
content:
<i>By default, the <b>duc</b> database is stored in <b>~/.duc.db</b>. This path can be changed using the <b>-d</b> or <b>--database</b> option. The database stores file system metadata and sizes, not the file contents themselves.</i>


title: INTERACTIVE UI
content:
<i>The <b>duc ui</b> command provides an interactive, curses-based user interface that allows users to navigate through the directory structure, inspect sizes, and identify large files or directories efficiently. It offers a user experience similar to <b>ncdu</b> but benefits from <b>duc</b>'s fast database lookups.</i>


title: WEB GUI
content:
<i>The <b>duc gui</b> command launches a local web server, providing a graphical web interface for exploring disk usage. This can be very useful for sharing reports with others or for users who prefer a browser-based visualization of disk space.</i>


title: HISTORY
content:
<i><b>duc</b> was developed by <b>Arnout Engelen</b> and first released around 2008. Its primary motivation was to address the slowness of <b>du</b> on very large file systems by leveraging a persistent database (SQLite by default) to store scan results, enabling much faster subsequent queries and interactive browsing. It has seen continuous development, adding features like a Text User Interface (TUI), a web-based Graphical User Interface (GUI), and various output formats, establishing itself as a robust and efficient alternative for disk usage analysis.</i>


title: PARAMETERS
content:
<b>DATABASE_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> The path to the database file. If omitted, <i>DuckDB</i> operates as an in-memory database, and all data is lost upon exit.<br><br><b>-readonly | --readonly</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified database file in read-only mode, preventing any modifications.<br><br><b>-s "SQL_QUERY" | -c "SQL_QUERY"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a single SQL query or command provided as a string and then exits the <i>DuckDB</i> shell. Useful for scripting.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>DuckDB</i> version information and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command-line help message and exits.<br><br><b>-init FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes SQL commands from the specified <i>FILE</i> upon starting the <i>DuckDB</i> shell, before any interactive input or queries.<br><br>


title: DESCRIPTION
content:
<i>DuckDB</i> is an open-source, in-process analytical database management system (DBMS) designed for high-performance OLAP (Online Analytical Processing) workloads.<br><br>Unlike traditional client-server databases, <i>DuckDB</i> runs directly within the application process, making it lightweight, easy to embed, and eliminating network overhead. It supports standard SQL, making it accessible to anyone familiar with relational databases.<br><br>Key features include column-oriented storage, vectorized query execution, and parallel processing, which contribute to its exceptional speed for analytical queries involving aggregations, joins, and complex filtering on large datasets. It integrates seamlessly with data analysis tools and programming languages like Python and R. <i>DuckDB</i> can operate entirely in memory or persist data to a single, compact file, offering flexibility for both temporary and persistent data storage.


title: CAVEATS
content:
<b>In-Memory Default:</b> If no <i>DATABASE_FILE</i> is specified, <i>DuckDB</i> runs entirely in memory, and all data is lost when the command process terminates. For persistent storage, always specify a database file name.<br><br><b>Memory Consumption:</b> While efficient, <i>DuckDB</i> can consume significant RAM for very large analytical queries, especially when processing datasets that exceed available memory without proper spilling mechanisms.<br><br><b>Concurrency:</b> <i>DuckDB</i> is designed for single-process analytical workloads and is not intended as a replacement for multi-user, client-server OLTP (Online Transaction Processing) databases. It lacks typical DBMS features like network protocols, complex user management, and high-availability replication.


title: PERSISTENT VS. IN-MEMORY OPERATION
content:
When invoked without a <i>DATABASE_FILE</i> (e.g., `duckdb`), it creates a temporary in-memory database that is discarded when the process exits. To save your data permanently, provide a file path (e.g., `duckdb my_data.duckdb`). All data, tables, and views will be stored within this single file.


title: SQL DIALECT AND EXTENSIONS
content:
<i>DuckDB</i> supports a large subset of standard SQL and includes many analytical extensions, window functions, and advanced data types (e.g., <i>STRUCT</i>, <i>MAP</i>, <i>ARRAY</i>) optimized for data analysis. It also offers powerful SQL functions for file system interaction and external data loading.


title: DIRECT FILE QUERYING
content:
A unique strength of <i>DuckDB</i> is its ability to directly query various data formats (like Parquet, CSV, JSON, Apache Arrow) without explicit loading. You can run SQL queries directly on files from your local filesystem or remote storage (HTTP/S3), e.g., `SELECT * FROM 'data.parquet';`.


title: HISTORY
content:
<i>DuckDB</i> originated from research at CWI (Centrum Wiskunde & Informatica), the national research institute for mathematics and computer science in the Netherlands. Its first public releases began around 2019-2020. It was developed with a focus on providing an embedded, high-performance analytical database for a growing ecosystem of data science and analytics tools. Its design emphasizes columnar storage, vectorized execution, and single-file deployment, quickly gaining popularity as a powerful alternative for local data analysis workflows.


title: SYNOPSIS
content:
<b>duf</b> [<I>options</I>] [<I>path</I>...]<br><br>Examples:<br><b>duf</b><br><b>duf</b> <I>/home /var</I><br><b>duf</b> <I>-h -a</I>


title: PARAMETERS
content:
<b>--all-local, -l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only local file systems.<br><br><b>--all, -a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all file systems, including pseudo ones.<br><br><b>--inodes, -i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display inode information instead of disk usage.<br><br><b>--output=FIELDS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which output fields to display.<br><br><b>--sort=FIELD</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by a specific field (e.g., SIZE, USED, USAGE, INODES, FILESYSTEM).<br><br><b>--raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw values without formatting (e.g., bytes instead of GB).<br><br><b>--style=STYLE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output style (e.g., unicode, ascii, basic).<br><br><b>--theme=THEME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the color theme.<br><br><b>--hide-fs=REGEXP</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hide filesystems matching the given regular expression.<br><br><b>--only-fs=REGEXP</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only filesystems matching the given regular expression.<br><br><b>--max-depth=N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum directory display depth when showing directory usage.<br><br><b>--total</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a grand total for all listed file systems.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>duf</i> is a modern, user-friendly utility designed to replace or complement traditional Linux commands like <i>df</i> and <i>du</i>. Written in Go, it offers a more visually appealing and intuitive way to display disk usage and free space information. Unlike its predecessors, <i>duf</i> provides a color-coded, tabular output that's easy to read at a glance, often including ASCII or Unicode graphs for a quick visual representation of disk fullness.<br><br>It can list information about all mounted filesystems, specific mount points, or even calculate the disk usage of specified directories and files, similar to how <i>du</i> operates. Its output is highly customizable, allowing users to select specific fields, sort by various criteria, and filter results. This makes <i>duf</i> an excellent tool for quick system health checks and identifying large files or directories, providing a much more pleasant user experience.


title: CAVEATS
content:
<i>duf</i> is a third-party utility, not part of the standard core GNU utilities found on all Linux distributions by default. It typically needs to be installed separately. While its rich formatting is excellent for human readability, it makes <i>duf</i> less suitable for parsing in shell scripts compared to the more structured output of traditional commands like <i>df</i> or <i>du</i>, unless the <code>--raw</code> option is used.


title: INSTALLATION
content:
<i>duf</i> is typically available in package managers for most popular Linux distributions (e.g., <i>sudo apt install duf</i> on Debian/Ubuntu, <i>sudo dnf install duf</i> on Fedora). It can also be installed by downloading pre-compiled binaries from its GitHub releases page or by compiling from source.


title: HISTORY
content:
<i>duf</i> was developed relatively recently, written in the Go programming language by Christian Schauer. Its creation was motivated by a desire to provide a more visually appealing and user-friendly alternative to the aging <i>df</i> and <i>du</i> commands, which often present information in a less intuitive format. Since its initial release, <i>duf</i> has gained considerable popularity among Linux users for its modern interface, clear output, and versatility in handling both filesystem and directory usage information.


title: SYNOPSIS
content:
<b>dump.exfat</b> [<i>-s</i> | <i>-b</i> | <i>-c cluster_no</i> | <i>-d dir_start_cluster</i>] <i>device</i>


title: PARAMETERS
content:
<b>device</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device or disk image file containing the exFAT filesystem (e.g., <i>/dev/sdXN</i> or <i>/path/to/image.img</i>).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the exFAT superblock information. This includes details like filesystem size, cluster size, and metadata locations.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the exFAT allocation bitmap. This bitmap tracks which clusters are free and which are in use.<br><br><b>-c <I>cluster_no</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the raw content of a specific cluster number. The output will typically be in hexadecimal format.<br><br><b>-d <I>dir_start_cluster</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the directory entries starting from a specified cluster number. This allows inspection of file and directory metadata within a specific directory.<br><br>


title: DESCRIPTION
content:
<i>dump.exfat</i> is a command-line utility used for low-level examination and dumping of information from an exFAT filesystem. It is part of the <b>exfatprogs</b> suite, which provides a comprehensive set of tools for managing exFAT filesystems on Linux. This command is primarily a diagnostic and debugging tool, allowing system administrators and developers to inspect various components of an exFAT filesystem, such as the superblock, allocation bitmaps, directory entries, and raw cluster content.<br><br>Unlike high-level tools like `ls` or `df`, <i>dump.exfat</i> provides a raw, block-level view of the filesystem's internal structures. It can be invaluable for understanding how data is organized on an exFAT volume, troubleshooting filesystem corruption, or verifying specific metadata attributes. By specifying different options, users can focus on particular parts of the filesystem to retrieve detailed, hexadecimal representations of the underlying data. It operates directly on a block device (e.g., <i>/dev/sdXN</i>) or a disk image file containing an exFAT filesystem.


title: CAVEATS
content:
<ul><li>Requires root privileges (or <i>sudo</i>) to access block devices directly.</li><li>The output is low-level and often in hexadecimal format, requiring knowledge of the exFAT filesystem structure to interpret effectively.</li><li><i>dump.exfat</i> is a read-only tool; it does not modify the filesystem. However, incorrect usage or interpretation of its output could lead to misdiagnoses.</li><li>Ensure the exFAT filesystem is unmounted before performing detailed diagnostics with <i>dump.exfat</i> to avoid potential inconsistencies, though simply reading is generally safe.</li></ul>


title: PURPOSE
content:
<i>dump.exfat</i> is primarily intended for filesystem debugging, forensic analysis, and educational purposes to understand the exFAT structure. It is not designed for everyday filesystem operations.


title: OUTPUT INTERPRETATION
content:
Users should refer to exFAT specification documents or relevant filesystem documentation to fully interpret the hexadecimal output provided by <i>dump.exfat</i>.


title: PACKAGE
content:
This command is typically provided by the <b>exfatprogs</b> package on most modern Linux distributions.


title: HISTORY
content:
The exFAT filesystem was developed by Microsoft for flash memory devices. Initial Linux support was often provided through FUSE (Filesystem in Userspace) modules, such as `exfat-fuse`. Over time, native kernel support for exFAT was integrated into the Linux kernel, significantly improving performance and reliability. The <b>exfatprogs</b> suite, which includes <i>dump.exfat</i>, emerged as the official and highly recommended set of user-space utilities for managing exFAT filesystems on Linux, often replacing older `exfat-utils` packages. Its ongoing development ensures robust and up-to-date tooling alongside kernel support.


title: SYNOPSIS
content:
<b>dumpcap</b> [ <i>options</i> ] <br> <br> Common Usage: <br> <b>dumpcap</b> [ <b>-i</b> <i><interface></i> ] [ <b>-w</b> <i><outfile></i> ] [ <b>-f</b> <i><capture filter></i> ] [ <i>other_options</i> ]


title: PARAMETERS
content:
<b><b>-i</b> <i><interface></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the network interface to capture from (e.g., <i>eth0</i>, <i>wlan0</i>). Use <b>-D</b> to list available interfaces.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the network interfaces on which <b>dumpcap</b> can capture packets, then exit.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the data link types supported by the specified interface and exit. Use with <b>-i</b>.<br><br><b><b>-f</b> <i><capture filter></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the capture filter expression. Only packets matching the filter will be captured. Filters use <i>libpcap</i> syntax (e.g., '<i>tcp port 80</i>', '<i>host 192.168.1.1</i>').<br><br><b><b>-w</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the raw packet data to the specified output file. If not specified, captured packets are discarded.<br><br><b><b>-s</b> <i><snaplen></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the snapshot length (bytes). Only the first <i><snaplen></i> bytes of each packet are captured. Default is 262144 bytes, often sufficient for full packet capture.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not put the interface into promiscuous mode. Normally, interfaces are put into promiscuous mode to capture all traffic on the segment, not just traffic directed to the host.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display packets while capturing (stdout). This is less common for actual captures and more for debugging or live viewing alongside other tools.<br><br><b><b>-a</b> <i><autostop arg></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an automatic stop condition. Common arguments include: <br> <i>duration:<seconds></i> (stop after a duration) <br> <i>filesize:<kilobytes></i> (stop after file reaches a size) <br> <i>packets:<count></i> (stop after a number of packets).<br><br><b><b>-b</b> <i><ringbuffer arg></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a ring buffer for capture files. Arguments control file count and size, e.g., '<i>files:10</i>' (keep 10 files) or '<i>filesize:1000</i>' (1MB per file).<br><br><b><b>-c</b> <i><count></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop after capturing <i><count></i> packets.<br><br><b><b>-B</b> <i><buffer size></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the capture buffer size in megabytes (MB). A larger buffer can prevent packet drops during bursts of traffic.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print packet counts or other verbose information to stderr during capture.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print verbose information about the capture process to stderr.<br><br><b><b>-y</b> <i><linktype></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the data link type to use while capturing. Use <b>-L</b> to see available link types for an interface.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<b>dumpcap</b> is the command-line packet capture tool that comes with the Wireshark suite. It is designed for high-performance, low-overhead packet capturing, making it the underlying engine used by both <b>Wireshark</b> (the graphical user interface) and <b>tshark</b> (the command-line analyzer). Unlike <b>Wireshark</b> or <b>tshark</b>, <b>dumpcap</b> itself does not perform any protocol analysis or display packets during capture (unless specifically requested via an option). Its primary function is to capture raw network traffic from a specified interface and write it to a <i>pcap</i> or <i>pcapng</i> file for later analysis. This separation of capture from analysis allows <b>dumpcap</b> to be very efficient and suitable for long-term or high-volume captures, often requiring root privileges to operate on network interfaces.


title: CAVEATS
content:
Most <b>dumpcap</b> operations, particularly those involving network interface capture, require root privileges or equivalent permissions (e.g., through <i>sudo</i> or by being part of the <i>wireshark</i> user group).<br><b>dumpcap</b> focuses purely on capturing; it does not analyze or dissect packets itself. For analysis, the captured files must be opened in <b>Wireshark</b> or processed by <b>tshark</b>.<br>Capturing to disk can consume significant storage, especially for high-traffic networks or long durations. Ensure adequate disk space is available, and consider using snapshot lengths or ring buffers to manage file sizes.


title: PARAMETERS
content:
<b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Print block group descriptors.</I><br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display feature flags.</I><br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display block group statistics for each group.</I><br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display only the superblock information, omitting block group descriptors.</I><br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display the inodes table. This option typically requires a specific inode number or range to be specified, often in conjunction with <b>-o</b> or <b>-O</b>.</I><br><br><b><b>-o</b> <I>superblock=num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Use an alternative superblock located at block <i>num</i> for analysis.</I><br><br><b><b>-O</b> <I>feature[,...]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Only display information about the specified filesystem <i>feature</i> (e.g., <i>has_journal</i>).</I><br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Display raw filesystem block numbers.</I><br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Print the version number of <b>dumpe2fs</b>.</I><br><br>


title: DESCRIPTION
content:
<b>dumpe2fs</b> is a utility for displaying detailed information about the superblock and block group descriptors of an ext2, ext3, or ext4 filesystem. It's an invaluable tool for filesystem diagnostics, understanding its layout, and verifying various parameters.<br>It provides insights into features like journaling status, inode count, block size, fragmentation, and timestamps. It can be used to examine a filesystem on a block device or a regular file containing a filesystem image. The output includes information about block groups, inode tables, free blocks, and free inodes, helping administrators troubleshoot filesystem issues or optimize its performance.


title: CAVEATS
content:
<b>dumpe2fs</b> operates in a read-only mode and does not modify the filesystem. However, it often requires root privileges to read directly from block devices like <I>/dev/sda1</I>.<br>It is designed specifically for ext2, ext3, and ext4 filesystems and will not work with other filesystem types such as XFS, Btrfs, or NTFS. For consistent output, it's advisable to ensure the device is not actively being written to, although the operation is read-only.


title: OUTPUT INTERPRETATION
content:
<I>The output of <b>dumpe2fs</b> can be extensive and highly detailed. It provides information on various aspects of the filesystem, including its superblock (containing global parameters like inode count, block size, and last mounted time), and granular details for each block group (such as free blocks, free inodes, and the location of inode tables). Understanding this output is crucial for advanced filesystem debugging, performance analysis, and optimization.</I>


title: USAGE WITH FILESYSTEM IMAGES
content:
<I>Beyond physical devices, <b>dumpe2fs</b> can effectively inspect filesystem images stored in regular files. This capability is particularly useful for forensic analysis, debugging filesystem corruption in non-live environments, or working with virtual machine disk images without needing to mount them, providing a safe and convenient way to analyze filesystem structures.</I>


title: HISTORY
content:
<b>dumpe2fs</b> is part of the <I>e2fsprogs</I> package, a collection of essential utilities for the ext2/ext3/ext4 filesystem. Developed and maintained by Theodore Ts'o since the early 1990s, <I>e2fsprogs</I> has been fundamental to Linux's filesystem management. <b>dumpe2fs</b> specifically provides diagnostic capabilities, evolving with the <I>ext</I> filesystem versions from ext2 to ext4, incorporating support for new features like journaling and extended attributes, making it a longstanding and reliable tool for filesystem analysis.


title: SYNOPSIS
content:
There is <i>no standard command-line synopsis</i> for <b>'dumper'</b> because it is not a standard Linux utility. <br><br>If you are looking for a command to 'dump' data, you should specify the type of data (e.g., filesystem, network packets, disk contents, database) to find the appropriate standard tool.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;There are <i>no standard parameters</i> for a generic command named <b>'dumper'</b>, as it is not a recognized Linux utility.<br><br>


title: DESCRIPTION
content:
The command <b>'dumper'</b> is <i>not a recognized or standard utility</i> found in typical Linux distributions. <br><br>When users refer to 'dumper', they often misremember or are referring to other commands that perform 'dumping' operations, which involves extracting or displaying data in a raw or formatted manner. Common commands that fit this description include: <br><b>dump(8)</b>: A utility for backing up Linux filesystems. <br><b>tcpdump(1)</b>: A powerful command-line packet analyzer used to capture and display network traffic. <br><b>dd(1)</b>: The 'disk duplicator', used for converting and copying files, often for creating disk images or extracting raw data from devices. <br><b>dumpe2fs(8)</b>: Displays superblock and block group information for ext2/ext3/ext4 filesystems. <br><br>It's also possible that <b>'dumper'</b> refers to a <i>custom script or an application-specific utility</i> within a particular software environment (e.g., a database dumper, a memory dumper for a specific application). Without specific context, the term <b>'dumper'</b> is ambiguous in the Linux command-line environment.


title: CAVEATS
content:
The primary caveat is that <b>'dumper'</b> is <i>not a standard Linux command</i>. Therefore, it has no predefined behavior, options, or manual pages. Any tool or script found named <b>'dumper'</b> would be a <i>custom or application-specific implementation</i>. Its functionality, security implications, and stability would depend entirely on its source and how it was created or deployed.


title: POSSIBLE INTENTS AND ALTERNATIVES
content:
If you were seeking a command to 'dump' specific types of information, consider these common alternatives: <br><b>Filesystem Backup/Archive</b>: Use <b>dump(8)</b>, <b>tar(1)</b>, <b>rsync(1)</b>. <br><b>Network Traffic Analysis</b>: Use <b>tcpdump(1)</b>, <b>tshark(1)</b> (part of Wireshark). <br><b>Disk/Partition Imaging</b>: Use <b>dd(1)</b>, <b>partclone(8)</b>, <b>fsarchiver(8)</b>. <br><b>Database Export</b>: Use database-specific utilities like <b>mysqldump(1)</b> for MySQL or <b>pg_dump(1)</b> for PostgreSQL. <br><b>Memory/Core Dump Analysis</b>: Use <b>gdb(1)</b> for debugging programs, or specialized tools like <b>crash(8)</b> for kernel dumps. <br><b>Filesystem Metadata Inspection</b>: Use <b>dumpe2fs(8)</b> for ext filesystems, or <b>debugfs(8)</b> for interactive filesystem debugging. <br><b>Program Debugging/Tracing</b>: Use <b>strace(1)</b> to trace system calls, or <b>ltrace(1)</b> to trace library calls.


title: HISTORY
content:
As <b>'dumper'</b> is <i>not a standard Linux command</i>, there is no common historical development or usage associated with a generic utility by this name. The history of any specific tool or script named <b>'dumper'</b> would be tied to its individual project or development context, separate from the core Linux utilities.


title: SEE ALSO
content:
dump(8), restore(8), tcpdump(1), dd(1), dumpe2fs(8), mysqldump(1), pg_dump(1), objdump(1), strace(1), gdb(1)


title: PARAMETERS
content:
<b>-c, --console-codes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump the kernel's table of console control sequences.<br><br><b>-fn, --full-numbers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print all numbers (keysyms, keycodes, etc.) in hexadecimal format rather than decimal.<br><br><b>-s, --short-composition</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print only the first key for multi-key (compose) sequences, shortening the output.<br><br><b>-t, --tables</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the kernel's action code tables, which can be useful for debugging.<br><br><b>-u, --unicode</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump Unicode values for dead keys and composite keys, rather than keysyms.<br><br><b>-n, --numeric</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print keysyms numerically (in hexadecimal) instead of their symbolic names.<br><br><b>-r, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the raw scan code to keycode mapping table. This is the lowest level of keyboard mapping.<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:
The <b>dumpkeys</b> command is a utility used on Linux systems to display the current keyboard translation table, also known as the keymap, loaded into the kernel. This keymap defines how raw scan codes generated by the keyboard hardware are interpreted and translated into key symbols (keysyms) and actions.<br><br>The primary purpose of <b>dumpkeys</b> is to output this keymap in a human-readable format, suitable for analysis, backup, or subsequent modification and reloading using the <b>loadkeys</b> command. It's particularly useful for understanding the behavior of special keys, modifier states (Shift, Ctrl, Alt), and dead keys.<br><br>By default, <b>dumpkeys</b> outputs the keymap in a format similar to that used by keymap files, allowing administrators and users to inspect or troubleshoot keyboard layouts on the virtual consoles. It operates at the kernel level, distinct from graphical environment keymap utilities like <b>xmodmap</b> or <b>setxkbmap</b>.


title: CAVEATS
content:
<b>dumpkeys</b> primarily interacts with the kernel's console keymap and is therefore relevant for the Linux text console (TTYs) rather than graphical environments like X Window System. For X, utilities such as <b>xmodmap</b> or <b>setxkbmap</b> are used.<br><br>While dumping the keymap usually doesn't require elevated privileges, modifying or loading a keymap using <b>loadkeys</b> typically requires root access or appropriate permissions.


title: OUTPUT FORMAT
content:
The output of <b>dumpkeys</b> is designed to be directly readable by the <b>loadkeys</b> command. This allows users to save the current keymap to a file, edit it, and then reload the modified keymap. For example, to save the current keymap to a file named 'mykeymap.map', you would run 'dumpkeys > mykeymap.map'. To later load this map, you would use 'sudo loadkeys mykeymap.map'.


title: HISTORY
content:
<b>dumpkeys</b> is an integral part of the <b>kbd</b> package, a collection of Linux console tools for configuring the keyboard and console fonts. It has been a fundamental utility for managing keyboard layouts on the Linux console since the early days of the kernel's keyboard support. Its design reflects the need for a persistent, easily modifiable text-based keymap system, allowing users to customize their console keyboard behavior without needing a graphical environment.


title: PARAMETERS
content:
<b><b><I>SERVICE</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the system service to dump. If omitted, `dumpsys` dumps information from all available services. Common examples include `activity`, `battery`, `meminfo`, `wifi`, `power`, `input`, `window`, etc.<br><br><b><b><I>ARGUMENTS</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments specific to the chosen `SERVICE`. Many services support `-h` or `--help` to display service-specific options. Other common arguments include `--checkin` for machine-readable output or `-a` for all information (e.g., with `meminfo`).<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available system services that `dumpsys` can query. This is useful for discovering which services can be targeted.<br><br><b><b>-t</b> <I>TIMEOUT_MS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout in milliseconds for the dump operation. If the dump takes longer than the specified timeout, it will be aborted, preventing indefinite hangs.<br><br><b><b>--skip-services</b> <I>SERVICE1,SERVICE2,...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When dumping all services, this option allows specifying a comma-separated list of services to exclude from the output, useful for reducing verbosity.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly requests dumping of all services. This is the default behavior if no `SERVICE` is specified, so it is often redundant but can be used for clarity.<br><br><b><b>-h</b> or <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the top-level usage information for the `dumpsys` command, including available options and basic syntax.<br><br>


title: DESCRIPTION
content:
The `dumpsys` command is a powerful diagnostic tool used on Android devices to retrieve detailed information about the state of various system services. It is typically invoked via `adb shell` from a host computer or directly on the device's shell. By default, running `dumpsys` without any arguments will output a massive amount of information about all running system services, including activity management, memory usage, battery stats, network connectivity, display settings, and more. This verbose output makes it an indispensable utility for Android developers, QA engineers, and system administrators to debug performance issues, identify resource leaks, analyze battery drain, and gain deep insights into the device's current operational state. Each system service provides its own specific diagnostic data, making `dumpsys` a versatile tool for troubleshooting a wide array of Android-specific problems.


title: CAVEATS
content:
The output of `dumpsys` is typically very verbose and unstructured, often requiring piping through command-line tools like `grep`, `less`, or redirection to a file for effective analysis. Its output format can vary between Android versions and device manufacturers, making parsing challenging. Understanding the meaning of specific output lines often requires deep knowledge of Android internals. `dumpsys` is an Android-specific command and is not part of standard Linux distributions.


title: COMMON USAGE PATTERNS
content:
The command is most frequently used with specific service names to narrow down the diagnostic output. Common examples include:<br><b><I>adb shell dumpsys activity</I></b>: Dumps information about the Activity Manager, including task stacks, recent activities, and process states.<br><b><I>adb shell dumpsys battery</I></b>: Provides detailed battery statistics, including current level, health, temperature, and historical power usage.<br><b><I>adb shell dumpsys meminfo</I></b> <I>package_name</I>: Shows memory usage for a specific application or all processes, helping identify memory leaks or excessive consumption.<br><b><I>adb shell dumpsys gfxinfo</I></b> <I>package_name</I>: Dumps graphics performance statistics for an app, useful for diagnosing UI jank and rendering issues.<br><b><I>adb shell dumpsys wifi</I></b>: Displays Wi-Fi service state, configured networks, connection statistics, and scan results.<br>Often, the output is piped to `grep` to filter for specific lines, e.g., `adb shell dumpsys battery | grep 'level'` to quickly find the battery percentage.


title: HISTORY
content:
`dumpsys` has been a fundamental diagnostic utility within the Android operating system since its early development stages. Its evolution has closely paralleled the growth of Android itself, with new system services gaining `dumpsys` capabilities as the OS expanded in features and complexity. While its core function of querying system service states has remained consistent, the breadth and depth of information it can provide have significantly increased over time, solidifying its role as an indispensable tool for Android development and debugging.


title: SYNOPSIS
content:
<i>dune</i> <command> [<i>options</i>]<br><br><b>Common commands:</b><br>&nbsp;&nbsp;&nbsp;<i>dune build</i> [TARGET]<br>&nbsp;&nbsp;&nbsp;<i>dune runtest</i><br>&nbsp;&nbsp;&nbsp;<i>dune exec</i> <PROGRAM> [ARGS]<br>&nbsp;&nbsp;&nbsp;<i>dune install</i><br>&nbsp;&nbsp;&nbsp;<i>dune clean</i><br>&nbsp;&nbsp;&nbsp;<i>dune help</i> [COMMAND]


title: PARAMETERS
content:
<b>-p, --profile <PROFILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the build profile (e.g., 'dev', 'release').<br><br><b>--root <DIR></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the root directory of the workspace.<br><br><b>--watch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Watch for file changes and rebuild automatically.<br><br><b>--display <MODE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the display mode of output (e.g., 'short', 'quiet', 'verbose').<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a rebuild of all targets, ignoring cached results.<br><br>


title: DESCRIPTION
content:
<i>Dune</i> is a sophisticated and highly efficient build system specifically crafted for <b>OCaml</b> and <b>Reason</b> projects.<br>It aims to streamline and automate the entire development workflow, from compiling source code to running tests and generating documentation.<br>Unlike general-purpose build tools, <i>Dune</i> is opinionated and leverages the structure of OCaml projects to provide sensible defaults, significantly reducing the amount of explicit configuration required. Its core strengths include automatic dependency tracking, parallel execution for faster builds, and ensuring reproducibility across diverse environments.<br><i>Dune</i> operates by reading simple `dune` configuration files (S-expressions) placed within project directories, making project setup intuitive and maintainable. It has become the de-facto standard for building OCaml software, replacing older, more complex solutions.


title: CAVEATS
content:
<i>Dune</i> is tightly coupled with the <b>OCaml</b> and <b>Reason</b> programming languages.<br>It is not a general-purpose build system for other languages or system-level tasks. A functional <b>OCaml</b> toolchain (typically managed by <i>opam</i>) must be installed for <i>Dune</i> to operate correctly.


title: SUBCOMMAND-BASED OPERATION
content:
<i>Dune</i> is invoked using a subcommand-based interface. Instead of a single command with many options, specific tasks are handled by distinct subcommands (e.g., <i>dune build</i>, <i>dune runtest</i>), making its usage modular and clear.


title: DECLARATIVE CONFIGURATION WITH 'DUNE' FILES
content:
Project configuration in <i>Dune</i> is managed through declarative 'dune' files. These S-expression-based files, placed in relevant directories, describe libraries, executables, tests, and other project artifacts, simplifying project setup and ensuring portability.


title: HISTORY
content:
<i>Dune</i> evolved from <i>Jenga</i>, an internal build system developed at <b>Jane Street</b>, a prominent user of OCaml.<br>Initially open-sourced as <i>Jbuilder</i>, it was later renamed <i>Dune</i> to reflect its broader vision and independent identity within the OCaml ecosystem. Since its inception, it has rapidly become the community's preferred and effectively standard build tool for OCaml, replacing older, more disparate build approaches like custom <i>Makefiles</i> or <i>ocamlbuild</i>.


title: PARAMETERS
content:
<b><b>history</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the notification history. Can be combined with <b>--json</b> for structured output.<br><br><b><b>close</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes the currently displayed notification.<br><br><b><b>close-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Closes all currently displayed notifications.<br><br><b><b>dismiss</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dismisses the oldest notification from the history, marking it as viewed.<br><br><b><b>action</b> <i>&lt;index&gt; &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invokes a specific action by its name on a notification identified by its index in the displayed list or history.<br><br><b><b>is-paused</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the <i>dunst</i> daemon is currently paused. Returns 'true' or 'false'.<br><br><b><b>set-paused</b> <i>&lt;true|false&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pauses or unpauses the <i>dunst</i> notification daemon, preventing or allowing new notifications to be displayed.<br><br><b><b>count</b> [<i>displayed|waiting|history</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Counts notifications by their state: <b>displayed</b> (currently visible), <b>waiting</b> (in queue), or in <b>history</b>.<br><br><b><b>debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps extensive internal debug information from the <i>dunst</i> daemon, useful for troubleshooting.<br><br><b><b>rule</b> <i>&lt;name&gt; &lt;key&gt; &lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dynamically adds or modifies a notification rule by its name, setting a specific key to a given value.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>dunstctl</i>'s usage information and a list of available commands.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of <i>dunstctl</i> and the connected <i>dunst</i> daemon.<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Global option. Outputs command results in JSON format for commands that support it (e.g., <b>history</b>, <b>count</b>).<br><br>


title: DESCRIPTION
content:
<i>dunstctl</i> is a command-line utility used to interact with a running instance of the <i>dunst</i> notification daemon. It provides a programmatic interface to manage notifications, allowing users to close, dismiss, view history, or dynamically set rules for notifications without needing to interact with the graphical notification pop-ups directly.<br><br>This is particularly useful for scripting, keyboard shortcuts, or integrating with other desktop tools. <i>dunstctl</i> communicates with <i>dunst</i> via a Unix domain socket, making it efficient and responsive. It's an essential companion for users who rely on <i>dunst</i> for their desktop notifications and desire fine-grained control over them, allowing for complex automation and management workflows.


title: CAVEATS
content:
<b>caveats</b>: <i>dunstctl</i> requires a running <i>dunst</i> daemon to connect to; it cannot start <i>dunst</i>.<br>Communication relies on a Unix domain socket, typically located at <i>/tmp/dunstsock</i>, which must be accessible.<br>Dynamic rules set via <b>dunstctl rule</b> are temporary and are not persistent across <i>dunst</i> daemon restarts. They only affect the current session.<br>Operations are performed on the live <i>dunst</i> instance, not on its configuration file.


title: COMMUNICATION MECHANISM
content:
<i>dunstctl</i> communicates with the <i>dunst</i> daemon via a Unix domain socket. This method ensures efficient and secure inter-process communication on the local system. The socket path is typically configured by <i>dunst</i> itself, making connection seamless for <i>dunstctl</i>.


title: SCRIPTING AND AUTOMATION
content:
Due to its clear command-line interface and the availability of the <b>--json</b> output option, <i>dunstctl</i> is exceptionally well-suited for scripting. It allows users to automate notification management tasks, integrate notification information into status bars (e.g., polybar, i3status), or create custom keyboard shortcuts for quick control over notifications.


title: HISTORY
content:
<i>dunstctl</i> was introduced as the official command-line control utility for the <i>dunst</i> notification daemon. <i>dunst</i> itself was created to be a lightweight, highly customizable, and dependency-free notification daemon, primarily for tiling window managers where fine-grained control is paramount. The development of <i>dunstctl</i> reflects the project's commitment to providing users with robust programmatic interaction capabilities, enhancing <i>dunst</i>'s utility beyond just displaying pop-ups by enabling advanced automation, scripting, and integration with desktop environments and keyboard shortcuts.


title: PARAMETERS
content:
<b>-A <name>, --action <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines an action that can be activated from the notification. Useful for interactive notifications.<br><br><b>-a <appname>, --appname <appname></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default application name associated with the notification.<br><br><b>-c <category>, --category <category></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the notification category (e.g., 'device', 'email'). Affects rules in Dunst configuration.<br><br><b>-D, --close-on-click</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the notification close automatically when clicked.<br><br><b>-h <type:name:value>, --hint <type:name:value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a hint for the notification daemon. Common types include 'int', 'string', 'double', 'byte', 'boolean'. Examples: 'int:value:100' for progress.<br><br><b>-i <icon>, --icon <icon></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an icon to display alongside the notification. Can be a path to an image file or a themed icon name.<br><br><b>-I <id>, --id <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific ID for the notification. This ID can be used to replace or update the notification later.<br><br><b>-N, --no-focus</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the notification from attempting to switch focus to the associated application.<br><br><b>-p, --printid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the unique ID of the sent notification to standard output.<br><br><b>-r <id>, --replace <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replaces an existing notification with the specified ID with the new one.<br><br><b>-s, --sticky</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the notification 'sticky', meaning it will not automatically time out and must be closed manually.<br><br><b>-t <timeout>, --timeout <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout duration for the notification in milliseconds after which it automatically disappears.<br><br><b>-u <level>, --urgency <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the urgency level of the notification. Possible levels are 'low', 'normal', or 'critical'. This often affects its appearance.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <I>dunstify</I> version information.<br><br><b>-H, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and usage.<br><br>


title: DESCRIPTION
content:
<i>dunstify</i> is a command-line utility designed to send notifications to the <I>Dunst</I> notification daemon, a highly customizable and lightweight notification manager. It offers a straightforward interface for generating transient desktop notifications, allowing users to specify a wide array of attributes such as urgency level, display timeout, associated icon, and interactive actions. This tool is commonly employed in shell scripts, cron jobs, or directly from the command line to provide users with timely information, alerts, or status updates regarding system events or application processes. <br><br>As an integral part of the <I>Dunst</I> ecosystem, <i>dunstify</i> acts as a more powerful and flexible replacement for generic notification senders like <I>notify-send</I> for users who have <I>Dunst</I> installed. It fully leverages <I>Dunst</I>'s extensive configuration capabilities, enabling precise control over the visual appearance and behavioral aspects of notifications, ensuring a consistent and personalized user experience.


title: CAVEATS
content:
<i>dunstify</i> relies entirely on the <I>Dunst</I> notification daemon being active. If <I>Dunst</I> is not running in the background, notifications sent via <i>dunstify</i> will not be displayed, although the command itself might exit without an error.


title: SUMMARY VS. BODY
content:
The "summary" argument is mandatory and typically provides a concise title or headline for the notification. The optional "body" argument allows for a more detailed and longer message, which is usually displayed below the summary in the notification window.


title: HINT USAGE
content:
Hints (`-h`) provide a powerful way to send specific, non-standard information to <I>Dunst</I>. These hints can be used by <I>Dunst</I>'s rules to alter a notification's behavior or appearance, for instance, displaying a progress bar, marking a notification as transient, or specific visual cues based on <I>Dunst</I>'s configuration.


title: HISTORY
content:
The <I>dunstify</I> command is an integral part of the <I>Dunst</I> notification daemon project, which began development around 2012-2013. <I>Dunst</I> was created to provide a lightweight, highly configurable, and less intrusive alternative to existing notification systems, focusing on adherence to the Desktop Notification Specification. <i>dunstify</i> emerged as the primary command-line interface for sending notifications directly to this daemon, ensuring users could leverage <I>Dunst</I>'s advanced features from scripts and the terminal.


title: PARAMETERS
content:
<b><b>-r</b>, <b>--reflink</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deduplicate files using copy-on-write (reflink) if the filesystem supports it (e.g., Btrfs, XFS).<br><br><b><b>-s</b>, <b>--symlink</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace duplicate files with symlinks to a single original file.<br><br><b><b>-L</b>, <b>--hardlink</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace duplicate files with hardlinks to a single original file.<br><br><b><b>-d</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a scan and report potential deduplication savings without making any changes.<br><br><b><b>-h</b> <i>NUM</i>, <b>--hash-threads</b>=<i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of threads to use for hashing file contents (default: number of CPU cores).<br><br><b><b>-j</b> <i>NUM</i>, <b>--io-threads</b>=<i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of threads to use for I/O operations (default: 1).<br><br><b><b>-p</b>, <b>--print-dupes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the paths of identified duplicate files.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity, showing more detailed progress and information.<br><br><b><b>-z</b>, <b>--0bytes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add null bytes to the end of the input file list (for xargs -0).<br><br><b><b>-o</b>, <b>--omit-zero-length</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude zero-length files from the scan.<br><br><b><b>-A</b>, <b>--all-files</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scan all file types, including special files (default: only regular files).<br><br><b><b>-H</b> <i>TYPE</i>, <b>--hash</b>=<i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the hashing algorithm (e.g., 'murmur3', 'sha256').<br><br><b><b>-f</b>, <b>--fiemap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use FIEMAP ioctl to detect common extents on filesystems that support it (faster for block-level deduplication).<br><br><b><b>-P</b>, <b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a progress bar during scanning and deduplication.<br><br><b><b>-i</b>, <b>--inodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Process files based on their inode numbers, useful for hardlinked files.<br><br><b><b>-m</b>, <b>--match-size</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only compare files of the exact same size (faster but can miss some duplicates).<br><br><b><b>-x</b> <i>PATTERN</i>, <b>--exclude</b>=<i>PATTERN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the specified glob pattern.<br><br><b><b>--chunk-size</b>=<i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the chunk size for block-level deduplication (default: 128KB).<br><br><b><b>--size</b>=<i>BYTES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only process files larger than or equal to this size.<br><br><b><b>--dedupe-file</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deduplicate against a list of files from a specified file.<br><br><b><b>--hash-file</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read hashes from a specified file instead of calculating them.<br><br><b><b>--skip-gaps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip zero-filled gaps during block-level deduplication.<br><br><b><b>--dedupe-gaps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to deduplicate zero-filled gaps (requires --reflink).<br><br><b><b>--ignore-zeros</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore zero-filled blocks during hashing.<br><br><b><b>--sparse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create sparse files when writing, if applicable.<br><br><b><b>--read-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to write to any files or modify anything (similar to --dry-run but also applies to hash writing).<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>duperemove</i> is a command-line utility designed to find and deduplicate redundant data within a filesystem. It works by first scanning specified directories and hashing file contents to identify identical files or identical blocks within files. Subsequently, it can optionally replace duplicate files with shared data blocks using reflink (copy-on-write), hardlinks, or symlinks. Reflink-based deduplication is particularly efficient on filesystems like Btrfs or XFS, as it allows multiple files to share the same physical data blocks without creating multiple copies, saving significant disk space. The utility supports multi-threading for hashing and I/O operations to speed up the process and can perform a dry run to show potential savings before making any permanent changes. It's an invaluable tool for managing disk space on systems with many duplicate files, such as development environments, backups, or virtual machine images.


title: CAVEATS
content:
Using <i>duperemove</i> with options like <b>--reflink</b>, <b>--symlink</b>, or <b>--hardlink</b> modifies your filesystem. Always perform a <b>--dry-run</b> first to understand the potential impact and ensure no critical data is inadvertently affected. Reflink/copy-on-write functionality is only supported on specific filesystems such as Btrfs and XFS. Incorrect usage or interruptions during deduplication can lead to data loss or corruption, particularly if not using reflink and instead opting for symlinks/hardlinks which directly modify directory entries. Be mindful of potential performance overhead on very large datasets due to extensive hashing and I/O operations.


title: FILESYSTEM REQUIREMENTS FOR REFLINK
content:
The highly efficient reflink-based deduplication (<b>--reflink</b>) is a key feature of <i>duperemove</i>, but it is only supported by filesystems that implement copy-on-write functionality at the block level. The most common Linux filesystems supporting this are Btrfs and XFS (with reflink support enabled during formatting or mounting). On other traditional filesystems (e.g., Ext4, FAT, NTFS via FUSE), <i>duperemove</i> will only be able to perform symlink or hardlink-based deduplication, or simply report duplicates without performing structural changes.


title: DEDUPLICATION METHODS EXPLAINED
content:
<i>duperemove</i> offers several ways to handle identified duplicates:<br><br><b>Reflink (Copy-on-Write)</b>: This is the most recommended method for compatible filesystems. Files share physical data blocks, but appear as separate, independent files. Modifications to one file only affect its unique blocks, not the shared ones, by writing new data to new blocks. This method is space-efficient, safe, and transparent.<br><br><b>Symlinks</b>: One file is kept as the original, and all duplicate files are replaced by symbolic links pointing to the original. This saves space but can be inconvenient as symlinks behave differently from regular files (e.g., when moving or backing up).<br><br><b>Hardlinks</b>: One file is kept, and all duplicates are replaced by hardlinks to the original. This saves space and files appear as regular files. However, hardlinks are restricted to the same filesystem, and the data is only truly freed when the last hardlink pointing to the inode is removed.


title: HISTORY
content:
<i>duperemove</i> was initially developed by Adam Borowski and later maintained by Joseph Salisbury and other contributors. Its development was heavily influenced by the growing adoption of modern Linux filesystems like Btrfs and XFS, which offer native copy-on-write (CoW) capabilities. The command arose from the need for efficient block-level deduplication tools to manage disk space, especially for use cases involving multiple copies of similar data (e.g., virtual machine images, incremental backups, software development environments). The command's focus shifted from simple file-level deduplication (like symlinking) to leveraging CoW to save space without altering file paths or breaking applications that expect separate files.


title: SYNOPSIS
content:
<b>duplicacy</b> &lt;<i>command</i>&gt; [<i>options</i>] [<i>arguments</i>]<br><br>Examples:<br><b>duplicacy</b> <b>init</b> &lt;<i>storage_url</i>&gt; &lt;<i>repository_id</i>&gt;<br><b>duplicacy</b> <b>backup</b><br><b>duplicacy</b> <b>restore</b> -r &lt;<i>revision</i>&gt; -to &lt;<i>path</i>&gt;<br><b>duplicacy</b> <b>prune</b> -keep &lt;<i>policy_args</i>&gt;


title: PARAMETERS
content:
<b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operation.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing extensive logging for troubleshooting.<br><br><b>-c &lt;<i>repository_path</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the repository if the command is not run from the repository root directory.<br><br><b>-storage &lt;<i>storage_url</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default storage URL configured for the repository.<br><br><b>-r &lt;<i>revision</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular snapshot revision number for commands like <b>restore</b>, <b>diff</b>, or <b>cat</b>.<br><br><b>-repository &lt;<i>repository_id</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the repository ID, useful when multiple repositories share the same storage.<br><br><b>(subcommand-specific options)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Each <i>duplicacy</i> subcommand (e.g., <b>init</b>, <b>backup</b>, <b>restore</b>, <b>prune</b>) has its own set of unique options. These can include options for encryption, include/exclude patterns, target paths, VSS support, or retention policies specific to that command.<br><br>


title: DESCRIPTION
content:
<i>duplicacy</i> is a robust, cross-platform cloud backup tool designed for efficiency and security. It offers client-side, AES-256 encryption and block-level deduplication, which significantly reduces storage space by identifying and storing identical data blocks only once, even across different backups. It supports a wide array of cloud storage providers, including Amazon S3, Google Cloud Storage, Azure Blob Storage, Dropbox, OneDrive, SFTP, and WebDAV, as well as local storage. Its snapshot-based approach allows for easy restoration to any previous state, while its incremental backup model ensures fast operation by only backing up changed data chunks. Written in Go, the command-line interface (CLI) is open-source, providing powerful and flexible control over your backup strategy.


title: CAVEATS
content:
While powerful, <i>duplicacy</i>'s performance with an extremely large number of very small files can be impacted by chunking overhead. The default glob-based include/exclude patterns can sometimes be unintuitive for users expecting regular expressions. The open-source CLI version does not include a graphical user interface; a commercial Web UI is available separately.


title: BLOCK-LEVEL DEDUPLICATION
content:
<i>duplicacy</i> performs content-defined chunking and deduplicates data at the block level across all snapshots and repositories pointing to the same storage. This means if the same file (or even parts of files) exist in multiple backups or repositories, they are only stored once, leading to significant storage savings.


title: CLIENT-SIDE ENCRYPTION
content:
All data is encrypted on the client side using AES-256-CTR with a passphrase-derived key before being uploaded to storage. This ensures that your data remains secure even if your cloud storage provider is compromised, as the data is unreadable without your passphrase.


title: SNAPSHOT MANAGEMENT
content:
Every backup creates an immutable snapshot, identified by a revision number. These snapshots are lightweight as they only store metadata and references to data chunks. This allows for easy navigation, restoration, and pruning of specific backup states without affecting other snapshots.


title: CLOUD AGNOSTIC DESIGN
content:
Beyond supporting various cloud providers, <i>duplicacy</i>'s design allows for flexible movement of data between different storage backends, or even copying snapshots from one storage to another, enhancing portability and disaster recovery options.


title: HISTORY
content:
<i>duplicacy</i> was developed by Gilbert Chen, with its initial public release around 2016. It was designed from the ground up to address the limitations of traditional backup solutions, focusing on modern cloud storage paradigms, efficient deduplication, and strong encryption. Written in Go, it quickly gained popularity in the cloud backup community for its performance and feature set.


title: SYNOPSIS
content:
<b>duplicity</b> [<i>options</i>] <i>source_directory target_url</i> <br><b>duplicity</b> [<i>options</i>] <i>target_url restore_directory</i> <br><b>duplicity</b> [<i>options</i>] <<i>command</i>> <i>target_url</i><br><br><i>Common commands:</i> <br>  <b>full</b>: Perform a full backup. <br>  <b>incremental</b>: Perform an incremental backup (default). <br>  <b>restore</b>: Restore files from a backup. <br>  <b>collection-status</b>: Show status of a backup chain. <br>  <b>cleanup</b>: Remove redundant or incomplete backup sets.


title: PARAMETERS
content:
<b>--encrypt-key <key_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GPG key ID for encryption. Essential for secure backups.<br><br><b>--sign-key <key_id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the GPG key ID for signing the backup. Ensures data integrity and authenticity.<br><br><b>--exclude <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the specified path pattern from the backup.<br><br><b>--include <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include files or directories matching the specified path pattern, even if previously excluded.<br><br><b>--full-if-older-than <time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a full backup if the last full backup is older than the specified time (e.g., '1M' for 1 month).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the execution of an action, even if it might seem unsafe.<br><br><b>--no-encryption</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable GPG encryption for the backup. Use with caution, especially for remote storage.<br><br><b>--s3-aws-id <ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the AWS Access Key ID for S3 backend authentication.<br><br><b>--s3-aws-secret-key <key></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the AWS Secret Access Key for S3 backend authentication.<br><br><b>--ssh-options <options></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass specific options directly to the underlying SSH command for SCP/SFTP backends.<br><br><b>--gpg-options <options></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass specific options directly to the GnuPG command.<br><br><b>--verbosity <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the verbosity level of output messages (e.g., 'info', 'warning', 'error').<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate the backup or restore operation without making any actual changes.<br><br><b>--file-to-restore <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, specify a particular file or directory within the backup to restore.<br><br><b>--time <time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, restore the state of files as they were at a specific time (e.g., '2023-01-01', 'now - 1D').<br><br><b>--remove-older-than <time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove backup sets older than the specified time from the target. Often used with 'cleanup'.<br><br><b>--list-current-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the files present in the latest full or incremental backup set on the target.<br><br>


title: DESCRIPTION
content:
<b>duplicity</b> is a powerful, free software backup utility that creates encrypted, digitally signed, incremental archives of files and directories. It leverages the <i>rsync</i> algorithm to efficiently store only the changes between backups, minimizing bandwidth and storage requirements. Backups can be stored on a variety of local or remote file servers, including SSH/SCP, FTP, Amazon S3, Google Drive, WebDAV, and local filesystems. It uses the <i>GnuPG</i> (GPG) framework for robust encryption and signing, ensuring data confidentiality and integrity. <br><br> The first backup is a full backup, and subsequent backups are incremental, storing only the differences relative to the previous backup. This chain of backups allows for efficient storage and restoration to any point in time covered by the backup chain. Its versatility and strong security features make it an excellent choice for off-site disaster recovery plans.


title: CAVEATS
content:
Using <b>duplicity</b> effectively requires careful management of <i>GnuPG</i> keys; loss of encryption keys means permanent data loss. Ensure GPG agent is running and keys are accessible. <br><br> For incremental backups, all segments in a chain (from the last full backup) are necessary for a complete restore. Incomplete or corrupted segments can compromise the entire chain. <br><br> It typically requires significant temporary disk space on the local machine for caching and processing, potentially matching the size of the source data during full backups or restores. <br><br> While powerful, configuring specific backend URLs and authentication can sometimes be complex and requires understanding of the target storage system.


title: BACKEND URL FORMATS
content:
The <i>target_url</i> specifies where backups are stored. Common formats include:<br><b>file:///path/to/local/dir</b>: Local filesystem.<br><b>scp://user@host[:port]/path/to/dir</b>: Secure Copy Protocol (SSH).<br><b>sftp://user@host[:port]/path/to/dir</b>: SSH File Transfer Protocol.<br><b>ftp://user:password@host[:port]/path/to/dir</b>: File Transfer Protocol.<br><b>ftps://user:password@host[:port]/path/to/dir</b>: FTP over SSL/TLS.<br><b>s3://bucket_name[/path]</b>: Amazon S3 cloud storage.<br><b>webdav://user:password@host[:port]/path/to/dir</b>: Web Distributed Authoring and Versioning.


title: BACKUP CHAIN CONCEPT
content:
<b>duplicity</b> builds a 'backup chain'. The first backup is a <i>full</i> backup. Subsequent backups are <i>incremental</i>, storing only the changes relative to the previous backup in the chain. To restore to any point in time, <b>duplicity</b> reconstructs the desired state by applying all relevant incremental changes on top of the last full backup. This chaining mechanism is highly efficient in terms of storage but means that all parts of the chain must be intact for successful restoration.


title: HISTORY
content:
<b>duplicity</b> was initially developed by <i>Kenneth Loafman</i>, with its first public release appearing around 2001-2002. Written in Python, it quickly gained traction as a reliable and secure tool for managing off-site backups due to its unique combination of incremental backups, strong encryption, and digital signing. Its design philosophy of using standard tools like <i>rsync</i> and <i>GnuPG</i> for its core functionality contributed to its robustness and adoption. It has since been continuously maintained and updated by a community of developers, evolving to support new storage backends and features, cementing its position as a cornerstone in Linux system administration for secure data archival.


title: PARAMETERS
content:
<b>-h, --human-readable</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display sizes in human-readable format (e.g., 1K, 234M, 2G). This is the default behavior.<br><br><b>-d, --depth <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the display to a certain directory depth, showing only items up to N levels deep from the starting path.<br><br><b>-x, --one-file-system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude directories on different file systems. This prevents scanning network mounts or other partitions.<br><br><b>-L, --dereference</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Follow symbolic links. By default, symbolic links are not followed.<br><br><b>-E, --exclude <PATTERN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files or directories matching the specified PATTERN. Multiple exclude patterns can be provided.<br>Example: <code>dust -E "*.log"</code><br><br><b>-t, --threshold <SIZE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show entries larger than the specified SIZE. Accepts human-readable sizes (e.g., 10M, 1G).<br><br><b>--total</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a grand total disk usage at the bottom of the output.<br><br><b>-p, --progress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a progress bar while scanning the file system, useful for large directories.<br><br><b>-n, --no-color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output, useful for scripts or terminals with limited color support.<br><br><b>-r, --reverse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort output in reverse order, displaying the smallest entries first.<br><br><b>--si</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use SI units (base 1000, e.g., KB, MB, GB) instead of binary units (base 1024, e.g., KiB, MiB, GiB).<br><br>


title: DESCRIPTION
content:
<b>dust</b> (<i>Disk Usage Tree</i>) is a command-line tool written in <I>Rust</I> that serves as a modern and more visually appealing alternative to the traditional <I>du</I> command. It provides a tree-like visualization of disk usage, making it easier to identify large files and directories at a glance. Key features include color-coded output for readability, human-readable sizes by default, efficient performance due to its Rust implementation, and the ability to filter and sort results. While <I>du</I> focuses on raw data, <I>dust</I> prioritizes user experience with its hierarchical and often more intuitive presentation of disk space consumption. It's particularly useful for quickly understanding disk space distribution.


title: CAVEATS
content:
<b>dust</b> is not a standard Linux utility and must be installed separately (e.g., via a package manager like <code>cargo</code> or <code>apt</code> on some distributions). Its highly formatted, color-coded output is designed for human readability and may not be suitable for programmatic parsing, unlike the more consistent output of the traditional <I>du</I> command.


title: NCDU EXPORT MODE
content:
<b>dust</b> includes an option (<code>-X</code> or <code>--ncdu-export</code>) to export the scan results in a JSON format compatible with <I>ncdu</I>, an ncurses-based disk usage analyzer. This allows users to generate data with <I>dust</I>'s speed and then explore it interactively using <I>ncdu</I>'s text-based graphical interface, combining the strengths of both tools.


title: HISTORY
content:
<b>dust</b> is a relatively new command-line utility, developed in <I>Rust</I> to offer a modern, faster, and more user-friendly alternative to the long-standing <I>du</I> command. Its development began in the late 2010s, focusing on leveraging Rust's performance capabilities for efficient file system traversal and providing an improved visual experience for disk usage analysis, often featuring tree-like and color-coded outputs.


title: SYNOPSIS
content:
<code>dvc [GLOBAL_OPTIONS] &lt;COMMAND&gt; [COMMAND_OPTIONS] [ARGUMENTS]</code><br><br><i>Examples of common usage:</i><br><code>dvc init</code><br><code>dvc add data/raw_data.csv</code><br><code>dvc repro</code><br><code>dvc push</code><br><code>dvc pull</code>


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the top-level help message or help for a specific DVC command.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the DVC version.<br><br><b><b>--cd</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Change to <i>&lt;path&gt;</i> before executing the command. Useful for running DVC from a script or an arbitrary directory.<br><br><b><b>--config</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a path to a custom DVC configuration file to use instead of the default <code>.dvc/config</code>.<br><br><b><b>--global</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the global DVC configuration file (typically in the user's home directory).<br><br><b><b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the local (project-specific) DVC configuration file within the current DVC repository.<br><br><b><b>--no-scm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not look for an SCM (Source Code Management) repository like Git. Useful for DVC operations outside of a Git repo.<br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output from DVC, showing only errors.<br><br><b><b>--verbose</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be more verbose during command execution, providing detailed information about the process.<br><br>


title: DESCRIPTION
content:
DVC, short for <i>Data Version Control</i>, is an open-source command-line tool designed to make machine learning projects reproducible, shareable, and scalable. It extends traditional Git-based version control to handle large files, datasets, and machine learning models, which Git is not optimized for.<br><br>DVC works by creating small <code>.dvc</code> pointer files that are versioned by Git, while the actual large data and model files are stored in a DVC-managed cache and can be synced with various remote storage options (e.g., S3, Google Cloud Storage, Azure Blob Storage, SSH, local storage).<br><br>Key features include data and model versioning, management of reproducible ML pipelines via a <code>dvc.yaml</code> file, and experiment tracking. It helps in maintaining data provenance, facilitating collaboration among data scientists, and enabling MLOps workflows by ensuring that experiments and models can be easily recreated and deployed.


title: CAVEATS
content:
DVC is designed to <i>complement Git</i>, not replace it. It relies heavily on Git for versioning the project's codebase and the small <code>.dvc</code> pointer files. Users must be familiar with Git workflows.<br><br>Proper configuration of <i>remote storage</i> (e.g., AWS S3, Google Cloud Storage, Azure Blob Storage) is essential for sharing data and models effectively across teams or different environments.<br><br>While powerful, DVC can have a learning curve, especially for users new to data versioning concepts and distributed storage systems.


title: INTEGRATION WITH GIT
content:
DVC's fundamental design principle is its deep integration with Git. While Git efficiently versions source code, DVC handles large binary files (datasets, models) by storing them in a dedicated <i>cache</i> and in remote storage. It then places small <code>.dvc</code> files within the Git repository. These <code>.dvc</code> files serve as pointers, containing metadata and checksums of the actual large files. This hybrid approach allows Git to track the version of the data without storing the data itself, enabling efficient branching, merging, and cloning of ML projects with large datasets.


title: REPRODUCIBLE ML PIPELINES
content:
A core feature of DVC is its ability to define and execute <i>reproducible machine learning pipelines</i>. This is achieved through a <code>dvc.yaml</code> file, which describes the various stages of a data science workflow, such as data preprocessing, feature engineering, model training, and evaluation. DVC tracks the inputs, outputs, and dependencies for each stage. When inputs change, DVC intelligently re-runs only the necessary stages, ensuring that the entire workflow can be reproduced consistently. This promotes transparency, reduces errors, and significantly aids in experiment management and result validation.


title: HISTORY
content:
DVC was created by <i>Iterative.ai</i> and first publicly released in <b>2017</b>. It emerged from the growing need to apply software engineering best practices, particularly version control and continuous integration/delivery (CI/CD), to data-intensive machine learning projects. Its development has been consistently driven by an active open-source community, focusing on making ML development more reproducible, collaborative, and manageable at scale.


title: SEE ALSO
content:
git(1): Version control system for source code., mlflow(1): An open-source platform for managing the end-to-end machine learning lifecycle., lakefs(1): An open-source project that delivers Git-like branching and versioning for data lakes., pachctl(1): The command-line tool for Pachyderm, which provides data versioning and data pipelines for ML.


title: SYNOPSIS
content:
<i>dvc add [-h] [-q | -v] [--no-commit] [--file &lt;path&gt;] [--desc &lt;text&gt;] [--to-remote] [--external] [--glob] [--name &lt;name&gt;] [--hash {md5,etag}] [--no-size] [--no-hash] [--force] &lt;path&gt; [&lt;path&gt; ...]</i>


title: PARAMETERS
content:
<b><i>&lt;path&gt; [&lt;path&gt; ...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories to track.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b><i>-q</i>, <i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress output.<br><br><b><i>-v</i>, <i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be more verbose.<br><br><b><i>--no-commit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not automatically commit the generated <i>.dvc</i> file to Git.<br><br><b><i>--file &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path and name for the generated <i>.dvc</i> file. Defaults to <i>&lt;target_path&gt;.dvc</i>.<br><br><b><i>--desc &lt;text&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a description to the <i>.dvc</i> file, visible in <i>dvc status</i> and <i>dvc metrics show</i> (if applicable).<br><br><b><i>--to-remote</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an external file directly to remote storage without bringing it to the local cache first. Requires <i>--external</i>.<br><br><b><i>--external</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add files or directories located outside of the current DVC repository.<br><br><b><i>--glob</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the provided <i>&lt;path&gt;</i> as a glob pattern (e.g., <i>data/*.csv</i>).<br><br><b><i>--name &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assign a specific name to the added data item in the <i>.dvc</i> file, useful for directory outputs.<br><br><b><i>--hash {md5,etag}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Algorithm to use for hashing the data. Defaults to MD5.<br><br><b><i>--no-size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include size information in the <i>.dvc</i> file.<br><br><b><i>--no-hash</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include hash information in the <i>.dvc</i> file. Use with caution as it impacts data integrity checks.<br><br><b><i>--force</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite an existing <i>.dvc</i> file without prompting.<br><br>


title: DESCRIPTION
content:
<i>dvc add</i> is a fundamental DVC command used to register files or directories within a DVC repository. Instead of storing large data directly in Git, DVC stores it in a special local cache or a remote storage (like S3, GCS, etc.).<br><br>When you run <i>dvc add &lt;path&gt;</i>, DVC computes a content hash of the data, moves or copies the actual data to its cache, and then creates a small, lightweight <i>.dvc</i> text file (e.g., <i>data.dvc</i>) at the specified location. This <i>.dvc</i> file contains a pointer to the data in the cache, along with its hash, size, and other metadata.<br><br>This <i>.dvc</i> file is designed to be versioned with Git. By versioning these small metadata files in Git, DVC enables efficient tracking of large datasets and machine learning models, ensuring reproducibility and collaboration without bloating your Git repository. It's the essential first step to bring your data under DVC's control.


title: CAVEATS
content:
Adding very large files or directories with <i>dvc add</i> can be time-consuming due to the hashing and copying process to the DVC cache. By default, the original files are moved into the DVC cache; if you need to keep them in their original location, consider configuring DVC cache types (e.g., symlinks) or using <i>--external</i> for files already on external storage. Always remember to commit the generated <i>.dvc</i> file to Git after running <i>dvc add</i> (unless <i>--no-commit</i> is used) to ensure proper version tracking. <i>.dvc</i> files are critical metadata and should not be deleted.


title: THE <I>.DVC</I> FILE
content:
The primary output of <i>dvc add</i> is a small YAML file (e.g., <i>data.dvc</i>) that serves as a lightweight pointer to the actual data. This file contains crucial metadata such as the data's content hash (MD5 by default), its size, and the original path. These <i>.dvc</i> files are designed to be committed to Git. This allows Git to version the metadata of large files, which in turn enables DVC to retrieve the correct data from its cache or remote storage corresponding to any Git commit.


title: DVC CACHE
content:
When data is added with <i>dvc add</i>, it is typically moved or copied into a DVC-managed cache directory (usually <i>.dvc/cache</i> within the repository, or a shared global cache configured by <i>dvc config</i>). This cache stores data content-addressed, meaning identical files or directories added to DVC only occupy storage space once, thanks to deduplication. The <i>.dvc</i> file created by <i>dvc add</i> then points to this deduplicated, cached data.


title: HISTORY
content:
DVC (Data Version Control), launched by Iterative.ai in 2017, was developed to address the significant challenge of versioning large datasets and machine learning models, which traditional Git alone cannot handle efficiently. <i>dvc add</i> has been a core command since DVC's inception, fundamental to its operation. It embodies DVC's paradigm of versioning data by creating lightweight pointer files (<i>.dvc</i> files) that Git can manage, while DVC handles the actual data in its cache or remote storage. Its design has continuously evolved to support diverse storage backends, external data sources, and performance optimizations, solidifying its role as a cornerstone in modern MLOps workflows.


title: SEE ALSO
content:
<i>dvc run(1)</i>, <i>dvc push(1)</i>, <i>dvc pull(1)</i>, <i>dvc remove(1)</i>, <i>dvc status(1)</i>, <i>git add(1)</i>


title: SYNOPSIS
content:
<code>dvc checkout [<path>...] [options]</code> <br><br><i>Commonly used forms:</i><br><b>dvc checkout</b><br><b>dvc checkout</b> <i>my_data.dvc</i><br><b>dvc checkout</b> <i>data/features/</i><br><b>dvc checkout</b> <i>data.csv</i> <i>model.pkl</i>


title: PARAMETERS
content:
<b><I>[<path>...]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional: One or more paths to DVC-tracked files, directories, or .dvc files. If omitted, checks out all .dvc files in the current directory and subdirectories.<br><br><b><B>--relink</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces recreation of links or copies even if the target is already present and correct. Useful for fixing broken links or changing link types.<br><br><b><B>-q</B>, <B>--quiet</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output messages, showing only errors.<br><br><b><B>-v</B>, <B>--verbose</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more detailed information about the operation.<br><br><b><B>--jobs</B> <I><number></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of parallel jobs to run when materializing data. Defaults to 1 (no parallelism). Set to 0 to use all available CPU cores.<br><br><b><B>--no-run-cache</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the use of the DVC run cache when checking out stages. This means stages will be re-run instead of using cached outputs, if applicable.<br><br><b><B>--with-deps</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <I><path></I>, it will checkout not only the specified target(s) but also all their DVC-tracked dependencies.<br><br>


title: DESCRIPTION
content:
<code>dvc checkout</code> is a fundamental command in <I>Data Version Control</I> (<B>DVC</B>) used to restore data files and directories tracked by DVC to a specific state or version. It materializes the data from the DVC cache into your workspace. <br><br>Similar to how <B>Git</B> restores source code files, <code>dvc checkout</code> ensures data reproducibility by linking or copying the correct data versions identified by corresponding <B>.dvc</B> files. When executed without arguments, it checks out all DVC-tracked files and directories in the current repository. If paths are specified, it operates only on those targets. <br><br>This command is crucial for switching between different data versions, reverting unwanted changes, or setting up a clean working environment based on a specific Git commit that includes DVC-tracked data. It interacts with the DVC cache, which stores immutable versions of your data. If the required data is not in the local cache, you might need to use <B>dvc pull</B> to retrieve it from a remote storage.


title: CAVEATS
content:
<B>Data Availability:</B> <code>dvc checkout</code> retrieves data from the local DVC cache. If the required data is not in the cache, you will need to run <B>dvc pull</B> first to download it from a configured remote storage.<br><B>Overwriting Changes:</B> Be cautious when running <code>dvc checkout</code> as it can overwrite existing files in your workspace that are tracked by DVC. Ensure you have committed or stashed any unsaved changes if they are important.<br><B>Git Integration:</B> <code>dvc checkout</code> works best when your DVC repository is integrated with a Git repository. It often follows Git checkouts to align data versions with code versions.


title: HISTORY
content:
<B>DVC</B> (Data Version Control) was first open-sourced by <B>Iterative.ai</B> in <B>2017</B>. The <code>dvc checkout</code> command has been a core component of DVC since its early versions, designed to mirror the familiarity of <B>Git's</B> checkout mechanism but applied specifically to machine learning data and models. Its purpose is to facilitate the reproducibility and versioning of large datasets and model files, which Git is not designed to handle efficiently. The command's functionality has evolved to include options like <B>--jobs</B> for parallel processing and <B>--with-deps</B> for managing dependencies, improving performance and usability over time.


title: SEE ALSO
content:
<B>dvc add</B>(1) - Adds files and directories to DVC for version control., <B>dvc pull</B>(1) - Downloads data from DVC remote storage to the local cache and checks it out., <B>dvc push</B>(1) - Uploads data from the local DVC cache to a remote storage., <B>dvc status</B>(1) - Shows the status of DVC-tracked files and stages., <B>dvc repro</B>(1) - Reproduces a DVC pipeline by running stages., <B>git checkout</B>(1) - The analogous Git command for source code, often used in conjunction with <code>dvc checkout</code>.


title: PARAMETERS
content:
<b><I>paths</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional.</i> One or more paths to DVC-tracked files, directories, or <i>.dvc</i> files. If specified, only changes to these specific targets will be committed. If omitted, DVC commits changes for all modified tracked data within the project.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results in JSON format, which can be useful for scripting and programmatic integration.<br><br>


title: DESCRIPTION
content:
<b>dvc commit</b> is a core DVC (Data Version Control) command used to finalize changes made to DVC-tracked files or directories. When you modify data that DVC tracks, these changes are not automatically reflected in its metadata files (<i>.dvc</i> files). <br><br> The <b>dvc commit</b> command scans the specified <i>targets</i> (or all modified tracked data if no targets are given), calculates their hashes, copies or links the new data to DVC's local cache, and updates the corresponding <i>.dvc</i> file to point to this new cache entry. This makes the new state of the data versionable. <br><br> It's often used after modifying DVC-tracked data and before <b>git add</b> and <b>git commit</b> to version the <i>.dvc</i> files themselves. It ensures that the <i>.dvc</i> file accurately reflects the current state of the data it represents, allowing for proper data versioning and reproducibility.


title: CAVEATS
content:
<b>dvc commit</b> only stages changes to DVC's internal cache and updates <i>.dvc</i> files. You must follow up with <b>git add .dvc_file</b> and <b>git commit</b> to version these metadata changes in your Git repository.<br><br>Does not interact with Git's staging area for other files; it exclusively deals with DVC-tracked data.<br><br>For large datasets, the hashing and caching process can take a significant amount of time.<br><br>This command does not upload data to remote storage; <b>dvc push</b> is required for that.


title: WORKFLOW INTEGRATION
content:
Integrated into the Git workflow, <b>dvc commit</b> is typically followed by <b>git add .dvc_file</b> and <b>git commit</b> to version the metadata itself within your Git repository.


title: HASH-BASED VERSIONING
content:
DVC uses content-addressable storage. When <b>dvc commit</b> is run, it computes a hash (e.g., MD5) of the data's content, and this hash is used to name the data in the DVC cache. This hash, along with file size, is recorded in the <i>.dvc</i> file. This ensures data integrity, enables efficient deduplication, and allows DVC to track data changes precisely.


title: HISTORY
content:
DVC (Data Version Control) was created by Iterative.ai, with its first public release around 2017. <b>dvc commit</b> has been a fundamental command since its early versions, forming the core mechanism for versioning data similar to how <b>git commit</b> versions code. Its design philosophy aligns with Git's, making it familiar to developers for managing data alongside code efficiently.


title: SYNOPSIS
content:
<B>dvc config</B> [<I>options</I>] <I>&lt;param&gt;</I> [<I>&lt;value&gt;</I>]<br><B>dvc config</B> [<I>options</I>] <I>--list</I><br><B>dvc config</B> [<I>options</I>] <I>--unset</I> <I>&lt;param&gt;</I>


title: PARAMETERS
content:
<b><I>-h</I>, <I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message for the <I>dvc-config</I> command and exit.<br><br><b><I>-q</I>, <I>--quiet</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output from the command, useful for scripting.<br><br><b><I>-v</I>, <I>--verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be more verbose in output, displaying additional diagnostic information.<br><br><b><I>-g</I>, <I>--global</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the global DVC configuration file, typically located at <I>~/.dvc/config</I> on Linux. Settings here apply to all DVC projects for the current user.<br><br><b><I>-L</I>, <I>--local</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the local DVC configuration file, usually found at <I>.dvc/config.local</I> within a DVC repository. Settings here have the highest precedence and are typically not committed to Git.<br><br><b><I>--unset</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unset (remove) the specified configuration parameter. This option requires a <I>&lt;param&gt;</I> argument and cannot be used with a <I>&lt;value&gt;</I>.<br><br><b><I>--list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all effective configuration parameters known to DVC, including those inherited from global, repository, and local files. This option does not take <I>&lt;param&gt;</I> or <I>&lt;value&gt;</I>.<br><br><b><I>&lt;param&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific configuration parameter to set, query, or unset. Parameters are often structured hierarchically using dot notation, e.g., <I>core.cache_dir</I> or <I>remote.origin.url</I>.<br><br><b><I>&lt;value&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The value to assign to the specified <I>&lt;param&gt;</I> when setting a configuration. This argument is not used with <I>--unset</I> or <I>--list</I>.<br><br>


title: DESCRIPTION
content:
<I>dvc-config</I> is a fundamental subcommand of DVC (Data Version Control) designed to manage configuration parameters for DVC projects. It empowers users to set, unset, query, or list various DVC settings that dictate how DVC operates within a specific repository, or globally across all DVC projects for a user. <br><br>These configurations can include critical settings such as defining remote storage locations (e.g., S3, Google Cloud Storage, SSH), specifying cache directories, controlling data linking strategies (e.g., hardlinks, symlinks), and adjusting other core behaviors. The command functions much like <I>git config</I>, providing a structured and familiar interface for customizing DVC to suit different environments, team workflows, or specific project requirements. It's capable of modifying configuration files at the system-wide, global user, repository-specific, or local repository levels, adhering to a defined precedence for how these settings are applied and overridden.


title: CAVEATS
content:
1. <B>Configuration Precedence:</B> DVC applies configuration settings with a specific order of precedence: <I>.dvc/config.local</I> (highest) > <I>.dvc/config</I> > <I>~/.dvc/config</I> > system-wide config (lowest). Be aware of where you set parameters to ensure they take effect as intended.<br>2. <B>Impact of Changes:</B> Modifying critical parameters like <I>core.cache_dir</I> or <I>remote.default</I> can significantly alter how DVC handles data and models. For instance, changing the cache directory might require re-running <I>dvc add</I> or <I>dvc checkout</I> to update links or move cached files.<br>3. <B>Sensitive Information:</B> While <I>dvc-config</I> can store any string, it's generally recommended to avoid embedding sensitive credentials (e.g., cloud access keys) directly into plain-text configuration files. DVC provides alternative mechanisms like environment variables or external credential management for better security.


title: CONFIG FILE LOCATIONS AND HIERARCHY
content:
DVC reads configurations from several locations, applying them in a specific hierarchical order, where settings in higher-priority files override those in lower-priority ones: <br>1. <B>Local Repository Config</B>: <I>.dvc/config.local</I> (highest precedence). This file is intended for user-specific settings within a repository and is typically excluded from Git version control.<br>2. <B>Repository Config</B>: <I>.dvc/config</I>. This file contains project-wide settings that are usually committed to Git, ensuring consistency across collaborators.<br>3. <B>Global User Config</B>: <I>~/.dvc/config</I>. This file applies to all DVC projects for the current user.<br>4. <B>System-wide Config</B>: <I>/etc/dvc/config</I> (or similar, depending on OS). This is the lowest precedence and is less commonly used.<br>When setting a parameter without <I>--global</I> or <I>--local</I> flags, <I>dvc-config</I> defaults to writing to the <I>.dvc/config</I> file.


title: PARAMETER NAMING STRUCTURE
content:
Configuration parameters are typically organized hierarchically using dot notation, reflecting a <I>section.key</I> or <I>section.subsection.key</I> structure. Common top-level sections include: <br>• <I>core</I>: Controls general DVC behavior and settings (e.g., <I>core.cache_dir</I>, <I>core.no_scm</I>, <I>core.dvc_ignore</I>).<br>• <I>remote</I>: Defines and configures remote storage locations for data and models (e.g., <I>remote.origin.url</I>, <I>remote.my_s3.path</I>, <I>remote.my_gcs.credentialpath</I>).<br>• <I>cache</I>: Specifies settings related to the DVC cache (e.g., <I>cache.type</I> for hardlinks/symlinks, <I>cache.dir</I> to override core.cache_dir).<br>• <I>feature</I>: Used for enabling or disabling experimental DVC features.


title: HISTORY
content:
<I>dvc-config</I> has been an integral and fundamental component of DVC (Data Version Control) since its initial major release around 2017 by Iterative.ai. Its design and functionality closely mirror that of <I>git config</I>, reflecting DVC's core philosophy of bringing Git-like version control to data and machine learning models. This deliberate design choice aimed to provide a familiar and intuitive configuration experience for users already accustomed to Git, thereby facilitating easier adoption and seamless integration of DVC into existing data science and MLOps workflows.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the command's help message and exit.<br><br><b>-o OUT, --out OUT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file path to write the output graph instead of standard output.<br><br><b>--dot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the dependency graph in Graphviz DOT format. This format can be processed by external tools like Graphviz to render visual graphs (e.g., as SVG or PNG images).<br><br><b>--mermaid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the dependency graph in Mermaid JS diagram syntax. This format is suitable for embedding diagrams in Markdown files or web pages that support Mermaid rendering.<br><br><b>--targets [TARGETS ...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter the pipeline graph to only show stages that produce the specified target outputs. Multiple targets can be provided.<br><br><b>--full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all stages in the graph, including those that might not currently exist as DVC files but are defined as part of the pipeline structure.<br><br>


title: DESCRIPTION
content:
The <b>dvc-dag</b> command is a core utility within Data Version Control (DVC) designed to visualize the dependency graph of a DVC project. It allows users to understand the relationships between different data files, code scripts, and machine learning models defined as stages in <I>dvc.yaml</I> files. By printing the dependency graph, <b>dvc-dag</b> helps in debugging pipelines, optimizing workflows, and ensuring that changes in one part of the project correctly trigger updates in dependent components. It primarily outputs the graph structure to standard output, with options to format it for external visualization tools like Graphviz (DOT format) or directly for Mermaid diagrams, making it highly versatile for documentation and analysis.


title: CAVEATS
content:
To visually render the Graphviz DOT output (e.g., into an image), you typically need to install an external tool like <I>Graphviz</I> and use its <b>dot</b> command. For example: <br><b>dvc dag --dot | dot -Tsvg -o pipeline.svg</b>.<br>The displayed graph reflects the state defined in your <I>dvc.yaml</I> and <I>dvc.lock</I> files, not necessarily the current execution state of your data or code.


title: VISUALIZATION EXAMPLE WITH GRAPHVIZ
content:
After generating a DOT file using <b>dvc dag --dot</b>, you can render it into a visual image. For instance, to create an SVG image and open it:<br><b>dvc dag --dot > pipeline.dot</b><br><b>dot -Tsvg pipeline.dot -o pipeline.svg</b><br><b>xdg-open pipeline.svg</b> (on Linux)<br>Similarly, for Mermaid output, you can paste the generated text into a Mermaid-compatible viewer or Markdown file.


title: HISTORY
content:
DVC (Data Version Control) was open-sourced in 2017 by Iterative.ai, aiming to bring Git-like versioning capabilities to machine learning projects and large datasets. The <b>dvc-dag</b> command, or its equivalent functionality, has been a fundamental part of DVC's toolkit from its early stages. It's crucial for understanding the data and model pipelines that DVC manages, evolving with DVC's core capabilities to support various output formats and filtering options, making pipeline visualization more accessible and powerful.


title: PARAMETERS
content:
<b>path ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> Specifies one or more DVC-tracked files or directories to destroy. If no paths are provided, <i>dvc destroy</i> operates on all DVC-tracked files within the current directory.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> Skips confirmation prompts, allowing for non-interactive execution. Use with caution as it can lead to irreversible data loss, especially when combined with <i>--cache</i>.<br><br><b>-c, --cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> In addition to removing the data from the working tree, this flag also removes the corresponding data from the DVC cache. This action is irreversible and permanently deletes the data from the cache, freeing up storage space.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional)</i> Displays a help message for the command and exits.<br><br>


title: DESCRIPTION
content:
<i>dvc destroy</i> is a command in Data Version Control (DVC) used to remove DVC-tracked files and directories from the working tree. It provides a way to "untrack" or clean up data that was previously managed by DVC. When executed without specific paths, it removes all DVC-tracked files within the current directory. Optionally, with the <i>--cache</i> flag, it can also delete the corresponding data from the DVC cache, freeing up storage space. This command is particularly useful for cleaning up a workspace, removing outdated data, or starting fresh with specific files without having to manually delete and then clean the DVC cache. It's important to note that <i>dvc destroy</i> primarily affects the working tree and the DVC cache; it does <b>not</b> automatically modify or remove the <i>.dvc</i> files themselves, nor does it interact with Git to remove these <i>.dvc</i> files from version control.


title: CAVEATS
content:
<ul><li><b>Irreversibility:</b> Using the <i>--cache</i> flag permanently deletes data from the DVC cache, which cannot be easily recovered without re-adding the original data source.</li><li><b>Working Tree vs. Cache:</b> By default, <i>dvc destroy</i> only removes data from the working tree. To also remove it from the DVC cache, the <i>--cache</i> flag must be explicitly used.</li><li><b>Git Integration:</b> This command does <b>not</b> automatically remove the <i>.dvc</i> files (the small metadata files that track the data) from Git. After running <i>dvc destroy</i>, you typically need to manually run <i>git rm &lt;file.dvc&gt;</i> and commit the changes to fully "untrack" the data from your repository's version control.</li><li><b>Scope:</b> It only operates on paths currently tracked by DVC.</li></ul>


title: DIFFERENCE FROM <I>DVC REMOVE</I>
content:
While both commands relate to removing DVC-tracked items, their purposes differ significantly. <i>dvc remove</i> is used to <i>untrack</i> data from DVC by deleting the corresponding <i>.dvc</i> file and updating the <i>.gitignore</i>. It's designed to remove data from DVC's tracking system entirely, akin to a permanent untracking. In contrast, <i>dvc destroy</i> primarily removes the actual data from the working tree and optionally from the DVC cache, without touching the <i>.dvc</i> metadata file. It's more about cleaning up the local workspace and cache while preserving the tracking information in the <i>.dvc</i> file for potential future <i>dvc pull</i> operations.


title: TWO-STEP UNTRACKING PROCESS
content:
To completely remove a DVC-tracked file from your working tree, DVC cache, and Git history, a common workflow involves two steps: first, use <i>dvc destroy --cache [path]</i> to remove the data from your workspace and cache; then, use <i>git rm [path].dvc</i> to remove the DVC metadata file from Git's tracking, followed by a <i>git commit</i>. This ensures that the data is no longer present locally or in the DVC cache, and the reference to it is removed from your Git repository.


title: HISTORY
content:
The <i>dvc destroy</i> command was introduced as part of the DVC (Data Version Control) ecosystem, which began its development around 2017. DVC aims to bring Git-like version control to data and models, addressing the challenges of managing large datasets in machine learning and data science projects. <i>dvc destroy</i> provides a necessary utility for cleaning up or resetting the state of DVC-tracked data in a workspace without affecting the DVC metadata files (<i>.dvc</i> files) or Git repository. Its evolution reflects the need for granular control over DVC-managed data, allowing users to remove data from their local working copy and optionally from the shared DVC cache, independent of their Git history.


title: SYNOPSIS
content:
<b>dvc diff</b> [<i>old_revision</i>] [<i>new_revision</i>] [<i>options</i>]<br><b>dvc diff</b> [<i>--old old_revision</i>] [<i>--new new_revision</i>] [<i>options</i>] [<i>paths...</i>]


title: PARAMETERS
content:
<b>old_revision</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The old revision (Git commit, branch, or tag) to compare from. Defaults to the HEAD commit.<br><br><b>new_revision</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The new revision (Git commit, branch, or tag) to compare to. Defaults to the current workspace.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print anything to standard output. Useful for scripting.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print detailed information for debugging.<br><br><b>--data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show changes in DVC-tracked data and directories. This is the default behavior.<br><br><b>--metrics</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show changes in DVC-tracked metrics files.<br><br><b>--plots</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show changes in DVC-tracked plot files.<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the differences in JSON format. Applicable for metrics and plots.<br><br><b>--tsv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output metrics/plots differences in TSV format.<br><br><b>--md</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output metrics/plots differences in Markdown table format.<br><br><b>paths...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more specific DVC-tracked paths to diff. If not provided, all tracked items are diffed.<br><br>


title: DESCRIPTION
content:
<i>dvc-diff</i> is a powerful command within the Data Version Control (DVC) framework, designed to reveal differences in DVC-tracked files, directories, metrics, and plots between various states of your repository. Similar to how <i>git diff</i> compares source code, <i>dvc diff</i> specializes in comparing data artifacts and the results of machine learning experiments.<br><br>It can compare two arbitrary revisions (commits, branches, or tags) or compare a revision with the current workspace. By default, it shows changes in DVC-tracked data files and directories, indicating whether they are added, deleted, or modified (based on DVC's content-addressing).<br><br>Beyond just data, <i>dvc-diff</i> can also highlight differences in metrics files (e.g., accuracy, loss values) and plot data, making it an invaluable tool for tracking experiment progress and understanding the impact of changes in data or code on model performance.<br><br>The command leverages Git for revision management, allowing users to easily compare different versions of their data science projects.


title: CAVEATS
content:
<i>dvc-diff</i> relies on DVC's metadata (<i>.dvc</i> files) and Git's revision history. If <i>.dvc</i> files are not committed or if the repository is not a Git repository, the command may not function as expected.<br><br>For very large datasets, calculating and displaying differences can be time-consuming, as DVC may need to compare hashes or even access remote storage.<br><br>The command primarily shows differences in content hashes (for data) or values (for metrics/plots) rather than line-by-line file differences within large data files themselves. For detailed content diffs of text files, traditional <i>git diff</i> or specialized tools are often needed.


title: INTEGRATION WITH GIT
content:
<i>dvc-diff</i> is deeply integrated with Git. When you run <i>dvc diff</i> without specifying revisions, it compares the current workspace with the last committed state. When revisions are provided, it uses Git's underlying revision graph to identify the corresponding DVC-tracked files and compare their content hashes, metrics, or plot definitions.


title: USE CASES
content:
Typical use cases for <i>dvc-diff</i> include comparing the performance of two different model training runs, analyzing how changes in data preprocessing affect downstream metrics, or simply understanding what data artifacts have changed between two branches of a project. It's essential for reproducible machine learning and collaborative data science.


title: HISTORY
content:
The <i>dvc-diff</i> command has been a core component of DVC since its early development. DVC was first released in 2017, and the ability to compare versions of data and models was fundamental to its mission of providing Git-like version control for machine learning projects. Initially, it focused primarily on data content diffs. Over time, as DVC evolved to include features like metrics and plot tracking, <i>dvc-diff</i> was extended to support these new data types, providing a comprehensive view of experiment changes.


title: PARAMETERS
content:
<b>--remote <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the DVC remote (e.g., S3, GCS, local path) to fetch data from. If omitted, the default remote is used.<br><br><b>--jobs <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of parallel downloads to run simultaneously. Defaults to 1.<br><br><b>--all-branches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches data referenced across all Git branches in the repository.<br><br><b>--all-tags</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches data referenced by all Git tags in the repository.<br><br><b>--all-experiments</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches data associated with all DVC experiments, including queued and finished ones.<br><br><b>--recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively fetches DVC-tracked data from subdirectories within the current repository.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces fetching, even if the data already exists in the cache, potentially overwriting corrupted entries.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run with no changes made, showing which data would be fetched.<br><br><b>--show-url</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the URL of the data being fetched from the remote storage.<br><br><b>--no-run-cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents fetching of run cache data from <i>dvc.yaml</i> files, only fetching outputs.<br><br><b>[targets...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies particular DVC-tracked files or directories to fetch. If omitted, all DVC-tracked data in the current repository (as defined in <i>.dvc</i> files and <i>dvc.yaml</i>) is fetched.<br><br>


title: DESCRIPTION
content:
<i>dvc-fetch</i> is a core command in the Data Version Control (DVC) system, primarily used to download data and models from a configured remote storage location into the local DVC cache. Unlike <i>dvc pull</i>, which both fetches data and checks it out to the workspace, <i>dvc-fetch</i><br> only populates the local DVC cache with the data referenced in <i>.dvc</i> files or <i>dvc.yaml</i> files. This means it retrieves the data content but does not modify the user's working directory.<br><br>This separation is beneficial for scenarios where users need to pre-populate their cache without altering the current state of their working directory, such as in CI/CD pipelines, preparing data for offline use, or debugging.<br><br>When <i>dvc-fetch</i> runs, it uses the metadata (hashes, paths) stored in <i>.dvc</i> files to identify the required data artifacts. It then efficiently downloads only the missing or outdated parts from the remote, ensuring data integrity through hash verification and optimizing network bandwidth usage.


title: CAVEATS
content:
<ul><li><b>DVC Repository Required:</b> <i>dvc-fetch</i> must be executed within an initialized DVC repository (after running <i>dvc init</i>).<br></li><li><b>Remote Configuration:</b> A DVC remote storage must be properly configured (e.g., via <i>dvc remote add</i>) and accessible.<br></li><li><b>Disk Space:</b> Sufficient local disk space is required to store the fetched data in the DVC cache.<br></li><li><b>No Workspace Modification:</b> Remember that <i>dvc-fetch</i> only populates the cache; you'll need <i>dvc checkout</i> or <i>dvc pull</i> to link the data into your workspace.<br></li><li><b>Permissions:</b> Appropriate network and access permissions are essential for connecting to and downloading from the remote storage.</li></ul>


title: DVC CACHE
content:
<i>dvc-fetch</i> downloads data into the DVC cache, which is a content-addressable storage area. Data is stored by its hash, enabling efficient deduplication across different versions of a dataset or even across multiple DVC projects. This cache is typically located outside the Git repository (e.g., in <i>.dvc/cache</i> or a user-defined location) to prevent bloating the Git history.


title: DATA INTEGRITY
content:
A key feature of DVC is its focus on data integrity. During <i>dvc-fetch</i>, DVC verifies the integrity of the downloaded data by comparing its MD5 (or other specified hash) with the hash recorded in the corresponding <i>.dvc</i> metadata file. This ensures that the data fetched is precisely what was intended and prevents corruption during transfer.


title: HISTORY
content:
DVC (Data Version Control) was open-sourced by Iterative.ai in 2017 with the ambitious goal of bringing Git-like version control capabilities to large datasets and machine learning models. <i>dvc-fetch</i> has been a fundamental command since DVC's early versions, providing the core functionality for retrieving data artifacts efficiently.<br><br>Its design reflects the need for robust data management in MLOps, allowing users to pre-download data for reproducibility, CI/CD pipelines, and collaborative machine learning projects without directly altering the working directory's state. The command has evolved with DVC's features, incorporating support for advanced concepts like experiments, branches, and tags.


title: PARAMETERS
content:
<b><I>path_or_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the <i>.dvc</i> file representing the stage, or the name of the stage defined in the <i>dvc.yaml</i> file.<br><br>


title: DESCRIPTION
content:
The <b>dvc freeze</b> command is part of Data Version Control (DVC), a tool for versioning machine learning models and data. It allows users to mark a specific DVC stage as "frozen" within the <i>dvc.yaml</i> file. When a stage is frozen, DVC will no longer attempt to resolve or update its dependencies (specified in the <i>deps</i> field of the stage definition) when the <b>dvc update</b> command is executed. This means that even if a dependency (like a data file or a script) changes externally, DVC will ignore those changes for the frozen stage, ensuring that subsequent reproductions of that stage use the exact versions of dependencies that were present when it was frozen. This is crucial for maintaining reproducibility, fixing pipeline behavior, and ensuring consistent results across different environments or experiments by preventing unintended updates to input data or code.


title: CAVEATS
content:
Freezing a stage prevents <b>dvc update</b> from automatically fetching newer versions of its dependencies. To incorporate new dependency versions, you must first unfreeze the stage using <b>dvc unfreeze</b>, then run <b>dvc update</b>, and potentially re-freeze it. The change made to <i>dvc.yaml</i> by <b>dvc freeze</b> must be committed to Git to persist the frozen state within your repository's version control.


title: IMPACT ON <I>DVC.YAML</I> AND <I>DVC.LOCK</I>
content:
When you run <b>dvc freeze</b>, it adds or modifies the <i>frozen: true</i> property for the specified stage within your <i>dvc.yaml</i> file. This flag is an instruction to DVC itself. It tells DVC to skip checking for updates for that stage's dependencies when <b>dvc update</b> is invoked. It's important to distinguish this from the <i>dvc.lock</i> file: <i>dvc.lock</i> stores the precise checksums of dependencies and outputs for each stage. <b>dvc freeze</b> itself does not directly modify <i>dvc.lock</i>; rather, it changes DVC's behavior towards how it processes that stage's entry in <i>dvc.lock</i> during dependency resolution. When <b>dvc repro</b> is run on a frozen stage, it will still use the checksums recorded in <i>dvc.lock</i> to ensure that the stage is reproduced with the exact versions of its inputs, regardless of external changes.


title: HISTORY
content:
DVC was created in 2017 to bring Git-like version control to data and machine learning pipelines. The concept of stages and managing their dependencies has always been core to DVC. The <b>dvc freeze</b> command was introduced as a fundamental mechanism to provide fine-grained control over the reproducibility flow, allowing users to stabilize specific parts of their pipelines. Its functionality has evolved alongside DVC's file formats, adapting from individual <i>.dvc</i> files to the modern centralized <i>dvc.yaml</i> for stage definitions, reinforcing its role in building robust and stable data science projects.


title: SYNOPSIS
content:
<b>dvc gc</b> [<i>&lt;path&gt;</i>] [<i>&lt;options&gt;</i>]<br><br><i>Common usage:</i><br><b>dvc gc</b> [--workspace | --all-branches | --all-tags | --all-commits] [--dry-run] [--cloud] [-r <i>&lt;remote&gt;</i>] [--force]


title: PARAMETERS
content:
<b><b>--workspace</b>, <b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collect garbage from data referenced by the current workspace. This is the default scope if no other scope option is provided.<br><br><b><b>--all-branches</b>, <b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collect garbage from data referenced by all branches in the repository.<br><br><b><b>--all-tags</b>, <b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collect garbage from data referenced by all tags in the repository.<br><br><b><b>--all-commits</b>, <b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collect garbage from data referenced by all commits in the repository. This is the most comprehensive option and implicitly includes all branches and tags.<br><br><b><b>--dry-run</b>, <b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show what data would be removed without actually deleting anything. Highly recommended before running <b>dvc gc</b> without <b>--dry-run</b>.<br><br><b><b>--force</b>, <b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force deletion of data without interactive confirmation. Use with caution, especially with <b>--cloud</b>.<br><br><b><b>--cloud</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Collect garbage from the DVC remote storage instead of the local cache. Requires the <b>--remote</b> option.<br><br><b><b>--remote &lt;name&gt;</b>, <b>-r &lt;name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the DVC remote to clean up when using the <b>--cloud</b> option.<br><br><b><b>--jobs &lt;jobs&gt;</b>, <b>-j &lt;jobs&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of jobs to run simultaneously for parallel processing, useful for large datasets.<br><br><b><b>--unsaved-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes only data that is <I>not</I> saved in the current workspace. This helps clean up stale cache entries without affecting current working data.<br><br><b><b>&lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional: Path to a specific DVC-tracked file or directory to clean up. If omitted, the entire project's cache is considered.<br><br>


title: DESCRIPTION
content:
<b>dvc gc</b> is a <I>Data Version Control</I> (DVC) command that performs garbage collection on the DVC cache. Its primary purpose is to remove data files and directories from the cache that are no longer referenced by any DVC-tracked <code>.dvc</code> files or Git commits within the current repository or specified remote. This helps in reclaiming disk space occupied by old, unused, or deleted data versions.<br><br>It can operate on the local cache, or on cloud remotes. The command offers various options to specify which references to consider (e.g., current workspace, all branches, all tags, all commits) and whether to perform a <I>dry run</I> before actual deletion. It's an essential maintenance tool for DVC repositories to manage storage efficiently.


title: CAVEATS
content:
<b>dvc gc</b> is a <I>destructive operation</I>. Once data is removed from the cache or remote, it is generally <I>not recoverable</I> without external backups.<br><br>Always use <b>--dry-run</b> first to preview what will be deleted.<br>Carefully consider the scope of cleaning (e.g., <b>--workspace</b>, <b>--all-branches</b>, <b>--all-commits</b>) to avoid accidentally deleting data referenced by other branches or tags. <b>--all-commits</b> is often the safest for local cache.<br>When cleaning cloud remotes (with <b>--cloud</b>), ensure you have appropriate permissions and understand the impact on shared storage.


title: HOW IT WORKS
content:
<b>dvc gc</b> identifies data objects in the DVC cache (which are typically symlinks or hardlinks to actual files) that are no longer referenced by any <code>.dvc</code> file or Git commit within the specified scope (e.g., current workspace, all branches). It then removes these unreferenced objects, freeing up disk space. For cloud remotes, it identifies and removes unreferenced objects directly from the remote storage.


title: SCOPE OF CLEANING
content:
The default behavior cleans the local cache based on the current workspace. To ensure no important data is accidentally deleted, it's often recommended to use options like <b>--all-branches</b>, <b>--all-tags</b>, or <b>--all-commits</b> to consider all potential references across your repository's history.


title: HISTORY
content:
DVC (Data Version Control) was created by Iterative.ai, with its initial public release in 2017. The <b>dvc gc</b> command was introduced as a core utility for managing disk space by cleaning the DVC cache, a fundamental aspect of DVC's design to separate data storage from Git. Its functionality has evolved to include cleaning cloud remotes, reflecting DVC's expanded capabilities for distributed data management and collaboration.


title: SYNOPSIS
content:
<b>dvc init</b> [<i>&lt;path&gt;</i>] [<i>--no-scm</i>] [<i>--subdir</i>] [<i>--quiet</i>] [<i>--help</i>]


title: PARAMETERS
content:
<b><i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional path where the DVC repository should be initialized. If not provided, it initializes in the current working directory.<br><br><b><i>--no-scm</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not initialize a Git repository or integrate with an existing one. This means DVC will not modify <B>.gitignore</B> or install Git hooks.<br><br><b><i>--subdir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initialize DVC in a subdirectory that is already part of a parent Git repository. This allows creating a DVC repo nested within a larger Git project without creating a new Git repo in the subdirectory.<br><br><b><i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output from the command.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br>


title: DESCRIPTION
content:
The <b>dvc init</b> command is the essential first step to start versioning your data, models, and machine learning pipelines with DVC (Data Version Control). It sets up a new DVC repository in the current directory or a specified path. <br><br>When executed, <b>dvc init</b> performs several key actions: <br><i>1. Creates the <B>.dvc/</B> directory:</i> This hidden directory stores DVC's internal files, including configuration (<B>.dvc/config</B>), cache information, and DVC's dependency graph. <br><i>2. Initializes configuration:</i> It sets up the basic DVC configuration, which can later be extended to include remote storage settings. <br><i>3. Integrates with Git (by default):</i> If a Git repository exists or is initialized, <b>dvc init</b> automatically modifies the <B>.gitignore</B> file to ignore DVC's cache directory (usually <B>.dvc/cache</B>) and adds DVC-related Git hooks (e.g., <B>pre-commit</B>) to ensure DVC files are committed correctly. This deep integration allows DVC to leverage Git for versioning metadata while handling large data files separately. <br><br>It's typically run at the root of a Git repository to ensure seamless version control of both code and data.


title: CAVEATS
content:
<i>1. Existing Repository:</i> If a <B>.dvc</B> directory already exists in the target path, <b>dvc init</b> will exit with an error, preventing accidental re-initialization. <br><i>2. Git Integration:</i> While DVC can work independently, its full power comes from integration with Git. Using <B>--no-scm</B> will prevent automatic <B>.gitignore</B> modifications and Git hook installations, requiring manual setup if Git is later introduced. <br><i>3. Repository Root:</i> For optimal functionality, it's recommended to run <b>dvc init</b> at the root of your project's Git repository. Initializing DVC in a subdirectory without <B>--subdir</B> can lead to unexpected behavior regarding Git integration and cache management.


title: DEFAULT GIT INTEGRATION
content:
By default, <b>dvc init</b> attempts to integrate with Git. It modifies the project's <B>.gitignore</B> file to include DVC's cache directory (usually <B>.dvc/cache</B>), ensuring large data files tracked by DVC are not committed directly to Git. It also installs Git hooks (e.g., <B>pre-commit</B>) which help DVC manage its internal files, like <B>.dvc</B> files, alongside your code. This seamless integration is a core strength of DVC, allowing users to leverage familiar Git workflows for both code and data.


title: CORE FILES CREATED
content:
Upon successful initialization, <b>dvc init</b> creates the following key components:<br><i>1. <B>.dvc/</B> directory:</i> The central hub for DVC's operations, containing configuration, cache link management, and other internal files.<br><i>2. <B>.dvc/.gitignore</B> file:</i> Often created inside the <B>.dvc/</B> directory to ignore internal DVC files from being tracked by Git. If no parent <B>.gitignore</B> exists, it might create one at the project root.<br><i>3. <B>.dvc/config</B> file:</i> The primary configuration file for the DVC repository, where you can define remote storage, cache settings, and other project-specific options.


title: HISTORY
content:
DVC (Data Version Control) was created by Iterative.ai, with its initial release in 2017. It was designed to address the challenges of versioning large datasets and machine learning models, which traditional source control systems like Git struggle with due to their size. <b>dvc init</b> has been a foundational command since DVC's inception, serving as the gateway to establishing a DVC-managed project. Its development has mirrored DVC's evolution, becoming more robust in its Git integration and handling of diverse project structures.


title: PARAMETERS
content:
<b><I>stage_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name(s) of the DVC stage(s) to unfreeze. Multiple stage names can be provided, separated by spaces.<br><br><b><b>-f</b>, <b>--file</b> <I>DVC_YAML_FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>dvc.yaml</i> file where the stage definitions are located. If omitted, DVC searches for <i>dvc.yaml</i> in the current directory and its parent directories.<br><br>


title: DESCRIPTION
content:
<b>dvc unfreeze</b> is a core command in Data Version Control (DVC) used to reverse the effects of <b>dvc freeze</b>. When a DVC pipeline stage is frozen, DVC bypasses its execution during subsequent <b>dvc repro</b> calls, regardless of changes to its dependencies. This feature is invaluable for debugging, isolating pipeline segments, or avoiding redundant computations of stable stages. <br><br>The <b>dvc unfreeze</b> command removes the <i>frozen: true</i> flag from the specified stage(s) within the <i>dvc.yaml</i> pipeline definition file. Once a stage is unfrozen, <b>dvc repro</b> will once again actively monitor its dependencies and re-execute the stage if any input data, code, or parameters have changed. This restoration of a stage's active status is crucial for maintaining an up-to-date and fully functional DVC pipeline, ensuring that all components are correctly recomputed as needed. It effectively brings a temporarily suspended stage back into the active pipeline execution flow.


title: CAVEATS
content:
The command exclusively modifies the <i>dvc.yaml</i> file; it does not trigger immediate re-execution of the stage. To run the unfrozen stage, a subsequent <b>dvc repro</b> command is necessary if its dependencies have changed.<br>This command operates solely on stages defined within <i>dvc.yaml</i>; an error will occur if a specified stage name does not exist.<br>For <b>dvc unfreeze</b> to function properly, DVC must be initialized in the project directory using <b>dvc init</b>.


title: <B>IDEMPOTENCY</B>
content:
Running <b>dvc unfreeze</b> on a stage that is already unfrozen has no adverse effect and does not produce an error, making the command idempotent.


title: <B>VERSION CONTROL INTEGRATION</B>
content:
Changes made to the <i>dvc.yaml</i> file by <b>dvc unfreeze</b> should typically be committed to your chosen Source Code Management (SCM) system, such as Git. This ensures that the pipeline's execution behavior is consistent across different environments and collaborators, maintaining pipeline reproducibility.


title: HISTORY
content:
DVC (Data Version Control) was initially released in 2017. The functionality for controlling pipeline execution, including the ability to freeze and unfreeze stages, has been an integral part of DVC since its early development. This feature matured alongside the evolution of the <i>dvc.yaml</i> pipeline definition file, becoming a fundamental component as DVC gained prominence in MLOps and data versioning workflows.


title: SYNOPSIS
content:
<b>dvd+rw-booktype</b> <i>device</i> [ <i>booktype</i> ]<br><br>The <i>device</i> argument specifies the path to the optical drive (e.g., <code>/dev/sr0</code>). The optional <i>booktype</i> argument can be one of <i>DVD-ROM</i>, <i>DVD+R</i>, or <i>DVD+RW</i>. If <i>booktype</i> is omitted, the current booktype of the media is displayed.


title: PARAMETERS
content:
<b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the optical drive containing the DVD+R or DVD+RW media (e.g., <code>/dev/sr0</code>, <code>/dev/dvd</code>). This is a mandatory positional argument.<br><br><b><i>booktype</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired booktype to set for the media. Valid values are <i>DVD-ROM</i>, <i>DVD+R</i>, or <i>DVD+RW</i>. This is an optional positional argument. If omitted, the command will display the current booktype of the media.<br><br>


title: DESCRIPTION
content:
The <b>dvd+rw-booktype</b> command is a utility from the <i>dvd+rw-tools</i> package designed to manipulate the booktype field on DVD+R and DVD+RW optical media. The booktype is a piece of information embedded in the disc that identifies its format. Its primary purpose is to enhance compatibility with older DVD players and ROM drives that may only recognize discs identified as DVD-ROM.<br><br>By changing the booktype of a DVD+R or DVD+RW disc to DVD-ROM, users can often ensure these discs are readable on a wider range of hardware. It's important to note that for DVD+R media, booktype changes are permanent, meaning once set, the disc will retain that booktype indefinitely. However, for DVD+RW media, the changes are only temporary and will revert to the original DVD+RW booktype after the disc is erased or formatted. The command allows setting the booktype to <i>DVD-ROM</i>, <i>DVD+R</i>, or <i>DVD+RW</i>. If no <i>booktype</i> is specified, the command will display the current booktype of the media in the specified drive.


title: CAVEATS
content:
<b>Limitations and Considerations:</b><br><i>Device and Media Compatibility:</i> This command strictly works with DVD+R and DVD+RW media and requires an optical drive that supports booktype modification. It does not apply to DVD-R, DVD-RW, or other disc formats, and not all drives have this specific capability.<br><i>Booktype Permanence:</i> For DVD+R media, booktype changes are permanent and cannot be reverted once set. For DVD+RW media, changes are temporary and will revert to the original DVD+RW booktype after any erase or format operation.<br><i>Guaranteed Compatibility:</i> While setting the booktype to DVD-ROM is intended to improve compatibility, it does not guarantee readability on all older players or ROM drives.


title: BOOKTYPE PERMANENCE
content:
For DVD+R media, setting the booktype is a permanent modification to the disc's metadata, which cannot be undone or re-changed on the same disc. For DVD+RW media, however, the booktype will automatically revert to <i>DVD+RW</i> after any erase or full format operation on the disc.


title: FUNCTIONALITY SCOPE
content:
This command is exclusively for modifying the booktype field. It does not provide any disc burning, erasing, or formatting capabilities. It can be used on both blank and already written DVD+R/RW media.


title: SUPPORTED MEDIA TYPES
content:
The <b>dvd+rw-booktype</b> command is strictly limited to DVD+R and DVD+RW optical media. It will not function with DVD-R, DVD-RW, CD-R, CD-RW, or any Blu-ray disc formats.


title: HISTORY
content:
The <b>dvd+rw-booktype</b> command is an integral part of the <i>dvd+rw-tools</i> project, primarily developed by Andy Polyakov. This suite of utilities emerged in the early 2000s, a period when DVD+R/RW technology was gaining traction as a writable DVD format, alongside the competing DVD-R/RW standard. A significant challenge for early adopters of DVD+R/RW was ensuring playback compatibility with the installed base of older DVD players and ROM drives, which were predominantly designed for factory-pressed DVD-ROM discs. The <b>dvd+rw-booktype</b> utility was specifically engineered to overcome this hurdle by allowing users to modify the disc's internal identification to mimic a DVD-ROM disc. Its inclusion and widespread use, often invoked implicitly by burning front-ends like <i>growisofs</i>, solidified its role in maximizing the reach and usability of DVD+R/RW media.


title: PARAMETERS
content:
<b>-full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a full format operation, writing to every sector on the disc. This ensures disc integrity but is significantly slower than quick initialization.<br><br><b>-lead-out</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the lead-out area to the disc, finalizing the session. This is typically used with sequential formats.<br><br><b>-force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the formatting process even if the disc appears to be non-empty or has existing data. Use with caution as this will destroy all data.<br><br><b>-format=sequential</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format the disc for traditional sequential recording. This is often the default behavior if no format type is specified.<br><br><b>-format=mrw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format the disc using the Mount Rainier (MRW) specification for random access. This enables features like background formatting and defect management. This usually performs a full MRW format.<br><br><b>-format=mrw-init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a quick initialization for Mount Rainier (MRW) random access. This is faster than <i>-format=mrw</i> but does not perform a full sector integrity check.<br><br><b>-format=mrw-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-initialize an already MRW-formatted disc for random access. Similar to <i>mrw-init</i>.<br><br><b>-a, --address-skip</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip address verification during the formatting process. This can speed up formatting but is generally not recommended due to potential data integrity issues.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of the <i>dvd+rw-format</i> utility and exit.<br><br><b><i>&lt;device&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the DVD+RW optical drive device, e.g., <i>/dev/sr0</i> or <i>/dev/cdrom</i>.<br><br>


title: DESCRIPTION
content:
<i>dvd+rw-format</i> is a specialized Linux command-line utility used to format DVD+RW optical discs. Unlike general filesystem creation tools like <i>mkfs</i>, this command performs low-level formatting tailored specifically for DVD+RW media. Its primary purpose is to prepare a blank or previously used DVD+RW disc for data writing, enabling either traditional sequential recording or advanced random access capabilities.<br><br>The tool is part of the <i>dvd+rw-tools</i> suite and is particularly notable for its support of the Mount Rainier (MRW) format. MRW allows DVD+RW discs to behave more like a removable hard drive or floppy disk, providing features such as background formatting, defect management, and the ability to write to arbitrary locations on the disc without the need to manage sessions or burn a full disc at once. When formatted with MRW, the disc is typically used with the UDF filesystem. For simple, session-based writing, it can also format discs for sequential access.


title: CAVEATS
content:
This command is specifically designed for <b>DVD+RW</b> discs. It will not work correctly or may damage other types of optical media (e.g., DVD-RW, DVD-R, CD-R).<br><br>Formatting a disc with <i>dvd+rw-format</i> is a <b>destructive operation</b>. All existing data on the disc will be permanently erased.<br><br>Ensure the target device is <b>not mounted</b> before attempting to format it to prevent data corruption or errors.<br><br>Full formatting operations (e.g., with <i>-full</i> or <i>-format=mrw</i>) can take a considerable amount of time, often 10-15 minutes or more depending on the drive and disc speed.<br><br>Using Mount Rainier (MRW) formatted discs typically requires <b>kernel support for UDF</b> (Universal Disk Format) to be properly recognized and used as a random-access device.


title: MOUNT RAINIER (MRW) FORMAT
content:
Mount Rainier is an industry initiative that standardizes defect management and background formatting for DVD+RW media. When a DVD+RW disc is formatted with MRW using <i>dvd+rw-format</i>, it gains several advantages:<br><b>Random Access:</b> Allows writing to any block on the disc, similar to a hard drive, without needing to finalize sessions.<br><b>Background Formatting:</b> The disc can be formatted in the background, making it immediately usable after a quick initialization, with the full formatting process completing transparently.<br><b>Defect Management:</b> The drive can remap bad sectors, improving reliability.<br><br>MRW formatted discs are typically accessed in Linux using the <b>UDF (Universal Disk Format)</b> filesystem, which is designed for optical media and supports random access.


title: SEQUENTIAL FORMAT
content:
The sequential format is the traditional method for writing to DVD+RW discs. In this mode, data is written in a continuous stream, and the disc must often be "finalized" or have a lead-out written after all data is recorded in a session. While simpler, it lacks the random-access and background formatting features of the Mount Rainier format.


title: HISTORY
content:
The <i>dvd+rw-format</i> command is a key component of the <b>dvd+rw-tools</b> project, primarily developed by Andy Polyakov. This suite of tools emerged in the early 2000s to provide robust Linux support for DVD+RW media, especially addressing advanced features like the Mount Rainier (MRW) format. Prior to these tools, support for DVD+RW's re-writable and random-access capabilities was often limited or non-existent in common Linux burning software. The development aimed to enable DVD+RW discs to be used more like traditional magnetic storage devices, allowing direct file manipulation and background formatting, significantly enhancing their utility in a Unix-like environment.


title: PARAMETERS
content:
<b><b>--set-speed</b> <i>&lt;speed&gt;</i> | <b>-s</b> <i>&lt;speed&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the DVD-RAM read/write speed. <i>&lt;speed&gt;</i> can be a numeric value (e.g., 2, 4, 6), or the keywords 'max' or 'min'.<br><br><b><b>--get-speed</b> | <b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries and displays the current DVD-RAM read/write speed.<br><br><b><b>--force</b> | <b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation, ignoring minor errors or warnings.<br><br><b><b>--verbose</b> | <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of output, providing more detailed information about the operation.<br><br><b><b>--help</b> | <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b> | <b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for the command and exits.<br><br><b><i>DEVICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the DVD-RAM device, typically a SCSI generic device like <i>/dev/sr0</i>, <i>/dev/cdrom</i>, or <i>/dev/sg1</i>.<br><br>


title: DESCRIPTION
content:
<b>dvd-ram-control</b> is a specialized Linux command-line utility designed for low-level interaction with DVD-RAM drives. Its core functionality revolves around managing the read and write speed of DVD-RAM media. Users can either query the drive's current speed setting using the <b>--get-speed</b> option or explicitly set a desired speed (e.g., 2x, 4x, or <i>max</i>) with the <b>--set-speed</b> option. This control is crucial for various scenarios, such as optimizing data transfer performance, reducing noise during quiet operation, or troubleshooting compatibility issues with specific media or drives.<br><br>The command operates by sending direct SCSI commands to the optical drive, necessitating appropriate system permissions, typically root access, and a properly configured kernel with support for SCSI generic devices (like <i>/dev/sg*</i> or <i>/dev/sr*</i>). It's an integral part of the <i>dvd+rw-tools</i> suite, providing fine-grained control over DVD-RAM hardware beyond what standard file system operations offer.


title: CAVEATS
content:
<ul><li>Requires a physical DVD-RAM capable drive and media for functionality.</li><li>Typically requires root privileges or appropriate group permissions to access low-level SCSI device files (e.g., <i>/dev/sg*</i>) for security reasons.</li><li>Not all DVD-RAM drives support all speed settings, and some may not allow software control over speed due to firmware limitations.</li><li>The actual achieved speed may be influenced by the quality of the DVD-RAM media and drive's internal mechanisms, potentially overriding the requested speed.</li><li>Proper kernel modules (e.g., <i>sr_mod</i>, <i>sg</i>) must be loaded for device recognition and SCSI command passing.</li></ul>


title: PERMISSIONS
content:
To effectively use <b>dvd-ram-control</b>, you usually need root privileges or to be part of a group (e.g., 'disk' or 'cdrom') that has direct read/write access to the raw SCSI device files (e.g., <i>/dev/sg*</i> or <i>/dev/sr*</i>). Improper permissions will result in 'Permission denied' errors.


title: MEDIA COMPATIBILITY
content:
This command is specifically designed for DVD-RAM media. Its functionality, especially speed control, is generally not applicable to other optical disc formats such as DVD-R, DVD+R, DVD-RW, or CD-R/RW, which have different mechanisms for speed and data management.


title: HISTORY
content:
<b>dvd-ram-control</b> is a component of the <i>dvd+rw-tools</i> suite, a collection of essential utilities for low-level control, formatting, and writing to various DVD formats, including DVD-RAM, on Linux systems. The suite was developed by Andy Polyakov, providing critical functionalities for managing optical drives that extend beyond standard file system operations.


title: PARAMETERS
content:
<b><i>input.dvi</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input <i>DVI</i> file to be converted. This argument is mandatory.<br><br><b><i>output.pdf</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the desired output <i>PDF</i> file. If omitted, the output filename is derived from the input <i>DVI</i> file (e.g., <i>document.dvi</i> becomes <i>document.pdf</i>).<br><br><b><b>-o</b> <i>output_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output <i>PDF</i> file. Equivalent to providing <i>output.pdf</i> as the second argument.<br><br><b><b>-p</b> <i>papersize</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the paper size for the output <i>PDF</i>. Common values include <i>a4</i>, <i>letter</i>, <i>legal</i>, etc.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in silent mode, suppressing most messages and warnings.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in verbose mode, providing more detailed output about the conversion process.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the page orientation to landscape mode.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>dvipdf</b> utility or its underlying program.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br>


title: DESCRIPTION
content:
The <b>dvipdf</b> command is a utility used in the TeX/LaTeX ecosystem to transform a <i>DVI</i> (DeVice Independent) file into a <i>PDF</i> (Portable Document Format) file. <i>DVI</i> files are the standard output of TeX or LaTeX compilers, containing typesetting instructions rather than a final rendered document. <b>dvipdf</b> acts as a bridge, interpreting these instructions and rendering them into the widely viewable <i>PDF</i> format. This allows users to easily share and print documents generated from TeX sources without needing specialized TeX viewers.<br><br>While its name suggests a direct conversion, <b>dvipdf</b> is often a wrapper script or a symbolic link that invokes more powerful and feature-rich DVI-to-PDF converters like <b>dvipdfm</b> or <b>dvipdfmx</b>. These underlying tools handle complex tasks such as embedding fonts (including Type 1 and OpenType), incorporating graphics in various formats (e.g., JPEG, PNG, EPS), and supporting advanced <i>PDF</i> features like hyperlinks and annotations. Its primary use case is for workflows where an intermediate <i>DVI</i> file is desired or required before the final <i>PDF</i> output.


title: CAVEATS
content:
The exact behavior and available options of <b>dvipdf</b> can vary significantly, as it is often a wrapper or symbolic link to more robust programs like <b>dvipdfm</b> or <b>dvipdfmx</b>. Therefore, the full range of supported features and options depends on the specific underlying implementation installed on your system. Older versions might lack support for certain modern <i>PDF</i> features or advanced graphic formats. It requires a functioning TeX distribution (like TeX Live or MiKTeX) to be present on the system for its dependencies.


title: WRAPPER FUNCTIONALITY
content:
In many Linux distributions and TeX Live installations, <b>dvipdf</b> is not a standalone executable but rather a symlink to <b>dvipdfm</b> or <b>dvipdfmx</b>. This means that when you invoke <b>dvipdf</b>, you are effectively running the underlying command, inheriting its full capabilities and options. Users are encouraged to consult the man pages for <b>dvipdfm</b> or <b>dvipdfmx</b> for a comprehensive list of all possible flags and functionalities.


title: TYPICAL USAGE WORKFLOW
content:
A common workflow for creating a <i>PDF</i> document from a LaTeX source using <b>dvipdf</b> involves two main steps:<br>1. Compile your LaTeX document to a <i>DVI</i> file: <code>latex <i>your_document</i>.tex</code><br>2. Convert the generated <i>DVI</i> file to <i>PDF</i>: <code>dvipdf <i>your_document</i>.dvi</code><br>This will typically produce <i>your_document</i>.pdf in the current directory.


title: HISTORY
content:
The need for a direct <i>DVI</i> to <i>PDF</i> conversion tool arose as <i>PDF</i> gained prominence as a portable document format. Initially, the conversion typically involved two steps: <i>DVI</i> to PostScript (using <b>dvips</b>) and then PostScript to <i>PDF</i> (using <b>ps2pdf</b>, which is based on Ghostscript). <b>dvipdf</b> was developed as a simpler, single-command wrapper for this two-step process or as a frontend for early direct <i>DVI</i>-to-<i>PDF</i> converters.<br><br>The development of more sophisticated direct converters like <b>dvipdfm</b> (DVI to PDF Manager) and later <b>dvipdfmx</b> (an extended version of <b>dvipdfm</b>, especially for CJK languages and more advanced features) made the conversion more efficient and feature-rich, directly embedding fonts and handling transparency. While <b>pdflatex</b> (which compiles LaTeX directly to <i>PDF</i>) has become the dominant method for <i>PDF</i> output from LaTeX, <b>dvipdf</b> (and its underlying tools) remains relevant for workflows that necessitate an intermediate <i>DVI</i> file or when specific features of the <i>DVI</i> processing chain are required.


title: PARAMETERS
content:
<b><b>-o</b> <i><output_file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output file. If omitted, the decoded image will be written to standard output.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version number of the <I>libwebp</I> library being used.<br><br><b><b>-h</b>, <b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short usage summary.<br><br><b><b>-short</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a very short usage summary.<br><br><b><b>-png</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the decoded image as a PNG file. This is often the default or preferred output format for transparency support.<br><br><b><b>-ppm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the decoded image as an uncompressed PPM file (for RGB) or PGM file (for grayscale), primarily for simple viewing or processing.<br><br><b><b>-tiff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the decoded image as an uncompressed TIFF file.<br><br><b><b>-yuv</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the raw YUV planes as a YUV file. Useful for video processing workflows.<br><br><b><b>-crop</b> <i><x> <y> <width> <height></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Crop the decoded image to a rectangle starting at (<i>x</i>, <i>y</i>) with the specified <i>width</i> and <i>height</i>.<br><br><b><b>-scale</b> <i><width> <height></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scale the decoded image to the specified <i>width</i> and <i>height</i>.<br><br><b><b>-resize</b> <i><width> <height></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <b>-scale</b>, resizes the decoded image.<br><br><b><b>-alpha_q</b> <i><float></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the alpha quantization factor (0-100) for transparency (lossy compression). A value of 0 means no alpha compression.<br><br><b><b>-blend_alpha</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Blend the alpha channel with a background color (default is black) instead of preserving it as a separate channel.<br><br><b><b>-nofancy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the fancy YUV420 upsampling method, which might make decoding slightly faster but with potentially lower quality.<br><br><b><b>-dither</b> <i><strength></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply dithering to the decoded image (0-100), to reduce banding artifacts, especially in images with limited color palettes.<br><br><b><b>-no_dither</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable dithering (equivalent to <b>-dither 0</b>).<br><br><b><b>-use_threads</b>, <b>-mt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use multi-threading for faster decoding on multi-core systems.<br><br><b><b>-no_metadata</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not copy any metadata (EXIF, ICC, XMP) from the input WebP file to the output file.<br><br><b><b>-no_icc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not copy ICC profile metadata.<br><br><b><b>-no_exif</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not copy EXIF metadata.<br><br><b><b>-no_xmp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not copy XMP metadata.<br><br><b><b>-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print information about the input WebP file (e.g., dimensions, alpha presence, animation properties) without decoding the image data.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the decoding process.<br><br><b><b>-quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all non-error output.<br><br>


title: DESCRIPTION
content:
<b>dwebp</b> is a command-line tool that decodes WebP image files into various common image formats such as PNG, PPM, TIFF, or YUV. It is an integral part of the official <I>libwebp</I> library, developed by Google, which provides comprehensive utilities for handling the WebP image format.<br><br>This utility is essential for converting WebP images for applications or environments that do not natively support the format, or for further processing with other image manipulation tools. It offers various options for controlling the decoding process, including scaling, cropping, dither control, alpha blending, and metadata handling, making it a versatile and powerful tool for diverse image conversion and manipulation tasks. It can also be used to inspect WebP file properties.


title: CAVEATS
content:
<b>dwebp</b> consumes memory proportional to the image size and complexity, especially when dealing with very large images or animated WebP files. Decoding animated WebP images can be resource-intensive.<br><br>While <b>dwebp</b> aims for fidelity, the quality of the output depends on the original WebP encoding parameters. Lossy WebP files will result in lossy decoded images. Compatibility with all WebP features (e.g., extended format, certain color profiles) might vary with <I>libwebp</I> versions.


title: SUPPORTED OUTPUT FORMATS
content:
Beyond the explicitly mentioned PNG, PPM, and TIFF, <b>dwebp</b> can also output raw YUV data. The specific format depends on the command-line option used. If no output format is specified and an output file is given, <b>dwebp</b> often defaults to PNG for images with alpha channels or PPM/PGM for opaque images, depending on the <I>libwebp</I> build configuration.


title: ANIMATED WEBP DECODING
content:
For animated WebP images, <b>dwebp</b> can decode individual frames. By default, it decodes only the first frame. Options like <b>-loop</b> and <b>-time</b> might be available in newer versions to control which frames of an animation are decoded, or to limit processing time for animated files.


title: HISTORY
content:
WebP, and consequently the <b>dwebp</b> utility, was developed by Google and first announced in 2010 as a new image format for the web, aiming for smaller file sizes with comparable quality to existing formats like JPEG and PNG. <b>dwebp</b> emerged as the primary tool to convert these WebP images back into widely supported formats, facilitating adoption and integration into existing workflows. Its development has closely tracked the evolution of the WebP format, adding support for features like animation (animated WebP) and extended format capabilities over time, continuously improving its decoding efficiency and feature set.


title: DESCRIPTION
content:
<i>dwm</i>, the <b>D</b>ynamic <b>W</b>indow <b>M</b>anager, is an extremely fast, small, and dynamic tiling window manager for X. Designed with minimalism and efficiency in mind, it provides a highly customizable and keyboard-driven desktop experience. Unlike most window managers, <i>dwm</i>'s configuration is managed by editing its C source code and recompiling it. This unique approach means there are no runtime configuration files, ensuring a lean and robust system.<br><br>It supports various layouts, including tiling, monocle (fullscreen), and floating modes, allowing users to efficiently manage their workspace. Windows are organized by 'tags' (workspaces), enabling seamless navigation between different sets of applications. Its low memory footprint and rapid response times make it a favorite among power users who prioritize speed and simplicity over graphical frills. As part of the <i>Suckless project</i> philosophy, <i>dwm</i> adheres to principles of clarity, frugality, and transparency, offering a highly personalized and efficient computing environment.


title: CAVEATS
content:
<i>dwm</i>'s unique configuration method, requiring modification of its C source code and recompilation, can be a significant hurdle for new users or those unfamiliar with software development. It lacks traditional graphical configuration tools or runtime configuration files. Furthermore, its minimalist design means it doesn't include many features commonly found in other desktop environments, such as a default application launcher, extensive system trays, or integrated notification systems, requiring users to install and configure these components separately. Users must be comfortable with the command line and basic C programming concepts to fully customize their <i>dwm</i> experience.


title: CONFIGURATION METHOD
content:
<i>dwm</i> is unique in that its configuration is done entirely by editing its C source code file, <I>config.h</I>, and then recompiling the program. This means there are no runtime configuration files in your home directory. All keybindings, layouts, colors, and other settings are hardcoded into the executable. This approach ensures extreme speed and a tiny memory footprint, but requires users to be comfortable with C compilation.


title: LACK OF COMMAND-LINE PARAMETERS
content:
The <i>dwm</i> command itself accepts no traditional command-line arguments for configuration or behavior modification. It is typically started as part of your X session via <I>.xinitrc</I> or a display manager. All customizations must be applied during compilation.


title: COMMUNITY PATCHES
content:
While <i>dwm</i> itself remains minimalist, a vibrant community around it develops and shares 'patches' – small modifications to the source code – to add desired features like status bar modules, specific layout variations, or advanced window rules. Users can apply these patches to their <i>dwm</i> source before compiling to extend its functionality.


title: HISTORY
content:
First released in 2006 by the <i>Suckless.org</i> community, <i>dwm</i> emerged as a radical departure from conventional window managers. Its development was driven by the principles of simplicity, clarity, and parsimony, aiming to create software that is small, fast, and secure. Unlike its contemporaries, <i>dwm</i> eschewed runtime configuration files in favor of compile-time configuration via its <i>config.h</i> source file. This design choice solidified its reputation as a window manager for advanced users who value control and efficiency. Over the years, <i>dwm</i> has maintained a steady development pace, focusing on refining its core functionality and adherence to its minimalist ethos rather than adding complex features. Its unique approach has influenced a generation of minimalist desktop enthusiasts and other tiling window manager projects.


title: DESCRIPTION
content:
<i>The 'dwp' command is not a standard or commonly recognized utility in typical Linux distributions. Extensive searches in standard manual pages, common command listings, and package repositories do not yield a program with this name.<br><br>It is highly probable that 'dwp' might be:<br><b>1. A custom script or alias:</b> Many users create their own commands for specific tasks, which are then run via a shell script or defined as an alias in their shell configuration (.bashrc, .zshrc, etc.).<br><b>2. A typo:</b> It could be a misspelling of a common command such as <b>pwd</b> (print working directory), <b>df</b> (disk free), <b>du</b> (disk usage), or <b>dpkg</b> (Debian package manager).<br><b>3. Part of a niche application:</b> Rarely, a command might belong to a very specific, non-standard, or enterprise-level software package not widely distributed or documented publicly.<br><br>Without further context about its origin or the environment where it was encountered, it is impossible to provide an accurate analysis or description of a 'dwp' Linux command, as it is not part of the standard Linux command set.</i>


title: CAVEATS
content:
<i>As 'dwp' is not a recognized standard Linux command, attempting to execute it on a typical system will almost certainly result in a 'command not found' error. Any behavior associated with 'dwp' would be entirely dependent on its specific implementation if it exists as a custom script, an alias, or part of a non-standard application. Its functionality, if any, is not documented in standard Linux resources.</i>


title: <I>IDENTIFYING NON-STANDARD COMMANDS</I>
content:
<i>If you encounter 'dwp' in a specific Linux environment, you might try the following to understand its origin:<br><b>1. `type dwp`:</b> This command can reveal if 'dwp' is an alias, a function, or an executable.<br><b>2. `which dwp`:</b> If it's an executable, this command will show its path. You can then inspect the file, especially if it's a shell script.<br><b>3. Check shell configuration files:</b> Look into files like `~/.bashrc`, `~/.zshrc`, or `/etc/profile` for alias or function definitions.</i>


title: HISTORY
content:
<i>There is no documented history for a standard 'dwp' Linux command, as it does not appear in common Linux distributions' utilities or historical command sets.</i>


title: DESCRIPTION
content:
The command 'dysk' is not a standard or commonly recognized utility in typical Linux distributions. It is highly probable that this is a typographical error for other common disk-related commands such as <b><I>du</I></b> (disk usage), <b><I>df</I></b> (disk free), <b><I>lsblk</I></b> (list block devices), <b><I>fdisk</I></b> (partition table manipulator), or <b><I>parted</I></b> (partition editor).<br><br>Users seeking to manage, inspect, or monitor disk space and partitions should refer to these standard utilities, which provide a wide range of functionalities for file system and block device management. The 'dysk' command, as specified, does not have any documented or functional equivalent in mainstream Linux environments.


title: CAVEATS
content:
This analysis is based on the premise that 'dysk' refers to a standard Linux command. Since no such command exists, attempting to execute 'dysk' will result in a 'command not found' error. Users should double-check the spelling of the command they intend to use, especially if they are looking for disk-related functionalities.


title: COMMON DISK MANAGEMENT COMMANDS
content:
For users looking to manage disk space, partitions, or file systems, here are some commonly used commands:<br><b><I>du</I></b>: Summarize disk usage of the set of FILEs, recursively for directories.<br><b><I>df</I></b>: Report file system disk space usage.<br><b><I>lsblk</I></b>: List information about all available or the specified block devices.<br><b><I>fdisk</I></b>: A dialog-driven program for creation and manipulation of partition tables.<br><b><I>parted</I></b>: A partition manipulation program that supports many partition table formats.


title: HISTORY
content:
There is no documented history for a standard Linux command named 'dysk' as it does not exist within the typical Linux command set.


title: PARAMETERS
content:
<b><i>-c cluster_size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report fragmentation based on units of <i>cluster_size</i> instead of the filesystem's block size. The <i>cluster_size</i> must be a power of 2.<br><br><b><i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print numbers in human-readable units (e.g., 1K, 23M, 2G).<br><br><b><i>-t</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show overall tree information. This provides a more detailed breakdown of the free space B-tree structure, often including internal node usage.<br><br><b><i>-V</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version number of <i>e2freefrag</i> and exit.<br><br>


title: DESCRIPTION
content:
The <i>e2freefrag</i> command is a utility from the <i>e2fsprogs</i> suite designed to analyze the fragmentation of free space on ext2, ext3, and ext4 filesystems. It provides valuable insights into how free blocks are distributed across the disk. <br><br>While Linux filesystems, especially ext4, are generally good at minimizing file fragmentation during writes, free space itself can become fragmented over time, leading to a large number of small, discontiguous free extents. This can potentially impact performance when allocating new large files, as the system may struggle to find contiguous blocks. <br><br><i>e2freefrag</i> reports metrics such as the average free extent size, the number of free extents, and a fragmentation index. It's crucial to understand that <i>e2freefrag</i> is an <b>analysis</b> tool, not a defragmentation tool. It does not modify the filesystem; it merely reports its state.


title: CAVEATS
content:
<i>e2freefrag</i> only <b>analyzes</b> free space fragmentation; it does <b>not</b> perform defragmentation. For the most accurate results, especially on active filesystems, it's best run on an unmounted filesystem or a mounted read-only filesystem. Running on a mounted read-write filesystem might yield slightly less accurate results due to ongoing changes, but it is generally safe as it performs only read operations and does not modify the filesystem.


title: INTERPRETING OUTPUT
content:
The output of <i>e2freefrag</i> typically includes several key metrics:<br><b>Average free extent size:</b> This is the average size of contiguous blocks of free space on the filesystem. A smaller average might indicate higher fragmentation, meaning free space is scattered in many small chunks.<br><br><b>Number of free extents:</b> This represents the total count of separate contiguous blocks of free space. A higher number for a given amount of total free space generally suggests more severe fragmentation, as the free space is broken into more pieces.<br><br><b>Fragmentation index:</b> This is a calculated metric indicating the overall degree of fragmentation. While the exact formula can vary, lower values are generally better, indicating less fragmentation. A higher index suggests more severe free space fragmentation.<br><br>High free space fragmentation can suggest that new, large files might be written in a scattered manner, potentially affecting read/write performance over time. If severe fragmentation is observed, and performance is a concern, a common approach to remedy it (since there's no native free-space defragmenter for ext filesystems) is to back up all data, reformat the filesystem, and then restore the data. This process effectively 'defragments' the free space by writing data contiguously onto a freshly empty filesystem.


title: HISTORY
content:
<i>e2freefrag</i> is part of the robust <i>e2fsprogs</i> package, a comprehensive collection of utilities for the ext2, ext3, and ext4 filesystems in Linux. Developed and maintained primarily by Theodore Ts'o, <i>e2fsprogs</i> has been a fundamental component of Linux filesystem management for decades. <i>e2freefrag</i> was introduced to address the specific need for a diagnostic tool to assess free space fragmentation, complementing other tools that manage or check the filesystem's integrity and performance.


title: PARAMETERS
content:
<b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically repair the filesystem without prompting. This option is generally safe for minor issues.<br><br><b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Same as <i>-p</i>; provided for backward compatibility. This option is deprecated.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all questions, automatically fixing issues. Use with caution as it can make potentially destructive changes.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'no' to all questions, preventing any modifications. This makes <i>e2fsck</i> run in read-only mode, useful for inspection.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force checking the filesystem, even if it appears clean (i.e., has a valid 'last check' timestamp).<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output, showing more details about the checks being performed.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for bad blocks on the device and add them to the bad block inode. This can take a long time.<br><br><b>-b <i>superblock</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an alternative superblock. This is useful if the primary superblock is corrupted. Common backup superblocks are 8193, 16385, etc.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize directories by reordering directory entries and compacting them. This can improve directory lookup performance.<br><br><b>-E <i>extended_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set extended options, such as <i>discard</i> (for SSD TRIM operations) or <i>ea_inode_size</i>.<br><br>


title: DESCRIPTION
content:
<i>e2fsck</i> is a utility used to check and optionally repair ext2, ext3, and ext4 filesystems in Linux. It performs a series of comprehensive checks on the filesystem's metadata, including superblocks, inodes, directories, and block bitmaps, to detect inconsistencies. If any errors are found, <i>e2fsck</i> attempts to correct them automatically or interactively, depending on the options provided.<br><br>It is crucial to run <i>e2fsck</i> on an <b>unmounted</b> filesystem to prevent data corruption and loss. Running it on a mounted, especially writeable, filesystem can lead to severe damage. The command is often invoked automatically at system boot time if the system detects an unclean shutdown or after a certain number of mounts/time intervals, as configured by <i>tune2fs</i>. While it can resolve many common filesystem issues, heavily corrupted filesystems might require more advanced recovery methods, and data loss can still occur.


title: CAVEATS
content:
<b><br>Critical Warning:</b> Always ensure the filesystem is <b>unmounted</b> before running <i>e2fsck</i>. Running it on a mounted filesystem, especially one with write access, can lead to severe data corruption and irreversible data loss. While <i>e2fsck</i> can fix many issues, it is not a data recovery tool for heavily damaged filesystems, and some data loss might still occur. It requires root privileges to execute.


title: EXIT STATUS CODES
content:
<i>e2fsck</i> returns various exit codes that are crucial for scripting and automated system maintenance:<br><b>0</b> - No errors.<br><b>1</b> - Filesystem errors corrected.<br><b>2</b> - Filesystem errors corrected, and system should be rebooted.<br><b>4</b> - Filesystem errors left uncorrected.<br><b>8</b> - Operational error.<br><b>16</b> - Usage or syntax error.<br><b>32</b> - <i>e2fsck</i> canceled by user request.<br><b>128</b> - Shared library error.


title: SAFETY PRECAUTION
content:
Before attempting repairs with options like <i>-y</i> on critical filesystems, especially those with unbacked-up data, consider backing up the data first if possible. Alternatively, use a live CD/USB to boot and run <i>e2fsck</i> in a controlled environment, perhaps initially with <i>-n</i> to assess the damage without making changes.


title: HISTORY
content:
<i>e2fsck</i> is a fundamental component of the <i>e2fsprogs</i> package, which provides a suite of utilities for managing ext2, ext3, and ext4 filesystems. It was primarily developed by <b>Theodore Ts'o</b>, who also spearheaded much of the development of the ext filesystem family.<br><br>Its design was heavily influenced by <i>fsck_ffs</i>, the filesystem checker for the Fast File System (FFS) used in BSD operating systems. Over time, <i>e2fsck</i> has evolved significantly to support the added complexities and features of ext3 (journaling) and ext4 (extents, larger filesystems, nanosecond timestamps), maintaining its role as the primary tool for filesystem integrity checks in Linux environments.


title: PARAMETERS
content:
<b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Raw mode. Copies all blocks as they are, including unused and deleted blocks. This creates a larger image, similar to <i>dd</i> for the used portion of the filesystem, useful for advanced forensic analysis.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parse-only mode. <i>e2image</i> will read the filesystem structure but will not write any output file. Useful for validating options or device integrity without creating an image.<br><br><b><b>-O</b> <i>output_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify output options to control what is written to the image file. Multiple options can be comma-separated. Common options include:<br>  <i>no_super</i>: Do not write the superblock and block group descriptors.<br>  <i>super_only</i>: Only write the superblock and block group descriptors.<br>  <i>all_inodes</i>: Write all inode blocks, including those marked as unused.<br>  <i>all_blocks</i>: Write all allocated data blocks (including metadata and file data), not just metadata structures.<br>  <i>journal</i>: Include the filesystem journal blocks in the image (this is typically the default).<br>  <i>write_jnl_blocks</i>: Write blocks referenced by the journal even if they are not part of an inode or directory.<br>  <i>write_blocks</i>: Write all blocks referred to by inodes and directories (this is the default behavior for the metadata-only image).<br><br><b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the ext2/ext3/ext4 filesystem device (e.g., <i>/dev/sda1</i>).<br><br><b><i>image_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the output image file will be created.<br><br>


title: DESCRIPTION
content:
<i>e2image</i> is a utility from the <i>e2fsprogs</i> package designed to create a raw image of an ext2, ext3, or ext4 filesystem. Unlike generic block-level copying tools like <i>dd</i>, <i>e2image</i> intelligently copies only the filesystem metadata, such as superblocks, group descriptors, inode tables, directory blocks, and block bitmaps, making the resulting image significantly smaller than the original device. This 'metadata-only' image is invaluable for debugging corrupted filesystems, analyzing filesystem structures, or performing forensic investigations without altering the original device.<br><br>While its primary mode creates a compact metadata image, <i>e2image</i> can also be instructed to include all allocated data blocks, or even raw blocks including deleted data, via specific options. The generated image file is not directly mountable as a filesystem but is intended for use with other <i>e2fsprogs</i> utilities like <i>debugfs</i> for interactive exploration or <i>e2fsck -D</i> for advanced filesystem checking and debugging.


title: CAVEATS
content:
For a consistent image, the target filesystem should ideally be unmounted or mounted read-only. Creating an image of a live, mounted, writable filesystem can lead to an inconsistent or corrupted image reflecting an intermediate state. <i>e2image</i> is not a backup solution; it's primarily a diagnostic and forensic tool. The resulting image is not directly mountable by the Linux kernel.


title: USAGE WITH DEBUGGING TOOLS
content:
The primary use case for an <i>e2image</i> output file is with tools like <i>debugfs</i> or <i>e2fsck -D</i>. For instance, to open an image for interactive debugging, you would use '<i>debugfs -i /path/to/your_image.e2i</i>'. This allows filesystem administrators and developers to examine the internal structure of a potentially damaged filesystem safely, without risking further damage to the original device.


title: FORENSIC ANALYSIS
content:
When used with the <i>-r</i> (raw) or <i>-O all_blocks</i> options, <i>e2image</i> can capture a more comprehensive snapshot of the filesystem, including all allocated data blocks. This capability is crucial in forensic investigations, enabling examiners to analyze filesystem structures and potentially recover deleted files or fragments from a copy rather than directly from the evidence source.


title: HISTORY
content:
<i>e2image</i> is an integral part of the <i>e2fsprogs</i> project, a suite of utilities for managing the ext2, ext3, and ext4 filesystems on Linux. Developed by Theodore Ts'o, the primary maintainer of <i>e2fsprogs</i> and a key figure in Linux kernel development, <i>e2image</i> was created to provide a specialized, efficient way to capture the critical metadata of ext filesystems for analysis and debugging, avoiding the overhead of raw device copying when only structural information is needed. Its development paralleled the evolution and maintenance of the ext filesystem family itself.


title: PARAMETERS
content:
<b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces execution, even if the filesystem is mounted or has errors. Use with extreme caution.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run; does not actually write any changes to the filesystem.<br><br><b><b>-o</b> <i>offset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the undo log to a specified device offset, useful for snapshots or LVM.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operation.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information and exits.<br><br><b><i>undo_log</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the undo log file to be replayed.<br><br><b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the block device containing the Ext2/3/4 filesystem to be modified.<br><br>


title: DESCRIPTION
content:
<b>e2undo</b> is a specialized utility designed to reverse metadata changes on Ext2, Ext3, or Ext4 filesystems. It achieves this by replaying an "undo log" file. These undo logs are typically generated by other <i>e2fsprogs</i> utilities like <b>e2fsck</b> (during filesystem checks) or <b>resize2fs</b> (when shrinking a filesystem).<br><br>The log captures metadata modifications made by these operations, allowing <b>e2undo</b> to revert the filesystem to its state <i>before</i> the problematic operation occurred. This tool is crucial for disaster recovery scenarios, enabling administrators to recover from unintended or corrupting changes. It is paramount that the target filesystem is <b>NOT</b> mounted when <b>e2undo</b> is executed to prevent data corruption. Users specify the undo log file and the target device where the changes should be applied.


title: CAVEATS
content:
It is <b>CRITICAL</b> that the filesystem specified by <i>device</i> is <b>NOT</b> mounted when <b>e2undo</b> is run. Running it on a mounted filesystem can lead to severe data corruption. Users should also exercise extreme caution when using the <b>-f</b> (force) option.


title: UNDO LOG GENERATION
content:
Undo logs are not generated by <b>e2undo</b> itself. They are typically created by other <b>e2fsprogs</b> utilities such as <b>e2fsck</b> (using the <b>-E undo_dir</b> or <b>-E undo_file</b> option) during a filesystem check, or by <b>resize2fs</b> (using the same options) when shrinking a filesystem. These logs record metadata changes for potential reversal.


title: HISTORY
content:
<b>e2undo</b> is part of the <i>e2fsprogs</i> project, a comprehensive suite of utilities for maintaining and administering the Ext2, Ext3, and Ext4 filesystems in Linux. Its development is intrinsically tied to the evolution of these filesystems and the persistent need for robust recovery mechanisms. The ability to generate and replay undo logs was introduced to provide a safer way to perform potentially destructive operations like filesystem checks or resizing, allowing administrators to revert changes if an operation fails or results in undesirable outcomes.


title: SYNOPSIS
content:
<b>e4defrag [<i>options</i>] <i>file</i>|<i>directory</i>...</b><br><b>e4defrag -c [<i>options</i>] <i>file</i>|<i>directory</i>...</b>


title: PARAMETERS
content:
<b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the current fragmentation level of the specified files or directories without performing defragmentation. It reports the number of fragmented files and their total fragmentation score.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the defragmentation process, including the progress and the fragmentation statistics for each file.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for e4defrag and exits.<br><br>


title: DESCRIPTION
content:
<b>e4defrag</b> is a utility designed to defragment individual files or directories on an <b>ext4</b> filesystem. Unlike traditional offline defragmentation tools that operate on the entire filesystem, <b>e4defrag</b> works <i>online</i>, meaning it can be run while the filesystem is mounted and in use. Its primary purpose is to improve read/write performance for fragmented files by consolidating their data blocks into contiguous regions on disk.<br><br>While fragmentation on modern filesystems and SSDs is less of a concern, it can still impact performance, especially for frequently modified large files or databases on traditional hard disk drives (HDDs). The command uses the <b>EXT4_IOC_MOVE_EXT</b> ioctl, a kernel-level operation, to efficiently move extents (contiguous block groups) of a file. It does not reclaim unused blocks or shrink the filesystem; it only rearranges existing file data.


title: CAVEATS
content:
<b>e4defrag</b> is specifically designed for <b>ext4</b> filesystems and will not work on other filesystem types (e.g., XFS, Btrfs, ext3). It requires a Linux kernel that supports the necessary online defragmentation ioctls (e.g., <b>EXT4_IOC_MOVE_EXT</b>), typically available since kernel 2.6.28 or later. While it can improve performance for highly fragmented files, it does <i>not</i> reclaim unused space for the filesystem or reduce its overall size; it only rearranges existing data. For filesystems on Solid State Drives (SSDs), defragmentation is generally unnecessary and can even reduce the lifespan of the SSD due to increased write amplification. Always ensure you have backups before performing significant disk operations.


title: KERNEL REQUIREMENTS
content:
The functionality of <b>e4defrag</b> relies on specific kernel support for online ext4 defragmentation, notably the <b>EXT4_IOC_MOVE_EXT</b> ioctl. This feature became stable and widely available in Linux kernels from version 2.6.28 onwards. Running <b>e4defrag</b> on older kernels or kernels without this support will likely result in errors or non-functional behavior.


title: MECHANISM OF OPERATION
content:
Unlike traditional block-level defragmenters that operate on the entire disk, <b>e4defrag</b> works by moving 'extents' (contiguous blocks of data) within a file. It identifies fragmented files and attempts to relocate their extents to consolidate them into larger, contiguous extents. This process is performed online, meaning the file can remain open and in use during defragmentation, although performance might be temporarily impacted by the I/O activity.


title: WHEN TO USE?
content:
While fragmentation is less critical on modern Linux systems, <b>e4defrag</b> can still be beneficial in specific scenarios:<br><ul><li>On traditional spinning Hard Disk Drives (HDDs) that store frequently modified large files (e.g., video files, large databases, virtual machine images).</li><li>To improve sequential read/write performance for applications that heavily rely on contiguous file access.</li><li>When fragmentation levels are exceptionally high (which <b>e4defrag -c</b> can report) and causing noticeable performance degradation.</li></ul>It is generally <i>not</i> recommended for SSDs, as it increases writes unnecessarily and offers little to no performance benefit due to the nature of SSDs.


title: HISTORY
content:
<b>e4defrag</b> was introduced as part of the <b>e2fsprogs</b> utilities, which provide a suite of tools for managing <b>ext2</b>, <b>ext3</b>, and <b>ext4</b> filesystems. Its development specifically targeted the <b>ext4</b> filesystem, leveraging new kernel features that allow for online extent-based defragmentation. The core functionality relies on the <b>EXT4_IOC_MOVE_EXT</b> ioctl, which was added to the Linux kernel around version 2.6.28-2.6.30. This command provides a user-space interface to this kernel capability, making online defragmentation of individual files a reality for <b>ext4</b>, addressing some fragmentation concerns prevalent on traditional spinning hard drives without requiring filesystem unmounting.


title: SYNOPSIS
content:
<b>easside-ng</b> -i <i>&lt;interface&gt;</i> [-s <i>&lt;ap_mac&gt;</i>] [-m <i>&lt;client_mac&gt;</i>] [-n <i>&lt;num_requests&gt;</i>] [-r <i>&lt;replay_file&gt;</i>] [-v] [-h]


title: PARAMETERS
content:
<b>-i <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the wireless interface to use, which must be in monitor mode (e.g., wlan0mon).<br><br><b>-s <i>&lt;ap_mac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the MAC address of the target Access Point. This is typically discovered using <i>airodump-ng</i>.<br><br><b>-m <i>&lt;client_mac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the MAC address to be used by <b>easside-ng</b> to spoof a client. Can be an arbitrary MAC address.<br><br><b>-n <i>&lt;num_requests&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of ARP requests (or similar packets) to send to the AP to generate IVs. A higher number increases the chance of success but also network noise.<br><br><b>-r <i>&lt;replay_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Saves the captured packets (containing IVs) to a .cap file for later analysis or cracking with <i>aircrack-ng</i>.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the operation.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
The <b>easside-ng</b> command is a specialized tool within the <i>aircrack-ng</i> suite, designed for performing a specific type of WEP (Wired Equivalent Privacy) client-side attack. Its primary purpose is to recover WEP keys from an Access Point (AP) without requiring an associated client. This is achieved by implementing an attack, often referred to as a 'Caffe Latte' attack, where <b>easside-ng</b> spoofs a client and sends specially crafted packets to the AP. The AP, in response, generates ARP requests or other packets, which <b>easside-ng</b> captures. These captured packets, containing Initialization Vectors (IVs), can then be used by <i>aircrack-ng</i> to crack the WEP key.<br><br>While WEP is an outdated and insecure encryption standard, <b>easside-ng</b> remains a historical example of how vulnerabilities in WEP could be exploited. It requires a wireless network adapter capable of monitor mode and packet injection. Users typically set their wireless card to monitor mode using <i>airmon-ng</i> before employing <b>easside-ng</b>.


title: CAVEATS
content:
<b>easside-ng</b> is designed for WEP networks, an obsolete and highly insecure encryption standard. Its use on modern WPA/WPA2/WPA3 networks is not applicable.<br>Successful execution requires a wireless adapter capable of monitor mode and packet injection.<br>Legal implications: Always ensure you have explicit permission before performing security testing on any network.


title: THE CAFFE LATTE ATTACK
content:
The 'Caffe Latte' attack, implemented by <b>easside-ng</b>, exploits a vulnerability in how some Access Points handle ARP requests. The attacker (<b>easside-ng</b>) sends a specially crafted ARP request to the AP, spoofing a non-existent client. The AP, attempting to resolve the ARP, generates an ARP reply packet (which is encrypted with the WEP key) and broadcasts it. By capturing these replies, the attacker collects sufficient IVs to then crack the WEP key using <i>aircrack-ng</i>. A key characteristic of this attack is that it does not require an actual client to be associated with the target AP, making it a powerful method for WEP key recovery in certain scenarios.


title: HISTORY
content:
<b>easside-ng</b> is a component of the comprehensive <i>aircrack-ng</i> suite, which evolved from the original <i>aircrack</i> project. It was developed to specifically address WEP client-side attacks, particularly the 'Caffe Latte' attack, which became prominent in the mid-2000s. As WEP became increasingly deprecated in favor of more robust encryption standards like WPA, the direct utility of tools like <b>easside-ng</b> diminished. However, it remains valuable for understanding historical wireless security vulnerabilities and for educational purposes within controlled environments.


title: PARAMETERS
content:
<b><I>input_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the source e-book file.<br><br><b><I>output_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path for the converted e-book file. The extension typically determines the output format.<br><br><b><b>--authors</b> <I>"Names"</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the authors for the output book, e.g., <I>"John Doe & Jane Smith"</I>.<br><br><b><b>--title</b> <I>"Title"</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the title for the output book.<br><br><b><b>--output-profile</b> <I>profile_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output device profile (e.g., <I>kindle</I>, <I>kobo</I>).<br><br><b><b>--enable-heuristics</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable heuristic processing to improve conversion results by fixing common issues.<br><br><b><b>--no-default-epub-cover</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate a default cover for EPUB output if one is not specified.<br><br><b><b>--input-encoding</b> <I>encoding</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the character encoding of the input document (e.g., <I>utf-8</I>).<br><br><b><b>--output-encoding</b> <I>encoding</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the character encoding for the output document.<br><br><b><b>--extra-css</b> <I>path_to_css_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to an additional CSS file to apply during conversion, overriding or extending existing styles.<br><br><b><b>--chapter</b> <I>xpath_expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An XPath expression to identify chapters in the input document for TOC generation.<br><br><b><b>--page-breaks-before</b> <I>xpath_expression</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An XPath expression to identify locations where new page breaks should be inserted.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print more detailed information during the conversion process, useful for debugging.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message listing all available options and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br>


title: DESCRIPTION
content:
<b>ebook-convert</b> is a <b>powerful command-line tool</b> that is a core component of the popular open-source <I>Calibre</I> e-book management suite. It is designed for high-quality, flexible conversion between a vast array of e-book formats.<br><br>Users can convert from formats like EPUB, MOBI, AZW3, PDF, DOCX, HTML, RTF, and TXT, to target formats such as EPUB, MOBI, AZW3, PDF, TXT, HTMLZ, OEB, and many others. The command offers extensive control over the conversion process through numerous options, allowing customization of metadata, table of contents generation, styling, font embedding, image handling, and more. It is an indispensable tool for automating e-book workflows or for users who prefer command-line operations.


title: CAVEATS
content:
PDF output quality can be highly variable and difficult to control precisely due to the complex nature of PDF rendering and the inherent lossiness of converting from a fixed-layout format. <br>Conversion of complex layouts, especially from PDF inputs, might not always yield perfect results and may require significant fine-tuning of options. <br>The extensive number of options can make the command-line arguments very long and complex for advanced customizations, requiring careful attention to syntax and escaping characters.


title: BATCH PROCESSING
content:
While <b>ebook-convert</b> processes one file at a time, its command-line nature makes it ideal for <I>batch processing</I>. It can be easily integrated into shell scripts or other automation tools to convert entire directories of e-books efficiently, making it a powerful tool for large collections.


title: ADVANCED CUSTOMIZATION WITH CSS AND XPATH
content:
The command offers advanced customization capabilities through the use of external CSS files for precise styling control and <I>XPath expressions</I> for fine-grained manipulation of document structure, such as identifying chapters, page breaks, or specific HTML elements for processing during conversion.


title: HISTORY
content:
<b>ebook-convert</b> is a core component of the <I>Calibre</I> e-book management software, which was first released in October 2006. It originated from a Python script written by Kovid Goyal to convert LRF (Sony Reader) format files to provide content for his Sony Reader device. As Calibre evolved into a comprehensive e-book ecosystem, <b>ebook-convert</b> became its powerful and flexible conversion engine, continually updated to support an ever-growing array of e-book formats and sophisticated conversion features.


title: PARAMETERS
content:
<b>`<b>-t</b> <i>table</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the table to operate on: <i>filter</i> (default), <i>nat</i>, or <i>broute</i>.<br><br><b>`<b>-A</b>, <b>--append</b> <i>chain</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends one or more rules to the end of the specified <i>chain</i>.<br><br><b>`<b>-D</b>, <b>--delete</b> <i>chain</i> [<i>rulenum</i>]`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes one or more rules from the specified <i>chain</i>. Can specify by rule number or full rule.<br><br><b>`<b>-I</b>, <b>--insert</b> <i>chain</i> [<i>rulenum</i>]`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inserts one or more rules at the specified position (or beginning) in the <i>chain</i>.<br><br><b>`<b>-P</b>, <b>--policy</b> <i>chain</i> <i>policy</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default <i>policy</i> for a built-in <i>chain</i> (e.g., <b>ACCEPT</b> or <b>DROP</b>).<br><br><b>`<b>-L</b>, <b>--list</b> [<i>chain</i>]`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the rules in the specified <i>chain</i> or all chains if none is specified.<br><br><b>`<b>-F</b>, <b>--flush</b> [<i>chain</i>]`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Flushes (deletes all rules from) the specified <i>chain</i> or all chains if none is specified.<br><br><b>`<b>-N</b>, <b>--new-chain</b> <i>chain</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new user-defined <i>chain</i>.<br><br><b>`<b>-X</b>, <b>--delete-chain</b> [<i>chain</i>]`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a user-defined <i>chain</i>.<br><br><b>`<b>-j</b>, <b>--jump</b> <i>target</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>target</i> of a rule: <b>ACCEPT</b>, <b>DROP</b>, <b>RETURN</b>, a user-defined <i>chain</i>, or an extension target like <b>LOG</b>.<br><br><b>`<b>-p</b>, <b>--protocol</b> <i>protocol</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the Ethernet <i>protocol</i> type (e.g., <b>ARP</b>, <b>IPv4</b>, <b>IPv6</b>, <b>802_1Q</b>).<br><br><b>`<b>--src</b>, <b>--source</b> <i>MAC[/mask]</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the source MAC address.<br><br><b>`<b>--dst</b>, <b>--destination</b> <i>MAC[/mask]</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches the destination MAC address.<br><br><b>`<b>-i</b>, <b>--in-interface</b> <i>name</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches frames entering the bridge via the specified <i>name</i> interface.<br><br><b>`<b>-o</b>, <b>--out-interface</b> <i>name</i>`</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Matches frames leaving the bridge via the specified <i>name</i> interface.<br><br>


title: DESCRIPTION
content:
`<b>ebtables</b>` is a user-space utility for configuring the Linux kernel's Ethernet bridge firewall tables. It operates at <b>Layer 2</b> of the OSI model, specifically designed to filter, modify, and manage <b>Ethernet frames</b> within Linux bridges. <br><br>It provides three main tables: <br>- <b>filter</b>: For filtering Ethernet frames based on various Layer 2 criteria (e.g., MAC addresses, Ethernet types).<br>- <b>nat</b>: For performing Network Address Translation (NAT) on Ethernet frames, primarily used to modify source or destination MAC addresses.<br>- <b>broute</b>: (Bridge-route) For making routing decisions on bridged frames, allowing traffic to be forced to Layer 3 routing even if it's supposed to be routed.<br><br>`<b>ebtables</b>` is essential for implementing granular security policies and traffic control in bridged network environments, complementing higher-layer firewall tools like <b>iptables</b>. It enables administrators to control exactly what Ethernet frames are allowed to traverse a bridge, which ones are dropped, or how their MAC addresses are altered.


title: CAVEATS
content:
<b>ebtables</b> operates solely at <b>Layer 2</b> (Ethernet frames) and does not inspect higher-layer protocols (like IP, TCP, UDP) by default. For Layer 3/4 filtering, <b>iptables</b> or <b>nftables</b> are required. <br><br>Rules configured with <b>ebtables</b> are <i>volatile</i> and will be lost upon system reboot unless explicitly saved using <b>ebtables-save</b> and restored using <b>ebtables-restore</b>, typically via a system service. <br><br>Its effectiveness is primarily within bridged environments; it filters traffic traversing a Linux bridge, not traffic flowing through a router. <br><br>Complexity can arise when combining <b>ebtables</b> with <b>iptables</b> or other networking tools, requiring careful consideration of packet flow through the kernel's various processing hooks.


title: EXTENSIONS
content:
Similar to `<b>iptables</b>`, `<b>ebtables</b>` supports various extensions that provide additional matching criteria or targets. These extensions allow for more specific filtering, such as matching IP addresses (e.g., `<b>--ip-src</b>`, `<b>--ip-dst</b>` with the `<b>ip</b>` protocol extension), ARP attributes, VLAN tags, and more. They are loaded dynamically when required.


title: TABLES AND CHAINS OVERVIEW
content:
Each of the three tables (<b>filter</b>, <b>nat</b>, <b>broute</b>) in `<b>ebtables</b>` contains several built-in chains, which are points where frames are processed. Common chains include <b>PREROUTING</b> (frames arriving at the bridge), <b>INPUT</b> (frames destined for the bridge itself), <b>FORWARD</b> (frames traversing the bridge), <b>OUTPUT</b> (frames generated by the bridge), and <b>POSTROUTING</b> (frames leaving the bridge). Users can also create their own custom chains.


title: HISTORY
content:
`<b>ebtables</b>` was developed by Bart De Schutter and first integrated into the Linux kernel around version 2.4.20. Its creation addressed the need for fine-grained Ethernet frame firewalling, a capability that existing tools like `<b>iptables</b>` could not directly provide at <b>Layer 2</b>. It has since become a standard component of Linux distributions for managing traffic on bridge devices, providing a robust and stable solution for Layer 2 security and traffic control. While newer frameworks like `<b>nftables</b>` can also perform Layer 2 filtering, `<b>ebtables</b>` remains widely used for its specific focus and established presence.


title: SEE ALSO
content:
<b>brctl(8)</b>: Utility for administering Linux Ethernet bridges., <b>iptables(8)</b>: Administration tool for IPv4 packet filtering and NAT., <b>ip6tables(8)</b>: Administration tool for IPv6 packet filtering and NAT., <b>arptables(8)</b>: Administration tool for ARP packet filtering., <b>ebtables-save(8)</b>: Saves <b>ebtables</b> rules to a file., <b>ebtables-restore(8)</b>: Restores <b>ebtables</b> rules from a file., <b>nft(8)</b>: Successor to iptables, ip6tables, and arptables, capable of Layer 2 filtering.


title: SYNOPSIS
content:
ebuild <path/to/ebuild> <phase> [<phase>...]<br>ebuild <path/to/ebuild> [options] <phase> [<phase>...]


title: PARAMETERS
content:
<b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force</i> a specific action, overriding safety checks that might otherwise prevent it.<br><br><b>--keep-going</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Continue</i> building even if an error occurs in an earlier phase, for troubleshooting.<br><br><b>--skip-phase <phase></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Skip</i> a named phase during the build process, useful for debugging or specific scenarios.<br><br><b>--read-only-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disallow</i> modifications to the root filesystem during the build process, enhancing safety.<br><br><b>fetch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Download</i> all required source files for the package to the designated source directory.<br><br><b>unpack</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Decompress</i> and extract source archives into a temporary build directory.<br><br><b>prepare</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Apply</i> patches and perform initial setup operations before the main compilation begins.<br><br><b>compile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Compile</i> the source code into executable binaries and libraries.<br><br><b>test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Run</i> any available unit or integration tests defined for the package.<br><br><b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install</i> compiled files into a temporary, isolated installation directory, typically in <i>PKGDIR</i>.<br><br><b>qmerge</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Merge</i> the contents of the temporary installation directory into the live root filesystem.<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Remove</i> temporary build directories and files after a successful build or installation, or to clear previous attempts.<br><br>


title: DESCRIPTION
content:
<i>ebuild</i> is a fundamental command in the Gentoo Linux distribution, acting as the low-level interface to the Portage package management system. An ebuild itself is a shell script that describes how to fetch, unpack, patch, compile, test, and install a specific software package. It encapsulates all the necessary instructions and metadata for building a package from source code, including its dependencies, configuration options, and installation paths. While users typically interact with <i>emerge</i> to manage packages, <i>ebuild</i> is the underlying tool that <i>emerge</i> calls to perform the actual build operations for individual packages. It provides fine-grained control over the package build process, allowing developers and advanced users to troubleshoot, customize, or create new package definitions.


title: CAVEATS
content:
<i>ebuild</i> is specific to the Gentoo Linux distribution and its Portage package manager; it is not available on other Linux distributions.<br>Direct invocation of <i>ebuild</i> is generally discouraged for regular package management; <i>emerge</i> is the preferred user-facing command that orchestrates <i>ebuild</i> calls.<br>Writing or modifying ebuilds requires a solid understanding of shell scripting, various build systems (e.g., autotools, cmake), and adherence to the Portage development guidelines.


title: EBUILD PHASES EXPLAINED
content:
Each command-line argument after the ebuild path typically corresponds to a specific "phase" in the package build lifecycle. These phases are executed sequentially if multiple are provided on the command line. If no phase is specified, <i>ebuild</i> will execute a default sequence, usually culminating in the <i>install</i> and <i>qmerge</i> phases. The standard order of execution for a full build is <i>fetch</i> &gt; <i>unpack</i> &gt; <i>prepare</i> &gt; <i>configure</i> &gt; <i>compile</i> &gt; <i>test</i> &gt; <i>install</i> &gt; <i>qmerge</i>. Developers can override or customize the behavior of each phase within the ebuild script itself to accommodate specific package requirements.


title: HISTORY
content:
The <i>ebuild</i> command emerged as a core component of Gentoo Linux's unique source-based package management philosophy. Conceived by Daniel Robbins, Gentoo's founder, in the early 2000s, it provided a flexible and powerful way to build software directly from source code, enabling system optimization and customization. Unlike binary package managers, <i>ebuild</i> scripts define the entire build process, offering unparalleled control and transparency, which became a hallmark of the Gentoo experience. Its development has been intertwined with the evolution of the Portage system, continually adapting to new software build practices and compiler optimizations while maintaining its foundational role.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Expand all specified octal values to their ASCII character equivalent.</i><br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Process backslash escape sequences explicitly.</i><br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable interpretation of backslash escapes (similar to modern `echo -e`).</i><br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress the trailing newline character from the output.</i><br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print the processed strings to standard output.</i><br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Process strings in raw mode, disabling certain interpretations.</i><br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Strip multiple blank characters into a single space.</i><br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Expand tab characters encountered in the string.</i><br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Expand vertical tab characters.</i><br><br>


title: DESCRIPTION
content:
The <b>ec</b> command, primarily found on older Unix-like systems such as SCO OpenServer and XENIX, is designed to process and expand escape character sequences within provided strings. It functions similarly to the <i>-e</i> option of the modern <b>echo</b> command, interpreting sequences like <i>\n</i> for newline, <i>\t</i> for tab, <i>\b</i> for backspace, and <i>\0nnn</i> for octal character representations. Its main purpose was to enable the display of special characters and formatting through the shell, especially in environments where the default <b>echo</b> command did not support such interpretations. This utility was crucial for script portability and text manipulation before the widespread adoption of standardized escape sequence handling in shell built-ins.


title: CAVEATS
content:
The <b>ec</b> command is primarily found on older Unix-like systems (e.g., SCO OpenServer, XENIX) and is generally not available on modern Linux distributions, where its functionality is typically handled by <b>echo -e</b> or <b>printf</b>. Its behavior might vary slightly across different legacy systems.


title: SUPPORTED ESCAPE SEQUENCES
content:
<b>ec</b> supports various escape sequences including <i>\a</i> (alert/bell), <i>\b</i> (backspace), <i>\c</i> (suppress newline), <i>\f</i> (form feed), <i>\n</i> (newline), <i>\r</i> (carriage return), <i>\t</i> (horizontal tab), <i>\v</i> (vertical tab), <i>\\</i> (literal backslash), and <i>\0nnn</i> (character specified by its octal value <i>nnn</i>).


title: HISTORY
content:
The <b>ec</b> command originates from early Unix systems, specifically appearing in distributions like SCO OpenServer and XENIX. It served as a standalone utility for processing escape sequences before the <b>echo</b> command gained its <i>-e</i> option, which standardized the interpretation of such sequences directly within the shell built-in. Its existence highlights an evolutionary step in shell scripting capabilities, moving from dedicated external commands to more integrated shell features.


title: PARAMETERS
content:
<b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output the trailing newline character.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable interpretation of backslash escape sequences. Common sequences include <i>\n</i> for a newline, <i>\t</i> for a horizontal tab, and <i>\c</i> to suppress further output.<br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable interpretation of backslash escape sequences. This is often the default behavior for the <i>/bin/echo</i> utility, but not necessarily for shell built-ins. Use this to ensure backslashes are printed literally.<br><br>


title: DESCRIPTION
content:
The <i>echo</i> command is a fundamental Unix/Linux utility used to display lines of text or the values of variables to standard output. It's commonly employed in shell scripts for debugging, providing user feedback, or outputting data that can be piped or redirected to files. When invoked, <i>echo</i> prints its arguments separated by spaces, typically followed by a newline character. Different versions of <i>echo</i> exist: a shell built-in command (present in most shells like Bash, Zsh, Dash) and an external utility (e.g., <i>/bin/echo</i>). Their behaviors, particularly regarding the interpretation of backslash escape sequences, can vary, which is an important consideration for scripting portability.


title: CAVEATS
content:
<b>Portability Issues:</b> The behavior of <i>echo</i>, especially concerning backslash interpretation (whether <i>-e</i> is implicitly enabled or not), is not consistent across all Unix-like systems and shell versions. This makes <i>echo</i> less portable for complex string manipulations. For robust and portable scripting, the <i>printf</i> command is generally preferred.<br><br><b>Built-in vs. External:</b> Most shells have their own built-in <i>echo</i> command, which takes precedence over the <i>/bin/echo</i> executable. The behavior of the built-in can differ from the external command. To explicitly use the external command, you can specify its full path (e.g., <i>/bin/echo</i>).


title: BACKSLASH ESCAPE SEQUENCES (WITH -E OPTION)
content:
When the <i>-e</i> option is used, <i>echo</i> interprets the following common backslash-escaped characters:<br><b>\a</b>  alert (bell)<br><b>\b</b>  backspace<br><b>\c</b>  produce no further output<br><b>\e</b>  escape<br><b>\f</b>  form feed<br><b>\n</b>  new line<br><b>\r</b>  carriage return<br><b>\t</b>  horizontal tab<br><b>\v</b>  vertical tab<br><b>\\</b>  backslash<br><b>\0NNN</b> byte with octal value NNN (1 to 3 digits)<br><b>\xHH</b>  byte with hexadecimal value HH (1 to 2 digits)


title: HISTORY
content:
The <i>echo</i> command has been a fundamental component of Unix since its earliest versions, making it one of the oldest and most widely used utilities. Its simplicity in printing text made it instantly valuable. However, the lack of a standardized behavior for backslash escape sequences in early implementations led to significant variations between different Unix systems and later, between different shell built-ins and the standalone <i>/bin/echo</i> utility. This inconsistency eventually prompted efforts by POSIX to standardize some of its behavior, and also led to the introduction and increasing preference for the more predictable and versatile <i>printf</i> command for new scripting.


title: SYNOPSIS
content:
<b>eclean</b> <I>subcommand</I> [<i>options</i>]<br><br><b>eclean</b> <b>distfiles</b> [<b>-adfpqstv</b>] [<b>--all</b>] [<b>--deep</b>] [<b>--destructive</b>] [<b>--force</b>] [<b>--pretend</b>] [<b>--quiet</b>] [<b>--size</b>] [<b>--time</b> <I>time</I>] [<b>--verbose</b>]<br><b>eclean</b> <b>packages</b> [<b>-dfpqstv</b>] [<b>--destructive</b>] [<b>--force</b>] [<b>--pretend</b>] [<b>--quiet</b>] [<b>--size</b>] [<b>--time</b> <I>time</I>] [<b>--verbose</b>]


title: PARAMETERS
content:
<b><b>distfiles</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The subcommand to clean up source archives (<I>distfiles</I>) located in <I>$PORTAGE_DISTDIR</I> (usually <I>/var/cache/distfiles</I>).<br><br><b><b>packages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The subcommand to clean up temporary build directories and binary packages located in <I>$PORTAGE_TMPDIR</I> (usually <I>/var/tmp/portage</I>).<br><br><b><b>-d</b>, <b>--destructive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the actual removal of files. By default, <i>eclean</i> runs in dry-run mode.<br><br><b><b>-p</b>, <b>--pretend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry-run; show what would be removed without actually deleting files. This is the default behavior.<br><br><b><b>-s</b>, <b>--size</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the total size of files that would be removed or have been removed.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not prompt for confirmation before removal.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about files being processed.<br><br><b><b>-t</b> <I>time</I>, <b>--time</b> <I>time</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove files older than the specified time. Examples: <I>30d</I> (30 days), <I>1w</I> (1 week), <I>2m</I> (2 months).<br><br><b><b>-a</b>, <b>--all</b> (<i>distfiles only</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all distfiles, even those still referenced by <I>Portage</I>. <b>Use with extreme caution, as this can break future installations or updates.</b><br><br><b><b>-D</b>, <b>--deep</b> (<i>distfiles only</i>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove distfiles not referenced by any currently <I>installed</I> packages. This is a common and safer way to deep clean distfiles.<br><br>


title: DESCRIPTION
content:
<i>eclean</i> is a command-line utility integral to the <I>Gentoo Linux Portage</I> package management system. Its primary function is to reclaim disk space by removing unneeded files accumulated during system operation and package management.<br><br>It operates on two main categories:<br><b><I>distfiles</I></b>: These are the source archives downloaded by Portage to build packages. Over time, multiple versions of source files can accumulate, consuming significant disk space. <i>eclean distfiles</i> helps manage this by removing older or unreferenced source files, retaining only those required by currently installed packages or specified configurations.<br><b><I>packages</I></b>: These refer to temporary build directories and potentially binary packages created by Portage, typically found under <I>/var/tmp/portage/</I>. While Portage often cleans these up after successful installation, <i>eclean packages</i> ensures that any lingering build artifacts from previous builds, failed installations, or manual interventions are properly cleared.<br><br><i>eclean</i> is a critical tool for maintaining disk hygiene and efficiency on Gentoo systems, especially given Portage's source-based nature, which can generate substantial temporary and archived data.


title: CAVEATS
content:
<b>1. Dry-run by default:</b> <i>eclean</i> runs in pretend mode by default. Always double-check its output using <I>-p</I> before running with <I>-d</I> (<I>--destructive</I>) to avoid accidental data loss.<br><b>2. <I>--all</I> option:</b> The <I>--all</I> option for <I>eclean distfiles</I> is highly dangerous. It removes all source archives, even those currently required, potentially breaking future package installations or updates if <I>Portage</I> cannot re-download them.<br><b>3. Gentoo-specific:</b> <i>eclean</i> is a utility specific to <I>Gentoo Linux</I> and its <I>Portage</I> package manager. It will not function on other Linux distributions.<br><b>4. Scope:</b> <i>eclean</i> only manages files within <I>Portage</I>-specific directories (<I>distfiles</I> cache, build temporary spaces). It does not clean user home directories, system logs, or other general system clutter.


title: HISTORY
content:
<i>eclean</i> is an integral part of the <I>Portage</I> package management system, which was developed concurrently with <I>Gentoo Linux</I> itself. Its evolution is directly tied to the needs of a source-based distribution, where large quantities of source archives (<I>distfiles</I>) and temporary build artifacts accumulate rapidly. Introduced to provide a straightforward method for disk space management, <i>eclean</i> has been a standard and essential utility for <I>Gentoo</I> users for many years, reflecting the ongoing commitment to system hygiene within the distribution's design philosophy.


title: SYNOPSIS
content:
<b>openssl ecparam</b> [<I>options</I>]<br>Common usage:<br><b>openssl ecparam -name</b> <I>curve</I> [<b>-out</b> <I>file</I>] [<b>-noout</b>] [<b>-text</b>]<br><b>openssl ecparam -in</b> <I>file</I> [<b>-check</b>] [<b>-text</b>] [<b>-noout</b>]


title: PARAMETERS
content:
<b><b>-in</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file from which to read EC parameters. Default is standard input.<br><br><b><b>-out</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file to which to write EC parameters. Default is standard output.<br><br><b><b>-text</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the EC parameters in a human-readable, textual format.<br><br><b><b>-noout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the output of the encoded EC parameters, useful when only checking or printing text output.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the EC parameters in C source code format.<br><br><b><b>-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the validity of the EC parameters read from the input.<br><br><b><b>-name</b> <I>curve</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates EC parameters for a specified standard named curve (e.g., <i>prime256v1</i>, <i>secp384r1</i>). This is the recommended way to get parameters.<br><br><b><b>-list_curves</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all the named elliptic curves supported by the OpenSSL library.<br><br><b><b>-param_enc</b> <I>explicit</I>|<I>named_curve</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls how the EC parameters are encoded. '<i>explicit</i>' includes all curve details; '<i>named_curve</i>' uses an OID reference.<br><br><b><b>-inform</b> <I>DER</I>|<I>PEM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input format for the EC parameters (DER or PEM).<br><br><b><b>-outform</b> <I>DER</I>|<I>PEM</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format for the EC parameters (DER or PEM).<br><br>


title: DESCRIPTION
content:
The <b>ecparam</b> command is a crucial utility within the OpenSSL toolkit, primarily used for managing Elliptic Curve (EC) parameters. It enables users to generate new EC parameters, which define the specific elliptic curve used in EC cryptography. Beyond generation, <b>ecparam</b> can also print the details of existing EC parameters, convert them between different formats (e.g., PEM, DER), and perform checks for their validity. This command is fundamental for cryptographic operations involving EC algorithms, such as ECDSA (Elliptic Curve Digital Signature Algorithm) and ECDH (Elliptic Curve Diffie-Hellman), where the underlying curve parameters are essential for secure key generation and agreement. It supports various named curves, including standard NIST curves, and allows for both prime field and binary field curves.


title: CAVEATS
content:
Incorrectly generated or insecure EC parameters can lead to vulnerabilities in cryptographic systems. Always prefer using well-known, standardized named curves. The <b>ecparam</b> command manages <i>parameters</i>, not private or public <i>keys</i>; use <b>openssl ec</b> for key operations.


title: IMPORTANCE OF NAMED CURVES
content:
When generating EC parameters, it is highly recommended to use well-established and standardized named curves (e.g., <i>prime256v1</i>, <i>secp384r1</i>, <i>secp521r1</i>). These curves have undergone rigorous scrutiny and are widely accepted for their security properties. Generating arbitrary or custom EC parameters can lead to insecure cryptographic operations unless done by experts with deep cryptographic knowledge.


title: ECPARAM VS. EC
content:
It's important to distinguish between <b>ecparam</b> and <b>ec</b>. The <b>ecparam</b> command is solely for handling Elliptic Curve <b>parameters</b>, which define the mathematical properties of the curve. In contrast, the <b>ec</b> command is used for managing Elliptic Curve <b>keys</b> (private and public keys), which are derived from these parameters.


title: HISTORY
content:
OpenSSL has supported Elliptic Curve Cryptography (ECC) for a significant period. The <b>ecparam</b> command emerged as part of this support, providing a dedicated utility for managing the curve parameters themselves, separate from key generation. Its development tracks the evolution of ECC standards and the integration of various named curves (like NIST P-256, P-384, P-521) into OpenSSL. It has been a stable part of the OpenSSL command-line interface, crucial for anyone deploying or testing ECC-based security solutions.


title: PARAMETERS
content:
<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>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose debugging information, useful for troubleshooting.<br><br><b><b>-f</b> <I>FILENAME</I>, <b>--file</b>=<I>FILENAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the passphrase from the first line of the specified <I>FILENAME</I> instead of prompting the user interactively. <br><b>Caution:</b> Storing passphrases in plain files is generally not recommended for security reasons.<br><br><b><b>-s</b>, <b>--system-wide</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds the passphrase to the system-wide keyring instead of the user-specific session keyring. This makes the passphrase available to all users and processes on the system, which can be useful in specific server configurations, but also poses a higher security risk.<br><br>


title: DESCRIPTION
content:
The <b>ecryptfs-add-passphrase</b> command is a utility designed to add a user-provided passphrase to the eCryptfs keyring within the Linux kernel. This passphrase is crucial for eCryptfs to decrypt and encrypt files on an eCryptfs mounted filesystem. When a user mounts an eCryptfs directory, the kernel needs to have the correct decryption key (derived from the passphrase) in its keyring to access the encrypted data. This command prompts the user interactively for a passphrase or can read it from a specified file. It's commonly used in conjunction with commands like <i>ecryptfs-mount-private</i> or the standard <i>mount</i> command when dealing with eCryptfs encrypted directories, ensuring that the necessary decryption key is available in the kernel's keyring before a mount operation can succeed.


title: CAVEATS
content:
The command adds the passphrase to the kernel's keyring; it does not directly perform any mount or decryption operations. <br>If an incorrect passphrase is added, it will still be stored in the keyring but will not allow decryption of the eCryptfs filesystem. <br>The passphrase must be present in the keyring <I>before</I> attempting to mount an eCryptfs filesystem that requires it. <br>Using the <b>--file</b> option can be a security risk as it involves storing the passphrase in plain text on disk.


title: KEYRING MANAGEMENT
content:
eCryptfs relies on the Linux kernel's keyring service to manage cryptographic keys. When a passphrase is added, it's converted into a key and stored in a keyring associated with the current user's session or, if specified, the system-wide keyring. This allows the kernel to access the necessary decryption keys without constantly prompting the user.


title: USAGE CONTEXT
content:
While <i>ecryptfs-add-passphrase</i> can be run independently, it's often implicitly called or its function performed by higher-level scripts like <i>ecryptfs-mount-private</i> when setting up or accessing encrypted home directories, simplifying the user experience by handling key management automatically.


title: HISTORY
content:
The <i>ecryptfs-add-passphrase</i> command is part of the eCryptfs utilities, which have been a core component of Linux's stacked cryptographic filesystem since its initial development in the mid-2000s, primarily driven by developers at IBM and later Canonical. It's designed to manage the critical passphrases that enable eCryptfs to function, evolving alongside the filesystem to provide robust data encryption capabilities for home directories and other sensitive data.


title: SEE ALSO
content:
ecryptfs(7), ecryptfs-mount-private(1), ecryptfs-insert-wrapped-passphrase-into-keyring(1), mount(8)


title: PARAMETERS
content:
<b><i>start_directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory from which to start the search. This should typically be an eCryptfs mount point.<br><br><b><b>-name</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for files by their decrypted (plaintext) name, using shell pattern matching.<br><br><b><b>-iname</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <b>-name</b>, but the matching is case-insensitive.<br><br><b><b>-cryptname</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for files by their raw encrypted name, using shell pattern matching.<br><br><b><b>-icryptname</b> <i><pattern></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <b>-cryptname</b>, but the matching is case-insensitive.<br><br><b><b>-type</b> <i><type></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter results by file type (e.g., 'f' for file, 'd' for directory, 'l' for symbolic link).<br><br><b><b>-mount</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only search filesystems that are mounted with eCryptfs. This prevents searching into non-eCryptfs filesystems.<br><br><b><b>-print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the full path of the found files (this would likely be the default action).<br><br><b><b>-exec</b> <i><command> {} \;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a specified command on each found file. The '{}' is replaced by the current file's path.<br><br><b><b>-max-depth</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Descend at most <i>N</i> levels into the directory tree. A value of 1 means only the starting directory and its immediate contents.<br><br><b><b>-min-depth</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not apply any tests or actions at levels less than <i>N</i> (level 0 is the starting directory).<br><br><b><b>-decrypted-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the decrypted (plaintext) path for each found item (useful when searching by encrypted name).<br><br><b><b>-encrypted-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the raw encrypted path for each found item (useful when searching by decrypted name).<br><br>


