# CommandSection

title: PARAMETERS
content:
<b><I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the script or file containing commands to be executed. If <I>filename</I> does not contain a slash ('/'), its lookup behavior can vary. POSIX shells typically do not search the <I>PATH</I> for it, expecting an explicit path or a command built-in. However, many interactive shells (like Bash, Zsh) will search for the file in the directories specified by the <I>PATH</I> environment variable.<br><br><b>[<I>arguments</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments passed to the sourced file. These arguments become the positional parameters (<I>$1</I>, <I>$2</I>, etc.) within the context of the executing file, temporarily replacing the current positional parameters of the calling shell. The original positional parameters are restored upon completion of the sourced file.<br><br>


title: DESCRIPTION
content:
The '<b>.</b>' command, also widely known by its more readable alias '<b>source</b>', is a fundamental shell <I>built-in</I> command. Its primary function is to read and execute commands from a specified file directly within the <I>current</I> shell environment. This behavior stands in contrast to executing a script directly (e.g., './myscript.sh'), which typically involves creating a new subshell process to run the commands. Because '<b>.</b>' executes in the existing shell, any changes made by the sourced file—such as defining new environment variables, modifying existing ones (like <I>PATH</I> or <I>PS1</I>), setting shell options, defining functions, or changing the current working directory—will persist in the shell from which the command was invoked.<br><br>This capability is invaluable for shell scripting and configuration. It is commonly used to load configuration files like <I>.bashrc</I>, <I>.profile</I>, or <I>.zshrc</I> at the start of a shell session, activate Python virtual environments, or load shell completion scripts for various commands. While '<b>source</b>' is often preferred for clarity and originated in C shell, '<b>.</b>' is the POSIX standard equivalent supported across a wider range of Bourne-compatible shells.


title: CAVEATS
content:
<b>Security Risk:</b> Sourcing an untrusted file is highly dangerous. Commands within the file are executed with the full privileges of the current user directly in the active shell. This allows malicious scripts to perform arbitrary actions, including modifying critical environment variables, deleting files, or executing system commands without prompting.<br><b>Path Resolution Differences:</b> As noted above, the behavior for resolving <I>filename</I> when it doesn't contain a slash varies between POSIX standards and common interactive shells (e.g., Bash). This can lead to unexpected 'file not found' errors or unintended execution of different files.<br><b>Error Handling:</b> By default, if a command within the sourced file fails, the sourcing process continues. To make the shell exit upon an error in a sourced file, you typically need to set the '<b>-e</b>' option (e.g., '<b>set -e</b>') in the current shell or within the file itself.


title: BUILT-IN NATURE
content:
Both '<b>.</b>' and '<b>source</b>' are shell built-ins. This means they are commands executed directly by the shell itself, rather than external programs located in directories like <I>/bin</I> or <I>/usr/bin</I>. Their built-in status is fundamental to their ability to modify the calling shell's environment, as external programs would run in separate processes and thus cannot affect the parent shell's state directly.


title: EXIT STATUS
content:
The exit status of '<b>.</b>' (or '<b>source</b>') is determined by the exit status of the <I>last command</I> executed within the sourced file. If the file cannot be found, opened, or read due to permissions or other issues, the '<b>.</b>' command itself will typically return a non-zero exit status, such as 1 or 127, depending on the shell and the specific error.


title: HISTORY
content:
The concept of executing commands within the current shell's environment was pioneered by the C shell (<I>csh</I>) with its '<b>source</b>' command. This innovation allowed scripts to modify the environment of their caller, a capability not possible with traditional <I>fork-exec</I> based script execution models where scripts run in isolated subshells. When the POSIX standard was developed for the Bourne shell (<I>sh</I>) and its descendants, it adopted this crucial functionality, but designated the single character '<b>.</b>' (dot) as the standard command. Modern shells like Bash, Zsh, and Ksh typically support both '<b>.</b>' (for POSIX compliance) and '<b>source</b>' (often as a more user-friendly alias or for backward compatibility with C shell and older conventions), making them effectively interchangeable in most contexts.


title: DESCRIPTION
content:
The <b>2048</b> Linux command provides a <i>console-based</i> version of the popular single-player sliding block puzzle game.<br><br>Players navigate a 4x4 grid, merging numbered tiles to achieve a tile with the value 2048. Starting with two tiles, typically 2 or 4, players use arrow keys to slide all tiles in one of four directions (up, down, left, right). When two tiles with the same number collide during a move, they merge into a single tile with the sum of their values (e.g., two 2s become a 4, two 4s become an 8). A new 2 or 4 tile randomly appears on an empty spot after each move.<br><br>The objective is to reach the <i>2048 tile</i>, but the game can continue beyond that. The game ends when no more moves are possible (the grid is full and no adjacent tiles can merge). This terminal adaptation typically utilizes libraries like <i>ncurses</i> for a rich, interactive text-based interface, making it a lightweight and accessible form of entertainment on various Linux environments, including servers.


title: CAVEATS
content:
The terminal version of <b>2048</b> often lacks advanced features found in graphical versions, such as save/load game states or sound effects. Game progress is typically lost upon exiting the command. Compatibility with specific terminal emulators and font configurations may vary, potentially affecting visual rendering or color display. Performance can also be affected by terminal responsiveness.


title: CONTROLS
content:
Gameplay typically relies on the <i>arrow keys</i> (Up, Down, Left, Right) to slide tiles across the grid. To quit the game, users usually press 'q' or 'Ctrl+C'.


title: HISTORY
content:
The original <b>2048</b> game was created by Italian web developer <i>Gabriele Cirulli</i> in March 2014 as a simple web-based game. Its open-source nature and viral popularity quickly led to numerous ports and adaptations across various platforms. The Linux command-line version emerged soon after, developed by various contributors leveraging terminal interface libraries like <i>ncurses</i> to bring the addictive gameplay to the command line, allowing users to play the game on minimal systems or even SSH sessions.


title: SEE ALSO
content:
<i>ncurses</i>(3) - Terminal user interface library, <i>tetris</i>(6) - Another classic terminal-based game, <i>snake</i>(6) - A simple terminal arcade game


title: SYNOPSIS
content:
<b>2to3</b> [<i>options</i>] <i>file_or_directory</i> ...<br><b>2to3</b> <i>-f</i> <<i>fixer</i>> | <i>--fix</i> <<i>fixer</i>> ... [<i>-x</i> <<i>fixer</i>> | <i>--nofix</i> <<i>fixer</i>> ...] [<i>-w</i> | <i>--write</i>] [<i>-n</i> | <i>--no-backup</i>] [<i>-o</i> <<i>dir</i>> | <i>--output-dir</i> <<i>dir</i>>] [<i>--diffs</i> | <i>--no-diffs</i>] [<i>--add-fixer</i> <<i>fixer</i>>] [<i>--list-fixers</i>] [<i>-v</i> | <i>--verbose</i>] <i>path</i> ...


title: PARAMETERS
content:
<b>-w, --write</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the modified files back to their original locations. Creates a `*.bak` backup unless `-n` is used.<br><br><b>-n, --no-backup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't create `*.bak` backup files when writing changes with `-w`.<br><br><b>-o <dir>, --output-dir <dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write converted files to a specified output directory instead of overwriting original files. Directory must exist.<br><br><b>-f <fixer>, --fix <fixer></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only run specified fixers. This option can be used multiple times to specify several fixers.<br><br><b>-x <fixer>, --nofix <fixer></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not run specified fixers. This option can be used multiple times to exclude several fixers.<br><br><b>--add-fixer <fixer></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a custom fixer from a specified path. This allows using user-defined transformation rules.<br><br><b>--list-fixers</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available fixers. Useful for understanding what transformations <i>2to3</i> can perform.<br><br><b>--diffs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always show diffs of the changes, even when writing files (with `-w`).<br><br><b>--no-diffs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show diffs of the changes, even when not writing files.<br><br><b>-p <num>, --processes <num></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run `num` fixers in parallel. Useful for speeding up conversion of large codebases.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print more information about the conversion process, including which fixers are being applied.<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 this help message and exit.<br><br>


title: DESCRIPTION
content:
<i>2to3</i> is a Python program that reads Python 2.x source code and applies a series of 'fixers' to transform it into valid Python 3.x code. It's a standard utility included with Python distributions, designed to assist developers in migrating their projects from the older Python 2 syntax and features to the newer Python 3. This tool automates many of the common code changes, such as print statements to print functions, `xrange` to `range`, integer division, and various module renames.<br><br>While `2to3` handles a significant portion of the conversion, it is not always perfect, especially with more complex codebases or those relying heavily on specific Python 2 library behaviors that have no direct Python 3 equivalent. It typically works by analyzing the code, proposing changes, and either displaying a diff or writing the modified code to new files (optionally creating backups). It serves as a valuable first step in the migration process, significantly reducing manual effort.


title: CAVEATS
content:
<i>2to3</i> primarily handles syntactic and built-in function changes; it does not automatically convert all Python 2 libraries or APIs to their Python 3 equivalents. Manual refactoring is often required for dependencies. It may not always produce perfectly idiomatic Python 3 code. Some converted constructs might be suboptimal and benefit from further manual optimization. Complex uses of `unicode` vs. `bytes`, `long` integers, or specific metaclass patterns may require significant manual review and adjustment after `2to3` runs. The tool is designed for one-way conversion; there is no `3to2` counterpart.


title: FIXERS
content:
<i>2to3</i> works by applying a collection of modular transformation rules called 'fixers.' Each fixer addresses a specific change between Python 2 and Python 3, such as `print` statement conversion, `exec` statement to function, dictionary methods like `iteritems`, and changes to `raise` syntax. Users can select which fixers to run (or exclude) to fine-tune the conversion process.


title: TYPICAL USAGE
content:
To preview changes for a single file without writing: <br> `<b>2to3 my_script.py</b>`<br><br>To convert a directory of code and write changes, creating backups: <br> `<b>2to3 -w my_project_dir/</b>`<br><br>To convert and write without backups, only applying specific fixers: <br> `<b>2to3 -w -n -f print -f xrange my_project_dir/</b>`


title: HISTORY
content:
The <i>2to3</i> utility was first introduced as a major component of the Python 3.0 release in 2008. Its primary goal was to ease the transition for developers and projects from the widely used Python 2.x series to the backward-incompatible Python 3.x series. Over the years, as Python 3 gained adoption and Python 2 approached its official end-of-life (January 1, 2020), the command's central role in new development diminished. However, it remains an indispensable tool for maintaining or porting older Python 2 codebases that are still in use or require migration to modern Python environments. Its development has focused on refining existing fixers and adding new ones to cover more transformation cases, though its active development has naturally slowed post-Python 2 EOL.


title: SYNOPSIS
content:
<b>7z</b> <i>&lt;command&gt;</i> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] [<i>@listfile</i>]<br><br>Common commands:<br><br><b>7z a</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] <i>&lt;directories&gt;</i>... <br><br><b>7z e</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] <br><br><b>7z x</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] <br><br><b>7z l</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> <br><br><b>7z d</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] <br><br><b>7z t</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> <br><br><b>7z u</b> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...]


title: PARAMETERS
content:
<b>a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add files to archive.<br><br><b>e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files from archive (without full path, extracts to current directory or specified output directory).<br><br><b>x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files with full path (extracts preserving the original directory structure).<br><br><b>l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List contents of archive.<br><br><b>d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete files from archive.<br><br><b>t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test integrity of archive.<br><br><b>u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update files in archive (add new files, update modified ones).<br><br><b>-o{dir}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify output directory for extraction. Example: -o/tmp/extracted.<br><br><b>-p{password}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set password for encryption/decryption of archives.<br><br><b>-m{method_params}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression method and parameters. Example: -m0=Copy (no compression), -mx9=LZMA:a=2:d=256m.<br><br><b>-mx{N}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression level. N can be 0 (Copy), 1 (Fastest), ..., 9 (Ultra). Default is typically 5 (Normal).<br><br><b>-sfx[{name}.sfx]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a self-extracting archive. The executable extracts itself when run.<br><br><b>-v{size}[b|k|m|g]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create volumes (split archive) of a specified size. Example: -v10m for 10MB volumes.<br><br><b>-r[-|0]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse subdirectories for adding files. -r enables, -r- or -r0 disables.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume Yes on all queries (non-interactive mode).<br><br><b>-ir{file_mask}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include files by name or mask when archiving or extracting. Example: -ir*.txt.<br><br><b>-xr{file_mask}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude files by name or mask when archiving or extracting. Example: -xr*.bak.<br><br>


title: DESCRIPTION
content:
<b>7z</b> is a command-line file archiver that provides a high compression ratio. It is the Linux/Unix port of the popular <i>7-Zip</i> archiver for Windows, part of the p7zip project. It primarily uses the <i>LZMA</i> and <i>LZMA2</i> compression methods, known for their excellent efficiency, especially for large files. <b>7z</b> supports its native <i>7z</i> archive format, which often yields significantly smaller file sizes compared to <i>ZIP</i> or <i>GZIP</i>. Beyond <i>7z</i>, it can pack and unpack <i>ZIP</i>, <i>GZIP</i>, <i>BZIP2</i>, <i>TAR</i>, and <i>XZ</i> archives. It also supports unpacking many other formats, including <i>AR</i>, <i>CPIO</i>, <i>DEB</i>, <i>DMG</i>, <i>ISO</i>, <i>RPM</i>, <i>WIM</i>, and <i>Z</i>. Key features include strong AES-256 encryption for <i>7z</i> and <i>ZIP</i> formats, the ability to create self-extracting archives, and support for splitting archives into multiple volumes. <b>7z</b> is a versatile tool for data compression and archiving, suitable for various use cases from backup to software distribution.


title: CAVEATS
content:
<b>7z</b> is not always pre-installed on Linux distributions and typically requires installing the <i>p7zip-full</i> package. Users should be aware of the distinction between the <b>e</b> (extract without full path) and <b>x</b> (extract with full path) commands, as they affect the directory structure upon extraction. While offering excellent compression, higher compression levels (e.g., <b>-mx9</b>) can be very CPU and memory intensive, especially for large archives, leading to significantly slower operations for both compression and decompression. The <i>7z</i> format, while efficient, may not be as universally supported as <i>ZIP</i> or <i>TAR.GZ</i> on systems without <b>7z</b> tools installed, which might require recipients to install specific software.


title: LICENSING
content:
The majority of the <b>7z</b> (<i>p7zip</i>) source code is distributed under the GNU LGPL license. However, the unRAR code, which allows <b>7z</b> to unpack RAR archives, is under a different, more restrictive license, which might affect commercial redistribution of compiled binaries in some contexts.


title: SELF-EXTRACTING ARCHIVES (SFX)
content:
The <b>-sfx</b> switch allows the creation of self-extracting archives. These are executable files (typically <i>.exe</i> on Windows, or a shell script on Linux) that contain the archived data and an integrated decompression engine. This means the recipient does not need to have <b>7z</b> or any other archiving software installed to extract the contents, making distribution simpler.


title: ENCRYPTION
content:
<b>7z</b> provides strong encryption capabilities, supporting AES-256 for both <i>7z</i> and <i>ZIP</i> formats. This allows users to protect sensitive data within archives using a password, ensuring confidentiality during storage or transmission. It's important to remember a forgotten password will render the encrypted archive irrecoverable.


title: HISTORY
content:
The <b>7z</b> command is the command-line interface for <i>7-Zip</i>, a file archiver originally developed by Igor Pavlov. The first public release of <i>7-Zip</i> for Windows was in 1999. The Linux/Unix port, known as <i>p7zip</i>, brought the advanced compression capabilities of <i>7-Zip</i> to these platforms. Its development was primarily driven by the introduction and refinement of the <i>LZMA</i> (Lempel-Ziv-Markov chain Algorithm) compression method, which offers exceptionally high compression ratios, often outperforming older methods like <i>Deflate</i> (used by <i>ZIP</i> and <i>GZIP</i>). Over the years, <b>7z</b> has gained significant popularity in the Linux community for its efficiency, versatility, and open-source nature, making it a preferred choice for archival tasks requiring maximum compression.


title: SYNOPSIS
content:
<b>7zr</b> &lt;command&gt; [&lt;switches&gt;...] &lt;archive_name&gt; [&lt;file_names&gt;... [&lt;@listfiles&gt;...]]


title: PARAMETERS
content:
<b>a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add (compress) files to an archive. <br>Usage: <code>7zr a archive.7z files...</code><br><br><b>e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files from an archive to the current directory, without full path names.<br><br><b>x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Extract files from an archive with full path names, preserving the directory structure.<br><br><b>l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the contents of an archive.<br><br><b>t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of an archive.<br><br><b>d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete files from an archive.<br><br><b>u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update files in an archive (add new files, replace older files).<br><br><b>-o{Directory}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output directory for extracted files. <br>Example: <code>-o/tmp/extracted</code><br><br><b>-p{Password}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the password for encryption/decryption. <br>Example: <code>-pMySecurePass</code><br><br><b>-r[-[0|1]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurse subdirectories when adding files. <code>-r</code> for all, <code>-r0</code> for no recursion, <code>-r1</code> for only explicitly included ones.<br><br><b>-m{Method}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the compression method (e.g., LZMA2, Deflate, BZip2). <br>Example: <code>-m0=lzma2</code><br><br><b>-mx={level}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the compression level (0-9). <code>-mx=0</code> for no compression, <code>-mx=9</code> for ultra compression. <br>Example: <code>-mx=7</code><br><br><b>-sfx[{name}]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a self-extracting archive. Optionally specify the module name.<br><br><b>-t{Type}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the type of archive (e.g., 7z, zip, tar, gzip, xz). <br>Example: <code>-tzip</code><br><br><b>-v{Size}[b|k|m|g]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create multi-volume archives. Specify volume size (bytes, kilobytes, megabytes, gigabytes). <br>Example: <code>-v100m</code><br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume Yes on all queries (non-interactive mode).<br><br><b>-ao{a|s|t|u}</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set overwrite mode for extraction: <code>a</code> (All), <code>s</code> (Skip), <code>t</code> (auto-rename Target), <code>u</code> (auto-rename existing).<br><br>


title: DESCRIPTION
content:
<i>7zr</i> is a robust command-line utility for Linux/Unix systems, serving as a standalone version of the renowned 7-Zip file archiver. It is primarily known for its exceptionally high compression ratio, especially with its native <b>.7z</b> format. Beyond 7z, it supports a multitude of other archive formats for both compression and extraction, including ZIP, GZIP, BZIP2, TAR, XZ, and many more. It provides features like strong AES-256 encryption, the ability to create self-extracting archives (SFX), and support for multi-volume archives. While often similar to the more general <i>7z</i> command, <i>7zr</i> is sometimes a more focused or statically linked variant, emphasizing portability and core 7z functionality, making it a staple for efficient data management in server environments and scripts.


title: CAVEATS
content:
While <i>7zr</i> is highly capable, it is generally a command-line-only tool, which can present a steep learning curve for users unfamiliar with CLI archiving tools. The distinction between <i>7zr</i> and <i>7z</i> can be subtle; <i>7zr</i> is often a specific build focusing on the .7z format and may lack support for some proprietary formats (like RAR) that <i>7z</i> might offer, depending on compilation options. High compression levels can be very CPU and memory intensive, impacting performance on less powerful systems.


title: KEY FEATURES
content:
<ul><li>Superior compression ratio using LZMA2 and LZMA algorithms.</li><li>Strong AES-256 encryption.</li><li>Ability to create self-extracting archives (SFX).</li><li>Support for creating and extracting a wide range of archive formats beyond .7z.</li><li>Efficient handling of very large files.</li></ul>


title: SUPPORTED FORMATS
content:
<b>7zr</b> supports: 7z, XZ, GZIP, BZIP2, TAR, ZIP, WIM. It can also extract from: AR, CPIO, RPM, DEB, ISO, LZH, LZMA, NSIS, RAR, Z, CAB, CHM, MSI, HFS, MBR, NTFS, SquashFS, CramFS, UDF, VHD, VMDK.


title: HISTORY
content:
<i>7zr</i> is part of the <b>p7zip</b> project, which is the official port of Igor Pavlov's 7-Zip archiver to POSIX systems like Linux. 7-Zip itself began development in 1999. The <i>7zr</i> executable specifically is often a streamlined or statically linked version within the p7zip distribution, designed to be more portable or to provide core 7z functionality with minimal dependencies. Its development mirrors the ongoing enhancements of the main 7-Zip project, bringing its industry-leading compression ratios and robust feature set to the Linux command line.


title: SYNOPSIS
content:
<b>7za</b> <i>&lt;command&gt;</i> [<i>&lt;switches&gt;</i>...] <i>&lt;archive_name&gt;</i> [<i>&lt;file_names&gt;</i>...] [<i>&lt;@listfiles...&gt;</i>]


title: PARAMETERS
content:
<b><i>&lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the primary action to perform. Common commands include <b>a</b> (add files to archive), <b>e</b> (extract files without full path), <b>l</b> (list archive contents), <b>x</b> (extract files with full paths), and <b>d</b> (delete files from archive).<br><br><b><b>-o</b><i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output directory for extracted files. For example, <b>-o/tmp/extracted</b>.<br><br><b><b>-p</b><i>&lt;password&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the password for encrypting or decrypting an archive. For 7z archives, use with <b>-mhe</b> for header encryption.<br><br><b><b>-m</b><i>&lt;method&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets compression method and parameters. Example: <b>-mx=9</b> for Ultra compression, <b>-mmt=on</b> for multi-threading.<br><br><b><b>-t</b><i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the type of archive to create or extract (e.g., <b>-t7z</b>, <b>-tzip</b>, <b>-ttar</b>, <b>-tgz</b>, <b>-tbz2</b>, <b>-txz</b>).<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recurses subdirectories when adding files to an archive.<br><br><b><b>-sfx</b>[<i>&lt;name&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a self-extracting archive. An optional <i>&lt;name&gt;</i> can specify the SFX module to use.<br><br><b><b>-v</b><i>&lt;size&gt;</i>[b|k|m|g]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates multi-volume archives with a specified volume size (e.g., <b>-v10m</b> for 10 MB volumes).<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assumes 'Yes' on all queries, useful for scripting and non-interactive operations.<br><br><b><b>-mx</b>[0-9]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the compression level: <b>0</b> (Store/No compression), <b>1</b> (Fastest), <b>...</b>, <b>9</b> (Ultra/Maximum compression).<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a solid archive (default for 7z format). Solid archives offer better compression for many small files but can make individual file extraction slower.<br><br><b><b>-mhe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables header encryption for 7z archives when used with <b>-p</b>, hiding filenames and other metadata.<br><br>


title: DESCRIPTION
content:
<i>7za</i> is a powerful command-line utility, serving as a standalone version of the renowned 7-Zip archiver. It is widely recognized for its exceptionally high compression ratio, particularly when utilizing the 7z format with its advanced LZMA and LZMA2 algorithms. This tool boasts extensive support for various archive formats, enabling the unpacking of numerous types (including 7z, Zip, Gzip, Bzip2, Tar, XZ, Cpio, and Ar) and efficient packing for a key subset (such as 7z, Zip, Gzip, Bzip2, Tar, and XZ).<br><br>The standalone nature of <i>7za</i> means it operates without external modules, making it highly portable and an ideal choice for minimalist Linux environments or scenarios requiring self-contained archive distribution. Key features include robust AES-256 encryption, the capability to create multi-volume archives, and support for self-extracting (SFX) archives. It stands as an indispensable tool for efficient data storage, secure backups, and streamlined file distribution.


title: CAVEATS
content:
While <i>7za</i> is highly capable, its design as a standalone executable means it might not support all archive formats for packing or unpacking that the full <i>7z</i> command (which can dynamically load plugins) might. Notably, it typically does not support proprietary formats like RAR by default. Using extremely high compression settings (e.g., <b>-mx=9</b>) can be very resource-intensive, demanding significant CPU time and memory, potentially leading to considerably longer archiving durations. Solid archives (enabled by <b>-s</b>) can sometimes result in slower extraction of individual files, as the entire solid block up to the desired file might need to be decompressed.


title: COMPRESSION LEVELS (<B>-MX</B>)
content:
<i>7za</i> provides a range of compression levels controlled by the <b>-mx</b> switch. Levels vary from <b>0</b> (Store), which performs no compression and is fastest, up to <b>9</b> (Ultra), which achieves the maximum possible compression. Higher levels, while yielding smaller archives, require significantly more time and system resources (CPU and RAM) during the compression process.


title: SOLID ARCHIVES (<B>-S</B>)
content:
By default, 7z archives created by <i>7za</i> are 'solid'. In a solid archive, all files are treated as a single continuous data stream, which can dramatically improve the compression ratio, especially for archives containing numerous small and similar files. However, a trade-off is that extracting a single file from a solid archive necessitates decompressing all data preceding that file within its solid block, potentially making individual file extraction slower compared to non-solid archives.


title: ENCRYPTION (<B>-P</B> AND <B>-MHE</B>)
content:
<i>7za</i> supports robust AES-256 encryption. The <b>-p</b> switch is used to specify the password for archive encryption. For 7z archives, to ensure that file names and other metadata (like file sizes and modification dates) are also hidden, the <b>-mhe</b> (Master Header Encryption) switch must be used in conjunction with <b>-p</b>. Without <b>-mhe</b>, only the actual file content is encrypted, leaving the filenames exposed.


title: CROSS-PLATFORM AVAILABILITY
content:
The <i>7-Zip</i> project, including the <i>7za</i> command-line utility, is highly cross-platform. Beyond its common use on Linux, it is also widely available and utilized on Windows, macOS, and other Unix-like operating systems. This broad compatibility ensures that archives created with <i>7za</i> can be reliably extracted across different operating environments.


title: HISTORY
content:
<i>7-Zip</i> was first introduced by Igor Pavlov in 1999. It rapidly gained prominence due to its open-source nature and the introduction of the highly efficient 7z archive format, powered by the LZMA compression algorithm. <i>7za</i> emerged as the standalone command-line version of 7-Zip, specifically designed for portability and self-containment, without reliance on external dynamic libraries or plugins. This characteristic has made it a favored tool for inclusion in minimalistic Linux distributions, rescue disks, and environments where a full 7-Zip installation is impractical. Its continuous development focuses on enhancing compression ratios, improving speed, and broadening format compatibility.


title: SYNOPSIS
content:
Since <b><I>]]</I></b> is not a standalone command but a shell keyword closing a compound command, it does not have an independent synopsis. Its usage is strictly as the closing part of the <b><I>[[ ... ]]</I></b> construct:<br><br><b><I>[[ expression ]]</I></b><br><br>The <b><I>expression</I></b> within the brackets is evaluated, and the exit status of the <b><I>[[ ... ]]</I></b> command indicates whether the expression is true (0) or false (1).


title: PARAMETERS
content:
<b>No direct parameters</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b><I>]]</I></b> keyword itself does not accept any parameters. Its function is solely to terminate the conditional expression initiated by <b><I>[[</I></b>. All operators and operands are part of the <b><I>expression</I></b> contained <I>between</I> <b><I>[[</I></b> and <b><I>]]</I></b>.<br><br><b>Common operators used within <b><I>[[ ... ]]</I></b>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;While not parameters of <b><I>]]</I></b>, the following are common test operators and constructs used within the expression that <b><I>]]</I></b> closes:<br><b><I>-a file</I></b>: True if <I>file</I> exists.<br><b><I>-d file</I></b>: True if <I>file</I> is a directory.<br><b><I>-f file</I></b>: True if <I>file</I> is a regular file.<br><b><I>-z string</I></b>: True if <I>string</I> has zero length.<br><b><I>-n string</I></b>: True if <I>string</I> has non-zero length.<br><b><I>string1 = string2</I></b>: True if <I>string1</I> is equal to <I>string2</I>.<br><b><I>string1 != string2</I></b>: True if <I>string1</I> is not equal to <I>string2</I>.<br><b><I>integer1 -eq integer2</I></b>: True if <I>integer1</I> is equal to <I>integer2</I>.<br><b><I>integer1 -ne integer2</I></b>: True if <I>integer1</I> is not equal to <I>integer2</I>.<br><b><I>integer1 -gt integer2</I></b>: True if <I>integer1</I> is greater than <I>integer2</I>.<br><b><I>integer1 -ge integer2</I></b>: True if <I>integer1</I> is greater than or equal to <I>integer2</I>.<br><b><I>integer1 -lt integer2</I></b>: True if <I>integer1</I> is less than <I>integer2</I>.<br><b><I>integer1 -le integer2</I></b>: True if <I>integer1</I> is less than or equal to <I>integer2</I>.<br><b><I>string =~ regex</I></b>: True if <I>string</I> matches <I>regex</I> (Bash/Zsh only).<br><b><I>expr1 && expr2</I></b>: Logical AND.<br><b><I>expr1 || expr2</I></b>: Logical OR.<br><br>


title: DESCRIPTION
content:
The double closing square bracket, <b><I>]]</I></b>, is not a standalone Linux command or executable program. Instead, it serves as the mandatory closing delimiter for the <b><I>[[ ... ]]</I></b> compound command in Bash, KornShell (ksh), and Zsh. This construct is an enhanced version of the older <b><I>[ ... ]</I></b> (which is an alias for the <b><I>test</I></b> command) used for evaluating conditional expressions in shell scripts.<br><br>The <b><I>[[ ... ]]</I></b> syntax offers several advantages over <b><I>[ ... ]</I></b>, including the prevention of word splitting and pathname expansion, and native support for logical operators like <b><I>&&</I></b> (AND) and <b><I>||</I></b> (OR), as well as regular expression matching with <b><I>=~</I></b>. Because <b><I>[[</I></b> and <b><I>]]</I></b> are shell keywords rather than external commands, they provide a more robust and less error-prone way to perform conditional checks. Therefore, <b><I>]]</I></b> only has meaning when paired with an opening <b><I>[[</I></b>, forming a complete conditional expression.


title: CAVEATS
content:
<b><I>&#x2022;</I></b> <b><I>]]</I></b> cannot be used on its own; it always requires a preceding <b><I>[[</I></b> to form a valid construct.<br><b><I>&#x2022;</I></b> There must be a space before the closing <b><I>]]</I></b> (e.g., <b><I>[[ expression ]]</I></b>, not <b><I>[[ expression]]</I></b>).<br><b><I>&#x2022;</I></b> The <b><I>[[ ... ]]</I></b> construct, and thus <b><I>]]</I></b>, is a Bash/KornShell/Zsh keyword and is not part of the POSIX standard for <b><I>sh</I></b>. Scripts using it may not be portable to all Bourne-like shells.


title: WHY PREFER <B><I>[[ ... ]]</I></B> OVER <B><I>[ ... ]</I></B>?
content:
Using <b><I>[[ ... ]]</I></b> (and thus <b><I>]]</I></b>) is generally recommended in Bash scripts for several reasons:<br><b><I>&#x2022;</I></b> <b><I>No word splitting/pathname expansion</I></b>: Variables inside <b><I>[[ ... ]]</I></b> do not need to be quoted (though it's good practice), as the shell does not perform word splitting or pathname expansion on them. This significantly reduces quoting errors.<br><b><I>&#x2022;</I></b> <b><I>Regular expression matching</I></b>: It supports the <b><I>=~</I></b> operator for powerful regular expression pattern matching.<br><b><I>&#x2022;</I></b> <b><I>Logical operators</I></b>: It allows direct use of <b><I>&&</I></b> (AND) and <b><I>||</I></b> (OR) operators within the expression, simplifying complex conditions without needing multiple <b><I>[ ... ]</I></b> commands.<br><b><I>&#x2022;</I></b> <b><I>Type-safe comparisons</I></b>: String and numeric comparisons are handled more predictably without requiring explicit type conversion for numeric strings.


title: HISTORY
content:
The <b><I>[[ ... ]]</I></b> construct, which <b><I>]]</I></b> completes, originated in the KornShell (ksh) to address limitations and common pitfalls of the traditional <b><I>[ ... ]</I></b> (<b><I>test</I></b>) command. It was subsequently adopted by Bash (version 2.0 and later) and Zsh, becoming a widely used feature for more robust and readable conditional expressions in shell scripting. Its status as a shell keyword, rather than an external command, allows for more advanced parsing and fewer issues with word splitting and globbing.


title: PARAMETERS
content:
<b>old_string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The substring to be replaced in the previous command.<br><br><b>new_string</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The replacement substring.<br><br>


title: DESCRIPTION
content:
The <b>^</b> character is not a standalone Linux command. Instead, it serves as a special character with multiple contexts and meanings within the Linux environment, primarily within shell scripting and regular expressions. Its most 'command-like' usage is as a shorthand for <I>history substitution</I> in shells like Bash. When used in this context, it allows for a rapid, one-off replacement of a string in the immediately preceding command line. For instance, if you typed a command with a typo and want to correct it quickly without retyping the whole line, you can use <b>^old^new^</b> to substitute 'old' with 'new' in the last command and execute the modified command. This feature is a powerful productivity tool for interactive shell use. Beyond history substitution, <b>^</b> is also fundamental in regular expressions to denote the beginning of a line or string, and it acts as the bitwise XOR operator in shell arithmetic expansions and various programming languages.


title: CAVEATS
content:
The <b>^</b> character itself is not a standalone Linux command. Its most 'command-like' usage is within shells like Bash for history substitution, which is a shell feature, not an external utility. This substitution only affects the immediately preceding command. For more complex or global string replacements in history, or for general text manipulation, other methods (e.g., using <b>!!:s/old/new/</b> with flags, or commands like <b>sed</b>) are required.


title: REGULAR EXPRESSIONS
content:
In regular expressions (used by commands like <b>grep</b>, <b>sed</b>, <b>awk</b>), <b>^</b> serves as an <I>anchor</I> that matches the beginning of a line or string. For example, the pattern <b>^start</b> would only match lines that begin with the word 'start'.


title: BITWISE XOR OPERATOR
content:
In shell arithmetic expansions (e.g., <b>((...))</b>) and various programming languages (like C, Python), <b>^</b> represents the <I>bitwise XOR</I> (exclusive OR) operator. This performs a logical XOR operation on corresponding bits of two operands. For example, in bash, <b>echo $((5 ^ 3))</b> would output <b>6</b> (binary 101 XOR 011 = 110).


title: HISTORY
content:
The concise <b>^old^new^</b> history substitution syntax originated in the <I>C shell</I> (<b>csh</b>) and was later adopted by the <I>GNU Bash</I> shell due to its convenience for quick edits of the last executed command. This form is a shorthand for the more general history modifier <b>:s</b>.


title: PARAMETERS
content:
<b>conf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the configuration file to disable. This should be the base name of the file (e.g., 'charset', 'security') without the .conf extension. The file must exist in /etc/apache2/conf-available/.<br><br><b>-q or --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of informational messages about symbolic link creation or removal. Only errors will be shown.<br><br>


title: DESCRIPTION
content:
<i>a2disconf</i> is a utility script primarily used on Debian-based Linux distributions (like Ubuntu) to manage Apache HTTP Server configuration files. It provides a convenient way to disable a specific configuration file without deleting its original content. The command operates by removing the symbolic link from the <i>/etc/apache2/conf-enabled/</i> directory that points to the actual configuration file located in <i>/etc/apache2/conf-available/</i>.<br><br>This method ensures that the original configuration file remains untouched and can be easily re-enabled later using the <i>a2enconf</i> command. After running <i>a2disconf</i>, the Apache web server must be reloaded or restarted for the changes to take effect, as the command itself does not automatically perform this action. It is commonly used by system administrators to temporarily or permanently disable specific server-wide settings, often for debugging, maintenance, or security purposes, ensuring that only actively required configurations are loaded by Apache.


title: CAVEATS
content:
<ul><li>Requires <b>sudo</b> or root privileges to execute successfully due to file system operations in protected directories.</li><li>Does not automatically reload or restart the Apache HTTP Server. After running <i>a2disconf</i>, you must manually reload (e.g., <b>sudo systemctl reload apache2</b>) or restart (e.g., <b>sudo systemctl restart apache2</b>) Apache for the changes to take effect.</li><li>The command only removes the symbolic link from <i>conf-enabled</i>; it does not delete the original configuration file from <i>conf-available</i>.</li><li>Attempting to disable a non-existent configuration file or one that is already disabled will result in an error or a message indicating that the link does not exist.</li></ul>


title: FILE LOCATIONS
content:
The command specifically interacts with the <i>/etc/apache2/conf-available/</i> directory (where available configurations are stored) and the <i>/etc/apache2/conf-enabled/</i> directory (where enabled configurations are symlinked from).


title: CONFIGURATION EXTENSION
content:
The 'conf' argument should typically be provided without the <i>.conf</i> file extension, as the command automatically appends it when searching for the file in <i>conf-available</i>. For example, to disable <i>charset.conf</i>, you would use <b>a2disconf charset</b>.


title: HISTORY
content:
The <i>a2disconf</i> command, along with its counterparts like <i>a2enconf</i>, <i>a2enmod</i>, and <i>a2dissite</i>, is part of the Apache utilities provided by Debian's Apache packaging. These scripts were developed to simplify the management of Apache configurations, modules, and virtual hosts in a structured and reversible manner, primarily for Debian and Ubuntu distributions. They encapsulate the manual process of creating or removing symbolic links, ensuring consistency and reducing errors. Their usage became widespread with the adoption of these distributions for web servers.


title: PARAMETERS
content:
<b><I>module</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Apache2 module to disable. This is typically the filename without the <B>.load</B> or <B>.conf</B> extension (e.g., <B>deflate</B>, <B>rewrite</B>).<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not complain if the specified module does not exist or is already disabled. This suppresses error messages.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all informative messages, showing only errors if they occur.<br><br>


title: DESCRIPTION
content:
The <b>a2dismod</b> command is a utility used on Debian/Ubuntu-based systems to disable a specific Apache2 module. Apache2 uses a modular configuration system where modules are typically enabled or disabled by managing symbolic links. When a module is <I>enabled</I>, a symlink exists from <B>/etc/apache2/mods-available/</B> to <B>/etc/apache2/mods-enabled/</B>. The <b>a2dismod</b> command automates the process of removing this symbolic link, effectively telling Apache2 to no longer load that module's configuration. This command requires root privileges (sudo). After running <b>a2dismod</b>, the Apache2 web server must be reloaded or restarted for the changes to take effect. It's the counterpart to the <B>a2enmod</B> command.


title: CAVEATS
content:
<b>Root Privileges:</b> This command requires superuser privileges (e.g., using <b>sudo</b>) to modify system configuration files.<br><br><b>No Automatic Reload:</b> <b>a2dismod</b> only modifies configuration files; it does <b>not</b> automatically reload or restart the Apache2 web server. You must manually reload or restart Apache2 (e.g., <b>sudo systemctl reload apache2</b> or <b>sudo service apache2 reload</b>) for the changes to take effect.<br><br><b>Dependencies:</b> Disabling a module that other active sites or modules depend on can lead to unexpected errors or site malfunctions. Ensure no critical dependencies are broken.<br><br><b>Configuration vs. Binary:</b> This command disables the <I>configuration</I> for a module; it does not remove or uninstall the module's binary files from your system.


title: RELOADING APACHE AFTER DISABLING A MODULE
content:
It is crucial to reload or restart the Apache2 web server after using <b>a2dismod</b> for the changes to become active. Common commands include:<br><br><B>sudo systemctl reload apache2</B><br>or<br><B>sudo service apache2 reload</B><br><br>For a full restart (which might cause a brief downtime):<br><B>sudo systemctl restart apache2</B>


title: FINDING MODULE NAMES
content:
To see available module names, you can list the contents of the <B>/etc/apache2/mods-available/</B> directory:<br><br><B>ls /etc/apache2/mods-available/</B><br><br>Modules are typically listed as <B>modulename.load</B> and sometimes <B>modulename.conf</B>. When using <b>a2dismod</b>, you only need to provide the <B>modulename</B> part (e.g., <B>ls /etc/apache2/mods-available/rewrite.load</B> would mean using <B>rewrite</B> as the module name).


title: HISTORY
content:
The <b>a2dismod</b> command, along with its counterparts like <B>a2enmod</B>, <B>a2ensite</B>, and <B>a2dissite</B>, is a part of the Apache2 utility suite provided by Debian and Ubuntu distributions. These utilities were developed to simplify the management of Apache's modular configuration system, abstracting away the manual creation and removal of symbolic links in directories like <B>/etc/apache2/mods-enabled/</B> and <B>/etc/apache2/sites-enabled/</B>. This approach makes Apache configuration more maintainable and less prone to manual errors, especially for administrators managing multiple modules and virtual hosts.


title: PARAMETERS
content:
<b><i>site</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the site configuration file (without the <b>.conf</b> extension) to disable. Multiple sites can be specified.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Quiet</i>: Suppress all output except errors.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verbose</i>: Display information about actions being taken.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force</i>: Do not ask for confirmation before disabling the site(s).<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Help</i>: Display usage information and exit.<br><br>


title: DESCRIPTION
content:
<i>a2dissite</i> is a script used to disable Apache virtual host configurations. It operates by removing the symbolic link from the <b>/etc/apache2/sites-enabled/</b> directory that points to the configuration file in <b>/etc/apache2/sites-available/</b>. This effectively tells Apache to no longer load that specific site configuration upon restart or reload. This command simplifies the management of Apache virtual hosts, making it easy to turn sites on or off without manually manipulating symbolic links. After running <i>a2dissite</i>, the Apache web server must be reloaded or restarted for the changes to take effect. It typically requires root privileges to execute.


title: CAVEATS
content:
<ul><li>Requires root privileges (e.g., using <b>sudo</b>) to modify system configuration files.</li><li>Changes do not take effect until Apache is reloaded or restarted (e.g., via <b>sudo systemctl reload apache2</b> or <b>sudo service apache2 reload</b>).</li><li>Only disables the symbolic link; the actual configuration file in <b>sites-available/</b> remains unchanged.</li></ul>


title: CONFIGURATION DIRECTORIES
content:
<b>a2dissite</b> primarily interacts with the <b>/etc/apache2/sites-available/</b> and <b>/etc/apache2/sites-enabled/</b> directories. Configuration files in <b>sites-available/</b> contain the actual virtual host definitions, while <b>sites-enabled/</b> contains symbolic links to the files in <b>sites-available/</b> that are currently active. Disabling a site removes its link from <b>sites-enabled/</b>.


title: IMPACT ON RUNNING SERVER
content:
Disabling a site with <b>a2dissite</b> does not immediately stop the site from serving requests. The changes only take effect after the Apache web server is reloaded or restarted. It is crucial to perform this subsequent step (e.g., <b>sudo systemctl reload apache2</b>) for the site to become inactive and for Apache to recognize the updated configuration.


title: HISTORY
content:
The <i>a2dissite</i> script is part of the Apache HTTP Server package, predominantly found in Debian/Ubuntu-based distributions where Apache configuration is managed through a modular approach using <b>sites-available/</b> and <b>sites-enabled/</b> directories. Its development reflects the need for simplified administration of virtual hosts, moving away from manual symbolic link management to a command-line utility. It has been a standard tool for Apache administrators on these systems for many years, offering a consistent and convenient way to manage website configurations.


title: PARAMETERS
content:
<b><i>conf</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the configuration file (without the <i>.conf</i> extension) to enable. This file must exist in <i>/etc/apache2/conf-available/</i>.<br><br><b><i>-q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; suppress all messages and output from the command.<br><br><b><i>-m</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not show the informational message about needing to reload Apache after making changes.<br><br>


title: DESCRIPTION
content:
The <b>a2enconf</b> command is a utility script used on Debian-based Linux distributions (like Ubuntu) to enable an Apache 2 web server configuration file. Apache 2 on these systems organizes its configuration into <b>conf-available</b> and <b>conf-enabled</b> directories. Configuration files located in <b>conf-available</b> are inactive and not loaded by the server.<br><br><b>a2enconf</b> creates a symbolic link from a specified configuration file in <b>conf-available</b> to the <b>conf-enabled</b> directory. This action effectively activates the configuration, making it part of the Apache server's loaded settings. After enabling a configuration, the Apache web server must be reloaded or restarted for the changes to take effect.<br><br>This command is part of a suite of helper scripts (including <b>a2enmod</b>, <b>a2dismod</b>, <b>a2ensite</b>, <b>a2dissite</b>) designed to simplify Apache configuration management. It helps administrators activate or deactivate specific configurations, modules, or virtual hosts without directly manipulating symbolic links, which reduces the risk of errors and standardizes the configuration process. It is commonly used for activating general Apache settings like <b>charset.conf</b>, <b>security.conf</b>, or other custom <i>.conf</i> files.


title: CAVEATS
content:
<b>Caveats:</b><br><b>•</b> Requires root privileges (e.g., using <b>sudo</b>) to execute.<br><b>•</b> Does not automatically reload or restart the Apache web server. You must manually reload or restart Apache (e.g., <b>sudo systemctl reload apache2</b>) for the changes to take effect.<br><b>•</b> Only works with configuration files located in the <i>/etc/apache2/conf-available/</i> directory. Ensure the file you intend to enable exists there.<br><b>•</b> The command creates a symbolic link; any actual configuration changes or edits need to be made in the original file within <i>conf-available/</i>, not in <i>conf-enabled/</i>.


title: ACTIVATION REQUIREMENT
content:
After successfully running <b>a2enconf</b>, it is crucial to reload or restart the Apache web server for the newly enabled configuration to take effect. Apache does not automatically detect these changes. This is typically done using commands such as <b>sudo systemctl reload apache2</b> (for systems using systemd) or <b>sudo service apache2 reload</b> (for older init systems).


title: FILE LOCATIONS
content:
Configuration files managed by <b>a2enconf</b> are initially stored in the <i>/etc/apache2/conf-available/</i> directory. When a configuration is enabled, <b>a2enconf</b> creates a symbolic link from this location to <i>/etc/apache2/conf-enabled/</i>, which is the directory Apache reads upon startup or reload. Conversely, <b>a2disconf</b> removes this symbolic link.


title: HISTORY
content:
The <b>a2enconf</b> command, along with its counterparts like <b>a2enmod</b> and <b>a2ensite</b>, was developed as part of the Apache2 package on Debian and Ubuntu distributions. Its purpose is to streamline and standardize the management of Apache configurations by abstracting the symbolic link creation process, thus promoting a modular and less error-prone approach to server setup. This method simplifies enabling and disabling specific components of the web server.


title: PARAMETERS
content:
<b><i>module</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Apache module to enable (e.g., <i>rewrite</i>, <i>ssl</i>, <i>php7.4</i>). Do not include file extensions like .load or .conf.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses verbose output, useful for scripting or automated tasks to avoid unnecessary messages.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available Apache modules in the <i>mods-available</i> directory, indicating which ones are currently enabled. This option does not enable any modules.<br><br>


title: DESCRIPTION
content:
<i>a2enmod</i> is a utility script used on Debian-based Linux distributions (like Ubuntu) to efficiently enable modules for the Apache HTTP Server 2. It streamlines the configuration process by creating a symbolic link from a module file located in the <i>/etc/apache2/mods-available/</i> directory to the <i>/etc/apache2/mods-enabled/</i> directory. This action makes the module available for Apache to load upon server restart or graceful reload.<br><br>The command simplifies Apache administration by abstracting the manual management of symlinks, helping to maintain a clean and organized configuration structure. After running <i>a2enmod</i>, an Apache service reload or restart is typically required for the changes to take effect.


title: CAVEATS
content:
<ul><li>Requires <b>root</b> privileges (use <i>sudo</i>).</li><li>Changes made by <i>a2enmod</i> only take effect after an Apache service restart or graceful reload (e.g., <i>sudo systemctl reload apache2</i> or <i>sudo apachectl graceful</i>).</li><li>Only enables modules that are already present in the <i>/etc/apache2/mods-available/</i> directory. It does not install new modules.</li></ul>


title: MODULE NAMING CONVENTION
content:
When using <i>a2enmod</i>, modules are referenced by their base name (e.g., <i>rewrite</i>, <i>ssl</i>) without the <i>.load</i> or <i>.conf</i> file extensions.


title: IMPACT ON CONFIGURATION
content:
The command creates a symbolic link from the module's file in <i>/etc/apache2/mods-available/</i> (e.g., <i>rewrite.load</i> or <i>ssl.conf</i>) to <i>/etc/apache2/mods-enabled/</i>. Apache reads these symlinks to determine which modules to load during startup or reload.


title: APPLYING CHANGES
content:
It's crucial to reload or restart the Apache service after enabling a module for the changes to take effect. A common command for this is <i>sudo systemctl reload apache2</i>, which performs a graceful reload without dropping active connections.


title: HISTORY
content:
The <i>a2enmod</i> script, along with its counterparts like <i>a2dismod</i>, <i>a2ensite</i>, and <i>a2enconf</i>, is an integral part of the Apache2 package management system developed specifically for Debian-based distributions (such as Ubuntu). These scripts were created to standardize and simplify the administration of Apache configurations by abstracting the manual creation and removal of symbolic links within the <i>/etc/apache2/</i> directory structure. This modular approach, which separates 'available' from 'enabled' configurations, has been a cornerstone of Debian's Apache2 packaging for many years, significantly reducing configuration errors and standardizing management practices for system administrators.


title: PARAMETERS
content:
<b><i>&lt;site_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the Apache virtual host configuration file (typically without the <i>.conf</i> extension) located in the <i>/etc/apache2/sites-available/</i> directory. Multiple site names can be specified to enable several sites simultaneously.<br><br>


title: DESCRIPTION
content:
<i>a2ensite</i> is a fundamental utility script prevalent on Debian-based Linux distributions, such as Ubuntu, designed to efficiently manage Apache HTTP Server virtual host configurations. Its primary function is to enable a specific virtual host. The command achieves this by creating a symbolic link from the configuration file located in the <i>/etc/apache2/sites-available/</i> directory to the <i>/etc/apache2/sites-enabled/</i> directory. This symlink instructs Apache to include the linked configuration when it processes its active sites.<br><br>While <i>a2ensite</i> successfully enables the site, it does <b>not</b> automatically trigger a reload or restart of the Apache service. Therefore, it is essential for administrators to manually reload or restart Apache (e.g., using <i>sudo systemctl reload apache2</i> or <i>sudo service apache2 reload</i>) after running the command for the changes to take effect. This separation of tasks ensures that multiple configuration changes can be batched before a single service restart. The utility significantly streamlines the activation and deactivation process for various websites hosted on a single Apache instance, enhancing server management efficiency. It is typically part of the core <i>apache2</i> package.


title: CAVEATS
content:
<b>Root Privileges Required</b>:<br>The command must be executed with root privileges (e.g., using <i>sudo</i>), as it modifies system directories and creates symbolic links in <i>/etc/apache2/sites-enabled/</i>.<br><br><b>Apache Reload/Restart</b>:<br>After running <i>a2ensite</i>, Apache must be reloaded or restarted for the changes to take effect. The command itself does not perform this action.<br><br><b>Configuration Validity</b>:<br>The target configuration file in <i>/etc/apache2/sites-available/</i> must be a valid Apache virtual host configuration. <i>a2ensite</i> does not validate the syntax of the configuration file.<br><br><b>Complementary to a2dissite</b>:<br>It is the counterpart to <i>a2dissite</i>, which disables a virtual host by removing the symbolic link.


title: TYPICAL FILE LOCATIONS
content:
Configuration files relevant to <i>a2ensite</i> are primarily stored in:<br><i>/etc/apache2/sites-available/</i> (where site configurations are placed and reside)<br><i>/etc/apache2/sites-enabled/</i> (where active site symlinks are created and managed by <i>a2ensite</i>)


title: HISTORY
content:
<i>a2ensite</i> is a key component of the <i>apache2-common</i> or <i>apache2</i> package, primarily developed for and used by Debian and Ubuntu Linux distributions. Its introduction aimed to simplify the management of Apache virtual hosts, offering a structured and user-friendly alternative to manually creating and removing symlinks. This utility has streamlined the process of activating and deactivating websites, significantly contributing to more efficient and less error-prone server administration within these environments.


title: PARAMETERS
content:
<b>-b <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a block special file.<br><br><b>-c <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a character special file.<br><br><b>-d <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a directory.<br><br><b>-e <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists (regardless of type).<br><br><b>-f <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a regular file.<br><br><b>-g <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its set-group-ID bit is set.<br><br><b>-k <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its 'sticky' bit is set.<br><br><b>-L <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a symbolic link.<br><br><b>-p <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is a named pipe (FIFO).<br><br><b>-r <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and read permission is granted.<br><br><b>-s <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and has a size greater than zero.<br><br><b>-t <I>FD</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if file descriptor <I>FD</I> is open and refers to a terminal (defaults to 1, stdout).<br><br><b>-u <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and its set-user-ID bit is set.<br><br><b>-w <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and write permission is granted.<br><br><b>-x <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and execute permission is granted.<br><br><b>-O <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is owned by the effective user ID.<br><br><b>-G <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and is owned by the effective group ID.<br><br><b>-N <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE</I> exists and has been modified since it was last read.<br><br><b><I>FILE1</I> -nt <I>FILE2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE1</I> is newer (modification time) than <I>FILE2</I>.<br><br><b><I>FILE1</I> -ot <I>FILE2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE1</I> is older (modification time) than <I>FILE2</I>.<br><br><b><I>FILE1</I> -ef <I>FILE2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>FILE1</I> and <I>FILE2</I> refer to the same device and inode numbers (hard link).<br><br><b>-z <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the length of <I>STRING</I> is zero.<br><br><b>-n <I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the length of <I>STRING</I> is non-zero.<br><br><b><I>STRING</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>STRING</I> is not empty (non-zero length).<br><br><b><I>STRING1</I> = <I>STRING2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the strings are equal.<br><br><b><I>STRING1</I> != <I>STRING2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if the strings are not equal.<br><br><b><I>STRING1</I> < <I>STRING2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>STRING1</I> sorts before <I>STRING2</I> lexicographically.<br><br><b><I>STRING1</I> > <I>STRING2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>STRING1</I> sorts after <I>STRING2</I> lexicographically.<br><br><b><I>INT1</I> -eq <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is equal to <I>INT2</I>.<br><br><b><I>INT1</I> -ne <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is not equal to <I>INT2</I>.<br><br><b><I>INT1</I> -ge <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is greater than or equal to <I>INT2</I>.<br><br><b><I>INT1</I> -gt <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is greater than <I>INT2</I>.<br><br><b><I>INT1</I> -le <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is less than or equal to <I>INT2</I>.<br><br><b><I>INT1</I> -lt <I>INT2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>INT1</I> is less than <I>INT2</I>.<br><br><b>! <I>EXPR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if <I>EXPR</I> is false (logical NOT).<br><br><b><I>EXPR1</I> -a <I>EXPR2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if both <I>EXPR1</I> and <I>EXPR2</I> are true (logical AND).<br><br><b><I>EXPR1</I> -o <I>EXPR2</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;True if either <I>EXPR1</I> or <I>EXPR2</I> is true (logical OR).<br><br>


title: DESCRIPTION
content:
The ']' character, when used in the context of a Linux command, is primarily the <I>required closing bracket</I> for the '<b>[</b>' command. The '<b>[</b>' command is a synonym for the 'test' command, which evaluates conditional expressions. It is not a standalone command but rather a syntactic requirement that signifies the end of the expression to be evaluated by the 'test' utility.<br><br>When writing shell scripts, the '<b>[</b>' command is used to perform various checks, such as verifying file existence, comparing strings, or evaluating numerical conditions. The closing '<b>]</b>' acts as a mandatory delimiter, completing the command's syntax. Without this closing '<b>]</b>', the shell would report a syntax error or an unmatched bracket error, as the command interpreter expects it to properly delimit the conditional expression. Its primary purpose is to make the conditional expression visually resemble a mathematical or programming language bracketed expression, improving readability and ensuring correct parsing by the shell.


title: CAVEATS
content:
The '<b>]</b>' character is not a standalone command; it functions purely as the closing argument for the '<b>[</b>' (test) command. It <b>must</b> be provided as a separate argument, meaning a space is required before it. For example, `<b>[</b> -f myfile <b>]</b>` is correct, while `<b>[</b>-f myfile<b>]</b>` or `<b>[</b> -f myfile<b>]</b>` would result in errors due to incorrect parsing by the shell.<br><br>Additionally, variable expansions within '<b>[ ... ]</b>' are subject to word splitting and pathname expansion, which can lead to unexpected behavior if variables are not properly quoted (e.g., `<b>[</b> "$VAR" = "value" <b>]</b>`). Modern shells often provide enhanced conditional constructs like '<b>[[ ... ]]</b>' which mitigate these issues.


title: USAGE AS A COMMAND
content:
It's crucial to understand that '<b>[</b>' is an actual command (usually a hard link to 'test' or a shell built-in), and '<b>]</b>' is simply its final argument. The shell parses '<b>[</b>' as the command name and everything up to '<b>]</b>' as its arguments. The '<b>]</b>' character itself doesn't execute anything; it serves as a required marker for the end of the conditional expression.


title: SPACING REQUIREMENT
content:
A common pitfall for beginners is forgetting the spaces around the '<b>[</b>' and '<b>]</b>' characters. Because they are treated as separate arguments by the shell, `<b>[</b> -f file <b>]</b>` is correct, but `<b>[</b>-f file<b>]</b>` or `<b>[</b> -f file<b>]</b>` will cause errors as the shell tries to interpret them differently (e.g., `<b>[</b>-f` as a single command name or missing arguments).


title: COMPARISON WITH <I>[[ ... ]]</I>
content:
Modern shells like Bash, Zsh, and Ksh provide an extended conditional command `<b>[[ ... ]]</b>`. This `<b>[[</b>` construct is a keyword rather than a command, offering several advantages over `<b>[ ... ]</b>`: it prevents word splitting and pathname expansion on unquoted variables, allows for regular expression matching (`=~`), and supports C-style logical operators (`&&`, `||`). For new scripts, `<b>[[ ... ]]</b>` is generally recommended for its robustness and enhanced features.


title: HISTORY
content:
The 'test' command, for which '<b>[</b>' is a synonym and '<b>]</b>' is the required closing delimiter, is a fundamental part of Unix-like operating systems. It originated in the early versions of Unix and was standardized by POSIX (Portable Operating System Interface) to ensure consistent behavior across different systems. Its purpose is to perform conditional checks essential for scripting, such as checking file attributes or comparing values. The bracketed syntax `<b>[ ... ]</b>` was introduced for syntactic sugar, making conditional expressions resemble those in programming languages, thereby enhancing readability.


title: SYNOPSIS
content:
<b>a2p</b> [<i>options</i>] [<i>filename</i> ...]<br><br><i>a2p</i> reads the <i>awk</i> script from the specified <i>filename</i>(s) or from standard input if no files are provided, and writes the translated <i>Perl</i> script to standard output.


title: PARAMETERS
content:
<b>-D<number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debugging output. The <i>number</i> indicates the level of debugging information (e.g., 1, 2, 4, 8, 16).<br><br><b>-F<string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the default field separator (equivalent to <i>awk -F</i>). The <i>string</i> can be a literal string or a regular expression.<br><br><b>-M<module></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>use <module>;</i> to the generated <i>Perl</i> script. Useful for including necessary <i>Perl</i> modules.<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not assume <i>awk</i> style input parsing (i.e., do not automatically split lines into fields). This is useful when the <i>awk</i> script processes whole lines or uses <i>getline</i> extensively.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume <i>awk</i> style input parsing (this is the default behavior).<br><br><b>-o</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimize the generated <i>Perl</i> script. This might produce more concise or efficient <i>Perl</i> code.<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate stricter <i>Perl</i> code, adding <i>use strict;</i> and <i>use warnings;</i> pragmas. This encourages better coding practices in the resulting script.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include comments from the original <i>awk</i> script in the translated <i>Perl</i> script.<br><br><b>-v <var>=<value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Predefine an <i>awk</i> variable with a given value (equivalent to <i>awk -v</i>). Multiple <i>-v</i> options can be used.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable <i>Perl</i> warnings in the generated script (adds <i>-w</i> to the <i>#!/usr/bin/perl</i> line or <i>use warnings;</i>).<br><br>


title: DESCRIPTION
content:
<i>a2p</i> is a utility that translates <i>awk</i> scripts into <i>Perl</i> scripts. Its primary purpose is to aid in migrating existing <i>awk</i> codebases to <i>Perl</i>, allowing developers to leverage <i>Perl</i>'s more powerful features, extensive module ecosystem, and better performance for complex tasks. It attempts to translate common <i>awk</i> constructs such as <i>BEGIN</i> and <i>END</i> blocks, pattern-action pairs, built-in variables (e.g., <i>NR</i>, <i>NF</i>, <i>FS</i>), and functions (e.g., <i>print</i>, <i>printf</i>, <i>gsub</i>). While <i>a2p</i> does an admirable job for many straightforward <i>awk</i> scripts, the resulting <i>Perl</i> code may not always be idiomatic or fully optimized. Complex <i>awk</i> patterns, specific regular expression behaviors, or reliance on nuanced <i>awk</i> internals might require manual adjustments to the generated <i>Perl</i> script. Nonetheless, it provides a valuable starting point, significantly reducing the manual effort involved in such migrations.


title: CAVEATS
content:
While <i>a2p</i> is a powerful migration tool, it has several caveats:<br><ul><li><b>Not 100% Perfect:</b> It cannot translate every conceivable <i>awk</i> script perfectly, especially those relying on very obscure <i>awk</i> features or highly specific regular expression nuances.</li><li><b>Idiomatic Perl:</b> The generated <i>Perl</i> code might not always be the most idiomatic or efficient <i>Perl</i>. It often reflects a direct translation rather than a redesign for <i>Perl</i>'s strengths.</li><li><b>Regular Expression Differences:</b> Subtle differences in regular expression syntax or behavior between <i>awk</i> and <i>Perl</i> can lead to unexpected results.</li><li><b><i>getline</i> and File Handling:</b> Complex <i>awk</i> scripts using <i>getline</i> or intricate file handling might require significant manual review and adjustment.</li><li><b>Performance:</b> While <i>Perl</i> is generally faster than <i>awk</i> for complex tasks, a directly translated script might not immediately outperform a well-optimized <i>awk</i> script without further <i>Perl</i> optimizations.</li></ul>


title: EXAMPLE USAGE
content:
<br>To convert a simple <i>awk</i> script:<br><i># my_script.awk<br>BEGIN { print "Starting..." }<br>{ print NR, $0 }<br>END { print "Finished." }</i><br>You can translate it using:<br><i>a2p my_script.awk > my_script.pl</i><br>The generated <i>my_script.pl</i> will contain the <i>Perl</i> equivalent code.<br><br>To convert an <i>awk</i> script from standard input with a specific field separator:<br><i>echo '1:2:3' | a2p -F: '{ print NF, $1 }'</i><br>This would output the <i>Perl</i> code that, when run, would print '3 1'.


title: HISTORY
content:
<i>a2p</i> is an integral part of the <i>Perl</i> distribution itself, signifying <i>Perl</i>'s design philosophy as a superset and successor to traditional Unix text-processing tools like <i>awk</i> and <i>sed</i>. It was developed early in <i>Perl</i>'s history to facilitate the migration of existing text-processing workflows from <i>awk</i> to <i>Perl</i>. This allowed users familiar with <i>awk</i>'s pattern-action paradigm to transition more easily to <i>Perl</i>, which offered greater power, flexibility, and extensibility.


title: SEE ALSO
content:
<b>awk</b>(1)</i>: The original text processing language from which <i>a2p</i> translates scripts., <b>perl</b>(1)</i>: The powerful scripting language that is the target of the translation., <b>s2p</b>(1)</i>: A similar utility for converting <i>sed</i> scripts to <i>Perl</i> scripts.


title: PARAMETERS
content:
<b>-o, --output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>output filename</i>. This option is ignored if multiple input files are provided.<br><br><b>-f, --format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>output image format</i> (<code>png</code> or <code>jpeg</code>). The default format is <code>png</code>.<br><br><b>-w, --width <pixels></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the <i>output image width</i> in pixels. The height will be scaled proportionally to maintain aspect ratio.<br><br><b>-h, --height <pixels></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the <i>output image height</i> in pixels. The width will be scaled proportionally to maintain aspect ratio.<br><br><b>-r, --resolution <dpi></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>output resolution</i> in Dots Per Inch (DPI). The default resolution is 72 DPI.<br><br><b>-p, --pages <range></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>page range(s)</i> to convert (e.g., <code>1-5</code> for pages 1 through 5, <code>3</code> for page 3, or <code>1,4,7</code> for pages 1, 4, and 7).<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses <i>output messages</i>, making the command operate silently.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays <i>verbose information</i> and progress details during processing.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows <i>version information</i> of the <b>a2ping</b> utility and then exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive <i>help message</i> detailing usage and options, and then exits.<br><br>


title: DESCRIPTION
content:
<b>a2ping</b> is a command-line utility that leverages the <b>a2ps</b> and <b>ghostscript</b> (gs) tools to convert a wide range of document types into raster image formats, primarily PNG and JPEG.<br><br>It first uses <b>a2ps</b> to transform the input file(s) into PostScript, then pipes this PostScript output to <b>gs</b> which renders it into the specified image format. This makes <b>a2ping</b> ideal for generating document thumbnails, previews, or for integrating document content into web pages or image galleries. It supports various options to control the output image's dimensions, resolution, format, and specific page ranges. It's a convenient wrapper for a common <b>a2ps | gs</b> workflow.


title: CAVEATS
content:
<b>a2ping</b> relies on <b>a2ps</b> and <b>ghostscript</b> being installed and accessible in the system's PATH. Its capabilities are limited by the input formats supported by <b>a2ps</b> and the rendering quality of <b>ghostscript</b>. Converting large documents or generating images at very high resolutions can consume significant system memory and processing time.


title: TYPICAL USAGE EXAMPLE
content:
A common use case for <b>a2ping</b> is to generate web-ready thumbnails of PDF or text documents. For instance, to create a 200-pixel wide JPEG thumbnail of the first page of <i>document.pdf</i> named <i>doc_thumb.jpg</i>, you would use: <b>a2ping -w 200 -f jpeg -p 1 document.pdf -o doc_thumb.jpg</b>


title: HISTORY
content:
<b>a2ping</b> is part of the larger <b>a2ps</b> (Any to PostScript) project, which originated in the early 1990s as a robust tool to format various text and source code files into PostScript for printing. <b>a2ping</b> was developed later as a convenient wrapper to extend <b>a2ps</b>'s capabilities by leveraging <b>ghostscript</b> to convert the PostScript output into common raster image formats like PNG and JPEG, directly addressing the growing need for document previews and thumbnails outside of a traditional printing context.


title: PARAMETERS
content:
<b><i>-m</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all enabled Apache2 <b>modules</b>.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all enabled Apache2 <b>sites</b> (virtual hosts).<br><br><b><i>-c</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all enabled Apache2 <b>configuration enablers</b> (e.g., <i>charset</i>).<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the Apache2 <b>version string</b>.<br><br><b><i>-M module</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check if a specific Apache2 <i>module</i> is enabled. Returns 0 if enabled, 1 if not.<br><br><b><i>-S site</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check if a specific Apache2 <i>site</i> is enabled. Returns 0 if enabled, 1 if not.<br><br><b><i>-C enabler</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check if a specific Apache2 <i>enabler</i> is enabled. Returns 0 if enabled, 1 if not.<br><br><b><i>-q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Quiet mode</b>. Suppresses informational output, only returning the exit status. Useful for scripting.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report Apache2 <b>version</b>. Similar to <i>-v</i> but often used internally for version checking scripts.<br><br><b><i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a <b>help message</b> and exit.<br><br>


title: DESCRIPTION
content:
<i>a2query</i> is a utility command provided by the <i>apache2</i> package on Debian-based systems (like Ubuntu) to inspect the status of Apache2 web server configurations.<br><br>It allows administrators to quickly determine which <b>modules</b>, <b>virtual hosts</b> (sites), and <b>configuration enablers</b> are currently active. This is particularly useful for debugging, configuration management, and verifying that intended configurations are loaded.<br><br>It works by checking the symbolic links in the <i>mods-enabled</i>, <i>sites-enabled</i>, and <i>conf-enabled</i> directories, which are managed by other Apache2 helper scripts like <i>a2enmod</i>, <i>a2dismod</i>, <i>a2ensite</i>, <i>a2dissite</i>, <i>a2enconf</i>, and <i>a2disconf</i> respectively.


title: CAVEATS
content:
<i>a2query</i> primarily reports based on the <b>symbolic links</b> in <i>*-enabled</i> directories. It does not parse the Apache2 configuration files themselves to verify syntax or actual loading status by the Apache daemon. For full verification of syntax and operational status, <i>apache2ctl configtest</i> should be used.<br><br>The command is specific to <b>Debian-based Apache2 installations</b> that utilize the <i>a2enmod</i>/<i>a2dismod</i> management system. Other Linux distributions might manage Apache differently or provide alternative tools.


title: EXIT STATUS
content:
The command returns an exit status of <b>0 on success</b> (e.g., a specific module/site/enabler is found and enabled) and a <b>non-zero status</b> (typically 1) on failure or if the queried item is not enabled. This behavior makes it highly suitable for use in <b>shell scripts</b> for conditional logic.


title: LOCATION AND PERMISSIONS
content:
On most Debian-based systems, <i>a2query</i> is typically located in <i>/usr/sbin/a2query</i>. While it primarily reads configuration, it often requires <b>root privileges</b> for execution due to the permissions on Apache's configuration directories (e.g., <i>/etc/apache2/</i>).


title: HISTORY
content:
<i>a2query</i> is an integral part of the Apache2 package on <b>Debian and Ubuntu systems</b>. Its development emerged as part of the Debian packaging efforts for Apache2, specifically to complement the <i>a2enmod</i>, <i>a2ensite</i>, and <i>a2enconf</i> utilities. It provides a consistent and programmatic way to query the status of configured Apache components, allowing for more robust automation and management of the web server on these platforms.


title: PARAMETERS
content:
<b><i>-d</i>, <i>--dir</i> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory to scan for AppArmor profiles. The default directory is typically <i>/etc/apparmor.d</i>.<br><br><b><i>-r</i>, <i>--recurse</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively scans specified directories for AppArmor profiles to apply the complain mode change.<br><br><b><i>--reload</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a reload of the profile into the kernel after its mode has been changed. This is often implicit when specifying a profile file, but can be explicit for loaded profile names.<br><br><b><i>--no-reload</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the profile from being reloaded into the kernel after its mode is changed. This can be useful for advanced scripting or specific scenarios.<br><br><b><i>--force</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses confirmation prompts, especially when reloading profiles that are already loaded but in a different mode.<br><br><b><i>-v</i>, <i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for the AppArmor tools suite.<br><br><b><i>-h</i>, <i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a summary of command usage and available options.<br><br><b><i>&lt;file|profile&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to an AppArmor profile file (e.g., <i>/etc/apparmor.d/usr.bin.foo</i>) or the name of an already loaded profile in the kernel.<br><br>


title: DESCRIPTION
content:
<i><b>aa-complain</b></i> is an AppArmor utility designed to modify the enforcement mode of specified AppArmor profiles to 'complain' mode. In this mode, the AppArmor kernel module does not actively prevent actions that violate the profile's rules. Instead, it permits the actions while generating audit messages that record the violations. This functionality is invaluable for AppArmor administrators and developers, as it allows them to observe an application's behavior and identify necessary permissions without disrupting its operation. It's a crucial step for developing and debugging new AppArmor profiles before transitioning them to the stricter 'enforce' mode. Profiles can be specified either by their file path (e.g., <i>/etc/apparmor.d/usr.bin.foo</i>) or by their name if already loaded into the kernel.


title: CAVEATS
content:
<ul><li><i><b>aa-complain</b></i> requires root privileges (e.g., using <i>sudo</i>) to modify AppArmor policies at the kernel level.<br></li><li>While in complain mode, no enforcement is applied; the system only logs policy violations. This means an application could still perform potentially harmful actions.<br></li><li>Changes made using <i><b>aa-complain</b></i> are effective immediately but may not persist across system reboots unless the profile definition files themselves are permanently updated and reloaded upon boot.</li></ul>


title: PROFILE DEVELOPMENT WORKFLOW
content:
Setting a profile to complain mode is a critical initial step in the AppArmor profile development workflow. Developers typically begin by placing a new or existing profile in complain mode using <i><b>aa-complain</b></i>. They then execute the application, allowing it to generate logs of all attempted file accesses and operations. These logs are subsequently analyzed using tools like <i><b>aa-logprof</b></i> or <i><b>aa-genprof</b></i> to automatically generate or refine profile rules. Once a satisfactory set of rules has been established, the profile can be switched back to enforcing mode using <i><b>aa-enforce</b></i>.


title: HISTORY
content:
<i><b>aa-complain</b></i> is a core utility within the AppArmor security framework. AppArmor originated with Immunix, later acquired by Novell, and became a key security feature in SUSE Linux Enterprise Server and openSUSE distributions. It was integrated into the mainline Linux kernel in version 2.6.23. From its early development, <i><b>aa-complain</b></i> has been an indispensable tool, facilitating the iterative process of creating, testing, and refining AppArmor security profiles.


title: SEE ALSO
content:
apparmor(7), aa-enforce(8), aa-disable(8), aa-logprof(8), aa-genprof(8), aa-status(8), apparmor_parser(8)


title: PARAMETERS
content:
<b><I>&lt;profile_path&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to one or more AppArmor profile files (e.g., <I>/etc/apparmor.d/usr.bin.firefox</I>) to be disabled. Multiple paths can be specified, separated by spaces.<br><br><b><b>-d</b> <I>&lt;directory&gt;</I>, <b>--dir</b> <I>&lt;directory&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternative base directory where AppArmor profiles are stored, instead of the default location (typically `/etc/apparmor.d/`).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br>


title: DESCRIPTION
content:
The <b>aa-disable</b> command is part of the AppArmor security framework on Linux. AppArmor is a Mandatory Access Control (MAC) system that allows system administrators to restrict program capabilities with per-program profiles. <br><br>When a profile is 'enforced', AppArmor applies the rules defined within it to the associated application, limiting its access to system resources. <b>aa-disable</b> serves to unload one or more AppArmor profiles from the kernel and move their corresponding files from the `enforce` directory (e.g., `/etc/apparmor.d/enforce/`) to the `disable` directory (e.g., `/etc/apparmor.d/disable/`). This action effectively removes the security restrictions imposed by the profile, allowing the program to run with its default system permissions. <br><br>It is commonly used for debugging applications, troubleshooting AppArmor-related issues, or temporarily relaxing security policies when compatibility problems arise. Using <b>aa-disable</b> requires root privileges.


title: CAVEATS
content:
Disabling AppArmor profiles significantly <I>reduces the security posture</I> of the system or the affected application, potentially exposing it to vulnerabilities that the profile was designed to mitigate. <br><br>While <b>aa-disable</b> unloads the profile from the kernel, processes already running under the previously enforced profile might not immediately reflect the change until they are restarted. It is recommended to restart affected services or the system for full effect. <br><br>This command requires <I>root privileges</I> (e.g., via <b>sudo</b>) to operate.


title: PROFILE PERSISTENCE
content:
When a profile is disabled using <b>aa-disable</b>, it is not deleted from the system. Instead, its file is moved to a 'disabled' subdirectory (e.g., <I>/etc/apparmor.d/disable/</I>). This allows for easy re-enforcement later using the <b>aa-enforce</b> command without needing to recreate the profile.


title: HISTORY
content:
AppArmor was originally developed by <I>Immunix</I> and later acquired by <I>Novell</I> in 2005. It was integrated into the <I>openSUSE</I> distribution and subsequently adopted by <I>Ubuntu</I> as its default MAC system. The <b>aa-disable</b> utility, along with other <b>aa-*</b> commands, is part of the <I>apparmor-utils</I> package, which provides a set of tools for managing AppArmor profiles. Its development has progressed with AppArmor itself, aiming to simplify profile management for system administrators.


title: SYNOPSIS
content:
<b>aa-enforce</b> [<i>OPTION</i>]... <i>PROFILE_PATH</i><br>or<br><b>aa-enforce</b> [<i>OPTION</i>]... --dir <i>DIRECTORY</i> [<i>--recursive</i>]


title: PARAMETERS
content:
<b>-d, --dir <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory to scan for AppArmor profiles to enforce.<br><br><b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with --dir to recursively scan subdirectories for profiles.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity of output.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's version information and exits.<br><br>


title: DESCRIPTION
content:
<b>aa-enforce</b> is a command-line utility used to activate the enforcement mode for one or more AppArmor profiles. When an AppArmor profile is in <b>enforce</b> mode, it actively mediates and restricts an application's behavior according to the rules defined in the profile. Any action that violates these rules will be denied, and an audit message will be generated. This contrasts with <b>complain</b> mode, where violations are only logged without preventing the action. Transitioning a profile from <b>complain</b> to <b>enforce</b> is a critical step in deploying AppArmor security, as it moves from passive monitoring to active protection. It's typically used after a profile has been thoroughly tested and refined in <b>complain</b> mode to avoid breaking legitimate application functionality. The command requires root privileges to operate, as it modifies kernel-level security policies.


title: CAVEATS
content:
Enforcing an AppArmor profile without proper testing can lead to applications breaking or misbehaving, as legitimate operations might be denied. It is highly recommended to develop and test profiles in <b>complain</b> mode first, using tools like <b>aa-logprof</b> to refine rules, before switching to <b>enforce</b> mode. Also, ensure the AppArmor service is running (e.g., using <b>systemctl status apparmor</b>).


title: PROFILE LOCATION
content:
AppArmor profiles are typically stored in the <i>/etc/apparmor.d/</i> directory. When specifying <i>PROFILE_PATH</i>, you usually refer to a file within this directory or its subdirectories.


title: ROOT PRIVILEGES
content:
The <b>aa-enforce</b> command requires superuser privileges (e.g., using <b>sudo</b>) to modify kernel-level AppArmor policies.


title: HISTORY
content:
AppArmor, and consequently <b>aa-enforce</b>, originated with Novell and was later adopted by distributions like Ubuntu. It serves as a Mandatory Access Control (MAC) system for Linux, providing an alternative to SELinux. Its development focuses on ease of use and profile creation, distinguishing it from other MAC systems.


title: DESCRIPTION
content:
<b>aa-status</b> is a utility from the AppArmor security framework that provides a concise overview of the current AppArmor system status. AppArmor is a Linux security module that allows administrators to restrict programs' capabilities with per-program profiles. <b>aa-status</b> reports which AppArmor profiles are currently loaded into the kernel, their operational modes (e.g., <I>enforce</I> or <I>complain</I>), and the number of processes currently running under each profile.<br><br>It also indicates the number of processes that are unconfined or not currently restricted by AppArmor. This command is essential for quickly verifying the state of AppArmor enforcement on a system.


title: CAVEATS
content:
Requires root privileges (or <I>sudo</I>) to execute <b>aa-status</b> successfully and display comprehensive information. Running it as a non-privileged user might result in an error or incomplete output. The output can be extensive on systems with many loaded AppArmor profiles.


title: <I>UNDERSTANDING APPARMOR MODES</I>
content:
<I>aa-status</I> reports profiles in different modes:<br><br><b>enforce</b>: In this mode, the profile actively prevents a program from performing actions not permitted by its rules. Any attempts to violate the profile are blocked and logged.<br><br><b>complain</b>: In this mode, the profile does not actively block any actions. Instead, it logs policy violations, allowing administrators to gather information about what a program attempts to do without disrupting its operation. This mode is often used for profiling and debugging new or updated applications.<br><br><b>unconfined</b>: This refers to processes or files that are not currently under the control of any AppArmor profile. <b>aa-status</b> will report the number of processes that are "unconfined" on the system.


title: HISTORY
content:
AppArmor originated from Immunix and was later acquired by Novell in 2005, which then open-sourced it. It became a core security feature in SUSE Linux Enterprise and openSUSE. Ubuntu adopted AppArmor as its default Mandatory Access Control (MAC) system starting with Ubuntu 7.04 (Feisty Fawn). The <b>aa-status</b> utility has been a fundamental part of the AppArmor toolset since its early development, providing a quick way to inspect the state of the security module.


title: SYNOPSIS
content:
<b>aapt</b> &lt;<i>command</i>&gt; [<i>options</i>] [<i>arguments</i>]<br><br>Common command usage examples:<br><b>aapt package</b> [<i>options</i>] <b>-M</b> &lt;<i>AndroidManifest.xml</i>&gt; <b>-I</b> &lt;<i>android.jar</i>&gt; <b>-S</b> &lt;<i>resource_dir</i>&gt; <b>-F</b> &lt;<i>output.apk</i>&gt;<br><b>aapt dump</b> &lt;<i>subcommand</i>&gt; &lt;<i>file.apk</i>&gt;


title: PARAMETERS
content:
<b><b>package</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Creates or updates an APK file, processing resources and assets.<br><br><b><b>dump</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Dumps detailed information from an APK file, specified by a sub-option (e.g., <i>badging</i>, <i>resources</i>).<br><br><b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Lists the contents of an APK file, similar to <i>zip -l</i>.<br><br><b><b>add</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Adds a new file to an existing APK archive.<br><br><b><b>remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Removes a file from an existing APK archive.<br><br><b><b>crunch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Optimizes (crunches) PNG files, typically reducing file size. This is usually done automatically during packaging.<br><br><b><b>version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Subcommand:</I> Prints the <i>aapt</i> version number.<br><br><b><b>-S</b> &lt;<i>dir</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the path to a resource directory. Can be used multiple times.<br><br><b><b>-A</b> &lt;<i>dir</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the path to an assets directory. Can be used multiple times.<br><br><b><b>-I</b> &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the path to an Android framework JAR file (e.g., <i>android.jar</i>) to include for compilation.<br><br><b><b>-M</b> &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the path to the <i>AndroidManifest.xml</i> file.<br><br><b><b>-F</b> &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the output APK file name.<br><br><b><b>-J</b> &lt;<i>dir</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies the directory where the <i>R.java</i> file should be generated.<br><br><b><b>-0</b> &lt;<i>extension</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Specifies file extensions that should not be compressed in the APK (e.g., <i>.png</i>, <i>.jpg</i>).<br><br><b><b>--no-compress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Option (for package):</I> Prevents compression of any files within the APK.<br><br><b><b>badging</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sub-option (for dump):</I> Dumps human-readable information about the APK, including application label, icon, permissions, and activities.<br><br><b><b>permissions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sub-option (for dump):</I> Dumps the permissions declared in the APK's manifest.<br><br><b><b>xmltree</b> &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Sub-option (for dump):</I> Dumps a binary XML file (e.g., <i>AndroidManifest.xml</i>) as a human-readable XML tree structure.<br><br>


title: DESCRIPTION
content:
<i>aapt</i>, the <b>Android Asset Packaging Tool</b>, is a command-line utility integral to the Android SDK's build process. It compiles and packages application resources (such as layouts, strings, and images) and compiled code into an Android application package (<b>.apk</b>) file. This tool is responsible for tasks like parsing <i>AndroidManifest.xml</i>, compiling resource directories, and generating the binary <i>resources.arsc</i> file that points to compiled resources. Beyond packaging, <i>aapt</i> also provides functionalities to inspect existing <b>APKs</b>, allowing users to dump various details including package information, activities, permissions, and resource tables. While typically invoked by higher-level build systems like Gradle, it can be used directly for specific development and debugging purposes. It plays a crucial role in bridging raw application assets with the final distributable Android package.


title: CAVEATS
content:
<i>aapt</i> has largely been superseded by <b>aapt2</b>, which offers improved performance, better error reporting, and supports incremental compilation. While still present in the Android SDK Build-Tools, modern Android development typically relies on Gradle, which internally uses <i>aapt2</i>. Direct usage of <i>aapt</i> is generally for specific inspection or legacy build scenarios.


title: AAPT VS. AAPT2
content:
The primary difference between <i>aapt</i> and <i>aapt2</i> lies in their architecture and performance. <i>aapt2</i> splits the packaging process into two distinct steps: <b>compile</b> and <b>link</b>. This separation allows for incremental compilation, meaning only modified resources need to be recompiled, significantly speeding up build times. <i>aapt2</i> also provides more detailed error reporting and better support for modern Android features and resource types, making it the preferred tool for current Android development.


title: HISTORY
content:
<b>aapt</b> has been a foundational component of the Android SDK since its inception, serving as the primary tool for packaging application resources and assets into APKs. Its capabilities were essential for the entire Android build pipeline. As Android development evolved and projects grew in complexity, the need for faster, more robust, and incrementally compilable resource processing became evident. This led to the development and introduction of <b>aapt2</b> (Android Asset Packaging Tool 2), which became the default resource processor for the Android Gradle Plugin starting with AGP 3.0.0. While <b>aapt</b> remains available, <b>aapt2</b> is now the recommended and actively developed tool for Android resource compilation and packaging.


title: SYNOPSIS
content:
<code>ab <i>[options]</i> <i>[http[s]://]hostname[:port]/path</i></code><br><br><i>Example:</i><br><code>ab -n 1000 -c 10 https://example.com/index.html</code>


title: PARAMETERS
content:
<b>-n <i>requests</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Number of requests to perform for the benchmarking session.</i><br><br><b>-c <i>concurrency</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Number of multiple requests to perform at a time.</i><br><br><b>-t <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Maximum number of seconds to spend for benchmarking. Requests will be aborted after this time.</i><br><br><b>-p <i>postdata_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>File containing data to POST. Use with <code>-T</code> to specify Content-Type.</i><br><br><b>-T <i>content-type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Content-type header to use for POST/PUT data. E.g., <code>application/json</code>.</i><br><br><b>-v <i>verbosity</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>How much information to print. Levels 0 to 4 (more verbose).</i><br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use HTTP KeepAlive feature, i.e., send multiple requests within one HTTP session.</i><br><br><b>-H <i>header</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Add arbitrary header line to the request. E.g., <code>'Authorization: Bearer xyz'</code>.</i><br><br><b>-A <i>auth-string</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Add Basic WWW Authentication header to requests. Format: <code>user:password</code>.</i><br><br><b>-X <i>proxy[:port]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use specified proxy server for requests.</i><br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Perform HEAD requests instead of GET.</i><br><br><b>-e <i>csv_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output results to a CSV file, useful for spreadsheet analysis.</i><br><br><b>-g <i>gnuplot_file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output results in gnuplot format, for graphical plotting.</i><br><br><b>-s <i>timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Seconds to wait for the entire request to complete. Default is 30 seconds.</i><br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Do not display confidence intervals and warnings for latency.</i><br><br>


title: DESCRIPTION
content:
<i><code>ab</code>, short for <b>ApacheBench</b>, is a command-line tool designed for benchmarking HTTP servers. It measures the performance of web servers by sending a specified number of concurrent requests to a URL and reporting various metrics. These metrics include requests per second, time per request, transfer rate, latency, and throughput.</i><br><br><i>It's commonly used by developers and system administrators to understand how many requests an Apache (or any HTTP-compliant) web server can handle within a given timeframe, helping to identify potential bottlenecks, test server configurations, and evaluate the impact of code changes on server performance. While it's part of the Apache HTTP Server distribution, it can be used to benchmark any web server capable of handling HTTP/1.0 and HTTP/1.1 requests. Its simplicity and speed make it ideal for quick performance checks.</i>


title: CAVEATS
content:
<i><code>ab</code> operates from a single client machine, which may not accurately simulate distributed user load from multiple geographical locations. The client machine itself can become a bottleneck if it lacks sufficient resources (CPU, network bandwidth) to generate the desired load. It primarily supports HTTP/1.0 and HTTP/1.1, potentially missing out on benefits or nuances of newer protocols like HTTP/2 or HTTP/3. <code>ab</code> cannot execute JavaScript or simulate complex user behavior (e.g., login, navigate, click), making it unsuitable for advanced end-to-end user experience testing. It also does not fetch embedded resources (images, CSS, JS), only the specified URL.</i>


title: OUTPUT INTERPRETATION
content:
<i><code>ab</code> provides a summary of its test run, including the total number of requests, failed requests, transferred data, and most importantly, throughput (requests per second) and time per request (mean, median, min/max). It also presents a percentage served table, showing the latency distribution (e.g., 50% of requests completed within X ms, 90% within Y ms), which is crucial for understanding response time consistency and identifying outliers.</i>


title: BEST PRACTICES
content:
<i>For accurate results, run <code>ab</code> from a different machine than the server being tested to avoid client-side resource contention. Perform multiple runs to account for network variability and server warm-up. Ensure the test URL accurately reflects the resource you intend to benchmark (e.g., a dynamic page vs. a static file). Avoid running overly aggressive tests that might degrade the performance of other services on the same network or even trigger security countermeasures.</i>


title: HISTORY
content:
<i><code>ab</code> is an integral part of the Apache HTTP Server distribution. It was developed by the Apache Software Foundation community as a simple and quick utility for testing the performance of web servers. Its development has been primarily driven by the needs of the Apache project, focusing on efficient HTTP/1.0 and HTTP/1.1 benchmarking. While ApacheBench itself has seen incremental updates over the years, its core functionality and usage remain consistent, reflecting its purpose as a straightforward command-line utility for performance assessments.</i>


title: SEE ALSO
content:
wrk(1): <i>A modern HTTP benchmarking tool capable of generating significant load.</i>, siege(1): <i>HTTP regression testing and benchmarking utility.</i>, curl(1): <i>Transfer data from or to a server, often used for testing HTTP endpoints.</i>, wget(1): <i>Non-interactive network downloader, useful for simple HTTP testing.</i>


title: SYNOPSIS
content:
<b>abbr</b> [<i>options</i>] [<i>NAME</i> [<i>VALUE</i>]]<br><b>abbr --add</b> <i>NAME VALUE</i><br><b>abbr --erase</b> <i>NAME</i>...<br><b>abbr --show</b> [<i>NAME</i>...]


title: PARAMETERS
content:
<b><b>--add</b>, <b>-a</b> <i>NAME VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new abbreviation mapping <i>NAME</i> to <i>VALUE</i>.<br><br><b><b>--erase</b>, <b>-e</b> <i>NAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases one or more existing abbreviations by <i>NAME</i>.<br><br><b><b>--set</b>, <b>-s</b> <i>NAME VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the value of an existing abbreviation <i>NAME</i> to <i>VALUE</i>.<br><br><b><b>--rename</b>, <b>-r</b> <i>OLD_NAME NEW_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renames an existing abbreviation from <i>OLD_NAME</i> to <i>NEW_NAME</i>.<br><br><b><b>--show</b>, <b>-S</b> [<i>NAME</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all or specific abbreviations, showing their name and value.<br><br><b><b>--list</b>, <b>-l</b> [<i>NAME</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists abbreviations in a machine-readable format, suitable for scripting.<br><br><b><b>--function</b>, <b>-f</b> <i>NAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts one or more abbreviations into a function. This is often used to get more complex behavior than simple expansion allows.<br><br><b><b>--global</b>, <b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the abbreviation permanent by saving it to the fish configuration, accessible in future sessions.<br><br><b><b>--session</b>, <b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the abbreviation temporary, valid only for the current shell session and not saved.<br><br><b><b>--description</b> <i>TEXT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a descriptive text to the abbreviation, visible with <b>abbr --show</b>.<br><br><b><b>--regex</b> <i>REGEX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output of <b>--show</b> or the targets of <b>--erase</b>/<b>--disable</b>/<b>--enable</b>/<b>--toggle</b> by a regular expression.<br><br><b><b>--disable</b>, <b>-D</b> <i>NAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Temporarily disables one or more abbreviations without erasing them.<br><br><b><b>--enable</b>, <b>-E</b> <i>NAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables one or more previously disabled abbreviations.<br><br><b><b>--toggle</b> <i>NAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Toggles the enabled/disabled state of one or more abbreviations.<br><br><b><b>--reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases all current abbreviations.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b>abbr</b> command.<br><br>


title: DESCRIPTION
content:
The <i>abbr</i> command is an integral part of the <b>fish</b> (friendly interactive shell), used for managing command abbreviations. Unlike traditional shell aliases that substitute a command during execution, <i>abbr</i> expands a short keyword into a longer command <b>before</b> it is parsed by the shell. This pre-parsing expansion allows for features like argument completion on the expanded form, which is a significant advantage over aliases. It helps users type less for frequently used commands or create memorable shortcuts. Abbreviations can be defined for the current session or saved globally to persist across shell sessions. They are a powerful tool for streamlining workflow and enhancing productivity within the fish shell environment.


title: CAVEATS
content:
The <i>abbr</i> command is exclusive to the <b>fish</b> shell. It is not a standard Unix/Linux command and will not work in other shells like Bash or Zsh. Users of other shells should look for similar functionality provided by their shell (e.g., <i>alias</i> or functions).


title: ABBREVIATION VS. ALIAS
content:
While conceptually similar in saving typing, <b>abbr</b> in fish differs significantly from the <i>alias</i> command found in Bash or Zsh. An <b>abbr</b> expands the abbreviation into its full form <b>before</b> the command line is parsed. This means that command-line completions and argument handling work on the expanded command, not the abbreviation itself. For example, if you have <b>abbr gc 'git commit'</b>, typing <b>gc -m</b> will offer completions relevant to <b>git commit</b>, whereas an <i>alias</i> might not provide the same context.


title: PERSISTENCE
content:
By default, abbreviations defined without the <b>--global</b> or <b>--session</b> flags are temporary. To make an abbreviation persistent across shell sessions, the <b>--global</b> (<b>-g</b>) flag must be used when adding it. Fish saves global abbreviations in its configuration directory (typically <i>~/.config/fish/abbreviations</i>), ensuring they are loaded automatically upon shell startup.


title: HISTORY
content:
The <i>abbr</i> command is a core feature of the <b>fish</b> shell, designed to enhance user experience and productivity. It has been an integral part of <b>fish</b> since its early development, reflecting the shell's philosophy of being user-friendly and feature-rich out-of-the-box. Its implementation provides a distinct advantage over simple aliases by allowing pre-execution expansion and completion.


title: SEE ALSO
content:
fish(1), alias(1) <i>(conceptually similar in other shells)</i>, function(1) <i>(for defining more complex shell commands in fish)</i>


title: SYNOPSIS
content:
<b>abduco</b> [<i>options</i>] [<i>command</i> [<i>arg ...</i>]]<br><br>Common usage examples:<br><b>abduco</b> <b>-l</b><br><b>abduco</b> <b>-n</b> <i>session_name</i> [<i>command</i> [<i>arg ...</i>]]<br><b>abduco</b> <b>-a</b> <i>session_name</i><br><b>abduco</b> <b>-A</b> <i>session_name</i> [<i>command</i> [<i>arg ...</i>]]<br><b>abduco</b> <b>-d</b> <i>session_name</i><br><b>abduco</b> <b>-x</b> <i>session_name</i>


title: PARAMETERS
content:
<b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reattach to a session if it exists. If not, it will typically exit.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new session if the specified session does not exist. If it does, it will typically exit.<br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Auto) Reattach to a session if it exists, otherwise create a new one. Equivalent to <b>abduco -rc</b>.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all currently active <i>abduco</i> sessions.<br><br><b>-a <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attach to the specified <i>session</i>.<br><br><b>-e <cmd></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute <i>cmd</i> inside the attached session (requires <i>-a</i>).<br><br><b>-n <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new session named <i>session</i>. If <i>command</i> is provided, it runs that command; otherwise, it starts a shell.<br><br><b>-d <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach (disconnect) from the specified <i>session</i>.<br><br><b>-x <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Kill (terminate) the specified <i>session</i> and all processes running within it.<br><br><b>-q <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query the status of the specified <i>session</i> (e.g., whether it's attached or detached).<br><br><b>-k <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disconnect (kick) any attached client from the specified <i>session</i>, but leave the session running.<br><br><b>-s <session></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a shell within the specified <i>session</i> (requires <i>-a</i>).<br><br>


title: DESCRIPTION
content:
<i>Abduco</i> is a minimal and efficient session manager for terminal programs, designed with the <br>suckless philosophy of simplicity and conciseness in mind. It allows users to <br><b>detach</b> running programs from their controlling terminal, letting them continue to <br>execute in the background, and then <b>reattach</b> to them later from the same or a different <br>terminal. Unlike more feature-rich multiplexers like <i>GNU Screen</i> or <i>tmux</i>, <br><i>abduco</i> focuses solely on session detachment and reattachment, providing a <br>straightforward and lightweight solution for persistent terminal sessions. It leverages <br>the underlying <i>dtach</i> utility for its core detachment functionality. This design makes <br><i>abduco</i> ideal for users who prefer a minimalist approach and do not require <br>features such as multiple windows, panes, or extensive scrollback buffers built into the <br>session manager itself. It's particularly useful for keeping long-running processes <br>alive across network disconnections or when switching between different terminal <br>emulators.


title: CAVEATS
content:
<i>Abduco</i>'s minimalist design means it lacks many features found in more complex terminal <br>multiplexers. It does not provide built-in support for multiple windows, panes, <br>scrollback buffers, or extensive customization options. Its session files are by default <br>created in the current working directory, which means sessions are context-dependent <br>unless an absolute path for the session file is specified. The underlying detachment <br>mechanism relies on <i>dtach</i>, which handles the core process management, and any limitations <br>or behaviors of <i>dtach</i> can indirectly affect <i>abduco</i>.


title: <I>SESSION PERSISTENCE & SHARING</I>
content:
<i>Abduco</i> sessions provide persistence for programs. A session, once created, continues <br>to run even after the client terminal detaches or closes. This means long-running tasks <br>like compilations or server processes can be started and left to run independently. <br>Furthermore, multiple clients can attach to the same <i>abduco</i> session concurrently, <br>allowing for shared terminal sessions, which can be useful for collaborative work or <br>demonstrations where several users need to view the same terminal output and interact <br>with the same process.


title: <I>UNDERLYING MECHANISM</I>
content:
<i>Abduco</i> internally utilizes the <i>dtach</i> utility, which provides the core functionality <br>for detaching and attaching processes from controlling terminals. When a new <i>abduco</i> <br>session is created, <i>abduco</i> essentially wraps <i>dtach</i>, setting up a socket or named pipe <br>in the background. This socket serves as the communication channel between the <br>detached process and any future attaching clients. When a client attaches, it connects <br>to this socket, and all terminal I/O is redirected through it. Detaching simply means <br>disconnecting from this socket while the underlying process managed by <i>dtach</i> continues <br>to run. This design choice offloads the complex task of terminal emulation and process <br>management to a dedicated, proven utility, allowing <i>abduco</i> to remain small and focused <br>on its session management role.


title: HISTORY
content:
<i>Abduco</i> is part of the <br>suckless.org project, which advocates for software that is simple, secure, and <br>small. It was developed to provide a lightweight alternative to existing terminal <br>multiplexers, adhering strictly to the Unix philosophy of doing one thing and doing it <br>well. Its development focuses on code clarity and minimal dependencies, building upon <br>the established <i>dtach</i> utility rather than reimplementing core process detachment. This <br>approach reflects a commitment to simplicity and efficiency in terminal session <br>management.


title: DESCRIPTION
content:
The command 'abroot' does not appear to be a standard or commonly recognized utility within major Linux distributions (e.g., Debian, Ubuntu, Red Hat, Fedora, Arch Linux). <br><br>While commands like <b>chroot(1)</b> are standard for changing the apparent root directory for a running process, 'abroot' is not documented in typical man pages nor found in standard system binaries. <br><br>It is possible that 'abroot' is a typo (e.g., for `chroot`), a custom script developed for a very specific environment, or part of a highly specialized application or development project. Without further context or information about its origin, it is not possible to analyze its functionality, options, or typical usage.


title: CAVEATS
content:
<b>'abroot' is not a standard Linux command.</b> Users should verify the spelling of the command or confirm if it is a custom script or part of a specific third-party tool they are using. Attempting to execute 'abroot' on a typical Linux system will likely result in a 'command not found' error.


title: HISTORY
content:
As 'abroot' is not a standard Linux command, there is no documented history of its development or widespread usage within the Linux kernel or common userland utilities.


title: PARAMETERS
content:
<b><i>COMMANDS</i>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>abrt-cli</b> operates with various subcommands to perform specific actions. Common commands include:<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all detected problems.<br><br><b>info <i>PROBLEM_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific problem identified by its ID.<br><br><b>report <i>PROBLEM_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the process of reporting a problem to a configured bug tracking system.<br><br><b>process <i>PROBLEM_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes a problem, e.g., analyzes it, generates a backtrace, or prepares it for reporting.<br><br><b>remove <i>PROBLEM_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a detected problem and all its associated data from storage.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current status of the ABRT daemon and its activities.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages ABRT configuration settings, allowing adjustments to reporting, storage, and monitoring behavior.<br><br><b><i>OPTIONS</i>:</b><br>&nbsp;&nbsp;&nbsp;&nbsp;General options applicable to the <b>abrt-cli</b> command:<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output for troubleshooting and detailed information.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details on command execution.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message for the command or a specific subcommand and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for <b>abrt-cli</b> and exits.<br><br>


title: DESCRIPTION
content:
ABRT (Automatic Bug Reporting Tool) is a suite of utilities designed to help users detect, analyze, and report software crashes, kernel oops, and other application problems on Linux systems. It acts as a proactive guardian, automatically intercepting unexpected program terminations or system errors.<br><br>When a problem occurs, ABRT collects relevant diagnostic information, such as core dumps, backtraces, and system logs, storing it in a structured format. This data is crucial for developers to identify the root cause of issues.<br><br>While <i>abrtd</i> (the ABRT daemon) runs in the background monitoring for problems, the primary command-line interface for user interaction with the ABRT system is <b>abrt-cli</b>. This command allows users to list detected problems, view detailed information about them, process problem data (e.g., analyze, pack), and report bugs to various bug tracking systems (like Bugzilla) or vendor-specific platforms.<br><br>ABRT aims to simplify the bug reporting process, making it accessible even for non-technical users, thereby improving the overall stability and quality of software.


title: CAVEATS
content:
ABRT collects sensitive system information, including potentially private data from crashed applications. Users should review the data being reported before submission to ensure privacy. It also consumes system resources for monitoring and data collection, which can be noticeable on systems with frequent crashes or very limited resources. Proper configuration is essential to manage disk space usage and reporting destinations.


title: ABRT ARCHITECTURE
content:
The ABRT system consists of several components working in tandem:<br><i>abrtd</i>: The core daemon that monitors for problems and dispatches problem data.<br><i>abrt-action-*</i>: A series of modular plugins that perform specific actions (e.g., analyzing dumps, packing data, reporting to different services).<br><i>abrt-cli</i>: The command-line interface for user interaction and management.<br><i>abrt-applet</i>: A graphical user interface (GUI) for desktop environments, providing visual notifications and reporting options.<br><br>Problem data is typically stored under <i>/var/spool/abrt/</i>.


title: INTEGRATION WITH SYSTEMD
content:
ABRT leverages <i>systemd</i> for its functionality, particularly for handling crashed processes and managing core dumps. <i>systemd-coredump</i> can be configured to integrate seamlessly with ABRT, ensuring that core dumps are processed and managed by the ABRT system for easier reporting and analysis, centralizing crash handling.


title: HISTORY
content:
ABRT was initially developed by Red Hat and is a prominent feature in Fedora and Red Hat Enterprise Linux. Its development began with the goal of simplifying the complex process of bug reporting, making it more accessible to a broader user base and improving the feedback loop between users and developers. It has evolved significantly to handle various types of crashes and integrate with different reporting backends.


title: SYNOPSIS
content:
<b>abrt-action-analyze-backtrace</b> [-d <I>PROBLEM_DIR</I>] [-f <I>BACKTRACE_FILE</I>] [<I>OPTIONS</I>]


title: PARAMETERS
content:
<b>-d <I>PROBLEM_DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <I>ABRT</I> problem directory containing the backtrace and related crash information to be analyzed. If omitted, the command typically expects to be run from within an <I>ABRT</I> problem directory or for the context to be inherited.<br><br><b>-f <I>BACKTRACE_FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative backtrace file within the problem directory to analyze (e.g., <i>backtrace-0</i>, <i>backtrace-1</i>) instead of the default <i>backtrace</i> file.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in quiet mode, suppressing non-essential output.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in verbose mode, providing more detailed output about the analysis process.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>abrt-action-analyze-backtrace</b> command is an integral part of the <I>ABRT</I> (Automatic Bug Reporting Tool) system in Linux. Its primary purpose is to process and analyze existing backtrace files within an <I>ABRT</I> problem directory, typically generated after a software crash or hang.<br><br>It examines various files such as <i>backtrace</i>, <i>bt_src</i>, <i>exec_path</i>, and <i>maps</i> to identify the exact cause of the crash, including the failing function, library, or software component. The analysis results are then used to populate key fields within the problem directory, such as 'reason', 'component', 'cc_component', and 'kernel_component'. This information is crucial for grouping similar crashes, prioritizing bug reports, and providing developers with actionable insights.<br><br>While it can be invoked manually, it is most commonly triggered automatically by other <I>ABRT</I> components or services as part of the automated crash reporting and analysis workflow.


title: CAVEATS
content:
This command is primarily an internal utility of the <I>ABRT</I> system and is not typically intended for direct, standalone use by end-users for general debugging. Its functionality relies heavily on the specific structure and content of <I>ABRT</I> problem directories. Manual invocation without the proper <I>ABRT</I> context or directory structure may lead to unexpected behavior or incomplete analysis. It analyzes existing backtraces; it does not generate them.


title: AUTOMATED WORKFLOW INTEGRATION
content:
<b>abrt-action-analyze-backtrace</b> is a critical step in the automated <I>ABRT</I> workflow. After a crash is detected and a core dump (if available) is processed, <I>ABRT</I> creates a problem directory. This action is then typically invoked to extract meaningful information from the backtrace, helping to categorize the problem before it's reported or further processed.


title: OUTPUT FIELDS
content:
The command's primary output is not to standard output, but rather to populate specific files or fields within the target <I>ABRT</I> problem directory. Key fields include:<br><br><I>reason</I>: A concise string identifying the primary cause (e.g., 'segfault in foo()').<br><I>component</I>: The software component or package likely responsible.<br><I>cc_component</I>: Specific C/C++ component if applicable.<br><I>kernel_component</I>: Specific kernel component if the crash is kernel-related.<br><br>These fields are used by other <I>ABRT</I> tools for deduplication and reporting.


title: HISTORY
content:
<I>ABRT</I>, and by extension its constituent actions like <b>abrt-action-analyze-backtrace</b>, has been a core component of Red Hat-based Linux distributions (like Fedora and RHEL) for automated bug reporting for many years. Its development has focused on streamlining the crash reporting process, improving automated analysis to reduce manual triage, and enabling more efficient bug fixing. Over time, the analysis heuristics and integration with system debug information have evolved significantly.


title: PARAMETERS
content:
<b>-d, --dir DIRECTORY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the problem directory to operate on. If not provided, the current working directory is used.<br><br><b>-o, --output-dir DIRECTORY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes analysis output to the specified directory instead of the problem directory. This is typically used internally by ABRT.<br><br><b>-u, --user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyzes the crash for the current user's session.<br><br><b>--not-user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyzes the crash for the entire system, not just the user session (default behavior for system-wide ABRT instances).<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the command's output.<br><br><b>-y, --yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assumes "yes" to all interactive questions, if any, allowing non-interactive operation.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<b>abrt-action-analyze-c</b> is a specialized plugin within the <I>Automatic Bug Reporting Tool (ABRT)</I> suite, designed to analyze crashes and issues originating from C and C++ applications. When a C/C++ program crashes, ABRT collects relevant data, such as core dumps, executables, and backtraces, into a "problem directory". This command is then invoked, typically by ABRT itself, to process this collected data. It leverages <I>gdb</I> (GNU Debugger) to perform a deep analysis of the coredump or backtrace. The primary goal is to extract critical information about the crash, including the exact function where the crash occurred, the full stack trace, the involved executable, and the related component. This analysis results in various variables being added to the problem directory's metadata, such as <I>reason</I>, <I>backtrace</I>, <I>executable</I>, <I>component</I>, and <I>kerneloops</I> (if applicable). This information is crucial for ABRT to categorize, deduplicate, and eventually report the bug effectively. It requires the problem directory to contain at least a <I>coredump</I> (or <I>coredump.gz</I>) or a <I>backtrace</I> file, along with the <I>executable</I> file.


title: CAVEATS
content:
For effective analysis, especially when analyzing core dumps, the system needs to have the corresponding debugging symbols (<I>debuginfo</I> packages) installed for the crashing application and its libraries. Without debuginfo, stack traces might be incomplete or show only hexadecimal addresses, making analysis less useful. The command relies heavily on the presence of specific files (<I>coredump</I>, <I>executable</I>, <I>backtrace</I>) within the designated problem directory. It also requires <I>gdb</I> (GNU Debugger) to be installed and accessible on the system.


title: PROBLEM DIRECTORY STRUCTURE
content:
The command operates on a "problem directory", which is a directory created by ABRT containing all collected data related to a specific crash event. For <I>abrt-action-analyze-c</I> to function optimally, this directory typically must contain at least one of the following: a <I>coredump</I> file (or <I>coredump.gz</I>), or a <I>backtrace</I> file. Additionally, the <I>executable</I> file of the crashed program is crucial for proper symbol resolution and analysis.


title: ROLE IN ABRT WORKFLOW
content:
This action is part of the second stage of the ABRT workflow: <I>analysis</I>. After ABRT collects crash data into a problem directory (the <I>collection</I> stage), various <I>abrt-action-analyze-*</I> plugins are invoked to process the data. <I>abrt-action-analyze-c</I> specifically handles C/C++ application crashes, adding crucial metadata. This analyzed information then aids ABRT in the <I>reporting</I> stage, where the categorized crash data can be sent to bug trackers or developers.


title: HISTORY
content:
ABRT (Automatic Bug Reporting Tool) was developed by Red Hat to streamline the process of collecting and reporting software crashes and other issues on Linux systems, particularly Fedora and Red Hat Enterprise Linux. The <I>abrt-action-analyze-c</I> command is a fundamental component of the ABRT framework, integral to its ability to automatically process and categorize application-level crashes from C/C++ programs. It has been a part of ABRT's core functionality for many years, evolving with the tool to provide increasingly robust and automated crash analysis.


title: SYNOPSIS
content:
<b>abrt-cli</b> <i>[options]</i> <i>&lt;command&gt;</i> <i>[command_options]</i> <i>[arguments]</i><br><br>Common commands include:<br><b>abrt-cli</b> <b>list</b> <i>[--raw | --xml]</i><br><b>abrt-cli</b> <b>info</b> <i>&lt;problem_id&gt;</i><br><b>abrt-cli</b> <b>report</b> <i>&lt;problem_id&gt;</i><br><b>abrt-cli</b> <b>remove</b> <i>&lt;problem_id&gt;</i><br><b>abrt-cli</b> <b>auto-report</b> <i>[on|off]</i><br><b>abrt-cli</b> <b>status</b>


title: PARAMETERS
content:
<b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display verbose debug output, useful for troubleshooting ABRT itself.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed output than default, providing additional context for actions.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output, showing only errors or critical messages.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message for the command or subcommand and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information of the <b>abrt-cli</b> program and exit.<br><br>


title: DESCRIPTION
content:
<b>abrt-cli</b> is the command-line interface for the <i>Automatic Bug Reporting Tool</i> (ABRT) daemon. It allows users to interact with ABRT to manage detected problems such as application crashes, kernel oopses, and other software defects.<br><br>Users can list all collected problems, view detailed information about a specific problem, manually report a problem to a bug tracking system (e.g., Bugzilla), remove problems from the ABRT spool directory, or configure automatic reporting behavior. It provides a non-graphical way to control ABRT's functionality, making it suitable for server environments or scripting.


title: CAVEATS
content:
Requires the <i>ABRT daemon</i> (<b>abrtd</b>) to be running in the background to detect and manage problems.<br>Permissions: Users often need to be part of the 'abrt' group or use <b>sudo</b> to perform certain actions (e.g., removing problems, reporting kernel oopses or system-wide issues).<br>Problem data, especially core dumps, can consume significant disk space over time if not regularly cleaned up.<br>Reporting problems to external bug trackers requires internet connectivity and correctly configured reporting plugins.


title: PROBLEM TYPES
content:
ABRT is designed to detect and categorize various types of software problems, including <b>C/C++ crashes</b>, <b>Python crashes</b>, <b>kernel oopses</b>, and <b>kernel warnings</b>. Each detected problem is stored in a unique directory containing relevant diagnostic files such as core dumps, backtraces, log messages, and environment information, which are crucial for debugging.


title: ABRT PLUGINS
content:
ABRT's modular architecture relies heavily on plugins to extend its functionality. <i>Analysis plugins</i> process and categorize problem data, while <i>reporting plugins</i> handle the transmission of bug reports to specific destinations like Bugzilla, Red Hat Customer Portal, or custom bug trackers. This plugin system makes ABRT highly extensible and adaptable to different reporting workflows.


title: AUTOMATIC REPORTING
content:
A significant feature of ABRT is its ability to automatically report detected problems. While <b>abrt-cli</b> allows manual reporting, it also provides controls to enable or disable automatic reporting. This feature is particularly useful for unattended servers, ensuring that critical issues are reported without manual intervention, subject to configured filters and rate limits to prevent spamming bug trackers.


title: HISTORY
content:
ABRT (Automatic Bug Reporting Tool) was primarily developed by Red Hat for its Fedora and Red Hat Enterprise Linux distributions. Its inception aimed to simplify the process of detecting, collecting, and reporting software problems, making it easier for users to contribute valuable bug reports to developers. <b>abrt-cli</b> emerged as the robust command-line interface to this system, catering to server environments and automation needs. It has been a standard component of these distributions for many years, continuously evolving to support various problem types and integrate with diverse reporting backends.


title: PARAMETERS
content:
<b><b>-t</b> <i>&lt;target&gt;</i>, <b>--target</b> <i>&lt;target&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target IP address or hostname to audit.<br><br><b><b>-p</b> <i>&lt;protocol&gt;</i>, <b>--protocol</b> <i>&lt;protocol&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the network protocol to test (e.g., <i>ftp</i>, <i>ssh</i>, <i>telnet</i>, <i>smb</i>).<br><br><b><b>-U</b> <i>&lt;userlist&gt;</i>, <b>--userlist</b> <i>&lt;userlist&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of usernames to test.<br><br><b><b>-P</b> <i>&lt;passlist&gt;</i>, <b>--passlist</b> <i>&lt;passlist&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of passwords to test.<br><br><b><b>-u</b> <i>&lt;username&gt;</i>, <b>--username</b> <i>&lt;username&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a single username to test.<br><br><b><b>-D</b>, <b>--defaults</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the tool's built-in default username and password lists.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during the operation.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and exits.<br><br>


title: DESCRIPTION
content:
<i>acccheck</i> is a Python-based utility predominantly employed by security professionals and penetration testers to audit and brute-force user accounts across various network services. Unlike standard Linux commands, it's a standalone script designed to identify weak or default credentials by attempting a large number of username and password combinations against a target.<br><br>It supports multiple protocols such as FTP, SSH, Telnet, and often comes bundled with common default credential lists for efficiency. The tool automates the laborious process of trying potential logins, making it a valuable asset for vulnerability assessment. However, its use requires explicit authorization, as unauthorized attempts can have severe legal consequences and trigger security defenses.


title: CAVEATS
content:
<i>acccheck</i> is not a standard Linux command; it's a third-party security tool. Its use is subject to ethical guidelines and legal restrictions. Unauthorized access attempts or brute-forcing against systems without explicit permission is illegal and can lead to severe penalties. It can also generate significant network noise, potentially triggering intrusion detection/prevention systems.


title: ETHICAL USE
content:
Always ensure you have explicit written permission from the system owner before using <i>acccheck</i> or similar tools against any target. Use it only for legitimate security assessments and penetration testing within an authorized scope.


title: INSTALLATION & AVAILABILITY
content:
<i>acccheck</i> is usually distributed as a Python script. It can be obtained by cloning its repository from GitHub or by installing it via package managers on specialized security distributions. It requires a Python interpreter to run.


title: HISTORY
content:
The <i>acccheck</i> tool is typically a community-developed, open-source project often found on platforms like GitHub or bundled with penetration testing distributions (e.g., Kali Linux). It emerged from the need for a simple, specialized tool to test for common default credentials, complementing more complex or broader-scope brute-forcing tools. Its development is not tied to a specific Linux distribution's core utilities but rather to the cybersecurity community's efforts to provide effective auditing tools.


title: DESCRIPTION
content:
The command <b><code>accessdb</code></b> is not a widely recognized or standard utility found in most mainstream Linux distributions (e.g., Ubuntu, Debian, Fedora, CentOS, Arch Linux). Users often encounter Microsoft Access databases (<code>.mdb</code> or <code>.accdb</code> files) and seek tools to interact with them on Linux. Common approaches for Access files involve using <I><code>mdbtools</code></I> for older <code>.mdb</code> files, or leveraging ODBC drivers for broader database connectivity. For general database operations on Linux, commands like <I><code>sqlite3</code></I> (for SQLite databases), <I><code>psql</code></I> (for PostgreSQL), or <I><code>mysql</code></I>/<I><code>mariadb</code></I> (for MySQL/MariaDB) are typically used.<br><br>If you encountered <code>accessdb</code>, it might be a custom script, an alias, or a utility provided by a specific third-party application you have installed. It does not refer to a generic, built-in command for accessing various database types across Linux systems.


title: CAVEATS
content:
This command is not part of standard Linux distributions. Its existence on a system indicates it's likely a custom script, an alias, or a utility included with specific third-party software. Therefore, its behavior, syntax, and options are entirely dependent on its implementation.


title: HOW TO CHECK FOR A CUSTOM `ACCESSDB` COMMAND
content:
If you are looking for a command named <b><code>accessdb</code></b> on your system, it might be a user-defined script or an executable installed as part of a specific software package. You can try running <I><code>type accessdb</code></I> or <I><code>which accessdb</code></I> in your terminal to see if it's found in your PATH or if it's an alias. Alternatively, you might search for it within common installation directories like <I><code>/usr/local/bin</code></I> or within application-specific directories under <I><code>/opt/</code></I>.


title: HISTORY
content:
N/A - As <b><code>accessdb</code></b> is not a standard Linux command, it does not have a documented history within the official Linux command-line utilities. Any usage or development history would be specific to custom implementations or proprietary software packages that might include a utility with this name.


title: PARAMETERS
content:
<b><i>-i</i>, <i>--ignore-case</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores case distinctions in the <i>PATTERN</i>.<br><br><b><i>-v</i>, <i>--invert-match</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects non-matching lines; prints lines that do <b>not</b> contain the <i>PATTERN</i>.<br><br><b><i>-w</i>, <i>--word-regexp</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects only those lines containing matches that form whole words.<br><br><b><i>-l</i>, <i>--files-with-matches</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output; instead, prints the name of each input file from which output would normally have been printed.<br><br><b><i>-c</i>, <i>--count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses normal output; instead, prints a count of matching lines for each input file.<br><br><b><i>-H</i>, <i>--no-filename</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the prefixing of filenames on output.<br><br><b><i>--type=<TYPE></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches only files of the specified type (e.g., <i>--type=perl</i>, <i>--type=html</i>). Use <i>--show-types</i> to list available types.<br><br><b><i>--no-type=<TYPE></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files of the specified type from the search.<br><br><b><i>--ignore-dir=<DIR></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the specified directory from the search. Can be used multiple times.<br><br><b><i>--no-recurse</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not recurse into subdirectories. Searches only files in the current directory or explicitly specified files.<br><br><b><i>--pager=<PAGER></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends output through a specified pager program, e.g., <i>less -R</i>. Defaults to <i>less -R</i> if <i>ACK_PAGER</i> or <i>PAGER</i> environment variables are set.<br><br><b><i>--sort-files</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts the files by name before searching. Useful for consistent output.<br><br>


title: DESCRIPTION
content:
<i>ack</i> is a command-line tool designed specifically for developers to quickly search plain text files, particularly source code. While similar to <i>grep</i>, <i>ack</i> distinguishes itself by having sensible defaults tailored for programming projects.<br><br>By default, <i>ack</i> recursively searches directories, ignores common version control directories (like <i>.git</i>, <i>.svn</i>, <i>.hg</i>), and automatically skips binary files, backup files, and other non-source code files. It also intelligently determines file types based on extensions and shebang lines, allowing users to search only specific code types (e.g., <i>--type=perl</i> or <i>--type=java</i>).<br><br><i>ack</i>'s output is often more readable than <i>grep</i>'s, grouping matches by file and providing syntax highlighting. Its primary goal is to make common code search tasks faster and more convenient, reducing the need for complex command-line arguments often required with <i>grep</i> for similar functionality. It's written in Perl and highly extensible.


title: CAVEATS
content:
<i>ack</i> requires Perl to be installed on the system, as it's written in Perl. On some Linux distributions (e.g., Debian/Ubuntu), the command might be installed as <i>ack-grep</i> to avoid conflicts with a different utility named <i>ack</i> (the 'Analyse Control K' command). While generally faster for code searches due to its intelligent filtering, for extremely large non-code text files or very simple searches, <i>grep</i> or tools like <i>ripgrep</i> might offer better performance.


title: DEFAULT BEHAVIOR
content:
<i>ack</i>'s default behavior is to recursively search the current directory for files, automatically ignoring common version control system directories (like <i>.git</i>, <i>.svn</i>, <i>.hg</i>), common build directories, and common temporary/backup files. It also attempts to identify file types and only search relevant files.


title: FILE TYPE FILTERING
content:
<i>ack</i> maintains an internal list of file types and their associated file extensions or shebang lines. This allows users to narrow searches to specific languages (e.g., <i>--type=python</i>) or exclude them (<i>--no-type=xml</i>). Users can also define custom file types in their <i>.ackrc</i> file.


title: CUSTOMIZATION WITH .ACKRC
content:
<i>ack</i> can be extensively customized using a configuration file, typically named <i>.ackrc</i>, located in the user's home directory. This file allows users to set default options, define custom file types, and manage ignored directories, making <i>ack</i> behave exactly as preferred for their projects.


title: HISTORY
content:
<i>ack</i> was created by Andy Lester and first publicly released in 2007. Its development was motivated by the desire to provide a more developer-friendly and intelligent search tool than <i>grep</i> for common programming tasks. It quickly gained popularity within the Perl and broader open-source communities for its sensible defaults and ease of use. <i>ack</i>'s success and design choices have influenced the development of subsequent code search tools, such as the highly performant <i>ripgrep</i> (<i>rg</i>).


title: SYNOPSIS
content:
<b>acm</b> [<i>OPTIONS</i>] [<i>COMMAND_FILE</i>]<br>Where <i>COMMAND_FILE</i> is an optional input file containing commands or AML code to process for execution or analysis.


title: PARAMETERS
content:
<b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits, showing available command-line options.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>acm</i> utility and exits.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output or dumps parsed ACPI objects, depending on the context.<br><br><b>-f <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects all standard output from <i>acm</i> to the specified <i>file</i>.<br><br><b>-l <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug output <i>level</i> (e.g., 0-5), controlling the verbosity of messages during operation.<br><br><b>-e <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes commands or AML code from the specified input <i>file</i> as a batch process.<br><br><b>-p <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses an ACPI table (e.g., DSDT, SSDT) from the specified binary <i>file</i>.<br><br>


title: DESCRIPTION
content:
<i>acm</i>, or the <b>ACPI Machine</b>, is a specialized utility included in the ACPI Component Architecture (ACPI CA) tools suite. It serves as an interpreter and debugger for <b>ACPI Machine Language (AML)</b>, which is the bytecode used within ACPI tables. Unlike common user-facing utilities, <i>acm</i> is primarily designed for developers, system integrators, and advanced users who need to analyze, debug, or validate ACPI implementations.<br><br>It allows for processing of ACPI data tables, executing AML code, and tracing ACPI operations, making it crucial for low-level system debugging related to power management and hardware configuration. Its typical use involves processing input files containing AML code or ACPI data structures for testing and validation purposes.


title: CAVEATS
content:
<b>acm</b> is not a standard, widely installed user command on most Linux distributions. It is primarily an internal-use tool for ACPI development, debugging, and validation, requiring installation of the <i>acpica-tools</i> package. Its functionality is highly specialized and complex, intended for advanced users and developers working directly with ACPI specifications and low-level system interactions.


title: PRIMARY PURPOSE
content:
The primary purpose of <i>acm</i> is to facilitate the development and validation of ACPI implementations and firmware, rather than general system administration or everyday user tasks. It allows for detailed inspection, execution, and debugging of ACPI Machine Language (AML) code.


title: INSTALLATION
content:
<i>acm</i> is typically not included in minimal or standard Linux installations. To use it, you usually need to install the <i>acpica-tools</i> or a similar development package, which might vary in name depending on your Linux distribution (e.g., 'acpica-tools' on Debian/Ubuntu, 'acpica' on Fedora).


title: HISTORY
content:
<b>acm</b> is an integral part of the ACPI Component Architecture (ACPI CA) tools suite, developed by Intel. The ACPI CA provides an OS-independent reference implementation of the ACPI specification. The <i>acm</i> utility, along with other ACPI CA tools, has been crucial since the inception of ACPI for the development, testing, and validation of ACPI implementations across various operating systems, supporting proper power management and hardware configuration standards.


title: SYNOPSIS
content:
acme.sh <i>[command] [options]</i><br>acme.sh <b>--issue</b> <i>[domain_options] [validation_method] [other_options]</i><br>acme.sh <b>--renew</b> <i>[-d domain] [other_options]</i><br>acme.sh <b>--install-cert</b> <i>[-d domain]</i> <b>--key-file</b> <i>path</i> <b>--fullchain-file</b> <i>path</i> <i>[--reloadcmd service_cmd]</i><br>acme.sh <b>--uninstall</b> <i>[-d domain]</i><br>acme.sh <b>--cron</b>


title: PARAMETERS
content:
<b><b>--issue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Issue a new certificate.</i><br><br><b><b>-d</b>, <b>--domain</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify domain name(s). Can be used multiple times for SAN certificates.</i><br><br><b><b>--dns</b> <i>dns_api_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use DNS-01 validation. Specify the DNS provider API (e.g., `dns_cf` for Cloudflare).</i><br><br><b><b>--webroot</b> <i>/path/to/webroot</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use HTTP-01 validation with a webroot directory.</i><br><br><b><b>--standalone</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use HTTP-01 validation by spinning up a temporary standalone web server on port 80/443.</i><br><br><b><b>--renew</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Renew a certificate. This command is automatically run by the cron job.</i><br><br><b><b>--install-cert</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install certificate files to a specified location for use by services like web servers.</i><br><br><b><b>--install-ssl</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>An alias for <b>--install-cert</b>, provided for compatibility.</i><br><br><b><b>--reloadcmd</b> <i>"service_cmd"</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Command to execute after certificate installation/renewal (e.g., `systemctl reload nginx`).</i><br><br><b><b>--uninstall</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uninstall a certificate and remove its configuration from acme.sh.</i><br><br><b><b>--home</b> <i>/path/to/acme.sh</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the `acme.sh` working directory (default: `~/.acme.sh`).</i><br><br><b><b>--cert-home</b> <i>/path/to/certs</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the directory where certificates are stored (default: `~/.acme.sh/`).</i><br><br><b><b>--server</b> <i>ca_url</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an ACME server URL (e.g., staging server, custom CA).</i><br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force renewal or issuance, even if the certificate is not due. Use with caution.</i><br><br><b><b>--cron</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Run the daily cron job for certificate renewal checks. This is typically automated.</i><br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable debug output for troubleshooting.</i><br><br><b><b>--log-level</b> <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the log level (e.g., `1` for info, `2` for debug).</i><br><br><b><b>--upgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Upgrade `acme.sh` to the latest version from its git repository.</i><br><br><b><b>--set-default-dns</b> <i>dns_api_name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set a default DNS API to be used for future certificate issues, avoiding repeated `--dns` options.</i><br><br>


title: DESCRIPTION
content:
acme.sh is a pure Unix shell script that automates the process of issuing and renewing SSL/TLS certificates from ACME providers like Let's Encrypt. It's designed to be lightweight and simple, requiring no external dependencies beyond a standard Unix environment (curl, grep, sed, openssl, awk).<br><br>It supports various domain validation methods, including <b>HTTP-01</b> (webroot, standalone server) and <b>DNS-01</b>. For DNS-01, it offers extensive support for numerous DNS providers through their APIs, allowing fully automated wildcard certificate issuance and renewal.<br><br>Its primary purpose is to simplify certificate management for web servers, mail servers, and other services, providing an easy way to keep certificates up-to-date with automatic renewal capabilities integrated into a cron job.


title: CAVEATS
content:
acme.sh requires root or sudo privileges for certain operations like binding to port 80/443 for <b>standalone</b> mode, or installing certificates to system-protected directories (e.g., `/etc/nginx/ssl`). When using <b>DNS-01</b> validation, ensure the necessary API keys/tokens are correctly set as environment variables as per the documentation for your specific DNS provider. Be mindful of Let's Encrypt rate limits, especially during testing; use the <b>staging</b> server (`--server https://acme-staging-v02.api.letsencrypt.org/directory`) for testing to avoid hitting production limits. As a shell script, its execution speed might be slightly slower than compiled clients, but this is negligible for certificate management tasks.


title: COMMON USAGE: ISSUING A CERTIFICATE WITH DNS-01 VALIDATION
content:
To issue a wildcard certificate using DNS-01 validation (e.g., with Cloudflare DNS):<br><br>First, set up your DNS API credentials (replace with your actual API key/token and email):<br><i>`export CF_Key="sdfsdfsdfljlbjkljkljlkjlkjsdfs"`</i><br><i>`export CF_Email="xxxx@gmail.com"`</i><br><br>Then, issue the certificate:<br><i>`acme.sh --issue -d example.com -d *.example.com --dns dns_cf`</i><br><br>After issuance, configure your web server (e.g., Nginx) to use the generated certificates. `acme.sh` provides the <b>--install-cert</b> command to copy the certificates to a desired location and reload the service.


title: COMMON USAGE: INSTALLING AND RENEWING CERTIFICATES
content:
Once a certificate is issued, `acme.sh` stores it in its own directory (typically `~/.acme.sh/example.com/`). For web servers, you typically install them to a more conventional location:<br><br><i>`acme.sh --install-cert -d example.com \`<br>`  --key-file /etc/nginx/ssl/example.com.key \`<br>`  --fullchain-file /etc/nginx/ssl/example.com_fullchain.cer \`<br>`  --reloadcmd "systemctl reload nginx"`</i><br><br>`acme.sh` automatically creates a cron job (or adds to an existing one) to run the <b>--cron</b> command twice a day. This command checks for certificates due for renewal and executes the <b>--install-cert</b> command again if renewal is successful, ensuring your certificates are always up-to-date without manual intervention.


title: HISTORY
content:
acme.sh emerged as a lightweight, pure shell script alternative to more complex ACME clients like `certbot`. Its design philosophy prioritizes simplicity and minimal dependencies, making it suitable for a wide range of Unix-like systems, including embedded devices or environments where Python or other language runtimes might not be readily available or desired. It quickly gained popularity for its extensive support for DNS API integrations, enabling fully automated wildcard certificate management well before `certbot` offered similar robust support. It has continuously evolved to support new ACME features and protocols, including ACME v2 and external account binding, maintaining its status as a highly capable and versatile ACME client.


title: SEE ALSO
content:
certbot(1): <i>Another popular ACME client, typically Python-based.</i>, openssl(1): <i>Cryptographic toolkit used by acme.sh for key generation and certificate operations.</i>, curl(1): <i>Used for communication with ACME servers and DNS APIs.</i>, nginx(8): <i>Common web server often configured with certificates issued by acme.sh.</i>, apache2(8): <i>Another common web server.</i>, cron(8): <i>Used to schedule automatic certificate renewals by acme.sh.</i>


title: SYNOPSIS
content:
<b>aconnect</b> [<i>OPTIONS</i>] [<i>SENDER_CLIENT:PORT</i>] [<i>RECEIVER_CLIENT:PORT</i>]<br><b>aconnect -l</b><br><b>aconnect -i</b><br><b>aconnect -o</b><br><b>aconnect -d</b> <i>SENDER_CLIENT:PORT</i> <i>RECEIVER_CLIENT:PORT</i><br><b>aconnect -x</b>


title: PARAMETERS
content:
<b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all active ALSA sequencer connections.<br><br><b><b>-i</b>, <b>--input</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only ALSA sequencer input ports available.<br><br><b><b>-o</b>, <b>--output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only ALSA sequencer output ports available.<br><br><b><b>-d</b>, <b>--disconnect</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disconnects the specified <i>SENDER_CLIENT:PORT</i> from <i>RECEIVER_CLIENT:PORT</i>.<br><br><b><b>-x</b>, <b>--disconnect-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disconnects all active ALSA sequencer connections.<br><br><b><b>-r</b>, <b>--real-time</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to use real-time scheduling for connection setup (may require elevated privileges).<br><br><b><b>-s</b>, <b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows system ports (e.g., 'Midi Through').<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses non-error messages.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints more detailed information about ports and connections.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><i>SENDER_CLIENT:PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The source ALSA sequencer port, specified as <i>client_id:port_id</i> or <i>"client_name":"port_name"</i>.<br><br><b><i>RECEIVER_CLIENT:PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The destination ALSA sequencer port, specified as <i>client_id:port_id</i> or <i>"client_name":"port_name"</i>.<br><br>


title: DESCRIPTION
content:
<i>aconnect</i> is a command-line utility used to manage connections between ALSA (Advanced Linux Sound Architecture) sequencer ports. It serves as a crucial tool for configuring MIDI routing within Linux, enabling communication between various MIDI applications and hardware devices. For instance, you can connect a physical MIDI keyboard's output to a software synthesizer's input, or route MIDI data between different software applications. The command can list available input and output ports, display existing connections, and dynamically establish new connections or tear down old ones. This flexibility makes it indispensable for creating complex MIDI setups. Part of the <i>alsa-utils</i> package, <i>aconnect</i> provides a simple yet powerful interface to the ALSA sequencer API, allowing users to fully control their MIDI signal flow without needing a graphical frontend. It's often used in scripting for automated MIDI environment setup.


title: CAVEATS
content:
Connections made with <i>aconnect</i> are <b>not persistent</b> across system reboots or ALSA driver reloads; they must be re-established. Port client and ID numbers can sometimes change upon reboot or device reconnection, making automated scripting challenging. Using port names (e.g., <i>"Midi Through" "Midi Through Port-0"</i>) instead of numeric IDs can offer more stability but requires careful handling of spaces and quotes. The <b>-r</b> (real-time) option may require root privileges or specific user capabilities to function correctly.


title: <B><I>PORT IDENTIFICATION AND NAMING</I></B>
content:
ALSA sequencer ports can be identified by their numeric <i>client_id:port_id</i> (e.g., <i>129:0</i>) or by a descriptive name (e.g., <i>"FLUIDSYNTH" "FluidSynth synth"</i>). When using names containing spaces, they must be enclosed in double quotes. Using names is generally more robust for scripts as client/port IDs can occasionally change across system reboots or hardware reconfigurations.


title: <B><I>AUTOMATING CONNECTIONS</I></B>
content:
To ensure MIDI connections are automatically established when the system starts, users can create shell scripts containing <i>aconnect</i> commands. These scripts can then be executed via <i>systemd</i> user units, global <i>systemd</i> services, or traditional init scripts. This allows for a consistent MIDI environment without manual intervention after each reboot.


title: HISTORY
content:
<i>aconnect</i> is an integral part of the <i>alsa-utils</i> package, which developed alongside the ALSA (Advanced Linux Sound Architecture) project. ALSA emerged in the late 1990s as a successor to OSS (Open Sound System) to provide more robust and modern audio capabilities for Linux. The ALSA sequencer, which <i>aconnect</i> manages, was designed to handle MIDI events and routing effectively. Since its inception, <i>aconnect</i> has remained a fundamental command-line tool for Linux users and developers needing precise control over MIDI connections, especially in server environments or scripted setups where graphical tools are not available or desired. Its role has been consistently important in the Linux audio ecosystem.


title: PARAMETERS
content:
<b><b>-b</b>, <b>--battery</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only battery information. This includes current charge, remaining capacity, and charging/discharging status.<br><br><b><b>-a</b>, <b>--ac-adapter</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only AC adapter information, indicating if the system is running on AC power.<br><br><b><b>-t</b>, <b>--thermal</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only thermal information, such as temperatures of various sensors or thermal zones.<br><br><b><b>-c</b>, <b>--cooling</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only cooling device information, including fan status or processor cooling states.<br><br><b><b>-V</b>, <b>--everything</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all available ACPI information (battery, AC adapter, thermal, and cooling). This is often the default behavior if no specific option is given.<br><br><b><b>-s</b>, <b>--show-symbols</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display power symbols (e.g., '+', '-', '=') next to battery percentages to indicate charging, discharging, or full status.<br><br><b><b>-i</b>, <b>--show-empty-items</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show items even if no information is available for them (e.g., a thermal zone with no reported temperature).<br><br><b><b>-f</b>, <b>--fahrenheit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show temperatures in Fahrenheit instead of the default Celsius.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>acpi</b> command provides a straightforward way to query and display information related to the <i>Advanced Configuration and Power Interface (ACPI)</i> on a Linux system. It is commonly used by users to check the status of their laptop battery, whether the AC adapter is plugged in, and to monitor thermal zones or cooling devices. The command reads information exposed by the kernel, typically through filesystems like <I>/proc/acpi</I> (on older systems) or <I>/sys/class/power_supply</I> and <I>/sys/class/thermal</I> (on modern kernels).<br><br>It is particularly useful for scripting power-related actions, such as dimming the screen on battery power, or for quickly checking the remaining battery life and charge status without needing a full graphical user interface. By default, when invoked without options, it displays comprehensive power information including battery status, AC adapter presence, and thermal data.


title: CAVEATS
content:
The <b>acpi</b> command relies heavily on the underlying Linux kernel's ACPI support and the information exposed by the system's hardware. If ACPI is not properly configured or if the hardware doesn't expose certain details (e.g., specific thermal sensors), <b>acpi</b> might show incomplete or no data.<br><br>While <b>acpi</b> can display status, it is not designed for handling ACPI events (like lid close or power button press). For such reactive power management, the <b>acpid</b> daemon is typically used in conjunction with custom scripts.


title: DATA SOURCES
content:
The <b>acpi</b> command primarily reads data from the Linux kernel's exposed ACPI interfaces. On older systems, this information was often found in the <I>/proc/acpi/</I> filesystem. On modern kernels, it typically queries information from <I>/sys/class/power_supply/</I> for battery and AC adapter status, and <I>/sys/class/hwmon/</I> or <I>/sys/class/thermal/</I> for thermal data. This approach allows it to provide real-time power and thermal status without requiring root privileges for basic queries.


title: HISTORY
content:
The <b>acpi</b> command emerged as a simple utility to interface with the <i>ACPI (Advanced Configuration and Power Interface)</i> power management system on Linux. Its development paralleled the increasing adoption of ACPI in PC hardware and the Linux kernel's growing support for it. It provided a user-friendly command-line interface to status information primarily found in the <I>/proc/acpi</I> filesystem, and later <I>/sys/class/power_supply</I> and <I>/sys/class/thermal</I>. It largely superseded tools that interfaced with the older <i>APM (Advanced Power Management)</i> specification, becoming a standard utility in many Linux distributions due to its simplicity and directness in querying power status.


title: DESCRIPTION
content:
<i>acpi_listen</i> is a utility designed to monitor and display ACPI (Advanced Configuration and Power Interface) events as they occur on a Linux system. It typically listens on the ACPI daemon's socket (commonly <i>/var/run/acpid.socket</i>) for events generated by hardware actions. These events include, but are not limited to, power button presses, laptop lid closures or openings, battery status changes (e.g., AC adapter plug/unplug), and docking/undocking events. <br><br>The primary purpose of <i>acpi_listen</i> is for debugging and diagnostics, allowing system administrators and developers to observe exactly what ACPI events the operating system is receiving. This is crucial for configuring the <i>acpid</i> daemon's event handling scripts correctly or for troubleshooting issues related to power management and hardware interaction. It outputs event details to standard output, making it easy to see the event type, device, and relevant codes.


title: CAVEATS
content:
<ul><li><i>acpi_listen</i> typically requires the <i>acpid</i> (ACPI daemon) service to be running on the system to receive events. It acts as a client to <i>acpid</i>, listening on its communication socket. If <i>acpid</i> is not active, <i>acpi_listen</i> may not display any events.</li><li>The output from <i>acpi_listen</i> consists of raw ACPI event data, which might require some understanding of ACPI event types and codes to interpret fully. It is primarily a debugging tool, not intended for direct scripting of system actions without further processing.</li></ul>


title: USAGE EXAMPLE
content:
To observe ACPI events, simply open a terminal and execute the command:<br><i>acpi_listen</i><br>Then, perform an action like closing or opening your laptop lid, pressing the power button, or plugging/unplugging your AC adapter. You will see output similar to these examples:<br><i>button/lid LID open</i><br><i>button/power PWRF 00000080 00000000</i><br><i>ac_adapter ACAD 00000080 00000000</i> (for AC adapter plugged in)


title: INTERACTION WITH ACPID
content:
While <i>acpi_listen</i> shows ACPI events, it's important to understand its relationship with the <i>acpid</i> daemon. The Linux kernel handles raw ACPI events. <i>acpid</i> reads these raw events, parses them, and then dispatches them to various clients, including <i>acpi_listen</i>, via a Unix domain socket. Therefore, <i>acpi_listen</i> is observing the processed events from <i>acpid</i>, not directly from the kernel's ACPI event queue.


title: HISTORY
content:
<i>acpi_listen</i> has been an integral part of the <i>acpi</i> utilities package for Linux since the widespread adoption of ACPI as the standard for power management on modern computers, succeeding the older APM (Advanced Power Management) specification. It was developed to provide a crucial diagnostic tool for debugging and configuring how Linux systems react to hardware-generated ACPI events, supporting the transition to more sophisticated power management schemes.


title: PARAMETERS
content:
<b><b>-c</b>, <b>--config-dir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory for ACPI event configuration files.<br><br><b><b>-e</b>, <b>--event-file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Deprecated)</i> Read events from a specific file (e.g., <i>/proc/acpi/event</i>).<br><br><b><b>-g</b>, <b>--socket-group</b> <i>&lt;group&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the group ownership for the ACPI event socket.<br><br><b><b>-l</b>, <b>--log-file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Direct logging output to a specified file.<br><br><b><b>-n</b>, <b>--netlink</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the use of the <i>netlink</i> interface for event listening.<br><br><b><b>-s</b>, <b>--socket</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the UNIX domain socket.<br><br><b><b>-S</b>, <b>--stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send a stop signal to a running <i>acpid</i> instance.<br><br><b><b>-D</b>, <b>--no-daemon</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not fork into the background; run in the foreground.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>acpid</i>, the Advanced Configuration and Power Interface event daemon, is a critical component for power management and hardware event handling on Linux systems. Its primary function is to monitor various ACPI events originating from the kernel, such as power button presses, lid closures, battery status changes, or thermal alerts. Upon detecting an event, <i>acpid</i> consults its configuration files, typically located in <i>/etc/acpi/events/</i>, to identify a matching rule. Once a rule is matched, it executes a corresponding script, often <i>/etc/acpi/handler.sh</i>, to perform the desired action (e.g., suspend, hibernate, or log off).<br><br>Historically, <i>acpid</i> read events from <i>/proc/acpi/event</i>, but modern implementations leverage the <i>netlink</i> socket interface for more efficient and robust communication with the kernel. This daemon provides a flexible and customizable framework for system administrators and users to define how their Linux system reacts to physical hardware events, ensuring proper power management and a responsive user experience.


title: CAVEATS
content:
<i>acpid</i> requires kernel ACPI support to function. Its effectiveness heavily depends on the correct configuration of event rules and handler scripts in <i>/etc/acpi/</i>. Misconfigured scripts can lead to unintended power actions or system instability. While <i>acpid</i> handles many hardware events, modern desktop environments and <i>systemd-logind</i> may handle certain common events (like lid closure or power button) natively, potentially overriding or working in conjunction with <i>acpid</i>'s configurations.


title: CONFIGURATION FILES AND EVENT HANDLING
content:
<i>acpid</i>'s behavior is primarily defined by two types of files within the <i>/etc/acpi/</i> directory:<br><b>Event Configuration Files:</b> Found in <i>/etc/acpi/events/</i>, these files contain regular expressions that <i>acpid</i> uses to match incoming ACPI event strings. Each file typically specifies a single event pattern and the action (a script) to execute when that pattern is matched.<br><b>Event Handler Script:</b> The central handler is often <i>/etc/acpi/handler.sh</i>, which receives the detected event as arguments and dispatches to specific functions or scripts based on the event type (e.g., button/power, button/lid, ac_adapter, battery, thermal). This script provides the logic for how the system reacts to the matched events.


title: HISTORY
content:
<i>acpid</i> emerged as the standard daemon for handling Advanced Configuration and Power Interface (ACPI) events in Linux, effectively replacing the older Advanced Power Management (APM) system. Its initial implementations primarily relied on polling the <i>/proc/acpi/event</i> file provided by the kernel to receive event notifications. Over time, as Linux kernel development progressed, <i>acpid</i> transitioned to utilizing the more efficient and robust <i>netlink</i> socket interface for event communication, which is the default method on modern systems. While its core function remains consistent, its integration with the broader Linux ecosystem, particularly with the advent of <i>systemd</i> and <i>systemd-logind</i>, has seen some responsibilities for basic power actions shift, though <i>acpid</i> remains crucial for custom or complex ACPI event handling.


title: PARAMETERS
content:
<b>--workflows, -W &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the workflow file(s) or directory containing workflows.<br><br><b>--job, -j &lt;job_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run only a specific job from the workflow.<br><br><b>--event, -e &lt;event_type&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the GitHub event type to trigger the workflow with (e.g., <I>push</I>, <I>pull_request</I>).<br><br><b>--input, -i &lt;name=value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass an input to the workflow, typically used with <I>workflow_dispatch</I> events. Can be specified multiple times.<br><br><b>--secret, -s &lt;name=value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a secret to the workflow. Can be specified multiple times.<br><br><b>--secret-file, -sf &lt;file_path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing secrets (e.g., an .env file).<br><br><b>--env, -E &lt;name=value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set an environment variable for the workflow execution. Can be specified multiple times.<br><br><b>--container-architecture &lt;arch&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the architecture of the container to use (e.g., <I>linux/amd64</I>, <I>linux/arm64</I>).<br><br><b>--bind, -b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bind the current directory to the container, making it accessible inside the workflow.<br><br><b>--dryrun, -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run: parse and print the workflow without executing any actions.<br><br><b>--list, -l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available jobs within the specified workflow file(s).<br><br><b>--privileged</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run job containers in privileged mode, granting broader access to the host.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose logging to display more detailed information during execution.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output, showing only errors or critical messages.<br><br><b>--artifact-server-port &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the port for the local artifact server, used for uploading/downloading artifacts.<br><br><b>--artifact-server-path &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the directory where artifacts will be stored locally.<br><br><b>--rebuild</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a rebuild of Docker images before running the workflow.<br><br><b>--rm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove containers after the job completes, cleaning up resources.<br><br><b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br>


title: DESCRIPTION
content:
The <I>act</I> command, while not a standard core Linux utility, is a popular open-source tool that allows developers to run their <B>GitHub Actions</B> workflows directly on their local machine. It simulates the GitHub Actions environment by leveraging <B>Docker</B> containers to execute jobs and steps defined in your workflow files (typically located in <I>.github/workflows/</I>).<br><br>This capability significantly speeds up the development and debugging process for GitHub Actions workflows. Instead of pushing changes to a remote repository and waiting for GitHub's cloud runners, developers can test iterations almost instantly. <I>act</I> supports various GitHub events like <I>push</I>, <I>pull_request</I>, and <I>workflow_dispatch</I>, and can handle inputs, secrets, and environment variables, providing a comprehensive local testing environment. It's an indispensable tool for anyone building complex CI/CD pipelines with GitHub Actions.


title: CAVEATS
content:
<B>Docker Requirement:</B> <I>act</I> fundamentally relies on <B>Docker</B> to create and manage containers for workflow execution. Docker must be installed and running on the host system.<br><br><B>Environment Parity:</B> While <I>act</I> aims for high fidelity, it may not perfectly replicate all nuances of GitHub's cloud-hosted runners (e.g., pre-installed tools, specific runner configurations, network conditions).<br><br><B>Security Concerns:</B> Running untrusted workflows locally, especially with <I>--privileged</I> mode, can pose security risks. Always be cautious when executing code from external sources.<br><br><B>Resource Usage:</B> Local execution can consume significant CPU, memory, and disk resources, especially for large workflows or those involving heavy builds.


title: INSTALLATION
content:
<I>act</I> can be installed through various methods depending on your operating system. Common approaches include using package managers like Homebrew (macOS), Scoop (Windows), or downloading pre-compiled binaries directly from the project's GitHub releases page. Alternatively, it can be built from source using Go.


title: TYPICAL USAGE
content:
To use <I>act</I>, navigate to the root directory of your Git repository where your <I>.github/workflows</I> directory resides. You can then run <I>act</I> with specific options, for example, <I>act -j "build"</I> to run a job named 'build', or <I>act --event push</I> to simulate a push event triggering your workflow. It's often preceded by <I>git checkout</I> to ensure you are testing the desired branch or commit.


title: HISTORY
content:
<I>act</I> was developed by Nektos (a GitHub organization) as an open-source project to address the growing demand for local development and debugging of GitHub Actions workflows. It emerged as a crucial tool for developers to accelerate their CI/CD pipeline iteration cycles, eliminating the need to push changes to GitHub for every test run. Its development reflects the broader trend of shifting left in testing practices, bringing the execution environment closer to the developer's machine.


title: SEE ALSO
content:
docker(1): Underlying containerization technology used by <I>act</I>., git(1): Version control system commonly used with GitHub and GitHub Actions.


title: DESCRIPTION
content:
The command <i>'acyclic'</i> is <b>not a standard or commonly recognized utility</b> within the Linux operating system. It is highly probable that this is a typo, a custom script, or a reference to a specific tool not part of the core GNU/Linux distribution. Standard Linux environments do not ship with a command explicitly named 'acyclic' that performs a dedicated function related to acyclicity, such as detecting cycles in graphs or file systems via a single command.<br><br>While the concept of 'acyclic' is fundamental in computing (e.g., Directed Acyclic Graphs or DAGs in dependency management, or the tree-like structure of file systems), its operations are typically handled by more specialized tools or programming constructs. For instance, visualizing DAGs might involve Graphviz's <i>dot</i> command, and ensuring file system integrity (which implies acyclicity) is handled by tools like <i>fsck</i>.


title: CAVEATS
content:
This 'acyclic' command does not exist as a standard part of Linux distributions. Any references to it might be specific to a niche software package, a typo, or a custom user-defined alias/script. Attempting to execute 'acyclic' on a typical Linux system will result in a 'command not found' error.


title: ACYCLIC CONCEPTS IN LINUX
content:
While there's no direct 'acyclic' command, the concept of acyclicity is crucial in several Linux contexts:<br><i><b>File Systems:</b></i> The directory structure of a Unix/Linux file system is fundamentally an acyclic tree (a type of DAG). Although symbolic links can create traversal loops, they do not create true cycles in the underlying directory structure itself. Hard links can create cycles in inode references but typically not in the directory hierarchy.<br><i><b>Dependency Management:</b></i> Build systems (like <i>make</i>), package managers (like <i>apt</i> or <i>dnf</i>), and software pipelines often rely on Directed Acyclic Graphs (DAGs) to manage dependencies, ensuring that tasks are executed in the correct order without circular dependencies that would lead to infinite loops.<br><i><b>Graph Visualization:</b></i> Tools like <i>Graphviz</i> (especially the <i>dot</i> command) are used to visualize graphs, often with the intent of creating clean, acyclic layouts for representing dependencies or relationships.


title: SYNOPSIS
content:
<i><b>adb</b> [<I>global options</I>] <I>command</I> [<I>command options</I>] <I>arguments</I><br><br><b>Global Options:</b><br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-d</b>: Directs command to the only USB device connected.<br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-e</b>: Directs command to the only running emulator instance.<br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-s</b> <I>SERIAL</I>: Directs command to the device or emulator with the given serial number.<br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-t</b> <I>TRANSPORT_ID</I>: Directs command to the device with the given transport ID.<br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-P</b> <I>PORT</I>: Specifies the port number for the adb server.<br> &nbsp;&nbsp;&nbsp;&nbsp;<b>-H</b> <I>HOST</I>: Specifies the address of the adb server (default is localhost).</i>


title: PARAMETERS
content:
<b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs command to the only USB device connected.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs command to the only running emulator instance.<br><br><b><b>-s</b> <I>SERIAL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs command to the device or emulator with the given serial number.<br><br><b><b>-t</b> <I>TRANSPORT_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs command to the device with the given transport ID.<br><br><b><b>-P</b> <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number for the adb server (default 5037).<br><br><b><b>-H</b> <I>HOST</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the address of the adb server (default is localhost).<br><br><b><b>devices</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all connected devices and emulators.<br><br><b><b>install</b> <I>PATH_TO_APK</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an Android application package (APK) on the device. Common options include -r (reinstall) and -g (grant all permissions).<br><br><b><b>uninstall</b> <I>PACKAGE_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes an Android application from the device. Use -k to keep the data and cache directories.<br><br><b><b>push</b> <I>LOCAL</I> <I>REMOTE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies a file or directory from the host machine to the device.<br><br><b><b>pull</b> <I>REMOTE</I> <I>LOCAL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies a file or directory from the device to the host machine.<br><br><b><b>shell</b> [<I>command</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a remote shell on the device, or executes a single command on the device.<br><br><b><b>logcat</b> [<I>options</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays device log messages in real-time. Use -c to clear logs, -d to dump and exit, -s to filter by tag.<br><br><b><b>reboot</b> [<I>bootloader</I>|<I>recovery</I>|<I>sideload</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the device into the Android system, bootloader, recovery, or sideload mode.<br><br><b><b>connect</b> <I>HOST</I>[:<I>PORT</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a device via TCP/IP (usually after enabling wireless debugging).<br><br><b><b>disconnect</b> [<I>HOST</I>[:<I>PORT</I>]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disconnects from a specified TCP/IP device or all connected devices.<br><br><b><b>sideload</b> <I>OTA_UPDATE.zip</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the device in sideload mode to install an OTA update package from a zip file.<br><br>


title: DESCRIPTION
content:
<i><b>adb</b> (Android Debug Bridge) is a versatile command-line tool that lets you communicate with an Android-powered device. It's a client-server program that includes three components: a client, a daemon (adbd), and a server. The client runs on your development machine, the daemon runs as a background process on each connected device, and the server runs as a background process on your development machine to manage communication between the client and the daemon. <br><br>adb provides various functionalities crucial for Android app development and debugging. It enables you to install and uninstall applications, copy files to and from the device, access the device's shell (running commands directly on the Android system), view system logs (logcat), and control the device's state (e.g., reboot, boot into recovery). It's an essential tool for developers, testers, and power users alike, offering deep access and control over Android devices via USB or network connections.</i>


title: CAVEATS
content:
<i>Using <b>adb</b> requires USB debugging to be enabled on the Android device, which can pose a security risk if the device falls into unauthorized hands, as it allows deep system access. On Windows, proper USB drivers for the specific Android device are often necessary and can be a common source of connectivity issues. Misuse of powerful <b>adb</b> commands, especially those involving flashing partitions or modifying system files, can potentially lead to device bricking or instability if not performed correctly. Also, while <b>adb</b> supports network connections, initial setup often requires a USB connection.</i>


title: <B>ADB SERVER</B>
content:
The <b>adb</b> server runs as a background process on your development machine (usually on port 5037). It listens for <b>adb</b> client commands, then manages communication with the <b>adbd</b> daemon on connected Android devices. It's automatically started when you run an <b>adb</b> command and can be explicitly controlled with <b>adb start-server</b> and <b>adb kill-server</b>.


title: <B>USB DEBUGGING</B>
content:
For <b>adb</b> to communicate with an Android device via USB, 'USB debugging' must be enabled in the device's Developer options. This setting is typically hidden until you tap the 'Build number' seven times in the 'About phone' section of the device settings.


title: <B>WIRELESS ADB</B>
content:
While primarily known for USB connections, <b>adb</b> can also connect to devices over Wi-Fi. This usually requires an initial USB connection to configure the device for TCP/IP communication (e.g., <b>adb tcpip 5555</b>), after which the USB cable can be disconnected, and subsequent connections are made using <b>adb connect</b> <I>IP_ADDRESS</I>:<I>PORT</I>.


title: HISTORY
content:
<i><b>adb</b> has been an integral part of the Android SDK (Software Development Kit) since its early days, developed and maintained by Google. It was designed to provide developers with a robust tool to interact with Android devices for testing, debugging, and system access. Over the years, <b>adb</b> has seen continuous updates and improvements, adapting to new Android versions and device functionalities, ensuring compatibility and enhancing its capabilities for a wide range of debugging and development tasks. Its core functionality has remained consistent, making it a foundational tool in the Android ecosystem.</i>


title: PARAMETERS
content:
<b>host</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The IP address or hostname of the target Android device or emulator.<br><br><b>port</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The TCP port number on which the ADB daemon on the device is listening. The default and commonly used port for ADB is 5555.<br><br>


title: DESCRIPTION
content:
The `adb connect` command establishes a network connection from your development machine to an Android device or emulator over TCP/IP, enabling wireless debugging. This is particularly useful when a physical USB connection is inconvenient or impossible, for instance, when testing on multiple devices simultaneously or when the device is mounted in an inaccessible location. Before using `adb connect`, the target Android device must first be configured for TCP/IP debugging, typically by enabling Developer Options and then switching ADB from USB to TCP/IP mode using `adb tcpip <I>port</I>` (often 5555) while still connected via USB. Once connected, all standard `adb` commands (like `adb install`, `adb shell`, `adb logcat`) can be used wirelessly. The connection persists until explicitly disconnected with `adb disconnect` or until the device reboots.


title: CAVEATS
content:
The target Android device must have <I>Developer Options</I> enabled and <I>USB debugging</I> activated.<br>Before connecting via `adb connect`, the device's ADB daemon must be switched to TCP/IP mode, typically done via `adb tcpip <I>port</I>` while it's still connected via USB.<br>Both the development machine and the Android device must be on the same network and be able to communicate with each other (e.g., no firewall blocking the specified port).<br>The device's IP address might change if it's using DHCP, requiring reconnection.<br>Some devices or custom ROMs might have additional security measures or require specific settings to allow wireless ADB.


title: DISCONNECTING
content:
To disconnect from a wirelessly connected device, use `adb disconnect <I>host</I>:<I>port</I>` to disconnect from a specific device, or simply `adb disconnect` to disconnect from all active network connections.


title: DEFAULT PORT
content:
The standard port for ADB connections is 5555. If no port is specified in the `adb tcpip` command on the device, it defaults to 5555, which means `adb connect <I>host</I>:5555` is often the correct syntax.


title: USING WITH EMULATORS
content:
`adb connect` can also be used to connect to Android emulators running on the same machine or a remote machine, typically using `localhost` or the remote machine's IP, along with the emulator's specific ADB port (e.g., 5554, 5556, etc.).


title: HISTORY
content:
The Android Debug Bridge (ADB) has been a core component of the Android SDK since its early days, providing developers with a versatile tool for interacting with Android devices. The ability to connect via TCP/IP, including the `adb connect` command, was introduced early in ADB's development to facilitate wireless debugging, recognizing the convenience and flexibility it offers compared to a solely USB-based connection. This feature has remained largely consistent in its functionality and syntax, adapting to evolving Android versions and network environments while maintaining its foundational role in Android development workflows.


title: SYNOPSIS
content:
<b>adb</b> [<I>global_options</I>] <b>devices</b> [<I>-l</I>]<br><br><i>Explanation:</i><br><b>adb</b>: The main Android Debug Bridge executable.<br><b>devices</b>: The specific subcommand to list connected devices.<br><I>global_options</I>: Optional flags that apply to all adb commands (e.g., specifying a different ADB server host or port).<br><I>-l</I>: An optional parameter for a 'long format' listing.


title: PARAMETERS
content:
<b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a 'long format' listing, which includes additional details for each connected device such as the product name, model, and device identifier. This can be particularly useful when distinguishing between multiple similar devices.<br><br><b>[global_options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;While not specific to the 'devices' subcommand, <b>adb</b> supports various global options that can precede any command. Examples include <I>-H <host></I> to connect to a specific ADB server host, or <I>-P <port></I> to connect to a specific port. These options allow targeting different ADB server instances if needed.<br><br>


title: DESCRIPTION
content:
The <b>adb devices</b> command is a core utility within the Android Debug Bridge (ADB) framework. Its primary purpose is to display a list of all Android devices (physical phones, tablets, or emulators) currently connected to the host computer. These connections can be established via USB or, if configured, over a network (Wi-Fi).<br><br>Upon execution, if the ADB server is not already running, <b>adb devices</b> will automatically start it. The server then scans for and identifies connected devices. For each detected device, the command typically outputs a unique serial number and its current connection state (e.g., "device", "offline", or "unauthorized"). This command is essential for developers and power users as it serves as the initial verification step to ensure a device is properly recognized and ready for further ADB operations, such as installing applications, transferring files, or accessing the device's shell.


title: CAVEATS
content:
<b>USB Debugging Disabled:</b> Devices must have USB debugging enabled in their Developer Options for ADB to recognize them.<br><b>Unauthorized Device:</b> A device may appear as 'unauthorized' if you haven't accepted the RSA key fingerprint prompt on the device's screen upon its first connection.<br><b>Driver Issues:</b> On Windows, missing or outdated USB drivers are a common cause of devices not being detected.<br><b>ADB Server Conflict:</b> Sometimes the ADB server can crash or conflict with other instances. Running <I>adb kill-server</I> followed by <I>adb devices</I> often resolves such issues.<br><b>Firewall/Network:</b> For ADB over Wi-Fi, firewall settings on either the host or device can block the connection.<br><b>Faulty Cable/Port:</b> A damaged USB cable or a malfunctioning USB port can prevent proper device detection.


title: DEVICE STATES IN OUTPUT
content:
The output of <b>adb devices</b> typically shows the following states for a connected device:<br><b>device:</b> Indicates that the device is successfully connected to the ADB server and is ready to accept commands.<br><b>offline:</b> The device is connected, but it is not responding to ADB commands. This can happen during a device reboot, or if there's a problem with the connection that needs troubleshooting.<br><b>unauthorized:</b> The device is physically connected, but you have not yet granted permission for your computer to debug it. A prompt usually appears on the device's screen asking for authorization; you must accept this prompt to proceed.


title: TROUBLESHOOTING COMMON ISSUES
content:
If your device is not listed by <b>adb devices</b>:<br>1. Double-check your USB cable and try a different USB port.<br>2. Ensure that 'USB debugging' is enabled in the 'Developer Options' on your Android device.<br>3. Look for an 'Allow USB debugging?' authorization prompt on your device's screen and accept it.<br>4. Restart the ADB server by running <I>adb kill-server</I> followed by <I>adb devices</I>.<br>5. On Windows, verify that you have the correct Android USB drivers installed and updated.


title: HISTORY
content:
The <b>adb</b> tool, including the <b>devices</b> subcommand, has been an integral part of the Android SDK (Software Development Kit) since the early days of the Android operating system. It was designed from the outset as a primary interface for developers and power users to interact with Android devices for debugging, application development, and system administration tasks. The <b>adb devices</b> command, in particular, has remained a foundational utility, serving as the essential first step to confirm connectivity and availability of devices. Its consistent functionality and critical role underscore its enduring importance in the Android ecosystem's evolution.


title: PARAMETERS
content:
<b><I>host</I>[:<I>port</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies the IP address or hostname of the remote Android device or emulator to disconnect from. The port number is optional; if omitted, it defaults to 5555. If no host or port is provided, the command attempts to disconnect from all active TCP/IP connections.<br><br>


title: DESCRIPTION
content:
The `adb-disconnect` command is a utility designed to terminate active TCP/IP connections between the Android Debug Bridge (ADB) server and remote Android devices or emulators. It is commonly implemented as a shell script or an alias that wraps the standard `adb disconnect` subcommand.<br><br>When a device is connected via TCP/IP using `adb connect`, it establishes a network session with the ADB server running on the host machine. Over time, multiple such connections might accumulate, or a specific connection might become stale or problematic. `adb-disconnect` provides a clean way to sever these network links.<br><br>If invoked with a specific host and an optional port (e.g., `adb-disconnect 192.168.1.100:5555`), it targets and terminates only that particular connection. This is invaluable in scenarios where you need to manage multiple network-connected devices or debug network-related issues.<br><br>When called without any arguments, `adb-disconnect` performs a global cleanup, attempting to disconnect from <i>all</i> currently active TCP/IP connections that were previously established with `adb connect`. This makes it a quick tool for resetting the ADB server's network-based device list, freeing up resources, or ensuring that only USB-connected devices remain active. It's an essential command for maintaining a clean and efficient ADB environment, especially in complex development or testing setups.


title: CAVEATS
content:
The command `adb-disconnect` is not a standalone executable provided directly by the Android SDK. Instead, it is typically a convenience shell script, alias, or function created by users or within specific development environments (like Arch Linux's `android-tools` package) that internally executes the `adb disconnect` command. Therefore, its behavior is identical to `adb disconnect`. It only affects TCP/IP connections and does not disconnect USB-connected devices. Furthermore, it does not stop or kill the ADB server daemon itself.


title: DEFAULT BEHAVIOR
content:
When `adb-disconnect` is invoked without any arguments (i.e., without specifying a `host` or `port`), it attempts to disconnect from <i>all</i> currently active TCP/IP connections that were previously established using the `adb connect` command. This is a powerful feature for quickly cleaning up all network-based ADB sessions, allowing for a fresh start or to ensure that only USB-connected devices are being managed by the ADB server.


title: HISTORY
content:
The Android Debug Bridge (ADB) has been a fundamental tool for Android developers since the platform's inception, providing a command-line interface for communicating with devices and emulators. The `disconnect` functionality, integral to ADB's networking capabilities, was introduced to manage TCP/IP connections, which became increasingly relevant as Android devices began supporting ADB over Wi-Fi. While the core `adb disconnect` command has been present for a long time as part of the `adb` utility, `adb-disconnect` as a wrapper or alias likely emerged in community-driven distributions or user configurations to provide a more descriptive or convenient command name for this specific action.


title: SYNOPSIS
content:
<b>adb</b> [<i>-s &lt;serial&gt;</i> | <i>-d</i> | <i>-e</i> | <i>-t &lt;transport_id&gt;</i>] <b>forward</b> [<i>--no-rebind</i>] <i>&lt;local&gt; &lt;remote&gt;</i><br><b>adb</b> [<i>-s &lt;serial&gt;</i> | <i>-d</i> | <i>-e</i> | <i>-t &lt;transport_id&gt;</i>] <b>forward --list</b><br><b>adb</b> [<i>-s &lt;serial&gt;</i> | <i>-d</i> | <i>-e</i> | <i>-t &lt;transport_id&gt;</i>] <b>forward --remove &lt;local&gt;</b><br><b>adb</b> [<i>-s &lt;serial&gt;</i> | <i>-d</i> | <i>-e</i> | <i>-t &lt;transport_id&gt;</i>] <b>forward --remove-all</b>


title: PARAMETERS
content:
<b><i>&lt;local&gt; &lt;remote&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local and remote endpoints for the forward rule. These can be various types of sockets:<br><b>tcp:&lt;port&gt;</b>: TCP port (e.g., <i>tcp:8080</i>).<br><b>localabstract:&lt;name&gt;</b>: Unix domain socket in the abstract namespace.<br><b>localfilesystem:&lt;path&gt;</b>: Unix domain socket at a specific filesystem path.<br><b>dev:&lt;path&gt;</b>: Character device (e.g., <i>dev:/dev/ttyS0</i>).<br><b>jdwp:&lt;pid&gt;</b>: Java Debug Wire Protocol (JDWP) connection to a specific process ID.<br><br><b><b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently active port forwarding rules set for the specified device.<br><br><b><b>--remove &lt;local&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specific port forwarding rule identified by its local endpoint specification.<br><br><b><b>--remove-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all active port forwarding rules for the specified device.<br><br><b><b>--no-rebind</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>adb</i> from rebinding an existing local socket if it's already in use by another forward rule. If the local port is in use, the command will fail rather than overwriting an existing rule.<br><br><b><i>-s &lt;serial&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets a specific Android device by its unique serial number. Useful when multiple devices are connected.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets the only currently connected USB device. Fails if multiple USB devices are connected or no USB device is found.<br><br><b><i>-e</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets the only currently running emulator. Fails if multiple emulators are running or no emulator is found.<br><br><b><i>-t &lt;transport_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets a specific device by its transport ID. Useful for distinguishing devices when other selection criteria are ambiguous.<br><br>


title: DESCRIPTION
content:
<i>adb forward</i> establishes a network port forwarding rule between the host machine (where <i>adb</i> is run) and an Android device or emulator. This allows applications on the host to connect to a specific port on the device, or vice-versa (with <i>adb reverse</i>). It's commonly used for debugging, accessing services running on the device from the host, or testing network applications.<br><br>For example, you can forward a local host port (e.g., 8080) to a device port (e.g., 5000) so that connecting to <i>localhost:8080</i> on your computer actually connects to port <i>5000</i> on the Android device. This command is part of the Android Debug Bridge (ADB) utility, which provides a versatile command-line tool for communication with an Android device.


title: CAVEATS
content:
Requires the <i>adbd</i> daemon to be running on the Android device and USB debugging to be enabled and authorized. The specified local port must be available on the host machine. Forwarding ports can expose device services to the local network, potentially creating security vulnerabilities if not managed carefully. Some operations (e.g., accessing certain device filesystems or ports) might require root privileges on the Android device.


title: REVERSE PORT FORWARDING
content:
While <i>adb forward</i> creates a host-to-device connection, <i>adb reverse</i> (introduced later, starting from Android 5.0 Lollipop) allows forwarding a port from the device to the host. This is useful for device-side applications to connect to services running on the development machine.


title: RULE PERSISTENCE
content:
<i>adb forward</i> rules are typically temporary. They are automatically cleared when the <i>adbd</i> server on the device restarts, or when the <i>adb server</i> on the host machine restarts. For persistent forwarding, a script or startup service would be required.


title: HISTORY
content:
<i>adb</i> has been an integral part of the Android SDK since its early days. The <i>forward</i> command has been a core feature from the beginning, providing essential connectivity for developers to interact with and debug applications on Android devices and emulators. Its functionality has remained largely consistent, with minor enhancements and support for new socket types (like <i>jdwp</i>) being added over time.


title: PARAMETERS
content:
<b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Reinstall</I>. Replaces an existing application, preserving its data if possible.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Allow test packages</I>. Permits the installation of APKs that declare themselves as test-only (e.g., debug builds).<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Install to shared storage</I>. Attempts to install the application on shared/external storage (like an SD card) if the device supports it.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Allow version downgrade</I>. Enables installing an older version of an application over a newer one without requiring uninstallation first.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Grant all runtime permissions</I>. Automatically grants all runtime permissions requested by the application upon installation.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Keep data and cache</I>. When used with <B>-r</B> (reinstall), prevents the application's data and cache from being cleared during the update process.<br><br><b>--user <USER_ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Install for specific user</I>. Installs the application for a designated user profile on multi-user Android devices.<br><br><b><I>path_to_apk</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Path to APK file</I>. The mandatory argument specifying the full or relative path to the Android Package Kit (.apk) file on your host machine.<br><br>


title: DESCRIPTION
content:
The <B>adb install</B> command, part of the Android Debug Bridge (ADB) suite, is a fundamental tool used to deploy Android application packages (APKs) onto connected Android devices or emulators. It streamlines the process of transferring an application's executable file from a host machine to the target device and initiating its installation. <BR><BR>Primarily, <B>adb install</B> is indispensable for Android developers, enabling rapid testing, debugging, and iteration during the application development lifecycle. Beyond development, it's widely used for sideloading applications that are not available through official app stores or for installing custom builds. The command handles various installation scenarios, including fresh installs, reinstalling existing applications (optionally preserving data), downgrading app versions, and installing applications for specific users or storage locations. Successful execution requires USB debugging to be enabled on the Android device, the device to be properly connected and authorized, and the ADB server to be running on the host machine.


title: CAVEATS
content:
<B>Caveats</B>:<BR><BR><B>USB Debugging</B>: Must be enabled in the Developer options on the Android device.<BR><BR><B>Device Connection</B>: The device must be physically connected (via USB) and authorized with the host machine. Use <B>adb devices</B> to verify.<BR><BR><B>ADB Server</B>: The ADB server must be running on your host machine. It usually starts automatically with the first <B>adb</B> command.<BR><BR><B>Storage Space</B>: Insufficient storage space on the device will cause installation failure.<BR><BR><B>APK Validity</B>: The provided APK file must be valid, uncorrupted, and signed.<BR><BR><B>Security Prompts</B>: On some Android versions, you might need to manually confirm installation or grant permissions to install from unknown sources.


title: APK (ANDROID PACKAGE KIT)
content:
An <B>APK</B> is the package file format used by the Android operating system for distribution and installation of mobile applications and middleware. It is analogous to .exe files on Windows or .dmg files on macOS. An APK file contains all elements that an application needs to install correctly on a device, including code, assets, resources, certificates, and manifest files.


title: PACKAGE MANAGER (PM)
content:
On Android, the <B>Package Manager (PM)</B> is a system service responsible for installing, uninstalling, and managing applications. When you use <B>adb install</B>, ADB communicates with the device's <B>pm</B> service to perform the actual installation. You can also directly interact with the <B>pm</B> command via <B>adb shell pm install</B> for more granular or specific installation scenarios, though <B>adb install</B> simplifies the most common use cases.


title: HISTORY
content:
The <B>adb install</B> command has been a core component of the Android Debug Bridge (ADB) utility since the very early days of the Android SDK. Its fundamental purpose of deploying applications to devices made it an essential tool for Android developers from the outset. Over time, as the Android operating system evolved and introduced new features like multi-user support, runtime permissions, and different app installation mechanisms (e.g., split APKs, APEX), various options and flags were progressively added to <B>adb install</B> to accommodate these capabilities and provide more granular control over the installation process.


title: PARAMETERS
content:
<b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Silent mode.</I> Only print log messages for selected tags.<br><br><b><b>-f &lt;filename&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Output to file.</I> Write log messages to the specified file.<br><br><b><b>-r &lt;kbytes&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Rotate log file.</I> Rotate the log file every &lt;kbytes&gt; of output (requires <b>-f</b>).<br><br><b><b>-n &lt;count&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Max rotated files.</I> Set the maximum number of rotated log files (requires <b>-f</b> and <b>-r</b>).<br><br><b><b>-v &lt;format&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Output format.</I> Set the output format for log messages (e.g., <i>brief</i>, <i>long</i>, <i>threadtime</i>, <i>color</i>). Common formats include: <i>brief</i>, <i>long</i>, <i>process</i>, <i>raw</i>, <i>tag</i>, <i>thread</i>, <i>threadtime</i>, <i>time</i>, <i>color</i>, <i>epoch</i>, <i>monotonic</i>, <i>UTC</i>, <i>year</i>.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Clear buffer.</I> Clear (flush) the entire log buffer and exit.<br><br><b><b>-C &lt;count&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Clear and dump last N.</I> Clear the log buffer and then dump the last &lt;count&gt; entries.<br><br><b><b>-b &lt;buffer&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Select buffer.</I> Load an alternative log buffer (e.g., <i>main</i>, <i>system</i>, <i>radio</i>, <i>events</i>, <i>crash</i>, <i>kernel</i>, <i>default</i>, <i>all</i>).<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Dump and exit.</I> Print the buffer contents to the screen and exit.<br><br><b><b>-P &lt;pid&gt;</b>, <b>--pid=&lt;pid&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Filter by PID.</I> Select logs only from the specified process ID.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Dump latest.</I> Print only the latest event to the screen and exit.<br><br><b><b>-t &lt;time_format&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Time format.</I> Set the time format for log output (e.g., <i>time</i>, <i>threadtime</i>, <i>UTC</i>, <i>epoch</i>, <i>monotonic</i>).<br><br><b><b>-T &lt;count&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Dump last N lines.</I> Dump the most recent &lt;count&gt; lines from the buffer and exit.<br><br><b><b>-G &lt;size&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Set buffer size.</I> Set the log buffer size to &lt;size&gt;KB. Requires root or shell access.<br><br><b><b>--tag=&lt;tag&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Filter by tag.</I> Selects logs only from the specified tag.<br><br><b><b>&lt;filter-spec&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Log filtering.</I> Filters log output based on <i>tag:priority</i> pairs. Example: <i>ActivityManager:I *:S</i> (info for ActivityManager, silent for all others). Priority levels: <b>V</b> (<i>Verbose</i>), <b>D</b> (<i>Debug</i>), <b>I</b> (<i>Info</i>), <b>W</b> (<i>Warn</i>), <b>E</b> (<i>Error</i>), <b>F</b> (<i>Fatal</i>), <b>S</b> (<i>Silent/off</i>).<br><br>


title: DESCRIPTION
content:
<i>adb logcat</i> is a command-line tool that displays system messages (logs) from an Android device or emulator.<br>These logs are generated by various components of the Android system, including the kernel, services, applications, and the Android runtime. It's an essential tool for developers and testers to debug applications, understand system behavior, and diagnose issues.<br><i>logcat</i> allows for real-time viewing of logs as they occur, as well as filtering logs based on various criteria like tag, priority, process ID (PID), or message content. The logs are organized into several circular buffers, and <i>logcat</i> can access them, clear them, or display specific portions.<br>It's part of the Android Debug Bridge (ADB) suite, which provides a versatile interface for communicating with Android devices. This command is crucial for understanding the internal workings of an Android application or system, helping to identify errors, warnings, and informational messages during development and troubleshooting.


title: CAVEATS
content:
<i>Log buffer size can be limited, leading to older logs being overwritten.</i><br><i>adb logcat</i> can generate a large volume of data, making it hard to find relevant information without proper filtering.<br>Accessing certain log buffers or setting buffer size might require root privileges on the device.<br>Log formats can vary slightly across Android versions.<br>Running <i>logcat</i> on a heavily used device can impact performance due to constant I/O.


title: LOG BUFFERS
content:
Android organizes logs into multiple circular buffers. You can select a specific buffer using the <b>-b</b> option:<br><b>main</b>: <I>Default log buffer for application-related messages.</I><br><b>system</b>: <I>Log buffer for system-component messages.</I><br><b>radio</b>: <I>Log buffer for radio/telephony related messages.</I><br><b>events</b>: <I>Log buffer for system events.</I><br><b>crash</b>: <I>Log buffer for crash dumps.</I><br><b>kernel</b>: <I>Log buffer for kernel messages.</I><br><b>default</b>: <I>Combines main, system, and crash buffers.</I><br><b>all</b>: <I>Combines all available buffers.</I>


title: LOG PRIORITIES
content:
Logcat uses priority levels to categorize log messages. When filtering, a higher priority level will also include all messages of even higher priority. Priorities from lowest to highest are:<br><b>V</b> (<I>Verbose</I>): <I>Show everything (lowest priority).</I><br><b>D</b> (<I>Debug</I>): <I>Debug-level messages.</I><br><b>I</b> (<I>Info</I>): <I>Informational messages.</I><br><b>W</b> (<I>Warn</I>): <I>Warnings.</I><br><b>E</b> (<I>Error</I>): <I>Errors.</I><br><b>F</b> (<I>Fatal</I>): <I>Fatal errors (highest priority).</I><br><b>S</b> (<I>Silent/off</I>): <I>Turn off all log messages for a tag.</I>


title: HISTORY
content:
<i>adb logcat</i> has been an integral part of the Android SDK and platform tools since the early days of Android development. It evolved alongside the Android operating system, with new features and log buffers being added to support new system components (e.g., <i>events</i> buffer for system events, <i>crash</i> for crash dumps). Its functionality has remained consistent as a primary tool for debugging and system analysis on Android devices.


title: PARAMETERS
content:
<b><<i>host</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The IP address of the Android device to be paired. This is typically displayed on the device's 'Wireless debugging' settings screen.<br><br><b><<i>pairing_port</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The dynamic port number displayed on the Android device specifically for the pairing process. This port is distinct from the regular ADB connection port (e.g., 5555).<br><br><b>[<<i>pairing_code</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional 6-digit alphanumeric code displayed on the Android device for verification during the pairing process. If omitted, <b>adb-pair</b> will prompt the user to enter the code interactively.<br><br>


title: DESCRIPTION
content:
The <b>adb-pair</b> command is a crucial component of the Android Debug Bridge (ADB) suite, specifically designed to establish a secure, encrypted wireless debugging connection with an Android device. Introduced with Android 11 (API level 30), it provides a more robust and user-friendly alternative to the previous <b>adb tcpip</b> method for initial wireless setup.<br><br>Unlike <b>adb connect</b>, which is used for establishing a direct debugging session, <b>adb-pair</b> is a one-time authentication process. It facilitates the secure exchange of cryptographic keys between the host machine and the Android device. This process typically involves the device displaying a unique IP address, a dynamic pairing port, and a six-digit pairing code. The user then provides this information to the <b>adb-pair</b> command on the host.<br><br>Once successfully paired, the device remembers the host, and subsequent debugging sessions can be initiated using <b>adb connect</b> with the device's standard ADB connection port (typically 5555). This separation of pairing and connection enhances security by requiring an explicit, localized confirmation (the pairing code) for the initial trust establishment.


title: CAVEATS
content:
<b>Android Version Requirement:</b> Wireless debugging via <b>adb-pair</b> requires an Android device running Android 11 (API level 30) or later.<br><b>Network Connectivity:</b> Both the host machine and the Android device must be connected to the same Wi-Fi network.<br><b>Wireless Debugging Enabled:</b> The 'Wireless debugging' option must be enabled in the Developer options on the Android device.<br><b>Firewall Considerations:</b> Ensure that your host machine's firewall is not blocking outbound connections to the device's pairing port and subsequent connection port.<br><b>One-Time Pairing:</b> <b>adb-pair</b> is for initial setup. After successful pairing, use <b>adb connect</b> for debugging.<br><b>Port Distinction:</b> The <i>pairing_port</i> is dynamic and different from the standard ADB connection port (e.g., 5555).


title: WIRELESS DEBUGGING WORKFLOW
content:
The typical workflow for wireless debugging using <b>adb-pair</b> involves the following steps:<br>1.  On your Android device, navigate to <b>Settings</b> > <b>Developer options</b> > <b>Wireless debugging</b> and enable it.<br>2.  Tap on 'Wireless debugging' to view its details. Note down the IP address and the Pairing port, and the 6-digit pairing code.<br>3.  On your host machine, open a terminal and execute: <b>adb pair</b> <<i>device_ip_address</i>>:<<i>pairing_port</i>><br>4.  When prompted, enter the 6-digit pairing code displayed on your Android device.<br>5.  Upon successful pairing, you will see a confirmation message. The device is now authenticated.<br>6.  To start a debugging session, use <b>adb connect</b> with the device's IP address and the standard ADB connection port (usually 5555): <b>adb connect</b> <<i>device_ip_address</i>>:5555<br>7.  Verify the connection using <b>adb devices</b>. Your device should now be listed as connected over Wi-Fi.


title: HISTORY
content:
The <b>adb-pair</b> command was introduced as part of the Android 11 (API level 30) release in September 2020. Its development was driven by the need for a more secure, user-friendly, and streamlined approach to wireless debugging, addressing limitations and security concerns of the older <b>adb tcpip</b> method. It incorporates modern networking features like mDNS for discovery and a secure pairing flow, making wireless debugging a more integrated and reliable experience.


title: SYNOPSIS
content:
<b>adb reboot</b> [<i>bootloader</i> | <i>recovery</i> | <i>sideload</i> | <i>fastboot</i> | &lt;reason&gt;]


title: PARAMETERS
content:
<b>bootloader</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the device directly into the <i>bootloader</i> (also known as <i>fastboot</i>) mode. This mode is typically used for flashing firmware, unlocking the bootloader, or interacting with the device at a low level.<br><br><b>recovery</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the device into the <i>recovery</i> mode. Recovery mode allows users to perform system updates, factory resets, clear cache partitions, or flash custom ROMs.<br><br><b>sideload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the device into <i>recovery</i> mode and automatically prepares it to receive an update package via ADB sideload. This is commonly used for installing official OTA updates or custom ROMs.<br><br><b>fastboot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <i>bootloader</i>. Reboots the device into the <i>fastboot</i> mode.<br><br><b><reason></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows specifying a custom reboot reason string. This is less commonly used by end-users and more for system-level debugging or specific device implementations.<br><br>


title: DESCRIPTION
content:
<b>adb reboot</b> is an Android Debug Bridge command used to restart a connected Android device. It's part of the <i>adb</i> utility, which provides a versatile command-line tool for communication between a computer and an Android-powered device. This command is frequently used by developers, system administrators, and advanced users to quickly restart a device without needing to manually interact with the device's power button.<br><br>It's particularly useful when debugging applications, flashing custom ROMs, or performing system-level operations. The command supports various reboot modes, allowing the user to specify whether the device should reboot into the normal system, <i>bootloader</i>, <i>recovery</i>, or <i>sideload</i> mode. This granular control makes it an indispensable tool for device management and development workflows.


title: CAVEATS
content:
<i>Caveats</i>:<br>Requires Android SDK Platform-Tools to be installed on the host computer.<br>USB debugging must be enabled on the Android device.<br>The device must be connected to the computer via USB and authorized for debugging.<br>Firewall rules or USB driver issues can prevent a successful connection.<br>Using <b>adb reboot</b> with no arguments performs a normal system reboot.


title: PREREQUISITES
content:
Before using <b>adb reboot</b>, ensure that the Android SDK Platform-Tools are installed on your computer and that USB debugging is enabled on your Android device. You also need to authorize the connection on your device when prompted.


title: COMMON USE CASES
content:
Beyond general restarts, <b>adb reboot</b> is crucial for:<br><i>Flashing custom ROMs or recoveries</i>: By rebooting into <i>bootloader</i> or <i>recovery</i> mode.<br><i>Applying OTA updates</i>: Using <i>sideload</i> mode.<br><i>Debugging boot issues</i>: Restarting the device to observe boot logs.


title: HISTORY
content:
The Android Debug Bridge (ADB) has been an integral part of the Android SDK since its early days, evolving alongside the Android operating system. The <b>reboot</b> command has been a core functionality, providing developers with a consistent way to restart devices during development and testing cycles. Its functionality has remained largely stable, with occasional additions of specific reboot modes like <i>sideload</i> to support new device functionalities and development workflows.


title: SYNOPSIS
content:
<b>adb reverse</b> [<I>option</I>] <I>remote</I> <I>local</I><br><b>adb reverse</b> <I>--list</I><br><b>adb reverse</b> <I>--remove</I> <I>remote</I><br><b>adb reverse</b> <I>--remove-all</I>


title: PARAMETERS
content:
<b><I>remote</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port on the Android device. This is the port the application on the device will attempt to connect to. Typically in the format <I>tcp:&lt;device-port-number&gt;</I> (e.g., <I>tcp:8080</I>).<br><br><b><I>local</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port on the host machine. The connection from the device's <I>remote</I> port will be redirected to this host port. Typically in the format <I>tcp:&lt;host-port-number&gt;</I> (e.g., <I>tcp:8080</I>).<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all active reverse port forwardings currently set up via adb.<br><br><b>--remove <I>remote</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the specific reverse port forwarding associated with the given <I>remote</I> (device) port.<br><br><b>--remove-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all active reverse port forwardings from the device.<br><br>


title: DESCRIPTION
content:
The <I>adb reverse</I> command establishes a reverse port forwarding tunnel between an Android device (or emulator) and the host machine. Unlike <I>adb forward</I>, which makes a host port accessible to the device, <I>adb reverse</I> makes a <I>device</I> port accessible to the <I>host</I> machine. This means that an application running on the Android device can connect to a specified TCP port on the device, and that connection will be transparently redirected to a corresponding TCP port on the development host.<br><br>It's particularly useful in development scenarios where an app on the device needs to communicate with a server or service running locally on the developer's computer. For example, an app might try to connect to <I>localhost:8080</I> on the device, and <B>adb reverse</B> can route this connection to <I>localhost:8080</I> on the host, allowing the app to interact with a local backend server. The command supports TCP port mappings and can be cleared using the <I>--remove</I> or <I>--remove-all</I> options. This simplifies debugging and testing by eliminating the need to deploy local services to a publicly accessible IP address or expose them to the network.


title: CAVEATS
content:
Only supports TCP port forwarding. The established tunnels are temporary and will be cleared if the adb connection is lost (e.g., device disconnects, or <I>adb kill-server</I> is executed). Ensure the specified ports are not already in use on both the device and host machine. Requires developer options and USB debugging enabled on the Android device.


title: COMMON USE CASES
content:
<b><I>adb reverse</I></b> is invaluable for Android app development. Common scenarios include:<br><i>Connecting to a local backend server:</i> An application on the device can access a server running on the developer's machine (e.g., Node.js, Python, Java backend) via <I>localhost:&lt;port&gt;</I> on the device, without needing a public IP or complex network setup.<br><i>Debugging:</i> Facilitates communication with debugging tools or proxies running on the host.<br><i>Testing:</i> Enables rigorous testing against local versions of APIs or services.


title: MANAGING MAPPINGS
content:
It's good practice to manage your reverse port forwardings. You can view all active mappings using <b><I>adb reverse --list</I></b>. To clean up, use <b><I>adb reverse --remove &lt;device-port&gt;</I></b> for specific mappings or <b><I>adb reverse --remove-all</I></b> to clear all active reverse tunnels, especially after development sessions.


title: HISTORY
content:
The <B>adb reverse</B> command was introduced in later versions of the Android SDK Platform-Tools, specifically to address the growing need for devices to connect back to development services running on the host machine. While <I>adb forward</I> existed earlier for host-to-device communication, <B>adb reverse</B> filled the critical gap for device-to-host connectivity, becoming an indispensable tool for mobile application developers using local backend servers, debuggers, or other host-based services.


title: PARAMETERS
content:
<b>COMMAND</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. The specific command string to execute on the Android device. If a command is provided, <b>adb shell</b> will execute it, print its standard output and error, and then exit. Multiple commands can be chained using standard shell operators (e.g., <i>&&</i>, <i>||</i>, <i>;</i>).<br><br><b>ARGS...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Optional</i>. Arguments to be passed to the <i>COMMAND</i> being executed on the device. These arguments are interpreted by the shell environment on the Android device.<br><br>


title: DESCRIPTION
content:
The <b>adb shell</b> command is a crucial component of the Android Debug Bridge (ADB), a versatile command-line tool that allows communication with an Android-powered device or emulator. Specifically, <b>adb shell</b> provides a direct command-line interface (CLI) to the device's underlying Linux operating system. This functionality is invaluable for Android developers, system administrators, and power users for debugging applications, inspecting system state, managing files, and executing various system commands directly on the device. It can be used to execute a single command and return its output, or to establish a persistent, interactive shell session, much like SSHing into a remote Linux server. The commands available within the shell are typically standard Linux utilities, often provided by <I>BusyBox</I> or a more complete <I>toybox</I> environment, along with Android-specific tools like <I>logcat</I>, <I>dumpsys</I>, and <I>am</I> (Activity Manager).


title: CAVEATS
content:
Connecting via <b>adb shell</b> requires debugging mode to be enabled on the Android device (typically found in <i>Developer options</i> > <i>USB debugging</i>).<br>Device authorization via a pop-up prompt might be required on the device's screen upon the first connection from a new host.<br>By default, permissions are often limited to the scope of a non-root user; accessing root capabilities typically requires a rooted device and the use of the <i>su</i> command within the shell.<br>The set of available commands and their behavior can vary slightly between Android versions and device manufacturers due to different <I>BusyBox</I>/<I>toybox</I> versions or custom system utilities.<br>Complex shell scripting or input/output redirection within a single non-interactive command can sometimes behave differently than on a full Linux system due to shell environment variations.


title: INTERACTIVE VS. NON-INTERACTIVE MODE
content:
When no <i>COMMAND</i> is specified, <b>adb shell</b> enters an interactive mode, providing a continuous command prompt on the device, similar to a traditional terminal session. When a <i>COMMAND</i> is specified, it runs in non-interactive mode, executing the command, returning its output, and then returning control to the host shell after completion.


title: COMMON USES
content:
<b>adb shell</b> is widely used for:<br>- Inspecting device logs (e.g., <i>logcat</i>)<br>- Managing packages (e.g., <i>pm install/uninstall</i>, <i>pm list packages</i>)<br>- Controlling services and activities (e.g., <i>am start</i>, <i>dumpsys</i>)<br>- Exploring and managing the device's file system (e.g., <i>ls</i>, <i>cd</i>, <i>cp</i>, <i>rm</i>, <i>mkdir</i>)<br>- Monitoring processes (e.g., <i>ps</i>, <i>top</i>)<br>- Capturing screenshots (e.g., <i>screencap</i>)<br>- Recording screen video (e.g., <i>screenrecord</i>)


title: ROOT ACCESS
content:
On rooted devices, you can often gain root privileges within the <b>adb shell</b> by typing <i>su</i>. This provides elevated permissions, allowing access to protected system areas and execution of privileged commands, which is essential for advanced customization, deep debugging, and system modification.


title: HISTORY
content:
The <b>adb shell</b> functionality has been a fundamental component of the Android SDK since its earliest versions, evolving alongside the Android operating system itself. Its development has closely mirrored the needs of app developers and system engineers, providing a critical interface for interacting with Android's Linux kernel and user space. Over time, security enhancements in Android have introduced new authorization steps for ADB connections, but the core utility of <b>adb shell</b> for development, debugging, and advanced system interaction has remained undiminished. It has consistently been the primary method for performing low-level operations on Android devices without requiring physical interaction or a graphical user interface.


title: PARAMETERS
content:
<b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps the data and cache directories of the application after uninstallation. By default, both are removed, but this option preserves user data for reinstallation or analysis.<br><br><b>&lt;PACKAGE_NAME&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The full package name of the application to uninstall (e.g., 'com.android.chrome', 'com.whatsapp'). This is a mandatory argument that uniquely identifies the app.<br><br>


title: DESCRIPTION
content:
<i>`adb uninstall`</i> is a powerful subcommand of the Android Debug Bridge (<i>adb</i>) tool, which is an essential component of the Android SDK Platform-Tools. This command allows developers and power users to programmatically remove installed Android application packages (APKs) from a connected Android device or emulator. When executed, <i>`adb uninstall`</i> sends a command to the <i>adbd</i> daemon running on the target Android device, instructing it to remove the specified application. This process typically deletes not only the application's executable files but also its associated data, caches, and user settings, effectively cleaning up the device's storage and user profiles for that app.<br><br>The command requires the Android device to be connected to the computer via USB (or wirelessly, if configured) with USB debugging enabled in the device's developer options. It is widely used in app development for quick iterative testing, where applications are frequently installed and removed. Furthermore, it's invaluable for system administrators or advanced users who need to remove bloatware, pre-installed apps (often requiring root access), or simply manage storage on their Android devices. The operation is typically very fast, making it efficient for bulk uninstallation scripts or rapid deployment scenarios.


title: CAVEATS
content:
<i>Uninstalling system applications or bloatware often requires the device to be rooted, and even then, proceeding with extreme caution is advised as removing critical system components can brick the device. Ensure USB debugging is enabled on the Android device and that the device is properly connected and authorized by the host machine. The package name must be exact; typos will result in a 'Failure [DELETE_FAILED_INTERNAL_ERROR]' or 'Failure [not installed for 0]' message. Uninstallation is permanent for the application's core files and usually its data, unless the <i>`-k`</i> option is used.</i>


title: HOW TO FIND PACKAGE NAMES
content:
To successfully use <i>`adb uninstall`</i>, you need the exact package name of the application. You can find this using the command <i>`adb shell pm list packages`</i>, which lists all installed packages on the device. To filter the list, you can pipe it to <i>`grep`</i> on your host machine, for example: <i>`adb shell pm list packages | grep 'appname_keyword'`</i>. The output will typically be in the format 'package:<i>com.example.app</i>', where <i>com.example.app</i> is the package name you need.


title: COMMON ERROR MESSAGES
content:
A common error is 'Failure [not installed for 0]' which usually means the package name provided is incorrect or the app is not installed for the current user profile on the device. 'Failure [DELETE_FAILED_INTERNAL_ERROR]' is a more generic error that can occur for various reasons, including insufficient permissions (e.g., trying to uninstall a system app without root access) or underlying issues with the Android system's package manager. Always double-check the package name, device connection, and necessary permissions.


title: HISTORY
content:
The <i>`adb uninstall`</i> command has been a fundamental part of the Android Debug Bridge since its inception as a core component of the Android SDK Platform-Tools. Its primary functionality for removing applications has remained largely consistent across various Android versions, reflecting its crucial role in application development and device management. While Android itself has undergone significant evolution, the simplicity and directness of <i>`adb uninstall`</i> have ensured its continued relevance and widespread usage among developers and power users for over a decade.


title: SYNOPSIS
content:
Since <b>add-apt-key</b> is not a command, here's the synopsis for the <I>apt-key add</I> subcommand, which it commonly refers to:<br><br><b>apt-key add</b> <i>&lt;filename&gt;</i><br><b>apt-key add</b> <i>-</i>


title: PARAMETERS
content:
<b><i>&lt;filename&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the GPG ASCII armored public key file to add to the trusted keyring.<br><br><b><i>-</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <b>apt-key</b> to read the key from standard input (stdin). This is common when piping the output of a command like <b>curl</b> or <b>wget</b>.<br><br>


title: DESCRIPTION
content:
The term <b>add-apt-key</b> is a common phrase used by Linux users to describe the process of adding a GPG (GNU Privacy Guard) public key to APT's (Advanced Package Tool) trusted keyring. <br><br>It is important to note that <b>add-apt-key</b> is <B>not a standalone command</B> in Linux. Instead, users typically refer to actions performed using the <b>apt-key</b> utility, or more recently, a series of commands involving <b>curl</b> or <b>wget</b> and <b>gpg</b>.<br><br>Historically, and still commonly, users would use <b>apt-key add</b> to import a GPG key, typically provided by a third-party software repository. This key allows APT to verify the authenticity of packages downloaded from that repository, ensuring they have not been tampered with. <br><br>However, the <b>apt-key</b> utility is officially <B>deprecated</B> due to security concerns, as it places all added keys into a single, global trust store. If one of these keys were ever compromised, it could potentially affect the integrity of packages from all other repositories. Modern Linux distributions and APT versions encourage a more granular, per-repository key management approach, often involving placing de-armored keyrings in specific directories like <i>/etc/apt/keyrings/</i> and referencing them directly in <i>/etc/apt/sources.list.d/</i> entries using the <i>signed-by</i> option.


title: CAVEATS
content:
<ul><li><b>add-apt-key</b> is not a real command; it's a conceptual term.</li><li>The <b>apt-key</b> utility is considered <B>deprecated</B> and its use is discouraged in modern Debian-based systems (e.g., Ubuntu 20.04+).</li><li>Adding keys via <b>apt-key</b> places them into a global trust store (<i>/etc/apt/trusted.gpg</i> or <i>/etc/apt/trusted.gpg.d/</i>). This centralizes trust, meaning if any single key in this store is compromised, it could undermine the security of all your APT repositories.</li><li>For enhanced security and better maintainability, adopt the modern approach of using <i>signed-by</i> in your <i>sources.list</i> entries with keys stored in dedicated keyring directories (e.g., <i>/etc/apt/keyrings/</i>).</li></ul>


title: MODERN APT KEY MANAGEMENT
content:
For modern and more secure APT key management, avoid <b>apt-key</b>. Instead, download the GPG key, de-armor it, and place it directly into a dedicated keyring directory (e.g., <i>/etc/apt/keyrings/</i>). Then, reference this specific keyring file in your repository's <i>.list</i> file (e.g., in <i>/etc/apt/sources.list.d/</i>) using the <i>signed-by</i> option.<br><br><b>Example of Modern Key Addition:</b><br>1. Download and de-armor the key:<br>   <i>curl -fsSL https://example.com/example_repo_key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/example-archive-keyring.gpg</i><br><br>2. Add or modify your repository entry (e.g., <i>/etc/apt/sources.list.d/example.list</i>) to reference the new keyring:<br>   <i>deb [arch=amd64 signed-by=/etc/apt/keyrings/example-archive-keyring.gpg] https://example.com/repo stable main</i><br><br>This method ensures that the key's trust is scoped only to the specific repository it belongs to, improving security and clarity.


title: HISTORY
content:
The concept of managing APT's trusted keys has evolved significantly. The <b>apt-key</b> utility has been a part of the APT ecosystem for many years, serving as the primary method to add external GPG keys for repository verification. Its design, which involved adding keys to a global keyring, was sufficient for earlier times. However, with increased focus on supply chain security and the desire for more granular control over trusted sources, its limitations became apparent. Debian and Ubuntu, as maintainers of APT, began to actively discourage the use of <b>apt-key</b> starting around their 20.04 LTS and 22.04 LTS releases, promoting the more secure and explicit <i>signed-by</i> option in <i>sources.list</i> entries.


title: PARAMETERS
content:
<b><I>REPOSITORY</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 line (e.g., <I>"deb http://example.com/repo stable main"</I>).<br><br><b><B>-r</B>, <B>--remove</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the specified repository from the system's software sources.<br><br><b><B>-y</B>, <B>--yes</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all prompts, making the command non-interactive.<br><br><b><B>--no-update</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not run <I>apt update</I> after adding or removing the repository. By default, <I>apt update</I> is executed.<br><br><b><B>--update</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly run <I>apt update</I> after adding or removing the repository. This is the default behavior when <B>--no-update</B> is not specified.<br><br><b><B>--enable-max-https</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When adding a PPA, attempt to use maximum HTTPS security if available.<br><br><b><B>--ppa-dist-name</B> <I>DIST_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the distribution name for the PPA (e.g., <I>focal</I>, <I>jammy</I>). This can be useful if the auto-detected distribution is incorrect.<br><br>


title: DESCRIPTION
content:
The <I>add-apt-repository</I> command simplifies the process of adding and removing APT (Advanced Package Tool) repositories on Debian-based Linux distributions, most notably Ubuntu. It is a wrapper script that automates several manual steps involved in managing software sources.<br><br>Historically, adding a new repository required manually editing <I>/etc/apt/sources.list</I> or creating a new file in <I>/etc/apt/sources.list.d/</I>, then separately fetching and adding the repository's GPG public key using <I>apt-key</I> (or modern methods like <I>signed-by</I> directives), and finally running <I>apt update</I>. <I>add-apt-repository</I> streamlines this entire workflow into a single command.<br><br>Its primary use case is integrating Personal Package Archives (PPAs) hosted on Launchpad, which provide newer software versions or packages not available in the official distribution repositories. It can also be used to add any standard <I>deb</I> or <I>deb-src</I> APT line. Upon successful addition, it automatically runs <I>apt update</I> (unless specified otherwise) to refresh the package lists, making the new packages available for installation.


title: CAVEATS
content:
Adding arbitrary or untrusted repositories can pose significant security risks, as it grants the repository maintainer the ability to distribute any software, including malicious code, to your system. It can also lead to package conflicts or 'dependency hell' if the packages in the added repository clash with existing ones. It is advisable to only add repositories from trusted sources. <I>add-apt-repository</I> itself is typically provided by the <I>software-properties-common</I> package, which must be installed for the command to be available.


title: GPG KEY HANDLING
content:
When a repository is added, <I>add-apt-repository</I> attempts to fetch the corresponding GPG public key from a keyserver (usually <I>keyserver.ubuntu.com</I> for PPAs) or directly from the repository's host. It then places this key into a secure location, typically a file under <I>/etc/apt/trusted.gpg.d/</I>, or adds a <I>signed-by</I> directive to the repository's configuration, ensuring that packages from the repository can be authenticated by <I>apt</I>.


title: BEHIND THE SCENES
content:
For PPAs, <I>add-apt-repository</I> generally creates a new file in <I>/etc/apt/sources.list.d/</I> (e.g., <I>user-ubuntu-ppa-dist.list</I>). This file contains the <I>deb</I> and potentially <I>deb-src</I> lines for the PPA. For generic APT lines, it might also create a file in this directory or modify <I>/etc/apt/sources.list</I>. This modular approach helps keep the software sources organized and simplifies management, as each repository gets its own dedicated configuration file.


title: HISTORY
content:
<I>add-apt-repository</I> was introduced as part of the <I>software-properties-common</I> package, primarily for Ubuntu distributions. Its development aimed to simplify the management of Personal Package Archives (PPAs) hosted on Launchpad, which became a popular method for developers to distribute software outside of official repositories. Before this command, users had to manually perform multiple steps involving editing configuration files and using <I>apt-key</I> for GPG key management. <I>add-apt-repository</I> automated this process, making it more accessible to a wider range of users and integrating PPA management seamlessly into the system's package management workflow.


title: PARAMETERS
content:
<b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short usage message and exits.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of <i>addftinfo</i> and exits.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the processing.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to fix broken BDF font files, for example, those missing the <I>ENDFONT</I> keyword.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <I>encoding adobe</I> to the font information if it's not already present.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>addftinfo</i> from adding information if it detects that font info is already present in the file.<br><br><b><b>-e &lt;encoding&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the specified <I>encoding</I> string to be used instead of attempting to guess the encoding.<br><br><b><b>-s &lt;fontfamily&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the specified <I>fontfamily</I> string to be used instead of guessing the font's family.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to add the <I>FOUNDRY</I> field to the font information (this is disabled by default).<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the addition of a PFB (Printer Font Binary) header to Type 1 fonts. This option can be useful if <i>addftinfo</i> incorrectly adds a PFB header to a PFA (Printer Font ASCII) font.<br><br>


title: DESCRIPTION
content:
<i>addftinfo</i> is a utility program provided as part of the FreeType library's demonstration or utility packages. Its primary function is to parse various font files, such as <b>Type 1</b> (PFA/PFB) and <b>BDF</b> fonts, and embed additional metadata into them. This metadata, including details like <I>FONT</I>, <I>FAMILY</I>, <I>WEIGHT</I>, <I>FOUNDRY</I>, and <I>ENCODING</I>, is crucial for font configuration systems like <b>Fontconfig</b> to correctly identify and use the fonts.<br><br>The command inserts this information as a comment block within the font file: typically after <I>EndFontMetrics</I> for Type 1 fonts or before <I>EndSplineFont</I> for BDF fonts. While TrueType fonts usually contain sufficient internal metadata, <i>addftinfo</i> can also extract information from them. It works by creating a temporary modified file and then replacing the original, ensuring atomic updates. This tool is especially useful for older or less compliant font files that might lack the necessary metadata for modern font systems to function optimally.


title: CAVEATS
content:
<ul><li>Primarily useful for older or non-standard <b>Type 1</b> and <b>BDF</b> fonts. Modern font formats like TrueType and OpenType typically embed sufficient metadata and do not require <i>addftinfo</i>.</li><li>The command modifies the font file directly by creating a temporary file and then renaming it. It's always advisable to back up critical font files before processing them.</li><li>Incorrect usage or issues with the source font file can potentially lead to corrupted font files, though the temporary file approach reduces risk.</li></ul>


title: PURPOSE IN FONT MANAGEMENT
content:
While font rendering is handled by libraries like FreeType, font discovery and selection are managed by systems like <b>Fontconfig</b>. Fontconfig relies on specific metadata embedded within font files or provided in configuration files. <i>addftinfo</i> bridges the gap for fonts that lack this necessary internal metadata, making them discoverable and usable by Fontconfig without manual configuration.


title: SUPPORTED FONT FORMATS
content:
The tool primarily targets <I>Type 1</I> (both PFA and PFB) and <I>BDF</I> (Glyph Bitmap Distribution Format) font files. While it can extract information from <I>TrueType</I> fonts, it generally does not need to add information to them as TrueType fonts typically have rich internal metadata.


title: HISTORY
content:
<i>addftinfo</i> is part of the <b>FreeType</b> project, a widely used software library that implements a font rasterizer. It was developed by David Turner and has been a component of the FreeType utility suite for a considerable time, serving to address the specific need of embedding metadata into older or less compliant font formats to ensure proper recognition and rendering by modern font rendering systems like <b>Fontconfig</b>. Its primary utility emerged from the necessity to standardize font metadata across various formats for consistent font discovery and management in Unix-like operating systems.


title: SYNOPSIS
content:
<b>addgroup</b> [<i>options</i>] <i>groupname</i><br><b>addgroup</b> <i>--help</i><br><b>addgroup</b> <i>--version</i>


title: PARAMETERS
content:
<b><i>groupname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the new group to be created. This name must be unique and adhere to system naming conventions.<br><br><b><i>--system</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a system group. System groups typically have GIDs within a reserved range (e.g., 1-999) and are often used for system services rather than human users.<br><br><b><i>--gid GID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Group ID (GID) for the new group. The GID must be a unique, non-negative integer. If not specified, <i>addgroup</i> will automatically assign the next available GID from the appropriate range.<br><br><b><i>--force-badname</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows group names that do not conform to the system's regular expression for valid names. Use with caution as non-standard names can cause compatibility issues.<br><br><b><i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages, making the command execute silently without status updates or warnings.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage information and available options.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information for the <i>addgroup</i> command.<br><br>


title: DESCRIPTION
content:
<i>addgroup</i> is a command-line utility used to create new user groups on a Linux system. It is often a higher-level script or wrapper around the more fundamental <i>groupadd</i> command, providing a more user-friendly interface, default behaviors, and adherence to system policies for group creation. When invoked, <i>addgroup</i> assigns a unique Group ID (GID) to the new group, either automatically from an an available range defined in <i>/etc/login.defs</i> or explicitly if specified by the user. The command updates system configuration files, primarily <i>/etc/group</i> and <i>/etc/gshadow</i>, to register the new group.<br><br>Unlike <i>groupadd</i>, <i>addgroup</i> typically handles GID allocation automatically and may prompt for additional information or provide warnings based on the group name or GID chosen. It supports creating both regular user groups and system groups, which are typically used for system services and have GIDs within a reserved low range. This command is essential for system administrators to organize users into logical access control units for file permissions and resource management.


title: CAVEATS
content:
<b>Permissions:</b> <i>addgroup</i> requires root privileges to execute successfully, as it modifies critical system configuration files. <br><b>GID Collision:</b> If you specify a GID using <i>--gid</i> that is already in use, the command will typically fail unless overridden by specific options (though <i>addgroup</i> usually prevents this by default). <br><b>Wrapper Script:</b> On many distributions (especially Debian/Ubuntu), <i>addgroup</i> is a Perl script wrapper around <i>groupadd</i> from the shadow-utils package. This script provides a more user-friendly interface, enforces local policies (like GID ranges from <i>/etc/login.defs</i>), and handles common scenarios more gracefully than directly using <i>groupadd</i>. Consequently, its behavior can sometimes differ slightly from a direct <i>groupadd</i> call or between distributions.


title: CONFIGURATION FILES
content:
<i>addgroup</i> primarily modifies <i>/etc/group</i> (stores group names and GIDs) and <i>/etc/gshadow</i> (stores encrypted group passwords and administrators). It also refers to <i>/etc/login.defs</i> for default GID ranges and other policy settings.


title: GROUP NAMING CONVENTIONS
content:
Group names should generally be composed of alphanumeric characters, hyphens, and underscores, and typically start with a lowercase letter. The maximum length often varies but is usually limited to 32 characters to ensure compatibility across different system utilities.


title: HISTORY
content:
The <i>addgroup</i> command typically originates from distributions like Debian and its derivatives (e.g., Ubuntu). While the lower-level <i>groupadd</i> command has been a standard part of Unix-like systems for a long time (usually provided by the <i>shadow-utils</i> package), <i>addgroup</i> was developed to offer a more administrative-friendly, policy-aware interface. It often incorporates specific distribution policies regarding GID ranges, system vs. regular groups, and provides better error messages or prompts, making system administration tasks more streamlined and less prone to manual errors. Its development reflects a trend towards higher-level tools that abstract away some complexities of low-level system calls.


title: PARAMETERS
content:
<b><i>DEVICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The disk device (e.g., <i>/dev/sda</i> or <i>/dev/nvme0n1</i>) on which the partition resides.<br><br><b><i>PARTITION</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The numerical identifier of the partition to be added or re-read (e.g., <i>1</i> for the first partition).<br><br><b><i>START</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The starting sector of the partition. This is an optional parameter typically used to explicitly define the partition's extent for the kernel.<br><br><b><i>END</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The ending sector of the partition. This, along with <i>START</i>, defines the partition's boundaries and is also optional.<br><br>


title: DESCRIPTION
content:
<i><b>addpart</b></i> is a utility used to inform the Linux kernel about the existence of a new partition on a disk. It does not create or modify partition tables on the storage device; instead, it reads the on-disk partition table and tells the kernel to re-read it, specifically for a designated partition. This command is particularly useful when a partition has been created or resized using tools like <i><b>fdisk</b></i>, <i><b>sfdisk</b></i>, or <i><b>parted</b></i>, and the kernel needs to be made aware of these changes without requiring a full system reboot.<br><br>On many modern Linux distributions, <i><b>addpart</b></i> is a symbolic link to the more general <i><b>partx</b></i> utility, which provides broader functionality for manipulating partition information visible to the kernel. While <i><b>addpart</b></i> focuses on adding a <i>single</i> specified partition, <i><b>partx</b></i> can re-read the entire partition table for a device or list partitions.


title: CAVEATS
content:
<i>The <b>addpart</b> command does not create or modify partitions on the disk. It only instructs the kernel to re-read the partition table for a specified partition. Changes made to the disk's partition table using tools like <b>fdisk</b>, <b>sfdisk</b>, or <b>parted</b> must be saved first.<br><br>For automatic detection of partition table changes, <b>udev</b> rules often handle this, or <b>partprobe</b> is a more general utility. In many modern systems, <b>partprobe</b> or <b>partx -a</b> are preferred for comprehensive partition table re-scanning.</i>


title: KERNEL VS. ON-DISK PARTITION TABLES
content:
<i>When you create or modify partitions using tools like <b>fdisk</b> or <b>parted</b>, these changes are written to the disk's partition table. However, the Linux kernel maintains its own in-memory representation of the partition table. For the operating system to recognize and use the newly created or modified partitions, the kernel's in-memory table must be updated. <b>addpart</b> (or <b>partx</b>) serves this purpose, explicitly instructing the kernel to refresh its view of a specific partition without requiring a system reboot. If the kernel's view is not updated, attempts to mount or access the new partition will fail.</i>


title: HISTORY
content:
<i><b>addpart</b></i> is part of the <i><b>util-linux</b></i> package, a collection of essential Linux utilities. Its primary role was to manually inform the kernel about new partition layouts. With the advent and widespread adoption of <i><b>udev</b></i> and the <i><b>partprobe</b></i> utility, the manual execution of <i><b>addpart</b></i> or <i><b>partx -a</b></i> became less frequently necessary, as these systems often automatically detect and process partition table changes. On many current Linux distributions, <i><b>addpart</b></i> is implemented as a symbolic link to the more versatile <i><b>partx</b></i> command, inheriting its functionality.


title: SYNOPSIS
content:
<b>addr2line</b> [<i>options</i>] [<i>addresses</i>]<br><b>addr2line</b> -e <i>executable_file</i> [<i>options</i>] [<i>addresses</i>]


title: PARAMETERS
content:
<b><b>-a</b>, <b>--addresses</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show addresses before function names, file names, and line numbers. This is the default.<br><br><b><b>-b</b>, <b>--basename</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show the basename of the file name. For example, 'main.c' instead of '/home/user/project/main.c'.<br><br><b><b>-C</b>, <b>--demangle</b>[=<I>STYLE</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Demangle C++ function names. This makes names like '_ZN12MyClassCtorEv' readable as 'MyClass::MyClass()'.<br><br><b><b>-e</b> <I>executable_file</I>, <b>--exe</b>=<I>executable_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the executable or object file containing the addresses. This option is crucial for <b>addr2line</b> to find debug information.<br><br><b><b>-f</b>, <b>--functions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show function names as well as file and line information.<br><br><b><b>-i</b>, <b>--inlines</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all inlined functions that are part of the address's location. This can produce multiple lines of output for a single address.<br><br><b><b>-j</b> <I>section_name</I>, <b>--section</b>=<I>section_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read addresses from the specified section instead of the default '.text' section.<br><br><b><b>-p</b>, <b>--pretty-print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make the output more human-readable. Often combines addresses, functions, files, and lines on a single line.<br><br><b><b>-s</b>, <b>--absolute</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make file names absolute rather than relative to the current directory.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i><b>addr2line</b></i> is a utility that translates program addresses into file names and line numbers, and optionally function names.<br><br>It is an essential tool for debugging, especially when dealing with crash logs or core dumps that provide raw memory addresses but lack symbolic information. By providing <i><b>addr2line</b></i> with an executable (or shared library) and a list of addresses, it can use the debug information (typically <I>DWARF</I> debug symbols) embedded within the binary to pinpoint the exact location in the source code where a particular address falls.<br><br>This allows developers to quickly identify the source file, line number, and even the function name corresponding to an instruction address, which is invaluable for understanding program behavior, tracing execution flow, and diagnosing issues in post-mortem analysis.


title: CAVEATS
content:
<b>addr2line</b>'s effectiveness is entirely dependent on the presence of debug information within the executable or shared library. If the binary was compiled without debug symbols (e.g., using <b>-s</b> to strip symbols, or without the <b>-g</b> compiler flag), <b>addr2line</b> will likely report '??' for function names, file names, and line numbers.<br><br>Highly optimized code can sometimes make the output less precise, as compiler optimizations might reorder instructions or inline functions, making a direct address-to-source mapping ambiguous.


title: COMPILING WITH DEBUG SYMBOLS
content:
To ensure <b>addr2line</b> works correctly, always compile your C/C++ programs with the <b>-g</b> flag (e.g., <code>gcc -g my_program.c -o my_program</code>). This flag tells the compiler to include <I>DWARF</I> debug information in the executable, which <b>addr2line</b> relies upon.


title: TYPICAL USAGE
content:
You might use <b>addr2line</b> when a program crashes and prints a stack trace with memory addresses. For example:<br><code>addr2line -e my_program 0x400500 0x40052a</code><br>Or to process addresses from a file:<br><code>cat crash_addresses.txt | addr2line -f -C -e my_program</code>


title: HISTORY
content:
<b>addr2line</b> is part of the GNU Binutils project, a collection of programming tools for creating and managing binary programs, object files, libraries, and executables. Binutils has been actively developed since the 1980s, with <b>addr2line</b> emerging as a key component for post-mortem debugging alongside other utilities like <b>objdump</b> and <b>readelf</b>. Its functionality is often integrated into higher-level debuggers like GDB, but it remains an indispensable standalone tool for automated analysis and scripting.


title: SYNOPSIS
content:
<b>adduser</b> [<i>options</i>] <i>username</i> [<i>group</i>]<br><b>adduser</b> <i>username</i> <i>group</i><br><b>adduser</b> <i>--system</i> <i>username</i><br><b>adduser</b> <i>--help</i>


title: PARAMETERS
content:
<b>--home DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the user's home directory.<br><br><b>--shell SHELL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the user's login shell.<br><br><b>--uid ID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the user's unique ID (UID).<br><br><b>--gid ID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the primary group ID (GID).<br><br><b>--ingroup GROUP</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the primary group by name.<br><br><b>--disabled-password</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not set a password, user cannot login until one is set.<br><br><b>--disabled-login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not allow login until password is set.<br><br><b>--force-badname</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow usernames that do not conform to system regex.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a system account (UIDs typically below 1000).<br><br><b>--no-create-home</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not create the user's home directory.<br><br><b>--add_extra_groups</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add user to common extra groups defined in config.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose debug output.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
The <b>adduser</b> command is a high-level utility used to add new user accounts to a Linux system. It provides a more user-friendly and often <i>interactive</i> interface compared to the lower-level <b>useradd</b> command. While <b>useradd</b> directly manipulates system configuration files such as <i>/etc/passwd</i>, <i>/etc/shadow</i>, and <i>/etc/group</i>, <b>adduser</b> automates several steps. These include creating the user's home directory, copying default skeleton files from <i>/etc/skel</i>, setting up initial permissions, and prompting the administrator for necessary user details like username, password, and full name.<br><br>The specific implementation and features of <b>adduser</b> can vary significantly between Linux distributions. For instance, on Debian and Ubuntu systems, <b>adduser</b> is a sophisticated Perl script that handles many complexities automatically, while on Red Hat and CentOS, <b>useradd</b> is typically the preferred and more commonly used tool for both manual and automated user creation tasks. This command ensures that all necessary configurations for a new user are set up correctly and consistently.


title: CAVEATS
content:
The behavior and available options of <b>adduser</b> can differ significantly between Linux distributions. It is primarily a feature-rich script on Debian/Ubuntu systems, whereas on Red Hat/CentOS, <b>useradd</b> is the more direct and commonly used utility.<br><br>Execution typically requires root privileges.<br><br>Its interactive nature, while user-friendly for manual operations, makes it less ideal for shell scripting and automation, where <b>useradd</b> is generally preferred due to its non-interactive nature.


title: INTERACTIVE PROMPTS
content:
On Debian/Ubuntu systems, <b>adduser</b> is highly interactive. It prompts the administrator for a new password and then for optional 'full name', 'room number', 'work phone', 'home phone', and 'other' information. This interactive process ensures all relevant user details can be captured during creation.


title: CONFIGURATION FILE
content:
The default behavior of <b>adduser</b> is controlled by the <i>/etc/adduser.conf</i> configuration file (on Debian/Ubuntu systems). This file allows administrators to customize various aspects of new user accounts, such as the default home directory, default shell, private user group settings, UIDs/GIDs ranges, and password expiration policies.


title: HISTORY
content:
The <b>adduser</b> command emerged as a more administrator-friendly alternative to the lower-level <b>useradd</b> utility, especially prominent in Debian-based distributions. While <b>useradd</b> directly manipulates core system files like <i>/etc/passwd</i> and <i>/etc/shadow</i>, <b>adduser</b> automates a broader range of tasks. This includes creating home directories, copying skeleton files from <i>/etc/skel</i>, setting up default group memberships, and prompting for additional user information. Its design philosophy was to simplify user creation and ensure consistency. In contrast, Red Hat-based systems have historically relied more heavily on <b>useradd</b> for both interactive and scripted user account management.


title: SYNOPSIS
content:
<B>adguardhome</B> [<I>options</I>] [<I>command</I>]<BR><BR>Common usage examples:<BR><B>adguardhome</B> <I>--help</I><BR><B>adguardhome</B> <I>--version</I><BR><B>adguardhome</B> <I>--config /etc/adguardhome.yaml</I><BR><B>adguardhome</B> <I>--service install</I>


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the AdGuard Home version and exits.<br><br><b>--config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the YAML configuration file. Defaults to <I>AdGuardHome.yaml</I> in the working directory.<br><br><b>--work-dir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the working directory where data (logs, statistics, filter lists) is stored. Defaults to the directory where the executable is located.<br><br><b>--service <action></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages AdGuard Home as a system service. <I>Actions</I> include <I>install</I>, <I>uninstall</I>, <I>start</I>, <I>stop</I>, <I>restart</I>, and <I>status</I>.<br><br>


title: DESCRIPTION
content:
AdGuard Home is a network-wide software for blocking ads, tracking, and malware. It acts as a <I>DNS server</I> that reroutes DNS queries, filtering out unwanted domains. Unlike browser extensions, it protects <I>all devices</I> connected to your network without needing client-side software. This includes desktops, mobile phones, smart TVs, and IoT devices. It supports a wide range of DNS protocols such as <I>DNS-over-HTTPS (DoH)</I>, <I>DNS-over-TLS (DoT)</I>, <I>DNS-over-QUIC (DoQ)</I>, and <I>DNSCrypt</I>, enhancing privacy and security. Users can customize blocking lists, implement parental controls, view detailed query logs, and set up custom filtering rules through its intuitive web interface. It is an open-source, powerful, and easy-to-deploy solution for improving network security and user experience.


title: CAVEATS
content:
Requires a dedicated network port (typically 53 for DNS, 80/443 for web interface) which should not be used by other services.<BR>Misconfiguration can lead to network connectivity issues or unexpected blocking of legitimate content.<BR>Performance depends on the host machine's resources and the number of active filters.<BR>Relies on DNS blocking, which cannot block ads embedded directly within content or within non-DNS communication.


title: WEB INTERFACE (GUI)
content:
AdGuard Home provides a comprehensive web-based user interface (GUI) typically accessible on port 80 or 3000 (configurable). This GUI allows for easy configuration of DNS settings, filter lists, parental controls, viewing query logs and statistics, and managing various AdGuard Home features without direct command-line interaction after initial setup.


title: CONFIGURATION FILE
content:
The primary configuration of AdGuard Home is managed through a <I>YAML file</I> (e.g., <I>AdGuardHome.yaml</I>). This file defines listening interfaces, DNS server settings, upstream DNS servers, security settings, and paths to various data files, allowing for fine-grained control over its operation.


title: DNS PROTOCOLS SUPPORT
content:
A key feature of AdGuard Home is its extensive support for modern encrypted DNS protocols, including <I>DNS-over-HTTPS (DoH)</I>, <I>DNS-over-TLS (DoT)</I>, <I>DNS-over-QUIC (DoQ)</I>, and <I>DNSCrypt</I>. This allows it to communicate securely with upstream DNS servers, protecting privacy and preventing DNS manipulation.


title: HISTORY
content:
AdGuard Home is an open-source project developed by <I>AdGuard Software Ltd.</I> It was created to provide a robust, self-hosted, and network-wide ad-blocking solution, initially as an alternative to existing tools like Pi-hole, focusing on ease of use, a powerful web interface, and broader support for modern DNS protocols. Its development is active, with continuous updates and improvements driven by community feedback and AdGuard's expertise in ad-blocking technologies.


title: SYNOPSIS
content:
No standard synopsis available as <I>adig</I> is not a recognized Linux command. If you meant <I>dig</I>, its basic synopsis is:<br><br><b>dig</b> [<i>options</i>] [<i>@server</i>] [<i>name</i>] [<i>type</i>] [<i>class</i>]


title: PARAMETERS
content:
<b>N/A for adig</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No parameters available for <I>adig</I> as it is not a recognized command.<br><br><b>Common dig options (if intended):</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Below are common options for <I>dig</I>, assuming it was the intended command:<br><br><b><i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The domain name or hostname to look up (e.g., google.com).<br><br><b><i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The type of record to query (e.g., A, AAAA, MX, NS, SOA, TXT). Defaults to A record if not specified.<br><br><b><i>@server</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the DNS server to query instead of the default configured one (e.g., @8.8.8.8).<br><br><b><b>-x</b> <i>IP address</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a reverse DNS lookup (PTR record query) for the given IP address.<br><br><b><b>+short</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a concise output, showing only the answer portion of the query.<br><br><b><b>+trace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Traces the delegation path from the root name servers for the query, showing each step of the resolution.<br><br>


title: DESCRIPTION
content:
The command <I>adig</I> is not a standard or recognized command in most Linux distributions. It is highly probable that this is a typo for another common command, such as <I>dig</I> (Domain Information Groper), <I>ag</I> (The Silver Searcher), or <I>adis</I> (a debugging tool).<br><br>If the user intended to inquire about <I>dig</I>, it is a powerful and flexible command-line utility for querying DNS (Domain Name System) name servers. It performs DNS lookups and displays the answers that are returned from the name servers. It is commonly used by system administrators and network engineers for troubleshooting DNS issues, verifying DNS records, and gathering information about domains. Unlike <I>host</I> or <I>nslookup</I>, <I>dig</I> provides a more detailed and flexible output, making it the preferred tool for many advanced DNS tasks.


title: CAVEATS
content:
<I>adig</I> is not a standard Linux command. Attempting to execute it will likely result in a 'command not found' error unless a custom alias or script with that name has been defined on your system.


title: COMMON TYPO
content:
It is highly probable that <I>adig</I> is a typographical error for <I>dig</I>, which is a widely used and powerful command-line tool for DNS lookups.


title: CHECKING FOR CUSTOM ALIASES
content:
If you encounter <I>adig</I> in a script or documentation, it might refer to a custom alias or a user-defined function. You can check for aliases using <I>alias adig</I> or examine your shell's configuration files (e.g., .bashrc, .zshrc) for its definition.


title: HISTORY
content:
There is no documented history for a Linux command named <I>adig</I> as it does not exist as a standard utility. The utility <I>dig</I>, which is the most likely intended command, was developed as part of the BIND (Berkeley Internet Name Domain) tools by the Internet Systems Consortium (ISC) and has been widely used for DNS lookups since its inception, continually updated to support new DNS features and standards.


title: SEE ALSO
content:
If the intended command was <I>dig</I>:, <b>host</b>(1)<br>, <b>nslookup</b>(1)<br>, <b>ping</b>(8)<br>, <b>whois</b>(1)


title: SYNOPSIS
content:
<i><br><b>adscript</b>: Not a standard or recognized Linux command.<br>Therefore, a standard synopsis cannot be provided.</i>


title: DESCRIPTION
content:
The <b>adscript</b> command does not appear to be a standard utility or program found in common Linux distributions (e.g., Debian, Ubuntu, Fedora, RHEL, Arch Linux). Extensive searches of official manual pages, package repositories, and common command-line toolsets do not yield a definitive entry for <b>adscript</b>.<br><br>It is possible that this command is a custom script or alias created for a specific environment, an internal tool within a niche software project, a misremembered command, or a typo. Without a clear definition from an official source, its intended functionality, syntax, and parameters cannot be determined.<br><br>If <b>adscript</b> were to exist in a specific, non-standard context, its name might suggest a role related to administration scripts, active directory interactions, or potentially even advertising-related scripting, but this is purely speculative based on linguistic components.


title: CAVEATS
content:
Users should be aware that <b>adscript</b> is not a recognized command in standard Linux environments. Attempting to execute it will likely result in a 'command not found' error. If encountered, it most likely refers to a locally defined script, an application-specific utility not part of the common Linux toolchain, or a command from a highly specialized, non-mainstream system.


title: <I>POSSIBLE INTERPRETATIONS (SPECULATIVE)</I>
content:
Given the potential for <b>adscript</b> to be a custom or domain-specific command, its name could imply various functionalities:<br>1. <b>Ad</b>ministration <b>Script</b>: A script designed for system administration tasks.<br>2. <b>Ad</b>vertising <b>Script</b>: A tool for managing or interacting with advertising systems or data.<br>3. <b>Ad</b> (Active Directory) <b>Script</b>: A script used for interactions with Microsoft Active Directory services, potentially from a Linux client.<br>However, these are purely speculative and depend entirely on the specific, non-standard context in which such a command might be found.


title: HISTORY
content:
There is no documented history or development timeline for <b>adscript</b> as a standard Linux command, as it does not appear in official Linux project archives or distribution histories. Its non-existence in common repositories suggests it has not been part of mainstream Linux development.


title: DESCRIPTION
content:
The <b>adventure</b> command invokes the legendary Colossal Cave Adventure, one of the earliest and most influential text adventure games. Players navigate a vast, imagined cave system, solve puzzles, collect treasures, and avoid dangers by typing simple, two-word commands (e.g., <I>go north</I>, <I>take lamp</I>, <I>examine rock</I>). The game is renowned for pioneering many conventions of the interactive fiction genre, including inventory management, environmental interaction, and narrative progression through player choice. Originally written by Will Crowther and later expanded by Don Woods, it runs purely in the terminal, presenting descriptions of locations and events as text. Its enduring appeal lies in its imaginative world, challenging puzzles, and the nostalgic experience of a foundational piece of computer gaming history. It's a prime example of early interactive storytelling, offering hours of exploration and mental engagement without graphical interfaces.


title: CAVEATS
content:
This is a text-based game; it requires imaginative engagement and is not graphically intensive.<br>The command is typically not installed by default on most Linux distributions; it usually comes as part of the <I>bsdgames</I> or <I>games</I> package, which needs to be installed separately.<br>The game's parser for commands can be very specific, leading to frustrating moments if the exact verb-noun combination isn't used.<br>Saving game progress directly within the command line interface is generally not supported in the classic version; gameplay relies on single sessions or external terminal recording tools.


title: GAMEPLAY
content:
Gameplay primarily involves typing two-word commands (e.g., <I>go north</I>, <I>take key</I>, <I>light lamp</I>) to interact with the environment, explore locations, solve puzzles, and collect treasures. The game provides textual descriptions of your surroundings and the results of your actions.


title: INSTALLATION
content:
On most Debian/Ubuntu-based systems, you can install it using: <br><I>sudo apt install bsdgames</I><br>On Fedora/RHEL-based systems: <br><I>sudo dnf install bsd-games</I>


title: HISTORY
content:
<b>Colossal Cave Adventure</b> was originally created by Will Crowther in 1975-1976 on a PDP-10, inspired by his caving hobby. It was later significantly expanded by Don Woods in 1977, adding more puzzles, magic, and fantasy elements, which solidified its status as a seminal work. The game quickly spread via ARPANET, becoming a benchmark for early interactive fiction and inspiring an entire genre, including the highly successful Zork series and other adventure games. Its open source code led to numerous ports and variants across different computing platforms, ensuring its legacy as one of the most influential computer games ever developed.


title: PARAMETERS
content:
<b><b>-f</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output container format (e.g., 'aiff', 'caf', 'mp4f', 'wav').<br><br><b><b>-d</b> <i>&lt;data_format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output audio data format or codec (e.g., 'LEI16' for 16-bit little-endian PCM, 'aac ', 'mp3 ', 'flac', 'alac'). Note the space for some 4-char codes.<br><br><b><b>-r</b> <i>&lt;rate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output sample rate in Hz (e.g., 44100, 48000).<br><br><b><b>-c</b> <i>&lt;channel_layout&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of channels and their layout (e.g., 'mono', 'stereo', '5.1', '7.1').<br><br><b><b>-b</b> <i>&lt;bit_rate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For lossy codecs (like <i>AAC</i>, <i>MP3</i>), sets the target bit rate in bits per second (e.g., 192000).<br><br><b><b>-q</b> <i>&lt;quality&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For lossy codecs, controls the encoding quality (0-127, where 127 is highest quality).<br><br><b><b>-s</b> <i>&lt;sample_rate&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for <b>-r</b>, specifying the output sample rate.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the conversion process.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and usage syntax.<br><br>


title: DESCRIPTION
content:
The <b>afconvert</b> command is a powerful command-line utility primarily found on <i>macOS</i>, designed for converting audio files between various formats. It leverages <i>Apple's Core Audio</i> framework to provide robust capabilities for changing audio file containers (like <i>AIFF</i>, <i>WAV</i>, <i>CAF</i>, <i>M4A</i>) and encoding formats (such as <i>PCM</i>, <i>AAC</i>, <i>MP3</i>, <i>FLAC</i>, <i>ALAC</i>).<br><br>Users can specify precise output characteristics including sample rate, bit depth, channel layout, and encoding quality. While not a native <i>Linux</i> command, it is an essential tool for developers and users within the <i>Apple</i> ecosystem who need programmatic or batch audio conversion capabilities.


title: CAVEATS
content:
The <b>afconvert</b> command is <i>not a standard Linux utility</i>. It is part of <i>Apple's Core Audio Utility Kit</i> and is natively available only on <i>macOS</i> (and <i>iOS</i> development environments).<br><br>Attempting to run <b>afconvert</b> directly on most <i>Linux</i> distributions will result in a 'command not found' error. Users on <i>Linux</i> needing similar functionality should instead use native <i>Linux</i> tools like <b>ffmpeg</b> or <b>sox</b>.


title: <B>COMMON USAGE EXAMPLE</B>
content:
To convert an <i>AIFF</i> file to a <i>128 kbps AAC</i> file within an <i>M4A</i> container:<br><b>afconvert</b> <i>-f mp4f -d aac\  -b 128000 input.aiff output.m4a</i><br>Note the two spaces after '<i>aac</i>' in '<i>aac\  </i>' for the 4-char code, essential for correct parsing in some shells.


title: <B>UNDERSTANDING DATA FORMATS</B>
content:
Many data formats for <b>-d</b> are 4-character codes (e.g., '<i>aac </i>', '<i>mp3 </i>'). You can often find a full list in the <i>Core Audio</i> documentation or by using '<b>afconvert -h</b>' on a <i>macOS</i> system, which sometimes lists supported format codes.


title: <B>PLATFORM SPECIFICITY</B>
content:
Despite being queried in a <i>Linux</i> context, it is crucial to reiterate that <b>afconvert</b> is <i>macOS-exclusive</i>. It is not part of standard <i>Linux</i> distributions and cannot be run natively without a <i>macOS</i> environment or highly specialized emulation.


title: HISTORY
content:
<b>afconvert</b>'s history is deeply intertwined with <i>Apple's</i> development of its multimedia frameworks. It was introduced as part of the <i>Core Audio</i> framework, which debuted with <i>macOS 10.0 (Cheetah)</i> as <i>OS X</i>. As <i>Apple's</i> audio technologies evolved, so did <b>afconvert</b>, gaining support for new codecs (e.g., <i>AAC</i>, <i>ALAC</i>) and container formats. It has consistently served as the command-line interface for <i>Core Audio's</i> conversion capabilities, primarily for developers and power users within the <i>Apple</i> ecosystem.


title: SYNOPSIS
content:
<b>afmtodit</b> [ <i>-adgmn</i> ] [ <i>-D directory</i> ] [ <i>-k kerns</i> ] [ <i>-p path</i> ] [ <i>-t font</i> ] [ <i>file ...</i> ]


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <b>ligature</b> commands for all ligatures found in the <i>.afm</i> file.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output character widths in device units (default is thousands of units).<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not add <b>kern</b> commands for kerning pairs found in the <i>.afm</i> file.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <b>charwd</b> commands for all characters present in the <i>.afm</i> file.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not include <b>comment</b> commands in the output font description file.<br><br><b><b>-D</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the directory where the <b>groff</b> font description file should be placed (e.g., <i>devps</i>).<br><br><b><b>-k</b> <i>kerns</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum number of kerns to be output (default is 2000).<br><br><b><b>-p</b> <i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the PostScript font name to be included in the output (default is the base name of the <i>.afm</i> file).<br><br><b><b>-t</b> <i>font</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the <b>groff</b> font name for the output description file (default is the base name of the <i>.afm</i> file).<br><br><b><i>file ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input <i>.afm</i> files to be converted.<br><br>


title: DESCRIPTION
content:
<b>afmtodit</b> is a specialized utility program designed to convert Adobe Font Metrics (<i>.afm</i>) files into a format that can be understood and utilized by <b>ditroff</b> (device independent <b>troff</b>), specifically within the <b>groff</b> typesetting system.<br><br>Adobe Font Metrics files contain crucial information about Type 1 fonts, including character widths, kerning pairs, ligatures, and other typographic details. <b>groff</b> requires this metric data to accurately render text and ensure correct character spacing and positioning when using these fonts. By processing an <i>.afm</i> file, <b>afmtodit</b> generates a <b>groff</b> font description file, which is typically stored in a <b>groff</b> font directory (e.g., <i>/usr/share/groff/font/devps</i>).<br><br>This conversion is essential because <b>groff</b>'s internal font handling mechanism operates with a specific metric format, distinct from the raw <i>.afm</i> data. <b>afmtodit</b> enables users to integrate new PostScript Type 1 fonts into their <b>groff</b> documents, ensuring precise typesetting and high-quality output for various devices, most commonly PostScript.


title: CAVEATS
content:
<b>afmtodit</b> primarily supports PostScript Type 1 fonts through their associated <i>.afm</i> files. It does not directly handle TrueType (TTF) or OpenType (OTF) fonts unless they also come with a corresponding <i>.afm</i> file.<br><br>The generated font description files must be correctly placed within <b>groff</b>'s font search paths for <b>groff</b> to locate and use them. Incorrect placement will prevent <b>groff</b> from finding the font, leading to errors or fallback to a default font.


title: HISTORY
content:
<b>afmtodit</b> is an integral part of the <b>groff</b> (GNU <b>troff</b>) package, which is the GNU project's modern and extended re-implementation of the classic AT&T <b>troff</b> document formatting system. Developed to provide enhanced functionality and portability, <b>groff</b> needed a robust way to incorporate external fonts, particularly the widely used PostScript Type 1 fonts.<br><br>The development of <b>afmtodit</b> was crucial to enable <b>groff</b> to utilize these fonts by translating their standard Adobe Font Metrics (<i>.afm</i>) into <b>groff</b>'s internal font description format. This facilitated the integration of a vast array of commercially available and open-source Type 1 fonts into the <b>groff</b> typesetting workflow, significantly improving the quality and flexibility of document production, especially for PostScript output devices.


title: SYNOPSIS
content:
<b>ag</b> [<i>options</i>] [<i>pattern</i>] [<i>path</i>]<br><b>ag</b> [<i>options</i>] <b>-f</b> [<i>file1</i>] [<i>file2</i>] ...


title: PARAMETERS
content:
<b><i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The regular expression to search for. If omitted, <b>ag</b> reads from standard input.<br><br><b><i>path</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The directory or files to search. If omitted, <b>ag</b> searches the current directory recursively.<br><br><b><b>-i</b>, <b>--ignore-case</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignores case distinctions in patterns and data.<br><br><b><b>-w</b>, <b>--word-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the pattern to match only <i>whole words</i>.<br><br><b><b>-l</b>, <b>--files-with-matches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only the <i>names of files</i> containing matches, one per line.<br><br><b><b>-v</b>, <b>--invert-match</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the match; selects <i>non-matching lines</i>.<br><br><b><b>-C</b> <NUM>, <b>--context</b> <NUM></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <NUM> lines of <i>context</i> around matches.<br><br><b><b>--nocolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables <i>colorized output</i>.<br><br><b><b>--no-skip-vcs-ignores</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does <i>not skip files ignored</i> by Version Control Systems (e.g., .gitignore).<br><br><b><b>-g</b> <pattern></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for files whose names match the given <pattern> (regexp).<br><br>


title: DESCRIPTION
content:
<b>ag</b> (The Silver Searcher) is a command-line utility designed for searching source code. It emerged as a faster and more developer-friendly alternative to traditional `grep` for large codebases. Its primary design goal is speed, achieved by automatically skipping files irrelevant to code, such as those specified in <i>.gitignore</i> or <i>.hgignore</i>, and avoiding common binary file types. This focus on intelligent defaults makes it incredibly efficient for quick text searches within development projects. It supports powerful features including regular expressions, file type filtering, context display, and colorized output, significantly enhancing the developer's search experience.


title: CAVEATS
content:
While highly optimized for speed, <b>ag</b> can be more memory-intensive than <b>grep</b> for very large result sets. Its default behavior of ignoring VCS-ignored files and binary files is a feature, but users need to be aware of this default if a broader search is required.


title: SMART DEFAULTS
content:
<b>ag</b> automatically ignores files specified in <i>.gitignore</i>, <i>.hgignore</i>, and other VCS ignore files, as well as common binary file types. This intelligent filtering is a core reason for its speed and relevance to code search.


title: PERFORMANCE OPTIMIZATION
content:
Achieves its high performance through optimized C code, efficient file traversal, memory mapping, and skipping irrelevant files and directories, focusing solely on what's relevant to a programmer's search.


title: REGEX ENGINE
content:
Leverages PCRE (Perl Compatible Regular Expressions) for robust and powerful pattern matching capabilities, allowing complex search queries.


title: HISTORY
content:
<b>ag</b> (The Silver Searcher) was created by Andrew Gallant in 2012 as a faster alternative to <b>ack</b>, which itself aimed to improve upon <b>grep</b> for codebases. Its intelligent defaults and remarkable speed quickly made it a popular choice among developers for navigating and searching large programming projects, paving the way for even faster tools like <b>ripgrep</b>.


title: SYNOPSIS
content:
<b>agate</b> is a Python library and therefore does not have a direct command-line synopsis like typical Linux commands.<br><br>Its functionality is accessed by importing it into Python scripts:<br> <br> <i><code>import agate</code></i><br> <i><code>table = agate.Table.from_csv('data.csv')</code></i><br><br>For command-line operations, users often employ tools built upon <b>agate</b>, such as components of the <i>csvkit</i> suite, which expose <b>agate</b>'s power via commands like <i><code>csvlook</code></i> or <i><code>csvstat</code></i>.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;As a Python library, <b>agate</b> does not have command-line parameters or options in the manner of a standard Linux command. Its functionality is accessed through its API (Application Programming Interface) within Python scripts, where methods and functions accept arguments.<br><br>


title: DESCRIPTION
content:
<b>agate</b> is a powerful and opinionated Python library designed for data analysis, specifically focusing on structured data like CSV, Excel, and JSON files. Unlike traditional Linux commands that are standalone executables invoked directly from the shell (e.g., <i><code>ls</code></i>, <i><code>grep</code></i>), <b>agate</b> is typically imported and used within Python scripts. Its core philosophy emphasizes predictability, strong typing, and explicit schemas, aiming to provide a more robust and less error-prone experience for data manipulation than some other general-purpose data libraries. While it doesn't have a direct command-line interface itself, its capabilities are often leveraged by custom command-line tools built on top of it, most notably the popular <i>csvkit</i> suite, which uses <b>agate</b> as its data processing engine. Its primary applications include data journalism, reproducible research, and general-purpose tabular data cleaning and transformation.


title: CAVEATS
content:
<b>agate</b> is not a standard, pre-installed Linux command-line utility. It is a Python library that must be installed separately (e.g., via <i><code>pip install agate</code></i>). Users wishing to interact with its capabilities directly from the command line often utilize tools from the <i>csvkit</i> suite, which are built upon <b>agate</b>. Its primary interface is through Python programming, requiring familiarity with Python for full utilization. It is designed for structured data analysis rather than general text processing.


title: INSTALLATION
content:
To use <b>agate</b>, it must be installed using Python's package manager, <i>pip</i>: <br> <i><code>pip install agate</code></i> <br> It is generally recommended to install Python libraries within a virtual environment to manage project-specific dependencies.


title: PRIMARY USE CASES
content:
<b>agate</b> is primarily used for:<br> - Reading and writing various structured data formats (CSV, JSON, Excel, fixed-width files, etc.)<br> - Cleaning, transforming, and validating tabular data programmatically<br> - Performing aggregations, calculations, and statistical analyses<br> - Enabling reproducible data analysis pipelines within Python scripts<br> - Serving as the foundational data engine for command-line tools like those in <i>csvkit</i>.


title: HISTORY
content:
<b>agate</b> was created by Christopher Groskopf, a data journalist, with the goal of providing a robust and predictable library for data analysis, especially within reproducible data journalism workflows. It was designed to address some of the complexities and potential pitfalls encountered when using other data analysis tools like <i>pandas</i> for specific tasks, emphasizing strong typing and clear data schemas. It gained prominence through its integration as the core data engine for the popular <i>csvkit</i> suite of command-line tools, allowing its powerful data handling capabilities to be exposed through convenient shell commands.


title: SYNOPSIS
content:
<b>age-keygen</b> [<b>-o</b> <I>output_file</I>]<br><b>age-keygen</b> [<b>--output</b> <I>output_file</I>]<br><b>age-keygen</b> [<b>--help</b>]<br><b>age-keygen</b> [<b>--version</b>]


title: PARAMETERS
content:
<b>-o <I>output_file</I>, --output <I>output_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated key to the specified <I>output_file</I> instead of standard output. It is highly recommended to use this option and ensure the file permissions are set securely (e.g., <I>chmod 600</I>).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise help message detailing command usage and options.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <I>age-keygen</I> utility.<br><br>


title: DESCRIPTION
content:
The <b>age-keygen</b> command is an essential utility within the <I>age</I> encryption tool suite. Its primary function is to generate a new <I>age</I> secret key (private key) along with its corresponding public key. This pair is fundamental for asymmetric encryption with <I>age</I>.<br><br>When executed, <b>age-keygen</b> outputs the private key to standard output by default, along with its associated public key, which is prefixed with "# public key:". The private key, starting with "AGE-SECRET-KEY-1", must be kept absolutely confidential and secure, as it is required to decrypt any data encrypted using its corresponding public key. The public key, starting with "age1", can be freely shared and is used by others to encrypt data for the private key's owner. This command simplifies the process of establishing new identities for secure data exchange using the <I>age</I> file encryption format.


title: CAVEATS
content:
By default, <b>age-keygen</b> generates a raw private key without any passphrase protection. If you wish to protect your private key with a passphrase, you will need to manually encrypt the generated key file using <I>age</I> or another suitable tool. Always ensure the generated private key file has strict file permissions (e.g., <I>chmod 600</I>) to prevent unauthorized access. Mismanagement of the private key can compromise the security of all data encrypted with its corresponding public key.


title: STANDARD OUTPUT AND REDIRECTION
content:
When the <B>-o</B> or <B>--output</B> option is not used, <b>age-keygen</b> prints the private key to standard output. It's common practice to redirect this output to a file, for example: <I>age-keygen > ~/.config/age/keys.txt</I>. This file should then be secured with appropriate file permissions.


title: KEY FORMATS
content:
The generated private key follows the <I>age</I> secret key format, starting with <I>AGE-SECRET-KEY-1</I>. The public key, which is commented out in the output, starts with <I>age1</I>. Both formats are specifically designed for the <I>age</I> encryption system.


title: USAGE IN ENCRYPTION WORKFLOW
content:
After generating a key pair with <b>age-keygen</b>, the public key is distributed to parties who need to encrypt data for you. They use this public key with the <I>age</I> command (e.g., <I>age -r age1... &lt; input.txt &gt; encrypted.age</I>). You then use your private key with the <I>age</I> command to decrypt the data (e.g., <I>age -i ~/.config/age/keys.txt &lt; encrypted.age &gt; decrypted.txt</I>).


title: HISTORY
content:
The <b>age-keygen</b> utility is an integral part of the <I>age</I> encryption system, which was developed by Filippo Valsorda, a Google engineer, and first publicly released around 2020. <I>age</I> was designed as a modern, simple, and secure alternative to more complex encryption tools like GnuPG, focusing on ease of use and robust defaults. <b>age-keygen</b> provides the necessary functionality to generate the cryptographic identities (keys) fundamental to the <I>age</I> ecosystem, embodying the project's goal of secure and accessible encryption.


title: PARAMETERS
content:
<b><i>port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the TTY device file (e.g., <i>ttyS0</i> for a serial port or <i>tty1</i> for a virtual console), usually relative to <i>/dev/</i>.<br><br><b><i>baud_rate</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The initial baud rate or a comma-separated list of baud rates (e.g., <i>9600,19200,38400</i>) that <i><b>agetty</b></i> should attempt to use. A value of <i>0</i> signifies autobauding across all common rates.<br><br><b>[<i>termtype</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the terminal type to be set for the connection (e.g., <i>vt100</i>, <i>linux</i>). Defaults to <i>vt100</i> if not specified.<br><br><b><i>-h, --flow-control</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables hardware (RTS/CTS) flow control on the specified TTY port, essential for reliable serial communication.<br><br><b><i>-L, --local-enable</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>CLOCAL</i> flag for the tty, indicating a local connection that doesn't use modem control lines, preventing the system from waiting for a carrier detect signal.<br><br><b><i>-t, --timeout &lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a timeout in seconds. If no login name is entered within this period, <i><b>agetty</b></i> exits, effectively closing the connection.<br><br><b><i>-a, --autologin &lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically logs in the specified <i>user</i> without prompting for a login name. This is often used for dedicated console access or embedded systems.<br><br><b><i>-n, --skip-login</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not prompt for a login name; instead, it immediately invokes the <i>login</i> program, expecting <i>login</i> itself to handle user identification.<br><br><b><i>-i, --noissue</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of the system welcome message from <i>/etc/issue</i> before the login prompt.<br><br><b><i>-I, --init-string &lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends an initial string to the TTY device immediately after opening it. Useful for sending AT commands to modems or initializing specific terminal features.<br><br>


title: DESCRIPTION
content:
<i><b>agetty</b></i> is an alternative to the traditional <i>getty</i> program, primarily used to set up terminal lines for user login. Its standout feature is 'autobauding,' which means it can automatically detect the baud rate of an incoming connection, making it highly useful for serial console connections, modems, and other variable-speed serial devices.<br><br>When invoked, <i><b>agetty</b></i> opens a specified TTY (Teletypewriter) port, initializes its settings (like baud rate, character processing, flow control), displays the contents of <i>/etc/issue</i> (the system welcome message), and then prompts the user for a login name. Once a login name is entered, <i><b>agetty</b></i> typically invokes the <i>/bin/login</i> command, passing the entered username to it. The <i>login</i> program then handles password verification and sets up the user's session.<br><br>Unlike <i>getty</i>, which usually requires a fixed baud rate to be specified, <i><b>agetty</b></i> can cycle through a list of common baud rates until it detects a valid input, simplifying configuration for diverse serial connections. It is commonly started by <i>init</i> (on older systems) or more frequently by <i>systemd</i> (via <i>getty@.service</i> or <i>serial-getty@.service</i> unit files) to manage login prompts on virtual consoles and serial ports.


title: CAVEATS
content:
<i><b>agetty</b></i> is primarily designed for serial line login and virtual consoles. While it can be used on any TTY, its autobauding feature is most relevant for serial connections. Permissions on the TTY device file are critical; <i><b>agetty</b></i> must have appropriate read/write access. Misconfiguration of baud rates or flow control can lead to garbled output or unresponsive terminals.


title: INTEGRATION WITH SYSTEMD
content:
On modern Linux systems using <i>systemd</i>, <i><b>agetty</b></i> is usually invoked by <i>systemd</i>'s <i>getty@.service</i> (for virtual consoles) or <i>serial-getty@.service</i> (for serial ports) unit templates. These unit files automate the process of starting <i><b>agetty</b></i> on specified TTYs, managing their lifecycle, and ensuring proper terminal setup for login sessions. The <i>systemd-getty-generator</i> is responsible for creating these service units dynamically based on system configuration.


title: THE <I>/ETC/ISSUE</I> FILE
content:
Before presenting the login prompt, <i><b>agetty</b></i> reads and displays the contents of the <i>/etc/issue</i> file. This file typically contains a short system description, warning messages, or legal disclaimers. Administrators can customize this file to provide information or warnings to users before they log in. The <i>--noissue</i> option can be used to prevent this display.


title: HISTORY
content:
<i><b>agetty</b></i> was developed as an improved alternative to the traditional <i>getty</i> utility, specifically addressing the need for automatic baud rate detection on serial lines. This capability was crucial for systems connecting to a variety of serial devices, such as modems with unknown or changing speeds, and for providing a more robust serial console experience. It became part of the widely used <i>util-linux</i> package, ensuring its presence across many Linux distributions. Its role has adapted over time, particularly with the shift from traditional <i>SysVinit</i> to <i>systemd</i>, which now typically manages <i><b>agetty</b></i> instances.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Equivalent to <I>-v -t ANY</I>. Displays all available DNS records (A, AAAA, MX, NS, SOA, etc.) for a given name.<br><br><b>-c <i>class</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the query class. The default and most common class is <I>IN</I> (Internet). Other classes like <I>CH</I> (Chaosnet) or <I>HS</I> (Hesiod) are less common.<br><br><b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check consistency. This option attempts to compare SOA records from different authoritative servers for the zone to identify inconsistencies.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debugging output. Provides more detailed information about the query process and DNS responses.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all hosts in a domain by attempting a zone transfer (AXFR). This operation is often restricted by DNS server configurations for security reasons.<br><br><b>-N <i>ndots</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of dots that must appear in <I>name</I> for it to be considered an absolute name. Used in conjunction with the resolver's search path configuration.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a non-recursive query. The queried server will return whatever information it possesses without attempting to query other DNS servers.<br><br><b>-R <i>number</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the number of retries for UDP queries (default is 1). Specifies how many times <B>host</B> should attempt to re-send a query if no response is received.<br><br><b>-s <i>server</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the DNS server to query. This can be an IP address or a hostname. If not specified, the system's default DNS servers (from <I>/etc/resolv.conf</I>) are used.<br><br><b>-t <i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the query type. Common types include A (IPv4 address), AAAA (IPv6 address), MX (mail exchange), NS (name server), SOA (start of authority), TXT (text), SRV (service record), CNAME (canonical name), PTR (pointer for reverse lookups), or ANY (all records).<br><br><b>-T</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use TCP mode for queries. This is useful for large responses that might be truncated over UDP, such as zone transfers or large records.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, displaying more details about the query, response, and name server information.<br><br><b>-W <i>wait</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the wait time (timeout) in seconds for a reply (default is 5 seconds). Specifies how long <B>host</B> will wait for a response before retrying or failing.<br><br><b>-w</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait forever for a reply. This disables the query timeout, causing <B>host</B> to wait indefinitely for a response.<br><br><b>-4</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <B>host</B> to use IPv4 only for sending queries and resolving addresses.<br><br><b>-6</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force <B>host</B> to use IPv6 only for sending queries and resolving addresses.<br><br>


title: DESCRIPTION
content:
The <B>host</B> command is a simple command-line utility used for performing DNS (Domain Name System) lookups. Its primary function is to translate hostnames to IP addresses and vice-versa, but it can also retrieve various other DNS record types such as NS (Name Server), MX (Mail Exchange), SOA (Start of Authority), SRV (Service Record), and more.<BR><BR>It is part of the <I>bind-utils</I> (or <I>bind9-host</I> on Debian/Ubuntu) package and is a standard tool used for quick network diagnostics, verifying DNS configurations, and for scripting. Compared to <B>ping</B>, <B>host</B> provides more detailed information specifically about hostname resolution, and it is often preferred over the older <B>nslookup</B> command for automated tasks and scripting due to its more consistent and parseable output format.


title: CAVEATS
content:
The exact output format of <B>host</B> can sometimes vary slightly between different versions of the BIND utilities package across various Linux distributions.<BR><BR>The <I>-l</I> (zone transfer) option very frequently fails in practice on public or production DNS servers, as zone transfers (AXFR) are commonly disabled due to security concerns. For more advanced or in-depth DNS troubleshooting, particularly when tracing recursive query paths or examining detailed DNS packet information, the <B>dig</B> command typically offers superior capabilities and control.


title: CLARIFICATION: <I>AHOST</I> VS <I>HOST</I>
content:
The command <B>ahost</B> is not a standard, widely recognized Linux command found in common distributions. This analysis describes the functionalities and usage of the common DNS lookup utility <B>host</B>, which is a standard component of the BIND utilities package available on virtually all Linux and Unix-like operating systems.<BR><BR>It is highly probable that <B>ahost</B> on your system is either a custom script, an alias configured to execute <B>host</B>, or a command specific to a particular specialized environment or application. Always verify the actual command's behavior and refer to its specific documentation if <B>ahost</B> is present on your system.


title: HISTORY
content:
The <B>host</B> command is an integral part of the BIND (Berkeley Internet Name Domain) suite, which was originally developed at the University of California, Berkeley. It was created as a simpler, more robust, and scripting-friendly alternative to the older <B>nslookup</B> utility.<BR><BR><B>nslookup</B> was often criticized for its less consistent output and interactive-by-default behavior, making it cumbersome for automation. <B>host</B>, along with <B>dig</B>, was designed to address these shortcomings, providing predictable output and a command-line interface better suited for shell scripting. Its development has progressed alongside the BIND DNS server software, integrating improvements in DNS protocol support, performance, and security features, establishing it as a ubiquitous tool for DNS diagnostics on Unix-like systems.


title: SYNOPSIS
content:
<i><br><b>aider</b> [<I>options</I>] [<I>file_or_directory</I> ...]<br><br><b>Examples:</b><br><b>aider</b> <I>main.py</I> <I>tests/test_main.py</I><br><b>aider</b> <I>--diff</I> <I>my_feature_branch</I><br><b>aider</b> <I>--model</I> <I>gpt-4o</I> <I>src/</I></i>


title: PARAMETERS
content:
<b><I>file_or_directory ...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies one or more files or directories for Aider to analyze and edit.</i><br><br><b>-m MODEL, --model MODEL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Selects the AI model to use (e.g., gpt-4o, gpt-3.5-turbo).</i><br><br><b>--api-key API_KEY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the API key for the chosen Large Language Model provider.</i><br><br><b>--map-tokens MAP_TOKENS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Controls the maximum number of tokens for mapping source files into the LLM's context.</i><br><br><b>--no-map</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables mapping source files to the LLM, reducing context but saving tokens.</i><br><br><b>--diff DIFF_BRANCH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a diff against a specified Git branch to inform the AI's editing process.</i><br><br><b>--message MESSAGE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides an initial prompt or instruction to the AI, allowing non-interactive use.</i><br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Simulates the AI's changes without actually writing them to disk or committing.</i><br><br><b>--no-auto-commit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents Aider from automatically committing changes to Git.</i><br><br><b>--yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Answers 'yes' to all prompts automatically, enabling non-interactive execution.</i><br><br><b>--dir DIR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the working directory for the Aider session.</i><br><br><b>--root ROOT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the root directory of the project, typically the Git repository root.</i><br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables verbose logging for detailed output and debugging information.</i><br><br>


title: DESCRIPTION
content:
<i><br><b>Aider</b> is an innovative <b>AI pair programming assistant</b> designed to enhance your coding workflow directly from the command line. Unlike simple code completion tools, Aider functions as an interactive chat interface where you can describe your coding tasks, ask questions, or request changes.<br><br>It understands the context of the files you provide, allowing it to intelligently modify existing code, generate new functions, fix bugs, or refactor sections of your project. A core feature of Aider is its deep integration with <b>Git</b>. When Aider makes changes to your files, it automatically stages and commits them, creating clean, descriptive commits that capture the AI's contributions. This ensures that your version control history remains clear and manageable. It supports various Large Language Models (LLMs) and is highly configurable, making it a powerful tool for developers looking to leverage AI in their day-to-day coding tasks, from prototyping to debugging complex systems.</i>


title: CAVEATS
content:
<i><br>As an AI-driven tool, <b>Aider</b> is subject to the limitations of Large Language Models (LLMs). This includes potential for <b>hallucinations</b> (generating incorrect or nonsensical code), reliance on the quality of the prompt and context provided, and the need for human review of its suggestions. It requires an <b>active internet connection</b> and an <b>API key</b> from a supported LLM provider (e.g., OpenAI, Anthropic), which typically incurs <b>usage costs</b> based on token consumption. While Aider integrates well with Git, users should still be mindful of the changes it makes and utilize Git's capabilities for review and rollback.</i>


title: INSTALLATION AND SETUP
content:
<i><b>Aider</b> is typically installed via Python's package manager, <b>pip</b>:<br><code>pip install aider-chat</code><br>Before use, you usually need to set an API key for your chosen Large Language Model provider (e.g., OpenAI) via an environment variable (e.g., <code>export OPENAI_API_KEY='your_key_here'</code>) or using the <code>--api-key</code> option.</i>


title: INTERACTIVE MODE
content:
<i>When invoked without the <code>--message</code> option, <b>Aider</b> enters an interactive chat mode. Here, you can converse with the AI, provide new instructions, ask for explanations, or request further modifications to the files. Type <code>/help</code> for in-chat commands or <code>/exit</code> to quit.</i>


title: HISTORY
content:
<i><br><b>Aider</b> emerged in the wake of significant advancements in Large Language Models (LLMs), particularly with the widespread adoption of models like GPT-3.5 and GPT-4. Developed by Michael Green, it was designed to bridge the gap between powerful conversational AI and practical, direct code manipulation within a developer's existing workflow. Its initial releases focused on robust Git integration and an intuitive chat interface, distinguishing it from browser-based AI coding tools. Since its inception, Aider has seen rapid development, continually adding support for new LLMs, enhancing its context awareness, and refining its ability to make precise, diff-based edits, solidifying its position as a leading command-line AI pair programming tool.</i>


title: PARAMETERS
content:
<b>-a <I>bssid</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the BSSID (MAC address) of the fake AP.<br><br><b>-e <I>essid</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the ESSID (network name) of the fake AP. Use '-e' with no argument for hidden ESSID.<br><br><b>-c <I>channel</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the channel for the fake AP.<br><br><b>-w <I>wep key</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable WEP encryption for the fake AP using the specified key.<br><br><b>-W <I>0/1</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable (1) or disable (0) WPA handshake capture. Useful for forcing clients to reauthenticate.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable Shared Key authentication capture. Requires a client to associate.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable LEAP authentication capture.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deauthenticate clients that associate with the fake AP. Can be used to force reassociation.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable a fake WPA response. If a client attempts to associate, it will be prompted for WPA/WPA2.<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable Man-in-the-Middle (MITM) attacks. Requires another instance for packet forwarding.<br><br><b>-0</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Send deauthentication packets to all clients in range, forcing them to reconnect to your fake AP.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable ARP request replay. Repeats captured ARP requests.<br><br><b>--randomize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Randomize the MAC address and ESSID of the fake AP to avoid detection.<br><br><b>--ivs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create an IVS file for WEP cracking instead of a PCAP file.<br><br><b>--wps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable WPS (Wi-Fi Protected Setup) support on the fake AP.<br><br><b>--wps-pin <I>pin</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a WPS PIN for the fake AP.<br><br><b>--eap-file <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file containing EAP authentication credentials (e.g., username/password).<br><br>


title: DESCRIPTION
content:
<i>airbase-ng</i> is a powerful and versatile tool from the <b>aircrack-ng</b> suite, designed to simulate an access point (AP) and perform various wireless network attacks. Its primary functionalities include creating honeypots or 'Evil Twin' APs, capturing WEP/WPA/WPA2 handshakes by forcing client reassociations, and performing packet injection. It supports advanced features like authentication simulation (Open, Shared Key, LEAP), ARP request replay, and the ability to bridge network traffic through a virtual interface (e.g., <i>at0</i>). This allows for sophisticated Man-in-the-Middle (MITM) attacks, client deauthentication, and other forms of traffic manipulation, making it an essential tool for wireless security auditing and penetration testing.


title: CAVEATS
content:
Using <b>airbase-ng</b> requires a wireless adapter capable of monitor mode and packet injection. The network interface must be manually put into monitor mode (e.g., using <b>airmon-ng</b>) before running the command. It requires root privileges. Always ensure you have explicit permission before performing any wireless security testing, as unauthorized use can be illegal.


title: VIRTUAL INTERFACE (AT0)
content:
When <b>airbase-ng</b> starts, it often creates a new virtual interface, typically named <i>at0</i> (or <i>tap0</i> on some systems). This interface acts as a TAP interface, allowing you to bridge network traffic to and from clients connected to the fake AP. You can then assign an IP address to <i>at0</i>, run a DHCP server, or use it for routing, enabling advanced attacks like DNS spoofing or serving malicious content to connected clients.


title: PACKET INJECTION CAPABILITIES
content:
Beyond simply simulating an AP, <b>airbase-ng</b> has powerful packet injection capabilities. It can replay captured packets, inject custom packets, and perform various forms of frame manipulation. This makes it a versatile tool for both offensive and defensive wireless security operations, allowing for specific traffic generation and analysis.


title: HISTORY
content:
<b>airbase-ng</b> is a core component of the <b>aircrack-ng</b> suite, a renowned collection of tools for wireless security auditing. It evolved from earlier standalone tools and was integrated into the suite to provide comprehensive functionalities for network analysis, packet injection, and AP simulation. Its development is community-driven, with continuous updates to address new wireless technologies and vulnerabilities.


title: PARAMETERS
content:
<b><b>-a</b> &lt;<i>attack_mode</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the WEP attack mode. Common values include <b>1</b> (PTW attack), <b>2</b> (KoreK attack), etc.<br><br><b><b>-b</b> &lt;<i>BSSID</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets a specific access point by its BSSID (MAC address).<br><br><b><b>-e</b> &lt;<i>ESSID</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Targets a specific network by its ESSID (network name).<br><br><b><b>-w</b> &lt;<i>wordlist</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a dictionary file to use for WPA/WPA2-PSK cracking. This file contains potential passphrases.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables quiet mode, suppressing non-essential output.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's usage information and available options.<br><br>


title: DESCRIPTION
content:
<i>aircrack-ng</i> is a powerful and versatile suite of tools primarily used for auditing wireless network security. While the <i>aircrack-ng</i> command itself specifically focuses on cracking WEP and WPA/WPA2-PSK keys, the broader <i>aircrack-ng</i> suite encompasses various utilities like <i>airmon-ng</i> (for putting wireless adapters into monitor mode), <i>airodump-ng</i> (for capturing raw 802.11 frames), <i>aireplay-ng</i> (for injecting/replaying frames), and <i>airdecap-ng</i> (for decrypting WEP/WPA capture files).<br><br>The core <i>aircrack-ng</i> program works by taking a packet capture file (typically in .cap format), often generated by <i>airodump-ng</i>, and attempting to recover the network's pre-shared key. For WEP, it employs statistical attacks (such as the PTW attack) to deduce the key. For WPA/WPA2-PSK, it performs dictionary attacks against captured four-way handshake packets to find the passphrase. It is widely utilized by penetration testers and security researchers to assess the robustness of wireless network security implementations.


title: CAVEATS
content:
<b>Hardware Requirements</b>: Requires a compatible wireless adapter capable of monitor mode and packet injection for effective use of the full <i>aircrack-ng</i> suite.<br><b>Dictionary Attack Dependency</b>: WPA/WPA2-PSK cracking is a dictionary attack; its success hinges entirely on the quality and comprehensiveness of the provided wordlist.<br><b>Legality and Ethics</b>: Using <i>aircrack-ng</i> on networks without explicit permission from the owner is illegal in many jurisdictions and highly unethical. It should only be used for legitimate security auditing on networks you own or have authorization to test.<br><b>Computational Intensity</b>: WPA/WPA2 cracking can be very computationally intensive, especially for long passphrases and large dictionary files, often requiring significant CPU or GPU resources.


title: A SUITE OF TOOLS
content:
It's crucial to understand that <i>aircrack-ng</i> is not merely a single command but an integrated suite of tools. The various components (e.g., <i>airmon-ng</i>, <i>airodump-ng</i>, <i>aireplay-ng</i>) are designed to work together to perform comprehensive wireless network security assessments, from capturing packets to cracking keys.


title: SUPPORTED KEY TYPES
content:
The <i>aircrack-ng</i> command can successfully crack WEP keys (using various attacks like PTW, KoreK, etc.) and WPA-PSK / WPA2-PSK keys (via dictionary attacks against captured 4-way handshakes).


title: HISTORY
content:
The <i>aircrack-ng</i> project evolved from the original <i>aircrack</i> program, which itself was a fork of earlier tools like <i>dweputils</i> and <i>wepattack</i>. The '<b>-ng</b>' suffix (Next Generation) signifies a significant overhaul and enhancement of the original suite. This transition aimed to combine and improve various wireless auditing tools into a cohesive suite, offering better performance, more advanced attack methods (notably the PTW WEP attack and more robust WPA/WPA2 cracking), and broader hardware compatibility. Since its inception, <i>aircrack-ng</i> has become a de facto standard in the cybersecurity community for wireless network penetration testing and auditing, constantly being updated to address new wireless security protocols and vulnerabilities.


title: SYNOPSIS
content:
<b>airdecap-ng</b> [<i>options</i>] <i>&lt;capture file&gt;</i><br><b>airdecap-ng</b> [<i>-e &lt;essid&gt;</i>] [<i>-i &lt;bssid&gt;</i>] [<i>-p &lt;passphrase&gt;</i> | <i>-k &lt;wep key&gt;</i> | <i>-w &lt;pmk&gt;</i> | <i>-r &lt;raw key&gt;</i>] [<i>-o &lt;output file&gt;</i>] <i>&lt;input file&gt;</i>


title: PARAMETERS
content:
<b><i>&lt;capture file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The input <i>.cap</i> or <i>.pcap</i> file containing encrypted wireless traffic.<br><br><b><b>-l</b>, <b>--learn-key</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Learn WPA/WPA2 key from a key file or PMK file (advanced use).<br><br><b><b>-e</b> <i>&lt;essid&gt;</i>, <b>--essid</b> <i>&lt;essid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the ESSID (network name) to filter and decrypt traffic for. Mandatory for WPA/WPA2 decryption.<br><br><b><b>-i</b> <i>&lt;bssid&gt;</i>, <b>--bssid</b> <i>&lt;bssid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the BSSID (AP MAC address) to filter and decrypt traffic for. Recommended for WPA/WPA2 decryption.<br><br><b><b>-p</b> <i>&lt;passphrase&gt;</i>, <b>--key</b> <i>&lt;passphrase&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The WPA/WPA2 passphrase (WPA-PSK) for decryption.<br><br><b><b>-k</b> <i>&lt;hex key&gt;</i>, <b>--wep-key</b> <i>&lt;hex key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The WEP key in hexadecimal format for decryption.<br><br><b><b>-w</b> <i>&lt;pmk&gt;</i>, <b>--wpa-key</b> <i>&lt;pmk&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The WPA/WPA2 PMK (Pairwise Master Key) in hexadecimal for decryption.<br><br><b><b>-r</b> <i>&lt;raw key&gt;</i>, <b>--raw-key</b> <i>&lt;raw key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a raw key format (typically for expert or specific scenarios).<br><br><b><b>-o</b> <i>&lt;file&gt;</i>, <b>--output</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output file name for the decrypted capture. If not specified, it appends '-dec' to the input filename.<br><br><b><b>-u</b>, <b>--skip-wpa</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip decryption of WPA/WPA2 traffic.<br><br><b><b>-s</b>, <b>--skip-wep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip decryption of WEP traffic.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress non-essential output during operation.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the decryption process.<br><br><b><b>-H</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br>


title: DESCRIPTION
content:
<b>airdecap-ng</b> is a utility from the <b>Aircrack-ng</b> suite designed to decrypt wireless capture files (e.g., .cap, .pcap) that contain WEP, WPA, or WPA2 encrypted traffic. Unlike <b>aircrack-ng</b> which focuses on cracking encryption keys, <b>airdecap-ng</b> assumes you already possess the correct key or passphrase. Its primary function is to transform an encrypted capture file into a decrypted one, allowing tools like Wireshark to analyze the underlying network protocols (e.g., HTTP, DNS, FTP) that were previously obscured.<br><br>This is particularly useful for analyzing network traffic after successful key recovery or when analyzing your own encrypted wireless network. It requires the original capture file and the corresponding WEP key, WPA/WPA2 passphrase, or the Pairwise Master Key (PMK) to perform the decryption. The output is a standard pcap file, which can then be opened and inspected by any packet analyzer.


title: CAVEATS
content:
<b>airdecap-ng</b> is not a cracking tool; it requires the correct encryption key or passphrase to function. If the key is incorrect or not present, decryption will fail or result in corrupted data. For WPA/WPA2 decryption, a complete 4-way handshake between the client and AP must be present in the capture file, along with sufficient data packets. The tool decrypts only the wireless (802.11) layer; higher-layer encryption (e.g., VPN, SSL/TLS) will remain encrypted. Some fragmented packets or unusual network conditions might hinder successful decryption of all traffic.


title: USAGE NOTES
content:
After decryption, the output <i>.pcap</i> file can be opened with network protocol analyzers like <b>Wireshark</b> to inspect the original unencrypted network traffic. This allows for deep packet inspection, debugging network issues, or analyzing application-layer protocols. Ensure the capture file contains the necessary handshake (for WPA/WPA2) and a sufficient amount of data traffic for meaningful analysis.


title: HISTORY
content:
<b>airdecap-ng</b> is an integral part of the <b>Aircrack-ng</b> suite, a comprehensive set of tools for auditing wireless networks. The suite itself originated from the older <b>Aircrack</b> and <b>Airodump</b> projects, which primarily focused on WEP. As wireless security evolved to WPA and WPA2, the tools were significantly expanded and refactored into the '-ng' (Next Generation) version. <b>airdecap-ng</b> was specifically developed to handle the post-capture decryption needs for these newer standards, complementing the key recovery capabilities of <b>aircrack-ng</b> and providing a crucial step for network analysis.


title: SEE ALSO
content:
<b>aircrack-ng</b>(1): Wireless WEP/WPA/WPA2 key cracking program., <b>airodump-ng</b>(1): Packet sniffer/data capture tool for wireless networks., <b>aireplay-ng</b>(1): Packet injector/traffic generator for wireless networks., <b>wireshark</b>(1): Network protocol analyzer for viewing decrypted traffic.


title: SYNOPSIS
content:
<i><b>aireplay-ng</b> &lt;options&gt; &lt;replay interface&gt;</i><br><i><b>Common usage examples:</b></i><br><i><b>aireplay-ng</b> <b>--deauth</b> &lt;count&gt; <b>-a</b> &lt;AP MAC&gt; <b>-c</b> &lt;Client MAC&gt; &lt;interface&gt;</i><br><i><b>aireplay-ng</b> <b>--arpreplay</b> <b>-b</b> &lt;AP MAC&gt; <b>-h</b> &lt;Source MAC&gt; &lt;interface&gt;</i>


title: PARAMETERS
content:
<b><i>--deauth &lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Deauthentication attack. Disconnects clients from an AP. Count specifies the number of deauths. Use 0 for continuous.</i><br><br><b><i>-0 &lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shorthand for deauthentication attack. Same as <b>--deauth</b>.</i><br><br><b><i>-a &lt;bssid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the Access Point (AP) BSSID (MAC address) to target.</i><br><br><b><i>-c &lt;dmac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the client MAC address to target for attacks.</i><br><br><b><i>-D</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disassociation attack. Similar to deauthentication but for specific clients.</i><br><br><b><i>-H &lt;smac&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the source MAC address for sent packets.</i><br><br><b><i>--arpreplay</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Performs the standard ARP-request replay attack to generate new IVs.</i><br><br><b><i>-1 &lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Fake authentication attack. Used to associate with an AP. Count is reassociation interval.</i><br><br><b><i>-3</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>ARP request replay attack. Replays captured ARP requests to generate traffic.</i><br><br><b><i>-4</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Chopchop attack. Recovers WEP key by analyzing packet fragments.</i><br><br><b><i>-5</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Fragmentation attack. Recovers PRGA (Pseudo-Random Generation Algorithm) for WEP by exploiting fragment reassembly.</i><br><br><b><i>-x &lt;pkts/sec&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the replay speed in packets per second.</i><br><br><b><i>-r &lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reads packets from a pcap file for replaying.</i><br><br><b><i>-y &lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Reads PRGA (keystream) from a file for interactive attacks.</i><br><br><b><i>--ignore-negative-one</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Ignores the "fixed channel" error, useful for some drivers.</i><br><br>


title: DESCRIPTION
content:
<i><b>aireplay-ng</b> is a crucial tool within the <b>Aircrack-ng</b> suite, primarily designed for injecting and re-injecting wireless frames. Its main purpose is to generate traffic and accelerate the capture of Initialization Vectors (IVs) for WEP cracking, or to facilitate WPA/WPA2 handshake captures. It can perform various types of attacks, including deauthentication attacks to disconnect clients from an access point, ARP request replay attacks to generate IVs, and chopchop or fragmentation attacks to recover WEP keys. This utility is indispensable for active wireless security auditing, allowing users to interact with Wi-Fi networks in a controlled manner to test their vulnerabilities. It requires a wireless adapter capable of monitor mode and packet injection.</i>


title: CAVEATS
content:
<i><b>aireplay-ng</b> requires a wireless adapter capable of monitor mode and packet injection. Improper or unauthorized use of this tool can be illegal and may disrupt network services. It should only be used on networks for which you have explicit permission to test.</i>


title: <I>ATTACK TYPES</I>
content:
<i><b>aireplay-ng</b> offers several attack modes, indicated by a single digit (e.g., <b>-0</b> for deauthentication). Each mode serves a specific purpose, from generating IVs for WEP cracking (<b>-3</b>, <b>-4</b>, <b>-5</b>) to forcing WPA/WPA2 handshake captures (<b>-0</b>). Understanding the specific attack mode is key to its effective use.</i>


title: <I>MONITOR MODE REQUIREMENT</I>
content:
<i>For <b>aireplay-ng</b> to function, the wireless interface must be put into monitor mode. This allows the adapter to capture all packets on a given channel, rather than just those addressed to it, and enables the injection of custom packets. This setup is typically achieved using <b>airmon-ng</b>.</i>


title: HISTORY
content:
<i><b>aireplay-ng</b> is a core component of the <b>Aircrack-ng</b> suite, a powerful set of tools for auditing wireless networks. It evolved from earlier standalone tools like 'aireplay' and was integrated into the unified Aircrack-ng project to provide comprehensive wireless security testing capabilities. Its development has consistently focused on improving injection techniques and supporting new attack vectors against modern Wi-Fi security protocols.</i>


title: SYNOPSIS
content:
<b>airmon-ng</b> <i>&lt;action&gt;</i> <i>&lt;interface&gt;</i> [<i>&lt;options&gt;</i>]<br><br>Common actions and their syntax:<br><b>airmon-ng start</b> <i>&lt;interface&gt;</i> [<i>&lt;channel&gt;</i>] [<i>&lt;options&gt;</i>]<br><b>airmon-ng stop</b> <i>&lt;interface&gt;</i><br><b>airmon-ng check</b> [<b>kill</b>]


title: PARAMETERS
content:
<b><b>start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Puts the specified wireless interface into monitor mode, often creating a new virtual monitor interface.<br><br><b><b>stop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the specified monitor interface back to managed mode, removing the virtual monitor interface if created.<br><br><b><b>check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks for and lists processes that might interfere with monitor mode, such as NetworkManager or wpa_supplicant.<br><br><b><b>kill</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <b>check</b>) Kills all identified interfering processes detected by <b>airmon-ng check</b>.<br><br><b><i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the wireless network interface (e.g., <b>wlan0</b>, <b>phy0</b>) to operate on.<br><br><b><i>&lt;channel&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Specifies the Wi-Fi channel (1-14) for the monitor interface to operate on.<br><br><b>--bssid <i>&lt;BSSID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Filters the monitor mode interface to capture packets only from a specific BSSID (MAC address of an access point).<br><br><b>--newmac <i>&lt;MAC&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Assigns a new MAC address to the monitor mode interface.<br><br><b>--suffix <i>&lt;suffix&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Appends a custom suffix (e.g., 'mon', 'test') to the monitor interface name (e.g., <b>wlan0_mon</b>).<br><br><b>--cleanup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Automatically attempts to kill processes that might interfere with monitor mode during startup, similar to <b>check kill</b>.<br><br><b>--keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Optional, used with <b>start</b>) Prevents <i>airmon-ng</i> from killing interfering processes, useful if you want to manage them manually or avoid disruption.<br><br>


title: DESCRIPTION
content:
<i>airmon-ng</i> is a command-line utility from the Aircrack-ng suite, designed to enable monitor mode on wireless network interfaces. Its primary function is to transform a standard wireless adapter into a promiscuous sniffing device, allowing it to capture all wireless traffic visible to it, regardless of whether the packets are addressed to the adapter itself.<br><br>This capability is fundamental for various wireless security activities, including packet sniffing, traffic analysis, injection attacks, and ultimately, cracking WEP or WPA/WPA2 encryption keys. When <i>airmon-ng</i> is executed, it attempts to kill processes that might interfere with monitor mode (like NetworkManager, wpa_supplicant) and then changes the specified wireless interface's mode. It also reports the MAC address of the interface and suggests a name for the new monitor interface, typically <b>wlan0mon</b> or <b>mon0</b>. It is often the crucial first step in a wireless penetration test workflow.


title: CAVEATS
content:
<i>airmon-ng</i> requires root or superuser privileges to modify network interface modes.<br>Not all wireless network adapters fully support monitor mode or packet injection capabilities; compatibility can vary significantly based on chipset and driver.<br>Using <i>airmon-ng</i> may disrupt existing network connections on the host system as it takes control of the wireless interface.<br>The <b>check kill</b> option, while helpful, should be used with caution as it can terminate essential system services or applications, leading to unexpected behavior.


title: <I>TYPICAL WORKFLOW</I>
content:
The usual sequence of operations in a wireless security audit often starts with <b>airmon-ng</b> to enable monitor mode on a suitable wireless adapter. Once enabled, <b>airodump-ng</b> is used to capture packets and identify target networks and connected clients. For active attacks like deauthentication or ARP request injection, <b>aireplay-ng</b> is employed. Finally, <b>aircrack-ng</b> takes the captured handshake or IVs to attempt cracking the encryption key, relying on the data collected in monitor mode.


title: <I>MONITOR INTERFACE NAMING</I>
content:
After successfully starting monitor mode, <i>airmon-ng</i> typically renames the original interface or creates a new one to represent the interface operating in monitor mode. Common naming conventions include appending 'mon' to the original interface name (e.g., <b>wlan0</b> becomes <b>wlan0mon</b>), or assigning a generic name like <b>mon0</b>. It is crucial to note this new interface name, as it will be used for subsequent commands like <b>airodump-ng</b>.


title: HISTORY
content:
<i>airmon-ng</i> is an integral part of the Aircrack-ng suite, a collection of tools for auditing wireless networks. It evolved from earlier, more manual methods of activating monitor mode on wireless adapters, aiming to streamline the process for users. Its development has focused on improving compatibility with various chipsets and drivers, and automating the detection and termination of processes that might interfere with monitor mode, making it a more user-friendly and reliable initial step for wireless security assessments. Over time, features like automatic channel setting and MAC address changing have been integrated to enhance its utility and ease of use in penetration testing workflows.


title: PARAMETERS
content:
<b><b>-H</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help screen and exits.<br><br><b><b>-i</b>, <b>--ivs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves only IVs (Initialization Vectors) to the capture file. Useful for WEP cracking as IVs are the only necessary part of the packets.<br><br><b><b>-w</b> <i>&lt;prefix&gt;</i>, <b>--write</b> <i>&lt;prefix&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the captured raw 802.11 frames to a file with the specified prefix. The file format defaults to <i>pcap</i>, but can be specified with <b>--output-format</b>.<br><br><b><b>-c</b> <i>&lt;channels&gt;</i>, <b>--channel</b> <i>&lt;channels&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the channel(s) to hop on. Can be a single channel (e.g., '6'), a list of channels separated by commas (e.g., '1,6,11'), or a range (e.g., '1-11').<br><br><b><b>-b</b> <i>&lt;bssid&gt;</i>, <b>--bssid</b> <i>&lt;bssid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters captured data by a specific BSSID (MAC address of the AP). Only shows or saves data related to this AP.<br><br><b><b>--essid</b> <i>&lt;essid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters by a specific ESSID (network name). Note that this is not always reliable for hidden ESSIDs.<br><br><b><b>-a</b>, <b>--aps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only shows access points (APs) and hides clients in the display output.<br><br><b><b>-t</b>, <b>--cst</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only shows client stations (STAs) and hides access points in the display output.<br><br><b><b>-u</b> <i>&lt;seconds&gt;</i>, <b>--update</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the delay (in seconds) between screen updates. Default is 1 second.<br><br><b><b>--band</b> <i>&lt;abg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters by wireless band: 'a' for 802.11a, 'b' for 802.11b, 'g' for 802.11g. Can be combined (e.g., 'bg').<br><br><b><b>--manufacturer</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the manufacturer of the AP or client based on its MAC address OUI (Organizationally Unique Identifier).<br><br><b><b>--wps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays WPS (Wi-Fi Protected Setup) information if available for the APs.<br><br><b><b>--output-format</b> <i>&lt;formats&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output file format(s). Can be a comma-separated list of: <i>pcap</i>, <i>ivs</i>, <i>csv</i>, <i>kismet</i>, <i>netxml</i>. Default is <i>pcap</i>.<br><br>


title: DESCRIPTION
content:
<i>airodump-ng</i> is a powerful packet capture tool, an integral part of the <i>Aircrack-ng</i> suite, designed for 802.11 wireless networks.<br><br>It passively sniffs raw 802.11 frames from a wireless interface operating in monitor mode, displaying crucial information about access points (APs) and connected clients in real-time. This includes AP BSSID, ESSID, channel, encryption type, and power levels. For clients, it shows their MAC address, associated AP, and data frames.<br><br>The primary function of <i>airodump-ng</i> is to collect data, typically in <B>.pcap</B> or <B>.ivs</B> format, which can then be used by other tools like <i>aircrack-ng</i> for various purposes, such as password cracking (e.g., WEP or WPA/WPA2 handshakes). It's a foundational tool for network reconnaissance, auditing, and penetration testing in wireless environments, providing an overview of the wireless landscape and potential vulnerabilities.


title: CAVEATS
content:
Using <i>airodump-ng</i> requires a wireless interface that supports <B>monitor mode</B> (also known as RFMON mode).<br><br>It typically requires <B>root privileges</B> to function correctly, as it needs direct access to the network hardware.<br><br>The accuracy of the information displayed (e.g., signal strength) can vary depending on the wireless adapter's capabilities and driver implementation, and it is a passive tool, not designed for active attacks or packet injection.


title: REAL-TIME DISPLAY COLUMNS
content:
When <i>airodump-ng</i> runs, it displays several columns of information for both APs and clients:<br><br><b>For APs:</b><br><i>BSSID</i>: MAC address of the Access Point.<br><i>PWR</i>: Signal strength (higher is better, often negative dBm).<br><i>Beacons</i>: Number of beacon frames observed.<br><i>#Data</i>: Number of data packets observed (useful for WEP/WPA cracking).<br><i>#/s</i>: Data packets per second.<br><i>CH</i>: Channel.<br><i>MB</i>: Maximum speed supported by the AP.<br><i>ENC</i>: Encryption type (e.g., WEP, WPA, WPA2).<br><i>CIPHER</i>: Cipher suite used (e.g., CCMP, TKIP).<br><i>AUTH</i>: Authentication type (e.g., PSK, MGT).<br><i>ESSID</i>: Network name.<br><br><b>For Clients:</b><br><i>BSSID</i>: MAC address of the associated AP (or 'not associated' if probing).<br><i>STATION</i>: MAC address of the client station.<br><i>PWR</i>: Signal strength from client to your card.<br><i>Rate</i>: Current transmit/receive rates.<br><i>Lost</i>: Number of lost frames.<br><i>Frames</i>: Total frames from/to the client.<br><i>Probe</i>: ESSID(s) the client is actively probing for.


title: OUTPUT FILE FORMATS
content:
<i>airodump-ng</i> supports writing captured data into various formats, which can be specified using the <b>--output-format</b> option:<br><i><b>pcap</b></i>: Standard Wireshark/tcpdump format. Most versatile.<br><i><b>ivs</b></i>: A simplified format containing only IVs, specifically for WEP cracking.<br><i><b>csv</b></i>: Comma Separated Values, readable in spreadsheets.<br><i><b>kismet</b></i>: Kismet NetXML format, for compatibility with Kismet.<br><i><b>netxml</b></i>: An XML-based format, useful for structured parsing.


title: HISTORY
content:
<i>airodump-ng</i> is a direct descendant and successor to the original <i>airodump</i> tool, which was part of the initial <i>Aircrack</i> project. As the project evolved into <i>Aircrack-ng</i>, the '<i>-ng</i>' (new generation) suffix was added to signify improved features, stability, and integration within the broader suite of wireless security tools.<br><br>Its development has always been focused on providing a reliable and efficient way to gather the necessary data for auditing wireless network security, particularly for WEP and WPA/WPA2 cracking, making it a cornerstone utility in the ethical hacking and penetration testing community.


title: SYNOPSIS
content:
<b>airodump-ng-oui-update</b> [<i>options</i>]<br><br>Example usage:<br><i>airodump-ng-oui-update</i><br><i>airodump-ng-oui-update --oui-url https://custom.url/oui.txt</i>


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>--oui-url</b> <i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom URL from which to download the OUI (Organizationally Unique Identifier) file, overriding the default IEEE source.<br><br><b><b>--mac-url</b> <i>&lt;url&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom URL from which to download the IAB (Individual Address Block) file, overriding the default IEEE source.<br><br>


title: DESCRIPTION
content:
The <b>airodump-ng-oui-update</b> command is an essential utility within the Aircrack-ng suite, designed to maintain the accuracy and usefulness of <b>airodump-ng</b>'s output. When <b>airodump-ng</b> captures wireless traffic, it displays MAC addresses of detected devices. To provide more meaningful information, it attempts to resolve the first 3 bytes (the Organizationally Unique Identifier or OUI) of these MAC addresses to their respective manufacturer names.<br><br>This command automatically downloads the latest OUI and IAB (Individual Address Block) databases, typically from the IEEE website, ensuring that the manufacturer mapping used by <b>airodump-ng</b> is current. An up-to-date OUI file significantly enhances network analysis by allowing users to quickly identify the vendors of wireless devices, aiding in reconnaissance, troubleshooting, and security auditing.<br><br>Running this command periodically is recommended to keep your Aircrack-ng tools informed about new hardware manufacturers and assigned MAC address ranges.


title: CAVEATS
content:
An active internet connection is required for the command to successfully download the latest OUI and IAB databases. Depending on your system's configuration and the default installation path of Aircrack-ng, you may need root or sudo privileges to write the updated files to their designated system directories (e.g., <i>/usr/local/etc/aircrack-ng/</i> or <i>/etc/aircrack-ng/</i>).


title: DEFAULT FILE LOCATIONS
content:
By default, <b>airodump-ng-oui-update</b> attempts to save the updated <i>oui.txt</i> and <i>mac.txt</i> files in the Aircrack-ng configuration directory, typically located at <i>/usr/local/etc/aircrack-ng/</i> or <i>/etc/aircrack-ng/</i>. These paths are crucial for <b>airodump-ng</b> to correctly identify manufacturer information.


title: IMPORTANCE OF OUI/IAB
content:
The OUI (Organizationally Unique Identifier) is the first 24 bits (3 bytes) of a MAC address, globally administered by the IEEE. It uniquely identifies the organization that manufactured the hardware. IABs (Individual Address Blocks) are similar but assigned to organizations for smaller blocks of MAC addresses. Keeping these databases current allows <b>airodump-ng</b> to display human-readable manufacturer names instead of just raw MAC addresses, greatly enhancing the clarity of network scans.


title: HISTORY
content:
The <b>airodump-ng-oui-update</b> utility is an integral part of the Aircrack-ng suite, which originated from the earlier Aircrack project. As wireless technologies evolved and new hardware manufacturers emerged, the necessity for an updated OUI database became paramount for accurate network analysis. This command was developed to automate the process of keeping <b>airodump-ng</b>'s MAC address manufacturer lookup current, ensuring its continued effectiveness in wireless security auditing and reconnaissance since the early 2000s.


title: SYNOPSIS
content:
<I>airolib-ng</I> <B>database_path</B> [<I>options</I>]<br>Example: <I>airolib-ng</I> <B>wireless_db</B> <B>--file</B> <I>capture.cap</I> <B>--import</B> <I>wpa</I><br>Example: <I>airolib-ng</I> <B>wireless_db</B> <B>--convert</B> <I>essid</I> <I>essids.txt</I>


title: PARAMETERS
content:
<b><B>database_path</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the SQLite database file to create or use for storing data.<br><br><b><B>--help</B>, <B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><B>--stats</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows statistics about the database, including the number of ESSIDs, passwords, and handshakes.<br><br><b><B>--clean</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans the database by removing invalid or incomplete WPA/WPA2 handshakes.<br><br><b><B>--check</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the integrity of handshakes stored in the database.<br><br><b><B>--file</B> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an input file (e.g., <I>.cap</I> for handshakes, <I>.dico</I> for dictionaries) to be processed.<br><br><b><B>--import</B> <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports data from the specified input file. <I>format</I> can be <I>wpa</I> (for handshakes), <I>essid</I>, or <I>password</I>.<br><br><b><B>--add</B> <I>essid</I> <B>&lt;ESSID&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a specific ESSID (network name) to the database.<br><br><b><B>--add</B> <I>password</I> <B>&lt;password&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a specific password (plaintext or PMK) to the database.<br><br><b><B>--remove</B> <I>essid</I> <B>&lt;ESSID&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified ESSID from the database.<br><br><b><B>--remove</B> <I>password</I> <B>&lt;password&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified password from the database.<br><br><b><B>--export</B> <I>type</I> <B>&lt;file&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports data of a specific <I>type</I> (<I>essid</I> or <I>password</I>) from the database to a text <I>file</I>.<br><br><b><B>--convert</B> <I>format</I> <B>&lt;file&gt;</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts all PMK-ESSID pairs from the database into a specified output <I>format</I> (<I>dico</I>, <I>essid</I>, <I>lst</I>) and saves to <I>file</I>.<br><br>


title: DESCRIPTION
content:
<b>airolib-ng</b> is a utility from the <I>aircrack-ng</I> suite designed to process and optimize WPA/WPA2 handshake capture files. Its primary function is to convert raw handshake captures (typically <I>.cap</I> files) into formats suitable for dictionary-based password cracking tools like <I>aircrack-ng</I> itself, <I>hashcat</I>, or <I>John the Ripper</I>. It can also manage ESSID lists, merge files, and check the integrity of handshakes. This tool is crucial for preparing data captured by tools like <I>airodump-ng</I> before attempting to crack WPA/WPA2 passphrases offline. By optimizing the handshake data, <b>airolib-ng</b> helps streamline the cracking process, making it more efficient for various offline attack scenarios.


title: CAVEATS
content:
<b>airolib-ng</b> requires a complete 4-way WPA/WPA2 handshake for effective processing and conversion. Incomplete handshakes, even if present in the <I>.cap</I> file, cannot be used for cracking and will be noted or removed during database cleaning. The database file can grow substantially depending on the amount of captured data, potentially requiring significant disk space.


title: DATABASE MANAGEMENT
content:
<b>airolib-ng</b> uses an SQLite database to store ESSIDs, PMKs (Pairwise Master Keys), and captured handshakes. This centralized database allows for efficient management and reuse of cracking resources, eliminating the need to process the same raw <I>.cap</I> files multiple times.


title: WPA/WPA2 HANDSHAKE REQUIREMENTS
content:
For successful cracking with tools like <I>aircrack-ng</I> or <I>hashcat</I>, <b>airolib-ng</b> requires a complete 4-way handshake to be present in the captured <I>.cap</I> file. The tool can identify and help clean records with incomplete or corrupt handshakes, ensuring only viable data is used for further processing.


title: HISTORY
content:
<b>airolib-ng</b> is an integral part of the <I>aircrack-ng</I> suite, which evolved from the original <I>aircrack</I> project. Its development has focused on enhancing the efficiency and management of WPA/WPA2 cracking resources, particularly the preparation of captured handshake data for dictionary attacks. It streamlined the process of converting raw <I>.cap</I> files into optimized formats needed by <I>aircrack-ng</I> and other cracking tools, improving the overall workflow for wireless security auditing.


title: PARAMETERS
content:
<b><i><b>-p</b> port</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port to listen on or connect to. Defaults to 8080.<br><br><b><i><b>-n</b> name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the service name for mDNS discovery. Allows multiple <b>airpaste</b> instances on the same network.<br><br><b><i><b>-v</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the connection and transfer process.<br><br><b><i><b>-d</b> directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where received files should be saved.<br><br><b><i><b>-s</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <b>airpaste</b> in server mode, continually listening for incoming data without exiting after one transfer.<br><br><b><i><b>-c</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;On the sender side, clears the terminal after sending the content.<br><br><b><i><b>-t</b> timeout</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for waiting for a peer in seconds. Defaults to 5 seconds.<br><br><b><i><b>-h</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
<i><b>airpaste</b> is a lightweight command-line utility designed for quickly sharing text snippets or small files between machines on the same local area network. It leverages Multicast DNS (mDNS), also known as Bonjour or Avahi, for automatic service discovery, eliminating the need to know IP addresses or hostnames.<br><br>When executed, <b>airpaste</b> broadcasts its availability on the network and listens for incoming connections, or discovers other <b>airpaste</b> instances to send data to. Data transfer occurs over HTTP. This tool is particularly useful for ad-hoc sharing scenarios where setting up a full file server or using more complex tools like SCP might be overkill. It simplifies the process of sending output from a command, a block of text, or a small file to another nearby machine without manual configuration.</i>


title: CAVEATS
content:
<i><b>airpaste</b> is designed for convenience on trusted local networks and has several limitations. It does not employ any encryption, meaning all data is transferred in plain text and could be intercepted by other devices on the same network. It is not suitable for transferring very large files due to its HTTP-based transfer mechanism and lack of resume capabilities. Its reliance on mDNS means it might not work across different subnets or if mDNS services (like Avahi or Bonjour) are not properly configured or allowed on the network.</i>


title: <I>USAGE MODES</I>
content:
<i>When sending text (e.g., via pipe), <b>airpaste</b> automatically acts as a sender. When invoked without piped input or file arguments, it defaults to receiver mode, waiting for incoming data. If file arguments are provided, it sends those files.</i>


title: <I>DISCOVERY MECHANISM</I>
content:
<i><b>airpaste</b> uses mDNS (Multicast DNS) for discovery. Senders broadcast their service, and receivers listen for these broadcasts. This allows peers to find each other by name rather than IP address, simplifying ad-hoc connections.</i>


title: HISTORY
content:
<i><b>airpaste</b> is a relatively modern, open-source utility created by Zack Scholl (schollz). It was developed to address the need for simple, ad-hoc data sharing within a local network, drawing inspiration from similar pastebin concepts but tailored for direct peer-to-peer communication without external servers. Its development reflects a trend towards lightweight, zero-configuration tools for common command-line tasks.</i>


title: PARAMETERS
content:
<b><i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the wireless interface to be used by <b>airserv-ng</b>. This interface must typically be in monitor mode.<br><br><b><b>-p</b> <i>&lt;port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the TCP port number on which <b>airserv-ng</b> will listen for incoming client connections. The default port is <i>666</i>.<br><br><b><b>-r</b> <i>&lt;root&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the root directory for the server. The default is <i>"/"</i>. This option is less commonly used for its core function.<br><br><b><b>-d</b> <i>&lt;debug&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for output. Higher numbers usually mean more verbose output. The default is <i>0</i> (no debug).<br><br><b><b>-i</b> <i>&lt;interval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the interval (in milliseconds) at which the server updates. The default is <i>10</i>.<br><br><b><b>-a</b> <i>&lt;address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the IP address on which <b>airserv-ng</b> should listen. By default, it listens on all available interfaces (<i>0.0.0.0</i>).<br><br><b><b>-c</b> <i>&lt;channel&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the wireless channel on which the interface should operate. The default is <i>0</i> (auto/no specific channel enforced by <b>airserv-ng</b> itself, relying on the interface's current channel).<br><br><b><b>-l</b> <i>&lt;log&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a file to which logging information will be written. By default, logs go to standard output (<i>stdout</i>).<br><br><b><b>-n</b> <i>&lt;nb_clients&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of clients that can concurrently connect to the <b>airserv-ng</b> instance. The default is <i>1</i>.<br><br>


title: DESCRIPTION
content:
<b>airserv-ng</b> is a crucial component of the <i>Aircrack-ng</i> suite, designed to enable other tools within the suite to access a wireless network interface card (NIC) remotely. It acts as a server, listening on a specified port for incoming connections from clients (e.g., <b>airodump-ng</b>, <b>aireplay-ng</b> running on another machine or a virtual machine).<br><br>The primary purpose of <b>airserv-ng</b> is to facilitate wireless security testing and packet capture in scenarios where direct access to the physical wireless card is not convenient or possible. This includes setups where the <i>Aircrack-ng</i> tools are running inside a virtual machine (VM) and need to use a wireless adapter attached to the host operating system, or when sharing a dedicated wireless sniffing card among multiple testers over a network.<br><br>It streams the raw wireless traffic from the specified interface over the network connection to the connected client, allowing the client to perform tasks like packet injection, deauthentication attacks, or simply capturing network traffic as if it had direct access to the physical card. The wireless card must be capable of and put into monitor mode (often using <b>airmon-ng</b>) before <b>airserv-ng</b> can effectively utilize it.


title: CAVEATS
content:
Using <b>airserv-ng</b> requires the wireless interface to be capable of monitor mode and to be properly configured (often using <b>airmon-ng</b>).<br><br>Exposing <b>airserv-ng</b> to untrusted networks can pose a security risk, as it grants remote access to the underlying wireless card's capabilities, including packet capture and potentially injection.<br><br>There can be performance overhead and latency when using <b>airserv-ng</b> due to network communication, which might affect time-sensitive operations like certain injection attacks.


title: COMMON USE CASES
content:
A very common scenario for <b>airserv-ng</b> is when running the <i>Aircrack-ng</i> tools within a virtual machine (e.g., <i>Kali Linux</i> in <i>VirtualBox</i> or <i>VMware</i>). Instead of directly passing through a USB wireless adapter (which can be flaky), one can run <b>airserv-ng</b> on the host OS, serving the wireless card to the VM. The tools inside the VM then connect to <i>localhost</i> (or the host's IP) on the specified port.<br><br>Another use case involves sharing a high-gain or specialized wireless adapter located on a dedicated sniffing machine with multiple security researchers across a local network.


title: CLIENT CONNECTION
content:
When connecting to <b>airserv-ng</b> from a client tool like <b>airodump-ng</b> or <b>aireplay-ng</b>, you would specify the remote host and port using the <i>'net'</i> prefix for the interface, e.g., <b>airodump-ng</b> <i>net&lt;ip_address&gt;:&lt;port&gt;</i> or <i>net&lt;ip_address&gt;:&lt;port&gt;/&lt;interface_name&gt;</i>. For example, <b>airodump-ng</b> <i>net192.168.1.100:666</i>.


title: HISTORY
content:
<b>airserv-ng</b> is an integral part of the <i>Aircrack-ng</i> suite, which itself evolved from the original <i>Aircrack</i> project. The <i>Aircrack-ng</i> suite was developed for assessing Wi-Fi network security, focusing on packet sniffing, WEP and WPA/WPA2 cracking, and various attacks against wireless networks. <b>airserv-ng</b> was introduced to address the growing need for remote access to wireless adapters, particularly with the rise of virtual machines and the desire to centralize specialized hardware for penetration testing.


title: SYNOPSIS
content:
As <b>airshare</b> is not a standard Linux command, its synopsis can vary between implementations. However, common patterns observed across various <b>airshare</b>-like tools include:<br><br><b><I>Sharing files:</I></b><br><code>airshare <I>share</I> <I>file_or_directory</I> [<I>options</I>]</code><br><code>airshare <I>send</I> <I>file_or_directory</I> [<I>options</I>]</code><br><br><b><I>Receiving files:</I></b><br><code>airshare <I>receive</I> [<I>options</I>]</code><br><br><b><I>Starting a server:</I></b><br><code>airshare <I>start</I> [<I>options</I>]</code><br><br><b><I>General options:</I></b><br><code>airshare <I>--help</I></code><br><code>airshare <I>--version</I></code>


title: PARAMETERS
content:
<b><code><I>file_or_directory</I></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file or directory to be shared. This is typically an argument to a 'share' or 'send' command.<br><br><b><code>--port &lt;port_number&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number on which the sharing server will listen. Common defaults are 8000 or a randomly assigned available port.<br><br><b><code>--bind &lt;address&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the IP address or hostname to bind the server to (e.g., <code>0.0.0.0</code> for all network interfaces, <code>127.0.0.1</code> for localhost only).<br><br><b><code>--once</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shares the content once and then automatically shuts down the server after the first successful transfer. Useful for quick, single-use sharing.<br><br><b><code>--no-browser</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from automatically opening a web browser to the shared URL after the server starts.<br><br><b><code>--qrcode</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a QR code in the terminal. Mobile devices can scan this QR code to quickly access the shared content's URL.<br><br><b><code>--output &lt;path&gt;</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For receiving operations, this option specifies the directory where incoming files should be saved.<br><br><b><code>--verbose</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, showing more details about the operation and network activity.<br><br><b><code>-h, --help</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message, detailing available commands and options specific to the installed <b>airshare</b> utility.<br><br><b><code>-v, --version</code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>airshare</b> utility being used.<br><br>


title: DESCRIPTION
content:
The <b>airshare</b> command refers to various non-standard utilities designed for simplified, ad-hoc file sharing over a local area network (LAN).<br><br>Unlike traditional methods like SCP, FTP, or setting up full network shares, <b>airshare</b>-like tools aim to provide a zero-configuration or minimal-configuration experience, often by launching a temporary HTTP or WebSocket server. This allows other devices on the same network, including smartphones or other computers, to access shared files easily via a web browser or a dedicated client. Functionality typically includes sharing individual files or directories, and some implementations may offer features like QR code generation for mobile access, one-time sharing, or secure (HTTPS) connections. It's a common solution for quickly transferring data between devices without relying on cloud services or complex network setups.


title: CAVEATS
content:
<b>airshare</b> is <i>not</i> a standard Linux utility distributed with most mainstream distributions. Its availability and specific functionality depend entirely on whether a user has installed a particular <b>airshare</b> implementation (e.g., a Python script from PyPI, a Go binary, etc.).<br><br>Security considerations are important: sharing files using such tools often involves opening a local network port. While convenient for ad-hoc sharing, ensure you understand what you are sharing and with whom, especially when operating on unsecured or public networks. Always be mindful of the content you expose.


title: COMMON IMPLEMENTATIONS
content:
Several open-source projects implement <b>airshare</b>-like functionality, often written in Python (e.g., <code>airshare-cli</code> available on PyPI), Go, or Node.js. Users typically install these via language-specific package managers (like <code>pip</code> for Python) or by downloading pre-compiled binaries. Each implementation may have slightly different command-line syntax and feature sets, but the core purpose of simple local network file sharing remains consistent across them.


title: UNDERLYING TECHNOLOGY
content:
Most <b>airshare</b> utilities function by temporarily setting up a lightweight HTTP, HTTPS, or WebSocket server on a specified local port. They then generate a URL (often displayed in the terminal and sometimes accompanied by a QR code) that other devices on the same network can use to download (or, in some cases, upload) the shared content via a standard web browser. This approach avoids the need for dedicated client software on the receiving end, maximizing compatibility and ease of access.


title: HISTORY
content:
The concept behind <b>airshare</b>-like commands emerged to address the need for simple, ad-hoc file transfers on local networks, mirroring the ease-of-use seen in proprietary solutions like Apple's AirDrop. As a response to the often cumbersome setup of traditional network file sharing protocols, various independent developers and projects created command-line tools and scripts to provide this functionality. There isn't a single 'official' <b>airshare</b> development history; rather, it represents a category of tools that prioritize ease of use and quick deployment for local file sharing without requiring complex server configurations or cloud dependency.


title: SEE ALSO
content:
<code>nc(1)</code> (netcat), <code>python3 -m http.server</code>, <code>scp(1)</code>, <code>sftp(1)</code>, <code>rsync(1)</code>, <code>ssh(1)</code>, <code>nfs(5)</code>, <code>samba(7)</code>, <code>kdeconnect(1)</code>


title: PARAMETERS
content:
<b><b>-a</b> <i>&lt;bssid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the BSSID (MAC address) of the access point to which the virtual interface will connect. This is mandatory for tunnel mode operations.<br><br><b><b>-i</b> <i>&lt;ip_address&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the IP address for the virtual tunnel interface (e.g., <i>at0</i>). This IP address will be used to communicate over the tunnel.<br><br><b><b>-r</b> <i>&lt;ip_range&gt;/&lt;netmask&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines an IP range and netmask for the virtual interface, useful for more complex network setups.<br><br><b><b>-t</b> <i>&lt;essid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the ESSID (network name) of the target wireless network.<br><br><b><b>-w</b> <i>&lt;wepkey&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the WEP key in ASCII or hexadecimal format. This is required to decrypt/encrypt frames when interacting with a WEP-protected network.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables decryption of WEP frames as they pass through the tunnel.<br><br><b><b>-p</b> <i>&lt;pmkid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a PMKID to use for authentication or attack. This is used in specific WPA/WPA2 attacks.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-p</b> <i>&lt;pmkid&gt;</i> to specify shared key authentication.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <b>-p</b> <i>&lt;pmkid&gt;</i> to specify unauthenticated mode.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses dummy FCS (Frame Check Sequence) for injected frames.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new session, which can be useful for certain attack types.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates debug output, providing more verbose information for troubleshooting.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and available options for the command.<br><br>


title: DESCRIPTION
content:
<b>airtun-ng</b> is a powerful utility within the <i>aircrack-ng</i> suite, designed to create a virtual tunnel interface, typically named <i>at0</i>.<br><br>This interface allows for the injection of raw 802.11 frames, enabling advanced wireless security testing and exploitation. By capturing frames on a wireless interface operating in monitor mode and then re-injecting them through the <i>at0</i> tunnel, <b>airtun-ng</b> facilitates various network attacks, such as WEP/WPA key cracking, ARP request injection, and interactive packet manipulation.<br><br>It essentially bridges the gap between the raw 802.11 layer and the IP layer, making it possible to use standard networking tools like <i>ping</i>, <i>ssh</i>, or <i>nmap</i> over a WEP/WPA-protected wireless network, provided the WEP key is known or can be cracked. Its primary use case involves collaborating with other <i>aircrack-ng</i> tools, like <i>aireplay-ng</i>, to perform active attacks that require frame injection.


title: CAVEATS
content:
<ul><li>Requires a wireless adapter capable of monitor mode and frame injection.</li><li>Typically used on Linux systems; compatibility on other platforms may vary or require specific drivers/setups.</li><li>The target wireless interface must be in monitor mode before running <b>airtun-ng</b>.</li><li>Knowledge of the WEP key is usually necessary to effectively utilize the IP tunnel for communication beyond basic injection.</li><li>Misuse can lead to legal consequences or network instability.</li></ul>


title: MONITOR MODE REQUIREMENT
content:
Before running <b>airtun-ng</b>, ensure your wireless adapter is successfully placed into monitor mode using a utility like <i>airmon-ng</i>. This is crucial for <b>airtun-ng</b> to function correctly and interact with the wireless network.


title: VIRTUAL INTERFACE
content:
Upon successful execution, <b>airtun-ng</b> creates a virtual network interface, commonly named <i>at0</i>. This interface acts as a tunnel, allowing IP packets sent through it to be encapsulated into 802.11 frames and injected onto the wireless network, and vice versa for incoming frames.


title: HISTORY
content:
<b>airtun-ng</b> is an integral part of the <i>aircrack-ng</i> suite, which evolved from the original <i>aircrack</i> project. The <i>aircrack-ng</i> project focuses on tools for auditing wireless networks, and <b>airtun-ng</b> was developed to provide the necessary virtual interface for advanced frame injection and interaction with target networks at the IP layer. Its development has been driven by the need for more sophisticated and versatile attacks and analyses within the wireless security research community, allowing researchers to leverage standard networking tools over raw 802.11 traffic.


title: PARAMETERS
content:
<b><i>-p, --pretty</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the output JSON with human-readable indentation and newlines, making it easier to read.<br><br><b><i>-n, --newline</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends each new JSON object on a separate line, creating a JSON Lines (NDJSON) file. This is useful for streaming data and prevents the file from becoming a single large array, enabling line-by-line processing.<br><br><b><i>[JSON_OBJECT]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The JSON string to be appended. If this argument is not provided, <i>ajson</i> expects the JSON input to be piped via standard input (stdin).<br><br><b><i>[FILE]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the target file where the JSON object(s) will be appended. If this argument is omitted, <i>ajson</i> writes the resulting JSON to standard output (stdout).<br><br>


title: DESCRIPTION
content:
The <i>ajson</i> command-line utility is specifically designed for <b>appending new JSON objects</b> to existing files. It supports two primary modes of appending: either by integrating new objects into an existing JSON array within the file, or by adding each new object on a separate line, creating a <b>JSON Lines</b> (newline-delimited JSON) format.<br><br><i>ajson</i> is flexible with its input, capable of reading JSON objects directly from command-line arguments or piped through <b>standard input (stdin)</b>, making it highly suitable for scripting and data pipelines. The output can be directed to a specified file, updating its content, or printed to <b>standard output (stdout)</b> if no file is provided, allowing for further piping or display.<br><br>This tool is particularly valuable in scenarios requiring <b>incremental data collection</b>, logging, or building datasets where new JSON entries are generated sequentially. It helps maintain the structural integrity of the target JSON file while seamlessly integrating new data. Often implemented in environments like Node.js, <i>ajson</i> provides a straightforward and efficient way to handle common JSON manipulation tasks directly from the terminal.


title: CAVEATS
content:
<i>ajson</i> is <b>not a standard core utility</b> found in most Linux distributions. It typically requires separate installation, often via package managers like <i>npm</i> (Node Package Manager).<br><br>Incorrect usage, such as appending to a non-array file without the <i>--newline</i> option, can lead to <b>malformed JSON</b>.<br><br>For very large files, some implementations might read the entire file into memory before modifying and rewriting it, which could impact <b>performance and memory usage</b>. Concurrent writes from multiple processes to the same file without external locking mechanisms can lead to <b>data corruption</b>.


title: INSTALLATION
content:
As <i>ajson</i> is typically a third-party utility, it is commonly installed using <b>npm</b> (Node Package Manager), assuming Node.js is already installed on the system. The command for installation is usually: <br><code>npm install -g ajson-cli</code> (or similar package name, depending on the specific implementation).


title: INPUT/OUTPUT FLOW
content:
<i>ajson</i> is designed for flexible data flow. If no <i>JSON_OBJECT</i> is provided as a command-line argument, it will read JSON data from <b>standard input (stdin)</b>, allowing it to be used in shell pipelines (e.g., <code>cat data.json | ajson ...</code>). If no <i>FILE</i> is specified, the resulting JSON output is written to <b>standard output (stdout)</b>, enabling further processing or redirection (e.g., <code>ajson '{"key": "value"}' > new_data.json</code>).


title: JSON ARRAY VS. JSON LINES
content:
By default, <i>ajson</i> attempts to append new objects into an existing <b>JSON array</b> in the target file. If the file is not an array or if multiple distinct JSON objects need to be stored without forming a single array, the <i>--newline (-n)</i> option is crucial. This option instructs <i>ajson</i> to write each new JSON object on a separate line, adhering to the <b>JSON Lines (NDJSON)</b> format, which is ideal for log files, data streams, and processing large datasets line by line.


title: HISTORY
content:
The <i>ajson</i> command emerged in response to the growing prevalence of <b>JSON as a primary data interchange format</b>, particularly in web development, API communication, and data streaming. Unlike traditional Unix text processing tools, <i>ajson</i> provides a JSON-aware method for appending data, addressing a specific need for maintaining valid JSON structure.<br><br>Its development is closely tied to the rise of platforms like <b>Node.js</b>, which enabled developers to create powerful command-line utilities using JavaScript, making such tools accessible and easy to integrate into modern development workflows. While it lacks a long-standing Unix history, its utility is a direct reflection of contemporary data handling requirements.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints help information.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints version information.<br><br><b><b>-e</b>, <b>--command</b> <I>COMMAND</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <I>COMMAND</I> within the Alacritty terminal, followed by its arguments.<br><br><b><b>-c</b>, <b>--config</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom configuration <I>FILE</I> to load instead of the default.<br><br><b><b>-o</b>, <b>--option</b> <I>KEY</I>=<I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides a configuration option specified by <I>KEY</I> with the given <I>VALUE</I>.<br><br><b><b>-T</b>, <b>--title</b> <I>TITLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the window title for the Alacritty instance.<br><br><b><b>-W</b>, <b>--working-directory</b> <I>DIR</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial working directory to <I>DIR</I> for the terminal session.<br><br><b><b>-C</b>, <b>--class</b> <I>CLASS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the X11 window class and GTK application ID. Useful for window managers.<br><br><b><b>-d</b>, <b>--display</b> <I>DISPLAY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X11 <I>DISPLAY</I> to connect to (Linux/X11 only).<br><br>


title: DESCRIPTION
content:
Alacritty is a modern, cross-platform terminal emulator written in <b>Rust</b>, focusing on performance and simplicity. It leverages your <i>GPU</i> for rendering, providing incredibly low input latency and a smooth experience, making it one of the fastest terminal emulators available. <br><br>Designed with a minimalist approach, Alacritty intentionally omits features like tabs, splits, or complex scrollback history. Instead, it encourages users to pair it with a terminal multiplexer such as <I>tmux</I> or <I>zellij</I> for advanced session management. Its configuration is handled entirely through a <i>YAML</i> file, allowing for deep customization of appearance, key bindings, and behavior without a graphical interface.


title: CAVEATS
content:
Alacritty is designed to be lean; it does not offer built-in features such as tabs, splits, or graphical configuration interfaces. Users are expected to leverage external tools like <I>tmux</I> or <I>zellij</I> for session management and configure Alacritty solely via its <i>YAML</i> configuration file. While highly performant, it might use more GPU resources compared to purely CPU-rendered terminals.


title: CONFIGURATION
content:
Alacritty's configuration is managed entirely through a <i>YAML</i> file, typically located at <I>~/.config/alacritty/alacritty.yml</I> on Linux and macOS. This file allows extensive customization of fonts, colors, key bindings, scrollback, and other behaviors. Changes to the configuration file are applied live without needing to restart the terminal.


title: PERFORMANCE AND GPU ACCELERATION
content:
The primary design goal of Alacritty is performance. It achieves this by utilizing your system's GPU for rendering text, rather than the CPU. This GPU acceleration leads to significantly reduced input latency and smoother scrolling, especially when displaying large amounts of text or animations, providing a snappier feel compared to traditional CPU-bound terminals.


title: CROSS-PLATFORM SUPPORT
content:
Alacritty is a truly cross-platform application, providing native builds and consistent performance across Linux, macOS, and Windows. This makes it an ideal choice for users who work across multiple operating systems and desire a unified terminal experience.


title: HISTORY
content:
Alacritty was initiated by Joe Wilm in 2017 with the goal of creating the fastest terminal emulator possible, leveraging modern GPU rendering capabilities. Written in <b>Rust</b>, it quickly gained traction among developers seeking a highly performant and responsive terminal. Its development emphasizes stability, performance, and cross-platform compatibility, making it a popular choice across Linux, macOS, and Windows. Alacritty's minimalist philosophy has remained central throughout its evolution, focusing on doing one thing exceptionally well: emulating a terminal.


title: PARAMETERS
content:
<b><b>-o</b>, <b>--output</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output Haskell file to be generated. By default, Alex writes to a file with the same base name as the input but with a <i>.hs</i> extension.<br><br><b><b>-g</b>, <b>--ghc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates code that is specifically optimized for use with the Glasgow Haskell Compiler (GHC), potentially offering better performance or compatibility.<br><br><b><b>-s</b>, <b>--strict</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a 'strict' lexer. This can influence how the lexer handles lazy evaluation in Haskell, often leading to more predictable performance and memory usage.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the Alex tool and then exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a comprehensive help message detailing all available command-line options and their usage, then exits.<br><br><b><b>--encoding</b>=<i>ENC</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character encoding of the input Alex file (e.g., UTF-8). This ensures correct processing of multi-byte characters in regular expressions and actions.<br><br><b><b>--monad</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a monadic lexer, allowing the lexer actions to operate within a monadic context (e.g., <i>IO</i>, <i>State</i>). This is useful for lexers that require side effects or state management.<br><br><b><b>--bytestring</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a lexer that operates on <i>ByteString</i> input rather than <i>String</i>. This is often preferred for performance and memory efficiency when dealing with large binary or text data.<br><br><b><b>--utf8</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the generated lexer to handle UTF-8 encoded input correctly, ensuring that multi-byte Unicode characters are recognized and processed as single characters.<br><br>


title: DESCRIPTION
content:
The command <i>alex</i> refers to Alex, a powerful lexical analyzer generator specifically designed for the Haskell programming language. It serves a fundamental role in the initial phase of compilation, commonly known as lexing or scanning. Alex takes a high-level description of tokens defined using regular expressions, along with corresponding Haskell actions, specified in an <i>.x</i> source file. From this input, it efficiently generates a Haskell module (typically an <i>.hs</i> file) that can read an input character stream and produce a sequence of recognized tokens.<br><br>Lexical analysis is the process of transforming a raw sequence of characters into a stream of tokens—meaningful units in a programming language, such as keywords, identifiers, operators, or literals. Alex automates this often complex and error-prone task, performing a function analogous to <i>flex</i> and <i>lex</i> in the C/C++ programming ecosystem. While not a general-purpose Linux utility in the sense of commands like <i>ls</i> or <i>grep</i>, Alex is an indispensable tool for Haskell developers engaged in building compilers, interpreters, or any application that necessitates robust text parsing and understanding of language constructs. It leverages finite automata theory to produce highly optimized and performant lexers.


title: CAVEATS
content:
It is important to note that <i>alex</i> is a specialized development tool for the Haskell programming language, not a general-purpose utility found on all Linux systems by default. Its presence and functionality are contingent upon a Haskell development environment being installed. The Haskell code generated by Alex then needs to be compiled using a Haskell compiler like <i>ghc</i>. Users attempting to run <i>alex</i> without understanding its specific context in compiler construction and Haskell development may encounter unexpected results or errors.


title: ROLE IN COMPILATION
content:
In a typical compilation pipeline, the output generated by <i>alex</i> (the lexical analyzer or 'lexer') serves as the input for a parser. The parser then takes this stream of tokens and constructs a syntax tree, verifying the grammatical correctness of the input program. This clear separation of concerns—lexing for tokenizing, and parsing for structuring—significantly simplifies the overall language processing task.


title: COMPARISON TO FLEX
content:
Alex is conceptually the Haskell equivalent of <i>flex</i> (Fast Lexical Analyzer Generator), a widely used tool in the C/C++ world. Both tools generate efficient lexical analyzers from specifications based on regular expressions. The primary distinction lies in the target programming language for the generated code: Alex produces Haskell code, while <i>flex</i> generates C or C++.


title: HISTORY
content:
Alex was developed by Chris Dornan and has been maintained as an integral part of the broader Haskell ecosystem. It provides a robust, modern, and efficient alternative to traditional lexical analyzer generators for Haskell, integrating seamlessly with the language's features and strong type system. Its ongoing development is driven by the needs of the Haskell community for powerful compiler-building tools, ensuring it evolves to support new language features and performance improvements.


title: PARAMETERS
content:
<b><I>(no arguments)</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently defined aliases in the format <I>alias name='value'</I>.<br><br><b><I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the definition of the alias named <I>name</I>. If <I>name</I> is not an alias, no output is produced.<br><br><b><I>name=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines or redefines an alias. <I>name</I> is the alias name, and <I>value</I> is the command string it expands to. The <I>value</I> must be enclosed in single or double quotes if it contains spaces or shell metacharacters.<br><br><b><I>-p</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints all defined aliases in a reusable format (e.g., <I>alias name='value'</I>), suitable for piping or saving to a file.<br><br>


title: DESCRIPTION
content:
The <b>alias</b> command is a powerful shell builtin used to create, display, and manage shorthand names for longer or more complex commands. When you type a command, the shell first checks if it is an alias before searching for executables in your <I>PATH</I>. This allows users to personalize their command-line experience, correct common typos, or quickly invoke commands with specific options. For instance, <I>alias ll='ls -alF'</I> defines 'll' as a shortcut for listing directory contents in a long format, including hidden files, and indicating file types. Aliases are highly convenient for frequently used commands, improving productivity and reducing typing. By default, aliases are only active for the current shell session. To make them permanent, they must be defined in shell startup files like <I>~/.bashrc</I> or <I>~/.zshrc</I>.


title: CAVEATS
content:
Aliases are not recursive: an alias's <I>value</I> cannot refer back to itself or to another alias that eventually refers back to it. The shell performs alias expansion only on the first word of a command, unless the alias's value ends with a space. Aliases are shell-specific builtins and are not executable programs in themselves. They only exist for the current shell session unless added to a shell configuration file (e.g., <I>~/.bashrc</I>).


title: UNALIAS COMMAND
content:
The <b>unalias</b> command is used to remove alias definitions. Its syntax is <I>unalias</I> [<i>-a</i>] <I>name</I> [<I>name</I> ...]. The <I>-a</I> option removes all alias definitions.


title: PERSISTENCE
content:
To make aliases permanent across shell sessions, you must add their definitions (e.g., <I>alias ll='ls -alF'</I>) to your shell's startup configuration file. For Bash, this is typically <I>~/.bashrc</I>. For Zsh, it's <I>~/.zshrc</I>. After modifying these files, you can load the new aliases by sourcing the file (e.g., <I>source ~/.bashrc</I>) or by opening a new terminal session.


