# CommandSection

title: ESCAPING ALIASES
content:
If you need to execute the original command that an alias shadows, you can escape the alias. Common methods include:<br><I>\command</I> (e.g., <I>\ls</I>)<br><I>'command'</I> (e.g., <I>'ls'</I>)<br><I>"command"</I> (e.g., <I>"ls"</I>)<br><I>/bin/command</I> (using the full path, e.g., <I>/bin/ls</I>)


title: ALIAS EXPANSION RULES
content:
When a command is entered, the shell performs alias expansion as one of its first steps. Key rules include:<br>1. Only the first word of a command is checked for an alias.<br>2. If an alias's <I>value</I> ends with a space or tab, the next word on the command line is also checked for alias expansion.<br>3. Aliases are not recursive; an alias definition cannot refer to itself.


title: HISTORY
content:
The concept of aliases originated in earlier Unix shells like <I>csh</I> (C shell) and <I>ksh</I> (Korn shell) before being adopted by modern shells such as <I>bash</I> and <I>zsh</I>. They have been a fundamental feature for shell customization and convenience for decades, allowing users to streamline command-line interaction and improve efficiency by creating personalized shortcuts. The core functionality and usage have remained remarkably consistent across different shell implementations.


title: PARAMETERS
content:
<b>-d, --to-deb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to Debian <I>.deb</I> format (default).<br><br><b>-r, --to-rpm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to Red Hat <I>.rpm</I> format.<br><br><b>-l, --to-lsb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to LSB compliant <I>.deb</I> format.<br><br><b>-t, --to-tgz</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to Slackware <I>.tgz</I> format.<br><br><b>-p, --to-pkg</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert to Solaris <I>.pkg</I> format.<br><br><b>-i, --install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install the generated package after conversion.<br><br><b>-k, --keep-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not change the package version during conversion.<br><br><b>-c, --scripts</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include package maintainer scripts in the converted package.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display verbose output during the conversion process.<br><br><b>--fixdeps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to fix package dependencies after conversion.<br><br><b>--target=<arch></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a specific architecture for the converted package.<br><br><b>--test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the created package (often by installing and removing).<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<B>alien</B> is a utility that converts between different Linux package formats.<BR><BR>It supports conversions between Red Hat <I>RPM</I> packages, Debian <I>DEB</I> packages, Slackware <I>TGZ</I> packages, and <I>LSB</I> (Linux Standard Base) packages. It is particularly useful when you need to install software that is only available in a package format not native to your distribution (e.g., installing a <I>.deb</I> on a Fedora system, or an <I>.rpm</I> on an Ubuntu system).<BR><BR>While <B>alien</B> attempts to create usable packages, it's not foolproof. Converted packages might sometimes lack proper dependencies, pre/post-installation scripts, or other metadata, potentially leading to issues. It's generally recommended to use native packages or build from source if possible.


title: CAVEATS
content:
Converted packages might not always be fully functional or stable. Dependencies are often not handled correctly and may require manual resolution. Pre/post-installation scripts might not translate perfectly, leading to unexpected behavior. Using <B>alien</B> should be a last resort when a native package or source code isn't available. It's always recommended to back up your system before installing packages converted by <B>alien</B>.


title: SECURITY CONSIDERATIONS
content:
Running <B>alien</B> often requires root privileges (or <I>sudo</I>), especially when using the <I>-i</I> option. Be cautious when converting packages from untrusted sources, as malicious scripts could be embedded and executed during installation.


title: TEMPORARY FILES
content:
<B>alien</B> creates temporary directories and files during conversion. These are usually cleaned up automatically, but in case of errors, they might remain in locations like <I>/tmp</I> or the current working directory.


title: HISTORY
content:
<B>alien</B> was created by Joey Hess. It has been a staple tool for users needing cross-distribution package conversion for many years, reflecting the ongoing need for interoperability in the Linux ecosystem despite varying package formats.


title: PARAMETERS
content:
<b><b>-f</b> <I>folder</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <I>folder</I> to open upon startup. For example, <B>-f inbox</B>.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force Alpine into interactive mode, even if input is not from a terminal.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable keyboard shortcuts (K-mode), often for users accustomed to older systems.<br><br><b><b>-p</b> <I>printer</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <I>printer</I> to use for printing messages.<br><br><b><b>-r</b> <I>remote-host</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a <I>remote-host</I> for IMAP or NNTP operations if not configured globally.<br><br><b><b>-s</b> <I>subject</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a <I>subject</I> for a new message being composed.<br><br><b><b>-t</b> <I>address</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a recipient <I>address</I> when starting Alpine to compose a new message.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of Alpine and exit.<br><br><b><I>address</I> ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If addresses are provided without options, Alpine will start composing a new message to these recipients.<br><br>


title: DESCRIPTION
content:
Alpine is a free, open-source, text-based email and news client developed at the University of Washington. It is the spiritual successor and largely compatible replacement for the widely popular <I>Pine</I> email client. Designed to be easy to use and efficient within a terminal environment, Alpine offers comprehensive features for managing email, including support for IMAP, POP, and SMTP protocols. Users can compose, send, receive, and organize messages, manage address books, and handle attachments. Its intuitive, menu-driven interface, often leveraging keyboard shortcuts, makes it a favored choice for command-line users, system administrators, and those accessing email remotely via SSH. Alpine also integrates the simple <I>Pico</I> text editor for message composition, contributing to its streamlined workflow. While its text-only interface might be unfamiliar to users accustomed to graphical clients, its speed, stability, and robust feature set make it a powerful tool for email management in Unix-like operating systems.


title: CAVEATS
content:
Alpine's text-based user interface might be <I>unfamiliar</I> to users accustomed to modern graphical email clients. While powerful, its configuration can be <I>intricate</I> for advanced features or integrating with specific mail servers. Active development has <I>slowed</I> considerably compared to its peak popularity.


title: INTEGRATED PICO EDITOR
content:
Alpine often uses the <I>Pico</I> text editor for composing messages, known for its simplicity and ease of use. <BR>This editor is also available as a standalone command (<B>pico(1)</B>).


title: TERMINAL INTERFACE
content:
Designed for efficiency in a text-only terminal environment, Alpine is ideal for remote SSH access where graphical interfaces are not available or desirable. Its navigation is primarily keyboard-driven.


title: HISTORY
content:
The Alpine email client originated as a free and open-source successor to <I>Pine</I> (Program for Internet News and Email), which was developed at the University of Washington starting in 1989. <I>Pine</I> became immensely popular, especially in Unix and academic environments. However, licensing disputes and the desire for a fully open-source email client led to the development of <I>Alpine</I>. Released under the Apache License 2.0, Alpine aimed to provide a compatible and familiar experience while being entirely free software. It largely retains the user interface, keybindings, and feature set that made <I>Pine</I> widely used.


title: PARAMETERS
content:
<b><B>store</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current mixer settings for all soundcards or a specified card to the configuration file (default <I>/var/lib/alsa/asound.state</I>).<br><br><b><B>restore</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores the mixer settings from the configuration file for all soundcards or a specified card.<br><br><b><B>init</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes the mixer settings for all soundcards or a specified card to a default good state.<br><br><b><B>nrestore</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Non-blocking restore. Restores settings without waiting for the restore to complete (often used during boot).<br><br><b><B>restore_init</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores settings from the configuration file if available, otherwise initializes to a default good state.<br><br><b><B>monitor</B> [<I>card</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors mixer changes and prints them to standard output.<br><br><b><B>-f</B> <I><file></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file to use instead of the default.<br><br><b><B>-F</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force restore. Ignores state file differences or problems during restore.<br><br><b><B>-d</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode for verbose output during execution.<br><br><b><B>-L</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a lock file to prevent multiple instances from running concurrently, ensuring data integrity.<br><br><b><B>-P</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Program mode. Used for script compatibility, affects output format.<br><br><b><B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose output. Provides more detailed information about the command's actions.<br><br><b><B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<I>alsactl</I> is a utility program used to control and manage the Advanced Linux Sound Architecture (ALSA) mixer settings. Its primary functions involve saving the current sound card mixer state (volume levels, mute status, input/output selections) and restoring these settings, typically upon system startup. This ensures that audio configurations persist across reboots, preventing the user from having to manually adjust levels every time.<br><br>It can also initialize sound cards to a known good state or monitor changes. It's often used by system startup scripts (e.g., via <I>alsa-utils</I> package and systemd services like <I>alsa-restore.service</I>) to automatically manage sound settings. Without <I>alsactl</I>, sound levels might reset to defaults or undesirable states after a reboot, leading to a frustrating user experience.


title: CAVEATS
content:
<ul><li><B>Permissions:</B> <I>alsactl</I> often requires root privileges or membership in the <I>audio</I> group to save or restore mixer settings.<br></li><li><B>Configuration File Location:</B> The default configuration file <I>/var/lib/alsa/asound.state</I> is crucial. If it's corrupted or deleted, settings may be lost or reset to defaults.<br></li><li><B>Hardware Variations:</B> Restoring settings across different sound card models can lead to unexpected behavior due to variations in mixer controls.<br></li><li><B>Systemd Integration:</B> On modern Linux systems, <I>alsactl</I> functionality is usually managed by systemd services like <I>alsa-restore.service</I> and <I>alsa-state.service</I>. Manual intervention with <I>alsactl</I> might conflict with these services.<br></li><li><B>PulseAudio/PipeWire:</B> When high-level sound servers like PulseAudio or PipeWire are in use, they might manage sound levels independently, potentially overriding or conflicting with direct ALSA hardware mixer settings controlled by <I>alsactl</I>.</li></ul>


title: STARTUP AND SHUTDOWN INTEGRATION
content:
<I>alsactl</I> is typically integrated into the system's startup and shutdown processes to ensure persistence of audio settings.<br><br>On systems using systemd, the <B>alsa-restore.service</B> unit is responsible for calling <B>alsactl restore</B> during boot, while a mechanism (often part of <B>alsa-state.service</B> or a similar shutdown script) triggers <B>alsactl store</B> during system shutdown. This automation ensures that user-defined audio settings, such as volume levels and input/output selections, are preserved across reboots, eliminating the need for manual configuration each time the system starts.


title: HISTORY
content:
<I>alsactl</I> is a core component of the <I>alsa-utils</I> package, developed as part of the Advanced Linux Sound Architecture (ALSA). ALSA emerged in the early 2000s as the successor to the Open Sound System (OSS) for audio in Linux. The command was introduced to address the common problem of sound card mixer settings not persisting across reboots, a significant user frustration. Its development has been closely linked to the evolution of ALSA, providing robust and reliable control over audio hardware on Linux systems.


title: PARAMETERS
content:
<b>-P <playback_device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ALSA PCM device for playback. Example: <i>hw:0,0</i>.<br><br><b>-C <capture_device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ALSA PCM device for capture. Example: <i>hw:1,0</i>.<br><br><b>-r <rate></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sample rate in Hz. Example: <i>44100</i>.<br><br><b>-f <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sample format. Examples: <i>S16_LE</i>, <i>S32_LE</i>.<br><br><b>-c <channels></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of channels. Example: <i>2</i>.<br><br><b>-B <msec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the buffer size in milliseconds.<br><br><b>-Z <msec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the period size in milliseconds.<br><br><b>-t <msec></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the loop time in milliseconds. Loop terminates after this time.<br><br><b>-S <mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the synchronization mode. Values: <i>async</i>, <i>sync</i>.<br><br><b>-L <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the log level. (0=silent, 1=errors, 2=warnings, 3=infos, 4=debug).<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Daemonizes the process (runs in the background).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br>


title: DESCRIPTION
content:
alsaloop is a command-line utility from the <b>alsa-utils</b> package designed to create a real-time audio loop between two ALSA PCM (Pulse Code Modulation) devices. It acts as an intermediary, taking audio data from one ALSA device (either playback or capture) and sending it to another ALSA device (the opposite type, or even the same type if the driver supports it). This allows for flexible audio routing, enabling scenarios such as redirecting an application's output to another application's input, creating virtual soundcards for testing, or simply monitoring audio paths.<br><br>alsaloop can handle various audio parameters including sample rate, format (e.g., S16_LE), and number of channels, performing on-the-fly conversions if necessary. It offers fine-grained control over buffer and period sizes, and provides different synchronization modes to minimize latency and avoid xruns (underruns/overruns). While ALSA offers a kernel module (snd-aloop) for direct loopback, alsaloop provides more control over parameters and can be used when the kernel module isn't an option or when specific conversion or routing needs to be applied between different physical or virtual devices.


title: CAVEATS
content:
<ul><li><b>Resource Usage:</b> alsaloop can consume significant CPU resources, especially when performing real-time sample rate, format, or channel conversions.</li><li><b>Latency:</b> Depending on buffer sizes and system load, alsaloop can introduce noticeable audio latency. Careful tuning of <i>-B</i> and <i>-Z</i> parameters is often required.</li><li><b>Synchronization:</b> Achieving perfect synchronization between devices can be challenging, particularly with different clock sources. Xruns (underruns/overruns) may occur if parameters are not optimized.</li><li><b>Permissions:</b> Accessing ALSA devices might require appropriate user permissions or running alsaloop with root privileges, though this is generally discouraged.</li></ul>


title: COMMON USE CASES
content:
<ul><li>Routing audio from one application (e.g., a web browser playing a video) to another application (e.g., a recording software).</li><li>Creating a "virtual microphone" from a system's playback output.</li><li>Testing ALSA drivers and device configurations by looping audio back to a capture device on the same sound card.</li><li>Bridging between different physical sound cards or configurations.</li></ul>


title: DEVICE NAMING
content:
ALSA device names can be complex. Common examples include <b>hw:0,0</b> (first sound card, first digital audio interface), <b>default</b>, or <b>plug:dmix</b>.


title: HISTORY
content:
alsaloop is an integral part of the <b>alsa-utils</b> package, which provides various command-line tools for managing and interacting with the Advanced Linux Sound Architecture (ALSA). ALSA itself has been the standard low-level audio framework for Linux systems since the early 2000s, replacing the older OSS (Open Sound System). alsaloop has evolved alongside ALSA, providing a flexible software-based audio looping mechanism that complements the kernel's <b>snd-aloop</b> module. Its development has focused on robust real-time performance and versatile audio parameter handling to meet diverse audio routing and testing needs on Linux.


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>-c</b> <i>card</i>, <b>--card=</b><i>card</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the sound card to control. <i>card</i> can be an index number (e.g., 0, 1) or a string identifier (e.g., 'default', 'HDA Intel PCH').<br><br><b><b>-D</b> <i>device</i>, <b>--device=</b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the mixer device to control. Useful if multiple mixer interfaces exist on a single card.<br><br><b><b>-V</b> <i>view</i>, <b>--view=</b><i>view</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial view mode for controls. Valid options are 'playback', 'capture', or 'all'.<br><br><b><b>-g</b>, <b>--no-color</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables color output, using monochrome text for the interface.<br><br><b><b>-s</b>, <b>--no-sound-card</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts alsamixer without loading any sound card settings. Useful for debugging.<br><br><b><b>-M</b>, <b>--set-soft-master</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to create a 'soft master' control if the hardware does not provide a dedicated master volume. This can provide a unified volume control across multiple channels.<br><br>


title: DESCRIPTION
content:
<br>The <b>alsamixer</b> command provides a <i>curses-based</i> (text user interface) mixer program for the <b>ALSA</b> (Advanced Linux Sound Architecture) sound system. It allows users to interactively control various audio settings of their sound card(s) directly from the terminal.<br><br>Users can adjust playback and capture volumes for different channels (e.g., <i>Master</i>, <i>Headphone</i>, <i>Speaker</i>, <i>Mic</i>), mute/unmute specific outputs, and manage other hardware-specific controls like input sources or digital/analog switches. Its primary utility lies in environments without a graphical interface, such as servers, embedded systems, or for users who prefer a lightweight, keyboard-driven interface for audio management.<br><br>The interface typically displays a series of sliders for each control, allowing for easy navigation and adjustments using arrow keys. It also supports switching between different sound cards and views (playback, capture, or all controls).


title: CAVEATS
content:
<b>alsamixer</b> directly interacts with the <i>ALSA</i> sound drivers. It does not manage higher-level sound servers like <i>PulseAudio</i> or <i>PipeWire</i> directly, though changes made via <b>alsamixer</b> to the underlying ALSA hardware often affect these systems.<br><br>Changes made with <b>alsamixer</b> are usually not persistent across reboots by default. To save changes, you typically need to use <b>alsactl store</b> (or a similar system service/script) after making your adjustments.


title: KEYBOARD CONTROLS
content:
Once <b>alsamixer</b> is running, the following keyboard shortcuts are commonly used:<br><b>Left/Right Arrow</b>: Navigate between mixer channels/controls.<br><b>Up/Down Arrow</b>: Adjust the volume level for the selected control.<br><b>M</b>: Mute/unmute the selected channel.<br><b>Spacebar</b>: Switch between playback and capture views (depending on context).<br><b>Tab</b>: Switch between different views (e.g., 'Playback', 'Capture', 'All').<br><b>F1</b>: Help (often shows keyboard shortcuts).<br><b>F2</b>: System information (often shows card/chip info).<br><b>F3</b>: Switch to Playback view.<br><b>F4</b>: Switch to Capture view.<br><b>F5</b>: Switch to All controls view.<br><b>Esc</b> or <b>Ctrl+C</b>: Exit the program.<br><b>Numeric keys (0-9)</b>: (When multiple sound cards are present) Select a specific sound card by its index.


title: SAVING SETTINGS
content:
To make <b>alsamixer</b> changes persistent across reboots, you need to save the ALSA state. This is typically done using the <b>alsactl</b> utility:<br>Type <i>sudo alsactl store</i><br>This command saves the current ALSA mixer settings to a configuration file (often <i>/var/lib/alsa/asound.state</i> or <i>/etc/asound.state</i>), which is then loaded automatically by a system service or script during system startup.


title: HISTORY
content:
<b>alsamixer</b> is an integral part of the <i>ALSA</i> (Advanced Linux Sound Architecture) project, which replaced the older <i>OSS</i> (Open Sound System) as the standard sound framework in Linux. Developed to provide robust and flexible audio support, <b>alsamixer</b> has been a consistent and essential tool for managing sound hardware at a low level in Linux environments for many years. Its development is tied to the evolution of the ALSA kernel modules and user-space utilities, ensuring compatibility and control over a wide range of sound cards.


title: DESCRIPTION
content:
The term '<B>alt</B>' is not a standalone command in standard Linux distributions such as Debian, Ubuntu, Fedora, or Red Hat. It does not refer to a common executable or a built-in shell command. It is highly probable that the query refers to <B>ALT Linux</B>, a family of Russian-developed Linux distributions. ALT Linux utilizes the <I>APT</I> (Advanced Package Tool) package manager, similar to Debian/Ubuntu, but is built upon the <I>RPM</I> package format. Therefore, commands frequently used within the ALT Linux environment would be standard Linux utilities (e.g., <B>ls</B>, <B>cd</B>, <B>grep</B>) alongside package management tools like <B>apt-get</B>, <B>apt-cache</B>, or <B>rpm</B> itself. Without specific context, 'alt' as a command is undefined in the broader Linux ecosystem.


title: CAVEATS
content:
The term 'alt' does not correspond to a specific executable command in general Linux environments. If encountered, it might be a user-defined alias, a shell function, or a component of a highly specialized and niche application not widely distributed. Users seeking information on 'alt' commands should clarify the specific context, such as a particular Linux distribution (e.g., ALT Linux) or a unique software suite they are referencing.


title: ALT LINUX DISTRIBUTION
content:
ALT Linux is a set of operating systems based on the Linux kernel. It is notable for its rolling release development model (Sisyphus repository), a comprehensive package base, and its focus on enterprise, government, and educational use cases in Russia. Despite using <I>RPM</I> packages, it integrates the <I>APT</I> (Advanced Package Tool) package manager, providing a familiar package management experience to users accustomed to Debian or Ubuntu.


title: HISTORY
content:
As 'alt' is not a standalone command, it does not possess a distinct development or usage history in the general Linux context. However, <B>ALT Linux</B> (the distribution) has a significant history. It originated in Russia in the early 2000s, developed by ALT Linux Team (now BaseALT LLC). The project aimed to create a robust, secure, and user-friendly Linux distribution, with a strong emphasis on open-source principles, localization for the Russian market, and compliance with national standards. It has developed its own extensive infrastructure, including a unique 'Sisyphus' rolling-release development repository, and provides various desktop and server solutions.


title: SYNOPSIS
content:
<b>alternatives</b> --install <i>&lt;link&gt; &lt;name&gt; &lt;path&gt; &lt;priority&gt;</i> [ --slave <i>&lt;slink&gt; &lt;sname&gt; &lt;spath&gt;</i> ... ]<br><b>alternatives</b> --config <i>&lt;name&gt;</i><br><b>alternatives</b> --display <i>&lt;name&gt;</i><br><b>alternatives</b> --auto <i>&lt;name&gt;</i><br><b>alternatives</b> --set <i>&lt;name&gt; &lt;path&gt;</i><br><b>alternatives</b> --remove <i>&lt;name&gt; &lt;path&gt;</i><br><b>alternatives</b> [ --query <i>&lt;name&gt;</i> | --check | --version | --help ]


title: PARAMETERS
content:
<b><b>--install</b> <i>&lt;link&gt; &lt;name&gt; &lt;path&gt; &lt;priority&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Registers a new alternative into the system. <i>&lt;link&gt;</i> is the generic symbolic link (e.g., <i>/usr/bin/java</i>), <i>&lt;name&gt;</i> is the symbolic name for this group (e.g., <i>java</i>), <i>&lt;path&gt;</i> is the absolute path to the actual file (e.g., <i>/usr/lib/jvm/java-11/bin/java</i>), and <i>&lt;priority&gt;</i> is an integer; higher values indicate a preferred alternative for automatic selection.<br><br><b><b>--slave</b> <i>&lt;slink&gt; &lt;sname&gt; &lt;spath&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--install</b> to register dependent 'slave' links. When the master link is switched, all associated slave links are also updated. <i>&lt;slink&gt;</i> is the slave symbolic link (e.g., <i>/usr/bin/javac</i>), <i>&lt;sname&gt;</i> is its symbolic name (e.g., <i>javac</i>), and <i>&lt;spath&gt;</i> is its actual path (e.g., <i>/usr/lib/jvm/java-11/bin/javac</i>).<br><br><b><b>--config</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows interactive selection of the active alternative for the specified <i>&lt;name&gt;</i> group. It presents a numbered list of available choices for the user to pick from.<br><br><b><b>--display</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows detailed information about the specified alternative group, including the currently selected alternative, its mode (manual/auto), and all registered alternatives with their priorities.<br><br><b><b>--auto</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the specified alternative group to 'automatic' mode. In this mode, <b>alternatives</b> selects the highest priority alternative available.<br><br><b><b>--set</b> <i>&lt;name&gt; &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manually sets the active alternative for <i>&lt;name&gt;</i> to the specified <i>&lt;path&gt;</i>. This action automatically switches the group to 'manual' mode.<br><br><b><b>--remove</b> <i>&lt;name&gt; &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the specific alternative <i>&lt;path&gt;</i> from the <i>&lt;name&gt;</i> group. If <i>&lt;path&gt;</i> is the only alternative in the group, the group and its master link are removed entirely.<br><br><b><b>--query</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about an alternative group in a machine-readable format, useful for scripting. Similar to <b>--display</b> but structured differently.<br><br><b><b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the integrity of the <b>alternatives</b> system by checking the symbolic links and database entries. It can identify and fix some inconsistencies.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the <b>alternatives</b> utility.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of command-line options and usage.<br><br>


title: DESCRIPTION
content:
The <b>alternatives</b> command provides a robust system for managing multiple versions of commands, files, or services on a Linux system. It allows administrators to maintain a single, consistent path (e.g., <i>/usr/bin/java</i>) that can dynamically point to different underlying implementations (e.g., Java 8, Java 11, or OpenJDK).<br><br>This utility helps resolve conflicts when multiple packages provide the same functionality, ensuring that system components and user scripts always use the desired version without hardcoding paths. It achieves this by creating and managing symbolic links in specific directories (like <i>/etc/alternatives</i>) and updating them based on user or system configuration. When a new alternative is installed, it registers itself with the <b>alternatives</b> system, along with a priority value. Users can then switch between available options either interactively or by setting a specific path. This mechanism is crucial for system flexibility, maintainability, and providing a consistent user experience across different software versions.


title: CAVEATS
content:
The <b>alternatives</b> command typically requires root privileges to perform most operations (e.g., <b>--install</b>, <b>--set</b>, <b>--remove</b>). Incorrect usage, such as specifying non-existent paths or removing critical system alternatives, can lead to system instability or broken commands. Users should also be aware of the distinction between the <b>alternatives</b> implementation (primarily found on Red Hat-based systems like RHEL, CentOS, Fedora) and the similar <b>update-alternatives</b> command found on Debian-based systems (like Debian, Ubuntu). While their functionality is very similar, their command names, option syntax, and underlying directory structures (e.g., where configuration files are stored) can differ.


title: IMPLEMENTATION DIFFERENCES: ALTERNATIVES VS. UPDATE-ALTERNATIVES
content:
While functionally similar, the <b>alternatives</b> command (Red Hat, CentOS, Fedora) and <b>update-alternatives</b> (Debian, Ubuntu) are distinct implementations. Key differences include their executable names, typical installation locations of master and slave links (e.g., <i>/etc/alternatives/</i> on RHEL, <i>/etc/alternatives/</i> for master links and <i>/var/lib/dpkg/alternatives/</i> for configuration files on Debian), and minor variations in command-line options. Users should consult the man page specific to their distribution.


title: MASTER AND SLAVE LINKS
content:
The <b>alternatives</b> system operates with a 'master' link and optional 'slave' links. A 'master' link (e.g., <i>/usr/bin/java</i>) is the primary command or file being managed. When this master link points to a specific alternative (e.g., <i>/usr/lib/jvm/java-11/bin/java</i>), any associated 'slave' links (e.g., <i>/usr/bin/javac</i>, <i>/usr/bin/javadoc</i>) are automatically updated to point to their corresponding files within the same alternative installation (e.g., <i>/usr/lib/jvm/java-11/bin/javac</i>, <i>/usr/lib/jvm/java-11/bin/javadoc</i>). This ensures consistency when switching between different versions of a software suite.


title: HISTORY
content:
The concept of an 'alternatives' system originated in Debian Linux with the <b>update-alternatives</b> utility, developed to manage common commands and files provided by multiple packages. This system was designed to allow users and administrators to easily switch between different versions or implementations of a service (e.g., different text editors, mail transfer agents, or Java runtimes) without manually managing complex symbolic links. Red Hat-based distributions subsequently adopted a similar system, implementing their version under the command name <b>alternatives</b>. Both implementations serve the same core purpose: providing a centralized and consistent mechanism for selecting default programs and files across the system, simplifying package management and user configuration.


title: SYNOPSIS
content:
<I>amadmin</I> <I>config</I> <I>subcommand</I> [<I>options</I>...] [<I>arguments</I>...]<br><br>The <I>config</I> argument refers to the name of the Amanda configuration to operate on.


title: PARAMETERS
content:
<b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the overall status of the specified Amanda configuration, including the last run, pending DLEs, and tape status.<br><br><b><b>daily</b> [<I>options</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a full Amanda daily backup run for the specified configuration. This subcommand is typically invoked by cron.<br><br><b><b>find</b> [<I>options</I>...] <I>host</I> [<I>disk</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Locates specific backups in the Amanda index, allowing administrators to find where a particular DLE's backup resides.<br><br><b><b>force</b> [<I>options</I>...] <I>host</I> [<I>disk</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks one or more DLEs to receive a full backup during the next scheduled run, regardless of their normal backup level.<br><br><b><b>unforce</b> [<I>options</I>...] <I>host</I> [<I>disk</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the 'forced full backup' status from specified DLEs.<br><br><b><b>label</b> <I>label</I> [<I>options</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Labels a tape or other backup media for use by Amanda.<br><br><b><b>tape</b> [<I>options</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides various operations related to tape media, such as listing tapes in the changer, or showing the contents of a tape.<br><br><b><b>estimate</b> [<I>options</I>...] <I>host</I> [<I>disk</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs an estimate of the size of the data that would be backed up for the specified DLEs.<br><br><b><b>vault</b> [<I>options</I>...] <I>vault-set</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages vaulting operations, allowing for copying backups from the main storage to a vaulting set for offsite storage.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of the Amanda client and server software.<br><br>


title: DESCRIPTION
content:
The <b>amadmin</b> command is the primary command-line utility for administering an <I>Amanda (Advanced Maryland Automatic Network Disk Archiver)</I> backup system. It allows administrators to interact with Amanda's daily operations, view status, trigger manual actions, and manage backup media (tapes/disks).<br><br>Its functions include checking the status of backup runs, forcing or unforcing backups of specific DLEs (Disk List Entries), finding specific backups in the index, managing tape labels and media, and performing maintenance tasks. It operates on a specific Amanda "configuration," which groups together DLEs, tape devices, and other settings.


title: CAVEATS
content:
Using <b>amadmin</b> requires a correctly installed and configured Amanda backup system. The user executing the command must have appropriate permissions (typically the `amanda` user or root with `sudo`). A solid understanding of Amanda concepts like configurations, DLEs, and storage strategies is crucial for effective and safe use, as incorrect commands can lead to backup failures or difficulties in restoring data.


title: THE CONFIGURATION NAME
content:
Every <b>amadmin</b> command requires a <I>config</I> parameter. This name corresponds to a specific Amanda configuration directory (e.g., `/etc/amanda/<I>config</I>`). This design allows a single Amanda installation to manage multiple independent backup sets, each with its own policies, Disk List Entries (DLEs), and storage targets. Choosing the correct configuration name is paramount for all <b>amadmin</b> operations to ensure commands are applied to the intended backup environment.


title: HISTORY
content:
Amanda was originally developed at the <I>University of Maryland</I> in the late 1980s and early 1990s as a robust, open-source network backup solution for Unix-like systems. <I>amadmin</I> has been a fundamental administrative utility since Amanda's inception, providing the primary command-line interface for managing backup operations, configurations, and media within its client-server architecture. Its continuous development reflects the evolving needs for enterprise-grade backup management.


title: SEE ALSO
content:
<I>amanda</I>(8), <I>amdump</I>(8), <I>amcheck</I>(8), <I>amgetconf</I>(8), <I>amtape</I>(8), <I>amrestore</I>(8)


title: SYNOPSIS
content:
<code>amass &lt;command&gt; [options]</code><br><br>Common commands:<br><br><b>enum</b>: Perform subdomain enumeration and other OSINT gathering.<br><i>Usage</i>: <code>amass enum -d example.com [options]</code><br><br><b>db</b>: Interact with the Amass graph database.<br><i>Usage</i>: <code>amass db -dir /path/to/db [options]</code><br><br><b>track</b>: Track differences in enumeration results over time.<br><i>Usage</i>: <code>amass track -d example.com [options]</code><br><br><b>viz</b>: Generate network graphs from enumeration results.<br><i>Usage</i>: <code>amass viz -d example.com [options]</code>


title: PARAMETERS
content:
<b><code>-d &lt;domain&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Target domain</i> for enumeration (e.g., <code>example.com</code>).<br><br><b><code>-active</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>active enumeration techniques</i> (e.g., brute-forcing, port scanning). Requires more resources and can be detected.<br><br><b><code>-passive</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>passive enumeration techniques</i> (e.g., scraping OSINT sources). Less intrusive and less detectable.<br><br><b><code>-ip</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show <i>IP addresses</i> for discovered subdomains.<br><br><b><code>-o &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output enumeration results to a <i>specified file</i>.<br><br><b><code>-json &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output enumeration results in <i>JSON format</i> to a specified file.<br><br><b><code>-brute</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>brute-force</i> subdomain enumeration using common wordlists or custom ones.<br><br><b><code>-w &lt;wordlist&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a <i>wordlist file</i> for brute-force enumeration.<br><br><b><code>-src</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all <i>data sources</i> utilized by Amass.<br><br><b><code>-dir &lt;directory&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a <i>directory for the Amass database</i> and output files.<br><br><b><code>-config &lt;file&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a <i>configuration file</i> for Amass (e.g., for API keys, resolvers).<br><br><b><code>-v</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>verbose output</i>, showing detailed information during the scan.<br><br><b><code>-r &lt;resolver&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify <i>custom DNS resolvers</i> (e.g., <code>8.8.8.8,1.1.1.1</code>).<br><br><b><code>-p &lt;port&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify <i>ports for active scanning</i> (e.g., <code>80,443,22</code>).<br><br><b><code>-no-recursive</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable <i>recursive subdomain enumeration</i> (i.e., only find immediate subdomains).<br><br><b><code>-timeout &lt;duration&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a <i>maximum time</i> for the enumeration to run (e.g., <code>10m</code>).<br><br>


title: DESCRIPTION
content:
The <b>OWASP Amass</b> project is a sophisticated tool designed for comprehensive network reconnaissance. It specializes in external attack surface mapping, primarily through <i>subdomain enumeration</i> and <i>OSINT (Open-Source Intelligence)</i> gathering. Amass employs a variety of techniques, including passive methods like scraping various public data sources (e.g., DNS records, web archives, search engines, threat intelligence platforms, and numerous third-party APIs) and active methods such as <i>brute-forcing</i>, <i>permutations</i>, <i>DNS querying</i>, and <i>web crawling</i>. Its ability to combine multiple discovery methods makes it exceptionally effective in uncovering a broad range of subdomains, IP addresses, and other related assets linked to a target organization. This information is crucial for security assessments, penetration testing, and understanding an organization's public-facing infrastructure.


title: CAVEATS
content:
<b>API Keys Required</b>: Many of Amass's most effective data sources (e.g., various threat intelligence platforms, search engines) require <i>API keys</i>. Without these, the tool's performance will be significantly limited.<br><b>Resource Intensive</b>: Active enumeration, especially with brute-forcing and extensive recursive searches, can consume significant <i>CPU, memory, and network bandwidth</i>.<br><b>Legal and Ethical Considerations</b>: While passive enumeration is generally safe, active techniques can be considered intrusive. Always ensure you have <i>explicit permission</i> to conduct reconnaissance on target domains.<br><b>False Positives/Negatives</b>: Like any reconnaissance tool, Amass may occasionally produce false positives (non-existent subdomains) or miss some legitimate ones (false negatives), especially with highly protected or obscure targets.


title: <I>ARCHITECTURE & EXTENSIBILITY</I>
content:
Amass is designed with a highly modular and extensible architecture. It leverages a <i>graph database</i> (by default, a local BoltDB instance, but can be configured for others) to store and interlink discovered assets, making it efficient for tracking and visualizing relationships between subdomains, IP addresses, ASNs, and other network entities. Users can extend Amass's capabilities by adding custom data sources or integrating it into larger automation workflows. Its output can be easily parsed (especially JSON output) for further analysis.


title: <I>COMMON USAGE PATTERNS</I>
content:
1. <b>Basic Passive Scan</b>:<br><code>amass enum -passive -d example.com -o output.txt</code><br>(Performs a quick, quiet scan using OSINT sources.)<br><br>2. <b>Comprehensive Active Scan (with brute-force)</b>:<br><code>amass enum -active -brute -d example.com -w /path/to/wordlist.txt -json output.json</code><br>(A more aggressive scan, combining active discovery with a wordlist for brute-forcing, saving results in JSON.)<br><br>3. <b>Specifying Resolvers and Output Directory</b>:<br><code>amass enum -d example.com -r 1.1.1.1,8.8.8.8 -dir /home/user/amass_results</code><br>(Uses specific DNS resolvers and stores all results in a dedicated directory.)


title: HISTORY
content:
The <b>OWASP Amass</b> project was initiated and is continuously maintained by the <i>Open Web Application Security Project (OWASP)</i>, a nonprofit foundation that works to improve the security of software. It was conceived to provide a robust, comprehensive, and scalable solution for external attack surface mapping, addressing the shortcomings of previous, more limited subdomain enumeration tools. Its development has focused on integrating a wide array of passive and active techniques, making it a prominent and indispensable tool in the cybersecurity community for reconnaissance, penetration testing, and vulnerability assessment.


title: SYNOPSIS
content:
<b>amass db</b> <i>&lt;subcommand&gt;</i> [<i>options</i>]<br><br>Examples:<br><i><b>amass db list</b> -d example.com -names</i><br><i><b>amass db show</b> -id 1234567890 -full</i><br><i><b>amass db add</b> -d newdomain.com -src user -tag domain</i><br><i><b>amass db delete</b> -id 1234567890</i>


title: PARAMETERS
content:
<b><b>-dir</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Amass output directory where the database file is located. This option is common to the <b>amass db</b> command and its subcommands. Defaults to <i>~/.config/amass</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>db</b> command or its specific subcommand. This option is common to all Amass commands and subcommands.<br><br><b><b>-add</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> and <i>delete</i> subcommands. Specifies the type of information to add or delete (e.g., 'domain', 'ip', 'asn', 'ptr', 'cname').<br><br><b><b>-f</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> and <i>delete</i> subcommands. Provides a file containing a list of items to add or delete, one per line.<br><br><b><b>-ip</b> <i>&lt;address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> and <i>delete</i> subcommands. Specifies an IP address to add or delete.<br><br><b><b>-nocommunity</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used exclusively with the <i>add</i> subcommand. Disables interaction with the Amass Community API when adding information.<br><br><b><b>-src</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> subcommand. Specifies the source of the information being added (e.g., 'user', 'OSINT', 'DNS').<br><br><b><b>-tag</b> <i>&lt;tag&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i> subcommand. Assigns a tag to the information being added (e.g., 'subdomain', 'A', 'NS').<br><br><b><b>-d</b> <i>&lt;domain&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>add</i>, <i>delete</i>, and <i>list</i> subcommands. Specifies the target domain for the operation.<br><br><b><b>-id</b> <i>&lt;ID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>delete</i> and <i>show</i> subcommands. Specifies the unique ID of an enumeration result to delete or display.<br><br><b><b>-asn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Displays the Autonomous System Numbers (ASNs) collected in the database.<br><br><b><b>-domains</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Lists all unique domains currently stored in the database.<br><br><b><b>-ips</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Shows all unique IP addresses stored in the database.<br><br><b><b>-min</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Filters domains, listing only those with a minimum number of discovered names (subdomains, etc.). Default is 1.<br><br><b><b>-max</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Filters domains, listing only those with a maximum number of discovered names. A value of 0 means no upper limit.<br><br><b><b>-names</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>list</i> subcommand. Displays the discovered names (e.g., subdomains, hostnames) for each domain found in the database.<br><br><b><b>-full</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <i>show</i> subcommand. Displays all collected data for a specific enumeration ID, including detailed relationships and associated entities.<br><br>


title: DESCRIPTION
content:
The <b>amass db</b> (often referred to conceptually as <b>amass-db</b>) command is the primary interface for managing the graph database used by the OWASP Amass project. This database stores all discovered attack surface information, including subdomains, IP addresses, ASNs, DNS records, and their relationships, collected during various enumeration and intelligence gathering operations. It allows users to persist, retrieve, add, and delete this valuable reconnaissance data. By leveraging this command, analysts can ensure the longevity and reusability of their gathered intelligence, facilitating ongoing monitoring and historical analysis of target organizations' infrastructure.


title: CAVEATS
content:
The Amass database can grow very large, consuming significant disk space, especially after extensive or continuous enumerations. Users should regularly manage old or irrelevant data using the <i>delete</i> subcommand. Direct manual tampering with the database file (usually <i>amass.gdb</i>) without using the <b>amass db</b> commands can corrupt the data, leading to loss of information or errors in future Amass operations. It is advisable to make backups before performing major database changes or deletions.


title: SUBCOMMANDS OVERVIEW
content:
The <b>amass db</b> command operates through several dedicated subcommands, each designed for a specific database management task:<br><br><b><i>add</i></b>: Allows users to manually insert new data points (like domains, IPs, or DNS records) into the database, associating them with specified sources and tags.<br><b><i>delete</i></b>: Enables the removal of specific data entries (e.g., domains, IPs) or entire enumeration results from the database using their IDs.<br><b><i>list</i></b>: Provides various options to list and filter the contents of the database, such as domains, IPs, ASNs, or discovered names associated with domains.<br><b><i>show</i></b>: Displays detailed information for a specific enumeration ID, offering a comprehensive view of all collected data and relationships pertinent to that enumeration.


title: DATABASE LOCATION AND STRUCTURE
content:
By default, the Amass database is stored in a file named <i>amass.gdb</i> within the Amass output directory (typically <i>~/.config/amass</i>). It is designed as a graph database, storing entities (like domains, IP addresses, ASNs, hostnames) as nodes and their relationships (e.g., 'A record points to', 'is a subdomain of', 'resolves to') as edges. This graph structure is optimized for querying and analyzing complex connections within the attack surface, making it highly effective for detailed reconnaissance and dependency mapping.


title: HISTORY
content:
The <b>amass-db</b> functionality is an integral part of the OWASP Amass project, which began development around 2017 to provide comprehensive attack surface mapping. The database component evolved alongside the enumeration engine, becoming crucial for persisting and managing the vast amounts of reconnaissance data gathered. Early versions might have used simpler storage mechanisms, but it quickly matured into a robust graph database solution, enabling complex querying and analysis of discovered assets and their interconnections. Its design allows for flexible data models to accommodate the diverse types of information collected by Amass over time.


title: SYNOPSIS
content:
<b>amass</b> <b>enum</b> {<i>-d <domain></i> | <i>-df <file></i>} [<i>-active</i>] [<i>-brute</i>] [<i>-ip</i>] [<i>-v</i>] [<i>-o <file></i>] [<i>-dir <directory></i>] [<i>-config <file></i>] [<i>-timeout <duration></i>] [<i>-src <sources></i>] [<i><additional_options></i>]


title: PARAMETERS
content:
<b><b>-d</b> <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target domain for enumeration. This option can be used multiple times for several domains.<br><br><b><b>-df</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a path to a file containing a list of target domains, one per line.<br><br><b><b>-active</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables active enumeration techniques, which involve direct interactions with the target, such as port scanning, web scraping, and active DNS queries.<br><br><b><b>-passive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs Amass to only use passive reconnaissance techniques, relying on OSINT, DNS records, web archives, and other non-intrusive data sources. This is often the default if active isn't specified.<br><br><b><b>-brute</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates brute-forcing of subdomains using wordlists. Requires a wordlist to be specified or uses default ones.<br><br><b><b>-ip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the IP addresses for discovered subdomains in the output.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the enumeration process and findings.<br><br><b><b>-o</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an output file where the enumeration results will be saved.<br><br><b><b>-dir</b> <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines an output directory where Amass will store its database and other generated files.<br><br><b><b>-config</b> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the path to a custom configuration file for Amass, allowing extensive customization of settings, API keys, and resolvers.<br><br><b><b>-timeout</b> <I>duration</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum duration for the enumeration to run (e.g., '5m' for 5 minutes, '1h' for 1 hour).<br><br><b><b>-src</b> <I>sources</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of specific data sources to use for enumeration (e.g., 'dns,cert,virustotal').<br><br><b><b>-w</b> <I>wordlist</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom wordlist file to be used for subdomain brute-forcing.<br><br><b><b>-norecursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables recursive brute-forcing of subdomains. By default, Amass may brute-force subdomains of discovered subdomains.<br><br>


title: DESCRIPTION
content:
The <b>amass enum</b> command is a powerful subcommand of the OWASP Amass tool, specializing in passive and active subdomain enumeration techniques. Its primary goal is to discover internet-facing assets belonging to an organization. It achieves this by gathering information from a multitude of data sources, including public DNS records, web archives, search engines, threat intelligence platforms, and more. Amass builds a comprehensive map of an organization's attack surface, crucial for security assessments. The tool supports both <i>passive reconnaissance</i>, which minimizes direct interaction with the target, and <i>active reconnaissance</i>, involving techniques like DNS brute-forcing, web scraping, and active DNS queries. Its extensive capabilities make it an invaluable resource for penetration testers, bug bounty hunters, and security professionals engaged in asset discovery, vulnerability assessment, and maintaining an up-to-date inventory of external assets.


title: CAVEATS
content:
Using <b>amass enum</b>, especially with active reconnaissance and brute-forcing, can be resource-intensive and generate significant network traffic.<br>Active enumeration techniques might trigger security alerts on target systems or be perceived as malicious activity. Always ensure you have explicit permission before conducting any active scans on a domain.<br>The effectiveness of <b>amass enum</b> heavily relies on the availability and configuration of API keys for various third-party services, which need to be set up in the configuration file.<br>Results can vary based on network conditions, DNS resolver quality, and the completeness of external data sources.


title: CONFIGURATION FILE AND API KEYS
content:
<b>amass enum</b> leverages a detailed configuration file (typically located at <i>~/.config/amass/config.ini</i>) to customize its behavior. This file is crucial for inputting API keys for various third-party data sources (e.g., VirusTotal, Shodan, AlienVault, Censys) that provide valuable intelligence. Proper configuration and valid API keys significantly enhance the tool's ability to discover a wider range of subdomains and associated information.


title: GRAPH DATABASE INTEGRATION
content:
A powerful feature of Amass is its ability to store discovered attack surface information in a graph database, such as Neo4j. This allows for advanced visualization and analysis of the relationships between domains, subdomains, IP addresses, and other assets, providing a clearer picture of the target's infrastructure than raw text output alone.


title: HISTORY
content:
The Amass project, including the <b>enum</b> subcommand, was initially created by Jeff Foley (caffix) and became an official OWASP project. It was developed to address the need for a comprehensive and automated attack surface mapping tool. Since its inception, <b>amass enum</b> has undergone continuous development, expanding its data sources, enumeration techniques, and integration capabilities. Its focus on combining passive OSINT with active DNS and brute-forcing methods quickly established it as a leading tool for reconnaissance in penetration testing and bug bounty programs. Regular updates and community contributions ensure it remains at the forefront of external asset discovery.


title: SYNOPSIS
content:
<b>amass intel</b> [<i>options</i>] {<i>-d &lt;domain&gt;</i> | <i>-org &lt;organization&gt;</i> | <i>-addr &lt;IP&gt;</i> | <i>-asn &lt;ASN&gt;</i> | <i>-cidr &lt;CIDR&gt;</i>}


title: PARAMETERS
content:
<b><b>-d</b> <i>&lt;domain&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target domain for intelligence gathering. This is one of the primary ways to define the target.<br><br><b><b>-org</b> <i>&lt;organization&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the target organization name. Useful when you know the organization's name but not specific domains.<br><br><b><b>-addr</b> <i>&lt;IP address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide an IP address related to the target to gather intelligence about its associated entities.<br><br><b><b>-asn</b> <i>&lt;ASN&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide an Autonomous System Number (ASN) to gather intelligence about entities within that ASN.<br><br><b><b>-cidr</b> <i>&lt;CIDR&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a CIDR range to gather intelligence about IP addresses and associated entities within that range.<br><br><b><b>-active</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable active information gathering. This might involve more direct interactions and could be noisier.<br><br><b><b>-config</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom configuration file for Amass.<br><br><b><b>-dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a directory for Amass to store its collected data and output.<br><br><b><b>-exclude</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specific data sources from intelligence gathering (e.g., 'Google', 'Censys').<br><br><b><b>-include</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include specific data sources for intelligence gathering, overriding defaults.<br><br><b><b>-ip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include IP addresses in the output of the intelligence gathering process.<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the results in JSON format, suitable for programmatic parsing.<br><br><b><b>-max-dns-queries</b> <i>&lt;number&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of DNS queries per second to control network traffic.<br><br><b><b>-o</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output the results to a specified file.<br><br><b><b>-oA</b> <i>&lt;basename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output results to all available formats (JSON, TXT, etc.) using the provided basename.<br><br><b><b>-r</b> <i>&lt;resolver&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom DNS resolver to use for queries (e.g., '8.8.8.8').<br><br><b><b>-timeout</b> <i>&lt;duration&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum time allowed for queries to individual data sources (e.g., '10s', '5m').<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information during the command's execution.<br><br><b><b>-whois</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable WHOIS lookups to gather registration information about domains and IPs.<br><br>


title: DESCRIPTION
content:
The <b>amass intel</b> command, a subcommand of the OWASP Amass project, is a powerful tool designed for open-source intelligence (OSINT) gathering. It focuses on collecting publicly available information about a target organization or domain. This includes identifying associated domains, autonomous system numbers (ASNs), IP addresses, netblocks, email addresses, and other critical data points.<br><br>By querying numerous public data sources, certificate transparency logs, WHOIS databases, and various APIs, <b>amass intel</b> helps security professionals and penetration testers build a comprehensive external profile of a target's infrastructure before deeper enumeration or exploitation phases. It provides foundational intelligence to understand the attack surface.


title: CAVEATS
content:
The effectiveness and completeness of <b>amass intel</b> heavily rely on the availability and accuracy of publicly accessible data sources. Results may vary and could be outdated.<br><br>Using the <i>-active</i> option can generate noticeable network traffic and should be done with appropriate authorization. Always adhere to ethical hacking guidelines and ensure you have explicit permission to perform intelligence gathering on any target.


title: DATA SOURCES
content:
<b>amass intel</b> leverages a vast array of internet-facing data sources, including but not limited to, certificate transparency logs (e.g., CertSpotter, Censys), WHOIS databases, DNS records (e.g., PassiveTotal, Rapid7), public search engines (e.g., Google, Bing), various APIs (e.g., Shodan, VirusTotal), and more. This extensive network of sources allows it to aggregate diverse pieces of information for a holistic view of the target.


title: ETHICAL CONSIDERATIONS
content:
While <b>amass intel</b> gathers publicly available information, it's crucial to use it responsibly and ethically. Ensure that any intelligence gathering activities are performed within legal boundaries and with explicit authorization for the target in question. Avoid actions that could be interpreted as malicious or intrusive without proper consent.


title: HISTORY
content:
The Amass project, developed by the OWASP Amass Project, began as a comprehensive tool for subdomain enumeration. As its capabilities grew, the need for distinct functionalities emerged, leading to the creation of subcommands like <b>intel</b>. The <b>intel</b> subcommand was specifically designed to separate and enhance the focus on passive and active open-source intelligence gathering, providing a dedicated module for collecting foundational information about a target's external footprint. Its development is ongoing, with continuous integration of new data sources and improved processing techniques.


title: SYNOPSIS
content:
<b>amass track</b> <b>-d</b> <i><domain></i> <b>-dir</b> <i><directory></i> [<b>-last</b> <i><duration></i>] [<b>-json</b>] [<b>-o</b> <i><output_file></i>] [<b>-v</b>]


title: PARAMETERS
content:
<b><b>-d</b> <i><domain></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target domain for which changes will be tracked.<br><br><b><b>-dir</b> <i><directory></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory where Amass stores its project-specific graph database and other data. This is crucial for historical data comparison across scans.<br><br><b><b>-last</b> <i><duration></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares the current scan against data from the last specified duration (e.g., <i>24h</i>, <i>7d</i>).<br><br><b><b>-json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the tracking results in JSON format.<br><br><b><b>-o</b> <i><output_file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the tracking results to the specified output file.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information during execution.<br><br>


title: DESCRIPTION
content:
The <b>amass track</b> command is a powerful sub-command of the <I>OWASP Amass</I> network mapping and asset discovery tool. Its primary purpose is to monitor and report on changes observed in the DNS records and associated IP addresses of assets over time. It leverages historical data stored in Amass's graph database (usually within a specified output directory) to compare the current state of discovered assets with previous reconnaissance efforts. This allows security professionals and penetration testers to identify new subdomains, disappearing assets, changes in IP allocations, or modifications to DNS entries that could indicate infrastructure shifts, new deployments, or potential security events.<br><br>By automating the detection of these changes, <b>amass track</b> helps in maintaining an up-to-date attack surface view. It's particularly useful for continuous monitoring programs, red team operations, and vulnerability management processes where understanding the evolving infrastructure of a target organization is critical. It helps in proactively identifying emerging threats or compliance issues related to asset visibility.


title: CAVEATS
content:
The effectiveness of <b>amass track</b> heavily relies on the presence of a persistent Amass graph database, typically populated by previous <b>amass enum</b> runs with the same <b>-dir</b> path. Without sufficient historical data, the tracking functionality will be limited. It can also consume significant disk space over time as the database grows. Performance may degrade with very large datasets or extensive historical comparisons. Ensure the specified directory is accessible and has sufficient write permissions.


title: USAGE WITH PERSISTENT DATA
content:
For <b>amass track</b> to function effectively, it requires access to historical data generated by previous <b>amass enum</b> runs. It is crucial to use the same <b>-dir</b> parameter across all Amass commands (enumeration and tracking) to ensure data consistency and allow the tool to build and leverage its graph database for comparison.


title: OUTPUT INTERPRETATION
content:
The output of <b>amass track</b> typically highlights three categories of changes: <i>new</i> discoveries (assets found in the current scan but not in historical data), <i>disappeared</i> assets (assets present historically but not in the current scan), and <i>changed</i> assets (where DNS records or IP addresses associated with an asset have changed). Understanding these categories is key to interpreting the results.


title: HISTORY
content:
The <b>amass</b> project, developed by <I>OWASP</I>, was initially released around 2017-2018. It quickly gained popularity as a comprehensive and powerful tool for attack surface mapping. The <b>track</b> subcommand was introduced as a natural evolution to support continuous monitoring and help users understand the dynamic nature of their discovered assets. Its development has focused on leveraging the internal graph database for efficient historical comparisons, making it a cornerstone for persistent reconnaissance operations within the Amass ecosystem.


title: SYNOPSIS
content:
<b>amass-viz</b> <i>[options]</i> <b>-d</b> <i>&lt;directory&gt;</i><br><b>amass-viz</b> <i>[options]</i> <b>-f</b> <i>&lt;file&gt;</i>


title: PARAMETERS
content:
<b><b>-d</b>, <b>--dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory containing Amass output files to be visualized.<br><br><b><b>-f</b>, <b>--file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a single Amass output file (e.g., JSON) to be visualized. Less common than directory processing.<br><br><b><b>-p</b>, <b>--port</b> <i>&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port number for the local web server launched to display the visualization. Default is often 8080 or 8081.<br><br><b><b>-ip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes IP addresses as nodes in the generated graph visualization.<br><br><b><b>-asn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes Autonomous System Numbers (ASNs) as nodes in the generated graph visualization.<br><br><b><b>-no-open</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>amass-viz</i> from automatically opening the web browser to display the visualization.<br><br><b><b>-g</b>, <b>--graphml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the graph data in GraphML format instead of launching a web-based visualization.<br><br><b><b>-d3-force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the D3.js force-directed graph layout for visualization (default behavior).<br><br><b><b>-d3-tree</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the D3.js tree layout for visualization, suitable for hierarchical data.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of the <i>amass-viz</i> tool.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the help message and available command-line options.<br><br>


title: DESCRIPTION
content:
<i>amass-viz</i> is an integral component of the <b>OWASP Amass</b> project, designed to transform the vast output of network reconnaissance into understandable and interactive visualizations. It typically processes data from Amass output directories, generating a web-based, force-directed graph that illustrates the relationships between discovered domain names, IP addresses, autonomous system numbers (ASNs), and other infrastructure elements. This visual representation significantly aids analysts in mapping an organization's external attack surface by highlighting intricate connections that might be obscure in raw text output. <i>amass-viz</i> often launches a local web server to serve the interactive graph, allowing users to zoom, pan, and click on nodes for detailed information. It simplifies the complex task of making sense of extensive reconnaissance datasets, making asset discovery more intuitive and actionable.


title: CAVEATS
content:
For large datasets, <i>amass-viz</i> may require significant system resources (CPU/RAM). The interactive visualization in a browser can become complex and less readable with an extremely high number of nodes and edges. Ensure the Amass output directory is correctly specified for proper processing.


title: INTERACTIVE EXPLORATION
content:
The web-based visualization generated by <i>amass-viz</i> offers interactive features such as zooming, panning, and clicking on individual nodes (domains, IPs, ASNs) to reveal associated details and expand connections, facilitating deeper analysis of the attack surface.


title: OUTPUT FORMATS
content:
While its primary function is interactive web visualization, <i>amass-viz</i> can also output the graph data in the GraphML format. This allows users to import the reconnaissance graph into other dedicated graph analysis and visualization tools like Gephi or yEd for further manipulation and advanced analytics.


title: HISTORY
content:
<i>amass-viz</i> emerged as a crucial component within the <b>OWASP Amass</b> project, which began development around 2017. Its inclusion addressed the growing need for intuitive data visualization in the realm of external asset discovery. As reconnaissance efforts became more extensive, generating vast amounts of interconnected data, the raw textual output from Amass became challenging to interpret. <i>amass-viz</i> was developed to bridge this gap, providing a visual interface that allows security professionals to quickly grasp complex infrastructure relationships, enhancing the overall utility and impact of the Amass tool suite.


title: SYNOPSIS
content:
<i>amidi</i> <b>-p</b> <i>port</i> [<b>-S</b> <i>hex_data</i> | <b>-R</b> [<b>-d</b>]] [<i>options</i>]<br><i>amidi</i> <b>-l</b>


title: PARAMETERS
content:
<b><b>-p</b> <i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ALSA raw MIDI port to use. The port can be identified by its full name (e.g., "hw:1,0,0"), its card/device/subdevice numbers, or an ALSA sequencer port name.<br><br><b><b>-S</b> <i>hex_data</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends hexadecimal MIDI data to the specified port. The data should be provided as a continuous string of hexadecimal bytes, e.g., "F07E7F0901F7".<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Receives raw MIDI data from the specified port. It will continuously listen and print incoming data until interrupted.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used in conjunction with <i>-R</i>. Dumps the received raw MIDI data in hexadecimal format to standard output.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available ALSA raw MIDI devices and their capabilities. This is useful for identifying the correct port to use with <i>-p</i>.<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;Displays the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>amidi</i> is a command-line utility provided by the ALSA (Advanced Linux Sound Architecture) project. Its primary purpose is to facilitate the sending and receiving of raw MIDI data to and from ALSA raw MIDI ports. This makes it an invaluable tool for debugging MIDI hardware, testing MIDI software, or sending specific MIDI messages like System Exclusive (SysEx) dumps directly to a device. Unlike applications that interpret MIDI messages, <i>amidi</i> operates at a lower level, handling raw byte streams, which offers precise control over MIDI communication. It can be used to send pre-defined hexadecimal MIDI data, or to listen for and dump incoming MIDI messages from a specified port, showing them in hexadecimal format.


title: CAVEATS
content:
<i>amidi</i> handles raw MIDI data; it does not interpret or process MIDI messages (e.g., notes, control changes) beyond their raw byte representation.<br>It requires direct access to ALSA raw MIDI devices, which might not be available or correctly configured in all systems.<br>When receiving data (<i>-R</i>), it will continue to run until manually stopped (e.g., Ctrl+C).


title: COMMON USE CASES
content:
<i>amidi</i> is frequently used for:<br>Sending SysEx messages to update firmware or configure hardware.<br>Troubleshooting MIDI communication issues by monitoring raw MIDI traffic.<br>Sending specific MIDI commands not easily accessible through higher-level applications.


title: HISTORY
content:
<i>amidi</i> is part of the ALSA Utilities package, which provides command-line tools for managing and interacting with the Advanced Linux Sound Architecture (ALSA). ALSA replaced the older OSS (Open Sound System) as the default sound system in Linux and has been the standard since the early 2000s. <i>amidi</i> specifically addresses the need for low-level interaction with ALSA's raw MIDI devices, allowing developers and power users to directly manipulate MIDI streams.


title: SYNOPSIS
content:
<i>amixer</i> [<i>options</i>] [<i>command</i>]<br><br>Common usage examples:<br><i>amixer</i> [<i>options</i>] <b>scontrols</b><br><i>amixer</i> [<i>options</i>] <b>sget</b> <i>&lt;SCONTROL&gt;</i><br><i>amixer</i> [<i>options</i>] <b>sset</b> <i>&lt;SCONTROL&gt; &lt;SVALUE&gt;</i><br><i>amixer</i> [<i>options</i>] <b>cget</b> <i>&lt;CCONTROL&gt;</i><br><i>amixer</i> [<i>options</i>] <b>cset</b> <i>&lt;CCONTROL&gt; &lt;CVALUE&gt;</i><br><br><i>SCONTROL</i> refers to a simple mixer control name (e.g., "Master", "PCM").<br><i>SVALUE</i> specifies the value for a simple control (e.g., "50%", "on", "off", "mute").<br><i>CCONTROL</i> refers to a complex (raw) mixer control identifier.<br><i>CVALUE</i> specifies the value for a complex control.


title: PARAMETERS
content:
<b>-c &lt;card&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the sound card by its index or ID.<br><br><b>-D &lt;device&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the mixer device to control.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing output.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays card index in information output.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves control values (for <i>sset</i> command).<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores control values (for <i>sset</i> command).<br><br><b>-F</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads/writes control values from/to a configuration file.<br><br><b>-V &lt;view&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets volume view mode (<i>basic</i>, <i>exact</i>, <i>get-dB</i>, <i>get-percent</i>).<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads/saves master control file (<i>.amixer.reg</i>).<br><br><b>-E</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads/saves enum control file (<i>.amixer.enum</i>).<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays controls in sorted alphabetical order.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays names of Playback controls only.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays names of Capture controls only.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available sound cards.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available mixer devices.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints raw output, suitable for parsing.<br><br><b>-B</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables batch mode for scripting, suppressing interactive prompts.<br><br><b>-I</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables interactive mode (not fully implemented in all versions).<br><br><b>-o &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects output to the specified file.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays timestamps with control information.<br><br><b>-T</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays control types (e.g., BOOLEAN, INTEGER).<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays control groups (e.g., Playback, Capture).<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces control names, useful with <i>cget</i>/<i>cset</i> for ambiguous names.<br><br><b>scontrols</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists simple mixer controls available on the selected device.<br><br><b>scontents</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current settings of all simple mixer controls.<br><br><b>sinfo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows information about the simple mixer interface.<br><br><b>sget &lt;SCONTROL&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the current value(s) of a specific simple control.<br><br><b>sset &lt;SCONTROL&gt; &lt;SVALUE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the value(s) of a specific simple control.<br><br><b>controls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all complex (raw) mixer controls.<br><br><b>contents</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current settings of all complex (raw) mixer controls.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows information about the complex (raw) mixer interface.<br><br><b>cget &lt;CCONTROL&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the current value(s) of a specific complex control.<br><br><b>cset &lt;CCONTROL&gt; &lt;CVALUE&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the value(s) of a specific complex control.<br><br>


title: DESCRIPTION
content:
<i>amixer</i> is a versatile command-line utility for querying and adjusting mixer settings of <br><b>ALSA</b> (Advanced Linux Sound Architecture) sound devices. It allows users to control <br>various aspects of their sound card, such as master volume, PCM levels, microphone <br>gain, and input/output source selection, directly from the terminal. Unlike graphical <br>mixers, <i>amixer</i> is ideal for scripting, remote administration, and automated audio <br>management tasks. It can interact with both simple controls, like common volume <br>sliders, and more complex, low-level hardware controls. Its robust capabilities make <br>it an essential tool for system administrators and advanced Linux users who need <br>precise control over their audio hardware.


title: CAVEATS
content:
<i>amixer</i> can be challenging for beginners due to the varying names and types of controls across different sound cards.<br>Setting incorrect values may lead to no sound or unexpected audio behavior.<br>The distinction between <i>simple</i> (<i>sget</i>/<i>sset</i>) and <i>complex</i> (<i>cget</i>/<i>cset</i>) controls <br>requires understanding of ALSA's control interface, with simple controls typically <br>being easier to manage.


title: <B>SCRIPTING AND AUTOMATION</B>
content:
<i>amixer</i>'s command-line nature makes it highly valuable for inclusion in shell <br>scripts. It enables automated tasks such as setting default volume levels on system <br>startup, dynamically muting audio during specific events, or creating custom <br>keyboard shortcuts for precise volume adjustments. This capability is crucial for <br>system administrators and users requiring programmatic control over their audio setup.


title: <B>CONTROL NAMING CONVENTIONS</B>
content:
Mixer controls are typically named descriptively (e.g., "Master", "PCM", "Capture", <br>"Headphone"). However, names can vary significantly depending on the sound <br>card's manufacturer and specific chip. Users might need to consult <br><i>amixer scontrols</i> or the interactive <i>alsamixer</i> tool to identify the correct <br>control names for their particular hardware.


title: HISTORY
content:
<i>amixer</i> is an integral part of the <b>ALSA</b> (Advanced Linux Sound Architecture) <br>project, which began development in 1997 as a successor to the then-dominant <br><b>OSS</b> (Open Sound System). ALSA's goal was to provide more robust hardware <br>support, a modular architecture, and a modern API for sound management in Linux. <br><i>amixer</i> emerged as the primary command-line tool for interacting with ALSA's mixer <br>subsystem, evolving over the years to support new audio hardware features and <br>complex control paradigms. It remains a fundamental utility for low-level audio <br>configuration and scripting in Linux environments.


title: SYNOPSIS
content:
<b>anacron</b> [<i>options</i>] [<i>job_identifier</i>] <br><b>anacron</b> -t <i>anacrontab_file</i> [-S <i>spool_dir</i>] [<i>options</i>] [<i>job_identifier</i>]


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Run jobs sequentially</i>. <br> Executes the jobs defined in <i>anacrontab</i> one after another, waiting for each to finish before starting the next. This is the most commonly used option when <b>anacron</b> is invoked.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force execution</i>. <br> Forces the execution of all jobs, regardless of their timestamps.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Run immediately</i>. <br> Ignores the random delay specified in <i>anacrontab</i> and runs jobs immediately after the initial delay.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Update timestamps only</i>. <br> Updates the timestamps of all jobs to the current date, but does not actually run them. Useful for resetting job schedules.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verbose output</i>. <br> Prints more information about what <b>anacron</b> is doing to standard output.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Debug mode</i>. <br> Similar to verbose mode but also prints error messages to standard error. Implies <b>-V</b>.<br><br><b><b>-t</b> <i>anacrontab_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify anacrontab file</i>. <br> Uses the specified file as the <i>anacrontab</i> instead of the default <i>/etc/anacrontab</i>.<br><br><b><b>-S</b> <i>spool_dir</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify spool directory</i>. <br> Uses the specified directory to store timestamp files instead of the default <i>/var/spool/anacron</i>.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress messages</i>. <br> Suppresses all messages to standard output and standard error.<br><br><b><i>job_identifier</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Run a specific job</i>. <br> If provided, <b>anacron</b> will only run the job matching this identifier from the <i>anacrontab</i> file.<br><br>


title: DESCRIPTION
content:
<b>anacron</b> is a utility that executes commands periodically, much like <b>cron</b>, but with a crucial difference: it's designed for systems that are not running 24/7. Unlike <b>cron</b>, which relies on strict time schedules, <b>anacron</b> ensures that jobs are run even if the machine was powered off during their scheduled execution time. <br><br> When <b>anacron</b> is run (typically once a day via <b>cron</b> itself, often from <i>/etc/cron.daily/00anacron</i> or <i>/etc/cron.hourly/anacron</i>), it checks its configuration file, <i>anacrontab</i> (defaulting to <i>/etc/anacrontab</i>). For each job listed, it verifies if it has been executed within its defined period. If a job has not been run for longer than its specified period (e.g., a weekly job hasn't run in over 7 days), <b>anacron</b> will execute it. <br><br> To prevent resource spikes, <b>anacron</b> can apply a random delay before executing a job. It also updates a timestamp file (in <i>/var/spool/anacron</i> by default) after each successful job execution to track when it was last run. This makes <b>anacron</b> ideal for laptops, home servers, or any system that isn't always powered on, guaranteeing that maintenance tasks, backups, and log rotations eventually run.


title: CAVEATS
content:
<b>anacron</b> typically relies on <b>cron</b> to be started daily. If <b>cron</b> is not running or the daily/hourly <b>anacron</b> script is removed, <b>anacron</b> jobs won't execute.<br><br>Jobs are executed with the permissions of the user running <b>anacron</b> (usually root when invoked from system <b>cron</b>).<br><br>Jobs are <i>not</i> guaranteed to run at a precise time, only that they will run <i>eventually</i> after the machine has been on for a sufficient duration and the initial delay has passed.<br><br>The system clock must be reasonably accurate for <b>anacron</b> to function correctly regarding its period checks.


title: <I>ANACRONTAB FILE FORMAT</I>
content:
The <i>anacrontab</i> file (e.g., <i>/etc/anacrontab</i>) defines the jobs <b>anacron</b> manages. Each line typically has the format: <br> <i>period</i><tab><i>delay</i><tab><i>job-identifier</i><tab><i>command</i><br><br><ul><li><i>period</i>: The frequency in days (e.g., <b>7</b> for weekly, <b>30</b> for monthly, <b>1</b> for daily). Special values like <b>@daily</b>, <b>@weekly</b>, <b>@monthly</b> can also be used, which are equivalent to <b>1</b>, <b>7</b>, <b>30</b> days respectively.</li><li><i>delay</i>: The number of minutes <b>anacron</b> waits after starting before executing the job. This helps to spread out system load.</li><li><i>job-identifier</i>: A unique string for the job, used to create its timestamp file.</li><li><i>command</i>: The shell command to be executed.</li></ul>


title: <I>TIMESTAMP FILES</I>
content:
<b>anacron</b> uses timestamp files, typically stored in <i>/var/spool/anacron</i> (or a specified spool directory), to record the last execution date of each job. These files are named after their <i>job-identifier</i>. <b>anacron</b> checks these timestamps against the current date and the job's defined <i>period</i> to decide if a job needs to be run.


title: <I>TYPICAL INVOCATION</I>
content:
On most Linux distributions, <b>anacron</b> is not started manually by users. Instead, it's typically invoked by the system's <b>cron</b> daemon, usually daily or hourly. For example, a script like <i>/etc/cron.daily/00anacron</i> might contain: <br> <code>#!/bin/sh</code> <br> <code>test -x /usr/sbin/anacron || exit 0</code> <br> <code>/usr/sbin/anacron -s</code> <br> This ensures that <b>anacron</b> checks for missed jobs whenever the system performs its daily <b>cron</b> tasks.


title: HISTORY
content:
<b>anacron</b> was developed to address a common problem with traditional <b>cron</b> scheduling: jobs would be missed on systems that were not continuously powered on, such as laptops. It first appeared in Debian and was subsequently adopted by other Linux distributions. Its design focuses on ensuring eventual execution of periodic tasks, making it a vital component for maintaining intermittently active machines. It gained widespread adoption as Linux became more common on desktop and portable devices.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>-s</b> <I>SERVER</I>, <b>--server</b> <I>SERVER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the preferred streaming server (e.g., gogoanime, zoro).<br><br><b><b>-d</b>, <b>--download</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download the selected episode instead of streaming it.<br><br><b><b>-q</b> <I>QUALITY</I>, <b>--quality</b> <I>QUALITY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the desired video quality (e.g., 360p, 720p, 1080p).<br><br><b><b>-c</b>, <b>--crunchy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use Crunchyroll as the streaming server (may require premium subscription and authentication).<br><br><b><b>-r</b>, <b>--random</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Play a random episode from a specified anime or a random anime if no title is given.<br><br><b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display detailed information about an anime title.<br><br><b><b>-e</b> <I>EPISODE</I>, <b>--episode</b> <I>EPISODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific episode number to stream or download.<br><br><b><b>-p</b> <I>PLAYER</I>, <b>--player</b> <I>PLAYER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative video player to <i>mpv</i>.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available episodes for a given anime title.<br><br><b><b>-g</b>, <b>--gui</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the episode link in a web browser instead of streaming via <i>mpv</i>.<br><br><b><b>-n</b>, <b>--no-subs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable subtitles for the selected episode.<br><br><b><b>-S</b>, <b>--skip-search</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip the search results if an exact anime title is provided, playing the first match directly.<br><br><b><b>-V</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for debugging and detailed progress information.<br><br>


title: DESCRIPTION
content:
<i>ani-cli</i> is a powerful command-line interface (CLI) tool designed for streaming and downloading anime directly from the terminal. It provides a lightweight and efficient way to access a vast library of anime without the need for a web browser, relying on common external tools like <i>mpv</i> for video playback. Users can search for specific titles, browse episodes, and either play them instantly or download them for offline viewing. Its primary appeal lies in its minimalist interface and speed, making it suitable for users who prefer a terminal-centric workflow or want to consume media on systems without a full graphical environment. It typically scrapes content from various online anime streaming websites, allowing for server and quality selection to optimize the viewing experience.<br>


title: CAVEATS
content:
Using <i>ani-cli</i> to access copyrighted content without proper authorization may carry legal risks. The tool relies on scraping external streaming websites, which can be unreliable, change their structure, or go offline, potentially breaking functionality. It is also subject to geographical restrictions imposed by content providers. Users should be aware that <i>ani-cli</i> is not typically available through official distribution package managers and often requires manual installation, along with dependencies like <i>mpv</i>, <i>curl</i>, and standard Unix utilities.<br>


title: INSTALLATION
content:
<i>ani-cli</i> is primarily distributed via its GitHub repository. Users typically clone the repository, make the main script executable, and place it in their system's PATH. It is also available via community-maintained packages for some distributions (e.g., AUR for Arch Linux).<br>


title: DEPENDENCIES
content:
The tool relies on several external programs for its functionality, including <i>mpv</i> (for video playback), <i>curl</i> (for network requests), and standard Unix utilities like <i>grep</i>, <i>sed</i>, and <i>awk</i> for parsing data. Optional dependencies like <i>fzf</i> can enhance interactive search and selection.<br>


title: HISTORY
content:
<i>ani-cli</i> emerged as an open-source project, primarily developed on GitHub, gaining popularity among command-line enthusiasts and anime fans seeking a lightweight alternative to browser-based streaming. Its development has been community-driven, with contributions focusing on improving site compatibility, adding new features like server selection and quality options, and refining the user experience within the terminal environment. It has evolved to support a growing number of anime sources and playback customization options since its initial release.<br>


title: PARAMETERS
content:
<b>-delay <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the delay between frames in 1/100ths of a second. E.g., <B>-delay 20</B> for 0.2 seconds.<br><br><b>-loop <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of times the animation will loop. A value of <B>0</B> means infinite looping.<br><br><b>-dispose <method></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines how the previous frame is treated before displaying the next one (e.g., <B>None</B>, <B>Background</B>, <B>Previous</B>).<br><br><b>-geometry <WxH+X+Y></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial size and position of the animation window (e.g., <B>-geometry 640x480+10+10</B>).<br><br><b>-backdrop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the animation on the X server root window (desktop background).<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints detailed information about the image sequence being animated.<br><br><b>-window <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the image in a specified X window by its ID.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the ImageMagick version number.<br><br>


title: DESCRIPTION
content:
The <I>animate.im6</I> command is a utility from the <B>ImageMagick 6</B> software suite, designed to display a sequence of images as a continuous animation on an <B>X Window System</B> display.<br><br>It is commonly used to preview multi-frame image formats like GIFs, or to quickly view a series of individual image files as a slideshow or animation. Unlike ImageMagick's <I>display</I> command which typically handles single images, <I>animate.im6</I> focuses specifically on temporal sequences.<br><br>Users can control various aspects of the animation, such as the delay between frames, the number of times the animation loops, and how frames are disposed. The <I>.im6</I> suffix signifies that this is the version of the command specifically from the ImageMagick 6 distribution, distinguishing it from newer versions (like those consolidated under the <I>magick</I> command in ImageMagick 7). It's an invaluable tool for developers and graphic artists working with animations, offering a quick visual check of their work directly from the command line.


title: CAVEATS
content:
The <I>animate.im6</I> command requires an active <B>X Window System</B> display environment to function, as it is a graphical utility. It cannot be used on headless servers or environments without a graphical interface.<br><br>Being part of ImageMagick 6, its behavior and available options might slightly differ from newer ImageMagick 7 installations, where the functionality is often accessed via <B>magick animate</B>.


title: X WINDOW SYSTEM REQUIREMENT
content:
As a graphical utility, <I>animate.im6</I> must be run in an environment with an active <B>X Window System</B> display. It will not work in command-line-only or SSH sessions without X forwarding enabled.


title: IMAGEMAGICK VERSIONING
content:
The <I>.im6</I> suffix explicitly indicates that this command belongs to the <B>ImageMagick 6</B> branch. Newer systems might primarily use <B>ImageMagick 7</B>, where the equivalent functionality is often accessed through the unified <I>magick</I> command (e.g., <B>magick animate</B>).


title: HISTORY
content:
The <I>animate</I> utility has been a core component of the <B>ImageMagick</B> software suite since its early days, providing an essential way to preview image animations. The <I>.im6</I> suffix became common with the release of <B>ImageMagick 7</B>, which introduced a consolidated <I>magick</I> command and often installed its binaries alongside previous ImageMagick 6 versions. This naming convention (<I>command.im6</I>) allows systems to maintain compatibility with scripts or workflows dependent on ImageMagick 6 while also leveraging the capabilities of ImageMagick 7.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b><b>-o</b> <i>DIRECTORY</i>, <b>--output</b> <i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the downloaded files will be saved.<br><br><b><b>-q</b> <i>QUALITY</i>, <b>--quality</b> <i>QUALITY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the preferred video quality for download (e.g., "720p", "1080p").<br><br><b><b>-e</b> <i>EPISODES</i>, <b>--episode</b> <i>EPISODES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads specific episodes or a range (e.g., "1,3,5" or "1-10").<br><br><b><b>-S</b> <i>SOURCE</i>, <b>--source</b> <i>SOURCE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the streaming source or website to download from. Use <b>--list-sources</b> to see available options.<br><br><b><b>--search</b> <i>QUERY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for anime matching the given query instead of downloading from a URL.<br><br><b><b>--auto-select</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically selects the best available quality for download.<br><br><b><b>--force-download</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the download even if the file already exists in the output directory.<br><br><b><b>--list-sources</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all supported anime streaming sources that <i>animdl</i> can download from.<br><br><b><b>--list-qualities</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays available video qualities for a given URL without initiating the download.<br><br><b><b>--skip-download</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the actual video download, only extracting and displaying information about the content.<br><br><b><b>--no-mux</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>animdl</i> from muxing video and audio streams into a single file after download.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more detailed information during the process.<br><br><b><b>--ffmpeg-location</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the custom path to the <i>ffmpeg</i> executable if it's not in the system's PATH.<br><br>


title: DESCRIPTION
content:
<i>animdl</i> is a powerful, open-source command-line utility designed for downloading anime from a wide array of online streaming services. <br>Built with Python, it offers a versatile solution for users who prefer to watch anime offline or manage their personal media libraries. <br>The tool supports downloading individual episodes, entire seasons, or even complete series, providing flexibility in how content is acquired. <br>It intelligently parses episode information, handles quality selection, and can integrate with external tools like <i>ffmpeg</i> for muxing and format conversion, ensuring a complete and high-quality download experience. <br><i>animdl</i> aims to be a one-stop solution for anime enthusiasts, abstracting the complexities of web scraping and content acquisition into a simple, easy-to-use command-line interface.


title: CAVEATS
content:
<i>animdl</i> relies on web scraping, meaning its functionality can be affected by changes to anime streaming website layouts. <br>Users should ensure <i>ffmpeg</i> is installed and accessible for proper muxing and format conversion. <br>Always be aware of copyright laws and terms of service regarding downloading copyrighted content in your region.


title: INSTALLATION
content:
<i>animdl</i> is typically installed via pip, the Python package installer. <br>The most common installation command is: <br><i>pip install animdl</i> <br>It is recommended to use a virtual environment to manage dependencies. <br>Users also need to ensure that <i>ffmpeg</i> is installed and accessible in their system's PATH for full functionality, particularly for muxing audio and video streams.


title: HISTORY
content:
<i>animdl</i> is an active open-source project primarily developed on GitHub. Its development focuses on continuously adapting to changes in anime streaming websites and expanding its list of supported sources. As a Python-based utility, it leverages community contributions for bug fixes and feature enhancements, typical of many web-scraping tools that require frequent updates to maintain compatibility with dynamic web content.


title: PARAMETERS
content:
<b><i>--profile</i> <I>PROFILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches Anki with a specific user profile by its name. This is useful for managing multiple distinct sets of decks, settings, and statistics for different users or purposes.<br><br><b><i>--lang</i> <I>LANG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display language for the Anki interface. Common values include 'en' for English, 'es' for Spanish, 'fr' for French, etc.<br><br><b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens Anki and attempts to import or open the specified Anki deck package (<i>.apkg</i>) or an Anki collection file (<i>.anki2</i>, <i>.sqlite</i>).<br><br>


title: DESCRIPTION
content:
Anki is a powerful, open-source spaced repetition flashcard program designed to help users remember facts and concepts efficiently using active recall and spaced repetition. The <b>anki</b> command primarily serves to launch the graphical user interface (GUI) application on Linux. It provides a comprehensive environment for deck management, card creation, synchronization across devices, and personalized review sessions. Widely adopted by students, language learners, and professionals, Anki excels at memorizing diverse information, from vocabulary and historical dates to medical terminology and programming syntax. Its core principle is to present flashcards at optimal intervals, just as you're about to forget them, maximizing retention with minimal effort and study time.


title: CAVEATS
content:
The <b>anki</b> command primarily launches a graphical desktop application; it is not a typical command-line utility for direct data manipulation or extensive CLI-based interactions. All significant operations like creating decks, adding cards, or performing reviews are executed within the GUI. Command-line options are limited to initial setup and file loading.


title: <I>PRIMARY USE CASE</I>
content:
The <b>anki</b> command's main purpose is to initiate the graphical user interface. All core functionalities of Anki, such as deck management, card creation, review sessions, and synchronization, are performed interactively within the launched GUI application, not directly via command-line arguments.


title: <I>ADD-ONS AND ECOSYSTEM</I>
content:
Anki boasts a rich ecosystem of community-developed add-ons that significantly extend its capabilities, ranging from advanced card styling to integration with external tools. These add-ons are managed and utilized from within the Anki GUI, not through command-line parameters.


title: <I>SPACED REPETITION PRINCIPLE</I>
content:
Anki's effectiveness is rooted in its intelligent scheduling algorithm, which optimizes learning by presenting cards to you at increasing intervals, just before you're likely to forget them. This principle maximizes long-term memory retention and minimizes the overall study time required.


title: HISTORY
content:
Anki was originally created by Damien Elmes in 2006. Its development was largely driven by the desire for a highly efficient learning tool based on the principles of spaced repetition, particularly the SM-2 algorithm from SuperMemo. Its open-source nature has fostered a robust community, leading to continuous improvements, numerous add-ons, and translations, significantly expanding its functionality and global reach. Anki has evolved from a simple flashcard program into a sophisticated and widely-used learning platform.


title: SYNOPSIS
content:
<b>ansible</b> <i>&lt;host-pattern&gt;</i> [<b>-i</b> <i>INVENTORY</i>] [<b>-m</b> <i>MODULE_NAME</i>] [<b>-a</b> <i>MODULE_ARGS</i>] [<i>options</i>]<br>


title: PARAMETERS
content:
<b><b>-i</b> <i>INVENTORY</i>, <b>--inventory=</b><i>INVENTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify inventory host file or script.<br><br><b><b>-m</b> <i>MODULE_NAME</i>, <b>--module-name=</b><i>MODULE_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Ansible module to execute (default: <i>command</i>).<br><br><b><b>-a</b> <i>MODULE_ARGS</i>, <b>--args=</b><i>MODULE_ARGS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide arguments to the module.<br><br><b><b>-u</b> <i>REMOTE_USER</i>, <b>--user=</b><i>REMOTE_USER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect as this user.<br><br><b><b>-b</b>, <b>--become</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run operations with become (e.g., sudo) privileges.<br><br><b><b>-k</b>, <b>--ask-pass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for connection password (e.g., SSH password).<br><br><b><b>-K</b>, <b>--ask-become-pass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for become (sudo) password.<br><br><b><b>-e</b> <i>VARS</i>, <b>--extra-vars=</b><i>VARS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set additional variables as key=value or YAML/JSON string.<br><br><b><b>-l</b> <i>SUBSET</i>, <b>--limit=</b><i>SUBSET</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit selected hosts to a subset specified by a pattern.<br><br><b><b>-f</b> <i>FORKS</i>, <b>--forks=</b><i>FORKS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of parallel processes to use (default: 5).<br><br><b><b>--list-hosts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all hosts that match the pattern, without executing any module.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output (use multiple <b>-v</b> for more verbosity).<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br>


title: DESCRIPTION
content:
The <b>ansible</b> command is a fundamental part of the Ansible automation engine, designed for executing quick, one-off tasks against a group of managed hosts. Unlike <b>ansible-playbook</b>, which orchestrates complex, multi-step workflows defined in YAML playbooks, <b>ansible</b> is used for immediate execution of specific modules. It allows administrators to perform actions such as checking host connectivity, gathering facts, managing packages, restarting services, or running shell commands across an entire inventory or a subset of it, all without needing to write a playbook. This makes it ideal for rapid troubleshooting, administrative tasks, or verifying configurations across a large infrastructure. It operates over SSH (by default), requiring no agents on the remote machines, leveraging their existing Python installations.


title: CAVEATS
content:
<ul><li>While powerful for ad-hoc tasks, <b>ansible</b> is not designed for complex, multi-step orchestration or configuration management; for those, <b>ansible-playbook</b> is the appropriate tool.</li><li>Requires Python (version 2.7 or 3.5+) on the managed nodes to execute modules.</li><li>Without proper inventory and host patterns, commands might target unintended hosts.</li></ul>


title: HOST PATTERN
content:
The <i>&lt;host-pattern&gt;</i> argument is crucial, specifying which hosts from your inventory the command should run against. It can be 'all', a specific host, a group name, or a complex pattern (e.g., 'webservers:&amp;production' for hosts in both groups).


title: MODULES
content:
Ansible's functionality is driven by modules. The <b>-m</b> option allows you to specify which module to use (e.g., <i>ping</i>, <i>shell</i>, <i>apt</i>, <i>yum</i>, <i>service</i>, <i>copy</i>). Modules are designed to be idempotent where applicable, meaning running them multiple times results in the same final state without unintended side effects. The default module if not specified is <i>command</i>.


title: HISTORY
content:
Ansible was created by Michael DeHaan, the author of Cobbler and Func, and was first released in 2012. It quickly gained popularity due to its simplicity, agentless architecture, and use of human-readable YAML for automation. In 2015, Red Hat acquired Ansible, integrating it into its enterprise offerings and further accelerating its development and adoption within the open-source community and enterprises alike. The <b>ansible</b> command has been a core component since the project's inception, serving as the immediate interface for quick interactions with managed hosts.


title: SEE ALSO
content:
<b>ansible-playbook</b>(1), <b>ansible-vault</b>(1), <b>ansible-galaxy</b>(1), <b>ansible-config</b>(1)


title: SYNOPSIS
content:
<b>ansible-doc</b> <b>[-l]</b> <b>[-s]</b> <b>[-t <i><type></i>]</b> <b>[<i>module_or_plugin_name</i> ...]</b><br><b>ansible-doc</b> <b>--version</b><br><b>ansible-doc</b> <b>--help</b>


title: PARAMETERS
content:
<b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available Ansible modules and plugins that can be documented.<br><br><b><b>-s</b>, <b>--snippet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage snippet for the specified module or plugin, showing common parameters.<br><br><b><b>-t <i><type></i></b>, <b>--type <i><type></i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of plugin to document. Common types include <i>module</i> (default), <i>lookup</i>, <i>filter</i>, <i>connection</i>, and <i>inventory</i>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, which can provide more detailed information during execution.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the <i>ansible-doc</i> command and exits.<br><br>


title: DESCRIPTION
content:
<i>ansible-doc</i> is a command-line utility used to display documentation for Ansible modules, plugins, and lookups. It provides detailed information including module parameters, examples, return values, and common usage patterns. This tool is invaluable for Ansible users and developers to quickly understand how to use various components without needing internet access or searching external documentation. It retrieves the documentation directly from the installed Ansible libraries, ensuring accuracy for your specific Ansible version. Users can either query specific module or plugin names or list all available modules to explore Ansible's vast capabilities. It significantly aids in playbook development and debugging by providing immediate access to critical module specifications.


title: CAVEATS
content:
<i>ansible-doc</i> relies on an installed Ansible environment, meaning it will not function without a proper Ansible installation. The documentation it provides is specific to the version of Ansible currently installed on your system; it may not reflect the latest or oldest versions available online. Furthermore, it focuses exclusively on modules and plugins, and does not provide documentation for general Ansible concepts, playbook syntax, or best practices.


title: <B>EXAMPLES OF USAGE</B>
content:
To view documentation for a specific module, such as the <i>yum</i> module, you would run:<br><code>ansible-doc yum</code><br><br>To see a brief snippet for the <i>shell</i> module's common parameters:<br><code>ansible-doc -s shell</code><br><br>To list all available modules:<br><code>ansible-doc -l</code><br><br>To view documentation for a <i>lookup</i> plugin, such as <i>file</i>:<br><code>ansible-doc -t lookup file</code>


title: <B>OFFLINE ACCESSIBILITY</B>
content:
One of the key benefits of <i>ansible-doc</i> is its ability to provide comprehensive module and plugin documentation without requiring an active internet connection. This makes it an ideal tool for use in isolated or air-gapped environments where external documentation resources are not readily available.


title: HISTORY
content:
<i>ansible-doc</i> has been a fundamental part of the Ansible project since its early stages. It was introduced to provide an on-demand, offline documentation source for the ever-growing collection of Ansible modules. As Ansible evolved, <i>ansible-doc</i> adapted to support new plugin types (like lookups, filters, and inventory plugins) and underwent continuous improvements in its output formatting and search capabilities. Its core purpose of being an accessible, quick reference for module and plugin usage remains unchanged, making it an indispensable tool for Ansible users.


title: SEE ALSO
content:
<b>ansible(1)</b>, <b>ansible-playbook(1)</b>, <b>ansible-galaxy(1)</b>, <b>ansible-vault(1)</b>, <b>man(1)</b>


title: SYNOPSIS
content:
<b>ansible-galaxy</b> [<I>GLOBAL_OPTIONS</I>] <I>COMMAND</I> [<I>SUBCOMMAND_OPTIONS</I>] [<I>ARGUMENTS</I>]<br><br><b>Commands:</b><br>&nbsp;&nbsp;<b>install</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Install roles or collections from Galaxy or a local path.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy install <I>author.role_name</I></i><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy install <I>author-collection_name</I></i><br>&nbsp;&nbsp;<b>init</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Create a new role skeleton.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy init <I>my_new_role</I></i><br>&nbsp;&nbsp;<b>list</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;List installed roles or collections.<br>&nbsp;&nbsp;<b>remove</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Remove an installed role.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy remove <I>author.role_name</I></i><br>&nbsp;&nbsp;<b>search</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Search Galaxy for roles or collections.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy search <I>webserver</I></i><br>&nbsp;&nbsp;<b>login</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Authenticate to a Galaxy server.<br>&nbsp;&nbsp;<b>logout</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Log out from a Galaxy server.<br>&nbsp;&nbsp;<b>collection</b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Manage collections (subcommands: build, init, install, publish, verify).<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>e.g., ansible-galaxy collection build</i>


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output. Use multiple times for more verbosity (-vvv).<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwriting an existing role or collection when installing.<br><br><b>--no-deps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not download dependencies when installing a role or collection.<br><br><b>--role-file, -r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of roles or collections to install (requirements.yml).<br><br><b>--roles-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory where roles should be installed. Defaults to ~/.ansible/roles or current working directory.<br><br><b>--collections-path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory where collections should be installed. Defaults to ~/.ansible/collections.<br><br><b>--ignore-certs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore SSL certificate validation errors when connecting to Galaxy.<br><br><b>--server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Galaxy API server URL to use (e.g., https://galaxy.ansible.com).<br><br><b>--token</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authentication token for the Galaxy API server. Can be stored with 'login'.<br><br><b>--timeout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the socket timeout in seconds for network operations.<br><br><b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not connect to the Galaxy server. Only use local cache and paths (useful for 'list' command).<br><br><b>--format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output format for 'list' or 'search' commands (e.g., 'json', 'yaml').<br><br>


title: DESCRIPTION
content:
The <b>ansible-galaxy</b> command is a command-line utility used to interact with <I>Ansible Galaxy</I>, a free website for finding, reusing, and sharing Ansible content, primarily <I>roles</I> and <I>collections</I>.<br><br>It serves as the primary tool for installing community-contributed roles and collections from Galaxy into your Ansible project. This significantly promotes reusability and standardization in Ansible automation. Beyond installation, <b>ansible-galaxy</b> allows users to initialize new role or collection structures, list installed content, remove existing content, and search the Galaxy platform directly from the terminal.<br><br>With the introduction of <I>Ansible Collections</I> in Ansible 2.9, <b>ansible-galaxy</b> was extended to support these new packaging formats, enabling users to build, initialize, and install collections, which encapsulate not only roles but also modules, plugins, playbooks, and documentation. It's an indispensable tool for anyone building, consuming, or contributing to the Ansible ecosystem, streamlining the process of managing dependencies and leveraging community-driven content.


title: CAVEATS
content:
When installing roles or collections, <b>ansible-galaxy</b> often requires network connectivity to reach the Ansible Galaxy server. For private or air-gapped environments, content must be pre-downloaded or served from a private Galaxy instance.<br><br>Using the <I>--force</I> option can overwrite existing content, potentially leading to unintended changes if not used carefully.<br><br>Dependencies specified in <I>meta/main.yml</I> for roles or <I>galaxy.yml</I> for collections are automatically resolved and installed by default, which can sometimes pull in many additional components. Use <I>--no-deps</I> to prevent this behavior.<br><br>Content from Ansible Galaxy is community-contributed; it's advisable to review roles and collections before deploying them in production environments to ensure security and quality standards are met.


title: ROLE VS. COLLECTION MANAGEMENT
content:
Originally, <b>ansible-galaxy</b> primarily managed <I>Ansible Roles</I>. With Ansible 2.9+, it also manages <I>Ansible Collections</I>. The syntax for installation using `ansible-galaxy install` handles both (e.g., `author.role_name` or `author.collection_name`). However, specific `collection` subcommands (e.g., `ansible-galaxy collection build`) are exclusively for collections, and `ansible-galaxy init` (without `collection`) is for roles.


title: REQUIREMENTS FILE
content:
For managing multiple roles or collections, it's common practice to use a <I>requirements.yml</I> file. This YAML file lists roles or collections with their sources (Galaxy, Git, local path) and versions. You can install all listed dependencies using `ansible-galaxy install -r requirements.yml` (for roles) or `ansible-galaxy collection install -r requirements.yml` (for collections, if specified in a collection-specific requirements file).


title: OFFLINE INSTALLATION
content:
If direct internet access to Galaxy is not available, you can use <b>ansible-galaxy</b> to install roles/collections from a local tarball (e.g., `ansible-galaxy install <I>./my_role.tar.gz</I>`) or from a private Galaxy instance by specifying the <I>--server</I> option.


title: CUSTOM PATHS
content:
By default, roles are installed in `~/.ansible/roles` and collections in `~/.ansible/collections/ansible_collections`. These paths can be overridden globally in `ansible.cfg` or per-command using the <I>--roles-path</I> or <I>--collections-path</I> options, allowing for project-specific dependencies or system-wide installations.


title: HISTORY
content:
The <b>ansible-galaxy</b> command was introduced early in Ansible's development lifecycle to facilitate sharing and reusing Ansible <I>roles</I>. It was initially designed primarily for managing roles on <I>galaxy.ansible.com</I>.<br><br>With the release of Ansible 2.9, a significant architectural change introduced <I>Ansible Collections</I>, a new packaging format that allows bundling modules, plugins, roles, playbooks, and documentation together. Consequently, <b>ansible-galaxy</b> was updated to support collections, gaining new subcommands like <I>collection build</I>, <I>collection init</I>, and <I>collection install</I> to manage this new content type. This evolution reflects Ansible's growth towards more modular and organized content distribution.


title: SYNOPSIS
content:
<i>ansible-inventory</i> <b>[<I>-i INVENTORY</I>]</b> <b>[<I>--list</I> | <I>--graph</I> | <I>--host HOSTNAME</I> | <I>--export</I>]</b> <b>[<I>options</I>]</b><br><br>Examples:<br><i>ansible-inventory -i /etc/ansible/hosts --list</i><br><i>ansible-inventory -i /path/to/inventory.yaml --graph</i><br><i>ansible-inventory -i my_dynamic_inventory_script.py --host webserver1 -v</i>


title: PARAMETERS
content:
<b><I>-i INVENTORY, --inventory=INVENTORY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the inventory file, directory, or dynamic inventory script to use. This option is often required for most commands.<br><br><b><I>--list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all hosts and groups from the inventory in JSON format. This is the default action if no other action option (like <i>--graph</i> or <i>--host</i>) is specified.<br><br><b><I>--graph</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a graphical representation (ASCII art) of the inventory groups and hosts, showing their hierarchical relationships.<br><br><b><I>--host=HOSTNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information and all resolved variables for a specific host within the inventory. Essential for debugging variable precedence.<br><br><b><I>--export</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports the inventory in a format suitable for use with <i>-i</i>, typically JSON, enabling inventory transformation or further processing.<br><br><b><I>-v, --verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output. Can be specified multiple times (e.g., <i>-vvv</i>) for increasing levels of detail, which is particularly useful for debugging.<br><br><b><I>--yaml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs <i>--list</i> or <i>--host</i> information in YAML format instead of the default JSON, often preferred for readability.<br><br><b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs <i>--list</i> or <i>--host</i> information in JSON format (this is the default behavior).<br><br><b><I>--toml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs <i>--list</i> or <i>--host</i> information in TOML format (requires the <i>toml</i> Python package to be installed).<br><br><b><I>--show-enabled-plugins</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently enabled inventory plugins that Ansible is configured to use, which can help diagnose inventory loading issues.<br><br><b><I>--help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the command and exits.<br><br>


title: DESCRIPTION
content:
<i>ansible-inventory</i><br>is a powerful command-line utility provided by Ansible, designed to help users view, manage, and debug their Ansible inventories. It offers a structured and comprehensive way to inspect the hosts, groups, variables, and host/group relationships defined within any inventory source, whether it's a static file (INI, YAML) or a dynamic inventory script. Its primary applications include <b>verifying the correctness and structure of the inventory</b>, listing all available hosts and their associations, showing detailed information and resolved variables for specific hosts, and understanding the complex variable precedence rules. This tool is indispensable for any Ansible user, as it provides critical insights into how Ansible perceives the environment before executing playbooks, thereby significantly aiding in troubleshooting, ensuring proper targeting of systems, and confirming that playbooks receive the expected variable values. It serves as a diagnostic window into your Ansible-managed infrastructure.


title: CAVEATS
content:
Using <i>ansible-inventory</i> requires an existing Ansible installation on the system. <br>Dynamic inventory scripts must be executable and strictly adhere to Ansible's dynamic inventory protocol to provide valid JSON output. <br>Understanding variable precedence can be complex; <i>ansible-inventory --host</i> is an invaluable tool for debugging how Ansible resolves variables for a specific host, as it shows the final, merged variable values. <br>For very large or highly complex dynamic inventories, performance might be a consideration, as the inventory script must be executed to gather all data, potentially leading to longer execution times.


title: COMMON USE CASES
content:
<I>Debugging Inventory</I>: Quickly check if hosts, groups, and their relationships are correctly defined and recognized by Ansible.<br><I>Variable Inspection</I>: Determine the final, merged value of a variable for a specific host, considering all sources (inventory files, group_vars, host_vars, roles, etc.). This is critical for troubleshooting playbook behavior.<br><I>Listing Hosts</I>: Obtain a machine-readable list of all hosts and their associated groups, useful for scripting or integration with other automation tools.<br><I>Graph Visualization</I>: Understand the hierarchical relationships between groups and hosts using the <i>--graph</i> option, which provides an ASCII art representation of the inventory structure.


title: OUTPUT FORMATS
content:
By default, <i>ansible-inventory --list</i> and <i>ansible-inventory --host</i> output information in JSON format.<br>The <i>--yaml</i> and <i>--toml</i> options allow switching the output format, which can be useful for enhanced readability or for integration with tools that prefer those formats.<br>The <i>--graph</i> output is always text-based, providing an ASCII art representation of the inventory structure, illustrating group nesting and host membership.


title: HISTORY
content:
<i>ansible-inventory</i> was introduced into the Ansible ecosystem to provide a dedicated and robust tool for inspecting and debugging Ansible inventories. Prior to its existence, inventory introspection was less comprehensive, often relying on simpler methods like <i>ansible --list-hosts</i> or custom scripting, which lacked the detailed variable resolution capabilities. Its development significantly streamlined inventory management and debugging workflows, making it an indispensable utility for Ansible users, especially when dealing with complex or dynamic inventory sources.


title: PARAMETERS
content:
<b><b>PATH</b>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to Ansible files (e.g., playbooks, roles, or directories) to lint. If no path is provided, it typically lints the current working directory.<br><br><b><b>-c</b> <i>CONFIG_FILE</i>, <b>--config-file</b> <i>CONFIG_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a YAML configuration file to override default settings and rule configurations. Common locations include <i>.ansible-lint</i> in the project root.<br><br><b><b>--fix</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to automatically fix detected issues. Not all issues can be fixed automatically, and manual review of changes is recommended.<br><br><b><b>-f</b> <i>FORMAT</i>, <b>--format</b> <i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Choose the output format for violations. Common options include <i>plain</i> (default), <i>json</i>, and <i>sarif</i> for integration with other tools.<br><br><b><b>--parseable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output violations in a machine-readable, parseable format, typically without additional decorative elements.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output except for violations. Useful in CI/CD environments where only errors need to be reported.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of output. Use multiple <b>-v</b> for more detailed debugging information (e.g., <b>-vvv</b>).<br><br><b><b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Return an exit code of 1 even if only warnings are found. By default, only errors cause a non-zero exit code.<br><br><b><b>--skip-list</b> <i>RULE_ID_LIST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of rule IDs to skip during the linting process. E.g., <b>--skip-list 201,305</b>.<br><br><b><b>--enable-list</b> <i>RULE_ID_LIST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of rule IDs to enable, even if they are generally disabled by default or via configuration.<br><br><b><b>--disable-list</b> <i>RULE_ID_LIST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of rule IDs to disable, overriding any configuration that might enable them.<br><br><b><b>--warn-list</b> <i>RULE_ID_LIST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of rule IDs that should be downgraded from errors to warnings.<br><br><b><b>-p</b> <i>PROJECT_DIR</i>, <b>--project-dir</b> <i>PROJECT_DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the project directory. This helps <b>ansible-lint</b> locate related files, roles, and collections.<br><br><b><b>--rules-dir</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify one or more directories containing custom linting rules. Can be specified multiple times.<br><br><b><b>--exclude</b> <i>EXCLUDE_PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specific paths or files from being linted. Can be specified multiple times.<br><br><b><b>--offline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not attempt to download collection schemas from the internet. Useful for environments with restricted network access.<br><br><b><b>--nocolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output. Useful when output is redirected to a file or in terminals that don't support color.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's version number and exit.<br><br>


title: DESCRIPTION
content:
<b>ansible-lint</b> is a command-line utility designed to help maintain and improve the quality of Ansible content, including playbooks, roles, and collections. It analyzes Ansible YAML files against a set of predefined rules and best practices, identifying potential errors, deprecated features, style inconsistencies, and security issues. <br><br>By enforcing coding standards, <b>ansible-lint</b> assists developers in writing more reliable, readable, and maintainable Ansible code. It provides actionable feedback, often with suggestions for remediation, and can even automatically fix some common issues using its <b>--fix</b> option. It's an invaluable tool for individual developers and highly beneficial when integrated into Continuous Integration/Continuous Delivery (CI/CD) pipelines to ensure code quality before deployment.


title: CAVEATS
content:
<b>ansible-lint</b> requires Python 3.8+ and needs to be installed via <b>pip</b>. While it is highly effective, it may sometimes produce false positives, or certain rules might not align with specific project conventions. In such cases, fine-tuning rule configurations, using skip lists, or developing custom rules is necessary. The <b>--fix</b> option should always be used with caution and its changes reviewed, as automatic fixes might not always align perfectly with desired code style or logic.


title: CONFIGURATION FILE USAGE
content:
<b>ansible-lint</b> can be configured using a YAML file, typically named <i>.ansible-lint</i>, located in the root of your Ansible project. This file allows you to define default rule lists (enable/disable/warn), specify custom rules directories, set verbosity, exclude paths, and more. This centralizes linting settings, making them consistent across a team or CI/CD pipelines. Alternatively, configuration can be specified in <i>pyproject.toml</i> under the <b>[tool.ansible-lint]</b> section.


title: CUSTOM RULES
content:
Users can extend <b>ansible-lint</b>'s capabilities by writing custom rules in Python. These rules allow organizations to enforce internal best practices or validate highly specific architectural patterns not covered by the default rule set. Custom rules are placed in a directory specified in the configuration file or via the <b>--rules-dir</b> option.


title: CI/CD INTEGRATION
content:
Due to its command-line interface and configurable exit codes, <b>ansible-lint</b> is perfectly suited for integration into CI/CD pipelines. It can be run as a pre-commit hook or as part of a build step to automatically check Ansible content for quality and compliance before merging code or deploying changes, ensuring a higher standard of code quality and reducing post-deployment issues.


title: HISTORY
content:
Initially developed as a community-driven project, <b>ansible-lint</b> has grown to become an essential part of the Ansible ecosystem, officially supported by Ansible project maintainers. Its evolution reflects the increasing demand for code quality, maintainability, and automated testing within the Ansible community. Over time, it has expanded its rule set, improved performance, and integrated more deeply with Ansible's internal structures, including support for Ansible collections and robust configuration options.


title: PARAMETERS
content:
<b><b>-i</b> <i>INVENTORY</i>, <b>--inventory=</b><i>INVENTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the Ansible inventory file or host list to target. This can be a file path, directory, or a comma-separated list of hosts.<br><br><b><b>-l</b> <i>SUBSET</i>, <b>--limit=</b><i>SUBSET</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Further limit the selected hosts to a specified group, host pattern, or individual host name within the inventory.<br><br><b><b>-f</b> <i>FORKS</i>, <b>--forks=</b><i>FORKS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of parallel processes (forks) to use for execution. The default value is typically 5.<br><br><b><b>-u</b> <i>REMOTE_USER</i>, <b>--user=</b><i>REMOTE_USER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to the remote host as this specified user.<br><br><b><b>-b</b>, <b>--become</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run operations with privilege escalation (e.g., using sudo or su) on the remote hosts.<br><br><b><b>-k</b>, <b>--ask-become-pass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for the privilege escalation password (e.g., sudo password) before execution.<br><br><b><b>-K</b>, <b>--ask-pass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ask for the connection password (e.g., SSH password) if SSH keys are not used or protected.<br><br><b><b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a 'dry run' of the playbook. It won't make any actual changes, but will report what would have happened.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When changing files or templates, show the differences (diffs) between the original and modified content.<br><br><b><b>--syntax-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a syntax check on the playbook(s) without executing any tasks. Useful for validating playbook structure early.<br><br><b><b>--list-hosts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all hosts that would be targeted by the playbook based on the inventory and limit parameters, without running tasks.<br><br><b><b>--list-tasks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all tasks that would be executed by the playbook, in the order they would run, without actual execution.<br><br><b><b>--start-at-task=</b><i>TASK_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Begin the playbook execution at a specific named task, skipping preceding tasks.<br><br><b><b>-v</b>, <b>-vv</b>, <b>-vvv</b>, <b>-vvvv</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity level of output. More 'v's provide progressively more detailed information for debugging.<br><br><b><b>-e</b> <i>EXTRA_VARS</i>, <b>--extra-vars=</b><i>EXTRA_VARS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set additional variables as key=value, @file.yml, or @file.json. These variables override others.<br><br><b><b>-t</b> <i>TAGS</i>, <b>--tags=</b><i>TAGS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only run plays and tasks that have the specified tags (comma-separated list).<br><br><b><b>--skip-tags=</b><i>SKIP_TAGS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip plays and tasks that have the specified tags (comma-separated list).<br><br><b><b>--flush-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear the fact cache before running the playbook. Useful when facts might be stale or need to be re-gathered.<br><br><b><b>--step</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Engage one-step-at-a-time interactive execution, prompting the user before each task runs.<br><br>


title: DESCRIPTION
content:
<i>ansible-playbook</i> is the primary command-line tool for running Ansible playbooks.<br>Playbooks are declarative YAML files that define a set of tasks to be executed on remote hosts or localhost. They serve as the blueprint for automating complex IT workflows, ranging from simple configuration changes to multi-tier application deployments and continuous delivery pipelines.<br><br>The command parses the specified playbook(s), connects to the hosts defined in the inventory, and executes tasks sequentially. It leverages SSH for communication (by default) and aims to ensure idempotency, meaning tasks can be run multiple times without causing unintended side effects. It's the core component of Ansible's powerful automation capabilities, enabling users to define, manage, and scale their infrastructure and applications as code.


title: CAVEATS
content:
While Ansible strives for idempotency, custom scripts or external commands called within playbooks might not always be inherently idempotent, potentially leading to unintended state changes if not carefully designed.<br>Ansible requires Python on both the control node (where <i>ansible-playbook</i> is executed) and the managed nodes (for running modules).<br>Reliable SSH connectivity between the control node and managed nodes is fundamental for <i>ansible-playbook</i> to function correctly.<br>Effective use of <i>ansible-playbook</i> necessitates a good understanding of YAML syntax for writing playbooks and Ansible's execution model.


title: PLAYBOOK STRUCTURE
content:
An Ansible playbook is a YAML file typically structured with one or more 'plays'. Each play defines a group of hosts (from the inventory) to target and a list of 'tasks' to execute on those hosts. Playbooks can also include sections for variables (<i>vars</i>), handlers (for executing tasks when notified), roles (reusable collections of content), and more, allowing for modular and highly reusable automation code.


title: IDEMPOTENCY PRINCIPLE
content:
A core principle of Ansible and <i>ansible-playbook</i> is idempotency. This means that executing a playbook multiple times should result in the same system state as executing it once, assuming no external factors interfere. Ansible modules are designed to check the current state of a system before making changes, only acting if the desired state is not met, thus ensuring consistency, preventing unnecessary modifications, and simplifying repeated deployments.


title: EXECUTION FLOW
content:
When <i>ansible-playbook</i> runs:<br>1. It parses the specified playbook(s) and the associated inventory.<br>2. For each play, it identifies the target hosts based on the 'hosts' directive and any applied limits.<br>3. It then typically gathers 'facts' (system information) about the remote hosts.<br>4. Tasks are executed sequentially on the target hosts. For each task, Ansible determines if a change is needed (due to idempotency) and executes the relevant module.<br>5. If a task signals that a change occurred, 'handlers' (special tasks that run only when notified) can be triggered at the end of the play or specific plays.


title: HISTORY
content:
Ansible was created by Michael DeHaan and first released in 2012, aiming to be a simpler, agentless automation engine compared to existing configuration management tools. Red Hat acquired Ansible in 2015. From its inception, <i>ansible-playbook</i> has been central to Ansible's design, providing a declarative, human-readable way to define IT automation workflows using YAML. Its popularity surged due to its agentless architecture (relying on SSH), ease of use, and strong focus on idempotency, which has made it a de-facto standard for infrastructure as code and orchestration.


title: SYNOPSIS
content:
<b>ansible-pull</b> [options] <b>--url</b> <i><repository_url></i> <b>--directory</b> <i><local_dir></i> [<i>playbook.yml</i>]


title: PARAMETERS
content:
<b><b>-U</b> <i><repository_url></i>, <b>--url</b> <i><repository_url></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the URL of the Git repository to pull configurations from. This is a mandatory option.<br><br><b><b>-d</b> <i><local_dir></i>, <b>--directory</b> <i><local_dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local directory where the Git repository will be cloned or updated. This is a mandatory option.<br><br><b><b>-i</b> <i><inventory></i>, <b>--inventory</b> <i><inventory></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the inventory file or hosts. For <i>ansible-pull</i>, it's typically 'localhost,' or a dynamically generated one.<br><br><b><b>-s</b> <i><sleep></i>, <b>--sleep</b> <i><sleep></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a random delay (in seconds, up to this value) before executing the playbook. Useful for cron jobs to prevent all clients hitting the Git repo simultaneously.<br><br><b><b>--checkout</b> <i><branch></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Git branch, tag, or commit hash to checkout from the repository. Defaults to the repository's default branch.<br><br><b><b>--accept-host-keys</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically accept new SSH host keys when cloning the repository. Use with caution in production environments.<br><br><b><b>--clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets any local modifications in the repository directory before pulling. Useful for ensuring a clean state.<br><br><b><b>--full-idempotence</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures that all tasks run, not just changed ones, for full idempotence checking. This is primarily for debugging.<br><br><b><b>--purge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Purges the entire local checkout directory before cloning the repository. Useful for starting fresh.<br><br><b><b>--verify-commit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the GPG signature of the latest commit before running the playbook. Requires a valid GPG setup.<br><br><b><b>--vault-password-file</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a file containing the Ansible Vault password.<br><br><b><b>--ask-vault-pass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts for the Ansible Vault password interactively. Less common for automated <i>ansible-pull</i> usage.<br><br><b><b>--private-key</b> <i><file></i>, <b>--key-file</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the SSH private key file to use for authenticating with the Git repository.<br><br><b><i>[playbook.yml]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional argument to specify the playbook file within the cloned repository to execute. Defaults to <i>main.yml</i> or <i>site.yml</i> if not provided.<br><br>


title: DESCRIPTION
content:
<i>ansible-pull</i> is an Ansible command-line utility designed for a decentralized, client-driven configuration management model. <br><br>Unlike the standard <i>ansible-playbook</i>, which operates in a 'push' mode from a central controller, <i>ansible-pull</i> reverses this dynamic. It enables managed nodes (clients) to fetch their configuration directly from a Git repository. This command clones or updates a specified Git repository on the local machine, then executes an <i>ansible-playbook</i> against 'localhost' using the content pulled from that repository. <br><br>This approach is particularly useful in scenarios where a central controller might not have direct SSH access to all managed nodes, such as dynamic cloud environments, large-scale deployments, or when managing IoT devices. It's commonly deployed as a cron job on the client machines, allowing them to periodically check for and apply updates. <i>ansible-pull</i> ensures that the configuration is idempotent, meaning it can be run multiple times without causing unintended side effects, only applying changes when necessary. It simplifies initial bootstrapping and ongoing maintenance by empowering nodes to manage their own configuration lifecycle from a version-controlled source.


title: CAVEATS
content:
<i>ansible-pull</i> requires <i>git</i> and <i>python</i> to be installed on the client machines. <br><br>Security is a key concern: ensure secure handling of Git repository access credentials (SSH keys or HTTPS tokens) on client systems, especially for private repositories. Managing Ansible Vault passwords on client machines also requires careful consideration. <br><br>Visibility and debugging can be more challenging compared to the push model, as logs and command output are local to the client. Centralized logging solutions or Ansible callback plugins are often needed to aggregate results.


title: TYPICAL WORKFLOW
content:
A common use case involves scheduling <i>ansible-pull</i> as a cron job on target machines (e.g., hourly). The command pulls the latest playbook from a Git repository and executes it against 'localhost'. This ensures machines are always up-to-date with the desired configuration defined in the central repository, without requiring a constant connection from a central Ansible control node.


title: AUTHENTICATION
content:
For private Git repositories, clients need appropriate authentication. This typically involves SSH keys (often an agent-forwarded key or a key stored directly on the client, protected with proper permissions) or HTTPS credentials. For HTTPS, personal access tokens are generally preferred over usernames and passwords.


title: ERROR HANDLING & LOGGING
content:
Since <i>ansible-pull</i> runs locally on the client, managing output and errors is crucial. Output can be redirected to a log file. For centralized reporting, Ansible callback plugins can be configured to send execution results, failures, or changes to a monitoring system, syslog, or a log aggregation service.


title: HISTORY
content:
<i>ansible-pull</i> was introduced relatively early in Ansible's development lifecycle to address the need for a decentralized, client-driven configuration management model. It provided a solution for scenarios where the traditional 'push' model wasn't suitable, such as managing cloud instances behind NATs or large-scale, dynamic environments where direct SSH access from a central controller is impractical or undesirable. Its core functionality has remained consistent, evolving alongside Ansible's general features and options.


title: SYNOPSIS
content:
<i>ansible-vault</i> <i>action</i> [<i>options</i>] <i>file</i> [<i>file</i> ...]<br><br><b>Common Actions:</b><br><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> create [--vault-id <i>id</i>] <i>file</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> edit [--vault-id <i>id</i>] <i>file</i><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> encrypt [--vault-id <i>id</i>] <i>file</i> [<i>file</i> ...]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> decrypt <i>file</i> [<i>file</i> ...]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> rekey [--new-vault-id <i>id</i>] <i>file</i> [<i>file</i> ...]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> view <i>file</i> [<i>file</i> ...]<br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ansible-vault</i> encrypt_string [--name <i>variable_name</i>] [--encrypt-vault-id <i>id</i>] <i>string</i>


title: PARAMETERS
content:
<b>--vault-password-file <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing the vault password(s). This is a secure way to provide passwords programmatically.<br><br><b>--vault-id <i>id</i>[@<i>path</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a vault ID, optionally linked to a password file. This allows managing multiple vaults with different passwords.<br><br><b>--ask-vault-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt for the vault password interactively at the command line.<br><br><b>--new-vault-password-file <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'rekey' action to specify a file containing the new vault password.<br><br><b>--ask-new-vault-pass</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'rekey' action to prompt for the new vault password interactively.<br><br><b>--output <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write command output to the specified file instead of standard output.<br><br><b>--encrypt-vault-id <i>id</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'encrypt_string' to specify which vault ID to use for encryption.<br><br><b>--name <i>variable_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'encrypt_string' to output the encrypted string as a YAML variable with the given name.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without making actual changes (primarily for 'rekey' action).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output. Use multiple '-v' (e.g., -vvv) for more detailed debugging information.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>ansible-vault</i> is a command-line utility for Ansible that facilitates the secure storage and management of sensitive information such as passwords, API keys, and other confidential data. It allows you to encrypt files or strings within your Ansible projects, making it safe to commit them to version control systems like Git. When Ansible executes playbooks, it can automatically decrypt vaulted content on the fly, provided the correct vault password. This tool uses AES256 encryption and supports various actions, including creating new encrypted files, editing existing ones, encrypting or decrypting arbitrary files or strings, viewing content without permanent decryption, and rekeying (changing) vault passwords. It is an essential component for maintaining security best practices in Ansible automation.


title: CAVEATS
content:
<b>Password Management:</b> The security of your vaulted data is entirely dependent on the vault password. It is critical to manage this password securely, avoiding hardcoding it directly in scripts or exposing it in logs.<br><br><b>No Partial Decryption:</b> <i>ansible-vault</i> encrypts entire files. You cannot decrypt or access only a portion of an encrypted file; the entire file must be decrypted.<br><br><b>Editor Integration:</b> When using <i>ansible-vault edit</i>, the command invokes your default text editor (controlled by the EDITOR environment variable). Ensure this editor is configured securely and that temporary files created during editing are handled properly to prevent accidental data exposure.


title: MULTIPLE VAULTS AND VAULT IDS
content:
Ansible 2.4 introduced support for managing multiple vault passwords using the <i>--vault-id</i> option or the <i>ANSIBLE_VAULT_IDENTITY_LIST</i> environment variable. This feature allows users to organize sensitive data into different 'vaults,' each secured by a unique password. For example, you can have separate vaults for development, staging, and production environments, each with its own access credentials.


title: <I>ENCRYPT_STRING</I> FOR AD-HOC ENCRYPTION
content:
The <i>encrypt_string</i> action is particularly useful for encrypting small, single pieces of sensitive data (like a specific password or API key) directly into a YAML file, rather than encrypting an entire file. This eliminates the need for separate vault files for every small secret, making it convenient for embedding sensitive variables directly within variable files (e.g., <i>group_vars</i> or <i>host_vars</i>) or even playbooks.


title: INTEGRATION WITH <I>ANSIBLE.CFG</I>
content:
Default vault password files or vault IDs can be configured in the <i>ansible.cfg</i> file. This allows users to set up a primary vault password file or specific vault identities that Ansible will automatically use, reducing the need to specify them on the command line for every operation.


title: HISTORY
content:
<i>ansible-vault</i> was introduced in Ansible 1.5 (released February 2014), marking a significant enhancement to Ansible's security capabilities. Prior to its existence, users often resorted to less secure methods for handling sensitive data within their automation projects. Its development addressed a critical need for securely storing credentials and other confidential information directly within Ansible codebases, thereby allowing projects to be safely committed to version control systems. Subsequent Ansible versions have improved <i>ansible-vault</i>'s functionality, most notably with the introduction of multiple vault IDs in Ansible 2.4, which allows for more granular control and management of different sets of sensitive data with distinct passwords.


title: PARAMETERS
content:
<b><b>--location</b> <I>LOCATION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the geographical location for weather data (e.g., <I>London,GB</I>, <I>90210,US</I>, <I>34.05,-118.25</I>).<br><br><b><b>--units</b> <I>UNITS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the unit system for temperature and wind: <I>metric</I>, <I>imperial</I>, or <I>kelvin</I>.<br><br><b><b>--language</b> <I>LANG_CODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display language (e.g., <I>en</I> for English, <I>fr</I> for French).<br><br><b><b>--display</b> <I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls which weather elements are displayed. <I>MODE</I> can be <I>basic</I>, <I>forecast</I>, <I>full</I>, <I>alert</I>, or a comma-separated list of elements (e.g., <I>temp,humidity</I>).<br><br><b><b>--apikey</b> <I>API_KEY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the OpenWeatherMap API key directly as a command-line argument.<br><br><b><b>--config</b> <I>FILE_PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file path instead of the default.<br><br><b><b>--forecast-days</b> <I>DAYS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of days for the weather forecast (typically 1-5 days).<br><br><b><b>--symbols</b> <I>true|false</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables the use of Unicode symbols in the output.<br><br><b><b>--colors</b> <I>true|false</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables ANSI colors in the output.<br><br><b><b>--output</b> <I>FORMAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format (e.g., <I>plain</I> for no ANSI codes, <I>ansi</I> for default).<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays additional debug information, useful for troubleshooting.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>ansiweather</b> version information and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and exits.<br><br>


title: DESCRIPTION
content:
<b>ansiweather</b> is a lightweight command-line tool that fetches and displays current weather conditions and forecasts directly in your terminal. Written as a shell script, it utilizes the OpenWeatherMap API to retrieve data, presenting it with colorful ANSI escape codes and Unicode symbols for an aesthetically pleasing and easily readable output. Users can customize the location, units (metric or imperial), language, and specific information displayed (e.g., temperature, humidity, wind). It's popular for quick weather checks, often integrated into shell prompts or status bars. An OpenWeatherMap API key is required and can be configured via a file or command-line argument.


title: CAVEATS
content:
<I><b>API Key Requirement</b></I>: <b>ansiweather</b> requires a free OpenWeatherMap API key, which must be obtained from their website and properly configured. Free tier keys have rate limits.<br><I><b>External Dependency</b></I>: The command relies entirely on the OpenWeatherMap API; functionality ceases if the API is unreachable, down, or if the API key is invalid.<br><I><b>Terminal Support</b></I>: Optimal display of ANSI colors and Unicode symbols depends on the capabilities of your terminal emulator and the fonts installed on your system.


title: CONFIGURATION FILE
content:
<b>ansiweather</b> typically reads its default settings from a configuration file, commonly located at <I>~/.config/ansiweather/config</I> or <I>~/.ansiweather.conf</I>. This file allows users to set persistent options such as the API key, default location, and preferred units, reducing the need for repetitive command-line arguments during daily use.


title: API KEY SETUP
content:
To enable <b>ansiweather</b> to fetch weather data, users must register at the OpenWeatherMap website to obtain a free API key. This key then needs to be placed into the <b>ansiweather</b> configuration file (e.g., by setting <I>API_KEY="your_key_here"</I>) or provided directly with each invocation using the <b>--apikey</b> option. Without a valid and active API key, <b>ansiweather</b> cannot retrieve weather information.


title: HISTORY
content:
<b>ansiweather</b> was developed by <I>fcambus</I> as an open-source shell script. Its creation aimed to offer a simple, visually appealing method for displaying weather in the terminal. Leveraging existing shell features and the OpenWeatherMap API, it quickly became popular among command-line users for its customizability and low resource usage, commonly integrated into shell startup files like <I>.bashrc</I> or <I>.zshrc</I>.


title: SEE ALSO
content:
<b>curl</b>(1): Common tool for transferring data with URLs, often used internally by <b>ansiweather</b> to fetch API data., <b>jq</b>(1): A lightweight and flexible command-line JSON processor, frequently used for parsing API responses., <b>wttr.in</b>: A web service providing weather information directly in the terminal, accessible via <b>curl</b>.


title: PARAMETERS
content:
<b><I>-buildfile <file></I>, <I>-f <file></I>, <I>-file <file></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified buildfile.<br><br><b><I>-D<property>=<value></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the given value for the specified property.<br><br><b><I>-find <file></I>, <I>-s <file></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search upwards from the current directory for the specified buildfile.<br><br><b><I>-help</I>, <I>-h</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print help message and exit.<br><br><b><I>-listener <classname></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an instance of a ProjectListener.<br><br><b><I>-logger <classname></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The class to use for logging build events.<br><br><b><I>-lib <path></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a path to search for JAR files and classes to extend Ant.<br><br><b><I>-projecthelp</I>, <I>-p</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print project help information, listing available targets.<br><br><b><I>-version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the Ant version information and exit.<br><br><b><I>-verbose</I>, <I>-v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print extra verbose messages during the build.<br><br><b><I>-debug</I>, <I>-d</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print debugging messages.<br><br><b><I>-quiet</I>, <I>-q</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print less messages during the build.<br><br><b><I>-emacs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce logging information without adornments, suitable for Emacs parser.<br><br><b><I>-keep-going</I>, <I>-k</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute all targets that do not depend on failed targets, even if some targets fail.<br><br>


title: DESCRIPTION
content:
Apache <B>Ant</B> is an open-source, Java-based build automation tool. It automates the software build process, primarily for Java projects, by compiling source code, packaging binaries (JARs, WARs), deploying applications, and running tests. <B>Ant</B> uses XML files, typically named <I>build.xml</I>, to define build targets and tasks. Each task represents a specific action (e.g., <I>&lt;javac&gt;</I> for compilation, <I>&lt;jar&gt;</I> for packaging).<br><br>Unlike <B>make</B>, <B>Ant</B> is platform-independent because it is written in Java and uses Java classes for its tasks. Its flexibility allows developers to define custom tasks, making it highly extensible. <B>Ant</B> works by executing specified targets, which are collections of tasks. It resolves dependencies between targets, ensuring tasks are executed in the correct order. While newer build tools like <B>Maven</B> and <B>Gradle</B> have gained popularity, <B>Ant</B> remains widely used, especially for legacy projects or when fine-grained control over the build process is required.


title: CAVEATS
content:
<ul><li>Requires a Java Development Kit (JDK) to be installed and configured on the system.</li><li>Build files are XML-based, which can become verbose and complex for large projects compared to convention-over-configuration tools.</li><li>Lacks built-in dependency management, requiring explicit handling or reliance on external tools/extensions.</li><li>Error messages can sometimes be cryptic, requiring detailed logging or debugging to understand the root cause.</li></ul>


title: BUILDFILE STRUCTURE
content:
An Ant build is defined in an XML file, conventionally named <I>build.xml</I> (though configurable via <I>-buildfile</I>). The root element is <I>&lt;project&gt;</I>, which typically contains attributes like <I>name</I>, <I>default</I> target, and <I>basedir</I>. Inside the project, you define <I>&lt;target&gt;</I> elements. Each <I>&lt;target&gt;</I> defines a sequence of <I>&lt;task&gt;</I> elements to be executed (e.g., <I>&lt;javac&gt;</I>, <I>&lt;copy&gt;</I>, <I>&lt;jar&gt;</I>). Targets can declare dependencies on other targets using the <I>depends</I> attribute, ensuring a specific execution order. Properties can be defined using <I>&lt;property&gt;</I> to hold values (e.g., paths, version numbers) that can be reused throughout the build file, enhancing flexibility and maintainability.


title: HISTORY
content:
Apache <B>Ant</B> originated in early 2000 as a replacement for <B>make</B> in the Apache Tomcat project, aiming to overcome <B>make</B>'s platform-specific issues and command-line shell dependencies. Written entirely in Java, <B>Ant</B> achieved platform independence, a significant advantage for Java development. Its adoption grew rapidly within the Java community due to its flexibility, extensibility through custom tasks, and the ability to define complex build processes using XML.<br><br>While <B>Maven</B> (introduced in 2004) and <B>Gradle</B> (introduced in 2007) later emerged offering convention-over-configuration and integrated dependency management, <B>Ant</B> continues to be maintained and used, especially for legacy projects or scenarios requiring highly customized build logic where fine-grained control is paramount.


title: SYNOPSIS
content:
<b>antibody</b> <i>[global-options]</i> <b>&lt;command&gt;</b> <i>[command-options]</i> <i>[arguments]</i><br><br><b>Common Commands:</b><br><b>antibody bundle</b> <i>&lt;plugin-source&gt;</i>...<br><b>antibody init</b><br><b>antibody update</b><br><b>antibody help</b> <i>[command]</i>


title: PARAMETERS
content:
<b><b>bundle</b> <i>&lt;plugin-source&gt;</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads one or more plugins. This command is typically placed in your <b>.zshrc</b> file. <i>&lt;plugin-source&gt;</i> can be a GitHub repo (e.g., <i>'zsh-users/zsh-autosuggestions'</i>), a Gist ID, or a local path.<br><br><b><b>init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates the Zsh initialization script based on the plugins specified by <b>bundle</b> commands. This script is usually evaluated in your <b>.zshrc</b> (e.g., <i>'eval "$(antibody init)"'</i>).<br><br><b><b>update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates all currently installed plugins to their latest versions from their respective sources.<br><br><b><b>home</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the path to the directory where Antibody stores its cloned plugins.<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all plugins currently managed and installed by Antibody.<br><br><b><b>help</b> <i>[command]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows help information for the <b>antibody</b> command itself or for a specific subcommand.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the overall help message for Antibody (global option).<br><br><b><i>-v</i>, <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of Antibody (global option).<br><br><b><i>-q</i>, <i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output during command execution (global option).<br><br>


title: DESCRIPTION
content:
Antibody is a lightweight and performant Zsh plugin manager designed to significantly reduce shell startup times. Inspired by `antigen`, it distinguishes itself by focusing on speed through asynchronous plugin loading. Instead of sourcing each plugin sequentially, Antibody fetches and initializes them in parallel, allowing your Zsh shell to become interactive much quicker. Users define their desired plugins, themes, and completions in their `.zshrc` file using a straightforward syntax, typically referencing GitHub repositories (e.g., `robbyrussell/oh-my-zsh/themes/robbyrussell.zsh-theme`). Antibody automatically handles cloning these resources to a local cache, updating them, and generating the necessary initialization script for Zsh. It supports various plugin sources, including GitHub repositories, Gist snippets, and local paths. Its minimalistic approach and emphasis on performance make it a popular choice for Zsh users who prioritize a snappy command-line experience.


title: CAVEATS
content:
Antibody is <i>not</i> a standard Linux system command; it must be installed separately. It is specifically designed for the <b>Zsh</b> shell and will not function with Bash, Fish, or other shells. It relies on the <b>git</b> command for cloning repositories and requires internet connectivity for fetching remote plugins. Performance benefits are most noticeable with a large number of plugins.


title: INSTALLATION
content:
Antibody is typically installed by piping a script from GitHub directly into your shell or by manually downloading the binary. A common installation method involves: <br><i>'curl -sL git.io/antibody | sh -s -- -b /usr/local/bin'</i> <br>This fetches the latest release and installs the <b>antibody</b> binary to <i>/usr/local/bin</i> or another specified path.


title: TYPICAL USAGE IN <I>.ZSHRC</I>
content:
After installation, you configure Antibody in your <b>~/.zshrc</b> file. A basic setup looks like this:<br><br><i># List your plugins<br>antibody bundle zsh-users/zsh-autosuggestions<br>antibody bundle zsh-users/zsh-syntax-highlighting<br>antibody bundle robbyrussell/oh-my-zsh/themes/robbyrussell.zsh-theme<br><br># Initialize antibody<br>eval "$(antibody init)"</i><br><br>This structure ensures that plugins are loaded efficiently when your Zsh shell starts.


title: HISTORY
content:
Antibody emerged as a response to the perceived overhead of existing Zsh plugin managers, particularly concerning shell startup times. It was initially developed by <i>caarlos0</i> (Carlos Alexandro Becker) and later moved to the <i>getantibody</i> organization. The primary motivation was to create a simpler, faster, and more robust solution for managing Zsh plugins by leveraging asynchronous operations. Its development focused on minimizing dependencies and streamlining the plugin loading process, leading to its adoption by Zsh users who prioritize a highly responsive shell environment.


title: PARAMETERS
content:
<b><I>input_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input image file. If omitted, <B>anytopnm</B> reads image data from standard input (<I>stdin</I>). The file format will be automatically detected.<br><br><b><I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any options specified on the command line are not processed by <B>anytopnm</B> itself, but are passed directly to the specific image converter program (e.g., <B>jpegtopnm</B>, <B>pngtopnm</B>) that <B>anytopnm</B> automatically selects based on the input file format. Refer to the manual pages of individual <B>*to*pnm</B> converters for their specific options.<br><br>


title: DESCRIPTION
content:
<B>anytopnm</B> is a powerful front-end utility from the Netpbm package designed to convert various image formats into the standard Netpbm (Portable Anymap) format. It acts as a universal adapter, automatically detecting the input file's format (e.g., JPEG, PNG, GIF, TIFF, XBM) and piping it through the appropriate specific Netpbm converter (like <B>jpegtopnm</B>, <B>pngtopnm</B>, <B>giftoppm</B>, etc.).<br><br>This automatic detection makes <B>anytopnm</B> incredibly convenient when you are unsure of the input image's exact format or when dealing with a mix of formats. It reads the input image either from a specified file or from standard input, and always writes the resulting PNM (Portable Pixmap, Greymap, or Bitmap) data to standard output. While <B>anytopnm</B> itself has no command-line options, it intelligently passes any options you provide to the underlying specific converter, allowing for flexible control over the conversion process.


title: CAVEATS
content:
<I><B>Format Detection:</B></I> <B>anytopnm</B> relies on 'magic numbers' within the file content or on the filename extension to identify the format. If detection fails, it may default to interpreting the input as a Netpbm image, which can lead to errors for other formats.<br><br><I><B>Limited Support:</B></I> It only supports formats for which a corresponding <B>*to*pnm</B> converter is installed and available in the system's PATH. It does not recognize every possible image format.<br><br><I><B>Output Fixed to PNM:</B></I> The output format is always PNM (PBM, PGM, or PPM). It cannot convert to other non-Netpbm formats directly.<br><br><I><B>Error Handling:</B></I> Error messages can sometimes be cryptic as they may originate from the underlying converter.


title: HOW IT WORKS
content:
<B>anytopnm</B> operates by first attempting to identify the input image's format. It does this by checking a 'magic number' (a unique byte sequence) at the beginning of the file, or by examining the filename extension. Once the format is identified, it dynamically constructs a command, typically piping the input file through the appropriate specialized Netpbm converter (e.g., <B>cat image.jpg | jpegtopnm</B>) and then sends the PNM output to standard output. This mechanism allows <B>anytopnm</B> to efficiently handle various formats without needing to implement all conversion logic itself.


title: OUTPUT FORMAT
content:
Regardless of the input image format, <B>anytopnm</B> always produces output in one of the Netpbm formats: Portable Pixmap (<B>PPM</B> for color images), Portable Greymap (<B>PGM</B> for grayscale images), or Portable Bitmap (<B>PBM</B> for black and white images). The specific PNM variant depends on the color depth and content of the input image. These PNM formats are simple, uncompressed, and widely used as an intermediate format within the Netpbm suite for further processing with other tools.


title: HISTORY
content:
<B>anytopnm</B> is a core component of the Netpbm project, a venerable suite of graphics utilities dating back to the late 1980s. Its development arose from the need to simplify image format conversions within scripting environments. Instead of requiring users to manually determine and invoke the correct converter (e.g., <B>giftoppm</B> for GIF, <B>jpegtopnm</B> for JPEG), <B>anytopnm</B> was created to automate this process. It represents an abstraction layer over a large collection of specialized Netpbm converters, embodying the Unix philosophy of small, specialized tools working together. This design has made it a stable and widely used utility for interoperability between diverse image formats in command-line workflows.


title: SEE ALSO
content:
pnm(5), ppm(1), pbm(1), pgm(1), netpbm(1), jpegtopnm(1), pngtopnm(1), giftoppm(1), tifftopnm(1), xbmtopbm(1), xpmtoppm(1)


title: SYNOPSIS
content:
<br><b>apache2</b> [<i>options</i>]<br><br><i>Common management via scripts:</i><br><b>apache2ctl</b> [<i>start</i>|<i>stop</i>|<i>restart</i>|<i>graceful</i>|<i>configtest</i>|<i>status</i>|...]<br><b>systemctl</b> [<i>start</i>|<i>stop</i>|<i>restart</i>|<i>reload</i>|<i>status</i>] <b>apache2</b>


title: PARAMETERS
content:
<b><b>-D</b> <i>parameter</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a <i>parameter</i> to be used with <I>&lt;IfDefine&gt;</I> directives in the configuration file.<br><br><b><b>-f</b> <i>configfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate primary configuration file to use instead of the default (<I>apache2.conf</I>).<br><br><b><b>-C</b> "<i>directive</i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes a configuration <i>directive</i> before reading the primary configuration file.<br><br><b><b>-c</b> "<i>directive</i>"</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes a configuration <i>directive</i> after reading the primary configuration file.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version and build parameters of the Apache HTTP Server and exits.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version number of the Apache HTTP Server and exits.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a syntax test on the configuration files to check for errors.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the parsed settings for virtual hosts. Useful for debugging configuration issues.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available directives and their valid locations.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all modules compiled into the server.<br><br><b><b>-T</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all modules loaded by the server, including dynamically loaded ones.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs Apache in single-process debug mode, typically for development or troubleshooting.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message with available command-line options.<br><br>


title: DESCRIPTION
content:
The <b>apache2</b> command typically refers to the Apache HTTP Server daemon, a powerful, open-source, and widely used web server. It's designed to serve web content, such as HTML pages, images, and other files, over the HTTP and HTTPS protocols. While <b>apache2</b> is the name of the main executable that runs the server, direct invocation of this command is less common for routine management in modern Linux systems. Instead, administrators primarily interact with the Apache service through wrapper scripts like <b>apache2ctl</b> or the system's service manager, <b>systemctl</b>. Apache is known for its modular architecture, allowing administrators to enable or disable functionalities like SSL/TLS encryption, virtual hosting, URL rewriting, proxying, and various authentication methods by loading specific modules. Its flexibility, stability, and extensive feature set have made it a cornerstone of the internet's infrastructure, powering a vast number of websites and web applications globally. It handles concurrent connections efficiently, making it suitable for both small personal sites and large enterprise environments.


title: CAVEATS
content:
The <b>apache2</b> command, while being the daemon executable, is typically not invoked directly for daily server management. Doing so bypasses proper process control and environment setup handled by <I>apache2ctl</I> or <I>systemctl</I>. Running <b>apache2</b> directly might also leave orphaned processes or fail to load necessary modules and configurations correctly, leading to unexpected behavior. Always prefer using the provided service management scripts for starting, stopping, reloading, or testing the server in production environments. Pay close attention to file permissions for configuration files, log files, and web root directories, as incorrect permissions can lead to security vulnerabilities or server failures.


title: SERVICE MANAGEMENT
content:
While <b>apache2</b> is the daemon executable, its lifecycle (start, stop, restart, reload) is typically managed using <b>apache2ctl</b>, a control script, or the system's service manager, <b>systemctl</b>. For example, to restart Apache: <br><i>sudo systemctl restart apache2</i><br>or<br><i>sudo apache2ctl restart</i><br>These methods ensure proper daemonization, logging, and process handling.


title: CONFIGURATION FILES
content:
The primary configuration file is usually <I>/etc/apache2/apache2.conf</I>. <br>Other important directories include:<br><b>/etc/apache2/ports.conf</b>: Defines listening ports.<br><b>/etc/apache2/mods-available/</b> and <b>/etc/apache2/mods-enabled/</b>: For managing Apache modules.<br><b>/etc/apache2/sites-available/</b> and <b>/etc/apache2/sites-enabled/</b>: For defining virtual hosts.


title: HISTORY
content:
The Apache HTTP Server project began in 1995 when a group of developers created a patch set for the NCSA HTTPd server, leading to the name "A PAtCHy server" or Apache. It quickly evolved, with Apache 1.0 released in 1995. By the late 1990s, Apache had become the dominant web server on the internet, surpassing its NCSA predecessor and other competitors. The Apache Software Foundation was formed in 1999 to oversee its development and other open-source projects. Apache 2.0, released in 2002, represented a significant rewrite, introducing a new architecture (MPM - Multi-Processing Modules), better support for non-Unix operating systems, and improved performance. The "apache2" command name is primarily used in Debian-based distributions (like Ubuntu) to denote the Apache 2.x series, whereas Red Hat-based distributions often retain "httpd" for the daemon name. Its development has consistently focused on stability, security, and modularity, maintaining its position as a leading web server.


title: SEE ALSO
content:
<b>apache2ctl</b>(8), <b>systemctl</b>(1), <b>httpd</b>(8), <b>a2enmod</b>(8), <b>a2dismod</b>(8), <b>a2ensite</b>(8), <b>a2dissite</b>(8), <b>netstat</b>(8), <b>ss</b>(8)


title: SYNOPSIS
content:
<I>apache2ctl</I> [<B>command</B>] [<I>arguments</I>...]<br><I>apache2ctl</I> [<B>option</B>] [<I>arguments</I>...]


title: PARAMETERS
content:
<b><B>start</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Apache HTTP Server daemon.<br><br><b><B>stop</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the Apache HTTP Server daemon.<br><br><b><B>restart</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops and then starts the Apache HTTP Server daemon.<br><br><b><B>graceful</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gracefully restarts the Apache HTTP Server daemon. This allows current connections to complete before the server reloads its configuration and restarts child processes.<br><br><b><B>configtest</B> or <B>-t</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tests the Apache configuration files (e.g., <I>apache2.conf</I>) for syntax errors. This is crucial before restarting a production server to prevent downtime due to configuration issues.<br><br><b><B>status</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise server status report. This typically requires the <I>mod_status</I> module to be enabled and a text-based web browser like <I>lynx</I> or <I>w3m</I> to be installed.<br><br><b><B>fullstatus</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a detailed server status report, including information about individual workers and requests. Similar to <B>status</B>, it requires <I>mod_status</I> and a text-based web browser.<br><br><b><B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Apache version number and build date.<br><br><b><B>-V</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Apache version number along with a comprehensive list of compile-time settings and installed modules.<br><br><b><B>-S</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows compiled-in settings and a parsed list of virtual host configurations, useful for debugging setup issues.<br><br><b><B>-D</B> <I>DEFINE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a <I>DEFINE</I> parameter to the underlying <I>httpd</I> binary. This is often used for conditional configuration directives in Apache configuration files.<br><br><b><B>-f</B> <I>configfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative main server configuration file to use instead of the default. This is useful for testing or running multiple instances.<br><br><b><B>-k</B> <I>signal</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a specific signal to the <I>httpd</I> daemon. Common signals include <I>start</I>, <I>stop</I>, <I>restart</I>, <I>graceful</I>, and <I>graceful-stop</I>.<br><br>


title: DESCRIPTION
content:
<I>apache2ctl</I> is a front-end command-line utility designed to simplify the administration of the Apache HTTP Server. It acts as a wrapper for the underlying <I>httpd</I> binary, providing a convenient and standardized interface for managing the server's lifecycle. Administrators use <I>apache2ctl</I> to perform essential tasks such as starting, stopping, restarting, or gracefully reloading the Apache daemon. It also includes functions for testing the server's configuration files for syntax errors (<I>configtest</I> or <I>-t</I>) and displaying server status information. By abstracting the complexities of direct <I>httpd</I> invocation, <I>apache2ctl</I> ensures that necessary environment variables are set and proper signals are sent, making server management more robust and user-friendly across various Unix-like operating systems. It often works in conjunction with system-specific init scripts or systemd units, which might call <I>apache2ctl</I> internally to manage the Apache service.


title: CAVEATS
content:
Most <I>apache2ctl</I> commands that interact with the running daemon (e.g., <B>start</B>, <B>stop</B>, <B>restart</B>, <B>graceful</B>) require root privileges, especially if Apache is configured to listen on privileged ports (like 80 or 443).<br>The <B>status</B> and <B>fullstatus</B> commands rely on the <I>mod_status</I> module being enabled and properly configured in your Apache setup, and often require a text-based web browser like <I>lynx</I> or <I>w3m</I> to be installed on the system. Modern Linux distributions increasingly use <I>systemd</I> (with <B>systemctl</B>) or <I>SysVinit</I> (with <B>service</B>) as the primary method for managing daemons, which may internally call <I>apache2ctl</I> but provide a more standardized interface.


title: WRAPPER SCRIPT
content:
<I>apache2ctl</I> is fundamentally a shell script that translates user commands into appropriate calls to the core <I>httpd</I> binary, handling pathing, environment variables, and signal sending automatically. This abstraction simplifies complex <I>httpd</I> command-line invocations and ensures consistency.


title: ENVIRONMENT VARIABLES
content:
The behavior of <I>apache2ctl</I> can be influenced by several environment variables, such as <B>APACHE_HTTPD_CONF_FILE</B> (to specify an alternate configuration file), <B>APACHE_PID_FILE</B> (to specify the PID file location), <B>APACHE_RUN_DIR</B>, <B>APACHE_LOCK_DIR</B>, and <B>APACHE_LOG_DIR</B> (to specify various directory paths). These variables are often configured within the <I>apache2ctl</I> script itself or in system-wide environment files.


title: DISTRIBUTION DIFFERENCES
content:
As mentioned, <I>apache2ctl</I> is commonly found on Debian/Ubuntu systems, while <I>apachectl</I> is the name used by most other distributions and the Apache upstream project. Functionally, they are identical; the difference is purely in naming due to package conventions and adherence to distribution-specific naming schemes.


title: HISTORY
content:
<I>apache2ctl</I> is specific to Debian/Ubuntu-based distributions where the Apache HTTP Server package is named <I>apache2</I>. In most other distributions (e.g., Fedora, CentOS) and in the upstream Apache HTTP Server documentation, the corresponding control script is named <I>apachectl</I>. Both scripts serve the same purpose: to provide a convenient front-end for the <I>httpd</I> binary. This utility predates modern service managers like <I>systemd</I> and was historically the primary method for administrators to manage the Apache server's lifecycle on Unix-like systems. It continues to be available for backward compatibility and direct server management.


title: SYNOPSIS
content:
<b>apachectl</b> <i>[command]</i><br><b>apachectl</b> <i>[command] [arguments]</i><br><b>apachectl</b> <i>[option] [arguments]</i>


title: PARAMETERS
content:
<b><b>start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Apache HTTP Server.<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the Apache HTTP Server.<br><br><b><b>restart</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a full restart of the Apache HTTP Server. It stops and then starts the daemon, potentially causing a brief service interruption.<br><br><b><b>graceful</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a graceful restart. New requests are handled by the new server processes, while old processes are allowed to finish their current requests before exiting. This minimizes downtime.<br><br><b><b>graceful-stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a graceful shutdown. New connections are refused, and existing connections are allowed to complete.<br><br><b><b>configtest</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the syntax of the Apache configuration files (<i>httpd.conf</i>) without starting or restarting the server. Essential for verifying configuration changes before applying them.<br><br><b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief summary of the server's status. Requires <i>mod_status</i> to be enabled and configured, and a text-based browser like <i>lynx</i> or <i>w3m</i>.<br><br><b><b>fullstatus</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a detailed status report, including individual request information. Similar requirements to <i>status</i>.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of available <i>apachectl</i> commands.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Apache HTTP Server version information.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>httpd</i> server's version and compile settings (similar to <i>httpd -V</i>).<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a syntax test of the configuration files (equivalent to <i>configtest</i>).<br><br><b><b>-D <i>DEFINE</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes a define variable to the <i>httpd</i> server.<br><br><b><b>-f <i>configfile</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative server configuration file to use instead of the default.<br><br><b><b>-C <i>directive</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes a configuration <i>directive</i> before reading the main configuration files.<br><br><b><b>-c <i>directive</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes a configuration <i>directive</i> after reading the main configuration files.<br><br>


title: DESCRIPTION
content:
<i>apachectl</i> is a front-end control script for the Apache HTTP Server (<i>httpd</i> daemon). It provides an easy-to-use command-line interface to manage common Apache operations, such as starting, stopping, restarting, and checking the configuration.<br><br>While it wraps calls to the underlying <i>httpd</i> binary, it often includes additional logic for environment setup, configuration file location, and error handling, making it more robust than directly invoking <i>httpd</i> commands. It is widely used in traditional init.d scripts and, in some setups, even by modern <i>systemd</i> service files to manage the Apache service lifecycle. Its primary purpose is to simplify server administration and ensure proper shutdown and startup sequences.


title: CAVEATS
content:
Most <i>apachectl</i> operations that modify the server's state (start, stop, restart) require root privileges.<br>The <i>status</i> and <i>fullstatus</i> commands rely on the <i>mod_status</i> module being enabled and correctly configured in Apache's <i>httpd.conf</i>, along with the availability of a text-based web browser like <i>lynx</i> or <i>w3m</i> on the system.<br>On modern Linux distributions, <i>systemctl</i> is the preferred method for managing services. While <i>apachectl</i> still functions, <i>systemctl start httpd</i> (or <i>apache2</i>) is often the standard and recommended approach, as the <i>systemd</i> service unit may internally call <i>apachectl</i> or handle the daemon directly.


title: BEST PRACTICE: CONFIGURATION TESTING
content:
Always run <i>apachectl configtest</i> (or <i>apachectl -t</i>) after making any changes to your Apache configuration files and before attempting a <i>restart</i> or <i>graceful</i> restart. This prevents the server from failing to start due to syntax errors, potentially causing downtime.


title: SYSTEMD INTEGRATION
content:
On systems using <i>systemd</i>, you typically manage Apache via commands like <i>systemctl start apache2</i> or <i>systemctl restart httpd</i>. The <i>systemd</i> service unit for Apache often includes directives that either call <i>apachectl</i> internally or handle the daemon directly. While <i>apachectl</i> can still be used for specific tasks (like <i>configtest</i> or detailed <i>status</i> checks), <i>systemctl</i> provides a more unified and robust service management experience across the OS.


title: HISTORY
content:
<i>apachectl</i> has been an integral part of the Apache HTTP Server distribution since its early versions, serving as the primary administrative tool for managing the <i>httpd</i> daemon. It emerged to simplify the complex command-line arguments of <i>httpd</i> into more user-friendly actions (like 'start' and 'restart'). Before the widespread adoption of modern service managers like <i>systemd</i>, it was the standard way to integrate Apache into system init scripts (e.g., SysVinit <i>/etc/init.d/apache2</i> files). Its core functionality has remained remarkably consistent over decades, evolving to support features like graceful restarts while maintaining backward compatibility.


title: SYNOPSIS
content:
<B>apg</B> [<I>OPTIONS</I>] [<I>NUMBER_OF_PASSWORDS</I>] [<I>PASSWORD_LENGTH</I>]<br><br><B>Common Usage Examples:</B><br><B>apg</B> <I>-a 1 -m 8 -x 12 -n 3</I><br><I>  Generates 3 pronounceable passwords, each between 8 and 12 characters long.</I><br><br><B>apg</B> <I>-a 0 -M NCLSU -m 12 -x 12 -n 1</I><br><I>  Generates 1 completely random 12-character password using Numbers, Complex, Lowercase, Special, and Uppercase characters.</I><br><br><B>apg</B> <I>-a 0 -m 10 -x 10 -M NCLS -E 'iIlL0oO'</I><br><I>  Generates a 10-character random password using Numbers, Complex, Lowercase, Special characters, excluding confusing characters (i.e., 'i', 'I', 'l', 'L', '0', 'o', 'O').</I>


title: PARAMETERS
content:
<b><B>-a</B> <I>&lt;algorithm&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Selects the password generation algorithm: <B>0</B> for random character sequences, <B>1</B> for pronounceable words (default: <B>0</B>).</I><br><br><b><B>-n</B> <I>&lt;number&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Specifies the number of passwords to generate (default: <B>1</B>).</I><br><br><b><B>-m</B> <I>&lt;min_len&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets the minimum length for generated passwords (default: <B>8</B>).</I><br><br><b><B>-x</B> <I>&lt;max_len&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sets the maximum length for generated passwords (default: <B>10</B> for pronounceable, <B>10</B> for random).</I><br><br><b><B>-M</B> <I>&lt;mode&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Defines the character modes for random passwords. Can be a combination of <B>N</B> (Numbers), <B>S</B> (Special characters), <B>L</B> (Lowercase), <B>U</B> (Uppercase), <B>C</B> (Complex/All) (default: <B>LSU</B>).</I><br><br><b><B>-X</B> <I>&lt;char_string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Includes additional specified characters in the password generation pool.</I><br><br><b><B>-E</B> <I>&lt;char_string&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Excludes specified characters from the password generation pool.</I><br><br><b><B>-L</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Prevents the use of lowercase letters when generating random passwords (used with <B>-M S,U,N</B>).</I><br><br><b><B>-s</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Uses <B>/dev/random</B> for entropy, which might block if entropy is low, but is considered cryptographically stronger than <B>/dev/urandom</B>.</I><br><br><b><B>-d</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Generates pronounceable passwords suitable for easy typing (implies <B>-a 1</B>).</I><br><br><b><B>-t</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Disables security features for faster generation (use with extreme caution, for testing only).</I><br><br><b><B>-q</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Quiet mode; suppresses all output except the generated passwords.</I><br><br><b><B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Verbose mode; displays program version and configuration information.</I><br><br>


title: DESCRIPTION
content:
<I>The <B>apg</B> command, short for <B>A</B>utomatic <B>P</B>assword <B>G</B>enerator, is a versatile command-line utility designed to generate random passwords based on various algorithms and character sets.</I><br><br><I>It primarily offers two modes of password generation:</I><br><I>1. <B>Pronounceable Passwords</B>: These are generated using a phonetic algorithm, making them easier for humans to remember and type. While convenient, they might be slightly less secure than completely random ones due to their structured nature.</I><br><I>2. <B>Completely Random Passwords</B>: These are highly secure, created from a combination of numbers, uppercase letters, lowercase letters, and special characters. They leverage cryptographically strong pseudo-random number generators (PRNGs) like <B>/dev/urandom</B> or <B>/dev/random</B> to ensure unpredictability, making them highly resistant to brute-force and dictionary attacks.</I><br><br><I><B>apg</B> provides extensive options for customization, allowing users to specify the number of passwords, their minimum and maximum lengths, and the exact character pools to include or exclude. It's an essential tool for system administrators and users requiring robust, unique, and secure passwords.</I>


title: CAVEATS
content:
<I>1. <B>Pronounceable Passwords Security</B>: While convenient for memorization, pronounceable passwords (<B>-a 1</B>) may be more susceptible to dictionary attacks or guessing algorithms that mimic human language patterns, compared to truly random character sequences.</I><br><I>2. <B>Entropy Source</B>: By default, <B>apg</B> uses <B>/dev/urandom</B>. While generally sufficient for most cryptographic purposes, some highly sensitive applications might prefer <B>/dev/random</B> (via the <B>-s</B> option), which guarantees true randomness but can block if system entropy is low.</I><br><I>3. <B>Character Exclusions</B>: Carefully consider character exclusions (<B>-E</B>). Removing too many characters, especially those commonly found in strong passwords, can significantly reduce the password's entropy and make it easier to crack.</I>


title: <B>UNDERSTANDING PASSWORD ENTROPY</B>
content:
<I>The strength of a password is often measured by its entropy, expressed in bits. Higher entropy means more possible combinations, making it exponentially harder to guess. <B>apg</B> aims to maximize this entropy by default when generating random passwords, utilizing a wide range of character sets. When specifying character sets or lengths, users should be mindful of how these choices impact the overall entropy and, consequently, the password's strength.</I>


title: <B>CHOOSING THE RIGHT ALGORITHM</B>
content:
<I>For maximum security where memorability is not a primary concern (e.g., machine-generated keys, initial administrative passwords, or API tokens), the <B>random character sequence algorithm</B> (<B>-a 0</B>) is highly recommended. For user passwords that need to be typed or remembered, the <B>pronounceable algorithm</B> (<B>-a 1</B>) offers a good balance between security and usability, provided it's combined with sufficient length and adherence to other best security practices.</I>


title: HISTORY
content:
<I><B>apg</B> has been a reliable utility in the Linux and Unix ecosystems for generating strong passwords since its creation. Developed by <B>Wojtek Paczynski</B>, it was designed to provide a robust and flexible solution for creating passwords that are both secure and, optionally, easy for humans to remember.</I><br><I>Its development has consistently focused on leveraging system entropy sources effectively and offering various customization options for password complexity, catering to diverse security needs. Over the years, while newer tools have emerged, <B>apg</B> remains a trusted and widely used command-line utility for password generation due to its proven track record and comprehensive features.</I>


title: DESCRIPTION
content:
The command 'apgbfm' is <I>not recognized</I> as a standard or commonly known Linux command or utility. <br>It does not appear in common manual pages (man), system directories like /usr/bin or /sbin, nor is it a widely documented alias or function within typical Linux distributions. <br>Therefore, a factual analysis of its purpose, syntax, and options cannot be provided. <br>It is possible that 'apgbfm' is a typo, a highly specialized, custom-built script specific to a particular environment, or an internal alias/function defined by a user. <br>Users are advised to <I>double-check the spelling</I> or consult local system administrators/documentation if this command is expected to exist in their environment.


title: CAVEATS
content:
As 'apgbfm' is not a recognized command, any attempt to execute it on a standard Linux system would likely result in a 'command not found' error. <br>No operational caveats apply as the command itself does not exist.


title: VERIFICATION
content:
Before attempting to execute 'apgbfm', it is recommended to verify its existence using commands like <I>which apgbfm</I> or <I>man apgbfm</I>. These commands will typically indicate if the command is not found on the system.


title: SYNOPSIS
content:
<b>apk</b> <i>[options] command [arguments...]</i><br><br>Common Commands:<br>&nbsp;&nbsp;<b>apk add</b> <i>&lt;package&gt;...</i> - Installs specified packages.<br>&nbsp;&nbsp;<b>apk del</b> <i>&lt;package&gt;...</i> - Removes specified packages.<br>&nbsp;&nbsp;<b>apk update</b> - Updates the package index from repositories.<br>&nbsp;&nbsp;<b>apk upgrade</b> - Upgrades all installed packages to their latest versions.<br>&nbsp;&nbsp;<b>apk search</b> <i>&lt;pattern&gt;</i> - Searches for packages matching a pattern.<br>&nbsp;&nbsp;<b>apk info</b> <i>&lt;package&gt;</i> - Displays information about an installed or available package.<br>&nbsp;&nbsp;<b>apk fix</b> - Attempts to fix broken installations (e.g., missing dependencies).<br>&nbsp;&nbsp;<b>apk cache</b> <i>[clean|sync]</i> - Manages the local package cache.


title: PARAMETERS
content:
<b>--allow-untrusted</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permit installing packages without valid signatures.<br><br><b>--no-cache</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use or create a package cache.<br><br><b>--no-network</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent network access (useful for offline operations).<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase output verbosity.<br><br><b>-i, --interactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt for confirmation before proceeding.<br><br><b>--root <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate root directory for operations.<br><br><b>--repository <url></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific repository URL instead of configured ones.<br><br><b>--initdb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initialize the local package database if it doesn't exist.<br><br>


title: DESCRIPTION
content:
`apk` is the official package manager for <b>Alpine Linux</b>, a security-oriented, lightweight Linux distribution. Unlike other common package managers like <i>apt</i> or <i>dnf</i>, `apk` is designed from the ground up to be incredibly small, fast, and resource-efficient, making it ideal for containers, embedded systems, and minimal server environments.<br><br>It manages <b>.apk</b> packages, which are simple <i>tar.gz</i> archives containing compiled binaries, libraries, and metadata. `apk` handles dependency resolution, package installation, upgrades, and removal from both local repositories and official mirrors. Its simplicity contributes to Alpine's small footprint and fast boot times. By prioritizing minimalism, `apk` helps maintain Alpine's focus on a secure and compact base system, often resulting in Docker images that are orders of magnitude smaller than those built on other distributions.


title: CAVEATS
content:
`apk` is exclusive to <b>Alpine Linux</b> and its derivatives. Packages for other distributions (e.g., <i>.deb</i>, <i>.rpm</i>) are incompatible. Alpine Linux uses <i>Musl libc</i> instead of the more common <i>glibc</i>, which means binaries compiled for other distributions will generally not run directly on Alpine without specific recompilation or compatibility layers. Its package repositories, while growing, are generally smaller than those of larger distributions.


title: PACKAGE REPOSITORIES
content:
`apk` uses a list of repositories defined in <i>/etc/apk/repositories</i>. Each line in this file specifies a URL to an Alpine repository, allowing users to configure which package sources are used. This flexibility enables easy setup of local mirrors or custom repositories.


title: SECURITY MODEL
content:
`apk` strongly emphasizes security. All official packages are cryptographically signed using <i>RSA</i> keys. `apk` verifies these signatures and package checksums during installation to ensure package integrity and authenticity, protecting against tampering and unauthorized modifications.


title: HISTORY
content:
The development of <b>Alpine Linux</b> began around 2005 with a strong focus on security and small size. `apk` was created specifically for Alpine to fulfill its unique requirements for a lightweight and efficient package manager. Its design has evolved in tandem with Alpine's growth, particularly with the increasing adoption of containers, where `apk`'s minimal footprint and fast operations provide significant advantages. The move from <i>uClibc</i> to <i>Musl libc</i> for a more compliant and robust C library was a notable milestone in Alpine's history that `apk` seamlessly adapted to.


title: PARAMETERS
content:
<b>-o <i><output_dir></i>, --output <i><output_dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where the downloaded APK should be saved.<br><br><b>-v <i><version_code></i>, --version <i><version_code></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download a specific version of the application by its version code.<br><br><b>-a <i><architecture></i>, --arch <i><architecture></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter APKs by CPU architecture (e.g., <i>armeabi-v7a</i>, <i>arm64-v8a</i>). <br>Can be specified multiple times.<br><br><b>-c <i><country_code></i>, --country <i><country_code></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the country code (e.g., <i>us</i>, <i>de</i>) for geo-restricted content.<br><br><b>-L <i><language_code></i>, --lang <i><language_code></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the language code (e.g., <i>en</i>, <i>de</i>) for localization.<br><br><b>-p <i><proxy_url></i>, --proxy <i><proxy_url></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an HTTP/SOCKS proxy for the download.<br><br><b>-s, --split-apks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download split APKs if available, which are common for modern apps.<br><br><b>-x, --extract-apks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract the base APK from a downloaded bundle of split APKs.<br><br><b>-k <i><file></i>, --key <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a Google account key file for authentication, necessary for <br>paid or region-restricted apps.<br><br><b>-u <i><user_agent_string></i>, --user-agent <i><user_agent_string></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a custom User-Agent string for requests.<br><br><b>-d, --download-data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to download associated OBB (opaque binary blob) data files <br>along with the APK.<br><br><b>-D <i><device_id></i>, --device <i><device_id></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a specific device ID to simulate for the download.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>apkeep</i> is a powerful command-line utility written in <br>Rust that enables users to download Android Application Packages (APKs) <br>directly from the Google Play Store. It bypasses the need for an Android <br>device or a Google account for many free applications, making it ideal for <br>archival purposes, installing apps on devices without Google Play Services, <br>or accessing geo-restricted content. It supports downloading specific app <br>versions, filtering by architecture, country, and language. <i>apkeep</i> <br>achieves this by simulating Google Play API requests, providing a <br>convenient way to acquire APK files for analysis, preservation, or offline <br>installation.


title: CAVEATS
content:
<i>apkeep</i> relies on simulating Google Play API interactions. <br>Changes to Google's API may occasionally break its functionality. <br>While many free apps can be downloaded without authentication, <br>paid applications, region-locked content, or certain restricted <br>updates may require a valid Google account key file (<br>often obtained via tools like <i>gplaycli</i>'s login process). <br>Always be mindful of Google's Terms of Service when using <br>such tools.


title: AUTHENTICATION
content:
For certain downloads (e.g., paid apps, region-restricted apps, <br>or specific app updates), <i>apkeep</i> requires a Google account <br>key file. This file, typically named <i>key.proto</i>, <br>contains authentication credentials. It can often be generated <br>using other Google Play-related command-line tools that <br>handle the initial login process.


title: APP ID OR URL
content:
The <i>APP_ID_OR_URL</i> argument can either be the package name <br>(e.g., <i>com.example.app</i>) or a full Google Play Store URL <br>(e.g., <i>https://play.google.com/store/apps/details?id=com.example.app</i>). <br><i>apkeep</i> automatically parses the ID from the URL.


title: HISTORY
content:
Developed in <br>Rust, <i>apkeep</i> emerged as a modern, efficient, and robust <br>command-line solution for downloading APKs directly from Google Play. <br>It addresses the common need for users to acquire specific app versions, <br>access apps outside of geo-restrictions, or maintain an archive <br>of applications independent of a physical device. Its design <br>focuses on reliability and ease of use, providing a <br>streamlined alternative to more complex methods or relying on <br>third-party APK mirrors.


title: PARAMETERS
content:
<b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><i>-f FILE</i>, <i>--file FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the target APK file. This is a <b>mandatory</b> option.<br><br><b><i>-o FILE</i>, <i>--output FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path where the results should be saved.<br><br><b><i>-r REGEX_FILE</i>, <i>--regex REGEX_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a path to a custom regex file containing additional patterns for detection.<br><br><b><i>-s</i>, <i>--silent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables silent mode, suppressing most of the verbose output during the scan.<br><br><b><i>-x</i>, <i>--extract</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <b>apkleaks</b> to decompile and extract the contents of the APK. Note: This may require <i>apktool</i> to be installed and accessible in the system's PATH.<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the scan results in JSON format, suitable for programmatic parsing.<br><br><b><i>-v</i>, <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the program's version number and exits.<br><br>


title: DESCRIPTION
content:
<b>apkleaks</b> is an open-source static analysis tool written in Python that helps in finding sensitive information from compiled Android Package Kit (APK) files. It automatically extracts URIs, endpoints, API keys, URLs, and other potentially confidential data patterns by analyzing the bytecode and resources within the APK. This tool is widely used by security researchers, penetration testers, and developers to identify potential vulnerabilities before or during the deployment of Android applications.<br><br>It leverages a comprehensive set of predefined regex patterns to detect various types of sensitive data and can output results in different formats, including standard console output or JSON.


title: CAVEATS
content:
<b>apkleaks</b> primarily performs static analysis, which means it may produce false positives or false negatives as it does not analyze runtime behavior.<br>It requires Python 3 to run.<br>The <i>-x</i> (extract) option relies on external tools like <i>apktool</i> being present and configured correctly in the system's PATH.<br>Obfuscation techniques employed in Android applications can potentially hide sensitive information, making it undetectable by <b>apkleaks</b>.


title: HOW IT WORKS
content:
<b>apkleaks</b> operates by first decompiling the target APK file (either internally or by requiring an external tool like <i>apktool</i>) to access its source code and resource files. It then scans these extracted files using a predefined set of regular expressions, designed to match common patterns of sensitive data such as API keys, URLs, endpoints, and credentials. Users can also provide custom regex patterns to tailor the search criteria to their specific needs. The detected patterns are then reported to the user, indicating potential vulnerabilities.


title: INSTALLATION
content:
<b>apkleaks</b> is a Python package and can typically be installed using <i>pip</i>, the Python package installer. The common installation command is: <br><i>pip install apkleaks</i><br>It's recommended to install it in a virtual environment to manage dependencies properly.


title: HISTORY
content:
<b>apkleaks</b> was developed by Shivam Kapoor (<i>shivamkapoor007</i>) and is an open-source project primarily hosted on GitHub. Since its initial release, it has gained significant traction within the cybersecurity community for its effectiveness and ease of use in identifying common sensitive data patterns in Android applications. Its development continues with contributions from the community, making it a continuously evolving tool for Android application security analysis.


title: SYNOPSIS
content:
<b>apktool</b> <i>[global_options]</i> <b>&lt;command&gt;</b> <i>[command_options]</i> <i>[arguments]</i><br><br><b>Common Commands:</b><br><b>apktool</b> <b>d</b> <i>[options]</i> <i>&lt;file.apk&gt;</i> (Decode an APK)<br><b>apktool</b> <b>b</b> <i>[options]</i> <i>&lt;decoded_folder&gt;</i> (Build an APK from a decoded folder)<br><b>apktool</b> <b>if</b> <i>&lt;framework.apk&gt;</i> (Install a framework file)


title: PARAMETERS
content:
<b><b>d</b>, <b>decode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes an APK file, extracting resources and Smali source code into a specified directory.<br><br><b><b>b</b>, <b>build</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebuilds an APK from a previously decoded project directory, generating a new APK file.<br><br><b><b>if</b>, <b>install-framework</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an Android framework file (e.g., from a specific Android version or manufacturer) for better decoding/building compatibility.<br><br><b><i>-f</i>, <i>--force</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Decode/Build)</i> When decoding, forces deletion of the existing output directory. When building, forces rebuilding all files, skipping change detection.<br><br><b><i>-o</i>, <i>--output &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Decode/Build)</i> Specifies the output directory for decoding or the output APK file name for building.<br><br><b><i>-r</i>, <i>--no-res</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Decode)</i> Prevents decoding of resources (XML layouts, strings, images, etc.), focusing only on source code extraction.<br><br><b><i>-s</i>, <i>--no-src</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Decode)</i> Prevents decoding of source code (Smali), only extracting resources.<br><br><b><i>-d</i>, <i>--debug</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Build)</i> Sets the 'android:debuggable' flag to 'true' in the AndroidManifest.xml when rebuilding the application.<br><br><b><i>--use-aapt2</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Decode/Build)</i> Instructs <i>apktool</i> to utilize <i>aapt2</i> for resource processing, if available, which can improve compatibility and speed with newer Android versions.<br><br>


title: DESCRIPTION
content:
<i>apktool</i> is a powerful open-source command-line utility used for reverse engineering Android applications. It can decode resources to their nearly original form and rebuild modified APKs. This makes it invaluable for security researchers, Android developers, and enthusiasts who need to analyze, modify, or debug Android applications without access to their original source code.<br><br>It handles various aspects of APK structure, including resources (XML layouts, strings, images), Smali code (disassembled DEX bytecode), and the AndroidManifest.xml file. <i>apktool</i> facilitates tasks such as localization, adding features, debugging, and identifying vulnerabilities by allowing users to inspect and manipulate an app's internal workings. It aims to be as compatible as possible with different Android versions and device manufacturers by managing framework files.


title: CAVEATS
content:
<ul><li>A Java Runtime Environment (JRE) is required for <i>apktool</i> to function.</li><li>Rebuilt APKs are unsigned and must be signed with a tool like <i>apksigner</i> or <i>jarsigner</i> before they can be installed on an Android device.</li><li>Decoding heavily obfuscated applications can be challenging, as the resulting Smali code might be difficult to understand or modify.</li><li>Accuracy of decoding and successful rebuilding can depend on the presence of appropriate framework files installed via <i>apktool if</i>.</li></ul>


title: <I>TYPICAL WORKFLOW</I>
content:
A common workflow for using <i>apktool</i> involves: <br>1. <b>Decoding</b> an APK: `<b>apktool d original.apk</b>` <br>2. <b>Modifying</b> the extracted Smali code or resource files (XML, images) within the generated directory. <br>3. <b>Rebuilding</b> the application: `<b>apktool b decoded_folder</b>` <br>4. <b>Signing</b> the newly built APK using external tools like `apksigner` or `jarsigner` before it can be installed on an Android device.


title: <I>SMALI CODE</I>
content:
When decoding, <i>apktool</i> disassembles the Dalvik/ART bytecode (found in DEX files) into a human-readable assembly-like language called Smali. Modifications to an application's core logic are typically made by editing these Smali files, which are then reassembled back into DEX bytecode during the build process.


title: <I>FRAMEWORK FILES</I>
content:
For proper decoding and rebuilding, especially for system applications or apps targeting specific Android versions/manufacturers, <i>apktool</i> often requires 'framework' files. These files contain compiled resource definitions that <i>apktool</i> uses to correctly interpret and reconstruct resources. They can be installed using the `<b>apktool if</b>` command, referencing a framework APK (e.g., from a device's system directory or an SDK).


title: HISTORY
content:
<i>apktool</i> was created by Brut.all as an open-source project. Its development began in the early days of Android, driven by the need for developers and security researchers to inspect and modify compiled Android applications. It quickly became a de-facto standard tool in the Android reverse engineering community due to its reliability and comprehensive features for both decoding and rebuilding APKs, a functionality often missing in other tools that only focused on one aspect. Its continuous development ensures compatibility with newer Android versions and build tools like <i>aapt2</i>.


title: SYNOPSIS
content:
<b>aplay</b> [<I>options</I>] [<I>filename</I>...]<br><br>Common options:<br><b>-D</b> <I>device</I> &nbsp;&nbsp;&nbsp;Select ALSA device<br><b>-f</b> <I>format</I> &nbsp;&nbsp;&nbsp;Sample format<br><b>-c</b> <I>channels</I> &nbsp;&nbsp;&nbsp;Number of channels<br><b>-r</b> <I>rate</I> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sample rate<br><b>-t</b> <I>type</I> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;File type (e.g., wav, raw)<br><b>-s</b> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Show progress bar<br><b>-v</b> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Verbose output


title: PARAMETERS
content:
<b><b>-D</b> <i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ALSA playback device to use. Use 'aplay -L' to list available devices.<br><br><b><b>-f</b> <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sample format, e.g., S16_LE (signed 16-bit, little endian) or U8 (unsigned 8-bit).<br><br><b><b>-c</b> <i>channels</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the number of audio channels (e.g., 1 for mono, 2 for stereo).<br><br><b><b>-r</b> <i>rate</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the sample rate in Hertz (e.g., 44100 for CD quality audio).<br><br><b><b>-t</b> <i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the file type, such as 'wav' for WAV files or 'raw' for raw PCM data.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a progress bar during playback, indicating the elapsed time and position.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the playback process and device parameters.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages during playback, operating in quiet mode.<br><br><b><b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>aplay</b> from touching existing mixer settings; playback is done without altering volume.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables interactive mode, allowing playback to be paused/resumed by pressing the Spacebar.<br><br><b><b>--period-size</b> <i>frames</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the period size in frames, affecting latency and buffer handling.<br><br><b><b>--buffer-size</b> <i>frames</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the total buffer size in frames, influencing how much audio data is buffered.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available PCM devices and their descriptions, useful for identifying device names for <b>-D</b>.<br><br>


title: DESCRIPTION
content:
<b>aplay</b> is a command-line utility within the <i>ALSA</i> (Advanced Linux Sound Architecture) project, designed for playing raw and <i>WAV</i> audio files through sound devices. It serves as the playback counterpart to the <b>arecord</b> command, which is used for recording audio. <b>aplay</b> provides a straightforward method to test sound card functionality, play back recorded audio, or simply output sound from scripts directly from the terminal. <br><br>While it primarily handles uncompressed formats like <i>WAV</i> and raw PCM data, its robust integration with the <i>ALSA</i> framework allows it to interact directly with various audio hardware devices and their channels. Users can specify playback parameters such as the device, sample format, rate, and number of channels, offering granular control over the audio output. It's an essential tool for developers, system administrators, and anyone needing low-level audio playback capabilities in a Linux environment.


title: CAVEATS
content:
<b>aplay</b> primarily handles uncompressed audio formats like <i>WAV</i> and raw <i>PCM</i>. It does not natively support compressed formats such as <i>MP3</i>, <i>OGG</i>, or <i>FLAC</i>; for these, a separate player or transcoder (like <b>mpg123</b> or <b>ffplay</b>) is required. <br><br>Playback might fail if the specified <i>ALSA</i> device is already in use by another application or if the user lacks sufficient permissions to access the audio hardware. Ensuring correct device selection and proper user group membership (e.g., 'audio' group) is crucial for successful playback.


title: <B>SUPPORTED FILE TYPES</B>
content:
<b>aplay</b> natively supports <i>WAV</i> (.wav) files and raw <i>PCM</i> data. For raw data, the sample format, rate, and channels must be explicitly specified using options like <b>-f</b>, <b>-r</b>, and <b>-c</b>. Support for other formats is generally not built-in and requires external decoders or pipes for conversion.


title: <B>DEVICE SELECTION</B>
content:
The <b>-D</b> option is critical for specifying the playback device. Users can list available <i>ALSA</i> devices using '<b>aplay -L</b>' to identify the correct device string (e.g., 'hw:0,0', 'default', or 'plug:dmix'). Choosing the wrong device can result in no sound or playback errors.


title: HISTORY
content:
<b>aplay</b> is an integral part of the <i>ALSA</i> (Advanced Linux Sound Architecture) utilities, which emerged as the successor to <i>OSS</i> (Open Sound System) for sound card drivers in Linux. <i>ALSA</i> development began in 1997, aiming to provide a more modular and robust audio framework. <b>aplay</b>, alongside <b>arecord</b>, was developed to provide command-line interfaces for playback and recording within this new architecture. Its continued relevance stems from <i>ALSA</i>'s widespread adoption as the default sound system in most modern Linux distributions, making <b>aplay</b> a fundamental tool for direct audio hardware interaction.


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>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version number and exits.<br><br><b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available ALSA sequencer ports on the system.<br><br><b><b>-p</b> <i>client:port</i>, <b>--port=</b><i>client:port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ALSA sequencer port(s) to send MIDI data to. Can be a client number, client name, or client:port combination. Multiple ports can be separated by commas.<br><br><b><b>-d</b> <i>name</i>, <b>--device=</b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a raw MIDI device name for direct output, bypassing the sequencer. Example: <i>hw:1,0,0</i>.<br><br><b><b>-i</b> <i>name</i>, <b>--input-port=</b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a MIDI input port. Useful for setting up a MIDI 'thru' box where input events are immediately played back.<br><br><b><b>-q</b>, <b>--queue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an ALSA sequencer queue for playback, which can provide more robust timing, especially for complex MIDI files.<br><br><b><b>-s</b> <i>pos</i>, <b>--start=</b><i>pos</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts playback from a specific position in the MIDI file. Position can be specified in beats, seconds, or measures:beats.<br><br><b><b>-e</b> <i>pos</i>, <b>--end=</b><i>pos</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ends playback at a specific position in the MIDI file, similar to <b>--start</b>.<br><br><b><b>-t</b> <i>val</i>, <b>--tempo=</b><i>val</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the playback tempo. <i>val</i> is a ratio, where 1.0 is normal tempo. E.g., 0.5 for half speed, 2.0 for double speed.<br><br><b><b>-o</b> <i>file</i>, <b>--output-file=</b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of playing, writes the MIDI events to the specified output MIDI file. Useful for MIDI file manipulation or conversion.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, displaying detailed information about the MIDI events as they are processed.<br><br><b><b>-c</b> <i>chan</i>, <b>--channel=</b><i>chan</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays only the specified MIDI channel(s). Channels are 1-16. Can be a single channel or a comma-separated list.<br><br><b><b>-r</b>, <b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables raw MIDI output mode, bypassing the ALSA sequencer. Requires a specific raw MIDI device to be specified with <b>--device</b>.<br><br><b><b>-L</b>, <b>--loop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables continuous looping playback of the MIDI file(s).<br><br><b><b>-P</b>, <b>--progress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a simple progress bar during playback, indicating progress through the MIDI file.<br><br><b><b>-C</b>, <b>--continue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continues playback even if errors (e.g., unrecognized events) are encountered in the MIDI file.<br><br><b><b>-f</b>, <b>--fingerprinting</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a fingerprint (MD5 sum) of the MIDI events, useful for identifying or comparing MIDI files structurally.<br><br>


title: DESCRIPTION
content:
The <b>aplaymidi</b> command is a utility from the ALSA (Advanced Linux Sound Architecture) project, designed for playing standard MIDI files on Linux systems. It leverages the ALSA sequencer, which provides a powerful and flexible interface for managing MIDI events and connecting applications to MIDI devices or software synthesizers. Users can specify one or more MIDI files to play, and the command will send the MIDI events contained within these files to the selected ALSA sequencer port. This allows for playback through physical MIDI interfaces connected to external synthesizers, or to software synthesizers (like FluidSynth or TiMidity++) that expose ALSA sequencer ports. <b>aplaymidi</b> supports various options for controlling playback, including selecting output ports, adjusting tempo, looping, specifying start/end points, and providing verbose output for debugging.


title: CAVEATS
content:
For <b>aplaymidi</b> to function, the ALSA sequencer must be running and accessible. If no ALSA MIDI ports are listed with <b>-l</b>, ensure that MIDI devices are properly configured and necessary kernel modules (e.g., <i>snd_seq_oss</i> for legacy devices, or specific drivers for USB MIDI interfaces) are loaded. Playback to software synthesizers requires the synthesizer to be running and exposing an ALSA sequencer port.<br><br>Using realtime options (e.g., specific looping modes, buffer/fragment sizes for low-latency, not listed here) might require elevated user privileges or specific user/group configurations for optimal performance and avoiding XRuns (underruns/overruns).


title: SEQUENCER PORTS
content:
ALSA's sequencer allows complex routing of MIDI data. You can connect <b>aplaymidi</b>'s output to various destinations using the <b>--port</b> option, including physical MIDI interfaces (e.g., <i>Midi Through:0</i>), software synthesizers (e.g., <i>TiMidity:0</i>, <i>FluidSynth:0</i>), or other applications that listen on ALSA sequencer ports. Use <b>aplaymidi -l</b> to discover available ports and their client/port numbers or names.


title: MIDI FILE FORMAT
content:
<b>aplaymidi</b> primarily supports Standard MIDI Files (SMF), which typically have <i>.mid</i> or <i>.midi</i> extensions. It can handle both Type 0 (single track) and Type 1 (multi-track) MIDI files, processing their events sequentially and sending them to the chosen output port(s).


title: HISTORY
content:
<b>aplaymidi</b> is an integral part of the ALSA (Advanced Linux Sound Architecture) utilities, which replaced the older OSS (Open Sound System) as the default sound system on Linux kernels since version 2.6. ALSA provides a robust and modular framework for audio and MIDI capabilities. <b>aplaymidi</b> specifically emerged as the standard command-line tool for playing MIDI files through ALSA's advanced sequencer infrastructure, allowing users to interact directly with ALSA's powerful MIDI routing and timing capabilities. Its development has mirrored the evolution of ALSA itself, aiming to provide low-latency and flexible MIDI playback on Linux.


title: PARAMETERS
content:
<b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display verbose information, often including daemon version if <I>apmd</I> is running.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display AC line status (online/offline).<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display battery status (e.g., discharging, charged, critical, low).<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display battery percentage remaining.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display low battery warning status.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display estimated remaining battery time in minutes.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Put the system into the APM standby state (low power, often CPU stopped).<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display overall power status, including AC line, battery state, and APM capabilities.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Put the system into the APM suspend state (deeper sleep than standby, often saving to RAM).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information of the <I>apm</I> utility.<br><br><b><b>-W</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for APM events. This option is primarily used by the <I>apmd</I> daemon, not typically for interactive use.<br><br>


title: DESCRIPTION
content:
The <I>apm</I> command is a utility for interacting with the system's Advanced Power Management (APM) BIOS interface. APM was an earlier standard for power management on x86 computers, preceding the more comprehensive Advanced Configuration and Power Interface (ACPI). This command allows users to query the APM BIOS for information such as battery status (charge, remaining time), AC adapter status, and power management states (e.g., suspend, standby). It reads information typically exposed through the <I>/proc/apm</I> file system interface, which is populated by the <I>apm_bios</I> kernel module. While largely superseded by ACPI on modern hardware, <I>apm</I> can still be relevant for older laptops, some embedded systems, or virtual machines that emulate APM. It provides a textual interface to basic power management functions.


title: CAVEATS
content:
The <I>apm</I> command relies on the BIOS-level Advanced Power Management (APM) interface, which has been largely superseded by the Advanced Configuration and Power Interface (ACPI) on modern computers. Consequently, it may not function correctly or at all on newer hardware, where power management is handled exclusively by ACPI. The kernel must have <I>apm_bios</I> support compiled in or loaded as a module, and the BIOS must expose APM functionality. Its power management actions (suspend/standby) are often less reliable or functional compared to ACPI-based methods.


title: KERNEL SUPPORT
content:
For the <I>apm</I> command to function, the Linux kernel must have the <I>CONFIG_APM</I> and <I>CONFIG_APM_BIOS</I> options enabled, typically through the <I>apm_bios</I> module. The command interacts with the kernel via the <I>/proc/apm</I> pseudo-filesystem, which exposes the APM BIOS state.


title: HISTORY
content:
The Advanced Power Management (APM) standard was developed by Intel and Microsoft in 1992 as a BIOS-level interface for power management on x86 PCs. The <I>apm</I> command and associated daemon (<I>apmd</I>) were created in the Linux environment to provide userspace access to these BIOS functions. Its peak usage was in the mid to late 1990s and early 2000s, especially on laptops. With the widespread adoption of ACPI (starting around 1996 and becoming standard by the early 2000s), APM gradually became obsolete. While still part of the Linux kernel for backward compatibility, new hardware primarily relies on ACPI.


title: SYNOPSIS
content:
As <I>apm_available</I> is not a standard Linux command, a formal synopsis does not exist. However, if it were implemented as a simple check, its usage would most likely have been:<br><br><b>apm_available</b><br><br>It is unlikely to have supported significant command-line options or arguments, as its purpose was typically a boolean check for APM presence.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No standard parameters exist for this non-standard, legacy command.<br><br>


title: DESCRIPTION
content:
apm_available is not a standard, widely distributed Linux command found on modern systems. It likely refers to a utility or script, historically used to determine if <I>Advanced Power Management (APM)</I> features were available or active on a Linux system. APM was an earlier power management specification for laptops and desktop computers, prevalent before the widespread adoption of <I>ACPI (Advanced Configuration and Power Interface)</I>.<br><br>This command would typically have been part of an older <I>apm</I> utilities package or a simple shell script wrapper that checked the kernel's APM support (often via <I>/proc/apm</I>) or the status of the <I>apmd</I> daemon. Its primary function was to provide a quick programmatic check for power management capabilities, which could then be used by other scripts or applications.<br><br>On contemporary Linux distributions, APM has been entirely superseded by ACPI. Therefore, <I>apm_available</I> is obsolete and will not be found as a native command. Modern systems rely on ACPI interfaces and tools like <I>acpi</I>, <I>upower</I>, or <I>systemd-logind</I> for power management status and control.


title: CAVEATS
content:
This command is considered <b>obsolete</b> and is generally <b>not present</b> on modern Linux distributions. Its functionality has been replaced by <I>ACPI</I> and related tools. Attempting to run it on a contemporary system will typically result in a "command not found" error.<br><br>If encountered in old documentation or scripts, it signifies reliance on legacy power management infrastructure that is no longer maintained or supported by current kernels and hardware.


title: IMPLEMENTATION DETAILS (HYPOTHETICAL)
content:
While not a standard binary, <I>apm_available</I> would typically have been a shell script that checked for the existence of <I>/proc/apm</I> (a kernel interface for APM information) or the running status of the <I>apmd</I> daemon. Its exit status (e.g., 0 for available, non-zero for not available) would have indicated APM presence.


title: MODERN EQUIVALENTS
content:
For checking power management capabilities on modern Linux systems, one would typically use commands like <I>acpi</I> (to query battery status, AC adapter status, thermal information), or interact with <I>upower</I> (via <I>upower -d</I>) or <I>systemd-logind</I> (via <I>loginctl show-session</I> or <I>show-user</I> for idle inhibitors and power management settings). These tools provide more comprehensive information and control over ACPI-based power management.


title: HISTORY
content:
The <I>Advanced Power Management (APM)</I> specification was developed by Intel and Microsoft in the early 1990s as a <I>BIOS</I>-level interface for operating systems to manage power. Linux kernels began supporting APM early on to enable power-saving features on laptops. The <I>apm_available</I> utility, or similar checks, emerged as part of this ecosystem.<br><br>However, APM had limitations, including its BIOS-centric nature and lack of extensibility. In the late 1990s, <I>ACPI (Advanced Configuration and Power Interface)</I> was introduced as a more robust and flexible standard for power management, configuration, and Plug and Play. ACPI delegates more control to the operating system and supports a wider range of power states and features.<br><br>Around the early 2000s, Linux kernels and hardware gradually transitioned from APM to ACPI. By the mid-2000s, APM support became a legacy option, and eventually, it was largely removed from modern kernels and distributions. Consequently, tools like <I>apm_available</I> became deprecated and then obsolete.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all processes, including those running unconfined. By default, only confined processes are shown.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print additional debug information, useful for troubleshooting.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output and only display errors.<br><br>


title: DESCRIPTION
content:
<b>apparmor_status</b> is a utility that provides a comprehensive overview of the AppArmor security system's current state on a Linux system.<br>It allows administrators to quickly ascertain whether AppArmor is enabled, which security profiles are loaded into the kernel, and how applications are being confined. The command distinguishes between profiles operating in <i>enforce</i> mode (actively enforcing security rules) and <i>complain</i> mode (logging violations without blocking them).<br>It lists processes that are actively confined by an AppArmor profile, as well as those that are running unconfined. This tool is invaluable for troubleshooting AppArmor configurations, verifying successful profile loading, and monitoring the security posture of confined applications. Its output helps identify potential security gaps or misconfigurations within the AppArmor framework.


title: CAVEATS
content:
<b>apparmor_status</b> typically requires root privileges (or `sudo`) to execute properly and access kernel-level AppArmor information. Without sufficient permissions, it may report an inability to connect to the AppArmor control socket or show incomplete information. The command's output reflects the AppArmor state at the moment of execution; it does not provide real-time monitoring.


title: UNDERSTANDING OUTPUT MODES
content:
The command's output typically distinguishes between "enforce" and "complain" modes.<br>Processes in <i>enforce</i> mode are actively protected and will be blocked if they attempt to violate their profile rules. Processes in <i>complain</i> mode, however, will only log violations to the system's audit logs (e.g., `/var/log/audit/audit.log` or `dmesg`) without blocking the action, making it useful for profile development and testing.


title: APPARMOR KERNEL MODULE
content:
For <b>apparmor_status</b> to report meaningful information, the AppArmor kernel security module must be loaded and enabled.<br>If AppArmor is not active, the command will indicate this, usually by stating that AppArmor is "not available" or "not enabled."


title: HISTORY
content:
AppArmor, originally developed by Immunix and later acquired by Novell, became part of the Linux kernel mainline starting with version 2.6.36. The <b>apparmor_status</b> command is a fundamental component of the AppArmor utilities suite, designed to provide an immediate diagnostic view of the system's AppArmor confinement status. Its development has closely tracked the evolution of AppArmor itself, aiming to simplify the process of understanding and managing application security profiles. It is a key tool for administrators to quickly assess the state of their AppArmor deployments.


title: SEE ALSO
content:
aa-enforce(8), aa-complain(8), aa-disable(8), aa-genprof(8), aa-logprof(8), aa-unconfined(8), apparmor(7), dmesg(1)


title: SYNOPSIS
content:
<b>apport-bug</b> [<I>OPTIONS</I>] {<I>PACKAGE</I> | <I>PID</I> | <I>PATH</I> | <I>URL</I> | <I>...additional arguments</I>}


title: PARAMETERS
content:
<b>-p PACKAGE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;File a bug against a specific <I>PACKAGE</I> name.<br><br><b>-s SERVICE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report the bug to a specified bug reporting <I>SERVICE</I> (e.g., "ubuntu").<br><br><b>-c CRASH_REPORT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an existing <I>CRASH_REPORT</I> file for the bug submission.<br><br><b>-u URL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report a bug related to a specific <I>URL</I>.<br><br><b>-f FILENAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;File a bug against a particular <I>FILENAME</I>.<br><br><b>--no-info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not collect any system information; only use user-provided details.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a test run without actually submitting the bug report.<br><br><b>--save FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Save the generated report to a specified <I>FILE</I> instead of submitting.<br><br><b>--attach FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attach an additional <I>FILE</I> to the bug report.<br><br><b>-w, --wait</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the graphical <I>Apport</I> interface to close before exiting.<br><br><b>--launchpad-bug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force reporting the bug to Launchpad directly.<br><br><b>--bug-url URL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific <I>URL</I> for the bug tracking system.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information of the command.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the command's help message and exit.<br><br>


title: DESCRIPTION
content:
<I>apport-bug</I> is a command-line utility designed to simplify and automate the process of reporting bugs on systems using the <I>Apport</I> crash reporting system, primarily Ubuntu and Debian-based distributions.<br><br>When invoked, it intelligently gathers crucial information related to the problem, such as package versions, system logs, stack traces (for crashes), and other diagnostic data. This data is then presented to the user, who can add steps to reproduce the bug, expected behavior, and actual behavior. Finally, the tool facilitates submitting this comprehensive report to a designated bug tracking system, often Launchpad for Ubuntu. Its primary goal is to provide developers with detailed, actionable bug reports with minimal effort from the user.


title: CAVEATS
content:
<I>apport-bug</I> relies on the <I>Apport</I> system being installed and enabled on the Linux distribution, primarily found on Ubuntu and its derivatives. It may collect sensitive system information and logs, which users should review before submission. Network connectivity is required to submit reports to online bug trackers. While aiming for automation, user interaction is still necessary to describe the problem and its reproduction steps.


title: GRAPHICAL INTERACTION
content:
When run in a graphical environment, <I>apport-bug</I> typically launches a GTK/Qt wizard to guide the user through the bug reporting process, allowing for review of collected data and input of problem descriptions.


title: OFFLINE REPORTING
content:
Using the <I>--save FILE</I> option, users can generate a report file offline, which can then be submitted later or transferred to another machine for submission.


title: HISTORY
content:
<I>Apport</I>, and by extension <I>apport-bug</I>, was introduced in Ubuntu 7.04 (Feisty Fawn) with the goal of making bug reporting significantly easier and more effective for end-users. Before <I>Apport</I>, users had to manually gather system information, logs, and stack traces, which was often daunting. <I>Apport</I> automated this process, encouraging more users to report bugs and providing developers with richer data, thereby accelerating bug resolution and improving software quality within the Ubuntu ecosystem.


title: SYNOPSIS
content:
<b>appres</b> [ <I>-a</I> ] [ <I>-l</I> ] [ <I>-s</I> ] [ <I>-u</I> ] [ <I>-V</I> ] [ <I>resource_name</I> ... ] <I>class_name</I> [ <I>instance_name</I> ]


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all resources in the database, not just those specific to the application.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List resources from the lowest level of the resource database, typically the most specific ones.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List resources from the highest level of the resource database, typically the least specific ones.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List resources that are unrecognized by the toolkit for the specified application or class.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the program version and exit.<br><br><b>resource_name ...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more specific resource names to query from the database.<br><br><b>class_name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The application class name (e.g., "XTerm", "Emacs") for which resources are queried. This argument is required.<br><br><b>instance_name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The application instance name (e.g., "xterm", "emacs"). This argument is optional and provides more specific resource matching.<br><br>


title: DESCRIPTION
content:
appres is a utility for displaying resources specific to a given X application or class from the X resource database. It's primarily used by application developers and users for debugging and understanding how resources are applied. The command queries the merged resource database (constructed from .Xdefaults, application-specific resource files, and other sources) for entries matching the specified application class and optionally an instance name. It helps to verify if resources are being loaded correctly and if the precedence rules are working as expected. By default, it shows resources specifically scoped for the application, but options allow viewing all resources or focusing on unrecognized ones.


title: CAVEATS
content:
appres relies on the X resource database being properly configured and accessible by the X server. The -a option can show resources not directly scoped to the specified application, which might require careful interpretation. A good understanding of X resource precedence rules is essential to effectively analyze the output.


title: RESOURCE FILES AND ENVIRONMENT VARIABLES
content:
appres consults standard X resource files such as <I>~/.Xdefaults</I> (or <I>~/.Xresources</I> depending on configuration), application-specific resource files (often found in <I>~/.Xresources/</I>), and files referenced by the <I>XAPPLRESDIR</I> environment variable. The <I>XENVIRONMENT</I> variable can also point to a specific file to be loaded. These files and variables define the resource database that appres queries.


title: HISTORY
content:
appres is a standard utility within the X Window System distribution, dating back to early releases like X11R3 or X11R4. Its development is intertwined with the evolution of the X Toolkit Intrinsics (Xt) and the X resource manager, serving as a fundamental tool for debugging X client configurations and resource loading behaviors.


title: SYNOPSIS
content:
<b>apropos</b> [<i>-alrtw</i>] [<i>-s section</i>] [<i>-m system</i>] [<i>-M path</i>] [<i>-P pager</i>] [<i>--jaro-winkler</i>] [<i>--levenshtein</i>] [<i>-e</i> | <i>-r</i>] <i>expression</i>...<br><b>apropos</b> [<i>-d</i>] [<i>-v</i>] [<i>--help</i>] [<i>--version</i>]


title: PARAMETERS
content:
<b><b>-a</b>, <b>--and</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Require all supplied expressions to match (AND logic).<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print debugging information.<br><br><b><b>-e</b>, <b>--exact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an exact match; do not use wildcards.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--jaro-winkler</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use Jaro-Winkler distance for fuzzy matching (requires man-db 2.10.0+).<br><br><b><b>-l</b>, <b>--long-output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not truncate the output, show full description lines.<br><br><b><b>--levenshtein</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use Levenshtein distance for fuzzy matching (requires man-db 2.10.0+).<br><br><b><b>-m</b> <i>&lt;system&gt;</i>, <b>--system=</b><i>&lt;system&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search manual pages from another specified hierarchy.<br><br><b><b>-M</b> <i>&lt;path&gt;</i>, <b>--path=</b><i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the search path for manual pages directly.<br><br><b><b>-P</b> <i>&lt;pager&gt;</i>, <b>--pager=</b><i>&lt;pager&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified pager program to display the output.<br><br><b><b>-r</b>, <b>--regex</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret the search expression as a regular expression.<br><br><b><b>-s</b> <i>&lt;list&gt;</i>, <b>--section=</b><i>&lt;list&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search only in the specified manual sections (e.g., '1,8').<br><br><b><b>-t</b>, <b>--troff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't use <i>nroff</i> to format the output. Useful for programmatic parsing.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print verbose warnings.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><b>-w</b>, <b>--word</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Match only on word boundaries, preventing partial word matches.<br><br>


title: DESCRIPTION
content:
<i>apropos</i> (which is equivalent to <i>man -k</i>) is a fundamental utility for searching system manual pages. When you are uncertain about the exact name of a command, function, or concept, <i>apropos</i> helps you discover relevant man pages by searching their names and the brief descriptions found in their <b>NAME</b> sections. It operates by querying a pre-built database, typically maintained by <i>mandb</i>, which ensures fast and efficient lookups. By default, the search is case-insensitive and matches substrings, but it offers options for exact matching, regular expressions, or word boundary searches. This command is an invaluable tool for exploring the vast array of commands and functions available on Unix-like operating systems, making it easier to find utilities related to a specific task or topic.


title: CAVEATS
content:
<i>apropos</i> relies on a pre-built and up-to-date database of man page summaries. If this database (managed by <i>mandb</i>) is stale or corrupted, <i>apropos</i> may not find new man pages or provide incomplete results. It only searches the brief descriptions in the <b>NAME</b> section, not the full content of manual pages. Fuzzy matching options (<i>--jaro-winkler</i>, <i>--levenshtein</i>) are relatively recent additions and might not be available on older system versions.


title: DATABASE REQUIREMENT
content:
For <i>apropos</i> to function correctly and provide up-to-date results, the underlying <i>whatis</i> or <i>man-db</i> database must be periodically refreshed. This database is typically updated by the <i>mandb</i> command (or <i>makewhatis</i> on older systems), which often runs as a scheduled cron job. If you install new software and <i>apropos</i> doesn't find its man pages, you might need to manually run <b>sudo mandb</b> to update the database.


title: SEARCH LOGIC AND EXPRESSIONS
content:
By default, <i>apropos</i> treats multiple <i>expression</i> arguments as an 'OR' operation, meaning it will return results if any of the expressions match. The <b>-a</b> (<b>--and</b>) option changes this to an 'AND' operation, requiring all expressions to match. The search itself is case-insensitive and matches substrings by default. However, options like <b>-e</b> (exact match), <b>-r</b> (regular expression), and <b>-w</b> (word boundary) allow users to refine their search patterns for more precise results.


title: HISTORY
content:
The <i>apropos</i> command has been a staple of Unix-like operating systems for decades, providing a crucial indexing and search capability for manual pages. It's historically equivalent to <i>man -k</i>. Its operation relies on a database of man page summaries, which on modern Linux systems is typically managed by the <i>man-db</i> project. This project aimed to provide a more robust and flexible manual page system compared to older implementations. Recent developments include the addition of fuzzy matching algorithms like Jaro-Winkler and Levenshtein distances, reflecting ongoing efforts to enhance user experience and search accuracy.


title: SYNOPSIS
content:
<b>apt</b> [<I>options</I>] <I>command</I><br><br>Common commands:<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt install</b> <I>package</I>...<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt remove</b> <I>package</I>...<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt full-upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt search</b> <I>keyword</I><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt show</b> <I>package</I><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt list</b> [<I>options</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt autoremove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>apt clean</b>


title: PARAMETERS
content:
<b><b>--assume-yes</b>, <b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answer yes to prompts; proceed without asking for confirmation.<br><br><b><b>--simulate</b>, <b>-s</b>, <b>--just-print</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run; show what would happen without actually making any changes.<br><br><b><b>--fix-broken</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to correct a system where broken dependencies prevent package operations.<br><br><b><b>--no-install-recommends</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install recommended packages as dependencies. Only essential and suggested ones.<br><br><b><b>--allow-downgrades</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permit the installation of older versions of packages (use with caution).<br><br><b><b>--allow-remove-essential</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow removal of essential system packages (highly dangerous; use only if you know what you're doing).<br><br><b><b>--allow-change-held-packages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow changes to packages that have been 'held' (marked to prevent upgrades).<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information and exit.<br><br>


title: DESCRIPTION
content:
<b>apt</b> is the command-line utility for the <I>Advanced Package Tool</I> (APT) system, primarily used on Debian-based Linux distributions like Ubuntu, Mint, and Pop!_OS. It provides a high-level, user-friendly interface for managing software packages. <b>apt</b> simplifies tasks such as installing, upgrading, removing, and searching for software, handling complex dependencies automatically. While older commands like <b>apt-get</b> and <b>apt-cache</b> still exist and are used in scripts, <b>apt</b> offers a more interactive and visually appealing experience for human users, featuring progress bars, colored output, and a more concise syntax. It intelligently resolves dependencies, ensuring that all necessary libraries and components are installed when you add new software and safely removed when no longer needed. This makes <b>apt</b> an indispensable tool for system administration and software management on Debian-derived systems.


title: CAVEATS
content:
<b>apt</b> operations typically require root privileges (e.g., using <b>sudo</b>).<br>Incorrect usage, especially forcing installations or removals without understanding consequences, can lead to system instability or breakage.<br>It manages <b>.deb</b> packages and repositories configured in <I>/etc/apt/sources.list</I> and <I>/etc/apt/sources.list.d/</I>. It does not directly manage <b>snap</b> or <b>flatpak</b> packages, which have their own dedicated package managers.<br>Dependency resolution, while powerful, can sometimes lead to complex scenarios known as &quot;dependency hell&quot; if repositories are misconfigured or external packages are introduced carelessly.


title: UNIFIED INTERFACE
content:
<b>apt</b> was designed to be a unified front-end, combining the most frequently used functions of <b>apt-get</b> (like <b>install</b>, <b>remove</b>, <b>update</b>, <b>upgrade</b>) and <b>apt-cache</b> (like <b>search</b>, <b>show</b>). This reduces the need for users to remember multiple command names for common tasks.


title: USER EXPERIENCE
content:
A key focus of <b>apt</b>'s development was enhancing the user experience. This includes features such as colored output, a progress bar during installations, and clearer, more concise messages, making it easier for users to understand what's happening during package operations.


title: RECOMMENDED TOOL
content:
For interactive use on the command line, <b>apt</b> is now the generally recommended package management tool over <b>apt-get</b> for most Debian and Ubuntu users due to its improved usability and merged functionalities. <b>apt-get</b> remains important for scripting purposes where its stable, predictable output is preferred.


title: HISTORY
content:
The <b>apt</b> command itself is a relatively newer front-end for the <b>Advanced Package Tool</b> system, which has been the backbone of Debian's package management since 1998. It was introduced to provide a more consistent, user-friendly, and interactive experience than its predecessors, <b>apt-get</b> and <b>apt-cache</b>. The development focused on improving human readability of output, adding progress bars, and consolidating common functionalities into a single command, making it the de facto standard for interactive package management on modern Debian-based distributions like Ubuntu since its initial release in 2014-2016 versions. Its goal was to make package management more intuitive and less verbose for end-users, while retaining the power and flexibility of the underlying APT system.


title: SEE ALSO
content:
<b>apt-get</b>(8), <b>apt-cache</b>(8), <b>dpkg</b>(1), <b>sources.list</b>(5), <b>apt-file</b>(1), <b>synaptic</b>(8)


title: SYNOPSIS
content:
<b>apt-add-repository</b> [<i>options</i>] <i>repository_string</i><br><b>apt-add-repository</b> --remove [<i>options</i>] <i>repository_string</i>


title: PARAMETERS
content:
<b><i>repository_string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The repository to add or remove. This can be a PPA string (e.g., <i>ppa:user/ppa-name</i>) or a full APT deb line (e.g., <i>'deb http://example.com/debian stable main'</i>).<br><br><b>-r, --remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the specified repository from the system's software sources. This also removes the associated GPG key, if applicable.<br><br><b>-y, --yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all prompts, making the command run non-interactively. Useful for scripting.<br><br><b>--no-update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i><b>apt update</b></i> from being run automatically after adding or removing the repository. This can be useful when adding multiple repositories in succession.<br><br><b>--component <component></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used when adding a <i>deb</i> line to specify a particular component (e.g., <i>main</i>, <i>restricted</i>, <i>universe</i>, <i>multiverse</i>).<br><br><b>--enable-sources</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the addition of source package repositories (<i>deb-src</i> lines) alongside binary package repositories.<br><br>


title: DESCRIPTION
content:
<i><b>apt-add-repository</b></i> is a command-line utility used to add or remove APT repositories from a system's software sources. Its primary function is to simplify the process of adding Personal Package Archives (PPAs) on Ubuntu and Debian-based distributions. When a PPA is specified (e.g., <i>ppa:user/ppa-name</i>), the command automatically performs several steps:<br><br>1. It constructs the correct deb line for the PPA and adds it to a new file in the <i>/etc/apt/sources.list.d/</i> directory.<br>2. It automatically imports the GPG public key associated with the repository, ensuring that packages downloaded from it can be authenticated securely.<br>3. By default, it runs <i><b>apt update</b></i> to refresh the package lists, making the newly available packages immediately discoverable.<br><br>Beyond PPAs, it can also add standard <i>deb</i> or <i>deb-src</i> lines, abstracting away the manual editing of configuration files and GPG key management, making it an essential tool for users needing software not available in official repositories.


title: CAVEATS
content:
<b>1. Security Risks:</b> Adding third-party repositories, especially PPAs, can introduce security vulnerabilities. Always verify the trustworthiness of the source before adding.<br><b>2. System Instability:</b> Software from external repositories might be unstable, poorly tested, or conflict with packages from official sources, potentially leading to system instability or dependency issues.<br><b>3. Package Conflicts:</b> Adding too many repositories or those with conflicting packages can lead to 'dependency hell' or broken packages.<br><b>4. GPG Key Failures:</b> Occasionally, the automatic GPG key retrieval might fail due to network issues or keyserver problems, requiring manual intervention with <i><b>apt-key</b></i> or direct key import.


title: PPA INTEGRATION
content:
<i><b>apt-add-repository</b></i> is particularly well-integrated with Launchpad PPAs. When you provide a PPA string like <i>ppa:user/ppa-name</i>, the command intelligently queries Launchpad to determine the correct deb line for your system's architecture and distribution, and automatically retrieves the necessary GPG key for package authentication.


title: UNDERLYING MECHANISM
content:
Behind the scenes, <i><b>apt-add-repository</b></i> typically creates a new file (e.g., <i>user-ubuntu-ppa-name-*.list</i>) in the <i>/etc/apt/sources.list.d/</i> directory, containing the repository's deb line. It also interacts with <i><b>apt-key</b></i> (or newer methods like <i>/etc/apt/trusted.gpg.d/</i>) to add the repository's signing key, ensuring that packages from this source can be verified by <i><b>apt</b></i>.


title: HISTORY
content:
The <i><b>apt-add-repository</b></i> command (originally a script) gained prominence as part of the <i>software-properties-common</i> package, primarily to simplify the management of Personal Package Archives (PPAs) in Ubuntu. Before its existence, adding a PPA required manually editing <i>/etc/apt/sources.list</i> or creating files in <i>/etc/apt/sources.list.d/</i>, and then separately importing the GPG key using <i><b>apt-key</b></i>. <i><b>apt-add-repository</b></i> streamlined this multi-step process into a single, user-friendly command, making it significantly easier for users to access software distributed via PPAs.


title: PARAMETERS
content:
<b><B>search</B> <I>regex</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for packages whose names or descriptions match the given regular expression. This is one of the most frequently used commands to find relevant software.<br><br><b><B>show</B> <I>pkg</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about one or more specified packages, including description, dependencies, versions, and file sizes.<br><br><b><B>policy</B> [<I>pkg</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installation policy for packages, indicating which versions are available and which would be chosen for installation based on APT's priorities and pin-settings.<br><br><b><B>depends</B> <I>pkg</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all direct and indirect dependencies for a specified package, showing a tree-like structure of required packages.<br><br><b><B>rdepends</B> <I>pkg</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists packages that directly or indirectly depend on the specified package (reverse dependencies).<br><br><b><B>pkgnames</B> [<I>prefix</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all known package names in the system or filters them by a given prefix.<br><br><b><B>showpkg</B> <I>pkg</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about a package, similar to 'show' but with a focus on available versions, their dependencies, and reverse dependencies in a more structured format.<br><br><b><B>dumpavail</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a listing of all available packages to standard output, often used for debugging or parsing package metadata.<br><br><b><B>stats</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays statistics about the package cache, such as the number of packages, versions, and dependencies.<br><br><b><B>dotty</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a graphviz dot file representing the package dependencies, useful for visualizing complex dependency graphs.<br><br><b><B>gencaches</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds APT's package cache from the source lists (normally done automatically by 'apt update').<br><br><b><B>-q</B>, <B>--quiet</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress progress indicators and make output quieter, suitable for scripting.<br><br><b><B>-s</B>, <B>--no-virtual-packages</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display virtual packages in the output.<br><br><b><B>-n</B>, <B>--no-show-versions</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display version information for packages (e.g., with 'pkgnames').<br><br><b><B>-i</B>, <B>--important</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with 'depends' or 'rdepends', only show dependencies marked as 'important'.<br><br><b><B>-f</B>, <B>--full</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show full dependency lists (e.g., with 'depends', showing all versions).<br><br><b><B>-x</B>, <B>--regex</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat patterns as regular expressions (default for 'search').<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command usage.<br><br><b><B>-v</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program version.<br><br>


title: DESCRIPTION
content:
<i>apt-cache</i> is a command-line utility that is part of the <B>APT (Advanced Package Tool)</B> suite on Debian-based Linux distributions. Its primary function is to query, examine, and manipulate the local package cache, which stores metadata about available software packages.<br><br>Unlike <i>apt-get</i> or <i>apt</i>, <i>apt-cache</i> does not perform direct package installations or removals. Instead, it provides valuable insights into the package ecosystem, helping users find packages, inspect their dependencies, view available versions, and understand how packages are sourced and managed within the APT system.<br><br>It operates on the package metadata stored locally, typically in <i>/var/lib/apt/lists/</i>, which is populated by running <i>apt update</i>. This makes <i>apt-cache</i> an essential tool for system administrators and power users who need to diagnose package issues, explore software options, or understand the complex relationships between different software components.


title: CAVEATS
content:
All information provided by <i>apt-cache</i> is derived from the local package cache. This cache must be kept up-to-date by regularly running <B>apt update</B> to ensure accuracy. If the cache is stale, <i>apt-cache</i> might report outdated package versions or availability status. Also, while powerful for querying, <i>apt-cache</i> does not directly modify the system; it only provides information.


title: LOCAL CACHE LOCATION
content:
<i>apt-cache</i> operates on data stored primarily in the <i>/var/lib/apt/lists/</i> directory. These files are package metadata downloaded from the repositories defined in <i>/etc/apt/sources.list</i> and <i>/etc/apt/sources.list.d/</i>.


title: MODERN USAGE VS. APT
content:
For common tasks like searching or showing package details, the newer <B>apt</B> command is often preferred due to its more user-friendly output and consolidated interface (e.g., <B>apt search</B> vs. <B>apt-cache search</B>). However, <i>apt-cache</i> retains unique and powerful commands like <B>policy</B>, <B>depends</B>, <B>rdepends</B>, and <B>stats</B> that are not fully replicated in <B>apt</B>, making it indispensable for advanced package analysis and system administration.


title: HISTORY
content:
<B>APT (Advanced Package Tool)</B> and its associated utilities, including <i>apt-cache</i>, were developed by the Debian project to provide a robust and flexible package management system. <i>apt-cache</i> has been a core component of APT since its early days, designed specifically for querying the rich metadata stored in the package cache. While the newer, more user-friendly <B>apt</B> command (introduced around 2014) has absorbed some of <i>apt-cache's</i> functionalities (like <B>apt search</B> and <B>apt show</B>), <i>apt-cache</i> remains crucial for more specialized queries, detailed dependency analysis, and scripting purposes, offering granular control and specific output formats not always available in the consolidated <i>apt</i> command.


title: PARAMETERS
content:
<b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a CD-ROM to APT's list of package sources, scanning it for packages and updating <i>sources.list</i>.<br><br><b>ident</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Identifies the CD-ROM in the drive and prints its unique identity string.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all CD-ROMs currently known to APT from its <i>sources.list</i> configuration.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program version and exits.<br><br><b>-c, --config-file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default.<br><br><b>-o, --option <opt>=<val></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific APT configuration option directly. Can be used multiple times.<br><br><b>-d, --cdrom <mountpoint></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the mount point for the CD-ROM/DVD drive, overriding auto-detection.<br><br><b>-r, --rename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows renaming an existing CD-ROM entry in the sources list to a new descriptive name.<br><br><b>-m, --mount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to mount the CD-ROM if it's not already mounted at the specified or default mount point.<br><br><b>-f, --fast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimizes the scanning process by assuming package lists on the CD-ROM are sorted, leading to faster indexing.<br><br><b>-a, --thorough</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a complete and comprehensive scan of every package on the CD-ROM, which is slower but ensures all packages are found.<br><br><b>-n, --no-act</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run' without actually writing any changes to the <i>sources.list</i> file.<br><br><b>-D, --debug <item></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output for specific internal components of <b>apt-cdrom</b>.<br><br><b>--id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with the 'add' command, explicitly sets the identity string for the CD-ROM rather than auto-detecting it.<br><br><b>--passphrase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with 'add', provides a GPG passphrase if the CD-ROM repository is signed and requires authentication.<br><br><b>--with-source</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with 'add', also includes source package URIs for the CD-ROM in <i>sources.list</i>.<br><br><b>--no-auto-detect</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <b>apt-cdrom</b> from attempting to auto-detect the CD-ROM device path, requiring the mount point to be specified with <b>-d</b>.<br><br>


title: DESCRIPTION
content:
<b>apt-cdrom</b> is a utility within the APT (Advanced Package Tool) suite designed to add a CD-ROM or DVD as a source for APT's package management system. When executed, it scans the inserted disc for valid package files (typically located in the <i>dists/</i> directory), identifies the distribution and components, and then automatically appends an entry for the CD-ROM to APT's <i>/etc/apt/sources.list</i> file or a file within the <i>/etc/apt/sources.list.d/</i> directory. This allows package managers like <b>apt</b>, <b>apt-get</b>, and <b>aptitude</b> to locate and install software directly from the physical media. It is particularly useful for offline installations, systems with limited internet access, or for using official distribution media as a local repository. After successfully adding a disc, it's essential to run <b>apt update</b> to refresh the package cache, making the newly available packages discoverable.


title: CAVEATS
content:
<b>apt-cdrom</b> typically requires root privileges (or <b>sudo</b>) to modify system configuration files like <i>/etc/apt/sources.list</i>. After successfully adding a CD-ROM source, it is crucial to execute <b>apt update</b> (or <b>apt-get update</b>) to refresh the package cache and make the packages from the CD-ROM discoverable by APT. The command expects a standard Debian package repository structure on the disc. Its utility has significantly decreased in modern computing environments due to widespread internet access, as most users now rely on network repositories for software updates and installations.


title: SOURCES.LIST ENTRY
content:
When a CD-ROM is successfully added, <b>apt-cdrom</b> creates an entry in <i>/etc/apt/sources.list</i> or a dedicated file in <i>/etc/apt/sources.list.d/</i>. This entry typically looks like <i>deb cdrom:[Debian GNU/Linux 11.5.0 _Bullseye_ - Official amd64 DVD Binary-1 20220910-10:48]/ bullseye main contrib</i>, allowing APT to recognize the CD-ROM as a valid package source when mounted.


title: OFFLINE USAGE
content:
Despite its declining general use, <b>apt-cdrom</b> remains valuable for air-gapped systems or environments with extremely limited internet connectivity. It provides a reliable mechanism to install base systems and essential packages directly from official distribution media without requiring an active network connection.


title: HISTORY
content:
<b>apt-cdrom</b> is a long-standing component of the APT (Advanced Package Tool) suite, which was first developed for Debian in the late 1990s. Its primary role was to enable offline installations and updates from physical distribution media (CD-ROMs and later DVDs). In an era before pervasive high-speed internet, this was a critical feature for deploying and maintaining Debian-based systems, especially in areas with limited connectivity. While still functional and maintained, its usage has significantly diminished as network-based package repositories have become the dominant method for software distribution and updates.


title: SYNOPSIS
content:
<b>apt-clone</b> &lt;command&gt; [options] [arguments]<br><b>apt-clone</b> clone &lt;output-directory&gt;<br><b>apt-clone</b> restore &lt;archive-file.apt-clone.tar.gz&gt;


title: PARAMETERS
content:
<b>clone &lt;output-directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clones the current system's APT configuration and installed packages into the specified directory. This directory will contain the <i>.apt-clone.tar.gz</i> archive.<br><br><b>restore &lt;archive-file.apt-clone.tar.gz&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restores APT packages and configuration from the specified <i>apt-clone</i> archive file.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, force overwriting of existing files or configurations without prompting.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a simulation of the restore operation, showing what packages would be installed or removed without making any actual changes to the system.<br><br><b>--with-dpkg-repack</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When cloning, also uses <i>dpkg-repack</i> to save <i>.deb</i> files for all currently installed packages into the archive. This can create very large archives.<br><br><b>--savelog</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When cloning, saves the APT history logs (<i>/var/log/apt/history.log</i> and <i>/var/log/apt/term.log</i>) into the archive.<br><br><b>--save-pkgs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly saves the list of installed packages. This is the default behavior for the <b>clone</b> command.<br><br><b>--restore-src</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, recreates <i>sources.list.d</i> entries from the archive, configuring APT repositories.<br><br><b>--restore-etc-apt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, restores the entire <i>/etc/apt</i> directory from the archive. This includes all configuration files and repository definitions.<br><br><b>--restore-dpkg-statoverrides</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, restores <i>dpkg-statoverrides</i> from the archive, which can modify file permissions and ownership for certain installed packages.<br><br><b>--restore-debs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, installs <i>.deb</i> files that were saved with <i>--with-dpkg-repack</i> during the clone operation. This allows offline package installation if the packages are available in the archive.<br><br><b>--auto-install-pkgs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, automatically installs missing packages listed in the archive. This is the default behavior for the <b>restore</b> command.<br><br><b>--dont-check-gpg</b><br>&nbsp;&nbsp;&nbsp;&nbsp;During restore, disables GPG signature checking for repositories. <b>Use with extreme caution</b> as this can compromise system security by allowing installation of untrusted packages.<br><br><b>--destination &lt;directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination directory for the cloned data. For the <b>clone</b> command, this is where the <i>.apt-clone.tar.gz</i> file will be created.<br><br><b>--tempdir &lt;directory&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a temporary directory to be used for intermediate operations during cloning or restoring.<br><br><b>--assume-yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answers 'yes' to all prompts during the operation, making it non-interactive.<br><br>


title: DESCRIPTION
content:
<i>apt-clone</i> is a utility designed to create a backup of installed APT packages and repository information from one system, allowing for easy restoration on another system or the same system after a fresh install. It captures the list of currently installed packages, the APT sources (repositories), and any authentication keys associated with them.<br><br>This makes it efficient for migrating package selections between machines or for setting up new systems with a similar software environment without manually reinstalling each package. During the <b>clone</b> operation, it creates a tarball (typically named <i><filename>.apt-clone.tar.gz</i>) containing all necessary data. The <b>restore</b> command then uses this archive to replicate the package environment, installing missing packages and configuring repositories.


title: CAVEATS
content:
<ul><li><i>apt-clone</i> primarily manages APT package selection and repository configurations. It <b>does not</b> back up or restore application-specific configuration files located outside of <i>/etc/apt</i>. For a full system backup, other tools are necessary.</li><li>Using the <i>--with-dpkg-repack</i> option can generate extremely large archive files, especially on systems with many installed packages. Ensure sufficient disk space.</li><li>Restoring an <i>apt-clone</i> archive on a significantly different distribution version or architecture might lead to dependency issues or package conflicts. It works best between identical or very similar systems.</li><li>The <i>--dont-check-gpg</i> option disables critical security checks and should only be used in controlled environments with full understanding of the risks.</li><li>A network connection is required during the <b>restore</b> operation to download packages that are not present in the archive (unless <i>--restore-debs</i> is used and the packages are in the archive).</li></ul>


title: ARCHIVE CONTENTS
content:
A typical <i>.apt-clone.tar.gz</i> archive created by <i>apt-clone</i> usually contains:<br><ul><li><i>pkgs.txt</i>: A plain text file listing all manually installed packages on the source system.</li><li><i>sources.list.d/</i>: A directory containing the <i>.list</i> files that define additional APT repositories.</li><li><i>trusted.gpg.d/</i>: A directory with GPG public keys used to authenticate packages from added repositories.</li><li><i>repack/</i>: (Only if <i>--with-dpkg-repack</i> was used) A directory containing the <i>.deb</i> files for all installed packages.</li></ul>


title: COMMON USE CASES
content:
<i>apt-clone</i> is particularly useful for:<br><ul><li><b>System Migration</b>: Easily transferring your installed software environment from an old machine to a new one.</li><li><b>OS Reinstallation</b>: Quickly restoring your preferred applications after a fresh operating system installation.</li><li><b>Environment Replication</b>: Setting up multiple development or testing machines with an identical set of packages and repositories.</li><li><b>Backup</b>: Creating a point-in-time backup of your system's software configuration.</li></ul>


title: HISTORY
content:
<i>apt-clone</i> was originally developed as part of the <i>ubuntu-tweak</i> project, a popular configuration utility for Ubuntu. Its utility in simplifying system migration and replication led to its adoption as a standalone tool, often included in official repositories of Debian-based distributions like Ubuntu. It provides a more specialized and convenient way to manage package environments compared to manual methods involving <i>dpkg --get-selections</i> and <i>dpkg --set-selections</i>.


title: PARAMETERS
content:
<b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the entire APT configuration in a structured format.<br><br><b>shell</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates shell export statements for all active APT configuration variables, useful for scripting.<br><br><b>list <config_item></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the value of a specific configuration item. Functionally similar to <I>get</I>.<br><br><b>get <config_item></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the value of a specified APT configuration item. For example, `apt-config get APT::Default-Release`.<br><br><b>set <config_item> <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Temporarily sets the value of a configuration item for the current `apt-config` invocation. <B>Changes are not persistent.</B><br><br><b>source <config_item></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows which configuration file defined a specific APT configuration item. Useful for debugging configuration overrides.<br><br><b>-o, --option <ConfString></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>Set a configuration option directly on the command line.</B> This allows overriding any configuration file entry for the current command execution. Format is `APT::Option::Name=value`.<br><br><b>-c, --config-file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file to use instead of the default ones.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage summary and available options.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information.<br><br><b>-D, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables various debug outputs, useful for troubleshooting.<br><br>


title: DESCRIPTION
content:
`apt-config` is a command-line utility from the <I>APT (Advanced Package Tool)</I> suite. It provides a powerful interface for querying, inspecting, and temporarily modifying APT's configuration settings. This tool is invaluable for system administrators and developers who need to understand how APT resolves its behavior from various configuration files, such as <I>/etc/apt/apt.conf</I> and those in <I>/etc/apt/apt.conf.d/</I>.<br><br>While it can set configuration options, these changes are generally <B>temporary</B> for the current `apt-config` invocation. For persistent changes, one typically edits the APT configuration files directly. Its primary use cases include debugging APT's behavior, scripting automated tasks that depend on specific APT settings, and verifying that APT is configured as expected before performing package operations.


title: CAVEATS
content:
The `set` command in `apt-config` only applies the configuration change for the <B>current invocation</B> of `apt-config`. It does <I>not</I> make persistent changes to APT's global configuration files.<br><br>Understanding APT's configuration hierarchy (default settings, main config file, `apt.conf.d` directory, and command-line options) is crucial when interpreting `apt-config` output or attempting to modify settings. Command-line options generally <B>override</B> file-based settings.


title: APT CONFIGURATION HIERARCHY
content:
APT resolves its configuration settings from several locations in a specific order of precedence, with later sources overriding earlier ones:<br>1. <B>Default Built-in Settings</B>: Hardcoded defaults within the APT binaries.<br>2. <B>`/etc/apt/apt.conf`</B>: The main APT configuration file.<br>3. <B>`/etc/apt/apt.conf.d/`</B>: Directory containing additional configuration snippets. Files are parsed in alphabetical order.<br>4. <B>Environment Variables</B>: Some settings can be influenced by environment variables (e.g., `APT_CONFIG`).<br>5. <B>Command-line Options (`-o`)</B>: Options passed directly to `apt` commands, which always take the highest precedence. `apt-config`'s <I>`dump`</I> command provides a consolidated view of the final, resolved configuration.


title: HISTORY
content:
`apt-config` emerged as a utility within the <B>APT (Advanced Package Tool)</B> suite, which was developed to replace `dselect` as a more robust and user-friendly front-end for <I>dpkg</I> (Debian Package management system). APT's design relies heavily on a flexible configuration system, and `apt-config` was created to provide a programmatic interface to this system. It became increasingly important as APT's configuration grew in complexity, allowing administrators to inspect and debug how various settings (like repositories, proxies, or default releases) were resolved from multiple configuration files and command-line options.


title: SYNOPSIS
content:
<b>apt-extracttemplates</b> [<i>OPTIONS</i>] <i>PACKAGE_FILE</i>...<br>Extracts debconf templates from specified <i>.deb</i> packages.


title: PARAMETERS
content:
<b><i>PACKAGE_FILE</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to Debian package (<i>.deb</i>) files from which to extract templates.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b>-t <tempdir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a temporary directory where the extracted templates should be placed. This overrides the default temporary location.<br><br><b>-c <configfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file for debconf to use. This is typically used internally and not directly by users.<br><br>


title: DESCRIPTION
content:
<i>apt-extracttemplates</i> is a specialized utility primarily used by package management tools like <i>dpkg</i> and <i>APT</i> to extract debconf templates from Debian (<i>.deb</i>) package files. Debconf templates contain questions and configuration prompts displayed to users during package installation or upgrade, allowing for interactive setup.<br><br>This command parses the control archive within a <i>.deb</i> package, identifies the <i>templates</i> and <i>config</i> files, and makes them available for <i>debconf</i> processing. It ensures that user-configurable options embedded within packages are properly registered and presented. While essential for the package management ecosystem, it is generally not invoked directly by end-users, serving as a backend component of the <i>debconf</i> system.


title: CAVEATS
content:
This command is an internal utility primarily used by <i>dpkg</i> and <i>APT</i> during package processing. It is rarely, if ever, called directly by users. Its successful execution depends on the presence of a valid <i>.deb</i> package structure containing debconf templates. It does not actually configure the package, but merely extracts the templates for <i>debconf</i> to process. Direct interaction with this command may lead to unexpected behavior if its internal context is not correctly replicated.


title: BACKEND UTILITY
content:
It's crucial to understand that <i>apt-extracttemplates</i> functions as a backend helper for package managers like <i>APT</i> and <i>dpkg</i>. It is not intended for direct interactive use by administrators or users for package installation or configuration. Its role is solely to prepare the debconf templates for the <i>debconf</i> system to consume.


title: ROLE IN DEBCONF
content:
The command plays a vital role in the <i>debconf</i> framework by making the configuration questions and options embedded within Debian packages accessible to the <i>debconf</i> database and frontend. Without this extraction step, <i>debconf</i> would not know what questions to ask or what configuration options are available for a given package, thus hindering the interactive configuration process.


title: HISTORY
content:
<i>apt-extracttemplates</i> is an integral part of the <i>debconf</i> system, which was developed in the late 1990s and early 2000s to standardize and improve the configuration process of Debian packages. Before <i>debconf</i>, package configuration often involved custom scripts, leading to inconsistent user experiences. <i>debconf</i> introduced a modular, standardized approach, and tools like <i>apt-extracttemplates</i> became essential backend components to enable this system by providing a reliable mechanism to extract and register configuration prompts embedded within <i>.deb</i> packages.


title: SYNOPSIS
content:
apt-file [options] <I>command</I> [arguments]<br><br>Common commands:<br><I>apt-file</I> [options] <B>update</B><br><I>apt-file</I> [options] <B>search</B> <I>pattern</I><br><I>apt-file</I> [options] <B>list</B> <I>package</I><br><I>apt-file</I> [options] <B>show</B> <I>package</I>


title: PARAMETERS
content:
<b>-a, --case-insensitive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform case-insensitive matching for the pattern.<br><br><b>--architecture=<arch></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a particular architecture to search for files within (e.g., amd64, i386).<br><br><b>--force-all-architectures</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force searching all architectures, ignoring the default architecture.<br><br><b>--force-specific-architecture</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force searching only the specified architecture, ignoring other architecture configurations.<br><br><b>-c, --config-file=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative configuration file for apt-file.<br><br><b>-e, --regexp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the search pattern as a regular expression. This is the default for 'search'.<br><br><b>-f, --from-file=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read patterns from the specified file, one per line.<br><br><b>-i, --ignore-missing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not complain if the local cache for a repository is missing.<br><br><b>-l, --long</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show full path, package name, and architecture for results.<br><br><b>-o, --option <configstring></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a configuration option (e.g., 'apt-file::Dir::Cache=/tmp/cache').<br><br><b>-s, --show-description</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the package description along with the search results.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about operations.<br><br><b>-x, --fixed-string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform an exact match on the pattern, disabling regular expression interpretation.<br><br>


title: DESCRIPTION
content:
apt-file is a command-line utility used to search for files contained within packages available in Debian/Ubuntu-based APT repositories. Unlike <I>dpkg -S</I>, which searches only installed packages, <I>apt-file</I> searches packages that are <I>not yet installed</I> on your system. It relies on a local cache of package contents, which must be updated periodically using <I>sudo apt-file update</I>. This tool is invaluable for tasks such as identifying which package provides a specific header file, a shared library, or a configuration file, especially when debugging compilation errors or missing dependencies. It can search by exact filename, by pattern, and provides options to list all files in a specific package.


title: CAVEATS
content:
Requires a local cache of package contents, which must be updated regularly using <I>sudo apt-file update</I>. If the cache is stale or missing, <I>apt-file</I> will not function correctly or provide outdated results.<br>The search results reflect packages available in your APT repositories, not necessarily packages currently installed on your system.<br>The initial <I>apt-file update</I> can be time-consuming and consume significant disk space, as it downloads package content lists from all configured repositories.


title: UPDATING THE CACHE
content:
Before using <I>apt-file</I> for the first time, or after adding new repositories or running <I>apt update</I>, it is crucial to update its local cache. This is done via <B>sudo apt-file update</B>. This command downloads and processes package lists, building an index of all files contained within available packages from your APT sources. Regular updates are recommended to keep the cache synchronized with the repositories, ensuring accurate and up-to-date search results.


title: COMMON USE CASES
content:
<I>apt-file</I> is extremely useful for:<br>- Identifying which package provides a specific header file (e.g., <I>apt-file search stdio.h</I>).<br>- Finding the package containing a shared library (e.g., <I>apt-file search libssl.so.1.1</I>).<br>- Determining which package a specific command or configuration file belongs to (e.g., <I>apt-file search apache2.conf</I>).<br>- Listing all files contained within a specific package (e.g., <I>apt-file list vim</I>).


title: HISTORY
content:
<I>apt-file</I> was developed to fill a crucial gap in the APT ecosystem, providing a convenient way to search for files within uninstalled packages, a feature not natively offered by <I>apt</I> or <I>dpkg</I> for uninstalled packages. It offers similar functionality to <I>rpm -qf</I> on RPM-based systems but tailored for Debian/Ubuntu's APT. Its development is closely tied to the Debian and Ubuntu communities, aiming to provide a more comprehensive package management experience. It has become a standard and indispensable tool for system administrators and developers working with Debian-based distributions.


title: SYNOPSIS
content:
<b>apt-ftparchive</b> [<I>options</I>] <I>command</I><br><b>apt-ftparchive generate</b> <I>configfile</I><br><b>apt-ftparchive release</b> <I>configfile</I><br><b>apt-ftparchive contents</b> <I>path</I><br><b>apt-ftparchive packages</b> <I>path</I> [<I>override-file</I> [<I>path-prefix</I>]]<br><b>apt-ftparchive sources</b> <I>path</I> [<I>override-file</I> [<I>path-prefix</I>]]<br><b>apt-ftparchive print-structure</b> [<I>type</I>]<br><b>apt-ftparchive dump</b> <I>configfile section</I><br><b>apt-ftparchive help</b>


title: PARAMETERS
content:
<b>generate <I>configfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates <i>Packages</i> and <i>Sources</i> index files for components and architectures defined in the specified configuration file.<br><br><b>release <I>configfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a <i>Release</i> file for the archive, often including cryptographic checksums of the index files and potentially signing it with a GPG key as defined in the configuration.<br><br><b>contents <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a <i>Contents</i> file from the packages located under the specified path, listing files contained within each package.<br><br><b>packages <I>path</I> [<I>override-file</I> [<I>path-prefix</I>]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a <i>Packages</i> file from <i>.deb</i> files found recursively under the given path. An optional override file can be used to modify package information like priorities and sections.<br><br><b>sources <I>path</I> [<I>override-file</I> [<I>path-prefix</I>]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a <i>Sources</i> file from source packages (<i>.dsc</i> files) found recursively under the given path. An optional override file can be provided for source package information.<br><br><b>print-structure [<I>type</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the internal structure of the archive. An optional type can filter the output to specific components or architectures.<br><br><b>dump <I>configfile</I> <I>section</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps a specific section of the configuration file to standard output, useful for debugging.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of commands and common options.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's detailed help text.<br><br><b>--config-file <I>file</I>, -c=<I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to be used instead of the default ones.<br><br><b>--option <I>APT::Key=Value</I>, -o=<I>APT::Key=Value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a configuration option directly. Can be used multiple times to set different options, overriding values from configuration files.<br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information.<br><br><b>--quiet, -q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output, showing only error messages.<br><br><b>--force-architecture</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the inclusion of packages regardless of their declared architecture, useful for building repositories for multiple architectures or cross-building.<br><br><b>--md5</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates MD5 checksums for files. This is often included by default for <i>Packages</i> and <i>Sources</i> files.<br><br><b>--sha1</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates SHA1 checksums for files.<br><br><b>--sha256</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates SHA256 checksums for files.<br><br><b>--sha512</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates SHA512 checksums for files.<br><br><b>--no-compression</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents compression of generated index files (e.g., <i>Packages</i>, <i>Sources</i>). By default, they are compressed with gzip and/or xz if available.<br><br>


title: DESCRIPTION
content:
<b>apt-ftparchive</b> is a utility for generating index files (e.g., <i>Packages</i>, <i>Sources</i>, <i>Release</i>, <i>Release.gpg</i>) for a Debian archive. These files are crucial for APT clients to browse and download packages from a repository. It's typically used by repository maintainers to build and update the metadata necessary for APT to function correctly. It can generate <i>Packages</i> and <i>Sources</i> files from a directory tree of <i>.deb</i> and <i>.dsc</i> (Debian Source Control) files, respectively. Furthermore, it can generate and sign <i>Release</i> files, which provide cryptographic integrity checks for the entire archive. This command is a foundational tool for anyone hosting their own Debian package repository, enabling clients to use <b>apt update</b> and <b>apt install</b> against it effectively.


title: CAVEATS
content:
<b>apt-ftparchive</b> requires a well-structured directory layout adhering to Debian repository standards and a comprehensive configuration file for complex repositories. Errors in the configuration can lead to malformed archives that APT clients cannot properly process or trust. GPG signing of the <i>Release</i> file requires proper key setup and management on the system. It is important to note that this command <i>does not create packages</i>; it only indexes existing <i>.deb</i> and source packages and generates metadata for them.


title: CONFIGURATION FILES
content:
<b>apt-ftparchive</b> heavily relies on configuration files (e.g., <i>/etc/apt/ftparchive.conf</i> or a custom one specified with <i>-c</i>) to define repository paths, package filters, architecture mapping, and signing options. This makes it highly flexible but also requires careful setup and understanding of its directives and the APT configuration syntax.


title: REPOSITORY STRUCTURE
content:
It expects and is designed to work with a standard Debian repository structure, typically following the layout of <i>dists/suite/component/architecture/</i> where package files reside. Proper adherence to this structure is essential for correct indexing and for APT clients to locate packages.


title: SIGNING ARCHIVES
content:
The <b>release</b> command, when properly configured, can sign the <i>Release</i> file with a GPG key. This cryptographic signature is critical for <b>apt</b> clients to verify the integrity and authenticity of the repository, ensuring that packages have not been tampered with and originate from a trusted source. Without a valid signature, APT clients will typically refuse to use the repository.


title: HISTORY
content:
Part of the <b>apt</b> package suite, <b>apt-ftparchive</b> was developed as a robust and integrated tool for managing Debian repository metadata. It emerged to provide a more comprehensive and configurable solution compared to earlier, simpler scanning utilities like <b>dpkg-scanpackages</b> and <b>dpkg-scansources</b>, which primarily focused on single index file generation. Its introduction allowed for complete archive management, including <i>Release</i> file generation and GPG signing, which are vital for repository integrity and authenticity in modern APT environments. Its development has paralleled the growth and sophistication of the Debian package ecosystem, becoming an indispensable tool for anyone maintaining a Debian-based package repository.


title: SYNOPSIS
content:
<b>apt-get</b> [<i>options</i>] <i>command</i> [<i>packages...</i>]<br>Example: <b>sudo apt-get update</b><br>Example: <b>sudo apt-get install</b> <i>package-name</i>


title: PARAMETERS
content:
<b><b>-y</b>, <b>--assume-yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatic yes to prompts; assumes 'yes' to all questions.<br><br><b><b>-s</b>, <b>--simulate</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;No actual actions will be performed; simulates operations.<br><br><b><b>-f</b>, <b>--fix-broken</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempt to correct a system with broken dependencies.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces output suitable for logging, suppressing interactive prompts.<br><br><b><b>-V</b>, <b>--show-versions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version numbers of packages being installed/upgraded.<br><br><b><b>--no-install-recommends</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consider recommended packages as dependencies for installation.<br><br><b><b>--no-install-suggests</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consider suggested packages as dependencies for installation.<br><br><b><b>-u</b>, <b>--show-upgraded</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a list of all packages that are going to be upgraded.<br><br><b><b>-d</b>, <b>--download-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download packages only; don't install or unpack them.<br><br>


title: DESCRIPTION
content:
<b>apt-get</b> is a powerful command-line tool that handles the installation, removal, and upgrading of software packages on Debian, Ubuntu, and other Debian-based Linux distributions. It is part of the <i>Advanced Package Tool (APT)</i> system. <b>apt-get</b> works by interacting with configured repositories (servers hosting software packages), resolving dependencies, and retrieving the necessary <i>.deb</i> package files. It automates the complex process of ensuring all required libraries and programs are installed when you add new software or update existing ones. While still widely used, the newer <b>apt</b> command is often preferred for interactive use due to its more user-friendly interface, which combines functionalities from <b>apt-get</b> and <b>apt-cache</b>. Nonetheless, <b>apt-get</b> remains fundamental for scripting and certain system administration tasks.


title: CAVEATS
content:
Using <b>apt-get</b> typically requires root privileges (via `<b>sudo</b>`). Careless use, especially with commands like `<b>dist-upgrade</b>` on unstable systems or forcing installations with `--fix-broken`, can potentially destabilize your system. An active internet connection is essential for updating package lists and downloading new software. For general interactive use, the newer `<b>apt</b>` command is often more user-friendly.


title: COMMON COMMANDS
content:
Here are the most frequently used sub-commands for <b>apt-get</b>:<br><i><b>update</b></i>: <br>Resynchronizes the package index files from their sources. It downloads new package lists from the repositories, letting `apt-get` know about new versions of packages.<br><br><i><b>install</b> &lt;package&gt;</i>: <br>Installs new packages. It automatically resolves and installs any required dependencies. Multiple packages can be specified.<br><br><i><b>remove</b> &lt;package&gt;</i>: <br>Removes specified packages, but leaves their configuration files behind.<br><br><i><b>purge</b> &lt;package&gt;</i>: <br>Removes specified packages along with their configuration files.<br><br><i><b>upgrade</b></i>: <br>Installs the newest versions of all packages currently installed on the system that are available from the sources configured in `<i>/etc/apt/sources.list</i>`. Existing packages are upgraded.<br><br><i><b>dist-upgrade</b></i>: <br>Similar to `<b>upgrade</b>`, but also intelligently handles changing dependencies with new versions of packages; it may remove some packages or install new ones to satisfy dependencies. Often used for distribution upgrades.<br><br><i><b>autoclean</b></i>: <br>Clears out the local repository of retrieved package files that can no longer be downloaded, and are now of no use.<br><br><i><b>autoremove</b></i>: <br>Removes packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed.<br><br><i><b>clean</b></i>: <br>Clears out the local repository of retrieved package files. Unlike `<b>autoclean</b>`, it removes all <i>.deb</i> files regardless of whether they are still available for download.<br><br><i><b>check</b></i>: <br>Is a diagnostic tool; it updates the package cache and checks for broken dependencies.


title: HISTORY
content:
<b>apt-get</b> was developed as a core component of the <i>Advanced Package Tool (APT)</i> project by the Debian community. Its primary goal was to provide a more robust and user-friendly solution for managing software packages and their complex dependencies, improving upon the direct usage of `<b>dpkg</b>`. First released in 1998, it quickly became the standard for package management on Debian and its derivatives like Ubuntu. While its core functionality remains, the introduction of the simpler `<b>apt</b>` command in 2014 provided a consolidated interface for daily tasks, making `<b>apt-get</b>` more often used for scripting or specific administrative functions.


title: SYNOPSIS
content:
<b>apt-key</b> [<i>options</i>] <i>command</i> [<i>keyid</i> | <i>filename</i>]<br><br>Common commands:<br><b>apt-key add</b> <i>filename</i><br><b>apt-key del</b> <i>keyid</i><br><b>apt-key list</b><br><b>apt-key export</b> <i>keyid</i><br><b>apt-key update</b><br><b>apt-key net-update</b><br><br><i>Options</i>: <br><b>--keyring</b> <i>filename</i> (specifies an alternative keyring file)


title: PARAMETERS
content:
<b>add <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a GPG public key from <i>filename</i> to the trusted keyring. The key is typically added to `/etc/apt/trusted.gpg` or a file under `/etc/apt/trusted.gpg.d/`.<br><br><b>del <keyid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a GPG key identified by its <i>keyid</i> from the trusted keyring. This removes its trust for package verification.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all keys currently stored in the trusted keyring, displaying their ID, type, size, creation date, and user ID.<br><br><b>export <keyid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports a specific GPG key identified by its <i>keyid</i> to standard output. Useful for sharing or backing up keys.<br><br><b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the local APT keyring with new keys from a predefined keyserver (functionality largely removed in recent APT versions).<br><br><b>net-update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to `update`, but uses APT's network configuration for key fetching (also largely removed).<br><br><b>--keyring <filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative GPG keyring file to operate on instead of the default global keyrings.<br><br>


title: DESCRIPTION
content:
The `apt-key` command was historically used to manage the list of trusted GPG (GNU Privacy Guard) keys for the Advanced Package Tool (APT) on Debian-based Linux distributions. These keys are crucial for verifying the authenticity and integrity of software packages downloaded from repositories. <br><br>When a key was added using `apt-key`, it was placed into a global keyring (e.g., `/etc/apt/trusted.gpg` or `/etc/apt/trusted.gpg.d/`). This allowed APT to verify signatures of packages from any repository whose signing key was present in this global keyring. However, this global trust model presented a significant security vulnerability, as a compromised key could allow an attacker to sign malicious packages for <i>any</i> repository. <br><br>Due to these security concerns, `apt-key` has been largely deprecated in favor of a more secure, per-repository key management approach using the `signed-by` option in `sources.list` entries.


title: CAVEATS
content:
<b><i>DEPRECATED</i></b>: The `apt-key` command is officially deprecated. Its use for adding new keys is strongly discouraged due to security vulnerabilities.<br><br><b><i>Global Trust Issue</i></b>: Keys added via `apt-key` become globally trusted for <i>all</i> APT repositories. If a globally trusted key is compromised, it could be used to sign malicious packages for any repository, not just the one it originated from.<br><br><b><i>Modern Approach</i></b>: For securely adding repository keys, the recommended method is to use the `<b>signed-by</b>` option within `<b>/etc/apt/sources.list.d/*.list</b>` entries, pointing to a specific key file (e.g., `<b>.gpg</b>` or `<b>.asc</b>`) stored in `<b>/etc/apt/keyrings/</b>`.


title: WHY APT-KEY IS DEPRECATED AND THE MODERN APPROACH
content:
The deprecation of `apt-key` stems from its design flaw of creating a global trust store. Any key added via `apt-key` effectively grants permission to sign packages from <i>any</i> repository on the system, regardless of its origin. This means that if you add a key for a single third-party repository and that key is later compromised, it could be used to sign malicious packages that APT would blindly trust from any other repository you have configured.<br><br>The modern, secure alternative involves using the `<b>signed-by</b>` option in your `<b>/etc/apt/sources.list.d/*.list</b>` files. Instead of adding keys globally, you explicitly specify which key is allowed to sign packages for a particular repository. For example: <br><br><code>deb [signed-by=/etc/apt/keyrings/example-archive-keyring.gpg] https://example.com/debian stable main</code><br><br>This ensures that the `example-archive-keyring.gpg` key is only trusted for packages coming from `https://example.com/debian`. This targeted trust significantly reduces the attack surface and improves the overall security posture of your system's package management.


title: HISTORY
content:
Initially, `apt-key` was the primary tool for managing PGP/GPG keys used by APT to authenticate packages. It simplified the process of adding repository keys by placing them in a single, global keyring (e.g., `<b>/etc/apt/trusted.gpg</b>`).<br><br>Over time, as APT grew more sophisticated and security best practices evolved, the global trust model of `apt-key` was identified as a security risk. If a single key in the global keyring were compromised, it could undermine the security of the entire system by allowing an attacker to impersonate any repository.<br><br>Beginning with APT version 1.1 (released in 2015), `apt-key` started to be deprecated. Subsequent versions, particularly APT 2.1+, strongly pushed for a new, more secure paradigm: individual keys should be explicitly associated with specific repository entries using the `<b>signed-by</b>` option in `<b>sources.list</b>` files, and these keys should be stored in a dedicated directory like `<b>/etc/apt/keyrings/</b>` for better scoping and management. Functionality like `<b>apt-key update</b>` and `<b>apt-key net-update</b>` has also been removed from newer APT versions (2.4+).


title: SYNOPSIS
content:
apt-mark <i>{auto | manual | hold | unhold | showauto | showmanual | showhold}</i> [<i>options</i>] <i>{pkg ... | regexp ...}</i><br>apt-mark <i>[--help | --version]</i>


title: PARAMETERS
content:
<b>auto <i>&lt;pkg...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the specified packages as automatically installed. These packages can later be removed by <i>apt autoremove</i> if no longer needed by manually installed packages.<br><br><b>manual <i>&lt;pkg...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the specified packages as manually installed. This prevents <i>apt autoremove</i> from suggesting their removal, even if they are no longer dependencies.<br><br><b>hold <i>&lt;pkg...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Places the specified packages on hold. A held package cannot be upgraded, installed, or removed by APT until it is unheld. This is useful for preventing unwanted changes.<br><br><b>unhold <i>&lt;pkg...&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the hold mark from the specified packages, allowing APT to manage them normally again (upgrade, install, remove).<br><br><b>showauto</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages that are currently marked as automatically installed.<br><br><b>showmanual</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages that are currently marked as manually installed.<br><br><b>showhold</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all packages that are currently on hold.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage summary and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the program version and exits.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress progress indicators and other verbose output.<br><br><b>--config-file <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a configuration file to use instead of the default.<br><br><b>-o, --option <i>&lt;opt&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a configuration option. For example, <i>-o Dpkg::Options::="--force-confdef"</i>.<br><br>


title: DESCRIPTION
content:
apt-mark is a command-line utility within the APT (Advanced Package Tool) suite, used to manage special settings, or <i>"marks,"</i> for installed packages. Its primary functions include marking packages as <i>automatically</i> or <i>manually</i> installed, which influences whether <i>apt autoremove</i> will consider them for removal. It also allows users to <i>hold</i> packages, preventing them from being upgraded, installed, or removed, and to <i>unhold</i> them. This tool provides fine-grained control over how individual packages are managed by the APT system, offering a simplified interface compared to direct manipulation of package selection states. It plays a vital role in maintaining a clean and efficient system by managing dependencies effectively.


title: CAVEATS
content:
<b>Hold state:</b> A package placed on <i>hold</i> will not be upgraded, installed, or removed by <i>apt</i> until the <i>hold</i> is explicitly removed. This is a powerful feature for maintaining specific package versions.<br><b>Permissions:</b> Modifying package states (<i>auto</i>, <i>manual</i>, <i>hold</i>, <i>unhold</i>) requires root privileges (e.g., using <i>sudo</i>). Displaying states (<i>showauto</i>, <i>showmanual</i>, <i>showhold</i>) typically does not.


title: INTERACTION WITH <I>APT AUTOREMOVE</I>
content:
The <i>auto</i> and <i>manual</i> marks are fundamental to the behavior of the <i>apt autoremove</i> command. When a package is installed as a dependency (e.g., required by another package), it's usually marked <i>auto</i>. If the dependent package is later removed, and no other manually installed packages require it, <i>apt autoremove</i> will identify and suggest removing this 'orphaned' <i>auto</i>-marked package to free up disk space. Conversely, explicitly marking a package as <i>manual</i> ensures that it is always treated as an essential component, preventing <i>autoremove</i> from ever suggesting its removal, regardless of its dependency status.


title: HISTORY
content:
<i>apt-mark</i> is a more recent addition to the APT toolkit, developed to simplify and standardize the management of package installation states. Prior to its introduction, similar functionalities for managing <i>hold</i> states were often performed using <i>dpkg --set-selections</i>. <i>apt-mark</i> provides a more intuitive and direct interface for these common tasks, aligning with the broader goal of the <i>apt</i> command to offer a user-friendly, unified frontend for package management on Debian-based systems.


title: DESCRIPTION
content:
The <b>apt-moo</b> command is a humorous Easter egg found within the <b>apt</b> package management suite on Debian-based Linux systems. It does not perform any practical system function, such as managing packages, installing software, or updating the system. Instead, when executed, <b>apt-moo</b> simply displays a short, whimsical message:<br><br><i><b>Have you mooed today?</b></i><br><br>This command is essentially a wrapper or alias for the more widely known <b>apt-get moo</b> Easter egg. It serves no technical purpose beyond providing a moment of amusement for users who stumble upon it or are aware of its existence. It's a nod to the playful side of the Linux development community, showcasing that even serious system tools can contain lighthearted hidden features. The "moo" itself is a long-standing inside joke within the Debian community, often associated with the phrase "There are no user-serviceable parts inside." This phrase, originally from a joke about cows and package managers, refers to the idea that apt handles complex tasks internally, and users shouldn't try to tinker with its fundamental operations directly. <b>apt-moo</b> is a direct, dedicated command to trigger this specific Easter egg.


title: CAVEATS
content:
The <b>apt-moo</b> command is purely an Easter egg and serves no functional purpose in package management or system operation. It does not modify system files, install software, or affect system performance in any way. Its output is static and purely for amusement.


title: THE "MOO" ORIGIN
content:
The "moo" concept within <b>apt</b> is a whimsical reference to a specific programmer's joke. The phrase "There are no user-serviceable parts inside" often accompanied by a picture of a cow, became a popular way to explain the internal complexity and robustness of certain software, particularly <b>apt</b>. It suggests that the system handles its intricate tasks autonomously, and users should not attempt to manually interfere with its core mechanisms. The <b>apt-moo</b> command is a direct nod to this humorous philosophical stance within the Debian community.


title: HISTORY
content:
The <b>apt-moo</b> command, along with its progenitor <b>apt-get moo</b>, has been a delightful Easter egg within the <b>apt</b> package manager for many years, dating back to early versions of <b>apt</b> on Debian and Ubuntu distributions. Its origin lies in a long-standing inside joke within the Debian community concerning cows and the complexity of package management. The joke, often distilled to "There are no user-serviceable parts inside," implies that <b>apt</b> handles its intricate operations internally, much like a cow digesting its food, and users should trust its process rather than attempting to manually intervene at a fundamental level. The inclusion of <b>apt-moo</b> provides a dedicated, quick way to access this specific humorous message without needing to type the full <b>apt-get moo</b> command, making it a beloved quirk for many Linux users.


title: SYNOPSIS
content:
apt-secure<br><br><i>Note: apt-secure is a documentation page describing APT's security model, not an executable command with runtime options or arguments. Its 'invocation' is typically <b>man apt-secure</b>.</i>


title: DESCRIPTION
content:
<i>apt-secure</i> describes the security model employed by APT for managing software packages. It explains how APT verifies the authenticity and integrity of packages downloaded from repositories. At its core, this system relies on cryptographic signatures: each repository's <i>Release</i> file (or <i>InRelease</i>) is signed by a GPG key.<br><br>APT checks this signature against a keyring of trusted keys. Historically, trusted keys were managed globally in <i>/etc/apt/trusted.gpg</i> and <i>apt-key</i> was used for management. Modern APT, however, emphasizes per-repository trust via the <i>Signed-By</i> option in <i>sources.list(5)</i>, pointing to specific keyring files (e.g., in <i>/etc/apt/trusted.gpg.d/</i>).<br><br>This mechanism ensures that packages originate from a legitimate source and haven't been tampered with during transmission, protecting the system from malicious or corrupted software. If a signature verification fails, APT will refuse to install or upgrade packages from that source, issuing a warning.


title: CAVEATS
content:
The <i>apt-key(8)</i> command, especially <b>apt-key add</b>, is largely deprecated due to its global trust model. Modern practice dictates using the <b>Signed-By</b> option in <i>sources.list(5)</i> entries to specify per-repository keyrings.<br>Adding untrusted or unknown GPG keys to your system can severely compromise its security, as it allows APT to implicitly trust any package signed by that key, regardless of its origin.<br>Always ensure that the key used to sign a repository is obtained from a secure and trusted source.


title: PRACTICAL APPLICATION OF APT SECURITY
content:
While <i>apt-secure</i> is a documentation page, understanding its principles is crucial for managing external repositories securely.<br>When adding a new repository (e.g., a PPA), you typically download its GPG key and place it in a dedicated keyring file within <i>/etc/apt/trusted.gpg.d/</i>.<br>Then, in your <i>sources.list</i> file or a new <i>.list</i> file in <i>/etc/apt/sources.list.d/</i>, you specify the repository URL along with the <b>Signed-By</b> option pointing to the keyring file you just added.<br>For example: <br> <b>deb [signed-by=/usr/share/keyrings/myrepo-archive-keyring.gpg] https://example.com/debian stable main</b><br>This ensures APT only trusts packages from <i>example.com</i> if they are signed by the key in <i>myrepo-archive-keyring.gpg</i>, rather than globally trusting it.


title: HISTORY
content:
Initially, APT's security relied on a single, globally trusted keyring. Users would typically add repository keys using <b>apt-key add</b>. This approach, while simple, had a significant drawback: adding a key granted trust to <i>all</i> repositories signed by it, making it difficult to manage granular trust.<br><br>Over time, the need for more isolated and explicit trust management grew. The <b>Signed-By</b> option was introduced in <i>sources.list(5)</i> entries, allowing administrators to specify the exact keyring file (often placed in <i>/etc/apt/trusted.gpg.d/</i>) that should be used to verify a particular repository. This significantly improved security by limiting the scope of trust. Consequently, the <i>apt-key</i> command's <b>add</b> functionality was deprecated in favor of manual key management within <i>/etc/apt/trusted.gpg.d/</i> combined with the <b>Signed-By</b> directive. The <i>InRelease</i> file format was also introduced to combine the <i>Release</i> file and its signature into a single download, improving efficiency.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Show Help</b><br>Displays a short help text and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Show Version</b><br>Displays the program version and exits.<br><br><b>-s, --stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Standard Output</b><br>Writes the sorted output to standard output instead of sorting files in-place.<br><br><b>-m, --merge-filename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Merge Files</b><br>When processing multiple input files, merges them into a single sorted output. This option implies <i>--stdout</i>.<br><br><b>-c, --check-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Check Only</b><br>Performs a check to see if the input file(s) are already sorted correctly. Exits with status 0 if sorted, 1 otherwise.<br><br><b>-o, --option <config string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Configuration Option</b><br>Set an arbitrary configuration option. For example, <i>-o APT::SortPkgs::Fields</i> can be used to customize the field sorting order.<br><br><b>-k, --keep-empty-lines</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Keep Empty Lines</b><br>Prevents the removal of extra empty lines between package records.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Quiet Mode</b><br>Suppresses status messages during operation.<br><br>


title: DESCRIPTION
content:
<i>apt-sortpkgs</i> is a utility designed to sort package description files such as <i>Packages</i> and <i>Sources</i> files, commonly found in APT repositories. It reorders fields within each package entry based on a predefined list of standard Debian control file fields (e.g., <i>Package</i>, <i>Version</i>, <i>Description</i>). Fields not in the predefined list are appended alphabetically. This sorting is crucial for the efficient processing of these files by other APT tools, like <i>apt-file</i>, ensuring consistent and predictable data structures. By default, it sorts files in-place unless specified to output to standard output. It can also check if a file is already sorted without modifying it.


title: CAVEATS
content:
<i>apt-sortpkgs</i> is primarily an internal tool used for APT repository maintenance or by utilities like <i>apt-file</i> for efficient indexing. It is not typically used directly by end-users. Be cautious with in-place sorting as it overwrites the original files.


title: EXIT STATUS
content:
<b>Exit Status</b><br>The command returns <i>0</i> on success. If used with the <i>-c</i> (<i>--check-only</i>) option, it returns <i>1</i> if the file is not sorted correctly. It also returns <i>1</i> for malformed input files.


title: DEFAULT BEHAVIOR
content:
<b>Default Behavior</b><br>By default, <i>apt-sortpkgs</i> sorts the input files in-place, overwriting the original files with the sorted content. Use the <i>-s</i> (<i>--stdout</i>) option to output to standard output instead, which is safer for testing.


title: HISTORY
content:
<i>apt-sortpkgs</i> is part of the <i>apt-file</i> package, a critical component for searching files within Debian packages. Its development is closely tied to the need for efficient indexing and searching of package contents, where consistently sorted <i>Packages</i> and <i>Sources</i> files are crucial for performance. It has been a stable and essential utility within the Debian/Ubuntu ecosystem for many years, facilitating reliable package management operations.


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>apt-daemon</b> version number and exits.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message summarizing usage and available options, then exits.<br><br><b>-d, --daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <b>aptd</b> as a background daemon process. This is the typical operational mode when managed by <i>systemd</i> or similar init systems.<br><br><b>-f, --foreground</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <b>aptd</b> in the foreground. This mode is particularly useful for debugging, as it prints logs directly to the console.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about its operations, which can be helpful for troubleshooting.<br><br><b>-c CONFIGFILE, --config=CONFIGFILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default. This allows for customized behavior without altering global configurations.<br><br><b>-p PIDFILE, --pidfile=PIDFILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the path for the process ID (PID) file. This file stores the process ID of the running daemon, used by other tools to manage the service.<br><br>


title: DESCRIPTION
content:
<b>aptd</b> (also known as <i>apt-daemon</i>) is a system service that provides a high-level D-Bus API for performing APT (Advanced Package Tool) package management operations. It acts as a backend for graphical user interfaces like software centers and update managers, allowing non-root users to perform privileged package installations, removals, and updates securely by handling authentication and delegating tasks to the underlying APT tools.<br><br>Unlike direct APT commands (<i>apt</i>, <i>apt-get</i>), <b>aptd</b> is designed for programmatic interaction and system integration, abstracting away the complexities of <i>sudo</i> and process management. While primarily a background service managed by the system's init system (e.g., <i>systemd</i>), it can also be invoked directly for debugging or specific administrative purposes.


title: CAVEATS
content:
<b>aptd</b> is primarily a backend service; direct command-line invocation by end-users is uncommon and typically reserved for system administration or debugging.<br>It relies on underlying APT tools (like <i>apt-get</i>, <i>dpkg</i>) to perform actual package operations; <b>aptd</b> itself does not replace them but provides an interface.<br>Misconfiguration or improper handling can lead to issues with package management, potentially affecting system stability.<br>On modern Linux distributions, <b>aptd</b> is usually managed by <i>systemd</i> (or equivalent init systems), meaning it's automatically started, stopped, and restarted as needed.


title: D-BUS INTERFACE
content:
<b>aptd</b> exposes its functionality via a comprehensive D-Bus interface. This allows client applications (e.g., software stores, update notifiers) to call methods for package operations like <i>install_package</i>, <i>remove_package</i>, <i>update_packages</i>, and query package information. This D-Bus communication layer handles authentication and authorization, enabling privileged operations without the client application needing root privileges directly.


title: CONFIGURATION FILES
content:
While <b>aptd</b> has command-line options for startup, its operational behavior is primarily configured via system-wide configuration files. These are typically located within the <i>/etc/apt/apt.conf.d/</i> directory or specific <b>apt-daemon</b> configuration paths. These files define various aspects such as timeouts, log verbosity, and specific APT behaviors to be used by the daemon.


title: HISTORY
content:
<b>apt-daemon</b>, which provides the <b>aptd</b> service, was developed to address the challenge of securely allowing graphical applications to interact with the powerful, but often root-privileged, APT package management system. Prior to its existence, GUI tools might have resorted to less secure or less integrated methods for privilege escalation. <b>apt-daemon</b> emerged as a solution to centralize privilege management, provide a consistent D-Bus API, and enhance the user experience by enabling seamless package operations within desktop environments. It became a crucial component for graphical software centers (e.g., Ubuntu Software Center) and update managers across Debian-based distributions.


title: PARAMETERS
content:
<b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the current operational status of the APT daemon.<br><br><b><b>get_pkgs</b> [<I>package</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves detailed information about specified packages or lists all available packages if none are specified.<br><br><b><b>install_pkgs</b> <I>package</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a request for the APT daemon to install one or more specified packages.<br><br><b><b>remove_pkgs</b> <I>package</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a request for the APT daemon to remove one or more specified packages.<br><br><b><b>update_cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the APT daemon to update the package list from configured repositories, similar to 'apt update'.<br><br><b><b>upgrade_pkgs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the APT daemon to upgrade all installed packages to their newest versions, similar to 'apt upgrade'.<br><br><b><b>fix_broken</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Asks the APT daemon to attempt to resolve and fix broken package dependencies.<br><br><b><b>commit</b> <I>transaction_id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Commits a previously prepared transaction by its ID.<br><br>


title: DESCRIPTION
content:
<b>aptdcon</b> is a specialized command-line utility that serves as a console client for the <i>APT daemon</i> (<b>aptd</b>). The <b>aptd</b> daemon is a core component of the <i>aptdaemon</i> project, designed to provide a secure and consistent <i>D-Bus</i> interface for package management operations on Debian-based systems like Ubuntu.<br><br>Unlike standard user-facing tools such as <b>apt</b> or <b>apt-get</b>, <b>aptdcon</b> is primarily intended for developers, testers, and advanced users who need to directly interact with and debug the <b>aptd</b> service. It allows for sending various commands to the daemon, mirroring many of the <i>D-Bus</i> methods exposed by <b>aptd</b>, such as installing, removing, upgrading packages, or querying the daemon's status and transaction history. This direct interaction is crucial for understanding the daemon's behavior, testing new features, and diagnosing issues within the <i>aptdaemon</i> framework or graphical frontends that rely on it.<br><br>While it can perform package management tasks, it lacks the user-friendly interface and robust error handling of typical command-line tools. Its main value lies in its ability to expose the underlying <b>aptd</b> operations, making it an invaluable tool in the <i>aptdaemon</i> development and testing ecosystem. It requires the <b>aptd</b> service to be running to function correctly.


title: CAVEATS
content:
<b>aptdcon</b> is not intended for general end-user package management. It is a low-level client for testing the <i>APT daemon</i> (<b>aptd</b>) and may not provide the same user-friendly feedback or error handling as standard tools like <b>apt</b> or <b>apt-get</b>. Direct interaction with <b>aptdcon</b> often requires specific knowledge of the <i>aptdaemon D-Bus</i> interface.<br><br>Operations initiated via <b>aptdcon</b> may require PolicyKit authorization, meaning a password prompt could appear if the current user does not have sufficient privileges.<br><br>The command set and behavior of <b>aptdcon</b> can be subject to change as it is primarily a development and testing tool.


title: REQUIRES APT DAEMON
content:
For <b>aptdcon</b> to function, the <i>APT daemon</i> (<b>aptd</b>) service must be running. If it's not active, commands will fail to connect.


title: D-BUS INTERFACE
content:
The commands accepted by <b>aptdcon</b> directly map to the <i>D-Bus</i> methods provided by the <b>aptd</b> service. This makes it a useful tool for understanding and testing the <i>aptdaemon D-Bus</i> API.


title: HISTORY
content:
The <b>aptdcon</b> command is an integral part of the <i>aptdaemon</i> project, which began development to address the need for a secure, policy-kit enabled, and graphical-friendly interface to APT. Before <i>aptdaemon</i>, graphical package managers often had to run with root privileges or use cumbersome sudo calls. <i>aptdaemon</i> provided a D-Bus service that allowed unprivileged users to request package operations, with PolicyKit handling privilege escalation.<br><br><b>aptdcon</b> was created alongside <i>aptdaemon</i> as a straightforward command-line tool to interact with this new daemon, facilitating its development, testing, and debugging. Its usage primarily reflects the <i>D-Bus</i> methods exposed by the <b>aptd</b> service, evolving as <i>aptdaemon</i> itself matured.


title: SYNOPSIS
content:
<pre><b>aptitude</b> [<i>options</i>] <i>command</i> [<i>package</i>...]</pre><pre><b>aptitude</b> [<i>options</i>]</pre><i>Common commands include:</i><br><i>  </i><b>update</b><br><i>  </i><b>upgrade</b><br><i>  </i><b>full-upgrade</b> (or <b>dist-upgrade</b>)<br><i>  </i><b>install</b> <i>package</i>[<i>=version</i>]...<br><i>  </i><b>remove</b> <i>package</i>...<br><i>  </i><b>purge</b> <i>package</i>...<br><i>  </i><b>hold</b> <i>package</i>...<br><i>  </i><b>unhold</b> <i>package</i>...<br><i>  </i><b>markauto</b> <i>package</i>...<br><i>  </i><b>unmarkauto</b> <i>package</i>...<br><i>  </i><b>show</b> <i>package</i>...<br><i>  </i><b>search</b> <i>pattern</i>...<br><i>  </i><b>clean</b><br><i>  </i><b>autoclean</b><br>


title: PARAMETERS
content:
<b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The action <b>aptitude</b> should perform. Examples include <b>install</b>, <b>remove</b>, <b>update</b>, <b>search</b>, <b>upgrade</b>, etc.<br><br><b><i>package</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the package(s) to operate on. Wildcards and regular expressions can sometimes be used.<br><br><b><b>-y</b>, <b>--assume-yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answer yes to prompts, useful for scripting.<br><br><b><b>-s</b>, <b>--simulate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a 'dry run' operation, showing what would happen without actually making changes.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity of output. Can be specified multiple times.<br><br><b><b>-D</b>, <b>--show-deps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the dependencies that are automatically installed/removed.<br><br><b><b>-R</b>, <b>--with-recommends</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Consider recommended packages as dependencies (default behavior for <b>install</b>).<br><br><b><b>-r</b>, <b>--without-recommends</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not consider recommended packages as dependencies.<br><br><b><b>-P</b>, <b>--with-suggests</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Consider suggested packages as dependencies.<br><br><b><b>-t</b> <i>release</i>, <b>--target-release</b> <i>release</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the target release or distribution for package operations (e.g., <i>stable</i>, <i>testing</i>, <i>unstable</i>).<br><br><b><b>-F</b> <i>format</i>, <b>--display-format</b> <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for <b>search</b> and <b>show</b> commands.<br><br><b><b>-O</b> <i>option</i>, <b>--option</b> <i>option</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a configuration option (e.g., <i>APT::Get::Assume-Yes=true</i>).<br><br>


title: DESCRIPTION
content:
<b>aptitude</b> is a versatile and robust package manager for Debian-based Linux distributions, including Ubuntu. It serves as a high-level interface to the APT system, offering both a traditional command-line interface and a powerful, interactive text-based user interface (TUI) based on Ncurses. <br><br>While <b>apt</b> has become the default modern frontend for APT, <b>aptitude</b> remains a favored choice for many users due to its sophisticated dependency resolution algorithm, which is often considered more capable of handling complex dependency conflicts than its counterparts. It can intelligently propose solutions for broken dependencies and track packages installed automatically, facilitating their eventual removal. <br><br>Beyond basic installation and removal, <b>aptitude</b> provides extensive search capabilities, allowing users to find packages by name, description, or even complex search patterns. It also supports operations like upgrading the system, holding packages to prevent upgrades, marking packages as manually or automatically installed, and showing detailed information about packages. Its interactive mode, invoked by simply running <b>aptitude</b> without arguments, offers a visual way to browse, select, and manage packages, complete with dependency views and conflict resolution.


title: CAVEATS
content:
While powerful, <b>aptitude</b>'s dependency resolver can sometimes be overly aggressive in proposing solutions, which might surprise users accustomed to <b>apt</b> or <b>apt-get</b>'s behavior. Its interactive interface, though feature-rich, can have a steeper learning curve for new users. For simple day-to-day package management, <b>apt</b> is often considered more straightforward and is the default for many modern distributions.


title: INTERACTIVE MODE
content:
When invoked without any commands or arguments (e.g., just <b>aptitude</b>), it launches a full-screen, text-based interactive interface. This mode allows users to visually browse available packages, mark them for installation or removal, review proposed changes, and resolve dependency conflicts interactively. It provides a powerful alternative to command-line operations for complex package management tasks.


title: DEPENDENCY RESOLUTION
content:
One of <b>aptitude</b>'s most acclaimed features is its sophisticated dependency resolver. Unlike <b>apt-get</b>, which might refuse to proceed with broken dependencies, <b>aptitude</b> attempts to find a solution, even if it means suggesting the removal of conflicting packages or downgrading certain components. This makes it particularly useful for managing systems with complex or non-standard package configurations.


title: HISTORY
content:
<b>aptitude</b> was developed as a more feature-rich and user-friendly alternative to <b>apt-get</b> and <b>apt-cache</b>, aiming to combine their functionalities under a single, cohesive interface. It was particularly distinguished by its interactive Ncurses interface and its advanced dependency resolution capabilities, which often provided more intelligent solutions to complex dependency issues. Although <b>apt</b> has become the preferred command-line frontend for APT since its introduction around 2014, <b>aptitude</b> continues to be actively maintained and used by many Debian and Ubuntu power users for its unique strengths, especially its robust dependency solver and interactive mode.


title: PARAMETERS
content:
<b>--current-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only the current package selections (output of <i>dpkg --get-selections</i>) in the bundle, excluding other package information.<br><br><b>--apt-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only APT configuration files (<i>/etc/apt/sources.list</i> and <i>/etc/apt/preferences</i> directories) in the bundle, without package state.<br><br><b>--cache-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes only APT cache information (primarily the output of <i>apt-cache policy</i>) in the bundle.<br><br><b>--full-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all Aptitude configuration files, providing a more comprehensive view of Aptitude's settings.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message describing command usage and options, then exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's version information and exits.<br><br><b>FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The required argument specifying the path and filename for the output gzipped tar archive (e.g., <i>my-system-state.tar.gz</i>).<br><br>


title: DESCRIPTION
content:
The <i>aptitude-create-state-bundle</i> command generates a gzipped tar archive, often referred to as a 'state bundle,' that encapsulates the current state of the Aptitude package management system and relevant system information. This bundle is invaluable for reproducing a system's configuration for debugging purposes, particularly when reporting bugs related to Aptitude's behavior or complex package resolution issues. It typically includes critical files such as APT source lists (<i>/etc/apt/sources.list</i> and files in <i>/etc/apt/sources.list.d/</i>), APT preferences (<i>/etc/apt/preferences</i> and files in <i>/etc/apt/preferences.d/</i>), the output of <i>dpkg --get-selections</i>, Aptitude's internal state file (<i>/var/lib/aptitude/pkgstates</i>), a list of all installed packages, <i>apt-cache policy</i> output, and general system details. By providing a comprehensive snapshot, it helps developers and users understand and replicate specific package management scenarios, making bug identification and resolution significantly easier.


title: CAVEATS
content:
The generated state bundle can contain sensitive system configuration details. Care should be taken to ensure its security, especially when sharing it for bug reports. The command typically requires root privileges to access all necessary system files and directories to create a complete and accurate bundle.


title: CONTENTS OF THE STATE BUNDLE
content:
A typical state bundle generated by <i>aptitude-create-state-bundle</i> includes a variety of files and command outputs, such as:<br><br><ul><li>APT source list files (e.g., <i>/etc/apt/sources.list</i> and <i>/etc/apt/sources.list.d/*</i>)</li><li>APT preferences files (e.g., <i>/etc/apt/preferences</i> and <i>/etc/apt/preferences.d/*</i>)</li><li>Output of <i>dpkg --get-selections</i>, detailing package selections</li><li>Aptitude's internal state file (e.g., <i>/var/lib/aptitude/pkgstates</i>)</li><li>A list of all installed packages (from <i>dpkg -l</i>)</li><li>Output of <i>apt-cache policy</i> for relevant packages</li><li>System identification information (e.g., <i>lsb_release</i>, <i>uname -a</i>)</li><li>Aptitude version and relevant configuration files</li></ul>This comprehensive collection allows for a thorough analysis of the package system's exact state at the time the bundle was created.


title: HISTORY
content:
<i>aptitude-create-state-bundle</i> is a utility script that is part of the Aptitude package management suite, which serves as an interactive front-end to APT. Its development is intrinsically linked to the evolution of Aptitude itself, a prominent package manager on Debian-based systems since the early 2000s. This specific command was introduced to streamline the process of gathering comprehensive system state information, which is crucial for debugging complex package management issues and providing reproducible contexts for bug reports submitted by users to the Aptitude development team. It standardized the 'debug information' collection, making it easier for developers to assist users.


title: DESCRIPTION
content:
<i><b>aptitude-curses</b></i> is the full-screen, text-based interactive user interface for the <br><i><b>aptitude</b></i> package manager. <br><br>It leverages the <br><i><b>ncurses</b></i> library to provide a graphical, menu-driven environment within a terminal, allowing users to <br><i><b>browse available packages</b></i>, <br><i><b>search for software</b></i>, and <br><i><b>mark packages</b></i> for installation, removal, or upgrade.<br><br>One of its key strengths is its <br><i><b>sophisticated dependency resolution</b></i> capabilities, which can often suggest multiple solutions for dependency conflicts and allow the user to interactively choose the best path forward.<br><br>It presents package information, including descriptions, versions, sizes, and dependencies, in an organized layout. <br>While <br><i><b>aptitude-curses</b></i> is a standalone executable, it is most commonly invoked by simply running the <br><i><b>aptitude</b></i> command without any arguments, making it the default interactive mode for <br><i><b>aptitude</b></i>.


title: CAVEATS
content:
<i><b>aptitude-curses</b></i> requires a terminal emulator that fully supports the <br><i><b>ncurses</b></i> library. <br>While powerful for interactive use, it is <br><i><b>not suitable for scripting</b></i> as it's an interactive full-screen application. <br>For very large package lists or slow terminal connections, its performance might be <br><i><b>slower</b></i> compared to command-line tools like <br><i><b>apt</b></i> or <br><i><b>apt-get</b></i>. <br>Its extensive features and keybindings can have a <br><i><b>steep learning curve</b></i> for new users.


title: LAUNCHING APTITUDE-CURSES
content:
Although <br><i><b>aptitude-curses</b></i> is a standalone executable, it is most commonly launched by simply typing <br><i><b>aptitude</b></i> in the terminal without any command-line arguments. This default behavior of <br><i><b>aptitude</b></i> automatically brings up the interactive curses interface.


title: KEYBINDINGS AND INTERACTION
content:
The interface is highly interactive and driven by keyboard shortcuts. <br>Common actions include: <br><i><b>+</b></i> (mark for installation), <br><i><b>-</b></i> (mark for removal), <br><i><b>g</b></i> (go/apply changes), <br><i><b>/</b></i> (search), <br><i><b>?</b></i> (help/keybindings list), and arrow keys for navigation. <br>Its menu system allows for configuration of display options, fetching changelogs, and managing package states.


title: HISTORY
content:
The <br><i><b>aptitude</b></i> package manager was developed as an alternative to <br><i><b>apt-get</b></i>, aiming to provide a more advanced and robust dependency resolver. <br>The <br><i><b>ncurses</b></i>-based interactive interface (<br><i><b>aptitude-curses</b></i>) was a fundamental component of <br><i><b>aptitude</b></i> from its early stages, distinguishing it by offering a user-friendly, visual way to manage packages and resolve complex dependency issues.<br><br>It gained significant traction within the Debian and Ubuntu communities, particularly for users who preferred a guided, interactive approach to package management over command-line interfaces. <br>While the <br><i><b>apt</b></i> command has emerged as the preferred modern high-level command-line interface for many users, <br><i><b>aptitude</b></i> and its <br><i><b>curses</b></i> interface remain valuable tools, especially for scenarios requiring intricate dependency analysis or for users who appreciate its comprehensive interactive environment.


title: PARAMETERS
content:
<b><I>apt-uri</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Uniform Resource Identifier (URI) specifying the package(s) to install or an action to be performed. Examples include <I>apt:firefox</I> for installing Firefox, or <I>apt:thunderbird?section=main</I>.<br><br>


title: DESCRIPTION
content:
<i>apturl</i> is a specialized command-line utility primarily designed to handle <i>apt:</i> Uniform Resource Identifiers (URIs). These URIs serve as convenient links to software packages within the Debian and Ubuntu ecosystems. When a user clicks on an <i>apt:</i> link in a web browser, an email, or any document, the system typically invokes <i>apturl</i> to process it. <br><br>The tool parses the URI to identify the specified package(s) and then interacts with the underlying <b>APT</b> (Advanced Package Tool) system. Before making any changes, <i>apturl</i> usually prompts the user for confirmation, offering a safe way to install or remove software. It streamlines the process of acquiring recommended applications directly from web pages, bridging the gap between online content and the local package manager by correctly handling package dependencies and ensuring a smooth installation experience.


title: CAVEATS
content:
<b>Security Risk:</b> Clicking on <i>apt:</i> links from untrusted sources can lead to the installation of malicious software. Always verify the source before confirming any installation.<br><b>GUI Dependence:</b> While <i>apturl</i> is a command, it's primarily designed to work with desktop environments and GUI frontends (like <i>apturl-gtk</i>) that provide user confirmation dialogs. Direct command-line usage might require specific configurations for interactive prompts.<br><b>APT Reliance:</b> Relies entirely on the <b>APT</b> package management system and its repositories for package resolution and installation.


title: HOW IT WORKS WITH WEB BROWSERS
content:
Web browsers and other applications that encounter an <i>apt:</i> URI typically pass it to the system's default URI handler. On Linux desktops, this is often managed by <b>xdg-open</b>, which then dispatches the URI to <i>apturl</i>. <i>apturl</i> subsequently launches a graphical prompt (if available, e.g., via <i>apturl-gtk</i>) to confirm the installation with the user before proceeding via <b>APT</b>.<br><br>


title: APT: URI FORMAT
content:
An <i>apt:</i> URI generally follows the format <i>apt:<I>package_name</I></i>. More complex URIs can include multiple packages separated by commas (e.g., <i>apt:package1,package2</i>) or specify additional parameters like section, architecture, or release (e.g., <i>apt:vlc?section=video&architecture=amd64</i>). These parameters provide more specific instructions to <b>APT</b> regarding the package to be installed.


title: HISTORY
content:
The <i>apturl</i> utility emerged as a component of the Ubuntu and Debian desktop experience, specifically designed to enhance user convenience for software installation. Its development was driven by the need to simplify the process of installing applications directly from web pages or documentation without requiring users to manually open a terminal and type <b>apt install</b> commands. It serves as an integral part of the desktop's URI handling mechanism, typically invoked by browsers or file managers. It's often implemented in high-level scripting languages like Python, making it extensible and easily integrated into graphical environments.


title: PARAMETERS
content:
<b><b>-p</b>, <b>--individual-totals</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays connect time for each individual user.<br><br><b><b>-d</b>, <b>--daily-totals</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the total connect time for each day.<br><br><b><b>-y</b>, <b>--print-year</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>--daily-totals</b> to include the year in the daily output.<br><br><b><b>-f</b> <i>&lt;file&gt;</i>, <b>--file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads connect time data from the specified <i>wtmp</i> file instead of the default <i>/var/log/wtmp</i>.<br><br><b><b>--reboots</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes system reboots in the accounting.<br><br><b><b>--suppress-reboots</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes system reboots from the accounting.<br><br><b><b>--bad-dates</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints all records with bad time stamps.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose debugging information.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<b>ac</b> (access or accounting) is a utility that reports on system user connect times, calculated from login and logout entries in the <i>/var/log/wtmp</i> file.<br><br>By default, it outputs the total cumulative connect time for all users in hours. Users can specify options to view individual user totals, daily breakdowns, or process a different <i>wtmp</i> file. It's an essential tool for system administrators to monitor user activity and track resource usage over time. The output is typically in hours, providing a high-level overview of system access patterns.


title: CAVEATS
content:
<b>ac</b> relies on <i>wtmp</i> file integrity; a corrupted file can lead to inaccurate reports.<br><i>wtmp</i> can grow very large, affecting performance and disk space; it's often rotated by <b>logrotate</b>.<br><b>ac</b> only counts login/logout events, not active usage within a session.<br>Accuracy depends on proper system clock and time synchronization.


title: LOG FILE LOCATION
content:
The default <i>wtmp</i> file processed by <b>ac</b> is <i>/var/log/wtmp</i>. This file records all login, logout, and system reboot/shutdown events.


title: TIME UNIT
content:
All connect times reported by <b>ac</b> are in hours. Fractional hours are displayed as decimal values (e.g., 1.5 for one hour and thirty minutes).


title: HISTORY
content:
The <b>ac</b> command is part of the <i>GNU Accounting Utilities</i>, which have been a standard component of Unix-like operating systems for many years. Its purpose remains consistent: to provide a simple, cumulative report of user access times based on the <i>wtmp</i> log file. Its development has focused on maintaining compatibility with various system architectures and improving robustness in parsing potentially malformed log entries, rather than adding complex new features. It's a foundational utility for basic system usage monitoring.


title: SYNOPSIS
content:
<b>accelerate config</b><br><b>accelerate launch</b> [<i>OPTIONS</i>] <i>&lt;script_name&gt;</i> [<i>SCRIPT_ARGS</i>...]<br><b>accelerate test</b><br><b>accelerate env</b>


title: PARAMETERS
content:
<b><b>--config_file</b> <i>CONFIG_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a custom configuration file for <i>accelerate</i> settings.<br><br><b><b>--mixed_precision</b> {<i>no</i>,<i>fp16</i>,<i>bf16</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables training with mixed precision (e.g., half-precision floats for speed/memory).<br><br><b><b>--num_processes</b> <i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the total number of processes to launch across all machines.<br><br><b><b>--num_machines</b> <i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the total number of machines involved in a multi-node distributed setup.<br><br><b><b>--gpu_ids</b> <i>IDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of GPU IDs to use (e.g., '0,1,2').<br><br><b><b>--cpu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the training script to run exclusively on the CPU.<br><br><b><b>--deepspeed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates DeepSpeed integration for advanced model parallelism and optimization.<br><br><b><b>--fsdp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables PyTorch's Fully Sharded Data Parallel (FSDP) for large model training.<br><br><b><b>--main_process_ip</b> <i>IP_ADDRESS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;IP address of the main process machine for multi-node communication.<br><br><b><b>--main_process_port</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Port used by the main process for multi-node communication.<br><br><b><b>--log_with</b> {<i>all</i>,<i>tensorboard</i>,<i>wandb</i>,<i>comet_ml</i>,<i>clearml</i>}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the logging backend for tracking experiment metrics.<br><br><b><b>--project_dir</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the project directory for storing experiment tracking data.<br><br><b><b>--output_dir</b> <i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory for saving model checkpoints and training outputs.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more verbose output for troubleshooting.<br><br>


title: DESCRIPTION
content:
<i>accelerate</i> is a Command Line Interface (CLI) tool provided by the Hugging Face <i>accelerate</i> Python library. It is designed to abstract and simplify the complexities of running deep learning training scripts across various hardware configurations, including single-GPU, multi-GPU, distributed (DDP), and mixed-precision (FP16/BF16) environments. Rather than requiring developers to manually configure distributed training specifics, <i>accelerate</i> allows writing standard PyTorch or TensorFlow training loops that can be effortlessly scaled. The CLI primarily facilitates the configuration and launch of these training scripts, handling the underlying distributed communication, hardware allocation, and precision settings. It streamlines the development workflow by allowing a single script to run optimally from a local CPU to a multi-node GPU cluster.


title: CAVEATS
content:
<i>accelerate</i> is not a core Linux utility. It requires Python and must be installed via <i>pip</i> (e.g., <i>pip install accelerate</i>). It is primarily designed for PyTorch and TensorFlow deep learning frameworks, and its functionality is tied to the specific training scripts written using these libraries. While simplifying distributed training, advanced configurations may still require understanding underlying concepts.


title: HISTORY
content:
Developed by Hugging Face, the <i>accelerate</i> library and its CLI tool were introduced to address the growing complexity of distributed deep learning training. Its initial release, around late 2021 / early 2022, aimed to provide a high-level API that abstracts away the boilerplate code typically required for multi-GPU, multi-node, and mixed-precision training. It evolved to support various distributed strategies like DeepSpeed and FSDP, becoming a crucial tool for scaling Hugging Face Transformers models and other deep learning projects efficiently across diverse hardware setups.


title: SYNOPSIS
content:
The <I>acme.sh-dns</I> functionality is invoked as part of the <I>acme.sh</I> command. The general syntax for issuing a certificate using the DNS-01 challenge is:<br><br> <I>acme.sh</I> <I>--issue</I> <I>-d</I> <I>&lt;domain.com&gt;</I> [<I>-d</I> <I>&lt;another.com&gt;</I> ...] <I>--dns</I> [<I>&lt;dns_provider&gt;</I>] [<I>DNS_API_OPTIONS</I>]<br><br>For example, to issue a wildcard certificate for <I>example.com</I> using Cloudflare's DNS API:<br><br> <I>export CF_Token="s******s"</I><br> <I>export CF_Email="admin@example.com"</I><br> <I>acme.sh --issue -d example.com -d *.example.com --dns dns_cf</I><br><br>For manual DNS mode (without API):<br><br> <I>acme.sh --issue -d example.com --dns</I>


title: PARAMETERS
content:
<b>acme.sh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The main ACME client shell script executable.<br><br><b>--issue</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the certificate issuance process.<br><br><b>-d <domain> or --domain <domain></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the domain(s) for which to issue the certificate. Multiple -d flags can be used for SAN certificates.<br><br><b>--dns</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the DNS-01 challenge method. If no provider is specified (e.g., just '--dns'), it runs in manual mode, prompting the user to add the TXT record.<br><br><b>--dns <provider_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the DNS-01 challenge using a specific DNS API integration (e.g., <I>--dns dns_cf</I> for Cloudflare, <I>--dns dns_ali</I> for Alibaba Cloud DNS, <I>--dns dns_dp</I> for Dnspod). Requires corresponding API credentials set as environment variables.<br><br><b>DNS_API_OPTIONS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;These are environment variables specific to each DNS provider (e.g., <I>CF_Token</I>, <I>CF_Email</I> for Cloudflare; <I>DP_Id</I>, <I>DP_Key</I> for Dnspod). They must be set in the shell session before running the <I>acme.sh</I> command.<br><br>


title: DESCRIPTION
content:
The command <I>acme.sh-dns</I> refers to the functionality within the popular <I>acme.sh</I> ACME client for issuing SSL/TLS certificates using the <I>DNS-01 challenge</I> method.<br><br> <I>acme.sh</I> is a lightweight, pure Unix shell script designed to get certificates from Let's Encrypt (or other ACME CAs) with ease. Unlike the common HTTP-01 challenge which requires accessible ports 80/443 on the web server, the DNS-01 challenge verifies domain ownership by checking a specific <I>TXT record</I> in the domain's DNS zone. This method is particularly useful for servers behind restrictive firewalls, non-standard HTTP/HTTPS setups, or for issuing <I>wildcard certificates</I> (e.g., <I>*.example.com</I>), which strictly require DNS-01 validation.<br><br> <I>acme.sh</I> simplifies this process by integrating with a vast number of DNS service providers. Users provide API credentials for their DNS provider, and <I>acme.sh</I> automatically adds the necessary TXT record, waits for DNS propagation, completes the challenge, and then cleans up the record. This automation makes certificate issuance and renewal seamless, even for complex environments.


title: CAVEATS
content:
<b>DNS Propagation Time:</b> DNS changes can take time to propagate globally (up to several minutes or even longer for some providers). <I>acme.sh</I> typically waits for propagation, but delays can still cause challenge failures.<br><br><b>API Key Security:</b> DNS API credentials provide full control over your domain's DNS. They must be handled with extreme care and kept secure. Avoid storing them directly in scripts without proper permissions.<br><br><b>Provider Compatibility:</b> While <I>acme.sh</I> supports a large number of DNS providers, ensure your specific provider is supported and that its API is configured correctly.<br><br><b>Let's Encrypt Rate Limits:</b> Be mindful of Let's Encrypt's rate limits (e.g., certificates per registered domain, duplicate certificate limits) to avoid temporary bans during testing.


title: DNS-01 CHALLENGE EXPLAINED
content:
The DNS-01 challenge verifies domain ownership by requiring the ACME client to create a specific TXT record at <I>_acme-challenge.&lt;domain.com&gt;</I>. The CA then queries the DNS for this record. If the value matches the expected token, ownership is validated. This method is essential for wildcard certificates and hosts without direct web access.


title: SUPPORTED DNS PROVIDERS
content:
<I>acme.sh</I> boasts support for over 100 DNS API providers, ranging from major cloud DNS services like Cloudflare, AWS Route 53, Alibaba Cloud DNS, and Google Cloud DNS, to smaller, niche providers. The full list and specific environment variables required for each can be found in the <I>acme.sh</I> wiki or documentation.


title: AUTOMATIC RENEWAL
content:
A key advantage of using <I>acme.sh</I> with DNS API integration is the ability to fully automate certificate renewals. Once issued, <I>acme.sh</I> can be configured to automatically renew certificates before expiration, handling the DNS-01 challenge and record cleanup without manual intervention. This is typically set up via a cron job.


title: HISTORY
content:
<I>acme.sh</I> emerged as a lightweight, pure Unix shell script in the early days of Let's Encrypt, offering a simple and highly portable alternative to more complex ACME clients. Its development focused on ease of use and broad compatibility across various Linux/Unix environments. The integration of the DNS-01 challenge method, especially with automated DNS API support, was a significant milestone. This allowed users to obtain wildcard certificates and simplified automation for environments where HTTP-01 challenges were impractical. Over time, the list of supported DNS providers has grown substantially, making <I>acme.sh</I> a versatile tool for diverse infrastructure setups, solidifying its position as a popular choice for certificate management.


title: SYNOPSIS
content:
<br>N/A - Command not found<br><br>Since "acountry" is not a standard command, there is no predefined syntax or usage. Attempting to execute it will typically result in a "command not found" error.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No standard parameters exist for a non-existent command.<br><br>


title: DESCRIPTION
content:
The command "acountry" is <b>not</b> a standard Linux command found in common or enterprise-grade Linux distributions. It is highly probable that it is a misspelling of another command, such as <I>accton</I> (used for enabling/disabling process accounting) or <I>acct</I> (a package related to process accounting utilities). Alternatively, it could refer to a very specific, custom-developed script or alias on a particular system, or a command from an extremely niche or outdated software package not widely adopted.<br><br>Without further context, its intended functionality cannot be determined. Users encountering "acountry" in documentation or scripts should verify the spelling or seek clarification on its origin and purpose, as it is not part of the core GNU/Linux utilities or typical system administration tools.


title: CAVEATS
content:
Executing "acountry" will almost certainly result in a <I>command not found</I> error on any standard Linux distribution. If such a command exists on a specific system, it is a custom script, alias, or part of a non-standard application suite, and its behavior would be entirely dependent on its local definition. Using it without understanding its custom implementation could lead to unexpected results or security implications.


title: TYPOGRAPHICAL ERROR PROBABILITY
content:
Given the lack of documentation, it is highly probable that 'acountry' is a typographical error. Common candidates for correction include 'accton' or references to system 'account' management.


title: CUSTOM SCRIPT POTENTIAL
content:
If 'acountry' functions on a specific system, it is almost certainly a custom script or alias. System administrators often create such shortcuts for frequently used or complex operations. Users should investigate the system's PATH, aliases, and custom script directories (<I>/usr/local/bin</I>, <I>~/bin</I>, etc.) to understand its definition.


title: HISTORY
content:
There is no documented history for a standard Linux command named "acountry". It has never been part of common Unix or Linux distributions. Its appearance would indicate a modern misprint, a highly obscure utility, or a bespoke system customization.


title: SYNOPSIS
content:
<i>acpi_available</i> is not a directly executable command from the shell. It represents an internal check or API call within system software (like <b>acpid</b>, <b>upower</b>, or kernel modules) to determine the presence and functionality of the ACPI subsystem. There is no command-line syntax for <i>acpi_available</i> as a standalone utility.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As <i>acpi_available</i> is not a standalone command, it does not accept command-line parameters or options. Its "result" is typically an internal boolean (true/false) indicating ACPI availability, used by other programs.<br><br>


title: DESCRIPTION
content:
<i>acpi_available</i> is not a standalone, user-executable Linux command in the traditional sense. Instead, it refers to a conceptual check or an internal function/variable within system utilities and the kernel to determine if the Advanced Configuration and Power Interface (ACPI) subsystem is enabled and functioning on a given hardware platform. ACPI is crucial for modern operating systems like Linux to manage power, thermal events, battery status, and other hardware configurations efficiently. When a system or an application needs to interact with ACPI-driven features (e.g., suspend, hibernate, fan control, battery reporting), it first performs an "ACPI availability check" to ensure the necessary kernel modules and interfaces (often exposed via <b>/proc/acpi</b> or <b>/sys/firmware/acpi</b>) are present and accessible. This check confirms the system's ability to leverage ACPI for power management and hardware interaction.


title: CAVEATS
content:
The most important caveat is that <i>acpi_available</i> is <b>not a command you type</b> into the terminal. If you need to programmatically check for ACPI availability in a shell script, common methods involve:<br><br>1. Checking for the existence of <b>/proc/acpi</b>: <br><i>if [ -d /proc/acpi ]; then ... fi</i><br><br>2. Checking for the existence of <b>/sys/firmware/acpi</b>: <br><i>if [ -d /sys/firmware/acpi ]; then ... fi</i><br><br>The actual implementation of an "ACPI available" check can vary depending on the specific system utility or programming language used.


title: TYPICAL ACPI AVAILABILITY CHECKS IN SCRIPTS
content:
While not a direct command, the concept of checking ACPI availability is vital. In shell scripting, a common way to infer ACPI support is to check for the presence of the <i>/proc/acpi</i> directory or the <i>/sys/firmware/acpi</i> directory. These directories are populated by the kernel when ACPI is active and provide interfaces to ACPI events and information. For example, a script might contain: <br><i>if [ -d /sys/firmware/acpi ]; then<br>&nbsp;&nbsp;echo "ACPI is available."<br>else<br>&nbsp;&nbsp;echo "ACPI not detected."<br>fi</i>


title: HISTORY
content:
ACPI (Advanced Configuration and Power Interface) was introduced as a successor to APM (Advanced Power Management) in 1997, aimed at providing a more flexible and robust framework for power management, Plug and Play, and configuration in operating systems. Linux adopted ACPI support early on, with its integration evolving significantly over kernel versions. The concept of <i>acpi_available</i> emerged implicitly with this integration, as power management tools and kernel modules needed a standardized way to ascertain if the underlying hardware and kernel support for ACPI were present and usable. This check became fundamental for modern Linux distributions to correctly manage power states, battery life, and thermal controls on diverse hardware.


title: SEE ALSO
content:
acpid(8) - ACPI daemon for event handling, upower(7) - D-Bus interface for power management, proc(5) - Pseudo-filesystem providing process and kernel information, sys(5) - Pseudo-filesystem providing kernel data structures


title: SYNOPSIS
content:
add-shell <i>shell_path</i> [<i>options</i>]<br><i>(Hypothetical syntax for a non-standard command)</i><br><br><b>Practical Equivalent:</b><br>echo "<i>shell_path</i>" | sudo tee -a /etc/shells


title: PARAMETERS
content:
<b><i>shell_path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The absolute path to the shell executable to be added to `/etc/shells`. This argument would be mandatory.<br><br><b>--force, -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Hypothetical</i>) Force the addition of the shell path, even if the specified file does not exist or is not executable. Use with extreme caution.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Hypothetical</i>) Show what action would be taken without actually modifying `/etc/shells`.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Hypothetical</i>) Display usage information and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>Hypothetical</i>) Display version information and exit.<br><br>


title: DESCRIPTION
content:
The command `add-shell` is <i>not</i> a standard Linux command found in typical distributions. If such a command existed, its primary purpose would be to register a new shell executable's path in the system's list of valid login shells. This crucial list is maintained in the `/etc/shells` file. Services like `login(1)`, `chsh(1)`, and `ftpd(8)` consult `/etc/shells` to verify if a user's assigned shell is legitimate and secure. By adding a shell's path to `/etc/shells`, administrators enable users to safely switch to or be assigned alternative shells (e.g., custom builds, non-standard interpreters like `fish` or `zsh` if not installed via package managers). Without an entry in `/etc/shells`, a user might be denied login or face other authentication issues if their assigned shell is not recognized as valid by the system. In practice, new shells are typically added to this file automatically when a package manager installs a new shell, or manually by system administrators using text editors or `echo` commands. This analysis provides a hypothetical structure for what an `add-shell` command <i>would</i> look like, based on its implied functionality.


title: CAVEATS
content:
The command `add-shell` is <i>not</i> a standard utility in most Linux distributions. Functionality to add shells to `/etc/shells` is usually handled implicitly by package managers when installing a new shell (e.g., `apt`, `yum`, `dnf`), or explicitly by system administrators through manual editing of the `/etc/shells` file (e.g., using `echo "path/to/shell" | sudo tee -a /etc/shells`).<br><br>Directly manipulating `/etc/shells` requires root privileges. Incorrect modifications can lead to severe security vulnerabilities or prevent users from logging in if their assigned shell is invalid or points to a non-existent or malicious executable. Always ensure the shell path is correct, the executable is legitimate, and its permissions are secure before adding it to `/etc/shells`.


title: MANUAL ADDITION OF SHELL PATHS
content:
Since `add-shell` is not a standard command, the typical way to add a shell path to `/etc/shells` is manually. You can use the `echo` command combined with `sudo` and `tee` to append the path. For example, to add `/usr/local/bin/myshell`:<br><b>echo "/usr/local/bin/myshell" | sudo tee -a /etc/shells</b><br><br>Remember that `tee -a` appends to the file. Always verify the path exists and the shell is executable before adding it to ensure system stability and security. You can verify the contents after modification using `<b>cat /etc/shells</b>`.


title: IMPACT ON SYSTEM SECURITY
content:
Adding arbitrary or unverified executable paths to `/etc/shells` can pose a significant security risk. If an attacker gains control over a path listed in `/etc/shells` and replaces the legitimate shell with a malicious script, they could potentially execute commands as other users or gain unauthorized access. Therefore, only trusted and properly secured shell executables should ever be listed in `/etc/shells`.


title: HISTORY
content:
The concept of a dedicated `add-shell` command has not gained widespread adoption in mainstream Linux distributions. Historically, the management of valid system shells has been straightforward: either shells are installed via the system's package manager (which typically handles adding the shell's path to `/etc/shells` as part of the installation script), or administrators manually append new shell paths to the `/etc/shells` file. This manual approach, combined with the infrequent need to add custom shells, has likely precluded the development and standardization of a specific `add-shell` utility. Instead, existing tools like `chsh` rely on the integrity of `/etc/shells`, which is maintained either by the package system or direct administrative intervention.


title: SYNOPSIS
content:
<b>Encrypting:</b><br><i>age</i> [<i>OPTIONS</i>] -o <I>OUTPUT_FILE</I> <I>INPUT_FILE</I><br><i>age</i> [<i>OPTIONS</i>] < <I>INPUT_FILE</I> > <I>OUTPUT_FILE</I><br><br><b>Decrypting:</b><br><i>age</i> -d [<i>OPTIONS</i>] -o <I>OUTPUT_FILE</I> <I>INPUT_FILE</I><br><i>age</i> -d [<i>OPTIONS</i>] < <I>INPUT_FILE</I> > <I>OUTPUT_FILE</I>


title: PARAMETERS
content:
<b>-o, --output FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file. If not provided, output goes to standard output.<br><br><b>-d, --decrypt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypt the input. This option changes the command's mode from encryption to decryption.<br><br><b>-a, --armor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypt to a PEM encoded, ASCII armored format. Useful for sharing via text-based channels.<br><br><b>-R, --recipient-file FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add recipients from a file, where each line in the file contains a recipient's public key or identity.<br><br><b>-r, --recipient RECIPIENT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a recipient directly using their public key (e.g., age1..) or an SSH public key.<br><br><b>-i, --identity FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add identities (private keys) from a file for decryption. Can be age private keys or SSH private keys.<br><br><b>-p, --passphrase</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypt or decrypt using a passphrase. The passphrase will be prompted interactively.<br><br><b>-P, --passphrase-file FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypt or decrypt using a passphrase read from the specified file.<br><br><b>--fido</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a FIDO2 authenticator for identity (decryption).<br><br><b>--ssh-target TARGET</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When adding recipients from SSH public keys, specify which SSH key type (e.g., `ssh-ed25519` or `ssh-rsa`) to target.<br><br><b>--local-ssh-identities</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use identities found in common SSH identity locations (e.g., `~/.ssh/id_*`).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the encryption/decryption process.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version information and exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>age</i> is a simple, modern, and secure file encryption tool designed for ease of use and robust security. It's built to be a more user-friendly and cryptographically sound alternative to older encryption utilities like GPG, especially for stream encryption. Unlike GPG, <i>age</i> focuses on a minimal and opinionated design, supporting only a few secure cryptographic primitives (currently X25519, ChaCha20-Poly1305, and HKDF).<br><br>It supports multiple recipients and different types of identities for decryption, including X25519 keys, SSH keys (both Ed25519 and RSA), passphrases, and FIDO2 authenticators. Its design prioritizes forward secrecy and resistance to common cryptographic attacks. <i>age</i> can encrypt arbitrary data streams, making it suitable for piping with other commands like <i>tar</i> or <i>dd</i>. It provides a clean, human-readable ASCII-armored format for encrypted files, making them easy to share or store.


title: CAVEATS
content:
<i>age</i> does not perform compression or archiving itself; users typically pipe its output/input to/from tools like <i>tar</i> and <i>gzip</i> for these purposes. While it supports SSH keys, it does not directly integrate with `ssh-agent` for managing private keys. Its relatively younger age compared to GPG means a smaller ecosystem and fewer features beyond its core encryption purpose.


title: KEY TYPES AND IDENTITIES
content:
<i>age</i> supports several key types for both encryption (recipients) and decryption (identities):<br><ul><li><b>X25519 Keys:</b> Native <i>age</i> keys, which can be generated using <i>age-keygen</i>.</li><li><b>SSH Keys:</b> Supports both Ed25519 and RSA public keys as recipients, and their corresponding private keys as identities for decryption. This allows users to leverage existing SSH key infrastructure.</li><li><b>Passphrases:</b> Simple password-based encryption/decryption.</li><li><b>FIDO2:</b> Allows using FIDO2 compatible security keys for decryption.</li></ul>


title: STREAMING ENCRYPTION
content:
<i>age</i> is designed to work efficiently with data streams. It reads from standard input and writes to standard output by default, making it ideal for piping with other commands. For example, `tar -cvz folder/ | age -r age1... -o encrypted.tar.gz.age` encrypts a gzipped tarball directly.


title: HISTORY
content:
<i>age</i> was created by Filippo Valsorda, a cryptographer who also works on the Go programming language team at Google. It was designed as a modern, simpler, and more secure alternative to the traditional GNU Privacy Guard (GPG) for file encryption. Valsorda aimed to address common pitfalls and complexities associated with GPG, particularly regarding key management and cryptographic defaults. The project gained significant attention for its clear design principles, robust cryptography (using X25519 for key agreement and ChaCha20-Poly1305 for authenticated encryption), and support for SSH keys as a convenient identity method. It is written in Go, which contributes to its cross-platform compatibility and ease of deployment.


title: PARAMETERS
content:
<b><b>-i &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>input_file</i> (e.g., .cap or .pcap) to be processed. This file contains the raw wireless capture data.<br><br><b><b>-o &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>output_file</i> where the cleaned capture data will be written. This file will be suitable for further analysis.<br><br><b><b>-r &lt;rules_file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a <i>rules_file</i>, which is a text file containing custom rules to detect and remove specific patterns of cloaked frames. This allows for more targeted and effective cloaking removal.<br><br><b><b>-s &lt;essid&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters frames based on the specified ESSID (network name). Only frames belonging to this ESSID will be considered for processing.<br><br><b><b>-t &lt;bssid&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters frames based on the specified BSSID (MAC address of the Access Point). Only frames from this AP will be processed.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in quiet mode, suppressing non-essential output messages.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in verbose mode, providing more detailed output about the processing, including identified cloaking patterns.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits, showing available command-line options.<br><br>


title: DESCRIPTION
content:
<i>airdecloak-ng</i> is a specialized utility within the <i>aircrack-ng</i> suite designed to clean and prepare wireless capture files (typically in .cap or .pcap format) for subsequent analysis, especially for cracking WEP/WPA keys with <i>aircrack-ng</i>.<br><br>Many access points (APs) employ techniques, known as 'cloaking', to hinder attempts at WEP/WPA key cracking. These methods can involve injecting a large number of bogus frames, repeating Initialization Vectors (IVs), or otherwise manipulating network traffic to confuse analysis tools and artificially inflate IV counts, making it harder to distinguish legitimate data and thus crack the encryption key.<br><br><i>airdecloak-ng</i>'s primary function is to identify and remove these cloaking artifacts from the capture file. By filtering out the noise and illegitimate traffic, it produces a 'cleaner' capture file that is more accurate and efficient for <i>aircrack-ng</i> to process, significantly improving the chances of successfully cracking the WEP or WPA passphrase.


title: CAVEATS
content:
<i>airdecloak-ng</i> is primarily effective against known cloaking techniques and may not fully de-cloak all types of obfuscation, especially newer or proprietary methods. Its effectiveness heavily relies on the quality of the input capture and, for advanced removal, the comprehensiveness of the provided rules file. It does not perform key cracking; its role is solely data preparation.


title: RULES FILE FORMAT
content:
The rules file (specified with <b>-r</b>) is a plain text file where each line defines a pattern for identifying bogus frames. While specific formats can vary, typical rules might involve hexadecimal byte sequences, frame types, or IV patterns that are indicative of cloaking. Creating effective rules requires a good understanding of network protocols and cloaking methods.


title: INTEGRATION WITH AIRCRACK-NG SUITE
content:
<i>airdecloak-ng</i> is intended to be used as a pre-processing step. The output file generated by <i>airdecloak-ng</i> should then be fed as input to <i>aircrack-ng</i> for the actual WEP or WPA key cracking process, or to other tools for further analysis.


title: HISTORY
content:
<i>airdecloak-ng</i> emerged as a necessary component of the <i>aircrack-ng</i> suite to counter the evolving anti-cracking measures implemented by some wireless access point manufacturers. As WEP and WPA cracking became more prevalent, vendors began to introduce cloaking techniques to protect their networks. <i>airdecloak-ng</i> was developed to address this challenge, providing a tool to pre-process capture files and make them amenable to successful key cracking with <i>aircrack-ng</i>.


title: SYNOPSIS
content:
<b>amap</b> [<i>options</i>] <<i>target</i>> <<i>port(s)/portrange</i>><br>
<b>amap</b> [<i>options</i>] -i <<i>inputfile</i>><br><br>
<i>Examples:</i><br>
<b>amap</b> 192.168.1.1 80 443 21-23<br>
<b>amap</b> -u -p 10.0.0.5 53<br>
<b>amap</b> -i hosts_and_ports.txt -o results.amap


title: PARAMETERS
content:
<b><target></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The IP address or hostname of the target machine to scan.<br><br><b><port(s)/portrange></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A single port, a comma-separated list of ports, or a port range (e.g., 21-23, 80, 443) to scan on the target.<br><br><b>-i <inputfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads target hosts and ports from the specified input file. The file should list 'host port' pairs per line.<br><br><b>-o <outputfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes scan results to the specified output file.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a UDP scan instead of the default TCP scan.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables slow scan mode, which tries more probes and waits longer for responses for potentially more accurate results.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs banner grabbing only, without applying full protocol analysis. Useful for quick initial checks.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ping hosts before scanning. Useful if ping is blocked or not desired.<br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print application data in the output, only the identified protocol.<br><br><b>-B</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always print banner grabs for identified services.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity level for more detailed output.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not connect to ports, only use banner grabbing if the connection is already established (e.g., via -l).<br><br><b>-H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not resolve hostnames (no DNS lookups) for targets.<br><br><b>-t <timeout></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TCP connection timeout in milliseconds. Default is usually 5000ms.<br><br><b>-c <concurrency></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of concurrent connections or probes. Default is often 64.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses error messages and non-critical output.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>amap</b> version information.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with available options.<br><br>


title: DESCRIPTION
content:
<b>amap</b> (Asynchronous MApPer) is a powerful network scanning tool designed to identify the application layer protocols running on specified ports, even if they are not standard or are encapsulated. Unlike traditional port scanners that simply report an open port, <b>amap</b> goes further by sending a series of application-layer trigger packets (probes) and analyzing the responses. This allows it to accurately fingerprint the specific service, such as HTTP, SSH, FTP, or even unknown custom protocols, regardless of the port number they are listening on. This capability makes <b>amap</b> an invaluable tool for security auditors, penetration testers, and system administrators who need to gain a precise understanding of the services exposed on a network, especially when dealing with non-standard configurations or obfuscated services. It can handle both TCP and UDP services and includes support for SSL/TLS encrypted protocols. <b>amap</b> offers various scanning modes, from quick default scans to more exhaustive 'slow' scans that try more aggressive probes.


title: CAVEATS
content:
<b>amap</b> can generate a significant amount of network traffic and may be slower than basic port scanners due to its in-depth probing. While effective, its accuracy depends on its internal signature database and the service's adherence to known protocols. It is important to note that using <b>amap</b> against systems without explicit permission is generally considered unethical and potentially illegal. Always ensure you have proper authorization before performing any network scanning.


title: SIGNATURE DATABASE
content:
<b>amap</b> relies on an internal signature database to identify protocols. This database contains patterns of expected responses for various services. While powerful, it means that very new or highly custom protocols might not be identified without external definition files or manual analysis.


title: USAGE IN SECURITY AUDITS
content:
Due to its ability to identify actual services regardless of port, <b>amap</b> is crucial in security audits for discovering hidden or unexpected services that could pose security risks. It helps in mapping the true attack surface of a network.


title: HISTORY
content:
<b>amap</b> was developed by Gordon Lyon (Fyodor), the same creator of the widely popular Nmap security scanner. It emerged as a complementary tool to Nmap, specifically addressing the challenge of accurate application protocol identification on non-standard ports. While Nmap's service detection is robust, <b>amap</b> was designed to be more aggressive and focused on identifying services even when they try to masquerade or use unusual port assignments. It's often used in conjunction with Nmap in advanced penetration testing and network auditing scenarios.


title: SYNOPSIS
content:
<b>anbox</b> {<i>COMMAND</i>} [<i>OPTIONS</i>]<br><br>Common <i>COMMANDS</i> include:<br>&nbsp;&nbsp;<b>session-manager</b><br>&nbsp;&nbsp;<b>system-info</b><br>&nbsp;&nbsp;<b>launch</b><br>&nbsp;&nbsp;<b>help</b>


title: PARAMETERS
content:
<b><b>session-manager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Anbox session manager, responsible for managing the Android container and its lifecycle.<br><br><b><b>system-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the Anbox environment, including kernel module status, paths, and system capabilities.<br><br><b><b>launch --package</b> <i>&lt;package_name&gt;</i> <b>--component</b> <i>&lt;component_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches a specific Android application by its package name and component (activity) name.<br><br><b><b>help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the <b>anbox</b> command or its subcommands.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug output, providing more verbose logging for troubleshooting.<br><br><b><b>--gles-driver</b> <i>&lt;driver&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <b>session-manager</b>) Specifies the GLES driver to be used by the Android container (e.g., <i>host-mesa</i>).<br><br><b><b>--gles-driver-path</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <b>session-manager</b>) Specifies the filesystem path to the GLES driver library.<br><br><b><b>--enable-root-container</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <b>session-manager</b>) Allows the Android container to run with root privileges. Use with caution.<br><br>


