# CommandSection

title: DESCRIPTION
content:
<i>xrandr</i> is a command-line utility used to query, configure, and manipulate the X server's RandR (Resize and Rotate) extension. It allows users to control various aspects of their display setup, including screen resolution, refresh rate, rotation, reflection, and the arrangement of multiple monitors, all without requiring a restart of the X server. This makes it an indispensable tool for managing external displays, projectors, and adapting to different display modes on Linux desktop environments. Whether you need to connect a second monitor, change your laptop's native resolution, or orient a screen for a specific purpose, <i>xrandr</i> provides the flexibility to achieve these configurations on-the-fly. It queries available outputs (e.g., HDMI-1, DP-1), supported modes, and their current status, then applies desired settings.


title: CAVEATS
content:
<i>xrandr</i> operates on the X server and requires it to be running. Permissions issues can arise if not run with appropriate display access. Not all graphics drivers fully support every RandR feature; some operations (e.g., specific rotations or reflections) might not be available or function correctly depending on your hardware and driver. Changes made with <i>xrandr</i> are typically session-specific and will revert upon restarting the X server or rebooting the system unless persisted through a display manager configuration or startup script.


title: <I>PERSISTENCE OF CONFIGURATION</I>
content:
Changes made with <i>xrandr</i> are generally temporary and only apply to the current X session. To make configuration permanent, commands must be added to a startup script that runs after the X server starts, such as <i>~/.xprofile</i>, a desktop environment's autostart mechanism, or system-wide Xorg configuration files (e.g., <i>/etc/X11/xorg.conf.d/</i>).


title: <I>MODELINES FOR CUSTOM RESOLUTIONS</I>
content:
When an unsupported resolution or refresh rate is needed, <i>xrandr</i> allows adding 'modelines' via <i>--newmode</i>. These modelines are precise timing parameters for the display, typically generated by utilities like <i>cvt</i> or <i>gtf</i>. For example, <i>cvt 1920 1080 60</i> would provide the modeline for a 1920x1080 @ 60Hz display.


title: HISTORY
content:
The RandR (Resize and Rotate) extension for the X Window System was introduced to provide dynamic configuration capabilities for displays, moving beyond the static <i>xorg.conf</i> setup. <i>xrandr</i> is the command-line interface to this extension, evolving over time with the X.Org server to support more complex multi-monitor setups, hot-plugging, and advanced display manipulations. Its development has focused on enhancing user experience by allowing on-the-fly display adjustments without requiring system restarts.


title: PARAMETERS
content:
<b><B>-query</B> or <B>-q</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current contents of the <I>RESOURCE_MANAGER</I> property.<br><br><b><B>-load</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the contents of the specified file or standard input into the <I>RESOURCE_MANAGER</I> property. This is the default action if no explicit action is given and a file is provided.<br><br><b><B>-merge</B> or <B>-m</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Merges the contents of the specified file or standard input with the existing resources. This is the default behavior when loading.<br><br><b><B>-edit</B> or <B>-e</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows editing of the current <I>RESOURCE_MANAGER</I> property using an external editor defined by the <I>EDITOR</I> environment variable.<br><br><b><B>-remove</B> or <B>-r</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the <I>RESOURCE_MANAGER</I> property from the server.<br><br><b><B>-override</B> or <B>-ov</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides existing resources with the new ones.<br><br><b><B>-nocpp</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables processing the input through the C preprocessor.<br><br><b><B>-cpp</B> <I>program</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative C preprocessor program to use.<br><br><b><B>-silent</B> or <B>-s</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warning and error messages.<br><br><b><B>-backup</B> <I>suffix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a backup file with the given suffix before modifying the resource database file.<br><br><b><B>-display</B> <I>display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to.<br><br><b><B>-all</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on all screens of the display.<br><br>


title: DESCRIPTION
content:
<b>xrdb</b> is a command-line utility used to manage the X server's resource database. This database, typically stored in the <I>RESOURCE_MANAGER</I> property on the root window of screen 0, holds user-specific configuration settings for X applications. Applications often query this database to determine their appearance, behavior, and default values.<br><br>Common uses include loading user preferences from files like <I>~/.Xresources</I> or <I>~/.Xdefaults</I> during X session startup. By default, <b>xrdb</b> merges the contents of the specified file (or standard input) with the existing resources, allowing for flexible configuration updates. It can also query, remove, or edit the current resource database.<br><br>The resource file often uses a format similar to X application default files and can include C preprocessor directives, enabling conditional configurations based on various factors.


title: CAVEATS
content:
The <I>RESOURCE_MANAGER</I> property is typically managed per-display, and applications usually read it only once at startup. Changes made by <b>xrdb</b> may not affect already running applications until they are restarted.<br><br>Modern desktop environments often provide their own configuration systems that might override or coexist with <b>xrdb</b> settings, potentially leading to unexpected behavior if not managed carefully.


title: <B>RESOURCE FILE FORMAT</B>
content:
The resource file typically consists of lines defining resources in the format: <I>Application.ResourceName: value</I>. It supports C preprocessor directives like <I>#include</I>, <I>#define</I>, and conditional compilation (<I>#ifdef</I>, <I>#ifndef</I>), allowing for highly flexible and environment-dependent configurations.


title: <B>INTERACTION WITH X CLIENT LIBRARIES</B>
content:
X applications using the X Toolkit (Xt) or Xlib functions like <I>XGetDefault</I> automatically query the <I>RESOURCE_MANAGER</I> property (or <I>.Xdefaults</I> file as a fallback) to retrieve configuration values. This central mechanism ensures consistent application behavior across different sessions and applications if they adhere to the resource manager standard.


title: HISTORY
content:
<b>xrdb</b> is a fundamental utility from the early days of the X Window System. It was developed as part of the X11 distribution to provide a standardized way for users to define and load application-specific settings, moving away from individual application configuration files. Its design reflects the client-server architecture of X, allowing resources to be stored centrally on the X server. It has remained a stable and essential component for managing X resources over decades.


title: SYNOPSIS
content:
<b>xrefresh</b> [<i>-display <I>display</I></i>] [<i>-geometry <I>WxH+X+Y</I></i>] [<i>-root</i>] [<i>-help</i>] [<i>-version</i>]


title: PARAMETERS
content:
<b>-display <I>host:dpy</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server display to connect to.<br><br><b>-geometry <I>WxH+X+Y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a specific rectangular region of the screen to refresh. If omitted, the entire screen is refreshed.<br><br><b>-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces refreshment of only the root window. This is the default behavior when no geometry is specified.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief usage message and exits.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the program's version information and exits.<br><br>


title: DESCRIPTION
content:
<b>xrefresh</b> is a fundamental utility within the X Window System, serving to explicitly force a redraw of all or part of an X screen. Its primary function is to resolve visual glitches such as "ghost" windows, screen tearing, or artifacts left behind by applications that crash or terminate improperly without correctly unmapping their graphical elements. The command achieves this by unmapping and then immediately remapping the root window, which effectively signals the X server to repaint all content on the display.<br><br>While modern compositing desktop environments and window managers often handle screen redrawing more robustly, <b>xrefresh</b> remains a valuable diagnostic and cleanup tool, especially in simpler X setups or when troubleshooting issues with legacy applications. It ensures that the display accurately reflects the current state of the X server's window hierarchy, providing a quick way to clear visual clutter and restore a clean screen without needing to restart the X server itself.


title: CAVEATS
content:
Historically, a common <i>caveat</i> for <b>xrefresh</b> noted that the functionality it provides "should be part of the server." This implies that forcing a screen redraw was seen as a fundamental operation that ideally should be managed internally by the X server itself rather than requiring an external client utility.<br><br>While <b>xrefresh</b> is effective for visual cleanup, it does not address the root cause of applications misbehaving or failing to correctly manage their windows. Furthermore, in modern desktop environments utilizing compositing window managers (e.g., GNOME, KDE Plasma, MATE), <b>xrefresh</b>'s direct effect on redrawing might be less apparent or necessary, as compositors often handle screen updates more dynamically. However, it remains valuable in simpler, non-composited X setups or for diagnosing specific display issues.


title: INTERACTION WITH COMPOSITORS
content:
In modern X environments, especially those using compositing window managers (like GNOME's Mutter, KDE's KWin, or Picom), the direct visual impact of <b>xrefresh</b> might be less pronounced. Compositors manage screen updates and redrawing more dynamically, often preventing the types of artifacts <b>xrefresh</b> is designed to clear. However, <b>xrefresh</b> can still be useful for forcing a refresh at a lower level or for troubleshooting when the compositor itself is behaving unexpectedly.


title: USE CASES BEYOND ARTIFACT CLEANUP
content:
While primarily used for cleaning up visual artifacts, <b>xrefresh</b> can occasionally be employed in scripts to ensure a display update after certain programmatic changes to X resources or configurations. Although more specific Xlib or XCB calls are typically preferred for precise control within applications, <b>xrefresh</b> offers a quick and simple command-line method for a full or partial screen repaint.


title: HISTORY
content:
<b>xrefresh</b> has been a standard utility within the X Window System distribution since its early versions, typically bundled as part of the <i>x11-utils</i> or <i>xorg-apps</i> packages. Its consistent inclusion reflects a long-standing need for a simple, client-side tool to force screen redrawing in X environments. Its development has remained stable, primarily focused on maintaining compatibility with evolving X server versions rather than introducing new features. Its existence underscores common challenges in earlier X implementations regarding window management and artifact cleanup, issues that modern compositing techniques aim to mitigate automatically.


title: SYNOPSIS
content:
<b>xsel</b> [<i>-p</i>|<i>-s</i>|<i>-b</i>] [<i>-i</i>|<i>-o</i>] [<i>-f</i>|<i>-c</i>|<i>-k</i>|<i>-l</i>|<i>-t milliseconds</i>|<i>-a</i>|<i>-u</i>] [<i>file...</i>]


title: PARAMETERS
content:
<b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Primary Selection</i>. Operates on the PRIMARY selection, which is the default if no selection option is specified. Typically used for highlight-and-paste.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Secondary Selection</i>. Operates on the SECONDARY selection, which is less commonly used.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Clipboard Selection</i>. Operates on the CLIPBOARD selection. This is the common Ctrl+C/Ctrl+V mechanism.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Input</i>. Reads from standard input (or files specified as arguments) and sets the selected buffer's content.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Output</i>. Writes the content of the selected buffer to standard output.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Fork</i>. Forks to the background immediately after setting the selection. Useful for scripts where the parent process needs to continue without waiting for <b>xsel</b>.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Clear</i>. Clears the content of the specified selection buffer.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Kill</i>. Kills any existing <b>xsel</b> process that is currently owning a selection.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List</i>. Lists the owners of the PRIMARY, SECONDARY, and CLIPBOARD selections.<br><br><b><b>-t</b> <i>milliseconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Timeout</i>. Specifies a timeout in milliseconds to wait for a selection owner to appear when attempting to retrieve a selection.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Append</i>. Appends the input to the current content of the selection. Requires that <b>xsel</b> becomes the selection owner first.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Update</i>. Forces <b>xsel</b> to update its selection and act as a new selection owner, useful for certain applications.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>xsel</b> version information to standard output.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief usage message and exits.<br><br>


title: DESCRIPTION
content:
<b>xsel</b> is a command-line utility for interacting with the X Window System's selection buffers. It allows users to store text into and retrieve text from these buffers, effectively enabling copy-paste operations between terminal applications and graphical user interface (GUI) applications. <br><br>The X Window System defines several selection buffers, primarily:<br><i>Primary Selection</i>: This is typically used for highlight-and-paste behavior, where text is selected by simply highlighting it with the mouse.<br><i>Secondary Selection</i>: Less commonly used, often for specialized application functions.<br><i>Clipboard Selection</i>: This is the familiar copy-paste mechanism (Ctrl+C, Ctrl+V), where data persists even after the source application closes or the selection changes.<br><br><b>xsel</b> defaults to operating on the Primary selection but can be directed to use the Clipboard or Secondary selections. It can read input from standard input or a file and write the selection contents to standard output. This makes it a powerful tool for scripting and automating interactions between the command line and the graphical desktop environment.


title: CAVEATS
content:
<b>xsel</b> relies on the X Window System. It will not function in environments without a running X server (e.g., pure TTY consoles or SSH sessions without X forwarding). While robust for its intended purpose, it may exhibit different behaviors or limitations when interacting with applications that implement X selections in non-standard ways. For more advanced features like specifying target types (e.g., HTML, images), the <b>xclip</b> utility might be more suitable.


title: <B>BASIC USAGE EXAMPLES</B>
content:
To copy text from a file to the clipboard:<br><i><b>cat</b> <i>myfile.txt</i> | <b>xsel -b -i</b></i><br><br>To paste the clipboard content into a new file:<br><i><b>xsel -b -o</b> > <i>pasted_text.txt</i></i><br><br>To copy the last command executed to the primary selection:<br><i><b>history 1</b> | <b>awk '{print $2}'</b> | <b>xsel</b></i><br><br>To clear the clipboard:<br><i><b>xsel -b -c</b></i>


title: <B>X SELECTION TYPES</B>
content:
The X Window System defines several selection 'atoms' or types that <b>xsel</b> interacts with:<br><i><b>PRIMARY</b></i>: The default selection, often used for immediate highlight-and-paste.<br><i><b>SECONDARY</b></i>: A less commonly used auxiliary selection.<br><i><b>CLIPBOARD</b></i>: The standard clipboard for explicit copy/cut and paste operations, persisting content until explicitly overwritten.


title: HISTORY
content:
<b>xsel</b> is a long-standing utility within the X Window System's ecosystem, often distributed as part of the <i>xorg-x11-utils</i> or similar packages. It provides a simple yet effective command-line interface to the X selection mechanisms, a fundamental part of the X desktop experience. While the more feature-rich <b>xclip</b> utility emerged later, offering more fine-grained control over selection targets and formats, <b>xsel</b> has maintained its relevance due to its simplicity, minimal dependencies, and direct approach to handling basic text selections. Its development has been consistent with the evolution of Xorg, ensuring compatibility across various Linux and Unix-like systems.


title: PARAMETERS
content:
<b>-ac</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables access control, allowing any host to connect to the display. Use with caution.<br><br><b>-audit <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the audit trail level for server operations. A value of 0 disables auditing.<br><br><b>-br</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a blanking reset, turning off the screen blanking and DPMS (Display Power Management Signaling) features.<br><br><b>-config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an explicit Xorg configuration file to use instead of the default search path.<br><br><b>-configure</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the server to probe for hardware and generate a new <I>xorg.conf</I> file in the current directory, then exit.<br><br><b>-dpi <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the dots per inch (DPI) value for the display, overriding the detected or configured value.<br><br><b>-logfile <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom log file for the server's output, overriding the default location (e.g., <I>/var/log/Xorg.0.log</I>).<br><br><b>-nocursor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the display of the cursor. Useful for kiosks or embedded systems.<br><br><b>-novtswitch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the ability to switch virtual terminals (VT) using Ctrl+Alt+Fx keys.<br><br><b>-retro</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Emulates an older, monochrome X display, useful for testing or specific legacy applications.<br><br><b>-s <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the screen saver timeout in seconds. A value of 0 disables the screen saver.<br><br><b>-tst</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables toggle-sticky keys mode, a feature for accessibility.<br><br><b>-verbose <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the verbose logging level for server messages, with higher values providing more detailed output.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the X server version and exits without starting the server.<br><br><b>:<I>display_number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the display number for the server instance. For example, <B>:0</B> for the first display.<br><br>


title: DESCRIPTION
content:
The <I>Xserver</I>, primarily implemented by <I>Xorg</I>, is the fundamental component of the X Window System. It acts as the intermediary between graphical applications (X clients) and the underlying hardware (graphics card, keyboard, mouse). Its primary role is to manage all input and output for graphical displays. When an X client wants to draw something on the screen or needs input from the user, it communicates with the <I>Xserver</I>. The server then translates these requests into operations that the graphics hardware can understand and sends events (like keystrokes or mouse clicks) back to the clients. While <I>Xserver</I> itself is a general term, <B>Xorg</B> is the most prevalent and widely used open-source implementation. Users typically do not run <I>Xorg</I> directly; instead, it is started by display managers like GDM, LightDM, or SDDM, or via the <B>startx</B> utility, which simplifies the process of launching a full graphical session.


title: CAVEATS
content:
Running <B>Xorg</B> directly from the command line is generally not recommended for typical users, as it bypasses the setup provided by display managers or <B>startx</B>. Misconfiguration can lead to graphical issues or system instability. Security considerations are important, especially when disabling access control (`-ac`) or using XDMCP, which allows remote graphical access. Configuration often involves editing files in <I>/etc/X11/</I> or <I>/usr/share/X11/</I>, which requires root privileges and careful attention to syntax.


title: DISPLAY NUMBERS
content:
Each instance of an X server running on a system is assigned a unique display number, typically starting from <B>:0</B> (zero). This number is used by X clients to identify and connect to a specific X server instance. For example, setting the <B>DISPLAY=:0.0</B> environment variable tells a client to connect to display 0, screen 0.


title: CONFIGURATION FILES
content:
While modern <B>Xorg</B> is largely capable of auto-detecting hardware, detailed configuration can be managed through files like <I>xorg.conf</I> and fragments in <I>xorg.conf.d/</I> directories. These files specify input devices, monitor settings, display resolutions, and driver options. Common locations include <I>/etc/X11/xorg.conf</I> and <I>/etc/X11/xorg.conf.d/</I>.


title: CLIENT-SERVER MODEL
content:
The X Window System operates on a strict client-server model. The <B>Xserver</B> provides graphical services, and applications (<I>X clients</I>) request these services. This clear separation allows clients to run on different machines from the server, enabling remote graphical applications without transmitting raw pixel data.


title: HISTORY
content:
The X Window System originated at MIT in 1984, aiming to create a network-transparent graphical environment. The initial X server implementations evolved over time. A significant development was the <I>XFree86</I> project, which became the dominant open-source implementation of the X server for Unix-like systems from the early 1990s. Due to licensing and governance disagreements within <I>XFree86</I> in the early 2000s, a fork occurred, leading to the creation of the <I>X.Org Foundation</I> and its primary server implementation, <B>Xorg</B>. <B>Xorg</B> quickly superseded <I>XFree86</I> as the standard X server on Linux and other Unix-like systems, maintaining compatibility with existing X clients while actively developing new features and better hardware support. Its development continues as part of the broader freedesktop.org initiative.


title: SYNOPSIS
content:
<b>xset</b> [<i>options</i>] [<i>argument</i>]<br><br><b>Common Usage Examples:</b><br><b>xset</b> <i>q</i><br><b>xset</b> <i>s 600 300</i><br><b>xset</b> <i>dpms force off</i><br><b>xset</b> <i>m 5 2</i><br><b>xset</b> <i>-b</i>


title: PARAMETERS
content:
<b><i>q</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries and prints the current settings of all controllable aspects, including bell, keyboard, mouse, screen saver, and DPMS.<br><br><b><i>b [volume [pitch [duration]]]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the keyboard bell. <i>volume</i> (0-100), <i>pitch</i> (Hz), <i>duration</i> (ms). Use <i>-b</i> or <i>b off</i> to disable the bell, <i>b on</i> to enable it.<br><br><b><i>c [volume]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the key click. <i>volume</i> (0-100). Use <i>-c</i> or <i>c off</i> to disable key click, <i>c on</i> to enable it.<br><br><b><i>m [acceleration [threshold]]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls mouse acceleration and threshold. <i>acceleration</i> is a multiplier (e.g., 2/1 for double speed), <i>threshold</i> is the number of pixels the mouse must move before acceleration begins.<br><br><b><i>s [timeout [blanking]]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the screen saver. <i>timeout</i> (seconds) before activation. <i>blanking</i> can be <i>on</i> (blank screen), <i>off</i> (no blanking), or <i>prefer blanking</i>. Use <i>s on</i> to enable, <i>s off</i> to disable, and <i>s default</i> to restore defaults.<br><br><b><i>fp [path]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the font search path. <i>fp default</i> restores the default path. <i>fp+ [path]</i> adds to the path, <i>fp- [path]</i> removes from the path.<br><br><b><i>r [keycode]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls keyboard auto-repeat. <i>r on</i> enables auto-repeat for all keys. <i>r off</i> disables for all keys. <i>r [keycode]</i> disables auto-repeat for a specific keycode.<br><br><b><i>dpms [option]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls Display Power Management Signaling (DPMS). Options include <i>on</i> (enable), <i>off</i> (disable), <i>activate</i>, <i>deactivate</i>, <i>force standby|suspend|off</i>, and setting timeouts (<i>standby [suspend [off]]</i> in seconds).<br><br><b><i>led [integer]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls keyboard LEDs. <i>led on [integer]</i> turns on a specific LED (e.g., 3 for Caps Lock). <i>led off [integer]</i> turns off an LED.<br><br>


title: DESCRIPTION
content:
<i><b>xset</b></i> is a utility for the X Window System that allows users to query and set various user preference options of the X server. It can control aspects like keyboard auto-repeat, bell volume and pitch, mouse acceleration and threshold, screen saver timeout and blanking, font search paths, and display power management (DPMS) settings.<br><br><i><b>xset</b></i> is commonly used to customize the X environment for a user's session, often run from a user's <i>~/.xinitrc</i> or <i>~/.xprofile</i> script. It provides a command-line interface to configure options that might otherwise require graphical tools or direct server configuration, making it valuable for minimalist setups, scripting, or troubleshooting.


title: CAVEATS
content:
Changes made with <i><b>xset</b></i> are session-specific and will be lost when the X server restarts or the session ends. To make settings persistent, commands must be placed in startup scripts (e.g., <i>~/.xinitrc</i> or desktop environment autostart). <i><b>xset</b></i> requires a running X server to function. Some settings might be overridden by modern desktop environments or display managers.


title: PERSISTENT CONFIGURATION
content:
As <i><b>xset</b></i> changes are temporary, lasting only for the current X session, to make settings persistent across reboots or new sessions, the <i><b>xset</b></i> commands are typically placed in user startup scripts. Common locations include <i>~/.xinitrc</i> (for users starting X with <i>startx</i>) or <i>~/.xprofile</i> (often sourced by display managers like GDM, LightDM, SDDM).


title: X RESOURCES VS. XSET
content:
It's important to distinguish between settings controlled by <i><b>xset</b></i> and settings configured via X resources. <i><b>xset</b></i> manages server-wide behaviors like mouse acceleration, screen saver, and bell characteristics. X resources (typically defined in <i>~/.Xresources</i> or <i>~/.Xdefaults</i>) are used by individual X applications to customize their appearance and behavior (e.g., font sizes, color schemes for terminals or text editors). <i><b>xset</b></i> does not manage X resources.


title: HISTORY
content:
<i><b>xset</b></i> has been a fundamental part of the X Window System since its early days, providing command-line control over core X server user preferences. It predates many modern desktop environments and was crucial for users to customize their X server behavior directly from shell scripts. While graphical configuration tools in comprehensive desktop environments (like GNOME and KDE) now handle many of these settings, <i><b>xset</b></i> remains a valuable tool for minimalist setups, scripting automation, and troubleshooting scenarios where direct X server interaction is needed.


title: SYNOPSIS
content:
<I>xsetmode</I> [options] [arguments]<br><br><b>Note:</b> A standard synopsis for <I>xsetmode</I> is not available as it is not a widely recognized or standard Linux command. The above is a generic representation.


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specific options for <I>xsetmode</I> are not documented as it is not a standard command. Any functionality it might have provided would likely involve specifying a device and its desired mode (e.g., 'relative', 'absolute', 'on', 'off').<br><br>


title: DESCRIPTION
content:
<I>xsetmode</I> is not a standard or commonly available command in modern Linux distributions. Its name suggests a function related to setting or controlling operating modes for input devices within the X Window System (like keyboards or pointing devices). Historically, X Window System input devices could operate in different modes, such as relative (for mice, reporting movement deltas) or absolute (for tablets, reporting screen coordinates). If such a command existed as a standalone utility, it would likely have provided a command-line interface to toggle or configure these device-specific operating modes. However, its functionalities are now typically handled by other standard utilities like <I>xset</I>, <I>xinput</I>, or through configuration files specific to the X server or input drivers.


title: CAVEATS
content:
<I>xsetmode</I> is <b>not</b> a standard Linux command and does not typically come installed with common distributions. Information about it is extremely scarce, suggesting it might be:<br><ul><li>A deprecated or very old utility no longer in use.</li><li>Part of a very specific, niche X Window System setup or driver.</li><li>A misunderstanding, possibly referring to a function within <I>xset</I> (e.g., <I>xset r on</I> for auto-repeat mode) or an X API call.</li><li>A typo for a similar command like <I>xset</I> or <I>xmodmap</I>.</ul>It is not recommended to search for or rely on this command for general X Window System configuration.


title: MODERN ALTERNATIVES
content:
For managing X Window System input device properties and behaviors in modern Linux environments, consider using the <I>xinput</I> command. It provides comprehensive control over devices, including listing, setting properties, and enabling/disabling them. Keyboard-specific modes and layouts are typically managed with <I>setxkbmap</I>.


title: HISTORY
content:
The history of a standalone <I>xsetmode</I> command is largely undocumented, pointing to its non-standard nature. Concepts related to setting input device modes have existed since early versions of the X Window System. However, these functionalities were either managed through direct X server configuration, specific driver settings, or later integrated into more general-purpose utilities like <I>xset</I> (for general X server settings) and <I>xinput</I> (for X input device management), rather than a distinct <I>xsetmode</I> command. If it ever existed, it was likely an obscure or internal utility, or its functionality was absorbed into other commands.


title: PARAMETERS
content:
<b><i>pointer_type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default pointer shape for the X server. Common values include <i>arrow</i>, <i>cross</i>, <i>hand</i>, <i>ibeam</i>, <i>question</i>, <i>watch</i>, <i>xterm</i>, <i>plus</i>, and various angle shapes (e.g., <i>ul_angle</i>, <i>lr_angle</i>). Some types like <i>size</i> may require an additional numeric argument.<br><br>


title: DESCRIPTION
content:
<b>xsetpointer</b> is a utility for the X Window System that allows users to change the default pointer (cursor) shape displayed by the X server. Unlike modern tools that manage physical input devices or cursor themes, <b>xsetpointer</b> specifically targets the server's default pointer glyph, which is used when no specific window or application has set its own cursor. This command is particularly useful in environments where a specific default cursor appearance is desired globally for the X session, or for testing purposes related to X server pointer behavior. It operates by sending a request to the X server to switch its default cursor shape to one of several predefined types, such as an <i>arrow</i>, <i>crosshair</i>, or text <i>I-beam</i>. It's an older command, often found in X.Org installations, and its functionality for end-users has largely been superseded by desktop environment settings and cursor theme management.


title: CAVEATS
content:
<b>Deprecation/Modern Alternatives</b>: This command is relatively old and its direct use for customizing the cursor is largely superseded by modern desktop environment settings and cursor theme configurations (e.g., using <i>xcursor-themes</i> or GNOME/KDE settings).<br><br><b>Limited Scope</b>: It only affects the <i>default</i> server pointer. Once an application or window sets its own cursor, <b>xsetpointer</b>'s setting is overridden for that specific context.<br><br><b>Availability</b>: May not be installed by default on all minimal X installations or modern Linux distributions that favor <b>xinput</b> or desktop environment configuration tools.


title: PURPOSE
content:
While seemingly basic, <b>xsetpointer</b> can be useful for debugging pointer issues or ensuring a specific default cursor appearance in specialized kiosk or embedded X environments where a full desktop environment is not running.


title: INTERACTION WITH APPLICATIONS
content:
It's important to understand that <b>xsetpointer</b> only sets the <i>default</i> pointer. Applications can, and usually do, set their own specific cursors when the pointer is over their windows (e.g., an <i>I-beam</i> over text, a <i>hand</i> over a link). The <b>xsetpointer</b> setting will only be visible when the pointer is outside any application window that has defined its own cursor, or in contexts where the X server explicitly uses its default.


title: HISTORY
content:
<b>xsetpointer</b> has been a part of the X Window System utilities for a long time, dating back to earlier versions of X11 (e.g., X11R6). It provided a simple way to define the server's default cursor appearance. Its functionality reflects a time when X server configuration was more granular and directly managed via command-line utilities. While still present in many X.Org installations, its practical usage for end-users has diminished as graphical desktop environments and more advanced input configuration tools like <b>xinput</b> have become prevalent.


title: PARAMETERS
content:
<b><b>-display</b> <I>display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to.<br><br><b><b>-fg</b> <I>color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the foreground color for patterns (used with <b>-mod</b> or <b>-bitmap</b>).<br><br><b><b>-bg</b> <I>color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background color for patterns (used with <b>-mod</b> or <b>-bitmap</b>).<br><br><b><b>-mod</b> <I>x y</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a plaid-like pattern using specified foreground/background colors. <i>x</i> and <i>y</i> are integers.<br><br><b><b>-gray</b> or <b>-grey</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background to a built-in gray bitmap pattern.<br><br><b><b>-bitmap</b> <I>filename</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the bitmap specified by <i>filename</i> to tile the background.<br><br><b><b>-solid</b> <I>color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background to a solid color.<br><br><b><b>-cursor</b> <I>fontname maskfontname</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the root window cursor using a glyph from <i>fontname</i> and a mask from <i>maskfontname</i>.<br><br><b><b>-cursor_name</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the root window cursor by a standard X cursor name (e.g., "top_left_arrow").<br><br><b><b>-def</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the background to the default (usually a black and white checkerboard or solid white).<br><br><b><b>-name</b> <I>string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the name of the root window to <i>string</i>.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the program version and exits.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a summary of command-line options and exits.<br><br>


title: DESCRIPTION
content:
<i>xsetroot</i> is a command-line utility for manipulating the root window of an X server. It allows users to set various properties, including the background color, a tiled background pattern (from a bitmap file or a generated plaid pattern), and the appearance of the root window's cursor. While modern desktop environments often provide their own graphical tools for background customization, <i>xsetroot</i> remains valuable for minimalist window managers or for scripting direct root window modifications. It provides fine-grained control over the initial visual state of the X desktop. The command is a fundamental part of the X Window System utilities, offering a simple yet powerful way to personalize the base desktop appearance directly from the command line.


title: CAVEATS
content:
While <i>xsetroot</i> is effective for setting basic root window properties, it does not manage or persist these settings across X server restarts or user sessions without explicit scripting (e.g., in ~/.xinitrc). Modern desktop environments (like GNOME, KDE, XFCE) typically override or provide their own background management utilities, making <i>xsetroot</i> less commonly used directly by end-users in such environments. It also doesn't handle modern image formats like JPEG or PNG directly; for those, other tools like <i>feh</i> or <i>nitrogen</i> are typically required.


title: HISTORY
content:
<i>xsetroot</i> is a venerable utility originating from the early versions of the X Window System, a core component of Unix-like operating systems since the 1980s. It was designed to provide fundamental control over the appearance of the root window, which serves as the base layer for all other windows. Its simplicity and direct interaction with X properties have ensured its continued relevance, particularly in minimalist X setups where heavier desktop environments are not used. Despite the evolution of more sophisticated background management tools, <i>xsetroot</i> remains a testament to the modular and extensible design principles of X.


title: SYNOPSIS
content:
<b>xsetwacom</b> <i>[options] [command [arguments]]</i><br><br>Common usage patterns:<br><code><b>xsetwacom</b> <b>--list</b> <i>devices</i></code><br><code><b>xsetwacom</b> <b>--list</b> <i>parameters</i> <I>&lt;device_name_or_id&gt;</I></code><br><code><b>xsetwacom</b> <b>set</b> <I>&lt;device_name_or_id&gt;</I> <I>&lt;parameter_name&gt;</I> <I>&lt;value&gt;</I></code><br><code><b>xsetwacom</b> <b>get</b> <I>&lt;device_name_or_id&gt;</I> <I>&lt;parameter_name&gt;</I></code>


title: PARAMETERS
content:
<b>--list devices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all detected Wacom devices with their types and IDs. Useful for identifying target devices.<br><br><b>--list parameters <device></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all configurable parameters and their current values for a specified device.<br><br><b>--list options</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists global `xsetwacom` options that can be applied to the command itself.<br><br><b>set <device> Area <x1> <y1> <x2> <y2></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the usable tablet area in tablet coordinates (e.g., 0 0 20000 15000).<br><br><b>set <device> Button <button_number> <action></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns an action (e.g., mouse button click, key press, or a command) to a tablet or stylus button.<br><br><b>set <device> MapToOutput <output_name_or_resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maps the tablet's input area to a specific monitor or a specified screen resolution (e.g., 'HDMI-1', '1920x1080+0+0').<br><br><b>set <device> PressureCurve <x1> <y1> <x2> <y2></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the pressure response curve, represented by a Bezier curve defined by four control points (0-100 range).<br><br><b>set <device> Mode Absolute|Relative</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the input mode for the device: 'Absolute' for direct screen mapping, 'Relative' for mouse-like movement.<br><br><b>set <device> Rotate none|half|cw|ccw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rotates the tablet input coordinate system by 0, 180, 90 (clockwise), or -90 (counter-clockwise) degrees.<br><br><b>set <device> Threshold <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the pressure threshold for a tap to be registered as a click.<br><br><b>set <device> TapTime <milliseconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum time duration for a tap to register as a single click.<br><br><b>set <device> EnableTouch on|off</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables touch input functionality for devices that support it.<br><br>


title: DESCRIPTION
content:
<b>xsetwacom</b> is a command-line utility used to configure Wacom pen tablets and other Wacom devices within the X Window System environment. It allows users to dynamically adjust various properties of their Wacom devices, such as mapping the tablet area to a screen, setting pressure sensitivity curves, configuring button actions, adjusting scroll and pan settings, and enabling/disabling touch input or gestures. This tool is particularly useful for fine-tuning tablet behavior beyond graphical settings tools, for scripting custom configurations, or for troubleshooting. It interacts directly with the `xf86-input-wacom` X.Org driver, providing detailed control over individual input devices (stylus, eraser, touch, pad). Settings made with <b>xsetwacom</b> are typically session-specific and will revert upon logout or system reboot unless saved and reloaded through startup scripts or X.Org configuration files.


title: CAVEATS
content:
Settings made with <b>xsetwacom</b> are session-specific and are generally not persistent across system reboots or user logouts. To make settings permanent, they typically need to be added to a startup script (e.g., in a desktop environment's autostart options), a display manager's configuration, or an X.Org configuration file (e.g., <code>/etc/X11/xorg.conf.d/</code>).<br><br>This command operates within the X Window System and relies on the `xf86-input-wacom` X.Org driver. It is not directly applicable in Wayland environments, where tablet configuration is handled differently (e.g., through compositor-specific tools or `libinput` directly).


title: DEVICE IDENTIFICATION
content:
To use <b>xsetwacom</b> effectively, you first need to identify your specific Wacom devices. This can be done using <code><b>xsetwacom --list devices</b></code>. This command will output a list of detected Wacom devices, typically including a stylus, eraser, cursor, touch input, and pad (buttons/rings). Each device will have a name (e.g., "Wacom Intuos S Pen stylus") and an ID. You can use either the full name (quoted if it contains spaces) or the ID to target a device with <code><b>set</b></code> or <code><b>get</b></code> commands. For example:<br><code><b>xsetwacom</b> set "Wacom Intuos S Pen stylus" PressureCurve 0 20 80 100</code><br>or<br><code><b>xsetwacom</b> set <I>12</I> PressureCurve 0 20 80 100</code> (if 12 is the ID for the stylus).


title: HISTORY
content:
<b>xsetwacom</b> has been a fundamental utility for configuring Wacom tablets on Linux systems using the X Window System for many years. It was developed as part of the `xf86-input-wacom` driver project to provide a command-line interface for adjusting device properties, reflecting the flexibility and configurability inherent in X.Org's input architecture. While newer display servers like Wayland are emerging, <b>xsetwacom</b> remains essential for users on X.Org-based desktops who require fine-grained control over their Wacom devices. Its development has closely paralleled that of the Wacom Linux driver, adapting to new tablet features and X.Org input paradigms over time.


title: PARAMETERS
content:
<b>-display <I>display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to. This typically follows the format <I>hostname</I>:<I>display</I>.<I>screen</I>.<br><br><b>-session <I>session_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the session to use. If a session with this name has been saved previously, <b>xsm</b> will attempt to restore it.<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <b>xsm</b> to print verbose messages to standard error, useful for debugging.<br><br><b>-quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses verbose messages, overriding the default or other settings.<br><br><b>-geometry <I>geometry</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial size and location for the <b>xsm</b> window, if it displays one.<br><br><b>-builtin-save</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <b>xsm</b> to automatically save the current session state without prompting the user.<br><br><b>-shutdown</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the display manager (if present and supportive) to shut down the X server and potentially the system.<br><br><b>-reboot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests the display manager (if present and supportive) to reboot the system.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for <b>xsm</b> and then exits.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief usage message and then exits.<br><br>


title: DESCRIPTION
content:
The <b>xsm</b> command is the <I>X Session Manager</I>, a core component of the X Window System responsible for saving and restoring the state of a user's desktop session. It operates by communicating with session-aware client applications using the <I>X Session Management Protocol</I> (XSMP).<br><br>When a user logs out or requests a session save, <b>xsm</b> instructs registered applications to save their current state (e.g., window position, open documents, application settings). Upon logging back in or restoring a session, <b>xsm</b> retrieves this saved state and relaunches the applications, attempting to restore them to their previous condition.<br><br>While <b>xsm</b> provides the fundamental session management capabilities, in modern Linux desktop environments like GNOME or KDE, it often runs as a backend component, with the desktop environment's own session manager providing a higher-level user interface and managing the session lifecycle.


title: CAVEATS
content:
<b>xsm</b>'s ability to save and restore application states heavily relies on applications being 'session-aware' and correctly implementing the X Session Management Protocol (XSMP). Many older or simpler X applications may not support session management. In modern desktop environments, direct interaction with <b>xsm</b> is rare, as the DE's own session manager typically handles these functions at a higher level, often using <b>xsm</b> as an underlying component. Session data is typically stored in the user's home directory, often under <I>~/.xsm</I>.


title: SESSION FILES
content:
When a session is saved, <b>xsm</b> typically creates a directory, often named <I>~/.xsm/</I> followed by a unique session ID. Within this directory, configuration files and scripts are stored that describe the state of applications and how to restart them.


title: INTERACTION WITH DISPLAY MANAGERS
content:
<b>xsm</b> is frequently started by an X Display Manager (like <b>xdm</b> or GDM/LightDM) upon user login. The display manager and <b>xsm</b> cooperate to manage the X session's lifecycle, including clean shutdown and restart procedures.


title: HISTORY
content:
<b>xsm</b> has been an integral part of the X Window System since the introduction of the X Session Management Protocol (XSMP). It emerged as a solution to provide a consistent user experience across X sessions, allowing users to resume their work exactly where they left off. It was developed as part of the X.Org X11 distribution. While its core functionality remains, its role has evolved from a directly user-facing tool to a more fundamental, background service, especially with the rise of comprehensive desktop environments that integrate session management seamlessly.


title: PARAMETERS
content:
<b>--port <port>, -p <port></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the TCP port number for the server to listen on (e.g., 8080).<br><br><b>--address <address>, -a <address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the IP address to bind to. Use <i>0.0.0.0</i> for all available network interfaces, or <i>127.0.0.1</i> for localhost.<br><br><b>--root <path>, -r <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the physical path to the web application's root directory. Defaults to the current working directory.<br><br><b>--apppath <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the virtual path under which the application will be accessible (e.g., <i>/myapp</i>).<br><br><b>--verbose, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, displaying detailed server activity and debugging information.<br><br><b>--nonstop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps the server running even if errors occur within the application, preventing it from crashing.<br><br><b>--applications <virtual_path>:<physical_path>[,...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows serving multiple ASP.NET applications from different virtual and physical paths simultaneously.<br><br><b>--configfile <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an alternative path to the <i>web.config</i> file for the application.<br><br>


title: DESCRIPTION
content:
<b>xsp</b> is a command-line utility that provides a simple, lightweight web server specifically designed for testing and developing ASP.NET applications built with the Mono framework. It allows developers to quickly run and debug their ASP.NET websites and web services without needing to deploy them to a full-fledged web server like Apache with mod_mono or Nginx with FastCGI.<br><br><b>xsp</b> directly serves ASP.NET content by processing <i>.aspx</i>, <i>.asmx</i>, <i>.ashx</i> files, etc., using the Mono runtime. It is primarily intended for local development and <i>not</i> recommended for production environments due to its limited features and lack of robustness compared to production-grade servers.


title: CAVEATS
content:
<b>xsp</b> is strictly for development and testing purposes. It lacks features crucial for production environments, such as robust request handling, security hardening, performance optimization, and extensive logging. It should never be exposed directly to the internet or used in a production setting.


title: USAGE EXAMPLES
content:
To run an ASP.NET application located in the current directory on port 8080:<br> <b>xsp -p 8080</b><br><br>To run an application from a specific directory <i>/var/www/mywebapp</i> on port 9000, accessible at <i>http://localhost:9000/myapp</i>: <br> <b>xsp -p 9000 -r /var/www/mywebapp --apppath /myapp</b>


title: HISTORY
content:
<b>xsp</b> was developed as part of the Mono Project, an open-source implementation of Microsoft's .NET Framework, initiated by Miguel de Icaza in 2001. It provided a crucial development tool for early adopters and developers building web applications with Mono's ASP.NET stack, predating the widespread adoption of .NET Core.


title: SYNOPSIS
content:
<b>xstdcmap</b> [<I>-best</I> | <I>-default</I> | <I>-gray</I> | <I>-red</I> | <I>-green</I> | <I>-blue</I> | <I>-delete</I>] [<I>-namestoo</I>] [<I>-verbose</I>] [<I>-display <I>display</I></I>]


title: PARAMETERS
content:
<b><I>-best</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_BEST_MAP</I> standard colormap. This map provides the best visual approximation for the display.<br><br><b><I>-default</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_DEFAULT_MAP</I> standard colormap. This is typically a basic colormap providing a good range of colors.<br><br><b><I>-gray</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_GRAY_MAP</I> standard colormap, optimized for grayscale representation.<br><br><b><I>-red</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_RED_MAP</I> standard colormap, providing a ramp for red intensity.<br><br><b><I>-green</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_GREEN_MAP</I> standard colormap, providing a ramp for green intensity.<br><br><b><I>-blue</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs an <I>RGB_BLUE_MAP</I> standard colormap, providing a ramp for blue intensity.<br><br><b><I>-delete</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the specified standard colormaps (or all if no colormap type is explicitly given).<br><br><b><I>-namestoo</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates standard colormaps for all known standard colormap atoms, including those beyond the primary <i>RGB_*_MAP</i> types.<br><br><b><I>-verbose</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose messages during execution, showing details about the colormap operations.<br><br><b><I>-display <I>display</I></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to. The <I>display</I> argument should be in the format <I>hostname:displaynumber.screennumber</I>.<br><br>


title: DESCRIPTION
content:
<b>xstdcmap</b> is an X Window System utility designed to manage and install standard colormaps for an X display.<br><br>In older X setups, particularly those with pseudo-color (8-bit) displays, applications often relied on predefined colormaps (like <i>RGB_BEST_MAP</i> or <i>RGB_DEFAULT_MAP</i>) to correctly render colors. <b>xstdcmap</b> allows a user to explicitly install one of these standard colormaps, making it available for applications that query for them via specific X atoms. <br><br>While less crucial in the era of true-color (24-bit or 32-bit) displays, it remains relevant for legacy applications, specific scientific visualization tools, or niche environments that still utilize indexed color models. The utility can install various types of standard colormaps, such as optimized "best" maps, default maps, or grayscale maps, as well as separate red, green, and blue ramp maps. It can also be used to delete existing standard colormaps.


title: CAVEATS
content:
<b>xstdcmap</b> is primarily useful for pseudo-color (8-bit) X displays. It is less relevant for modern true-color (24-bit or 32-bit) displays where applications typically manage their own colors directly without relying on shared colormaps. Misuse or incorrect application of standard colormaps can potentially affect color rendering for other legacy applications on the same display.


title: STANDARD COLORMAPS EXPLAINED
content:
Standard colormaps are specific shared colormaps defined by the X Consortium, identified by atoms like <I>RGB_BEST_MAP</I>, <I>RGB_DEFAULT_MAP</I>, etc. They allow applications to share a common set of colors, which was essential on pseudo-color displays where only a limited number of colors could be displayed simultaneously. By installing a standard colormap, <b>xstdcmap</b> makes a predefined color palette available for applications that expect or request it.


title: XDGA_STANDARD_CMAP ATOM
content:
Applications often query for standard colormaps through the <I>XDGA_STANDARD_CMAP</I> atom on the root window of the X display. When <b>xstdcmap</b> installs a standard colormap, it sets this property, making the installed colormap discoverable and usable by applications designed to look for it.


title: HISTORY
content:
<b>xstdcmap</b> is an integral part of the X.Org (and previously XFree86 and X11R5/X11R6) distribution. Its functionality predates widespread true-color displays, originating in an era where shared colormaps were crucial for efficient color management on hardware with limited color capabilities. While its primary use case has diminished with modern display technology, it remains available for compatibility with legacy software and specific industrial or scientific applications that rely on indexed color models and standard X colormaps. The command has not undergone significant development or changes in recent years, maintaining its original purpose.


title: SYNOPSIS
content:
xsubpp [-C] [-nolinkage] [-typemap <i>file</i>] [-proto|-prototypes] <br>[-noprototypes] [-stubs <i>file</i>] [-nostubs] [-q|-quiet] [-o <i>file</i>] [<i>inputfile</i>]


title: PARAMETERS
content:
<b>-C</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retain C comments in the output C code, which can be useful for debugging the generated code.<br><br><b>-nolinkage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate the XS_BOOT_TYPEMAP and XS_APIVERSION linkage code. This option is typically used internally when building specific parts of Perl itself.<br><br><b>-typemap <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an additional typemap file to use. Typemaps define how C types are converted to and from Perl scalars, facilitating seamless data exchange between Perl and C.<br><br><b>-proto, -prototypes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the generation of prototypes for all XSUBs (XS subroutines). This ensures stricter argument checking at compile time, catching potential errors early.<br><br><b>-noprototypes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the generation of prototypes for XSUBs, overriding any default behavior or directives in the XS code. This might be used for compatibility with older compilers or specific build setups.<br><br><b>-stubs <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate stub functions to the specified <i>file</i>. Stubs are small C functions that provide an interface for static linking with Perl libraries, useful in scenarios where dynamic loading is not an option.<br><br><b>-nostubs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate stub functions, suitable for environments where dynamic loading of Perl modules is always the preferred or only method.<br><br><b>-q, -quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress verbose output and warnings during the processing of the XS file, leading to a cleaner build log.<br><br><b>-o <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output C file. If this option is omitted, <i>xsubpp</i> writes the generated C code to standard output (stdout).<br><br><b><i>inputfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the input XS source file (e.g., <i>MyModule.xs</i>). If omitted, <i>xsubpp</i> reads the XS source from standard input (stdin).<br><br>


title: DESCRIPTION
content:
<i>xsubpp</i> is a vital internal utility within the Perl ecosystem, specifically designed to process Perl XS (eXtension Subroutine) source files. XS is a language that allows Perl modules to be written partly in C or C++, enabling Perl to interface with external C libraries or for performance-critical sections. <i>xsubpp</i> takes an <i>.xs</i> file as input, which contains a mix of Perl and C code, and translates it into a <i>.c</i> file. This generated <i>.c</i> file can then be compiled by a standard C compiler into a shared library (e.g., <i>.so</i> on Linux, <i>.dll</i> on Windows), which Perl can dynamically load.<br><br>While <i>xsubpp</i> is a standalone executable, it is almost exclusively invoked indirectly by Perl's build tools, such as <i>ExtUtils::MakeMaker</i> or <i>Module::Build</i>, through the <i>ExtUtils::ParseXS</i> module. Developers typically do not run <i>xsubpp</i> manually. Its primary role is to handle the interface glue between Perl and C, managing argument passing, return values, and type conversions, thereby simplifying the development of XS modules.


title: CAVEATS
content:
<i>xsubpp</i> is an internal utility primarily used by Perl's build system (e.g., <i>ExtUtils::MakeMaker</i> and <i>Module::Build</i>). It is generally not intended for direct manual invocation by end-users or even most module developers. Misuse can lead to incorrectly generated C code and compilation errors. Its options and behavior are tightly coupled with the <i>ExtUtils::ParseXS</i> module, which manages its invocation.


title: WHAT IS XS?
content:
XS (eXtension Subroutine) is a language specification used within Perl for writing modules that require high performance or direct interaction with C/C++ libraries. It allows developers to seamlessly integrate C code into Perl, handling the complexities of data type conversions and function calls between the two languages.


title: ROLE IN PERL MODULE COMPILATION
content:
When a Perl module contains XS code, the <i>Makefile.PL</i> (generated by <i>ExtUtils::MakeMaker</i>) or <i>Build.PL</i> script (from <i>Module::Build</i>) will orchestrate the compilation process. This typically involves <i>ExtUtils::ParseXS</i> calling <i>xsubpp</i> to convert <i>.xs</i> files to <i>.c</i> files, which are then compiled by a C compiler (like GCC) into a shared library. This shared library is what Perl loads when the module is <i>use</i>d, extending Perl's capabilities with compiled code.


title: HISTORY
content:
<i>xsubpp</i> has been a fundamental component of the Perl core distribution for many years, dating back to early versions of Perl 5. Its development is intertwined with the evolution of Perl's XS interface, enabling robust and efficient integration with C/C++ libraries. It has continuously evolved to support new Perl features and improve the C binding process, remaining a critical, though often unseen, tool for Perl's extensibility.


title: SEE ALSO
content:
perl(1), ExtUtils::ParseXS(3pm), ExtUtils::MakeMaker(3pm), Module::Build(3pm), perlxs(1), perlguts(1)


title: SYNOPSIS
content:
<b>xsv <I>subcommand</I> [<i>options</i>] [<i>arguments</i>]</b><br><br><i><b>Common Subcommands and their basic syntax:</b></i><br><b>xsv cat</b> <i>[--no-headers] {rows|columns} {file...}</i><br><b>xsv count</b> <i>[--delimiter <arg>] [file]</i><br><b>xsv filter</b> <i>[--delimiter <arg>] {pattern} [file]</i><br><b>xsv flatten</b> <i>[--delimiter <arg>] [file]</i><br><b>xsv headers</b> <i>[--delimiter <arg>] [file]</i><br><b>xsv index</b> <i>[--delimiter <arg>] [file]</i><br><b>xsv select</b> <i>[--delimiter <arg>] {column...} [file]</i><br><b>xsv sort</b> <i>[--delimiter <arg>] [--select <arg>] [file]</i><br><b>xsv stats</b> <i>[--delimiter <arg>] [--everything] [file]</i><br><b>xsv validate</b> <i>[--delimiter <arg>] [file]</i><br><br><i>Note: This is a simplified representation. Each subcommand has its own specific options and arguments.</i>


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays general help information or help for a specific subcommand (e.g., `xsv <I>subcommand</I> --help`).</i><br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shows the `xsv` version information.</i><br><br><b><b>-d <arg></b>, <b>--delimiter <arg></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the field delimiter character to use (e.g., `,`, `\t`, `|`). Defaults to comma.</i><br><br><b><b>-j <arg></b>, <b>--jobs <arg></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the number of parallel jobs (threads) to run for operations that can be parallelized.</i><br><br><b><b>-n</b>, <b>--no-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Treats the first row of data as a regular row rather than a header row.</i><br><br><b><b>-o <file></b>, <b>--output <file></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the output of the command to the specified `file` instead of standard output.</i><br><br><b><b>-s <arg></b>, <b>--select <arg></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Used by some subcommands to select columns by name or 1-based index (e.g., `Col1,Col2`, `1-3,5`).</i><br><br><b><b>--sniff-limit <N></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Limits the number of bytes to sniff when inferring the delimiter and whether or not there are headers.</i><br><br>


title: DESCRIPTION
content:
<i>`xsv` is a modern, high-performance command-line utility for working with CSV (Comma Separated Values) data.</i><br><i>Written in Rust, it emphasizes speed and efficiency, making it particularly suitable for processing large datasets.</i><br><i>It provides a comprehensive suite of subcommands to perform common CSV manipulation tasks directly from the terminal, including selection, filtering, sorting, joining, indexing, and analysis.</i><br><i>`xsv` aims to be a fast and reliable alternative to traditional scripting with `awk`, `cut`, or `grep` when dealing specifically with tabular data in CSV format.</i><br><i>Its capabilities extend from basic viewing to complex transformations, making it an invaluable tool for data scientists, developers, and anyone regularly handling structured text files.</i>


title: CAVEATS
content:
<i>While `xsv` is generally very efficient, some operations, especially those involving sorting or joining large datasets without prior indexing, might consume significant memory or disk space.</i><br><i>Indexing large files with `xsv index` can be resource-intensive initially but greatly speeds up subsequent operations like `select` or `filter`.</i><br><i>It strictly adheres to the CSV format, which means malformed CSV files might cause unexpected behavior or errors, although it has robust error handling for common issues.</i>


title: <B>SUBCOMMANDS OVERVIEW</B>
content:
<i>`xsv` is designed around a subcommand model, where each subcommand performs a specific task.</i><br><i>This modular approach allows users to chain operations using standard Unix pipes (`|`), creating powerful data processing pipelines.</i><br><i>Common subcommands include `select` (choose columns), `filter` (filter rows based on patterns), `sort` (sort rows), `join` (merge two CSV files), `index` (create an index for faster lookups), and `stats` (calculate statistics).</i>


title: <B>PERFORMANCE FOCUS</B>
content:
<i>A core design principle of `xsv` is performance.</i><br><i>By being written in Rust, it achieves remarkable speed, often outperforming tools written in other languages for large datasets.</i><br><i>This makes `xsv` an excellent choice for batch processing or integrating into scripts where speed is critical.</i>


title: HISTORY
content:
<i>`xsv` was developed by BurntSushi (Andrew Gallant), a prominent Rust developer, with a strong focus on performance and correctness.</i><br><i>It was created to provide a robust and extremely fast alternative to existing CSV processing tools, leveraging Rust's memory safety and concurrency features.</i><br><i>First released around 2015, its development has been driven by the need for efficient handling of large CSV files, quickly gaining popularity in the data science and bioinformatics communities for its speed and reliability.</i>


title: SEE ALSO
content:
<b>csvkit</b> (Python-based CSV utilities), <b>awk</b>(1) (pattern scanning and processing language), <b>cut</b>(1) (remove sections from each line of files), <b>grep</b>(1) (print lines matching a pattern), <b>sed</b>(1) (stream editor for filtering and transforming text), <b>mlr</b>(1) (Miller, like sed/awk/cut/join/sort for name-indexed data)


title: SYNOPSIS
content:
<i>command-name</i> <i>[options] [arguments]</i><br><i>Note:</i> <i>command-name</i> is a symbolic link pointing to <b>xtables-multi</b> (e.g., <i>iptables</i>, <i>ip6tables</i>, <i>arptables</i>, <i>ebtables</i>, <i>iptables-restore</i>, etc.).


title: PARAMETERS
content:
<b><i>-h, --help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message for the specific Netfilter tool being emulated (e.g., <i>iptables</i>, <i>ip6tables</i>). The content of the help message is determined by the command invoked via the symbolic link.<br><br><b><i>-V, --version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for the <b>xtables-multi</b> binary and the Netfilter libraries it is built against. This provides details about the overall xtables suite version.<br><br>


title: DESCRIPTION
content:
<b>xtables-multi</b> is a versatile, single executable designed to consolidate the functionality of multiple Linux Netfilter packet filtering and NAT administration utilities. Rather than having separate binaries for commands like <i>iptables</i>, <i>ip6tables</i>, <i>arptables</i>, <i>ebtables</i>, and their corresponding <i>-restore</i> and <i>-save</i> counterparts, <b>xtables-multi</b> serves as a multi-call binary.<br><br>When invoked, it determines which specific Netfilter utility to emulate by inspecting the name it was called with (<i>argv[0]</i>). This is typically achieved by creating symbolic links from the desired command names (e.g., <i>/usr/sbin/iptables</i>) to the <b>xtables-multi</b> binary itself. This approach significantly reduces disk space usage, simplifies software distribution, and streamlines system administration by centralizing the binaries for these related tools. The behavior and command-line arguments are identical to those of the individual tools it impersonates.


title: CAVEATS
content:
The functionality of <b>xtables-multi</b> is entirely dependent on the name it is invoked as. If symbolic links are not correctly established, or if the binary is invoked directly without a symlink, its behavior might be unpredictable or it might display an error indicating it doesn't know what command to impersonate. Users must refer to the specific man pages of <i>iptables</i>, <i>ip6tables</i>, etc., for detailed command-line options and usage, as <b>xtables-multi</b> itself only acts as a dispatcher.


title: USAGE VIA SYMBOLIC LINKS
content:
The primary method of using <b>xtables-multi</b> is through symbolic links. System administrators typically create links such as <i>/usr/sbin/iptables -> /usr/sbin/xtables-multi</i>. When <i>iptables</i> is executed, the kernel resolves the symlink, and <b>xtables-multi</b> is invoked. It then checks <i>argv[0]</i> (which will be '<i>iptables</i>' in this case) and executes the corresponding <i>iptables</i> functionality.


title: SUPPORTED EMULATED COMMANDS
content:
<b>xtables-multi</b> can emulate a range of Netfilter commands, including but not limited to:<br><ul><li><i>iptables</i></li><li><i>ip6tables</i></li><li><i>arptables</i></li><li><i>ebtables</i></li><li><i>iptables-restore</i></li><li><i>ip6tables-restore</i></li><li><i>arptables-restore</i></li><li><i>ebtables-restore</i></li><li><i>iptables-save</i></li><li><i>ip6tables-save</i></li><li><i>arptables-save</i></li><li><i>ebtables-save</i></li></ul><br>The exact list might vary slightly based on the Netfilter package version and build configuration.


title: HISTORY
content:
The concept of a multi-call binary like <b>xtables-multi</b> emerged as part of the broader Netfilter project in Linux. Its development was driven by the desire for efficiency and maintainability. By consolidating multiple related executables into a single binary, it reduces overhead, simplifies packaging for Linux distributions, and ensures consistency across different Netfilter tools. This design has been a standard practice for many years in modern Linux systems, reflecting a mature approach to managing the diverse set of Netfilter utilities.


title: SYNOPSIS
content:
<b>xteddy</b> [<i>-display <I>display</I></i>] [<i>-geometry <I>geometry</I></i>] [<i>-speed <I>n</I></i>] [<i>-eyes <I>color</I></i>] [<i>-nose <I>color</I></i>] [<i>-belly <I>color</I></i>] [<i>-body <I>color</I></i>] [<i>-arms <I>color</I></i>] [<i>-ears <I>color</I></i>] [<i>-sleep</i> | <i>-awake</i>] [<i>-reverse</i>] [<i>-name <I>name</I></i>] [<i>-title <I>title</I></i>] [<i>-iconic</i>] [<i>-xrm <I>resource</I></i>] [<i>-help</i>] [<i>-version</i>]


title: PARAMETERS
content:
<b><b>-speed</b> <i>n</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the animation speed of the teddy bear. A higher numerical value typically results in faster eye movement.<br><br><b><b>-eyes</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the color of the teddy bear's eyes. Can be a color name (e.g., 'blue') or a hexadecimal RGB value (e.g., '#0000FF').<br><br><b><b>-nose</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the color of the teddy bear's nose.<br><br><b><b>-belly</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color of the teddy bear's belly.<br><br><b><b>-body</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the main body color of the teddy bear.<br><br><b><b>-arms</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color of the teddy bear's arms.<br><br><b><b>-ears</b> <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the color of the teddy bear's ears.<br><br><b><b>-sleep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the teddy bear in a 'sleeping' state with its eyes closed. It will 'wake up' if the mouse cursor passes over it.<br><br><b><b>-awake</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the teddy bear in an 'awake' state, with its eyes open and actively following the mouse cursor. This is often the default behavior.<br><br><b><b>-display</b> <i>display</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server display to connect to, useful for remote or multi-display setups.<br><br><b><b>-geometry</b> <i>WxH+X+Y</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the preferred size and position of the teddy bear on the screen. While its size might be fixed, the position (X,Y) might be respected.<br><br><b><b>-reverse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts or mirrors the image of the teddy bear horizontally.<br><br><b><b>-name</b> <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the application's instance name, which can be used by X resource files for customization.<br><br><b><b>-iconic</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to start the application in an iconified (minimized) state, though this may have limited effect for root window applications.<br><br><b><b>-title</b> <i>title</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the window title for the application. Similar to <b>-iconic</b>, its visibility may be limited for root window apps.<br><br><b><b>-xrm</b> <i>resource</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an X resource string to be loaded, allowing for direct command-line overrides of X resources.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message detailing the available command-line options for <b>xteddy</b>.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the version information of the <b>xteddy</b> program.<br><br>


title: DESCRIPTION
content:
The <b>xteddy</b> command is a delightful X11 application that displays an animated teddy bear directly on the root window of your X desktop. As you move your mouse cursor, the teddy bear's eyes amusingly follow its movement, adding a playful and interactive element to your traditional X session. <br><br>Users have the ability to customize various aspects of the bear's appearance, including its body, eyes, nose, and belly colors, as well as adjusting its animation speed. Originally conceived as a fun novelty program, <b>xteddy</b> serves as a historical example of standalone X applications designed for desktop personalization and lighthearted amusement. It showcases the direct interaction capabilities with the X Window System's fundamental root window, allowing for unique desktop embellishments.


title: CAVEATS
content:
<b>xteddy</b> is an older X11 application that draws directly onto the X root window. This method of display can lead to compatibility issues or visual anomalies in modern desktop environments that extensively use compositing (e.g., GNOME, KDE Plasma with compositing enabled) or alternative display protocols like Wayland (without XWayland). Its functionality may be limited, or it might not appear as expected on such systems. As it is not actively maintained, its future compatibility with evolving display technologies is uncertain.<br><br>Options typically associated with standard windowed applications, such as <b>-geometry</b>, <b>-iconic</b>, and <b>-title</b>, might have little to no discernible effect, as <b>xteddy</b> operates as a desktop overlay rather than a traditional framed window.


title: ROOT WINDOW OPERATION
content:
Unlike most contemporary applications that reside within their own framed windows, <b>xteddy</b> draws directly onto the 'root window' of the X server. The root window is essentially the desktop background, the fundamental canvas upon which all other application windows are drawn. This design choice allows <b>xteddy</b> to appear as an integral part of the desktop background, seamlessly blending in rather than being perceived as a separate, movable application window.


title: CUSTOMIZATION WITH X RESOURCES
content:
Beyond command-line options, <b>xteddy</b> supports customization through X resources. Users can specify default settings for colors, speeds, and other attributes within their <i>~/.Xresources</i> or <i>~/.Xdefaults</i> file. For instance, to set the bear's body color to 'brown' and its eyes to 'black', you could add the following lines:<br><i>XTeddy*body: brown</i><br><i>XTeddy*eyes: black</i><br>These resources, typically loaded by the X server at startup via <i>xrdb</i>, would then be applied to <b>xteddy</b> whenever it is launched, providing persistent customization.


title: HISTORY
content:
<b>xteddy</b> represents a charming piece of X11 history, created by E.M. Sager and often included in collections of X11 utilities. Its original intent was not utilitarian, but rather to demonstrate the graphical capabilities of the X Window System and to provide a touch of amusement and personalization to the user's desktop. Its development and widespread usage were most prominent during the late 1990s and early 2000s, an era when direct manipulation of the X root window was a common practice for desktop embellishments. Although it has not seen active development in recent years, <b>xteddy</b> continues to be available in many Linux distribution repositories, serving as both a nostalgic application and a simple demonstration of classic X windowing principles.


title: PARAMETERS
content:
<b>-geometry <i>geometry</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial size and position of the <i>xterm</i> window (e.g., <i>80x24+0+0</i>).<br><br><b>-font <i>font</i> / -fn <i>font</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the font to be used for displaying text within the terminal.<br><br><b>-background <i>color</i> / -bg <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background color of the terminal window.<br><br><b>-foreground <i>color</i> / -fg <i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the foreground (text) color of the terminal window.<br><br><b>-name <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the application name for X resource lookups, affecting customizations.<br><br><b>-title <i>title</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the window title string displayed in the window manager's title bar.<br><br><b>-e <i>command</i> [<i>arguments</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified command inside the <i>xterm</i> window instead of a shell.<br><br><b>-hold</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <i>xterm</i> to remain open after the command specified with <i>-e</i> exits.<br><br><b>-sb</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the scrollbar for the terminal window.<br><br><b>-sl <i>number</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of lines to save in the scrollback buffer.<br><br><b>-tn <i>name</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the terminal type name to be set in the TERM environment variable (e.g., <i>xterm-256color</i>).<br><br><b>-xrm <i>resourcestring</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an X resource string to be merged with the defaults, allowing fine-tuned customization.<br><br>


title: DESCRIPTION
content:
<i>xterm</i> is the standard terminal emulator for the <br><b>X Window System</b>, providing a command-line interface within a <br>graphical environment. Originally developed at <br>MIT as part of Project Athena in 1984, it is one of the oldest <br>and most mature terminal emulators available. <i>xterm</i> supports <br>DEC <br>VT102 and Tektronix 4014 emulation, offering robust capabilities <br>for interacting with shell programs and other text-based applications. <br><br>Known for its extensive configurability, <i>xterm</i> allows <br>users to customize nearly every aspect, from fonts and colors <br>to key bindings and scrolling behavior, primarily through <br>X resources. Its venerable age also means it has served as a <br>reference implementation, influencing the design and behavior <br>of many modern terminal emulators. Despite newer, feature-rich <br>alternatives, <i>xterm</i> remains a staple for its stability, <br>reliability, and adherence to established terminal standards.


title: CAVEATS
content:
<i>xterm</i>'s extensive configuration options, primarily <br>through X resources, can be overwhelmingly complex for new <br>users. While highly customizable, its default appearance and <br>feature set (e.g., no native tab support, older font rendering) <br>might feel dated compared to modern terminal emulators. <br>Truecolor support and certain advanced graphics features may <br>require specific patches or configurations not available out-of-the-box.


title: X RESOURCES
content:
<i>xterm</i> is extensively configured via X resources, <br>which are parameters loaded from files like <br><i>~/.Xresources</i>, <i>~/.Xdefaults</i>, or set via <br><i>xrdb</i>. This mechanism allows fine-grained control over <br>colors, fonts, key bindings, scrollback, and many other <br>behaviors, offering a level of customization not always apparent <br>from command-line options alone.


title: VT102 AND TEKTRONIX 4014 EMULATION
content:
A key feature of <i>xterm</i> is its ability to <br>emulate two historically significant terminals: the <br>DEC <br>VT102 and the <br>Tektronix 4014. VT102 emulation provides standard text-based <br>interaction, while Tektronix 4014 emulation offers support for <br>vector graphics, a feature less commonly used today but <br>historically important for certain scientific and engineering <br>applications.


title: HISTORY
content:
<i>xterm</i> was originally developed by <br><i>Mark Vandevoorde</i> and <br><i>Tony Della Fera</i> at <br>Digital Equipment Corporation (DEC) for the <br>X Window System, as part of <br>MIT's <br>Project Athena. It was first released in 1984 as a core <br>component of the inaugural X Window System distribution. <br>Over the decades, <i>xterm</i> has been maintained and continually <br>updated by various contributors, becoming a stable and reliable <br>fixture in Unix-like environments. Its long history and adherence <br>to established terminal standards have made it a de facto <br>reference implementation, influencing the design and behavior <br>of countless subsequent terminal emulators.


title: PARAMETERS
content:
<b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-help</b><br><i>Displays a concise help message and exits.</i><br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-version</b><br><i>Shows the version information of xtotroff and exits.</i><br><br><b>-file FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-file</b> <i>FILE</i><br><i>Specifies the input file to be displayed. If no file is specified, xtotroff reads from standard input.</i><br><br><b>-dev DEVICE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-dev</b> <i>DEVICE</i><br><i>Sets the output device for groff when processing raw troff source. For example, 'ps' for PostScript.</i><br><br><b>-page N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-page</b> <i>N</i><br><i>Starts the display at the specified page number N.</i><br><br><b>-zoom N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-zoom</b> <i>N</i><br><i>Sets the initial zoom factor for the displayed document.</i><br><br><b>-scale N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-scale</b> <i>N</i><br><i>Sets the scaling factor for the rendered output.</i><br><br><b>-delay N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-delay</b> <i>N</i><br><i>Sets a delay in milliseconds, primarily for internal or animated output processing.</i><br><br><b>-wait</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-wait</b><br><i>Causes xtotroff to wait for input on standard input before displaying.</i><br><br><b>-nofork</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-nofork</b><br><i>Prevents xtotroff from forking into the background, useful for debugging.</i><br><br><b>-debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-debug</b><br><i>Enables debugging output to the console, aiding in troubleshooting.</i><br><br><b>-Xgeometry GEOMETRY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-Xgeometry</b> <i>GEOMETRY</i><br><i>Sets the initial size and position of the X window (e.g., 800x600+100+50).</i><br><br><b>-fg COLOR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-fg</b> <i>COLOR</i><br><i>Specifies the foreground color of the X window.</i><br><br><b>-bg COLOR</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-bg</b> <i>COLOR</i><br><i>Specifies the background color of the X window.</i><br><br><b>-font FONT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-font</b> <i>FONT</i><br><i>Sets the font for page number display or other UI elements within the window.</i><br><br><b>-rv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-rv</b><br><i>Enables reverse video, swapping the foreground and background colors.</i><br><br><b>-title TITLE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-title</b> <i>TITLE</i><br><i>Sets the title string that appears in the X window's title bar.</i><br><br><b>-name NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-name</b> <i>NAME</i><br><i>Specifies the application name for X resource lookups.</i><br><br><b>-display DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-display</b> <i>DISPLAY</i><br><i>Connects to the specified X display (e.g., ':0.0').</i><br><br><b>-sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>-sync</b><br><i>Forces synchronous X protocol requests, useful for debugging X applications but can slow performance.</i><br><br><b>files...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>files...</i><br><i>One or more input files. These can be raw <i>groff</i> source or pre-formatted output (e.g., PostScript). If no files are provided, input is read from standard input.</i><br><br>


title: DESCRIPTION
content:
<i>xtotroff</i> is a utility that displays formatted output from the <i>groff</i> document formatting system directly in an X Window System environment. It acts as a convenient viewer, allowing users to preview documents formatted with <i>groff</i> without needing to print them or convert them to other static formats like PDF first. Essentially, <i>xtotroff</i> can either take raw <i>troff</i> source files and pipe them through <i>groff</i> to generate output for display, or it can accept pre-formatted output, typically in PostScript format (produced by drivers like <i>grops</i>), and render it for viewing. It provides basic navigation and viewing capabilities within the X window, making it useful for interactive document development and proofreading.


title: CAVEATS
content:
<i>xtotroff</i> is a relatively older utility primarily designed for the X Window System. It relies on <i>groff</i> for processing input and often uses drivers like <i>grops</i> or <i>gxditview</i> internally for rendering. Its functionality might be limited compared to modern PDF or DVI viewers, and it is not actively developed for new features, but rather maintained within the <i>groff</i> project.


title: INPUT FORMATS
content:
<b>Input Formats</b><br><i>xtotroff can accept various input types. It can process raw <i>troff</i> source files by piping them through the <i>groff</i> command. Alternatively, it can directly display pre-formatted device-independent files, such as PostScript output generated by <i>grops</i>. This flexibility allows it to be used both for live document development and for viewing already processed documents.</i>


title: INTERNAL OPERATION
content:
<b>Internal Operation</b><br><i>When provided with <i>troff</i> source files, <i>xtotroff</i> internally invokes the <i>groff</i> command to format the document. The resulting output, often in PostScript format (using <i>grops</i>), is then rendered and displayed in the X window. For pre-formatted input, it directly uses its rendering capabilities or delegates to a suitable viewer like <i>gxditview</i> if available and configured.</i>


title: HISTORY
content:
<i>xtotroff</i> is part of the <i>groff</i> project, which is a free implementation of the <i>troff</i> text formatter. Its development aimed to provide a direct visual feedback mechanism for <i>groff</i> users within the X Window System environment, allowing for quick previewing of documents without requiring printing. While newer tools might offer more advanced features (like <i>gxditview</i> for GTK-based viewing or external PDF viewers for PostScript output), <i>xtotroff</i> continues to serve its original purpose as a lightweight X-based viewer for <i>groff</i> output.


title: DESCRIPTION
content:
<b>xtrlock</b> is a lightweight and extremely simple screen locker for the X Window System. Unlike many modern screen lockers, it does not blank the screen or display a fancy lock overlay. Instead, it works by grabbing the X server's keyboard and pointer input, effectively locking the session.<br><br>When activated, it typically opens an <i>xterm</i> (or similar terminal emulator) window to prompt the user for a password. Upon successful authentication (usually checking against the user's password or root password via <i>su</i> or <i>sudo</i>), the input devices are ungrabbed, and the X session is unlocked. Its primary appeal lies in its minimal resource usage and straightforward design, making it suitable for users who prioritize simplicity and do not require screen blanking or complex features. It's often used in conjunction with a hotkey or an idle timer to automatically lock the screen.


title: CAVEATS
content:
<b>xtrlock</b> does <i>not</i> blank the screen. This means the contents of your screen remain visible while locked, which can be a privacy concern in some environments.<br><br>It typically relies on an external terminal emulator (like <i>xterm</i>) to display the password prompt. If <i>xterm</i> is not installed or configured correctly, <b>xtrlock</b> may not function as expected.<br><br>Security relies on the robustness of the X server's input grabbing mechanism. While generally effective, it's a very basic locking mechanism compared to modern alternatives.<br><br>It might require elevated privileges (e.g., <i>setuid root</i>) to successfully grab input devices, depending on system configuration and X server permissions.


title: HOW IT WORKS
content:
<b>xtrlock</b> operates by making an X server request to 'grab' the keyboard and pointer devices. This prevents any other application or user from receiving input events until <b>xtrlock</b> releases the grab. The password prompt is then displayed in a new <i>xterm</i> window launched by <b>xtrlock</b>.


title: USAGE EXAMPLE
content:
Users often bind <b>xtrlock</b> to a keyboard shortcut (e.g., <i>Ctrl+Alt+L</i>) or configure their window manager to execute it after a period of inactivity to automatically lock the session.


title: HISTORY
content:
<b>xtrlock</b> is one of the earliest and most basic screen lockers developed for the X Window System. Its origins trace back to the early days of X, reflecting a design philosophy focused on minimal functionality and resource consumption. Unlike later, more feature-rich screen savers and lockers, <b>xtrlock</b>'s design has remained largely unchanged, emphasizing its core function of simply grabbing input and requiring a password without any visual flair or screen blanking capabilities. This simplicity has ensured its continued presence in minimalist Unix-like environments, even as more advanced locking solutions became available.


title: SYNOPSIS
content:
<b><I>Xvfb</I> [:<I>display_number</I>] [-screen <I>screen_number width</I>x<I>height</I>x<I>depth</I>] [<I>options</I>...]<br></b>


title: PARAMETERS
content:
<b>:<I>display_number</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the display number (e.g., <I>:99</I>) for the virtual X server. This number is used to set the <I>DISPLAY</I> environment variable for clients.<br><br><b>-screen <I>screen_number width</I>x<I>height</I>x<I>depth</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the characteristics of a virtual screen. <I>screen_number</I> is usually 0. <I>width</I>, <I>height</I> define resolution, and <I>depth</I> is the color depth (e.g., <I>1024x768x24</I>).<br><br><b>-fbdir <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory where framebuffer backing store files will be created. Not commonly used unless specific persistence is needed.<br><br><b>-pixmapdir <I>directory</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory for backing store files for pixmaps. Similar to <I>-fbdir</I>.<br><br><b>-cc <I>class</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the default visual class for the virtual screen (e.g., <I>TrueColor</I>, <I>DirectColor</I>).<br><br><b>-dpi <I>dpi</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the dots per inch (DPI) value for the virtual screen. Affects font rendering and scaling.<br><br><b>-logfile <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects server output messages and errors to the specified log <I>file</I>.<br><br><b>-nolisten tcp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the X server from listening for TCP connections, enhancing security by limiting access to local Unix domain sockets only.<br><br><b>-auth <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an X authority <I>file</I> to use for access control. Essential for secure client connections.<br><br><b>-ac</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables access control, allowing any host to connect. <B>Use with extreme caution</B> as it introduces significant security risks.<br><br><b>-terminate</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <I>Xvfb</I> to exit automatically after all clients have disconnected from the server.<br><br><b>-s <I>script</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a shell <I>script</I> after the server has initialized. Useful for setting up the environment or running initial commands.<br><br>


title: DESCRIPTION
content:
<I>Xvfb</I>, which stands for <b>X Virtual Framebuffer</b>, is an X server that performs all graphical operations in memory without displaying anything on a physical screen. It acts as a complete, albeit virtual, X display. This makes it invaluable for environments where a graphical interface is required but no physical display or input devices are present, such as:<br><br><b>Automated Testing:</b> Running GUI-based test suites (e.g., Selenium, Cypress) on continuous integration servers without a visible browser window.<br><b>Server-Side Applications:</b> Executing applications that require an X server to render graphics or interact with an X environment, but don't need user interaction.<br><b>Screen Scraping and Rendering:</b> Generating screenshots or processing graphical output from X applications programmatically.<br><br><I>Xvfb</I> creates a virtual screen buffer in RAM, allowing applications to draw to it as if it were a real display. It provides a full X server environment, complete with input events and rendering capabilities, making it a robust solution for headless graphical operations.


title: CAVEATS
content:
While powerful, <I>Xvfb</I> has some considerations:<br><b>No Visual Output:</b> By design, it does not display anything on a physical monitor. Debugging graphical issues can be challenging without visual feedback.<br><b>Memory Consumption:</b> Large screen resolutions and color depths can consume significant amounts of RAM, as the entire framebuffer is stored in memory.<br><b>Security:</b> Running <I>Xvfb</I> without proper access control (e.g., using <I>-ac</I> or not using <I>-nolisten tcp</I>) can expose the virtual display to unauthorized access, especially in networked environments.<br><b>Resource Management:</b> It's important to manage the lifecycle of <I>Xvfb</I> instances, particularly in automated scripts, to avoid accumulating zombie processes or consuming excessive resources.


title: COMMON USAGE PATTERN
content:
A typical workflow for using <I>Xvfb</I> involves:<br>1. <B>Starting Xvfb:</B> <I>Xvfb :99 -screen 0 1024x768x24 &</I><br>   (This starts <I>Xvfb</I> on display number <I>:99</I> with a screen resolution of <I>1024x768</I> at <I>24-bit</I> color depth, and runs it in the background.)<br>2. <B>Setting DISPLAY:</B> <I>export DISPLAY=:99</I><br>   (This tells subsequent X clients to connect to the virtual display created by <I>Xvfb</I>.)<br>3. <B>Running Applications:</B> Execute your GUI application or test suite (e.g., <I>firefox</I>, <I>google-chrome</I>, Selenium tests).<br>4. <B>Cleaning Up:</B> After use, terminate the <I>Xvfb</I> process (e.g., <I>kill &lt;PID_of_Xvfb&gt;</I>). Some tools like <I>xvfb-run</I> automate this process.


title: THE <I>DISPLAY</I> ENVIRONMENT VARIABLE
content:
The <I>DISPLAY</I> environment variable is crucial for any X client to know which X server to connect to. When using <I>Xvfb</I>, you must set this variable to match the display number you assigned to your <I>Xvfb</I> instance (e.g., <I>export DISPLAY=:99</I>). Without this, X applications will attempt to connect to the default display, which might be a physical one or none at all.


title: <I>XVFB-RUN</I> HELPER SCRIPT
content:
Many distributions provide a helper script named <I>xvfb-run</I>. This script simplifies using <I>Xvfb</I> by automatically starting an <I>Xvfb</I> instance, setting the <I>DISPLAY</I> environment variable, running the specified command, and then cleaning up the <I>Xvfb</I> process when the command exits. It's often preferred for one-off commands or simpler scripts. Example: <I>xvfb-run firefox</I>


title: HISTORY
content:
The concept of a virtual framebuffer for the X Window System emerged in the mid-1990s as part of efforts to provide X server capabilities in environments without direct graphical hardware or for automated testing. <I>Xvfb</I> was developed by David Wiggins and others, becoming a component of the XFree86 project, and subsequently integrated into the X.Org Server, the open-source implementation of the X Window System. Its development was driven by the increasing need for headless operation in server environments, particularly for applications requiring graphical rendering (like web browsers for testing or server-side rendering tools) without the overhead or requirement of a physical display. It has since become a standard and indispensable tool in continuous integration/delivery (CI/CD) pipelines and cloud deployments.


title: SYNOPSIS
content:
<b>xvfb-run</b> [<i>options</i>] <i>command</i> [<i>args ...</i>]<br><b>xvfb-run</b> [<i>options</i>] -


title: PARAMETERS
content:
<b>-a, --auto-display</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Automatically select an available display number for <b>Xvfb</b>.</i><br><br><b>-e FILE, --error-file=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Redirects <b>Xvfb</b>'s standard error output to the specified <b>FILE</b>.</i><br><br><b>-f FILE, --auth-file=FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies an <b>X authority file</b> (e.g., for <i>xauth</i>) to store connection credentials.</i><br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a comprehensive help message and exits.</i><br><br><b>-l, --listen-tcp</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables <b>TCP connections</b> to the <b>Xvfb</b> server, generally less secure and not recommended for typical use.</i><br><br><b>-n DISPLAY, --server-num=DISPLAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the specific <b>X display number</b> (e.g., `99`) for <b>Xvfb</b> to use.</i><br><br><b>-o OPTIONS, --server-options=OPTIONS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Passes additional, raw <b>OPTIONS</b> directly to the <b>Xvfb</b> server command line.</i><br><br><b>-p PROTOCOL, --xauth-protocol=PROTOCOL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the <b>X authority protocol</b> to use (default is `MIT-MAGIC-COOKIE-1`).</i><br><br><b>-s SIZE, --server-display=SIZE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines the <b>screen resolution</b> and color depth for <b>Xvfb</b>, e.g., `1024x768x24`.</i><br><br><b>-w DELAY, --wait=DELAY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Waits for up to <b>DELAY</b> seconds for the <b>Xvfb</b> server to successfully start.</i><br><br><b>-X, --no-xauth</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables the use of <b>X authority</b> for client connections, reducing security.</i><br><br><b>-P PIDFILE, --pidfile=PIDFILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Writes the Process ID (PID) of the <b>Xvfb</b> server to the specified <b>PIDFILE</b>.</i><br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables <b>debug mode</b>, providing more verbose output from <i>xvfb-run</i> itself.</i><br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the <i>xvfb-run</i> version information and exits.</i><br><br>


title: DESCRIPTION
content:
<i>xvfb-run</i> is a utility script that automates the process of starting the <b>Xvfb</b> (X virtual framebuffer) server, setting up the <b>DISPLAY</b> environment variable, executing a specified graphical application, and then safely shutting down <b>Xvfb</b> upon the application's exit.<br><br>This utility is invaluable for scenarios where a graphical environment is required but a physical display is unavailable or undesirable, such as on headless servers, for automated UI testing (e.g., with Selenium or Cypress), or for rendering graphical content into images (e.g., using <i>wkhtmltopdf</i>). It allows applications that inherently depend on an X server to run seamlessly without a visible desktop, making them suitable for batch processing or continuous integration/delivery pipelines. <i>xvfb-run</i> handles the complex setup of <b>Xvfb</b>'s command-line arguments and display management, abstracting away the underlying details for the user.


title: CAVEATS
content:
<ul><li><i>xvfb-run</i> consumes system resources (CPU, memory) just like a regular X server, albeit without a physical display.</li><li>Running <b>Xvfb</b> with <i>root</i> privileges is generally discouraged unless strictly necessary due to security implications, especially when using options like `--listen-tcp` or `--no-xauth`.</li><li>Applications running under <i>xvfb-run</i> cannot interact with a physical display or user input.</li><li>Troubleshooting can be challenging if the X client fails silently; checking <b>Xvfb</b>'s stderr (e.g., with `-e`) is often helpful.</li><li>The <b>DISPLAY</b> variable is automatically set by <i>xvfb-run</i>; manually setting it beforehand can lead to conflicts.</li></ul>


title: HOW IT WORKS WITH DISPLAY
content:
<i>xvfb-run</i> automatically assigns an available display number (e.g., `:99`) and sets the <b>DISPLAY</b> environment variable for the <i>command</i> it executes. This allows the X client to find and connect to the <b>Xvfb</b> server.


title: SECURITY AND XAUTH
content:
By default, <i>xvfb-run</i> uses <i>xauth</i> to create a magic cookie, ensuring that only authorized clients can connect to the <b>Xvfb</b> server, enhancing security, especially when <b>Xvfb</b> might be accessible from other hosts (though `--listen-tcp` is rarely used).


title: TYPICAL USAGE EXAMPLE
content:
A common use case involves running a headless web browser for automated testing or screenshot generation:<br><code><b>xvfb-run</b> \<br>&nbsp;&nbsp;<b>--server-args="-screen 0 1024x768x24"</b> \<br>&nbsp;&nbsp;<i>firefox --headless -screenshot example.png example.com</i></code><br>This example demonstrates running a headless <i>Firefox</i> instance within <b>Xvfb</b> to take a screenshot of a webpage with a specified screen resolution.


title: HISTORY
content:
The <b>Xvfb</b> (X virtual framebuffer) server itself has been a part of the X Window System since X11R6 (around 1994), primarily developed for testing X server implementations and for applications needing an X server without a graphics card. <i>xvfb-run</i> emerged later as a convenience wrapper script, simplifying the complex invocation of <b>Xvfb</b> by handling display number allocation, <b>DISPLAY</b> environment variable setup, and <i>xauth</i> cookie management.<br><br>Its development was driven by the increasing need for automated testing of GUI applications and for server-side processing of graphical content in headless environments, allowing X-dependent software to run seamlessly in CI/CD pipelines or cloud infrastructure without manual configuration of a virtual display.


title: SYNOPSIS
content:
<b><i>xvidtune</i></b> [ <i>-display <br>display></i> ] [ <i>-geometry <br>geometry></i> ] [ <i>-show</i> ] [ <i>-prev</i> ] [ <i>-next</i> ] [ <i>-test</i> ] [ <i>-probe</i> ] [ <i>-sync</i> ] [ <i>-exit</i> ] [ <i>-f | -fullscreen</i> ] [ <i>-s | -save</i> ] [ <i>-t | -timeout <seconds></i> ]


title: PARAMETERS
content:
<b><b>-display</b> <i><display></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to connect to.<br><br><b><b>-geometry</b> <i><geometry></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial window geometry of the <i>xvidtune</i> application.<br><br><b><b>-show</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the current video mode settings to standard output in a format suitable for an X server configuration file (e.g., <i>xorg.conf</i>).<br><br><b><b>-prev</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the X server to the previous video mode in its internal list of available modes.<br><br><b><b>-next</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the X server to the next video mode in its internal list of available modes.<br><br><b><b>-test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the currently adjusted mode parameters for a brief period to allow visual evaluation, then reverts to the original mode. Typically used with <b>-timeout</b>.<br><br><b><b>-probe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to probe and discover additional video modes supported by the display hardware or driver. Functionality varies by driver.<br><br><b><b>-sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes <i>xvidtune</i>'s internal state with the X server's currently active video mode.<br><br><b><b>-exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately exits the <i>xvidtune</i> program.<br><br><b><b>-f</b>, <b>-fullscreen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches <i>xvidtune</i> in fullscreen mode, occupying the entire screen.<br><br><b><b>-s</b>, <b>-save</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the currently applied video mode settings to a user-specific configuration file, typically <i>~/.xvidtune</i>, which can later be used to update the main X server configuration.<br><br><b><b>-t</b>, <b>-timeout</b> <i><seconds></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the duration in seconds for the <b>-test</b> option before the video mode automatically reverts.<br><br>


title: DESCRIPTION
content:
<i>xvidtune</i> is a graphical user interface utility for the X Window System that allows users to fine-tune and dynamically adjust the video mode timings of the X server. It provides an interactive way to modify parameters such as dot clock, horizontal and vertical synchronization timings, and display dimensions. This tool was historically invaluable for optimizing display output, especially on CRT monitors or with custom display setups, by allowing live adjustments to eliminate screen artifacts, correct screen position or size, and achieve optimal refresh rates. <br><br>While its primary use case has diminished with modern display technologies and automatic EDID (Extended Display Identification Data) detection, <i>xvidtune</i> still offers a low-level interface to the X server's video driver. It can be particularly useful in niche scenarios or when dealing with older hardware that lacks proper EDID information, or when precise manual calibration is required. It reads the current video mode information and presents it via sliders and input fields, allowing users to test changes instantly before deciding to save them to the X server's configuration.


title: CAVEATS
content:
<i>xvidtune</i>'s direct video timing manipulation capabilities are less relevant for modern graphics drivers and displays that rely heavily on RandR (XRandR) and EDID for mode negotiation. <br><br>Incorrectly configured video timings can potentially damage older CRT monitors or cause display instability. Users should proceed with caution. <br><br>Saving changes typically writes to a user-specific file (<i>~/.xvidtune</i>) and often requires manual integration into the main X server configuration (e.g., <i>/etc/X11/xorg.conf</i> or a snippet within <i>/etc/X11/xorg.conf.d/</i>) and a subsequent X server restart to take permanent effect. <br><br>Permissions are critical; <i>xvidtune</i> often needs elevated privileges or specific policykit rules to interact directly with the X server's mode database.


title: <B>TYPICAL USAGE SCENARIOS</B>
content:
<i>xvidtune</i> is most beneficial in specific scenarios such as:<br><i>1.</i> Adjusting older CRT monitors to perfectly fit the screen, correct overscan/underscan issues, or achieve higher refresh rates.<br><i>2.</i> Troubleshooting displays with poor or missing EDID information.<br><i>3.</i> Fine-tuning projector outputs or custom embedded display panels where standard resolutions or timings are not optimal.


title: <B>INTEGRATION WITH XORG.CONF</B>
content:
The output from <i>xvidtune -show</i> can be directly copied into the 'Monitor' or 'Screen' sections of your <i>xorg.conf</i> file (or a relevant snippet in <i>/etc/X11/xorg.conf.d/</i>) as a 'Modeline'. This allows the X server to use your custom timing permanently after a restart. The <b>-save</b> option typically writes to <i>~/.xvidtune</i>, which serves as a temporary storage and may require manual transfer to the system-wide configuration.


title: HISTORY
content:
<i>xvidtune</i> originated as part of the XFree86 project, which was the dominant open-source implementation of the X Window System before X.Org took over. It was developed in an era when manual configuration of video modes via 'Modelines' in the X server configuration file (<i>XF86Config</i>, later <i>xorg.conf</i>) was a common necessity. Its introduction provided a much-needed interactive graphical interface for fine-tuning these complex timing parameters without requiring constant manual editing and X server restarts. <br><br>While still available in many modern Linux distributions, its practical utility has significantly declined since the widespread adoption of EDID-based automatic monitor detection and the more flexible RandR (XRandR) extension, which allows dynamic resolution and display layout changes at a higher level of abstraction.


title: PARAMETERS
content:
<b><b>-display</b> <i>&lt;display&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to contact. This option is useful for querying information from a remote display or a specific display on the local machine (e.g., `:0.0`).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <i>xvinfo</i> to print a comprehensive list of all visual IDs and types supported by the X server, in addition to the standard Xv adaptor information. This provides deeper insight into the server's rendering capabilities.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief usage message detailing the command's available options and then exits immediately.<br><br>


title: DESCRIPTION
content:
<i>xvinfo</i> is a command-line utility for the X Window System that provides detailed information about the XVideo (Xv) extension adaptors available on the current X server. The XVideo extension enables video-aware applications to display video directly on an X server display, often leveraging hardware acceleration for operations like scaling, color space conversion, and de-interlacing. <br><br><i>xvinfo</i> enumerates each Xv adaptor found, detailing its capabilities such as supported input and output formats (e.g., YUV, RGB), available attributes (like brightness, contrast, hue, saturation, and gamma), unique port IDs, and associated video encodings. It's an essential tool for diagnosing Xv-related issues, verifying hardware video acceleration support, and understanding the video playback capabilities of a given X server setup. Developers and power users frequently use it to confirm the presence and functionality of Xv drivers and adaptors for optimal multimedia performance in Linux environments.


title: CAVEATS
content:
<i>xvinfo</i>'s functionality is entirely dependent on the XVideo extension being present and enabled on the X server. If the extension is not found (e.g., on a headless server, a minimal X setup, or a Wayland session without XWayland), <i>xvinfo</i> will report "Xv extension not present" or similar.<br><br>The capabilities and attributes reported by <i>xvinfo</i> are specific to the graphics hardware and its installed drivers. Not all hardware supports all Xv features.<br><br>Modern desktop environments often use alternative display protocols (like Wayland) or rendering technologies (like OpenGL/Vulkan for textured video playback) that do not directly rely on the XVideo extension. In such cases, <i>xvinfo</i>'s output might not reflect the full video acceleration capabilities of the system.


title: XVIDEO EXTENSION (XV)
content:
The XVideo extension is a critical component of the X Window System architecture designed to optimize video playback. It provides a standardized interface for applications to interact with graphics hardware for video-related tasks. Instead of requiring applications to perform computationally intensive operations like YUV-to-RGB conversion or scaling in software, Xv allows these tasks to be offloaded to the GPU. This results in smoother video playback, reduced CPU utilization, and often enables features like hardware-accelerated de-interlacing. <i>xvinfo</i> serves as the primary diagnostic tool to understand what specific Xv capabilities and hardware acceleration features are available on a given X server instance.


title: HISTORY
content:
The XVideo (Xv) extension was developed as a crucial component of the X Window System to enable efficient video display within desktop environments. It provided a standardized API for applications to leverage hardware acceleration for video processing tasks like scaling, color space conversion, and direct video overlays, thereby improving performance and reducing CPU load. <i>xvinfo</i> emerged as the dedicated diagnostic tool to query and display the capabilities offered by this extension. Its development is intrinsically linked to the evolution of multimedia capabilities and hardware acceleration in desktop Linux, becoming a go-to utility for verifying and troubleshooting video playback performance on X11-based systems.


title: PARAMETERS
content:
<b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Causes <i>xvminitoppm</i> to print a line of text about the conversion process to standard error (stderr).<br><br>


title: DESCRIPTION
content:
<i>xvminitoppm</i> reads an XV 'mini-thumbnail' file as input and produces a PPM (Portable Pixmap) file as output.<br><br>These mini-thumbnail files are typically found in the <b>.xvpics</b> directory and contain a 72x54 true-color (24-bit) image. Consequently, the output generated by <i>xvminitoppm</i> is always a PPM file with these exact dimensions (72x54 pixels).<br><br>This program is an integral part of the Netpbm project, a comprehensive toolkit designed for various graphic file format conversions and manipulations.


title: CAVEATS
content:
The output PPM file always has fixed dimensions of 72x54 pixels, regardless of the original image's aspect ratio or potential embedded information beyond the standard mini-thumbnail size. This command specifically processes XV 'mini-thumbnail' files, which is a very particular and outdated image format.


title: INPUT FILE LOCATION
content:
The specific XV 'mini-thumbnail' files that <i>xvminitoppm</i> is designed to process are commonly located within the <b>.xvpics</b> directory.


title: HISTORY
content:
<i>xvminitoppm</i> was introduced as a new command in Netpbm 10.37 in October 2006. It superseded <i>xvpictoppm</i>, which handled the larger 120x90 thumbnails present in XV up through version 3.10. The 72x54 mini-thumbnails that <i>xvminitoppm</i> is designed to convert were specifically introduced with XV version 3.10.


title: PARAMETERS
content:
<b><I>-display display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to.<br><br><b><I>-root</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the root window of the screen instead of a specific application window.<br><br><b><I>-id id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the window with the specified X resource ID.<br><br><b><I>-name name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the window with the specified WM_NAME property (window title).<br><br><b><I>-add value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds <I>value</I> to each pixel, primarily for colormap debugging.<br><br><b><I>-xy</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses XY format for dumping pixmaps; the default is Z format.<br><br><b><I>-frame</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the window manager frame (borders and title bar) in the captured image.<br><br><b><I>-icmap</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the use of the ideal colormap for the window when dumping.<br><br><b><I>-nobdrs</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes the window's border from the captured image.<br><br><b><I>-out file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the image to the specified <I>file</I> instead of standard output.<br><br><b><I>-silent</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the bell and visual feedback when capturing a window.<br><br><b><I>-help</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command usage.<br><br><b><I>-version</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for <b>xwd</b>.<br><br>


title: DESCRIPTION
content:
<b>xwd</b> is an X Window System utility designed to dump an image of a window into an X Window Dump (XWD) format file. It provides a low-level method for screen capturing within an X environment. Users can capture either a specific window by its ID or name, or the entire root window (desktop). If no window is explicitly specified, <b>xwd</b> typically changes the cursor to a crosshair, allowing the user to interactively select the desired window by clicking on it.<br><br>The output, usually redirected to a file (e.g., <code>xwd &gt; screenshot.xwd</code>), is in the <code>.xwd</code> format. This format is native to the X Window System and can be viewed with tools like <b>xwud</b> or, more commonly, converted to widely supported image formats such as PNG or JPEG using utilities like ImageMagick's <b>convert</b> command. <b>xwd</b> is a fundamental tool for debugging X applications, documenting user interfaces, or taking screenshots in minimalist X setups.


title: CAVEATS
content:
The <code>.xwd</code> file format generated by <b>xwd</b> is specific to the X Window System and is not directly viewable by most common image viewers without prior conversion. Colormap issues can sometimes lead to unexpected color representation in the captured image, especially with older X applications or complex display setups.


title: XWD FILE FORMAT
content:
The XWD (X Window Dump) format is a simple raster image format tailored for the X Window System. It stores raw pixel data along with X-specific information, such as the visual type, depth, and colormap details of the captured window. This makes it particularly useful for X protocol-level analysis and debugging.


title: COMMON USAGE WITH IMAGEMAGICK
content:
While <b>xwd</b> produces its native format, it is often used in conjunction with ImageMagick's <b>convert</b> command for immediate format conversion. A common pattern is piping the output of <b>xwd</b> directly to <b>convert</b>: <code>xwd -silent -id $(xprop -root _NET_ACTIVE_WINDOW | cut -d ' ' -f 5) | convert xwd:- active_window.png</code>. This captures the currently active window and saves it as a PNG file.


title: HISTORY
content:
<b>xwd</b> is an integral part of the X.Org utilities, dating back to the early development of the X Window System. It has served as a foundational tool for screen capture and display debugging in X environments long before more sophisticated graphical screenshot utilities became common. Its continued existence reflects the need for a low-level, direct interaction with the X server's display capabilities.


title: SYNOPSIS
content:
<b>xwdtopnm</b> [<i>xwdfile</i>]<br><i>xwdfile</i>: Path to the XWD image file. If omitted, input is read from standard input.


title: DESCRIPTION
content:
<i>xwdtopnm</i> is a utility from the Netpbm suite that converts an X Window System image dump file (XWD format) into a Portable Anymap (PNM) image. The PNM format is a generic term encompassing PBM (Portable Bitmap for monochrome images), PGM (Portable Greymap for grayscale images), and PPM (Portable Pixmap for color images).<br><br>This tool is crucial for interoperability, allowing images captured from the X Window System (e.g., using the <i>xwd</i> command) to be processed, manipulated, or viewed using standard image tools that support the widely used PNM formats. It reads the XWD data from standard input by default or from a specified file, and writes the resulting PNM image to standard output, enabling easy piping with other Netpbm utilities or image processing tools.


title: CAVEATS
content:
<i>xwdtopnm</i> expects a valid XWD file as input. Issues may arise with corrupted XWD files or very old/uncommon XWD format variations. As part of the Netpbm suite, it is often used in pipelines, and its success depends on the preceding command providing a correct XWD stream. It does not provide any specific error messages for malformed input beyond what the Netpbm library might generate.


title: TYPICAL USAGE
content:
The most common usage involves piping the output of the <i>xwd</i> command directly into <i>xwdtopnm</i>. For example, to capture a window and convert it to a PNG file:<br><code>xwd -id $(xwininfo | grep "Window id:" | awk '{print $4}') | xwdtopnm | pnmtopng > screenshot.png</code><br>This demonstrates its role as an intermediate converter in a larger image processing workflow within the Unix command-line environment.


title: HISTORY
content:
<i>xwdtopnm</i> is an integral part of the Netpbm project, a comprehensive toolkit for manipulating graphic images. Netpbm itself evolved from the original pbmplus package, which was created by Jef Poskanzer in the late 1980s. The Netpbm tools, including <i>xwdtopnm</i>, are known for their simplicity, Unix philosophy adherence (doing one thing well), and their ability to be chained together in powerful pipelines for complex image processing tasks. Its development has focused on maintaining compatibility and robustness across various X Window System versions and image depths.


title: PARAMETERS
content:
<b><i>-help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief usage message and exits.<br><br><b><i>-id &lt;id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the window ID (hexadecimal or decimal) for which to display information. This bypasses interactive selection.<br><br><b><i>-name &lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the window by its name (case-sensitive) for which to display information. Supports partial matching.<br><br><b><i>-root</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the root window of the display for information gathering. The root window is the desktop background.<br><br><b><i>-tree</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the selected window's parent and child windows in a hierarchical tree format, illustrating the window lineage.<br><br><b><i>-stats</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays statistical information about the window's state, such as its map state (visible/hidden) and override redirect status.<br><br><b><i>-wm</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows window manager hints and properties associated with the window, including properties like <b>WM_HINTS</b> and <b>WM_CLASS</b>.<br><br><b><i>-int</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces all geometry output to be in integer format, avoiding floating-point numbers for position and size.<br><br><b><i>-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A convenience option that combines <i>-tree</i>, <i>-stats</i>, and <i>-wm</i> to show comprehensive information about the window.<br><br><b><i>-frame</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes the window manager's frame (decorations like title bar and borders) in geometry calculations and reported information.<br><br><b><i>-children</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only the immediate children of the specified window, without displaying other window information.<br><br><b><i>-metric</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays window geometry dimensions in millimeters (mm) instead of the default pixels.<br><br><b><i>-english</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays window geometry dimensions in pixels (the default behavior). Explicitly sets the unit to pixels.<br><br><b><i>-display &lt;display&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server display to connect to (e.g., <b>:0.0</b>) if not using the default.<br><br><b><i>-pointer</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the window at the current pointer position without user interaction. This is often the default interactive behavior if no ID/name is given.<br><br>


title: DESCRIPTION
content:
<i>xwininfo</i> is a command-line utility designed to display comprehensive information about a specific window on an X Window System server. It is an indispensable tool for developers, system administrators, and power users who need to understand the characteristics and state of graphical windows.<br><br>When invoked without specific window identifiers, <i>xwininfo</i> enters an interactive mode, prompting the user to click on the desired window. Alternatively, users can specify a window by its unique ID (hexadecimal or decimal) or by its name. The output typically includes the window's ID, its parent and children, its absolute and relative geometry (position and size), border width, depth, class, name, and various X properties. This information is crucial for debugging X applications, scripting window management tasks, and gaining insight into the X server's window hierarchy.


title: CAVEATS
content:
<i>xwininfo</i> requires a running X server to function. The 'window name' property it reports (<b>WM_NAME</b>) might not always correspond to the visible title bar text, as some applications use different properties or don't set <b>WM_NAME</b>. For complex applications or toolkits that manage numerous internal sub-windows, the output can be very verbose and potentially misleading without understanding the application's internal structure. Information gathered may be out of date if the window's state changes rapidly after the command is run.


title: INTERACTIVE USAGE
content:
If <i>xwininfo</i> is invoked without any window identification options (like <i>-id</i> or <i>-name</i>), it enters an interactive mode. In this mode, the cursor changes, and the user is prompted to click on any window on the desktop. Upon clicking, <i>xwininfo</i> will display the information for the selected window. This is often the easiest way to inspect an unknown window.


title: SCRIPTING AND AUTOMATION
content:
The output of <i>xwininfo</i> is highly structured and can be easily parsed using standard command-line tools like <i>grep</i>, <i>awk</i>, or <i>sed</i>. This makes it an invaluable component for shell scripts designed to automate window management tasks, such as repositioning windows, taking screenshots of specific applications, or identifying window IDs for further manipulation with tools like <i>xdotool</i>.


title: DEBUGGING X APPLICATIONS
content:
For developers, <i>xwininfo</i> serves as a critical debugging tool. It helps in verifying a window's reported size, position, depth, and other properties, ensuring that an application's windows are created and managed as expected by the X server and window manager. It can reveal inconsistencies that might lead to display issues or unexpected behavior.


title: HISTORY
content:
<i>xwininfo</i> is a fundamental utility that has been part of the X Window System's core distribution since its early days. It originated as part of the MIT X Consortium's X11 (X Window System, Version 11) utilities, which laid the groundwork for modern Unix-like graphical environments. Its development has continued under projects like XFree86 and currently X.Org, reflecting its ongoing importance in understanding and debugging X client-server interactions. Its design is rooted in the basic principles of the X Protocol, providing a direct interface to query window attributes.


title: PARAMETERS
content:
<b>-g <i>WIDTHxHEIGHT+X+Y</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the geometry (size and position) of the <b>xwinwrap</b> window.<br><br><b>-ni</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>No Input</i>. Prevents keyboard and mouse input from being passed to the wrapped window.<br><br><b>-nf</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>No Focus</i>. Prevents the wrapped window from gaining focus when clicked or tabbed to.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Below</i>. Places the <b>xwinwrap</b> window below all other windows, making it suitable for a desktop background.<br><br><b>-fs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Fullscreen</i>. Makes the <b>xwinwrap</b> window cover the entire entire screen.<br><br><b>-s <i>SCREEN_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Screen ID</i>. Specifies the X screen on which the window should be displayed in multi-monitor setups.<br><br><b>-o <i>OPACITY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Opacity</i>. Sets the opacity of the window, a floating-point value between 0.0 (fully transparent) and 1.0 (fully opaque).<br><br><b>-ov</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Overlay</i>. Forces the window to be an overlay, staying on top of other windows.<br><br><b>-sh</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Shared Memory</i>. Attempts to use shared memory for rendering, which may improve performance with some applications.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Desktop</i>. Forces the window to be treated as a desktop window (i.e., root window). This is the default behavior if not otherwise specified.<br><br><b>-nd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>No Desktop</i>. Forces the window not to be treated as a desktop window.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Command Separator</i>. This crucial argument separates <b>xwinwrap</b>'s own options from the command and its arguments that should be executed and wrapped inside the created window.<br><br>


title: DESCRIPTION
content:
<b>xwinwrap</b> is a command-line utility for the X Window System that allows you to embed any running application's window as your desktop background, or as a child of another window. Its primary use case is creating animated wallpapers by wrapping a video player (like <i>mpv</i>) or a web browser displaying a GIF/video.<br><br>It works by creating a new X window, setting its properties (like position, size, and Z-order), and then providing its Window ID (WID) to another command. The other command is expected to render its output into this specified WID. This enables dynamic and interactive backgrounds, going beyond static images.


title: CAVEATS
content:
<b>xwinwrap</b> directly interacts with the X Window System and might exhibit varying behavior or compatibility issues across different desktop environments (DEs) or window managers (WMs). It can be resource-intensive depending on the wrapped application and its content (e.g., high-resolution video). Furthermore, it relies on the wrapped application being able to render to a specified X Window ID, which is not supported by all applications. It's also an older utility, and its active development status may vary depending on the distribution.


title: USAGE WITH %WID
content:
When <b>xwinwrap</b> creates its window, it substitutes the special string <i>%WID</i> in the wrapped command with the actual Window ID (WID) of the newly created window. The wrapped application (e.g., <i>mpv</i>) must support an option to render into a specific WID. For <i>mpv</i>, this is typically done using the <i>--wid</i> option.<br><br><b>Example:</b><br><i>xwinwrap -ni -nf -b -fs -- mpv --loop-file=inf --no-audio --no-input-default-bindings --wid=%WID /path/to/your/video.mp4</i><br><br>This command runs <i>mpv</i> in an infinite loop, without audio, without default input bindings, and renders it into the background window created by <b>xwinwrap</b>. The <i>-ni -nf -b -fs</i> options ensure it behaves correctly as a background.


title: HISTORY
content:
<b>xwinwrap</b> emerged as a solution for users seeking dynamic and animated desktop backgrounds in traditional X11 environments, particularly before such features became more common or integrated into modern desktop environments like GNOME or KDE. Its development focused on providing a lightweight wrapper to leverage existing media players or rendering tools for this specific purpose, rather than building a full-fledged animated wallpaper engine from scratch.


title: PARAMETERS
content:
<b><b>-geometry</b> <i>&lt;geometry string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the preferred size and position of the window where the image will be displayed. E.g., <code>100x50+10+20</code>.<br><br><b><b>-display</b> <i>&lt;display name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X server to connect to. E.g., <code>:0.0</code> or <code>hostname:0</code>.<br><br><b><b>-inverse</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the image in inverse colors (reverse video, swapping black and white, etc.).<br><br><b><b>-mono</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the image to be displayed in monochrome (black and white), regardless of its original color depth.<br><br><b><b>-gray</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the image to be displayed in grayscale.<br><br><b><b>-std</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the default (standard) visual type for display on the X server.<br><br><b><b>-best</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to use the 'best' available visual type that closely matches the characteristics of the image data.<br><br><b><b>-</b><i>&lt;visual id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular hexadecimal visual ID to use for display. This can be found using <code>xdpyinfo</code>.<br><br><b><b>-name</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a specific name to the created window. This name can be used by window managers or other X tools.<br><br><b><b>-notitle</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the window manager not to add a title bar or borders to the <i>xwud</i> window.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a usage message detailing the available command-line options and then exits.<br><br>


title: DESCRIPTION
content:
<i>xwud</i> (X Window Undump) is a utility provided with the X Window System that allows users to display images created by the <i>xwd</i> (X Window Dump) command. These <i>xwd</i> files are essentially screenshots or 'dumps' of an X window's contents. <i>xwud</i> reads these window dump files, either from a specified file path or from standard input, and renders them onto an X display.<br><br>It is particularly useful for viewing and verifying the output of <i>xwd</i> or for simple image display within an X environment. The command supports various visual types, automatically adapting to the visual type of the image being displayed, or allowing the user to specify a preferred visual. It's a basic but fundamental tool for handling X window dumps within the X.Org ecosystem.


title: CAVEATS
content:
<i>xwud</i> is a command-line utility specifically designed for the X Window System; it cannot be used in a text-only console environment. Its input is strictly limited to <i>xwd</i> format files, and it offers no image editing capabilities or advanced viewing features. It serves primarily as a basic viewer for its specific file type.


title: EXITS ON WINDOW DESTRUCTION
content:
<i>xwud</i> terminates automatically if its display window is closed or destroyed by the user (e.g., clicking the close button) or by the window manager.


title: INPUT FROM STANDARD INPUT
content:
If no <i>file</i> argument is provided on the command line, <i>xwud</i> automatically reads the X window dump data from standard input. This allows it to be used effectively in pipes, such as <code>xwd -root | xwud</code> (to dump the root window and immediately display it).


title: HISTORY
content:
<i>xwud</i> has been a fundamental utility within the X Window System since its early development. It was created as a companion tool to <i>xwd</i>, the X Window Dump utility, to provide a simple means of verifying and displaying the <i>xwd</i> format image files. Its design is straightforward, focusing solely on the task of 'undumping' these specific image files. As part of the X.Org distribution, it has maintained its core functionality with minimal changes over the decades, reflecting its specific and foundational role in X window management.


title: SYNOPSIS
content:
<b>xxd</b> [<i>options</i>] [<i>file</i>]<br><b>xxd -r</b> [<i>options</i>] [<i>infile</i>] [<i>outfile</i>]


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Toggle autoskip: replace lines of zeroes with a single asterisk.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binary dump: display bits (0s and 1s) instead of hexadecimal values.<br><br><b><b>-c</b> <i>cols</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format <i>cols</i> bytes per line.<br><br><b><b>-g</b> <i>group_size</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Separate <i>group_size</i> bytes with spaces in the hex output.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in C include file style (unsigned char array).<br><br><b><b>-l</b> <i>len</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit to <i>len</i> bytes of input.<br><br><b><b>-o</b> <i>offset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add <i>offset</i> to the file position shown.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plain dump: no address or ASCII part, only hexadecimal bytes.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverse operation: convert a hex dump back to binary.<br><br><b><b>-s</b> <i>offset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start at <i>offset</i> bytes into the input file.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use upper case hex letters (A-F).<br><br>


title: DESCRIPTION
content:
<i><b>xxd</b></i> is a versatile command-line utility for creating hex dumps of files or standard input, and for converting hex dumps back into their original binary form. It is often used by programmers, system administrators, and security researchers to inspect the raw content of binary files, executables, memory dumps, or network packets. <br><br>Unlike some other hex dump utilities, <i><b>xxd</b></i> is renowned for its ability to convert back, making it useful for patching binaries or embedding data. It offers various formatting options, allowing users to control the number of bytes per line, group bytes, display ASCII or EBCDIC representations, and even generate C-style array definitions. Its dual functionality of dumping and reversing makes it a powerful tool for low-level data manipulation and analysis.


title: CAVEATS
content:
When using <i><b>xxd -r</b></i>, the input hex dump must adhere strictly to <i><b>xxd</b></i>'s own output format, or a very similar structure, for successful conversion. It is not a general-purpose hex parser for arbitrary formats. <br><br>Generating hex dumps of extremely large files can create very large text files, potentially consuming significant disk space and memory if loaded into an editor.


title: C INCLUDE FILE STYLE
content:
When using the <i><b>-i</b></i> option, <i><b>xxd</b></i> generates output suitable for inclusion in C or C++ source code as an array of unsigned characters. This is extremely useful for embedding binary data (like images, firmware, or small resources) directly into compiled applications. The output includes an array declaration with the data in hexadecimal format and a variable holding the total length.


title: REVERSE CONVERSION USE CASES
content:
The <i><b>-r</b></i> (reverse) option allows <i><b>xxd</b></i> to convert a hex dump back into its original binary form. This is invaluable for tasks such as patching binary files (editing a hex dump and then converting it back), recreating binary data from textual representations, or even for simple data obfuscation/de-obfuscation in scripts.


title: HISTORY
content:
<i><b>xxd</b></i> was originally written by Jorg Schilling for the Vim editor project in 1990. It has been a part of the Vim distribution (often included in <i>vim-common</i> or <i>vim-full</i> packages) for a long time, providing its hex dumping and reverse conversion capabilities directly alongside the editor's development. Its close association with Vim ensures its continued maintenance and widespread availability on Unix-like systems.


title: PARAMETERS
content:
<b>--shell &lt;shell_name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the shell to use on the remote host (e.g., <i>zsh</i>, <i>bash</i>, <i>fish</i>).<br><br><b>--plugins &lt;plugin_names&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of <b>xxh</b> plugins to enable and apply to the remote shell environment.<br><br><b>--install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force installation or re-installation of the <b>xxh</b> client and specified shells on the remote host.<br><br><b>--update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the <b>xxh</b> client and/or the installed shells and plugins on the remote host.<br><br><b>--config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open or modify the <b>xxh</b> client configuration file on the local machine.<br><br><b>--ssh-options &lt;options&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass raw options directly to the underlying <b>ssh</b> command (e.g., <i>-o StrictHostKeyChecking=no</i>).<br><br><b>--arguments &lt;args&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass arguments directly to the remote shell once it starts. Useful for interactive shell sessions.<br><br><b>--login &lt;user&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the username for the SSH login on the remote host.<br><br><b>--port &lt;port&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the SSH port to connect to on the remote host.<br><br><b>--key &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to an identity file (private key) for SSH authentication.<br><br><b>--yes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically answer 'yes' to all prompts, useful for non-interactive scripts.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing detailed steps of the <b>xxh</b> process for debugging.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the current version of the <b>xxh</b> client.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options and usage.<br><br>


title: DESCRIPTION
content:
The <b>xxh</b> command acts as a powerful wrapper around the standard <b>ssh</b> client, designed to provide a consistent and personalized shell environment on any remote server. <br>
It enables users to utilize their preferred local shell (like <i>Zsh</i>, <i>Fish</i>, or <i>Bash</i>) along with their customized dotfiles and plugins, even if these are not natively installed or configured on the remote host. <br>
Unlike a simple <b>ssh</b> connection, <b>xxh</b> automatically manages the transfer and setup of the desired shell and its configurations on the remote machine. It achieves this by transferring a small Python client to the remote, which then handles the download and unpacking of a pre-built shell environment (e.g., <i>zsh-xxh</i>) into the user's home directory (<i>~/.xxh</i>) on the remote. <br>
This significantly streamlines development workflows and enhances user experience by eliminating the need for manual remote shell setup or complex configuration synchronization.


title: CAVEATS
content:
<ul>
<li>Requires <i>Python 3.6</i> or higher to be present on the remote host for the <b>xxh</b> server component to function.</li>
<li>Initial connection to a new host or selection of a new shell/plugin might incur a delay due to downloading and unpacking the necessary shell environment and plugins.</li>
<li>Network bandwidth is consumed for transferring shell environments and plugins, which can be significant depending on the configuration.</li>
<li>While designed with security in mind, introducing external scripts and configurations (plugins, dotfiles) to a remote system always carries inherent security considerations.</li>
<li><b>xxh</b> is not a standard Linux utility; it needs to be explicitly installed on the local client machine.</li>
</ul>


title: HOW XXH WORKS
content:
When you invoke <b>xxh</b>, it first establishes an SSH connection to the remote host. It then uploads a small Python script to the remote host. This script, which acts as the <b>xxh</b> server component, checks for Python availability and then downloads and unpacks the selected shell environment (e.g., <i>zsh-xxh</i>, <i>bash-xxh</i>) and any specified plugins into the <i>~/.xxh</i> directory on the remote. Finally, it launches your preferred shell with your local dotfiles and configurations applied, giving you a consistent and familiar experience.


title: EXTENSIBILITY (PLUGINS)
content:
<b>xxh</b> supports a robust plugin system, allowing users to extend its functionality significantly. Plugins can include additional utilities, custom shell configurations, themes, or other scripts that are automatically deployed and activated in the remote shell environment. This makes <b>xxh</b> highly customizable and adaptable to various development needs, from specific language toolchains to custom prompt setups.


title: HISTORY
content:
The <b>xxh</b> project was initiated by Andrey Lekar (<i>lekum</i>) with its first public commits appearing on GitHub around 2018. It emerged from the common frustration of maintaining consistent shell environments across numerous remote servers. The goal was to simplify the process of bringing a personalized development environment, including specific shells, dotfiles, and plugins, to any remote machine without extensive manual setup or system-wide installations. Its development has focused on cross-platform compatibility and ease of use, leveraging Python for its remote client component and providing a rich plugin ecosystem.


title: SEE ALSO
content:
<i>ssh(1)</i>: The fundamental Secure Shell client for remote command execution and file transfer., <i>rsync(1)</i>: A versatile tool for remote file copying and synchronization, often used for managing dotfiles., <i>tmux(1)</i>: A terminal multiplexer that allows multiple terminal sessions within a single window, useful for persistent remote sessions., <i>screen(1)</i>: Another terminal multiplexer, similar to <b>tmux</b>, providing session management capabilities.


title: PARAMETERS
content:
<b><b>-b</b>, <b>--binary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read files in binary mode. This is the default on most systems.<br><br><b><b>-c</b>, <b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read XXH sums from the specified <I>FILE</I>s (or standard input if no file is given) and verify them.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print OK for each successfully verified file when checking.<br><br><b><b>-s<SIZE></b>, <b>--size=<SIZE></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output hash size in bits. Common values are 32, 64 (often default), or 128.<br><br><b><b>--xxh32</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the use of the XXH32 algorithm, producing a 32-bit hash.<br><br><b><b>--xxh64</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the use of the XXH64 algorithm, producing a 64-bit hash.<br><br><b><b>--xxh3</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the use of the XXH3 algorithm, which is even faster than XXH64 and can produce 64-bit or 128-bit hashes depending on <b>--size</b>.<br><br><b><b>--xxh128</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the use of the XXH128 algorithm, producing a 128-bit hash (internally uses XXH3 with 128-bit output).<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<I>xxhsum</I> is a command-line utility used to compute and verify Extremely Fast Hash (XXH) checksums for files or standard input. Developed as part of the <I>xxhash</I> library by Yann Collet, its primary advantage is its exceptional speed, significantly outperforming cryptographic hash functions like MD5 or SHA-256, while still offering excellent collision resistance for non-cryptographic applications. It's ideal for tasks requiring quick data integrity checks, such as verifying large file transfers, ensuring file consistency after a copy, or rapidly comparing files.<br><br>Unlike cryptographic hashes, <I>xxhsum</I> is not designed to be cryptographically secure and should not be used for security-sensitive applications where malicious tampering is a concern. It supports various XXH algorithms, including XXH32, XXH64, XXH3 (typically 64-bit or 128-bit), and XXH128, allowing users to choose the desired hash size and performance characteristics. The output format is similar to other *sum utilities, displaying the hash value followed by the filename. It also includes a robust checking mode to verify previously generated checksums.


title: CAVEATS
content:
<b><I>xxhsum</I></b> is explicitly designed for speed, not cryptographic security. While it offers excellent collision resistance for general data integrity checks, it is significantly easier to find collisions for XXH hashes than for cryptographic hashes like SHA-256. Therefore, it should <b>never</b> be used in security-critical applications where protection against malicious tampering or deliberate hash collisions is required.


title: PERFORMANCE CHARACTERISTICS
content:
The primary design goal of the XXH algorithms is extreme speed. They leverage modern CPU architectures and instruction sets to process data at very high throughputs, often exceeding gigabytes per second. This makes <b><I>xxhsum</I></b> particularly suitable for environments where large volumes of data need quick integrity checks without the overhead of cryptographic hashing.


title: COMMON USE CASES
content:
<b><I>xxhsum</I></b> excels in scenarios such as:<ul><li>Verifying large file transfers or backups.</li><li>Rapidly comparing file contents to detect accidental corruption or changes.</li><li>Checksumming data in high-performance computing (HPC) environments.</li><li>Use in caching systems or hash tables where quick and reliable key generation is needed.</li></ul>It provides a strong guarantee of accidental data corruption detection.


title: HISTORY
content:
The <b><I>xxhsum</I></b> utility is part of the <I>xxhash</I> library, an extremely fast hash algorithm developed by Yann Collet. Introduced to address the need for very high-speed, non-cryptographic hashing, <I>xxhash</I> (and by extension <I>xxhsum</I>) gained popularity in areas like game development, data processing, and large-scale file synchronization where performance is paramount and cryptographic guarantees are not required. Its development aimed to provide a faster alternative to traditional checksum utilities for data integrity verification.


title: SYNOPSIS
content:
<i>xz</i> [<I>OPTION</I>]... [<I>FILE</I>]...<br><i>unxz</i> [<I>OPTION</I>]... [<I>FILE</I>]...<br><i>xzcat</i> [<I>OPTION</I>]... [<I>FILE</I>]...


title: PARAMETERS
content:
<b>-d, --decompress, --uncompress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress. This is the default if the command is invoked as unxz or xzcat.<br><br><b>-z, --compress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compress. This is the default if the command is invoked as xz.<br><br><b>-k, --keep</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't delete input files after successful compression or decompression.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwrite of output files and compress symbolic links. This also allows compressing or decompressing to/from a terminal.<br><br><b>-c, --stdout, --to-stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write output to standard output and don't delete input files. This is the default if the command is invoked as xzcat.<br><br><b>-0 .. -9</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set compression preset level. -0 is fastest, -9 is smallest (highest compression). Default is -6.<br><br><b>-T NUM, --threads=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use NUM threads for multi-threaded compression or decompression. Use 0 for as many threads as there are CPU cores.<br><br><b>-l, --list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List information about compressed files. No files are decompressed.<br><br><b>-t, --test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of compressed files. No files are decompressed.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warnings and messages.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be more verbose. Output information like compression ratio.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of xz and xz-utils.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br>


title: DESCRIPTION
content:
<i>xz</i> is a powerful and versatile command-line utility for lossless data compression, primarily using the LZMA2 algorithm. It's designed to offer high compression ratios, often outperforming older tools like gzip and bzip2, making it ideal for distributing large files, software packages, and system archives. The tool is part of the <i>xz-utils</i> package and can compress files into the .xz format, as well as decompress legacy .lzma files. It offers various options for controlling compression levels, from fastest to smallest, and includes robust integrity checking features. <i>xz</i> seamlessly integrates into typical Unix workflows, often piped with <i>tar</i> for creating compressed archives. Its efficiency in reducing file sizes makes it a standard choice across many Linux distributions for package management and data distribution.


title: CAVEATS
content:
While <i>xz</i> offers superior compression, it can be slower for both compression and decompression compared to less efficient algorithms like those used by <i>gzip</i>, especially at higher compression levels. High compression levels also demand significantly more RAM during the compression process. Users should also be aware of the critical supply chain vulnerability (CVE-2024-3094) discovered in early 2024 in versions 5.6.0 and 5.6.1 of the <i>xz-utils</i> library, which could allow unauthorized remote code execution. It is crucial to ensure your system uses patched or unaffected versions of <i>xz-utils</i>.


title: ALIASES AND INTEGRATION
content:
<i>xz</i> typically creates symbolic links for common operations, allowing it to be invoked as <i>unxz</i> (for decompression), <i>xzcat</i> (for decompressing to standard output), <i>lzma</i>, <i>unlzma</i>, and <i>lzcat</i> (for backward compatibility with the legacy LZMA format). It is frequently integrated with the <i>tar</i> command for creating compressed archives, e.g., <code>tar -Jcvf archive.tar.xz files/</code> to compress, or <code>tar -Jxvf archive.tar.xz</code> to extract.


title: LZMA2 ALGORITHM
content:
The LZMA2 algorithm, which <i>xz</i> employs, is an improved version of the LZMA (Lempel–Ziv–Markov chain algorithm) developed by Igor Pavlov for 7-Zip. It offers variable dictionary sizes, support for multiple threads, and the ability to combine multiple LZMA streams into a single LZMA2 stream, which is particularly beneficial for compressing heterogeneous data and achieving high compression ratios efficiently.


title: HISTORY
content:
<i>xz</i> was developed by Lasse Collin, aiming to provide a modern, high-performance compression utility based on the LZMA2 algorithm, which originated from Igor Pavlov's 7-Zip project. It first achieved stable release around 2009, quickly gaining traction as a superior alternative to <i>gzip</i> and <i>bzip2</i> due to its significantly better compression ratios. Its adoption grew steadily, becoming the default compression method for many Linux distribution packages, including Debian, Fedora, and Arch Linux, for its efficiency in reducing file sizes. A notable recent event in its history is the discovery of the highly sophisticated supply chain backdoor (CVE-2024-3094) in March 2024, affecting <i>xz-utils</i> versions 5.6.0 and 5.6.1. This incident highlighted the critical importance of supply chain security in open-source projects.


title: PARAMETERS
content:
<b><b>-k</b>, <b>--keep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not delete the input file(s) after successful decompression. By default, <i>xzcat</i> processes files non-destructively, but this option explicitly ensures the original file remains.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force operations. This can be used to overwrite an existing output file (if redirecting output) or to decompress even if the input is not in <i>.xz</i> format (when reading from standard input).<br><br><b><b>-t</b>, <b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of the compressed file(s). This option checks the file's consistency without actually decompressing it to standard output. The exit status indicates whether the test passed or failed.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warnings and error messages, except for fatal errors.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more information during processing, such as the name of the file being processed.<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>xzcat</i> is a utility designed to decompress files compressed with the <i>XZ</i> algorithm and write the uncompressed data to standard output. It is effectively equivalent to running the <i>xz</i> command with the <i>--decompress</i> (<i>-d</i>) and <i>--stdout</i> (<i>-c</i>) options. This command is particularly useful for quickly viewing the contents of an <i>.xz</i> compressed file without having to permanently uncompress it or store the decompressed version on disk. It behaves much like <i>cat</i>, but for <i>XZ</i>-compressed data, allowing users to pipe the output to other commands, redirect it to a file, or simply display it on the terminal. It can process multiple files, concatenating their decompressed content in the order specified.


title: CAVEATS
content:
<i>xzcat</i> is designed exclusively for <i>.xz</i> compressed files; it will not work with other compression formats like <i>.gz</i> or <i>.bz2</i>. When decompressing large files to the terminal without redirection, the output can quickly scroll off the screen. For large files, it's advisable to pipe the output to a pager like <i>less</i> (e.g., <i>xzcat file.xz | less</i>) or redirect it to a new file.


title: USAGE WITH PIPES
content:
<i>xzcat</i> is frequently used in conjunction with pipes (<i>|</i>) to feed decompressed data directly into other commands. For example, <i>xzcat log.xz | grep 'error'</i> would decompress <i>log.xz</i> and then search for lines containing 'error' without ever saving the decompressed log to disk.


title: SYMBOLIC LINK
content:
In many Linux distributions, <i>xzcat</i> is often implemented as a symbolic link to the main <i>xz</i> executable, or it's a simple shell script that invokes <i>xz -dc</i>. This ensures consistent behavior and reduces redundancy in the system.


title: HISTORY
content:
<i>xzcat</i> is part of the <i>XZ Utils</i> software package, which replaced <i>LZMA Utils</i> as the standard implementation of the <i>LZMA2</i> compression algorithm. It was developed to provide a powerful and efficient compression/decompression tool for various Linux and Unix-like systems. <i>xzcat</i> emerged alongside the <i>xz</i> command itself, providing a convenient 'cat-like' interface for viewing the contents of <i>.xz</i> files, streamlining workflows where temporary decompression for viewing or piping is required.


title: SYNOPSIS
content:
<b>xzcmp</b> [<i>OPTION</i>]... <i>FILE1</i> [<i>FILE2</i>]<br>Alternative usage (for <i>diff</i> options):<br><b>xzcmp</b> [<i>DIFF_OPTION</i>]... <i>FILE1</i> [<i>FILE2</i>]


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>[CMP_OPTION]...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any option recognized by the 'cmp' command. These options are passed directly to 'cmp' when <i><b>xzcmp</b></i> decides to use 'cmp' for comparison (e.g., when called as 'xzcmp' without 'diff' options). Common 'cmp' options include <i>-s</i> (silent) and <i>-l</i> (long format).<br><br><b>[DIFF_OPTION]...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any option recognized by the 'diff' command. These options are passed directly to 'diff' when <i><b>xzcmp</b></i> decides to use 'diff' for comparison (e.g., when 'xzcmp' is called with 'diff'-like arguments). Common 'diff' options include <i>-q</i> (brief), <i>-u</i> (unified output), and <i>-N</i> (treat missing files as empty).<br><br>


title: DESCRIPTION
content:
<i><b>xzcmp</b></i> is a utility for comparing files, which may be compressed using <i>xz</i>, <i>lzma</i>, <i>gzip</i>, or <i>bzip2</i> compression formats, or even be uncompressed (raw) files. It acts as a wrapper around the standard <i><b>cmp</b></i> or <i><b>diff</b></i> commands, transparently decompressing the input files on the fly before passing them to the chosen comparison tool. This allows users to compare the contents of compressed archives directly without needing to decompress them manually beforehand. If only one file is provided, <i><b>xzcmp</b></i> will compare it against standard input. It's particularly useful for verifying the integrity of compressed backups or checking for differences between versions of compressed data.


title: CAVEATS
content:
<i><b>xzcmp</b></i> requires the <i>xzdec</i> (or <i>xz</i>), <i>gzip</i>, and <i>bzip2</i> utilities to be available in the system's PATH for decompressing files. Performance can be affected by the decompression speed and the size of the files being compared. It implicitly chooses between <i><b>cmp</b></i> and <i><b>diff</b></i> based on the options provided, which might lead to unexpected behavior if specific <i><b>cmp</b></i> or <i><b>diff</b></i> features are expected but the wrong underlying tool is chosen.


title: COMPARISON TOOL SELECTION
content:
<i><b>xzcmp</b></i> internally chooses between the <i><b>cmp</b></i> and <i><b>diff</b></i> utilities based on the options it receives. If options typically associated with <i><b>diff</b></i> (e.g., <i>-u</i>, <i>-q</i> when used with two files) are given, <i><b>xzcmp</b></i> will likely use <i><b>diff</b></i>. Otherwise, it defaults to using <i><b>cmp</b></i>. This behavior is similar to other 'z' utilities like <i><b>zcmp</b></i> and <i><b>bzcmp</b></i>.


title: INPUT HANDLING
content:
When only one <i>FILE</i> argument is provided, <i><b>xzcmp</b></i> compares the contents of that file (after decompression, if applicable) against standard input. This is useful for comparing a compressed file with data being piped from another command or a local uncompressed file without saving it to disk.


title: HISTORY
content:
<i><b>xzcmp</b></i> is part of the <i>xz-utils</i> package, which provides command-line tools for LZMA and XZ compression. It effectively superseded similar tools from the older <i>lzma_utils</i> package. Its design principle is inherited from <i><b>zcmp</b></i> (from <i>gzip</i>) and <i><b>bzcmp</b></i> (from <i>bzip2</i>), allowing seamless comparison of compressed files by decompressing them on the fly. This avoids the need for users to manually manage temporary decompressed files. It's primarily developed and maintained as part of the broader <i>xz-utils</i> project.


title: PARAMETERS
content:
<b>[diff_options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any options understood by the <i>diff</i> command. <i>xzdiff</i> passes these directly to the underlying <i>diff</i> process.<br><br><b>file1</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the first file to compare. This can be an <i>xz</i> compressed file (e.g., <i>file.txt.xz</i>) or a regular uncompressed file.<br><br><b>file2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the second file to compare. This can also be an <i>xz</i> compressed file or a regular uncompressed file. If <i>file2</i> is omitted, <i>file1</i> is compared with standard input.<br><br>


title: DESCRIPTION
content:
<i>xzdiff</i> is a convenience script that allows users to compare two files using the standard <i>diff</i> utility, where one or both of the files may be compressed with <b>XZ</b> compression. It acts as a wrapper, automatically decompressing the files on-the-fly before piping their content to <i>diff</i>. This eliminates the need for manual decompression, temporary file creation, and subsequent deletion, simplifying the comparison of compressed data.<br><br>It behaves exactly like <i>diff</i>, passing all command-line arguments directly to the underlying <i>diff</i> command after handling the decompression. This makes it particularly useful for quickly comparing compressed log files, configuration archives, or any data stored in the <i>.xz</i> format without explicit prior decompression steps.


title: CAVEATS
content:
<b>Dependency:</b> <i>xzdiff</i> relies on the <i>diff</i> and <i>xzcat</i> (or <i>xz</i>) utilities being available in the system's PATH. If they are missing, the command will fail.<br><br><b>Performance:</b> While convenient, the on-the-fly decompression adds processing overhead. For extremely large files, manually decompressing the files first and then running <i>diff</i> might be marginally faster in some scenarios, though less convenient.<br><br><b>Error Handling:</b> If an input file is corrupted or not a valid <i>xz</i> file, <i>xzcat</i> will report an error, which <i>xzdiff</i> will propagate.


title: ENVIRONMENT VARIABLES
content:
<i>xzdiff</i> may be influenced by environment variables that affect its underlying commands. For instance, the <b>DIFF</b> environment variable can be used to specify an alternative <i>diff</i> command to execute instead of the default.


title: EXIT STATUS
content:
The exit status of <i>xzdiff</i> is typically the exit status of the <i>diff</i> command it invokes:<br><b>0:</b> Files are identical.<br><b>1:</b> Files differ.<br><b>2:</b> An error occurred (e.g., cannot access a file, invalid options).


title: HISTORY
content:
<i>xzdiff</i> is an integral part of the <b>xz-utils</b> package, which provides command-line tools for compressing and decompressing files using the LZMA2 algorithm in the XZ container format. Developed to offer superior compression ratios compared to older formats like Gzip and Bzip2, the <i>xz</i> utilities, including <i>xzdiff</i>, have become standard on many Linux distributions, reflecting the widespread adoption of the <i>xz</i> format for archiving, software distribution, and system logs.


title: PARAMETERS
content:
<b><b>-i</b>, <b>--ignore-case</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Ignore case distinctions in both the <i>pattern</i> and input files.<br><br><b><b>-v</b>, <b>--invert-match</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Invert the sense of matching, to select non-matching lines.<br><br><b><b>-c</b>, <b>--count</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Suppress normal output; instead print a count of matching lines for each input file.<br><br><b><b>-n</b>, <b>--line-number</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Prefix each line of output with the 1-based line number within its input file.<br><br><b><b>-A</b> <i>NUM</i>, <b>--after-context=</b><i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Print <i>NUM</i> lines of trailing context after matching lines.<br><br><b><b>-B</b> <i>NUM</i>, <b>--before-context=</b><i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Print <i>NUM</i> lines of leading context before matching lines.<br><br><b><b>-C</b> <i>NUM</i>, <b>--context=</b><i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Print <i>NUM</i> lines of leading and trailing context. Equals <b>-A</b> <i>NUM</i> <b>-B</b> <i>NUM</i>.<br><br><b><b>-E</b>, <b>--extended-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Interpret <i>pattern</i> as an extended regular expression (ERE).<br><br><b><b>-F</b>, <b>--fixed-strings</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Interpret <i>pattern</i> as a list of fixed strings, separated by newlines, any of which is to be matched.<br><br><b><b>-P</b>, <b>--perl-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Interpret <i>pattern</i> as a Perl regular expression (PCRE).<br><br><b><b>-l</b>, <b>--files-with-matches</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Suppress normal output; instead print the name of each input file from which output would normally have been printed.<br><br><b><b>-L</b>, <b>--files-without-match</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Suppress normal output; instead print the name of each input file from which no output would normally have been printed.<br><br><b><b>-q</b>, <b>--quiet</b>, <b>--silent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Suppress all normal output. Exit immediately with zero status if any match is found, one if no match is found, or two for errors.<br><br><b><b>-s</b>, <b>--no-messages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Suppress error messages about nonexistent or unreadable files.<br><br><b><b>-w</b>, <b>--word-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Select only those lines containing matches that form whole words.<br><br><b><b>-x</b>, <b>--line-regexp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Select only those matches that exactly match the whole line.<br><br><b><b>-o</b>, <b>--only-matching</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Print only the matched (non-empty) parts of a matching line, with each such part on a separate output line.<br><br><b><b>-r</b>, <b>--recursive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Read all files under each directory, recursively. This option is equivalent to <b>-R</b>.<br><br><b><b>--exclude=</b><i>GLOB</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Skip files whose base name matches <i>GLOB</i> (a wildcard pattern).<br><br><b><b>--include=</b><i>GLOB</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Search only files whose base name matches <i>GLOB</i>.<br><br><b><b>--exclude-dir=</b><i>DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Exclude directories matching the pattern <i>DIR</i> from recursive searches.<br><br>


title: DESCRIPTION
content:
<i>xzegrep</i> is a convenient command-line utility designed to search for patterns within compressed files (e.g., <i>*.gz</i>, <i>*.bz2</i>, <i>*.xz</i>) and present the output in an interactive pager. It typically acts as a wrapper around the <i>zgrep</i> command, piping its output to a pager like <i>less</i> or <i>more</i>. This integration allows users to efficiently navigate through potentially large search results from compressed log files or data archives, providing features like scrolling, searching within results, and highlighting. While <i>zgrep</i> itself performs the pattern matching on compressed data, <i>xzegrep</i> enhances the user experience by making the output more manageable and browsable, particularly when the search yields numerous lines. Its primary benefit lies in combining the powerful searching capabilities of <i>grep</i> (via <i>zgrep</i>) with the interactive viewing features of a pager, making it an invaluable tool for system administrators and developers analyzing compressed data.


title: CAVEATS
content:
<i>xzegrep</i> is often not a standalone binary command but rather a shell script or an alias that combines <i>zgrep</i> with a pager program (most commonly <i>less</i>). As such, its exact behavior and availability can vary between different Linux distributions or user environments. If <i>xzegrep</i> is not found, users can typically create their own version (e.g., <code><i>alias xzegrep='zgrep "$@" | less -R'</i></code>) to achieve the same functionality. The interactive features and keybindings depend entirely on the pager used (e.g., <i>less</i>).


title: CREATING YOUR OWN <I>XZEGREP</I>
content:
If <i>xzegrep</i> is not pre-installed on your system, you can easily create an alias or a shell script to replicate its functionality. A common approach is: <br><code><i>alias xzegrep='zgrep "$@" | less -R'</i></code><br>or a script named <i>xzegrep</i> in your <i>PATH</i>:<br><pre><i>#!/bin/sh<br>zgrep "$@" | less -R</i></pre><br>The <b>-R</b> option passed to <b>less</b> is crucial as it tells <b>less</b> to output "raw" control characters, which ensures that <b>grep</b>'s colorized output (if enabled) is correctly displayed.


title: INTERACTING WITH THE PAGER
content:
Once <i>xzegrep</i> displays the output, you are interacting with the pager (e.g., <b>less</b>). Common commands within <b>less</b> include: <br><b>q</b>: Quit<br><b>spacebar</b>: Scroll down a full screen<br><b>b</b>: Scroll up a full screen<br><b>/<i>pattern</i></b>: Search forward for a pattern<br><b>?<i>pattern</i></b>: Search backward for a pattern<br><b>n</b>: Go to the next match of the last search<br><b>N</b>: Go to the previous match of the last search.


title: HISTORY
content:
The concept of <i>xzegrep</i> emerged from the need to easily view the often voluminous output of searching compressed files. While <i>zgrep</i> effectively handles the decompression and searching, its raw output can be overwhelming for large datasets. Users and system administrators naturally started piping <i>zgrep</i>'s output into pagers like <i>less</i> for better readability and navigability. <i>xzegrep</i> is essentially a formalized or aliased version of this common workflow, providing a convenient shortcut. It doesn't have a distinct development history as a standalone project but rather represents a best practice and common utility script evolved from the practical usage of <i>zgrep</i> and interactive pagers in Unix-like environments.


title: PARAMETERS
content:
<b>-F, --fixed-strings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interpret <i>PATTERN</i> as a list of fixed strings, separated by newlines, any of which is to be matched. This is the core functionality implied by 'fgrep'.<br><br><b>-i, --ignore-case</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ignore case distinctions in <i>PATTERN</i> and input data.<br><br><b>-v, --invert-match</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select non-matching lines.<br><br><b>-c, --count</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output; instead print a count of matching lines for each input file.<br><br><b>-l, --files-with-matches</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output; instead print the name of each input file from which output would normally have been printed.<br><br><b>-L, --files-without-match</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress normal output; instead print the name of each input file from which no output would normally have been printed.<br><br><b>-n, --line-number</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prefix each line of output with the 1-based line number within its input file.<br><br><b>-H, --with-filename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the file name for each match. This is the default when there is more than one file to search.<br><br><b>-h, --no-filename</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the prefixing of file names on output when multiple files are searched.<br><br><b>-q, --quiet, --silent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all normal output. Exit immediately with zero status if any match is found, or with non-zero status otherwise.<br><br><b>-s, --no-messages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress error messages about non-existent or unreadable files.<br><br><b>--color[=WHEN]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use markers to highlight the matching strings. <i>WHEN</i> can be 'never', 'always', or 'auto'.<br><br><b>-A NUM, --after-context=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print NUM lines of trailing context after matching lines.<br><br><b>-B NUM, --before-context=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print NUM lines of leading context before matching lines.<br><br><b>-C NUM, --context=NUM</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print NUM lines of leading and trailing context around matching lines.<br><br>


title: DESCRIPTION
content:
<i>xzfgrep</i> is not a standalone command in standard Linux distributions, but rather a conceptual combination of <i>xzgrep</i> and <i>fgrep</i> (which is equivalent to <i>grep -F</i>).<br><br>Conceptually, it allows users to efficiently search for fixed strings (literal text patterns, not regular expressions) within files compressed using the XZ compression algorithm, without requiring prior manual decompression. This utility is invaluable for tasks such as analyzing log files, data archives, or any text-based content stored in .xz format. It functions by transparently decompressing the input XZ files on-the-fly and then applying a fixed-string search. This approach saves disk space and simplifies workflows by enabling direct interaction with compressed data, mirroring the functionality of <i>grep</i> for uncompressed files.


title: CAVEATS
content:
This command is not a natively compiled binary or a standard alias in typical Linux distributions. It represents the conceptual functionality achieved by using <b>xzgrep -F</b>. Therefore, when attempting to use "xzfgrep", one should use the equivalent <b>xzgrep -F</b> command instead. Its performance relies on the underlying <i>xzcat</i> for decompression and <i>grep -F</i> for searching, making it efficient but still dependent on system resources for large files. It specifically searches for fixed strings and does not interpret patterns as regular expressions.


title: STANDARD INPUT SUPPORT
content:
If no <i>FILE</i> arguments are provided, <i>xzfgrep</i> would read from standard input, assuming the input stream is XZ-compressed data. This allows piping compressed data directly to the command for searching.


title: EXIT STATUS
content:
The command would exit with a status of 0 if one or more lines are selected, 1 if no lines are selected, and 2 if an error occurred (e.g., inaccessible file).


title: HISTORY
content:
The lineage of this conceptual command traces back to two primary tools: <i>grep</i> and <i>xz</i>. <i>grep</i>, a fundamental Unix utility for searching plain-text data for lines matching a regular expression, was first developed by Ken Thompson in the early 1970s. Its variant <i>fgrep</i> (fixed grep) was later introduced to handle literal string searches more efficiently by avoiding regular expression parsing overhead. The <i>xz</i> compression format and its associated utilities (like <i>xzcat</i> and <i>xzgrep</i>) emerged much later, gaining popularity for their high compression ratios and integrity checking capabilities, serving as a modern alternative to <i>gzip</i> and <i>bzip2</i>. The conceptual "xzfgrep" combines these functionalities, allowing the efficiency of fixed-string searches to be applied directly to modern XZ-compressed archives.


title: SYNOPSIS
content:
<b>xzgrep</b> [<i>grep_options</i>] <i>PATTERN</i> [<i>FILE...</i>]<br><b>xzfgrep</b> [<i>grep_options</i>] <i>PATTERN</i> [<i>FILE...</i>]<br><b>xzegrep</b> [<i>grep_options</i>] <i>PATTERN</i> [<i>FILE...</i>]


title: PARAMETERS
content:
<b><i>PATTERN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The regular expression or fixed string to search for. This argument is required.<br><br><b><i>FILE...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more <i>.xz</i> compressed files (or uncompressed files) to search. If no files are specified, <b>xzgrep</b> reads from standard input.<br><br><b><i>grep_options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any option valid for the <b>grep</b> command can be passed to <b>xzgrep</b>. These options control search behavior, output format, and more. Examples include <b>-i</b> (ignore case), <b>-v</b> (invert match), <b>-r</b> (recursive search in directories), <b>-l</b> (list matching files), and <b>-n</b> (show line numbers).<br><br>


title: DESCRIPTION
content:
The <b>xzgrep</b> command is a utility designed for searching patterns within files compressed with the XZ algorithm. It functions as a wrapper around the standard <b>grep</b> command, allowing users to search for text strings or regular expressions in <i>.xz</i> files without explicitly decompressing them first.<br><br>When executed, <b>xzgrep</b> intelligently pipes the decompressed content of the specified XZ file(s) to <b>grep</b>'s standard input. This on-the-fly decompression and searching saves disk space by eliminating the need for temporary decompressed files and streamlines the workflow for handling compressed logs or archives.<br><br>It behaves almost identically to <b>grep</b>, accepting all of <b>grep</b>'s standard options and arguments. This makes it intuitive for users familiar with <b>grep</b>. It also provides aliases: <b>xzfgrep</b> (for fixed string searches, equivalent to <b>fgrep</b>) and <b>xzegrep</b> (for extended regular expressions, equivalent to <b>egrep</b>).


title: CAVEATS
content:
<b>xzgrep</b> relies on the <b>xz</b> utilities (specifically <b>xzcat</b> or <b>xzless</b>) and <b>grep</b> being available on the system. Performance may be impacted by the overhead of on-the-fly decompression, especially for very large files or on systems with limited CPU resources. While it primarily handles <i>.xz</i> files, it can also process uncompressed files directly.


title: ALIASES
content:
<b>xzfgrep</b> is an alias that operates like <b>xzgrep -F</b>, interpreting the <i>PATTERN</i> as a list of fixed strings. <b>xzegrep</b> is an alias that operates like <b>xzgrep -E</b>, interpreting the <i>PATTERN</i> as an extended regular expression. These aliases provide direct access to <b>grep</b>'s specific search modes.


title: ENVIRONMENT VARIABLES
content:
Like <b>grep</b>, <b>xzgrep</b> may honor environment variables such as <i>GREP_OPTIONS</i>, <i>GREP_COLOR</i>, and <i>GREP_COLORS</i>. These variables can influence its default behavior or output formatting, allowing for customization without specifying options on the command line every time.


title: EXIT STATUS
content:
The exit status of <b>xzgrep</b> is inherited directly from the <b>grep</b> command it invokes: <b>0</b> if lines were selected, <b>1</b> if no lines were selected, and <b>2</b> if an error occurred.


title: HISTORY
content:
<b>xzgrep</b> is part of the <b>xz</b> utilities suite, which was developed to provide command-line tools for the XZ data compression format, a modern successor to LZMA. Following the established pattern of similar utilities like <b>zgrep</b> (for <i>gzip</i> files) and <b>bzgrep</b> (for <i>bzip2</i> files), <b>xzgrep</b> was created to offer a convenient and consistent interface for searching within XZ compressed archives across Unix-like environments. Its design emphasizes seamless integration with the existing functionality of the <b>grep</b> command.


title: PARAMETERS
content:
<b><i>file...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to .xz compressed files, or other file types that <b><i>xzless</i></b> can decompress and display. If no file is specified or <i>file</i> is '-', <b><i>xzless</i></b> reads from standard input.<br><br>


title: DESCRIPTION
content:
<b><i>xzless</i></b> is a command-line utility that allows users to view the contents of files compressed with the XZ compression algorithm (typically .xz files) directly in the <b>less</b> pager. It acts as a convenient wrapper, enabling interactive browsing of compressed data without the need to first decompress the entire file to a temporary location or to disk.<br><br>When invoked, <b><i>xzless</i></b> internally decompresses the input file using <b>xz -dc</b> (or <b>xzcat</b>) and pipes the resulting decompressed stream to the <b>less</b> command. This seamless integration means that users can navigate, search, and view large compressed files with all the familiar functionalities of <b>less</b>, such as scrolling, pattern searching, and jumping to specific lines. It is particularly useful for examining compressed log files, documentation, or archives efficiently, saving disk space and time. Its design follows the pattern of similar utilities like <b>zless</b> for Gzip files and <b>bzless</b> for Bzip2 files, providing a consistent user experience for various compressed formats.


title: CAVEATS
content:
<b><i>xzless</i></b> relies on the <b>xz</b> and <b>less</b> utilities being installed and accessible in the system's PATH. <br>Performance can be marginally affected by on-the-fly decompression, especially with very large files or on systems with limited CPU resources. <br>Viewing extremely large files might consume more memory in the <b>less</b> buffer than viewing smaller files. <br>Corrupted .xz files will result in decompression errors and will not be displayed correctly.


title: HOW IT WORKS
content:
<b><i>xzless</i></b> is a shell script that functions by creating a pipe. It executes <b>xz -dc</b> (or <b>xzcat</b>) to decompress the specified file(s) to standard output, and then pipes this decompressed data to the standard input of the <b>less</b> pager. The command chain typically looks like: <br><i>xz -dc [file] | less</i> <br>This pipeline allows <b>less</b> to display the file content incrementally as it is decompressed, providing an efficient way to view even very large compressed files without requiring significant temporary disk space.


title: LESS OPTIONS AND ENVIRONMENT VARIABLES
content:
While <b><i>xzless</i></b> itself doesn't have unique command-line options, it effectively supports all options available to the <b>less</b> pager, as it simply passes the decompressed stream to <b>less</b>. Options like <b>-N</b> (display line numbers), <b>+F</b> (follow end of file), <b>-/<i>pattern</i></b> (search for pattern), etc., can be used. These options are usually passed directly after <b><i>xzless</i></b> and before the filename, or can be specified via the <b>LESS</b> environment variable (e.g., <i>export LESS='-N -i'</i>). <br>The <b>LESSOPEN</b> environment variable can also be relevant; <b><i>xzless</i></b> often leverages <b>LESSOPEN</b> to register itself as a preprocessor for .xz files, allowing <b>less</b> to automatically invoke <b><i>xzless</i></b> when opening such files directly.


title: HISTORY
content:
The <b><i>xzless</i></b> command is part of the <b>xz</b> utilities, a suite of tools for manipulating files compressed in the XZ format. The XZ format itself is a modern, high-compression data compression format based on the LZMA2 algorithm, designed as a successor to LZMA and often replacing older formats like Gzip and Bzip2 in many Linux distributions for package management and archiving. <br><b><i>xzless</i></b> was developed following the established pattern of convenient wrappers like <b>zless</b> (for Gzip) and <b>bzless</b> (for Bzip2), aiming to provide a consistent and user-friendly way to interactively view compressed files without explicit decompression steps. Its development is tied to the evolution and adoption of the XZ compression standard.


title: PARAMETERS
content:
<b><i>file...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more <i>.xz</i> or <i>.lzma</i> compressed files to view. If omitted, standard input is read.<br><br><b><i>[options]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any options provided on the command line are passed directly to the underlying pager program (e.g., <b>more</b> or <b>less</b>). Refer to the pager's manual for available options.<br><br>


title: DESCRIPTION
content:
<b>xzmore</b> is a utility designed to allow users to view the contents of files compressed with <i>.xz</i> or <i>.lzma</i> without needing to decompress them permanently to disk. It functions by piping the output of <b>xzcat</b> (or <b>unxz</b>) directly into a pager program, typically <b>more</b> (or <b>less</b> if <b>more</b> is not available or explicitly configured). This provides a convenient way to inspect large compressed text files incrementally, making it an essential tool for system administrators and developers working with compressed logs or data. If no filenames are provided, <b>xzmore</b> reads from standard input, making it highly versatile for use in command pipelines where compressed data is streamed. Its primary advantage is avoiding the temporary creation of uncompressed files, saving disk space and reducing I/O operations.


title: CAVEATS
content:
<b>xzmore</b> relies on the availability of <b>xzcat</b> (or <b>unxz</b>) and a pager program (like <b>more</b> or <b>less</b>) on the system. Its behavior and available functionalities for navigation and searching are entirely dependent on the specific pager configured (e.g., via the <i>PAGER</i> environment variable). It is primarily designed for text files and may not display binary files meaningfully.


title: ENVIRONMENT VARIABLES
content:
The behavior of <b>xzmore</b> can be influenced by the <i>PAGER</i> environment variable. If set, <b>xzmore</b> will use the program specified by this variable as its pager instead of the default (typically <b>more</b>). For example, setting <i>export PAGER=less</i> would make <b>xzmore</b> use <b>less</b> for pagination, which offers more advanced features.


title: HISTORY
content:
<b>xzmore</b> is part of the <i>xz</i> utilities package, which provides a suite of tools for handling <i>.xz</i> and <i>.lzma</i> compressed files. The <i>xz</i> format itself is a modern, high-compression ratio successor to the older <i>lzma</i> format and is widely used in Linux distributions for software packages, archives, and system logs. <b>xzmore</b> emerged as a convenient front-end, similar to <b>zmore</b> for <i>gzip</i> files, allowing users to quickly inspect compressed content without full decompression, fitting into the standard Unix philosophy of small, focused tools.


title: SYNOPSIS
content:
<b>yay</b> [<i>options</i>] [<i>targets</i>]<br>Common usage examples:<br><b>yay -Syu</b> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>(Update all system and AUR packages)</i><br><b>yay -S</b> <i>&lt;package_name&gt;</i> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>(Install a package from official repos or AUR)</i><br><b>yay -Ss</b> <i>&lt;keyword&gt;</i> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>(Search for packages in official repos and AUR)</i><br><b>yay -R</b> <i>&lt;package_name&gt;</i> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>(Remove a package)</i>


title: PARAMETERS
content:
<b><b>-S</b>, <b>--sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes packages. Used for installing new packages, upgrading system, or refreshing package databases.<br><br><b><b>-R</b>, <b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes specified packages from the system.<br><br><b><b>-U</b>, <b>--upgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs or upgrades packages by specifying local package files (e.g., .pkg.tar.xz).<br><br><b><b>-Q</b>, <b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the package database for information about installed or available packages.<br><br><b><b>-G</b>, <b>--getpkgbuild</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads the <i>PKGBUILD</i> file for a specified package from the AUR or official repositories.<br><br><b><b>-P</b>, <b>--print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints <i>yay</i>'s current configuration or cache information.<br><br><b><b>--noconfirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses all interactive confirmation prompts during operations, proceeding automatically.<br><br><b><b>--nodiff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of <i>PKGBUILD</i> differences when installing or updating AUR packages.<br><br><b><b>--needed</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents reinstallation of targets that are already up-to-date during installation or sync operations.<br><br><b><b>--devel</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes development packages (e.g., Git, SVN packages) in update checks, often used with <b>-Syu</b>.<br><br><b><b>--aur</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the operation to only packages found in the Arch User Repository, excluding official repositories.<br><br><b><b>--repo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the operation to only packages found in official Arch Linux repositories, excluding the AUR.<br><br>


title: DESCRIPTION
content:
The command <i>"ya"</i> is not a standard Linux command. This analysis describes <i>"yay"</i> (Yet Another Yogurt), a widely popular and powerful command-line tool for Arch Linux. <i>yay</i> acts as an advanced wrapper for <i>pacman</i>, Arch's official package manager, providing seamless integration with the AUR (Arch User Repository). It allows users to easily search, install, update, and manage packages from both official repositories and the vast community-driven AUR. Known for its user-friendly interface, speed, and robust dependency resolution, <i>yay</i> significantly simplifies software management for Arch users by offering a unified workflow.


title: CAVEATS
content:
As stated, the direct command <i>"ya"</i> is not a standard Linux utility. This information pertains to <i>"yay"</i>, a specific AUR helper widely used on Arch Linux and its derivatives. <br><i>yay</i> is exclusive to Arch-based distributions and requires <i>pacman</i> to function.<br>Packages from the AUR are user-contributed; they are not officially vetted or supported by Arch Linux. Users should exercise caution and review <i>PKGBUILD</i>s before installing AUR packages.


title: AUR INTEGRATION AND AUTOMATION
content:
<i>yay</i> excels at automating the process of fetching, building, and installing packages from the Arch User Repository. It intelligently resolves dependencies, handles build processes, and offers interactive prompts, streamlining the often complex AUR workflow.


title: CONFIGURATION AND CUSTOMIZATION
content:
<i>yay</i> provides extensive configuration options, allowing users to customize its behavior, build processes, and default settings through a dedicated configuration file or environment variables. This flexibility enables users to tailor <i>yay</i> to their specific needs and preferences.


title: HISTORY
content:
<i>yay</i> was developed by J.C. Hong (Jguer) as a modern and more efficient successor to earlier AUR helpers like <i>yaourt</i> and <i>pacaur</i>. It quickly gained significant popularity within the Arch Linux community due to its superior speed, robust dependency resolution, and intuitive command-line interface. Its active development on GitHub and widespread adoption have established it as a de facto standard tool for managing software on Arch Linux, integrating both official repository and AUR packages seamlessly.


title: PARAMETERS
content:
<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;Show version information and exit.<br><br><b><b>-e</b> <i>expression</i>, <b>--execute</b> <i>expression</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the given <i>expression</i> and exit. Useful for non-interactive scripting.<br><br><b><b>-s</b> <i>file</i>, <b>--script</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute commands from the specified <i>file</i>. This is an alternative to passing files as arguments.<br><br><b><b>-i</b>, <b>--interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force interactive mode after processing any specified files or expressions.<br><br><b><b>-c</b>, <b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check the syntax of input files without executing them, useful for debugging scripts.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the startup banner and other informative messages.<br><br><b><b>-l</b> <i>file</i>, <b>--load</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load an additional <i>file</i> at startup, similar to the <b>Load()</b> command inside <b>yacas</b>.<br><br><b><b>-p</b>, <b>--pretty-print</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable pretty-printing of output, if the terminal supports it.<br><br>


title: DESCRIPTION
content:
<b>yacas</b> (<b>Y</b>et <b>A</b>nother <b>C</b>omputer <b>A</b>lgebra <b>S</b>ystem) is a free, general-purpose computer algebra system. It is designed to perform symbolic manipulation of mathematical expressions, arbitrary-precision arithmetic, and offers a powerful, extensible programming language. Users can interact with <b>yacas</b> through an interactive shell, or execute commands from scripts. Its core philosophy emphasizes a lightweight design, making it suitable for integration into other applications and for various computing environments. <b>yacas</b> supports a wide range of mathematical operations including calculus (differentiation, integration), solving equations, series expansions, matrix algebra, and number theory, making it a versatile tool for research, education, and scientific computing.


title: CAVEATS
content:
<b>yacas</b> is primarily a command-line tool, lacking a graphical user interface which might be preferred by some users. Its custom programming language requires a learning investment. While powerful, for extremely large-scale or computationally intensive symbolic tasks, specialized commercial software might offer better performance and broader functionality.


title: USAGE EXAMPLES
content:
To start an interactive <b>yacas</b> session:<br><b>yacas</b><br><br>To execute a <b>yacas</b> script file (e.g., <i>my_script.ys</i>):<br><b>yacas</b> <i>my_script.ys</i><br><br>To execute a single expression from the command line:<br><b>yacas</b> <b>-e</b> "<i>Simplify(Sin(x)^2 + Cos(x)^2)</i>"


title: INTERNAL PROGRAMMING LANGUAGE
content:
<b>yacas</b> features its own powerful, Lisp-like programming language. This allows users to extend its functionality, define new functions, and write complex algorithms directly within the system. The language supports pattern matching, rule-based rewriting, and various control structures, making it highly flexible for symbolic manipulation and custom mathematical problem-solving.


title: HISTORY
content:
<b>yacas</b> was initially developed by Ayal Pinkus around 1999, with the goal of creating a lightweight, extensible, and free computer algebra system. Its design emphasizes a small core, an intuitive syntax, and a powerful, Lisp-like programming language for extensibility. Over the years, it has been maintained and improved by a community of developers, expanding its mathematical capabilities and refining its programming environment. Its open-source nature and portability have contributed to its widespread availability in various Linux distributions and other operating systems.


title: PARAMETERS
content:
<b><b>-b</b> <i>file_prefix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the prefix for the names of the output files (e.g., <i>file_prefix.tab.c</i>, <i>file_prefix.tab.h</i>). Instead of the default 'y', output files will start with <i>file_prefix</i>.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a header file (default: <i>y.tab.h</i>) containing definitions for the token names (enums or #defines) used in the grammar. This file is crucial for the lexical analyzer.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the generation of <i>#line</i> directives in the output C code. This can be useful when debugging the generated parser itself, as it prevents line numbers from pointing back to the <b>yacc</b> input file.<br><br><b><b>-o</b> <i>outfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output parser C source file instead of the default <i>y.tab.c</i>.<br><br><b><b>-p</b> <i>prefix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the prefix of the external names used in the generated parser (e.g., <i>yyparse</i> becomes <i>prefixparse</i>, <i>yylex</i> becomes <i>prefixlex</i>). Useful for avoiding name collisions when linking multiple parsers into one executable.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a verbose description file (default: <i>y.output</i>) that summarizes the grammar, the state machine, and potential conflicts (shift/reduce, reduce/reduce) generated by <b>yacc</b>. This file is invaluable for debugging grammar ambiguities.<br><br>


title: DESCRIPTION
content:
The <b>yacc</b> command, short for "Yet Another Compiler Compiler", is a powerful programming tool that generates a parser (the syntactic analysis part of a compiler) from a formal grammar specification. It is widely used in the development of compilers, interpreters, and other language processing tools.<br><br><b>yacc</b> takes an input file, typically with a <i>.y</i> extension, which describes the grammar of a language using Backus-Naur Form (BNF) or a similar notation, along with associated C code actions for each grammar rule. Upon successful execution, <b>yacc</b> generates a C source file (<i>y.tab.c</i> by default) containing the LALR(1) parsing table and the parsing logic. This generated code can then be compiled with a standard C compiler. It is often used in conjunction with lexical analyzer generators like <b>lex</b> or <b>flex</b>, where <b>lex</b> handles tokenization (lexical analysis) and <b>yacc</b> handles the parsing of these tokens into a structured syntax tree (syntactic analysis).


title: CAVEATS
content:
The original <b>yacc</b> is an older tool and may not be installed by default on modern Linux distributions. It has largely been superseded by <b>GNU Bison</b> (often just referred to as <b>bison</b>), which offers more features, better error reporting, and is actively maintained. While <b>bison</b> is mostly compatible with <b>yacc</b> grammars, some <b>yacc</b>-specific features might not be present or behave differently in <b>bison</b>, and vice-versa. For new projects, <b>bison</b> is generally recommended over traditional <b>yacc</b>.


title: GRAMMAR FILE STRUCTURE
content:
A <b>yacc</b> grammar file (e.g., <i>parser.y</i>) typically consists of three sections, separated by <i>%%</i> delimiters:<br>1. <i>Declarations</i>: Contains C declarations, <i>%token</i>, <i>%type</i>, and <i>%start</i> directives defining tokens, non-terminal types, and the start symbol.<br>2. <i>Grammar Rules</i>: Defines the language's syntax using production rules (e.g., 'expression: term '+' term;') and associated C code actions to be executed when a rule is matched.<br>3. <i>User Subroutines</i>: Includes additional C functions, such as <i>main()</i>, <i>yyerror()</i> (for error handling), and <i>yylex()</i> (the lexical analyzer function, usually provided by <b>lex</b>/<b>flex</b>), required for the parser to operate.


title: OUTPUT FILES
content:
By default, when invoked with a grammar file (e.g., <i>grammar.y</i>), <b>yacc</b> generates two primary files:<br><i>y.tab.c</i>: The C source file containing the generated parser function (typically named <i>yyparse()</i>) and the LALR(1) parsing tables. This file is then compiled into an executable.<br><i>y.tab.h</i>: A C header file (generated when the <b>-d</b> option is used) defining the token numbers for all terminal symbols declared in the grammar. This file is essential for the lexical analyzer (e.g., generated by <b>lex</b> or <b>flex</b>) to use the same token definitions as the parser, ensuring proper communication between the two stages.


title: HISTORY
content:
<b>yacc</b> was originally developed by Stephen C. Johnson at Bell Labs in the early 1970s for the Unix operating system. It became a cornerstone tool for compiler construction and significantly influenced the design of subsequent language processing utilities. Its elegant approach to defining syntax and generating parsers made it indispensable for developers. The widespread adoption of <b>yacc</b> led to the development of compatible and enhanced versions, most notably <b>GNU Bison</b>, which aimed to be a free software replacement for <b>yacc</b> while adding numerous extensions and improvements. Although direct usage of the original <b>yacc</b> might be less common on modern systems, its legacy lives on through <b>bison</b> and similar tools.


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <b>yadm</b> repository in the user's home directory.<br><br><b>add <files>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds specified files or directories to the <b>yadm</b> repository for tracking, similar to <b>git add</b>.<br><br><b>commit [options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Records changes to the repository, identical to <b>git commit</b>.<br><br><b>push [options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates remote references along with associated objects, identical to <b>git push</b>.<br><br><b>pull [options]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches from and integrates with another repository or a local branch, identical to <b>git pull</b>.<br><br><b>clone <repository> [directory]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clones a <b>yadm</b> repository from a remote location, configuring it for your system.<br><br><b>bootstrap</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a custom <i>bootstrap</i> script (e.g., <i>~/.yadm/bootstrap</i>) after cloning or for initial setup.<br><br><b>encrypt <files>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts specified files using <i>GPG</i> before adding them to the repository.<br><br><b>decrypt <files>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts previously encrypted files within the repository.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the working tree status, identical to <b>git status</b>.<br><br><b>diff</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows changes between commits, commit and working tree, etc., identical to <b>git diff</b>.<br><br><b>config <key> [value]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages <b>yadm</b>-specific configuration settings or proxies to <b>git config</b>.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <b>yadm</b> or a specific command.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>yadm</b> version.<br><br>


title: DESCRIPTION
content:
<b>yadm</b> (Yet Another Dotfile Manager) is a powerful command-line tool designed to manage your dotfiles (configuration files) by leveraging <i>Git</i>. Unlike managing dotfiles directly within your home directory, <b>yadm</b> maintains its Git repository in a separate, dedicated location (typically <i>~/.yadm</i>). It then either symlinks or copies the tracked files into your home directory, keeping your setup clean while utilizing Git's full capabilities for version control, branching, and remote synchronization.<br><br>Users can easily track, commit, and push changes to their configuration files, share them across multiple machines, and handle machine-specific settings through templating and alternative branches. <b>yadm</b> also includes features like file encryption using <i>GPG</i> for sensitive data and the ability to execute bootstrap scripts for initial system setup or post-clone configurations.


title: CAVEATS
content:
<b>yadm</b> requires <i>Git</i> to be installed on your system. For file encryption and decryption features, <i>GPG</i> (GNU Privacy Guard) must also be available. Users should be familiar with basic <i>Git</i> workflows, as <b>yadm</b> primarily acts as a wrapper around <i>Git</i> commands. Care should be taken when adding sensitive files, ensuring they are properly encrypted or excluded to avoid exposing personal data.


title: INITIAL SETUP AND USAGE
content:
To begin managing your dotfiles with <b>yadm</b>, first initialize a new repository using <b>yadm init</b>. Then, add your desired configuration files, for example, <b>yadm add ~/.bashrc ~/.gitconfig</b>. Commit your changes with <b>yadm commit -m "Initial dotfiles"</b>. To synchronize with a remote repository, you can add a remote and push (e.g., <b>yadm remote add origin git@github.com:user/dotfiles.git</b> followed by <b>yadm push -u origin master</b>), or clone an existing repository with <b>yadm clone &lt;repository_url&gt;</b>. After cloning, the <b>yadm bootstrap</b> command can be used to execute a setup script for system-specific configurations or initial package installations.


title: TEMPLATING AND ALTERNATIVES
content:
<b>yadm</b> supports flexible templating, allowing for machine-specific configurations. Files ending with <i>.yadm</i> (e.g., <i>~/.gitconfig.yadm</i>) are processed as templates, typically using <i>Jinja2</i> syntax. This enables embedding conditional logic based on hostname, operating system, or other variables within your dotfiles. Furthermore, <b>yadm</b> provides mechanisms to manage different versions of files for specific systems or purposes by utilizing <i>Git</i> branches or defining alternative file locations, offering powerful adaptability for diverse environments.


title: HISTORY
content:
<b>yadm</b> was developed by Mike Boone (<i>TheCyberSaint</i>) to offer a streamlined, Git-centric approach to managing dotfiles. Its creation was driven by the desire for a tool that leverages <i>Git's</i> full power without the common pitfalls of directly initializing a <i>Git</i> repository in the home directory, or the complexities of more opinionated dotfile managers. The project focuses on being a thin, intuitive wrapper around <i>Git</i>, making it immediately familiar to users already comfortable with <i>Git</i>, and emphasizing simplicity and direct control over dotfiles.


title: SYNOPSIS
content:
<b>yadm</b> [<I>options</I>] <I>command</I> [<I>arguments</I>]<br><br>Common commands:<br><b>yadm</b> <I>init</I><br><b>yadm</b> <I>add</I> <I>&lt;file&gt;</I>...<br><b>yadm</b> <I>commit</I> [<I>options</I>]<br><b>yadm</b> <I>status</I><br><b>yadm</b> <I>pull</I><br><b>yadm</b> <I>push</I><br><b>yadm</b> <I>config</I> <I>&lt;key&gt;</I> [<I>&lt;value&gt;</I>]<br><b>yadm</b> <I>bootstrap</I><br><b>yadm</b> <I>encrypt</I> <I>&lt;file&gt;</I>...<br><b>yadm</b> <I>decrypt</I> <I>&lt;file&gt;</I>...


title: PARAMETERS
content:
<b><i>--help, -h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><i>--batch, -b</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable interactive prompts, useful for scripting.<br><br><b><i>--debug, -d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output for detailed operation tracing.<br><br><b><i>--git, -g</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass subsequent arguments directly to the underlying <b>git</b> command.<br><br><b><i>--repo &lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the path to the <b>yadm</b> repository (default: ~/.yadm).<br><br><b><i>--config &lt;key&gt;=&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a configuration variable for the duration of the command execution.<br><br><b><i>--gpg-decrypt</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force GPG decryption of files before processing them.<br><br><b><i>--gpg-encrypt</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force GPG encryption of files after processing them.<br><br><b><i>--no-gpg</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable GPG processing for the current command.<br><br><b><i>--ignore-gpg-error</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue execution even if GPG operations encounter errors.<br><br><b><i>init</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new <b>yadm</b> repository in the user's home directory.<br><br><b><i>add &lt;file&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds specified files or directories to the <b>yadm</b> repository.<br><br><b><i>commit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Records changes to the repository with a commit message.<br><br><b><i>status</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the working tree status, including untracked, modified, and staged files.<br><br><b><i>pull</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches changes from a remote repository and integrates them into the current branch.<br><br><b><i>push</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pushes local changes to a remote repository.<br><br><b><i>config &lt;key&gt; [&lt;value&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gets or sets configuration options for <b>yadm</b> or the underlying <b>git</b> repository.<br><br><b><i>bootstrap</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs initial setup scripts defined in the <b>yadm</b> repository.<br><br><b><i>encrypt &lt;file&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encrypts specified files in the repository using GPG.<br><br><b><i>decrypt &lt;file&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts specified files in the repository using GPG.<br><br><b><i>remove &lt;file&gt;...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes files from the <b>yadm</b> repository and the working directory.<br><br><b><i>checkout [&lt;branch&gt;]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches branches or restores working tree files.<br><br><b><i>clone &lt;repository&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clones a <b>yadm</b> repository from a remote URL.<br><br>


title: DESCRIPTION
content:
<b>YADM</b>, or <I>Yet Another Dotfiles Manager</I>, is a powerful command-line tool designed to help users manage their configuration files (dotfiles) across multiple systems using Git. It simplifies the process of synchronizing, backing up, and deploying personalized settings by treating your dotfiles as a Git repository. <u>Note: While the query refers to "yadm-alt", this analysis focuses on the widely recognized and standard "yadm" command, as "yadm-alt" is not a distinct standard utility and is likely a local alias or misnomer for "yadm".</u><br><br>Unlike simply symlinking files, <b>YADM</b> provides advanced features such as GPG encryption for sensitive data, templating capabilities, and the ability to define alternative files for different operating systems or environments. It integrates seamlessly with existing Git workflows, allowing users to leverage familiar commands for version control. By abstracting the complexities of dotfile management, <b>YADM</b> enables a consistent user experience across machines, making it an indispensable tool for developers and system administrators.


title: CAVEATS
content:
While powerful, <b>yadm</b> requires a good understanding of Git concepts to be used effectively. Misuse can lead to data loss or configuration conflicts. GPG encryption setup can be complex and requires careful key management. It is designed for managing dotfiles, not as a general-purpose system configuration management tool.


title: ALTERNATIVE FILES
content:
<b>YADM</b> supports 'alternative files' which allow different versions of a dotfile based on hostname, OS, or other criteria. For instance, you can have a <I>~/.bashrc.macos</I> and <I>~/.bashrc.linux</I>, and <b>yadm</b> will automatically symlink the correct one based on your system configuration. This is managed using the <I>yadm alt</I> command.


title: HOOKS
content:
<b>YADM</b> provides a powerful hook mechanism similar to Git hooks. Users can place executable scripts in the <I>~/.yadm/hooks</I> directory (e.g., <I>bootstrap</I>, <I>pre-pull</I>, <I>post-commit</I>). These hooks execute at specific points in <b>yadm</b>'s lifecycle, enabling custom actions like installing software, setting up symlinks for non-dotfiles, or post-update cleanups.


title: GPG ENCRYPTION
content:
For sensitive information like API keys or personal tokens within dotfiles, <b>yadm</b> offers integrated GPG encryption. Files can be encrypted directly within the repository, ensuring they remain secure even if the repository is publicly accessible. <b>Yadm</b> handles the encryption and decryption process seamlessly, provided GPG is properly configured.


title: HISTORY
content:
<b>YADM</b> was created by <I>ThePrimeagen</I> (aka TJ DeVries) as a lightweight, Git-centric solution for managing dotfiles, aiming to be simpler and more flexible than other existing tools. It gained popularity for its direct integration with Git, allowing users to leverage all Git features while managing their personal configurations. Its development is community-driven, continuously evolving to meet the needs of users seeking an efficient and robust dotfile management system.


title: DESCRIPTION
content:
<b>yadm-bootstrap</b> is a subcommand of the <b>yadm</b> dotfile manager, specifically designed for the initial setup and configuration of a new Linux system. Its primary purpose is to automate the installation of packages and execution of scripts immediately after the user's <b>yadm</b> dotfiles repository has been cloned.<br><br>The typical workflow involves first cloning your <b>yadm</b> repository (which contains your dotfiles and <b>yadm</b> configurations) to the home directory, and then executing <b>yadm bootstrap</b>. This command will look for specific configuration files:<br><i><b>~/.config/yadm/bootstrap</b></i> (or <i><b>~/.yadm/bootstrap</b></i> as a fallback) for package definitions, and<br>the <i><b>bootstrap</b></i> section within <i><b>~/.config/yadm/config</b></i> (or <i><b>~/.yadm/config</b></i>) for script execution.<br><br>If a `bootstrap` file exists, <b>yadm</b> attempts to install listed packages using the appropriate system package manager (e.g., `apt`, `dnf`, `pacman`). Concurrently, commands specified in the `bootstrap` section of the config file are executed, allowing for custom setup tasks like setting permissions, creating directories, or launching other setup scripts. This command streamlines the process of getting a new machine quickly configured to a user's preferred environment.


title: CAVEATS
content:
<ul><li>Requires a <b>yadm</b> repository to be already cloned to the system for the configuration files (<i><b>~/.yadm/bootstrap</b></i> and <i><b>~/.yadm/config</b></i>) to be present and effective.</li><li>Relies on the system having an identifiable package manager (e.g., `apt`, `dnf`, `pacman`) for automatic package installation.</li><li>Scripts executed via the <i><b>bootstrap</b></i> section of the config file run with the current user's permissions, so root-level operations might require `sudo` within those scripts.</li></ul>


title: BOOTSTRAP CONFIGURATION FILES
content:
The behavior of <b>yadm bootstrap</b> is defined by two key configuration sources:<br>1. <b><i>~/.config/yadm/bootstrap</i></b> (or <b><i>~/.yadm/bootstrap</i></b>): This file lists packages to be installed. Each line typically contains a package name. `yadm` attempts to use the system's package manager to install these.<br>2. The <b><i>bootstrap</i></b> section within <b><i>~/.config/yadm/config</i></b> (or <b><i>~/.yadm/config</i></b>): This section contains shell commands that will be executed sequentially. It allows for arbitrary scripting, such as creating directories, setting up symlinks, or running other setup tools that are not directly handled by package installation.


title: HISTORY
content:
The <b>bootstrap</b> functionality is a core component of <b>yadm</b>, a dotfile manager created by TheLocehiliosan. It was designed from early stages to address the common need for a streamlined initial setup process on new systems, allowing users to quickly configure their environment after deploying their dotfiles. Its integration provides a robust and automated way to handle dependencies and run post-install scripts, reflecting a focus on ease of use and reproducibility for dotfile management.


title: PARAMETERS
content:
<b><i>&lt;repository&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The URL (e.g., SSH, HTTPS) or local path to the Git repository containing your dotfiles. This is a mandatory argument.<br><br><b><i>[ &lt;directory&gt; ]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. The path where YADM will store its bare Git repository. If omitted, YADM defaults to creating the bare repository at <i>~/.yadm/repo.git</i>. This is the Git repository itself, not your home directory where files are managed.<br><br><b><i>[ options ]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any valid options supported by the underlying <b>git clone</b> command. <b>yadm clone</b> passes all recognized options and arguments directly to <b>git clone</b>. Examples include <i>--branch &lt;name&gt;</i> for cloning a specific branch, <i>--depth &lt;num&gt;</i> for a shallow clone, or <i>--recursive</i> for initializing submodules.<br><br>


title: DESCRIPTION
content:
The `yadm-clone` command is a fundamental subcommand of YADM (Yet Another Dotfiles Manager), designed to initialize a new YADM environment. It works by cloning an existing Git repository, which typically contains your dotfiles, as a bare repository. Unlike a standard `git clone` that creates a new working directory populated with files, `yadm-clone` sets up a bare Git repository (by default in <i>~/.yadm/repo.git</i>) and configures Git to manage files directly within your home directory (<i>~</i>) by setting `core.worktree` and `GIT_DIR` appropriately. This command establishes the foundation for YADM to track, manage, and synchronize your configuration files across multiple machines. It's the first step to bringing your dotfiles under YADM's control.


title: CAVEATS
content:
<b>Git Dependency:</b> <b>yadm-clone</b> relies on Git being installed and accessible in the system's PATH.<br><br><b>Bare Repository:</b> It establishes a bare Git repository, which means the repository itself (e.g., <i>.git</i> directory) is separated from the working tree (your home directory). This is YADM's core mechanism for managing dotfiles.<br><br><b>No Automatic Checkout:</b> After successfully cloning the repository, <b>yadm-clone</b> does not automatically populate your home directory with the dotfiles. You will typically need to run <b>yadm checkout</b> or <b>yadm pull</b> afterwards to synchronize the files from the repository to your working directory.<br><br><b>Overwriting Existing Files:</b> Be cautious when performing initial setup on a system with existing dotfiles, as subsequent <b>yadm checkout</b> or <b>yadm pull</b> operations can overwrite unmanaged files if not handled carefully.


title: INITIAL SETUP WORKFLOW
content:
The typical workflow after running <b>yadm clone</b> involves a subsequent command to populate your home directory. For instance, after <i>yadm clone git@github.com/user/dotfiles.git</i>, you would usually execute <i>yadm checkout</i> or <i>yadm pull</i> to bring the managed dotfiles from the cloned bare repository into your <i>~</i> (home) directory. This two-step process ensures the repository is correctly set up before files are deployed.


title: BARE REPOSITORY CONCEPT
content:
<b>yadm clone</b> fundamentally sets up a bare Git repository. In Git, a 'bare' repository does not have a working directory; it only contains the Git metadata (objects, refs, etc.). YADM cleverly uses this by setting your home directory as the working tree and the bare repository (e.g., <i>~/.yadm/repo.git</i>) as the Git directory. This allows Git to track changes and manage files directly in your home directory without needing a separate project folder, which is ideal for dotfiles.


title: HISTORY
content:
YADM (Yet Another Dotfiles Manager) was created by Mike Goltzman to provide a more streamlined and robust way to manage dotfiles using Git, addressing some complexities of traditional bare Git repository setups. The <b>yadm-clone</b> command is a foundational part of YADM, designed from its inception to simplify the initial setup and adoption of YADM by encapsulating the necessary Git commands and configurations for a bare repository dotfile management system. Its development has focused on ease of use and integrating smoothly with the broader YADM ecosystem.


title: SYNOPSIS
content:
<b>yadm config</b> [--local | --global | --system] &lt;variable&gt; [&lt;value&gt;]<br><b>yadm config</b> [--local | --global | --system] --get &lt;variable&gt;<br><b>yadm config</b> [--local | --global | --system] --set &lt;variable&gt; &lt;value&gt;<br><b>yadm config</b> [--local | --global | --system] --unset &lt;variable&gt;<br><b>yadm config</b> [--local | --global | --system] --list<br><b>yadm config</b> [--local | --global | --system] --edit


title: PARAMETERS
content:
<b>--local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Act on the configuration specific to the current <b>yadm</b> repository.<br><br><b>--global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Act on the per-user global configuration, typically stored in <i>~/.config/yadm/config</i>.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Act on the system-wide configuration, typically found in <i>/etc/yadm/config</i>.<br><br><b>--get &lt;variable&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieve the value of a specific configuration variable.<br><br><b>--set &lt;variable&gt; &lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the value of a specific configuration variable. If the variable already exists, its value is updated; otherwise, it is created.<br><br><b>--unset &lt;variable&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove a specific configuration variable from the configuration file.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all configuration variables and their values from all applicable levels (system, global, local).<br><br><b>--edit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open the relevant configuration file in an editor for manual editing. The editor is determined by the <i>EDITOR</i> environment variable or <b>yadm</b>'s internal configuration.<br><br><b>&lt;variable&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the configuration variable to operate on (e.g., <i>core.editor</i>, <i>yadm.encryptionMethod</i>).<br><br><b>&lt;value&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The value to set for the specified configuration variable.<br><br>


title: DESCRIPTION
content:
<i>yadm-config</i>, more commonly invoked as <b>yadm config</b>, is a subcommand of the <b>yadm</b> (Yet Another Dotfiles Manager) utility. It is used to get, set, or list configuration variables that control <b>yadm</b>'s behavior. Similar to <b>git config</b>, it allows users to manage settings at different levels: local to the current <b>yadm</b> repository, global for the current user, or system-wide. These settings can control various aspects, such as the encryption method, the default editor, specific hooks, or remote repository details. It's a fundamental tool for customizing the <b>yadm</b> experience and ensuring it behaves as desired for different projects or environments.


title: CAVEATS
content:
The command is an internal subcommand, meaning it's invoked as <b>yadm config</b>, not as a standalone <b>yadm-config</b> executable. <br>When reading configuration values, <b>yadm</b> searches for variables in the following order: local (repository), global (user), then system-wide. The first value found is used. <br>Modifying system-wide configuration requires appropriate permissions and affects all users on the system. <br>Be cautious when manually editing configuration files via <b>--edit</b>, as incorrect syntax can lead to issues.


title: CONFIGURATION FILE LOCATIONS
content:
<b>yadm</b> stores configuration settings in specific files, depending on the scope:<br><i>Local</i>: Stored within the <b>yadm</b> repository, typically at <i>.yadm/config</i> if <b>yadm</b> manages a directory, or at the root of a bare <b>yadm</b> repository. These settings apply only to that specific repository.<br><i>Global</i>: For the current user, located at <i>~/.config/yadm/config</i> or as specified by <i>$XDG_CONFIG_HOME/yadm/config</i>. These settings apply to all <b>yadm</b> repositories managed by the user unless overridden locally.<br><i>System</i>: System-wide settings are usually found in <i>/etc/yadm/config</i>. These apply to all users and all <b>yadm</b> repositories on the system unless overridden by global or local settings.


title: VARIABLE NAMING CONVENTIONS
content:
Configuration variables are typically structured hierarchically using dots ('.') to group related settings, similar to how <b>git</b> organizes its variables. Common categories include <i>core</i> for fundamental settings (e.g., <i>core.editor</i>), <i>remote</i> for remote repository configurations (e.g., <i>remote.origin.url</i>), and <i>yadm</i> for <b>yadm</b>-specific functionalities (e.g., <i>yadm.encryptionMethod</i>).


title: HISTORY
content:
<b>yadm</b> was developed by Michael Smoler as a robust tool for managing dotfiles, designed to overcome limitations of traditional methods like symlinks or bare Git repositories. The <b>yadm config</b> subcommand was an integral part of its initial design, closely mirroring <b>git config</b>'s functionality. This design choice provided a familiar and powerful mechanism for users to customize <b>yadm</b>'s behavior, particularly concerning encryption settings, hooks, and repository-specific options, contributing significantly to <b>yadm</b>'s flexibility and user-friendliness from its early stages.


title: PARAMETERS
content:
<b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrite existing decrypted files without prompting for confirmation. This can be useful for automated scripts or when you are certain you want to replace any current plain-text versions.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity, providing more detailed output about the decryption process, such as which files are being decrypted and messages from the underlying encryption backend.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypt all files that are currently marked as encrypted within the <i>yadm</i> repository. This option overrides any specific <i>PATH</i> arguments and ensures all sensitive files are brought into their plain-text state.<br><br><b>[PATH...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional. Specifies one or more paths to files or directories that <i>yadm</i> should attempt to decrypt. If no paths are provided, <i>yadm-decrypt</i> typically acts on files that are known to be encrypted within the current repository state, or all if <i>--all</i> is used.<br><br>


title: DESCRIPTION
content:
<i>yadm-decrypt</i> is a core subcommand of <i>yadm</i>, the powerful dotfiles manager, designed to reverse the encryption applied by <i>yadm-encrypt</i>. It provides a seamless way to access sensitive dotfiles and configurations that are stored in an encrypted state within your <i>yadm</i> repository.<br><br>Upon execution, <i>yadm-decrypt</i> intelligently identifies files previously marked for encryption and utilizes the configured backend &ndash; typically <b>git-crypt</b> or <b>gpg</b> &ndash; to transform their cipher-text back into plain-text content within your working directory. This ensures that while your sensitive information remains secure in version control, it is readily available when needed for your system's operation. The command supports selective decryption of specific files by path, or bulk decryption of all encrypted files, making it a flexible tool for maintaining a secure yet functional dotfile setup. Its integration is vital for managing secrets like API keys or private configurations within a publicly accessible or shared repository.


title: CAVEATS
content:
<b>Decryption Key/Passphrase:</b> For decryption to succeed, the correct decryption key or passphrase must be accessible to the configured encryption backend (either <i>git-crypt</i> or <i>gpg</i>). Without it, files cannot be decrypted.<br><br><b>Backend Installation:</b> The chosen encryption backend must be correctly installed and configured on the system. If the backend is missing or misconfigured, <i>yadm-decrypt</i> will fail.<br><br><b>File State:</b> <i>yadm-decrypt</i> operates only on files that <i>yadm</i> recognizes as encrypted. It cannot decrypt arbitrary files that were not encrypted via <i>yadm</i>.<br><br><b>Security Considerations:</b> While <i>yadm</i> facilitates encryption, the ultimate security relies on the robustness of the underlying backend and the protection of your decryption keys/passphrases.


title: ENCRYPTION BACKEND
content:
<i>yadm</i> supports different encryption backends, primarily <i>git-crypt</i> and <i>gpg</i>. The specific backend used for encryption and decryption is configured via the <i>yadm</i> configuration, typically set using <i>yadm config local.encryption.program</i>. <i>yadm-decrypt</i> automatically detects and uses the appropriate backend for the files it's processing.


title: PATH RESOLUTION
content:
When specific <i>PATH</i> arguments are provided, <i>yadm-decrypt</i> interprets these paths relative to the root of your <i>yadm</i> repository. This allows for precise control over which encrypted files are targeted for decryption.


title: HISTORY
content:
<i>yadm</i> (Yet Another Dotfiles Manager) was developed to provide a robust, Git-based solution for managing dotfiles, aiming to overcome limitations of simpler methods like bare Git repositories. The inclusion of encryption capabilities, accessible via commands like <i>yadm-encrypt</i> and <i>yadm-decrypt</i>, addressed a critical need for securely storing sensitive configuration data (e.g., API keys, private credentials) alongside public dotfiles.<br><br>This feature leverages established cryptographic tools such as <i>git-crypt</i> and <i>gpg</i>, rather than implementing new encryption algorithms, ensuring strong and tested security. The development focus was on providing a seamless interface within the <i>yadm</i> workflow, allowing users to easily toggle the encrypted state of files without manual interaction with the backend tools. This integration has been a key factor in <i>yadm</i>'s popularity for securely managing complex dotfile environments.


title: SYNOPSIS
content:
<b>yadm encrypt</b> [<i>options</i>] [-- <I>files</I>...]<br><b>yadm encrypt</b> --status<br><b>yadm encrypt</b> --rekey


title: PARAMETERS
content:
<b>--status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the encryption status of tracked files, indicating which files are encrypted and which are not.<br><br><b>--rekey</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Re-encrypts all files currently marked for encryption using the current encryption key or configuration. This is useful after key rotation or changes to encryption settings.<br><br><b><files>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more files or directories to mark for encryption. If no files are specified, <i>yadm encrypt</i> operates on the configured encryption manifest (e.g., <i>.yadm/encrypt</i>).<br><br><b>--remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts and removes the encryption designation for the specified files. The files will no longer be stored encrypted in the repository.<br><br><b>--gpg-recipient <id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the GPG recipient ID to use when <i>gpg</i> is configured as the encryption backend. This ensures files are encrypted for the specified key.<br><br><b>--gpg-homedir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative GPG home directory for the encryption process, overriding the default.<br><br><b>--git-crypt-path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>git-crypt</i> executable if it's not found in the system's PATH.<br><br>


title: DESCRIPTION
content:
<i>yadm encrypt</i> is a crucial subcommand of the <I>yadm</I> (Yet Another Dotfiles Manager) tool, designed to secure sensitive information within your dotfiles repository. It allows you to designate specific files or directories to be encrypted, ensuring that their content is stored in an encrypted format within your Git repository and decrypted only upon checkout or access on a trusted machine.<br><br>This feature is paramount for managing configuration files that might contain API keys, passwords, or other confidential data without exposing them in plain text, especially when your dotfiles repository is public or shared. <i>yadm encrypt</i> typically leverages external tools like <i>git-crypt</i> or <i>GnuPG</i> (GPG) for the actual encryption and decryption process, integrating seamlessly into the <i>yadm</i> workflow. Users must configure the encryption backend and associated keys before effectively utilizing this command.


title: CAVEATS
content:
Using <i>yadm encrypt</i> requires an external encryption tool (e.g., <i>git-crypt</i> or <i>gpg</i>) to be installed and properly configured within <i>yadm</i> via <i>yadm config local.encryption.program</i>.<br><br>Sensitive content should be encrypted <I>before</I> being added to the Git repository. If content is accidentally added unencrypted, it will remain in Git history unless history rewriting is performed.<br><br>Key and passphrase management for the chosen encryption backend is outside <i>yadm</i>'s scope and must be handled securely by the user.


title: ENCRYPTION BACKEND CONFIGURATION
content:
Before using <i>yadm encrypt</i>, you must configure the encryption program by setting <i>local.encryption.program</i> (e.g., to '<i>git-crypt</i>' or '<i>gpg</i>') using <i>yadm config</i>. Additional arguments for the chosen program can be set via <i>local.encryption.args</i>, and the encryption manifest file path can be configured with <i>local.encrypt.file</i>.


title: THE ENCRYPTION MANIFEST FILE
content:
<i>yadm encrypt</i> typically uses a manifest file (by default <i>.yadm/encrypt</i>) to track which files or patterns are designated for encryption. This file behaves similarly to <i>.gitignore</i> but specifies files to be encrypted rather than ignored. You add patterns or file paths to this manifest to control what <i>yadm</i> encrypts.


title: HISTORY
content:
The encryption feature within <i>yadm</i> was introduced to address the critical need for securely managing sensitive data within dotfiles. Instead of reinventing cryptographic wheels, <i>yadm</i> was designed to integrate with robust, established encryption solutions like <i>git-crypt</i> and <i>GnuPG</i>. This approach allows <i>yadm</i> to focus on its core strength of dotfile management while providing a flexible and powerful mechanism for data protection, making it suitable for publicly shared dotfiles repositories.


title: PARAMETERS
content:
<b><i>yadm-options</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional global <i>yadm</i> options that affect the execution, such as <code>--repo &lt;path&gt;</code> to specify an alternate yadm repository, or <code>--config-file &lt;path&gt;</code> for an alternate configuration file. These options must precede the 'enter' subcommand.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A standard convention used to signify the end of command options and the beginning of positional arguments. This is useful if the <i>command</i> itself starts with a hyphen.<br><br><b><i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command to be executed within the yadm repository's context. If no <i>command</i> is specified, <i>yadm-enter</i> will drop into an interactive shell (e.g., <b>bash</b> or <b>sh</b>) inside the repository.<br><br><b><i>arg ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Arguments to be passed to the <i>command</i> being executed.<br><br>


title: DESCRIPTION
content:
<i>yadm-enter</i> is a powerful subcommand of <b>yadm</b> (Yet Another Dotfiles Manager) designed to execute a command or an interactive shell directly within the context of the currently managed yadm repository. This means that the specified command will run as if your current working directory was the internal Git repository that yadm uses to store your dotfiles (typically located at ~/.yadm/repo.d).<br><br>This functionality is crucial for advanced users who need to interact directly with yadm's underlying Git repository without manually navigating to it. It allows for operations like inspecting Git history of your dotfiles, performing complex Git manipulations, or running scripts that rely on being executed within the dotfiles repository. By providing this isolated environment, <i>yadm-enter</i> ensures that any Git commands or other operations are applied to your yadm-managed dotfiles, preventing accidental modifications to other Git repositories you might be working with.


title: CAVEATS
content:
Commands executed via <i>yadm-enter</i> operate on the internal <b>yadm</b> Git repository (typically ~/.yadm/repo.d), not necessarily on any other Git repository you might be in at the time of execution. Be mindful of this context shift to avoid unintended operations on unrelated repositories. When no command is provided, an interactive subshell is spawned, and you must explicitly <code>exit</code> it to return to your original shell environment.


title: USAGE EXAMPLES
content:
To inspect the Git status of your dotfiles: <br><i>yadm enter git status</i><br><br>To view the Git log of your dotfiles repository: <br><i>yadm enter git log --oneline</i><br><br>To enter an interactive shell within the yadm repository context: <br><i>yadm enter</i><br><br>To run a custom script located within your yadm-managed dotfiles: <br><i>yadm enter bash ./my_dotfiles_script.sh</i>


title: HISTORY
content:
The <i>enter</i> subcommand has been a fundamental part of <b>yadm</b> since its early development. It serves as a crucial utility for direct interaction with yadm's underlying Git repository, reflecting yadm's design philosophy of being a thin wrapper around Git. Its functionality has remained consistent, primarily facilitating advanced Git operations or debugging within the dotfiles management context.


title: SYNOPSIS
content:
While "<I>yadm-git-crypt</I>" is typically a conceptual integration rather than a standalone command, interaction occurs by executing <I>git-crypt</I> subcommands within the <I>yadm</I> repository. The general form is to navigate to your <I>yadm</I> repository root and then execute <I>git-crypt</I> commands, or use <I>yadm</I>'s pass-through functionality.<br><br><B>yadm git crypt &lt;subcommand&gt; [options]</B><br><I>Or, more directly, by operating within your yadm repository:</I><br><B>cd "$(yadm root)" && git crypt &lt;subcommand&gt; [options]</B>


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes <I>git-crypt</I> for the current repository. This must be done once per repository to set up the encryption key.<br><br><b>add-gpg-user <key-id></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a GPG key to the list of authorized decryptors for the repository. This allows users with the specified GPG key to decrypt the files.<br><br><b>unlock [key-path]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decrypts files in the working directory using the primary key or a specified key file. Usually, it's automatically handled if you have the GPG key.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the encryption status of files in the repository, indicating which files are configured for encryption and their current state (encrypted/decrypted).<br><br><b>export-key <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports the symmetric encryption key of the repository to a file. Useful for backing up the key or sharing it securely.<br><br><b>help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <I>git-crypt</I> or a specific subcommand.<br><br>


title: DESCRIPTION
content:
The concept of "<I>yadm-git-crypt</I>" refers to the powerful integration of <I>yadm</I> (Yet Another Dotfiles Manager) with <I>git-crypt</I>, a tool designed for transparent encryption of files within a Git repository. <I>Yadm</I> leverages Git to manage your dotfiles, making it easy to synchronize configurations across multiple machines. However, dotfiles often contain sensitive information like API keys, SSH private keys, or personal tokens that should not be exposed in a public Git repository. <I>Git-crypt</I> addresses this by allowing you to encrypt specific files or patterns of files within your Git repository, decrypting them automatically when you <I>git pull</I> and encrypting them again on <I>git push</I>.<br><br>When used together, <I>yadm-git-crypt</I> enables users to securely store and synchronize sensitive dotfiles. This means you can keep your dotfiles repository public on platforms like GitHub, while ensuring that confidential data remains encrypted. The integration is typically achieved by initializing <I>git-crypt</I> within your <I>yadm</I>-managed repository and configuring a <I>.gitattributes</I> file to specify which files or directories need to be encrypted. Subsequent operations like <I>yadm pull</I> or <I>yadm push</I> will then handle the encryption/decryption transparently, provided the necessary decryption keys are available on the system. This setup offers a robust solution for managing sensitive configuration data while maintaining the convenience of version control.


title: CAVEATS
content:
<B>Dependency Requirement:</B> Both <I>yadm</I> and <I>git-crypt</I> must be installed and properly configured on the system for this integration to function.<br><B>Key Management:</B> The security of your encrypted dotfiles heavily relies on the secure management of your GPG keys (or other chosen decryption methods). Loss of keys means permanent loss of access to encrypted data.<br><B>.gitattributes Configuration:</B> Incorrectly configured <I>.gitattributes</I> files can lead to sensitive files being committed unencrypted, or important files being encrypted and becoming inaccessible if keys are lost.<br><B>Complexity:</B> Integrating and managing <I>git-crypt</I> adds a layer of complexity to dotfile management, especially for new users.


title: CONFIGURATION VIA .GITATTRIBUTES
content:
For <I>git-crypt</I> to work correctly within your <I>yadm</I> repository, you must specify which files or patterns should be encrypted. This is done by adding entries to a <B>.gitattributes</B> file at the root of your <I>yadm</I> repository. For example, to encrypt a file named <I>secrets.txt</I> and all files within a <I>keys/</I> directory, you would add the following lines:<br><br><B>secrets.txt filter=git-crypt diff=git-crypt</B><br><B>keys/** filter=git-crypt diff=git-crypt</B><br><br>Commit this <B>.gitattributes</B> file to your repository <I>before</I> adding or modifying the files you intend to encrypt. This ensures Git tracks the files as encrypted from the start.


title: TYPICAL SETUP WORKFLOW
content:
A common workflow for setting up <I>yadm-git-crypt</I> involves:<br><br>1. <B>Initialize yadm:</B> If you haven't already, set up your dotfiles with <I>yadm</I> (e.g., <B>yadm init</B>).<br>2. <B>Initialize git-crypt:</B> Navigate to your <I>yadm</I> repository root (<B>cd "$(yadm root)"</B>) and run <B>git crypt init</B>.<br>3. <B>Add GPG User:</B> Add your GPG key(s) to allow decryption: <B>git crypt add-gpg-user &lt;your-gpg-key-id&gt;</B>.<br>4. <B>Configure .gitattributes:</B> Create or edit <B>.gitattributes</B> in your <I>yadm</I> root to mark sensitive files for encryption (e.g., <B>private_key.txt filter=git-crypt diff=git-crypt</B>). Make sure to add and commit this file <I>before</I> adding the sensitive files themselves.<br>5. <B>Add Sensitive Files:</B> Add your sensitive files to <I>yadm</I> (e.g., <B>yadm add private_key.txt</B>). They will be automatically encrypted when committed and pushed.<br>6. <B>Push to Remote:</B> <B>yadm push</B> will push the encrypted files to your remote repository.


title: HISTORY
content:
The concept of encrypting sensitive files within version control systems predates both <I>yadm</I> and <I>git-crypt</I>. <I>Git-crypt</I> was created by Andrew Ayer to provide transparent encryption for Git repositories, gaining popularity for its ease of use compared to manual encryption or external tools. <I>Yadm</I> (Yet Another Dotfiles Manager) emerged as a robust tool for managing dotfiles using Git, offering features like alternate files and templates. The integration of <I>git-crypt</I> with <I>yadm</I> is a natural evolution driven by user needs to securely manage sensitive configuration data (like API tokens or SSH keys) within publicly shared dotfiles repositories. While no specific "yadm-git-crypt" project exists as a distinct entity, the pattern of using these two tools in conjunction has become a standard best practice for secure dotfile management.


title: SEE ALSO
content:
<I>yadm(1)</I>: Yet Another Dotfiles Manager, the core tool for managing dotfiles., <I>git-crypt</I>: A transparent file encryption tool for Git repositories., <I>git(1)</I>: The distributed version control system that both <I>yadm</I> and <I>git-crypt</I> rely upon., <I>gpg(1)</I>: GNU Privacy Guard, often used by <I>git-crypt</I> for managing access to encrypted data.


title: PARAMETERS
content:
<b><I>options</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;All arguments and options provided to <b>yadm gitconfig</b> are passed directly to the standard <I>git config</I> command. These include options to specify the configuration level (e.g., --local, --global, --system, --file &lt;file&gt;), actions to perform (e.g., --get, --add, --unset, --list, --edit), and key-value pairs to set or modify configuration entries.<br><br><b>--local</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the local Git configuration file of the <I>yadm</I> repository. This is the default behavior if no scope option is provided.<br><br><b>--global</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the global Git configuration file (`~/.gitconfig` or equivalent). Note that this affects your entire Git installation, not just <I>yadm</I>'s behavior.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on the system-wide Git configuration file. This affects all users and repositories on the system.<br><br><b>--add <I>key</I> <I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new line to the option (allows multiple values for a single key).<br><br><b>--get <I>key</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Get the value for a given configuration key.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all variables set in the configuration file.<br><br><b>--edit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open an editor to manually edit the configuration file.<br><br>


title: DESCRIPTION
content:
The <b>yadm-gitconfig</b> command is a specialized subcommand within the <I>yadm</I> (Yet Another Dotfiles Manager) utility. Its primary function is to invoke the standard Git <I>git config</I> command directly within the context of the <I>yadm</I> repository. This means any configuration changes made using <I>yadm gitconfig</I> will apply specifically to how <I>yadm</I>'s underlying Git repository operates, rather than affecting your global or system-wide Git configuration by default. <br><br>Users can leverage this command to set Git-specific options relevant to their dotfile management, such as `user.name`, `user.email`, `core.editor`, or `diff.tool`, ensuring that <I>yadm</I>'s Git operations are tailored to their preferences. It acts as a convenient wrapper, passing all provided arguments directly to <I>git config</I>, thereby providing full access to its extensive capabilities without needing to manually navigate into <I>yadm</I>'s internal Git directory.


title: CAVEATS
content:
When using <b>yadm gitconfig</b>, be mindful of the scope of your changes. By default, it operates on the <I>yadm</I> repository's local Git configuration. If you intend to modify your user's global Git configuration or system-wide settings, you must explicitly use the `--global` or `--system` options, respectively. Changes made with `--global` or `--system` will affect all Git operations on your system, not just those performed by <I>yadm</I>. Understanding the nuances of <I>git config</I> and its different configuration levels is crucial to avoid unintended side effects.


title: CONFIGURATION SCOPE
content:
By default, <b>yadm gitconfig</b> operates on the 'local' configuration of <I>yadm</I>'s internal Git repository. This means settings changed here are specific to how <I>yadm</I> interacts with its own version-controlled dotfiles. However, by explicitly passing `--global` or `--system` options, you can direct <b>yadm gitconfig</b> to modify your user's global Git configuration file (e.g., `~/.gitconfig`) or the system-wide Git configuration file, respectively. These latter options will affect <I>all</I> Git repositories and operations on your system, not just those managed by <I>yadm</I>.


title: BEHIND THE SCENES
content:
Functionally, <b>yadm gitconfig</b> executes the <I>git config</I> command after changing the current working directory to <I>yadm</I>'s internal Git repository. This ensures that any Git configuration operations (like setting `user.name` or `core.editor`) are performed on the `.git/config` file within <I>yadm</I>'s managed repository, unless a different scope (global or system) is specified.


title: HISTORY
content:
The <I>yadm</I> project, created by John Goerzen, emerged as a robust solution for managing dotfiles using Git's powerful version control capabilities. Given <I>yadm</I>'s deep reliance on Git for its core functionality (cloning, tracking, committing changes), providing direct access to Git commands within the <I>yadm</I> context was a natural and necessary design choice. The <b>yadm-gitconfig</b> command was integrated early in <I>yadm</I>'s development to empower users to fine-tune the Git repository <I>yadm</I> manages, ensuring that the underlying Git operations align perfectly with their workflow and preferences.


title: PARAMETERS
content:
<b><b>-b</b>, <b>--bare</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes the yadm repository as a bare repository. This implies using the 'git' and 'yadm' templates, suitable for direct cloning to a new machine.<br><br><b><b>-t</b> <i>&lt;name&gt;</i>, <b>--template</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a specified template during initialization. Templates can configure Git settings, add hooks, or include common yadm files. This option can be used multiple times.<br><br><b><b>--no-template</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents any default or specified templates from being applied during initialization. The repository will be created with minimal default configuration.<br><br><b><b>--git-config-template</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a specific Git configuration template. This is useful for pre-configuring Git settings within the yadm repository (e.g., user name, email).<br><br><b><b>--git-options</b> <i>&lt;options&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes additional options directly to the underlying 'git init' command that yadm invokes. This allows for fine-grained control over the Git repository creation.<br><br><b>[<i>directory</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where the yadm repository should be initialized. If omitted, the current working directory is used.<br><br>


title: DESCRIPTION
content:
<b>yadm-init</b> is the foundational command for setting up your dotfile management with <I>yadm</I> (Yet Another Dotfiles Manager). When executed, it transforms the current directory, or a specified directory, into a dedicated <I>yadm</I> repository. <br><br>At its core, <b>yadm-init</b> creates a hidden <I>.yadm</I> directory, which is itself a Git repository. This allows <I>yadm</I> to leverage Git's powerful version control capabilities to track, manage, and synchronize your configuration files (dotfiles) across multiple machines. Unlike traditional Git repositories that manage code within the project directory, <I>yadm</I> uses a bare Git repository approach behind the scenes to manage files in your home directory or any other specified location, making it ideal for dotfiles.<br><br>The initialization process can be customized using various options, such as applying templates for common Git configurations or <I>yadm</I>-specific settings, or specifying a directory where the repository should be created. After initialization, you would typically use <b>yadm add</b> to start tracking your dotfiles, followed by <b>yadm commit</b> to save their state, and <b>yadm remote add</b> to link your local repository to a remote version control service like GitHub.


title: CAVEATS
content:
<b>yadm init</b> creates the <I>.yadm</I> directory, which is a Git repository, but it does <I>not</I> automatically add or track any of your existing dotfiles. You must explicitly use <b>yadm add</b> for each file or directory you wish to manage. <br><br>While <I>yadm</I> uses Git, directly manipulating the <I>.yadm</I> directory with standard Git commands is generally discouraged; always prefer using the <b>yadm</b> wrapper commands for consistency and to avoid unexpected behavior. Be mindful when using templates, as they can alter the initial state and behavior of your repository.


title: THE .YADM DIRECTORY
content:
When <b>yadm init</b> is run, it creates a hidden <b>.yadm</b> directory (or a specified directory) which acts as a bare Git repository. This directory stores all the version control information for your dotfiles, including commit history, branches, remotes, and configurations specific to yadm.


title: TEMPLATES
content:
<I>yadm</I> templates are pre-defined sets of files or configurations that can be applied during initialization. They are useful for setting up common Git configurations, Git hooks, or initial directory structures within your yadm repository. Custom templates can also be created for specific workflows.


title: HISTORY
content:
<I>yadm</I> (Yet Another Dotfiles Manager) was created by Kyle Spearin (<I>TheLocehili</I>) as a robust and flexible solution for managing dotfiles using Git, addressing some limitations and complexities of other dotfile management approaches. The <b>yadm-init</b> command is fundamental to <I>yadm</I>'s design, being the very first step in setting up a dotfile repository. It has been a core part of <I>yadm</I> since its early development, evolving with features like templating and advanced configuration options to cater to diverse user needs and scenarios for managing sensitive and configuration files.


title: SYNOPSIS
content:
<b>yadm introspect</b> [<I>detail</I>] [<I>option</I>...]<br><br>Examples:<br><b>yadm introspect</b> --all<br><b>yadm introspect</b> --format json --repo-path<br><b>yadm introspect</b> version


title: PARAMETERS
content:
<b><b>--format &lt;format&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format, such as `text` or `json`. When `json` is used, the output is structured for programmatic parsing.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available introspection details about the yadm repository.<br><br><b><b>--config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the effective yadm configuration, including both global and repository-specific settings.<br><br><b><b>--path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the paths of all files currently managed by yadm.<br><br><b><b>--template</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the paths of files configured as yadm templates.<br><br><b><b>--alt</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the paths of yadm alternative files, which are managed but not directly linked.<br><br><b><b>--ignore</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows patterns that yadm is configured to ignore when managing files.<br><br><b><b>--bootstrap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the configured bootstrap commands, if any, that yadm runs on initialization.<br><br><b><b>--repo-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the absolute path to the yadm Git repository.<br><br><b><b>--repo-name</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the name of the yadm repository, typically the last component of the repository path.<br><br><b><b>--home-path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the absolute path to the home directory where yadm manages dotfiles.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed yadm version information.<br><br><b><b>--shell-config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows shell-specific configuration details relevant to yadm's operation.<br><br><b><b>--state &lt;state&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides specific details about a particular yadm state, for example, `encrypted` to check encryption status.<br><br>


title: DESCRIPTION
content:
The `yadm-introspect` command, typically invoked as `<b>yadm introspect</b>`, serves as a powerful diagnostic tool for examining the internal state and configuration of a yadm repository. It allows users to retrieve various pieces of information, such as the repository's absolute path, the user's home directory where dotfiles are managed, the current encryption status, details of the Git configuration used by yadm, and paths to managed files, templates, or alternative files. This command is <I>exceptionally useful for debugging</I> yadm setups, understanding precisely how yadm is configured on a system, or programmatically retrieving information for scripting purposes. It provides insight into yadm's operational parameters without directly modifying them, helping to confirm crucial paths, settings, and other details that influence how yadm manages your dotfiles.


title: CAVEATS
content:
The accuracy and completeness of the output depend on the current state of the yadm repository and the options used.<br>When querying encrypted state, full details might only be available if the repository is currently decrypted.<br>This command requires an initialized yadm repository to provide meaningful introspection results.


title: PROGRAMMATIC USE
content:
By utilizing the `<b>--format json</b>` option, `yadm introspect` transforms into a powerful tool for <I>scripting and automation</I>. This allows external applications or scripts to reliably query yadm's operational parameters and repository state without needing to parse human-readable output, making it ideal for integration into larger system configuration workflows.


title: DEBUGGING AND VERIFICATION
content:
This command is an <I>indispensable debugging aid</I>. It allows users to quickly verify paths, confirm configuration settings, and check the status of features like encryption or template application. It helps ensure that yadm is operating as expected and can pinpoint misconfigurations or unexpected states within the dotfiles repository.


title: HISTORY
content:
`yadm-introspect` emerged as a dedicated subcommand within the <I>yadm</I> (Yet Another Dotfiles Manager) project to centralize and standardize the retrieval of repository information. As yadm's feature set expanded to include encryption, templates, and alternative files, the need for a robust way to query its internal state became apparent. Its development is intertwined with the overall evolution of yadm, aiming to enhance debuggability and facilitate programmatic interaction with yadm's managed dotfiles.


title: PARAMETERS
content:
<b><b>-l</b>, <b>--literal</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the literal path of the file as it exists within the <b>yadm</b> repository, including the repository's internal structure (e.g., `~/.local/share/yadm/repo.git`).<br><br><b><b>-t</b>, <b>--tracked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays files that are currently tracked by <b>yadm</b>, meaning they are committed to the <b>yadm</b> Git repository. This is the default behavior if no other file type option (<b>-u</b>, <b>-i</b>, <b>-s</b>) is specified.<br><br><b><b>-u</b>, <b>--untracked</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists files that exist in the <b>yadm</b>-managed home directory but are not yet tracked by <b>yadm</b> (i.e., not added to the repository).<br><br><b><b>-i</b>, <b>--ignored</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows untracked files that are explicitly ignored by <b>yadm</b>, typically through rules defined in `.yadmignore` or `~/.config/yadm/ignore`.<br><br><b><b>-s</b>, <b>--staged</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays untracked files that have been staged for addition to the <b>yadm</b> repository, but not yet committed.<br><br><b><b>-f</b> <i>&lt;file&gt;</i>, <b>--file=</b><i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads file patterns from the specified <i>&lt;file&gt;</i>. Each line in the <i>&lt;file&gt;</i> is treated as a pattern to filter the list of files.<br><br><b><i>pathspec...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths or patterns that limit the output to files matching the provided specifications. This allows for filtering the list to specific directories or file names.<br><br>


title: DESCRIPTION
content:
<b>yadm-list</b> is a subcommand of the <b>yadm</b> (Yet Another Dotfiles Manager) utility, specifically designed to provide an insightful overview of the files under its management. This command allows users to efficiently inspect which configuration files (dotfiles) are currently tracked within the <b>yadm</b> Git repository, and also to identify untracked files present in the <b>yadm</b>-managed home directory that could potentially be brought under <b>yadm</b>'s control. It serves as a vital tool for maintaining an organized and up-to-date dotfile setup, assisting users in discovering files that may need to be added to the repository or those that are unintentionally ignored.<br><br>The command offers various filtering options, enabling users to tailor the output to their specific needs, such as showing only tracked files, only untracked files, or specific categories of untracked files (e.g., ignored or staged). This functionality provides a quick and comprehensive way to audit the state of your dotfiles managed by <b>yadm</b> without requiring direct interaction with complex Git commands. It significantly enhances transparency and control over your personal configuration files.


title: CAVEATS
content:
Using <b>yadm-list</b> requires <b>yadm</b> to be installed and an active <b>yadm</b> repository initialized in your home directory. The output reflects the state of the <b>yadm</b> repository and its interaction with files in your home directory, and does not perform any modifications.


title: DEFAULT BEHAVIOR
content:
When no options (such as <b>-t</b>, <b>-u</b>, <b>-i</b>, or <b>-s</b>) are provided, <b>yadm list</b> defaults to displaying only the tracked files within your <b>yadm</b> repository.


title: INTERNAL GIT INTERACTION
content:
While <b>yadm-list</b> provides a simplified interface, it internally leverages Git commands, making its functionality conceptually similar to aspects of <b>git ls-files</b> but specifically tailored for dotfile management.


title: HISTORY
content:
The <b>yadm list</b> subcommand has been a fundamental component of <b>yadm</b> (Yet Another Dotfiles Manager) since its early stages. As <b>yadm</b> was developed by Mike Hostetler to simplify dotfile management using Git, the <b>list</b> command was crucial for providing users with visibility into their managed files. Its evolution has focused on offering more granular control and clearer output, reflecting the general refinement of <b>yadm</b> into a robust and user-friendly tool for maintaining configurations across various systems.


title: SYNOPSIS
content:
<b>yadm perms</b> <i>[-f | --fix] [-n | --dry-run] [-v | --verbose] [-q | --quiet] [-L | --no-log-perms] [path...]</i>


title: PARAMETERS
content:
<b><b>-f</b>, <b>--fix</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically fix identified insecure file permissions to more secure defaults.<br><br><b><b>-n</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a dry run. Show what permissions would be changed without actually modifying any files.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity. Display information about files that already have correct permissions, in addition to those with issues.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress output for files with correct permissions, only showing files that require attention or changes.<br><br><b><b>-L</b>, <b>--no-log-perms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--fix</b>, prevents <b>yadm</b> from logging permission changes to its internal Git repository. This is primarily for advanced use cases where permission changes should not trigger Git tracking updates.<br><br><b><i>path...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional: Specify one or more specific paths to check or fix. If omitted, <b>yadm-perms</b> will apply to all files managed by <b>yadm</b> in the current repository.<br><br>


title: DESCRIPTION
content:
The <b>yadm-perms</b> command, typically invoked as <b>yadm perms</b>, is an essential utility for <b>Yadm</b>, the Yet Another Dotfiles Manager. Its primary purpose is to inspect, report on, and optionally correct the file permissions of dotfiles managed by <b>yadm</b>.<br><br>This command is crucial for maintaining the security of sensitive configuration files, such as SSH keys, GnuPG files, or Git configurations, which often contain private information. It helps ensure that these files do not have overly permissive access rights (e.g., world-readable or world-writable) that could compromise system security.<br><br><b>yadm-perms</b> identifies files with permissions that are considered 'too open' based on <b>yadm</b>'s security defaults. It provides options to perform a dry run to see proposed changes or to automatically fix the permissions to more secure levels, typically <b>0600</b> (read/write only by owner) or <b>0644</b> (read/write by owner, read-only by group and others). By automating permission checks and fixes, <b>yadm-perms</b> streamlines the process of keeping your dotfiles secure across various systems.


title: CAVEATS
content:
The <b>yadm-perms</b> command operates on files managed by <b>yadm</b> and requires <b>yadm</b> to be properly installed and initialized. While generally safe, using the <b>--fix</b> option should be done with caution, especially for files where non-standard permissions might be intentionally set. <b>yadm</b>'s default security assumptions might not always align with highly specific use cases, in which case custom permission overrides should be configured within <b>yadm</b>.<br><br>It primarily addresses file permissions and does not manage permissions for directories themselves.


title: PERMISSION ENFORCEMENT LOGIC
content:
By default, <b>yadm-perms</b> considers permissions insecure if they allow write access to group or others (e.g., anything more permissive than <b>0644</b> for regular files or <b>0755</b> for executable files, or specific stricter rules like <b>0600</b> for very sensitive files like SSH keys). This logic is built into <b>yadm</b> to align with common security best practices for configuration files.


title: CUSTOMIZING EXPECTED PERMISSIONS
content:
For specific files where <b>yadm</b>'s default permission expectations do not align with your needs (e.g., a file truly needs world-read access), you can instruct <b>yadm</b> to expect a different mode. This is done via <b>yadm config local.perms.<file_path> <mode></b> (e.g., <b>yadm config local.perms.~/.config/myapp/config 0664</b>). This allows you to bypass warnings or automatic fixes for those specific files without compromising the security checks on others.


title: HISTORY
content:
The <b>perms</b> command was developed as an integral part of the <b>yadm</b> project, created by Mike McQuaid. Its inclusion reflects <b>yadm</b>'s emphasis on providing not just a robust dotfile management solution but also one that prioritizes security. As dotfiles frequently contain sensitive personal and system configurations, the ability to easily check and enforce secure permissions was deemed a critical feature from early in <b>yadm</b>'s development. It addresses a common oversight in manual dotfile management: ensuring appropriate file access rights to prevent unauthorized information disclosure.


title: SYNOPSIS
content:
<b>yadm-transcrypt</b> <I>add</I> <I>path</I> [<I>rule</I>]<br><b>yadm-transcrypt</b> <I>remove</I> <I>path</I> [<I>rule</I>]<br><b>yadm-transcrypt</b> <I>update</I> <I>path</I> [<I>rule</I>]<br><b>yadm-transcrypt</b> <I>show</I> [<I>rule</I>]<br><b>yadm-transcrypt</b> <I>help</I>


title: PARAMETERS
content:
<b><action></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the operation to perform on the transcrypt configuration. Common actions include <i>add</i>, <i>remove</i>, <i>update</i>, <i>show</i>, and <i>help</i>.<br><br><b><path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a file or directory within the yadm repository that the encryption rule applies to. Required for <i>add</i>, <i>remove</i>, and <i>update</i> actions.<br><br><b>[<rule>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional identifier or name for the encryption rule. When specified, it helps to uniquely identify or apply the rule. For <i>show</i>, it filters the displayed rules.<br><br>


title: DESCRIPTION
content:
The `yadm-transcrypt` command is a specialized utility script within the `yadm` (Yet Another Dotfiles Manager) ecosystem. Its primary function is to manage the configuration for <br> `transcrypt`, an external tool that provides transparent encryption and decryption of sensitive files within a Git repository. <br><br>While `yadm` supports multiple encryption backends like `git-crypt` and `age`, `yadm-transcrypt` specifically handles the setup and modification of `transcrypt` rules. These rules are typically stored in a `.yadm/transcrypt.conf` file, which dictates which files or directories should be encrypted or decrypted by `transcrypt` when `yadm encrypt` or `yadm decrypt` commands are executed. <br><br>This utility allows users to add, remove, update, or display these encryption rules, providing fine-grained control over which parts of their dotfiles remain sensitive and protected. Although often invoked indirectly by `yadm` for its encryption features, understanding `yadm-transcrypt` is crucial for advanced `yadm` users who wish to customize their transparent encryption setup using `transcrypt`.


title: CAVEATS
content:
<code>yadm-transcrypt</code> is primarily a helper script used by `yadm` to manage its `transcrypt` integration. Direct invocation is possible but less common than relying on `yadm encrypt` or `yadm decrypt`. <br>It requires the `transcrypt` utility to be installed and configured on your system for `yadm`'s transparent encryption features to function correctly. <br>Misuse of this command can lead to unencrypted sensitive files or issues with decryption.


title: INTEGRATION WITH .YADM/TRANSCRYPT.CONF
content:
The `yadm-transcrypt` utility primarily manipulates the `.yadm/transcrypt.conf` file located within your yadm repository. This file acts as a manifest, listing paths and associated encryption rules (e.g., 'AES256') that `transcrypt` should apply. `yadm` reads this configuration when performing encryption or decryption operations.


title: TRANSPARENT ENCRYPTION WORKFLOW
content:
When `yadm` is configured to use `transcrypt`, files matching rules in `.yadm/transcrypt.conf` are automatically encrypted upon 'git add' and decrypted upon 'git checkout'. This 'transparency' means sensitive data is never stored unencrypted in the Git repository but is readily available in its decrypted form when working on your local machine.


title: HISTORY
content:
`yadm` has supported transparent encryption of sensitive files for a long time, initially relying heavily on `git-crypt`. As part of its continuous development, `yadm` expanded its support to include other encryption backends, one of which is `transcrypt`. The `yadm-transcrypt` helper script was introduced to facilitate the specific configuration and management of `transcrypt` rules within the `yadm` dotfiles repository, providing users with more choice and flexibility in their encryption strategy. Its evolution is tied to `yadm`'s goal of offering robust and adaptable dotfile management.


title: PARAMETERS
content:
<b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output from the command, except for errors.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run with no changes made, showing what would be done.<br><br><b><b>--ff-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refuse to merge unless the fetch can be resolved as a fast-forward. Ensures a linear history.<br><br><b><b>--no-ff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a merge commit even if a fast-forward merge is possible.<br><br><b><b>--rebase</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Rebase the current branch on top of the upstream branch after fetching. This avoids merge commits and keeps a linear history.<br><br><b><b>--autostash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically stash and later unstash local modifications before and after the operation to prevent conflicts.<br><br><b><b>--no-autostash</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable automatic stash/unstash behavior, even if configured.<br><br>


title: DESCRIPTION
content:
<i>yadm-upgrade</i> (often simply invoked as <b>yadm upgrade</b>) is a convenience alias for <b>yadm pull</b>. It automates the process of fetching and integrating changes from the configured remote repository into your local yadm dotfile repository. This command is essential for keeping your dotfiles synchronized across multiple machines or for pulling the latest changes from your central dotfile repository.<br><br>Under the hood, <b>yadm upgrade</b> executes <b>git pull</b>, which typically performs a <b>git fetch</b> followed by a <b>git merge</b> or <b>git rebase</b>, depending on your Git configuration. It's a fundamental operation for maintaining an up-to-date and consistent dotfile setup managed by yadm.


title: CAVEATS
content:
<b>Uncommitted Changes</b>:<br>If you have uncommitted changes in your yadm repository, <b>yadm upgrade</b> might fail or require stashing/committing those changes first, unless <b>--autostash</b> is used or configured.<br><br><b>Merge Conflicts</b>:<br>If the remote changes conflict with your local modifications, <b>yadm upgrade</b> will stop with merge conflicts. You will need to resolve these conflicts manually using <b>git status</b>, <b>git diff</b>, and <b>git add</b> before committing the merge.<br><br><b>Rebase Risks</b>:<br>Using <b>--rebase</b> can rewrite history. Be cautious if you have shared your local yadm repository or pushed branches that others are tracking, as rebasing can cause issues for collaborators.<br><br><b>Network Connectivity</b>:<br>The command requires an active internet connection to communicate with the remote Git repository.


title: BEHIND THE SCENES
content:
The <b>yadm upgrade</b> command essentially executes <b>git pull</b> within your yadm repository (typically located at <i>~/.yadm/repo.git</i> or similar). This means all <b>git pull</b> configurations and hooks apply.


title: CONFIGURATION
content:
The default behavior of <b>yadm upgrade</b> (and <b>git pull</b>) can be configured using Git's configuration system, for example, <b>git config pull.rebase true</b> to always rebase instead of merge, or <b>git config pull.ff only</b> to enforce fast-forward merges.


title: HISTORY
content:
The <i>yadm</i> (Yet Another Dotfiles Manager) project was created to provide a simple yet powerful way to manage dotfiles using Git. The <b>upgrade</b> command was introduced as a convenient alias for <b>yadm pull</b> to simplify the common task of synchronizing dotfiles with a remote repository. This reflects a design philosophy aimed at ease of use for routine operations, abstracting the underlying Git commands while retaining their full power through option pass-through.


title: SEE ALSO
content:
yadm(1), yadm-pull(1), yadm-commit(1), yadm-status(1), git(1), git-pull(1), git-fetch(1), git-merge(1), git-rebase(1)


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b>--hide</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides the Yakuake window if it is currently visible.<br><br><b>--show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the Yakuake window if it is currently hidden.<br><br><b>--toggle</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Toggles the visibility of the Yakuake window (shows if hidden, hides if visible).<br><br><b>--run-command <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <I>command</I> in a new terminal tab within Yakuake.<br><br><b>--profile <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens a new tab using the Konsole profile named <I>name</I>.<br><br><b>--geometry <WxH+X+Y></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial size and position of the Yakuake window. Example: <I>1024x768+0+0</I>.<br><br><b>--fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Yakuake in fullscreen mode.<br><br>


title: DESCRIPTION
content:
Yakuake is a KDE Konsole-based terminal emulator that slides down from the top of your screen with a single key press (default F12), providing instant command-line access. It aims for speed and convenience, eliminating the need to switch windows or launch new terminal instances. Built on Konsole's robust technology, Yakuake offers extensive customization options, including appearance (transparency, size, animation), profiles, and tab management. Its tight integration with the KDE Plasma desktop and support for D-Bus commands make it a powerful tool for both casual users and developers, allowing for scripted interactions and seamless workflow.


title: CAVEATS
content:
Primarily designed for and integrated with the KDE Plasma desktop environment. While it may run on other desktop environments, its full feature set and seamless integration (e.g., global hotkeys, D-Bus commands) are best experienced within KDE Plasma.


title: D-BUS INTERFACE
content:
Yakuake exposes a D-Bus interface, allowing external applications or scripts to control its behavior, such as showing/hiding the window, running commands, or creating new tabs. This enables advanced automation and integration with other system components, making it highly scriptable.


title: CONFIGURATION
content:
Most of Yakuake's extensive configuration options, including keybindings (default F12 for toggle), appearance (e.g., transparency, width, height, animation speed), and default profiles, are accessible through its graphical settings dialog. This dialog is typically found by right-clicking on the Yakuake window or its system tray icon.


title: HISTORY
content:
Yakuake, short for 'Yet Another Kuake' (referencing the 'Quake' game console), was conceived to provide a quick-access terminal for the KDE desktop environment. Inspired by the in-game consoles of popular games like Quake, it brings the convenience of an instantly accessible command line to the desktop. It has been an integral part of the KDE applications suite, leveraging the powerful Konsole terminal engine, and continuously evolved to offer robust customization and D-Bus integration for enhanced usability and scripting.


title: PARAMETERS
content:
<b><b>-p</b>, <b>--primary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the primary selection (often associated with mouse selection) instead of the standard clipboard.<br><br><b><b>-c</b>, <b>--clipboard</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly use the clipboard selection. This is typically the default behavior on X11 and Wayland systems.<br><br><b><b>-s</b> <i><type></i>, <b>--selection</b> <i><type></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the selection type to use: 'primary' or 'clipboard'.<br><br><b><b>-o</b>, <b>--output</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of copying, print the current content of the specified clipboard selection to standard output.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all informational messages, such as 'Copied N bytes to clipboard'.<br><br><b><b>-l</b> <i><N></i>, <b>--line</b> <i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy only the N-th line from the input (1-indexed).<br><br><b><b>-r</b> <i><N-M></i>, <b>--range</b> <i><N-M></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy lines from N to M (inclusive) from the input.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copy the entire input. This is the default action if no specific lines or ranges are provided.<br><br><b><b>-z</b>, <b>--null</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use null characters as input delimiters, useful when piping output from commands like <i>find -print0</i>.<br><br><b><b>--trim-whitespace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove leading and trailing whitespace from each line before copying to the clipboard.<br><br><b><b>--exec-clipboard</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute the content retrieved from the clipboard as a shell command. <i>Use with extreme caution!</i><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 for <i>yank</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>yank</i> is a command-line utility designed to streamline the process of copying text directly from the terminal to the system clipboard. It allows users to pipe the standard output of other commands or specify file content, and then effortlessly make that text available for pasting into other applications, whether they are terminal-based or graphical. The utility supports various copying modes, including copying entire inputs, specific lines, or defined ranges of lines. <i>yank</i> is particularly valuable for developers and system administrators who frequently need to transfer command output, log snippets, or configuration details from the console to other applications without resorting to cumbersome manual mouse selection and copying. It integrates with existing system clipboard utilities like <i>xclip</i> or <i>xsel</i> (for X11) and <i>wl-copy</i> (for Wayland) to perform its core function, enhancing command-line efficiency.


title: CAVEATS
content:
<i>yank</i> is not a standard Linux utility that comes pre-installed with most distributions; it typically needs to be installed separately. Its functionality relies heavily on other underlying clipboard utilities like <i>xclip</i> or <i>xsel</i> (for X11 display servers) or <i>wl-copy</i> and <i>wl-paste</i> (for Wayland compositors). If these dependencies are not met, <i>yank</i> will be unable to interact with the system clipboard. Furthermore, the <b>--exec-clipboard</b> option poses a significant security risk, as it allows arbitrary commands to be executed from text copied into your clipboard, potentially by malicious sources.


title: INSTALLATION
content:
As <i>yank</i> is not a core utility, it must be installed. Users can often find it in community-maintained repositories (e.g., Arch Linux AUR) or install it by compiling from its source code. In some cases, it might also be installable via Python's <i>pip</i> if the necessary system dependencies (like <i>xclip</i>) are already present.


title: BASIC USAGE EXAMPLES
content:
To copy the output of a command to the clipboard:<br><i>ls -l | yank</i><br><br>To copy a specific line from a text file to the clipboard:<br><i>cat /etc/hosts | yank -l 3</i><br><br>To copy a range of lines from piped input:<br><i>seq 1 10 | yank -r 4-6</i><br><br>To paste content from the clipboard to your terminal (standard output):<br><i>yank --output</i>


title: HISTORY
content:
The <i>yank</i> utility, developed by Michael Treanor (mptre), emerged as an open-source project to address a common efficiency gap in command-line environments. While traditional methods of copying terminal output often involve manual mouse selection, this is cumbersome and unscriptable for large or dynamically generated content. <i>yank</i> was designed to provide a simple, pipe-friendly, and programmatic way to transfer text from standard input or files directly to the system clipboard. Its development is part of a broader trend of creating specialized command-line tools that enhance interoperability between the terminal and graphical applications, making text manipulation and transfer more seamless for developers and system administrators.


title: SYNOPSIS
content:
<pre><b>yaourt</b> [options] [package(s)]</pre><br><code>yaourt</code> broadly follows <code>pacman</code>'s syntax for common operations, with additional options for AUR-specific interactions.<br><br><i>Examples:</i><pre><b>yaourt -S</b> <i>package_name</i>           <i># Install a package from official repos or AUR</i>
<b>yaourt -Ss</b> <i>search_term</i>         <i># Search for packages in official repos and AUR</i>
<b>yaourt -Syu --aur</b>              <i># Synchronize official repos and update all installed packages, including AUR ones</i>
<b>yaourt -G</b> <i>package_name</i>           <i># Download a PKGBUILD and associated files for a package</i>
<b>yaourt -Cd</b>                     <i># Clean cached build directories</i></pre>


title: PARAMETERS
content:
<b><b>-S</b>, <b>--sync</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize packages. Used for installing, upgrading, or querying packages from official repositories and AUR.<br><br><b><b>-Sy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize official package databases.<br><br><b><b>-Syu</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronize databases and upgrade all installed packages, including AUR ones if detected.<br><br><b><b>-Ss</b> <i>&lt;term&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Search for packages in official repositories and AUR matching <i>&lt;term&gt;</i>.<br><br><b><b>-Si</b> <i>&lt;pkg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about a package from official repos or AUR.<br><br><b><b>-U</b>, <b>--upgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrade or add local packages.<br><br><b><b>-R</b>, <b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove packages.<br><br><b><b>-Q</b>, <b>--query</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Query the package database.<br><br><b><b>-G</b>, <b>--getpkgbuild</b> <i>&lt;pkg&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download the PKGBUILD and associated files for a package into the current directory.<br><br><b><b>-Cd</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clean orphaned build directories used by yaourt.<br><br><b><b>--devel</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check and update development packages (e.g., -git, -svn packages).<br><br><b><b>--aur</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit operations exclusively to the AUR, e.g., 'yaourt -Ss --aur'.<br><br><b><b>--noconfirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass all confirmation prompts. <br><b><i>Use with extreme caution.</i></b><br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show PKGBUILD and .install file differences before building. <br><i>(Highly recommended security practice)</i>.<br><br>


title: DESCRIPTION
content:
<code>yaourt</code> (Yet AnOther User Repository Tool) was a popular, albeit now deprecated, command-line tool for Arch Linux users that significantly simplified interaction with the Arch User Repository (AUR). It acted as a wrapper around <code>pacman</code>, Arch's native package manager, extending its capabilities to include packages available in the AUR. Its primary function was to automate the process of searching, installing, and updating AUR packages, handling dependencies, and offering a more user-friendly interface compared to manual AUR package compilation.<br><br>While <code>pacman</code> manages official repository packages, <code>yaourt</code> bridged the gap by allowing users to effortlessly install community-maintained software not found in the official repos. It would fetch PKGBUILDs, prompt the user for review, build packages using <code>makepkg</code>, and then install them via <code>pacman</code>. Despite its initial popularity for its convenience and rich feature set, <code>yaourt</code> has fallen out of maintenance and is no longer recommended for use due to security concerns and the emergence of more robust and secure alternatives.


title: CAVEATS
content:
<code>yaourt</code> is officially <b>deprecated and no longer maintained</b>. It has known security vulnerabilities and design flaws that make it unsafe for current use. It is strongly advised that users migrate to actively maintained and more secure AUR helpers like <code>yay</code> or <code>paru</code>. Continued use of <code>yaourt</code> can expose your system to unnecessary risks, including potential privilege escalation if not configured or used correctly, and may lead to system instability due to unmanaged dependencies or outdated package builds.


title: <I><BR>ALTERNATIVES</I>
content:
Given <code>yaourt</code>'s deprecation and security issues, users should switch to modern, actively maintained AUR helpers. The most popular and recommended alternatives are <code>yay</code> and <code>paru</code>. These tools offer similar <code>pacman</code>-like syntax, improved security features (e.g., building in a dedicated, unprivileged directory by default), and are continuously updated to align with <code>pacman</code> and Arch Linux changes.


title: <I><BR>SECURITY BEST PRACTICES</I>
content:
When using any AUR helper, it is paramount to <b>always review the PKGBUILD file</b> before installing a package. This file dictates what commands will be executed on your system during the build process. <code>yaourt</code> (and its successors) provided options like <code>--diff</code> to review these changes. Never install AUR packages from untrusted sources or without reviewing their PKGBUILDs, as malicious scripts could compromise your system. Always run AUR helpers as a regular user, and let <code>makepkg</code> (which runs without root privileges) handle the build, with the final installation step prompted for <code>sudo</code>.


title: HISTORY
content:
<code>yaourt</code> emerged as one of the earliest and most widely adopted AUR helpers for Arch Linux, gaining significant popularity due to its <code>pacman</code>-like syntax and automated handling of AUR package installation, which was a considerable improvement over manual compilation. It filled a crucial gap by simplifying access to the vast Arch User Repository. Its development thrived for several years, making it the de-facto standard AUR helper for many Arch users. <br><br>However, around 2018-2019, its maintenance waned, and security concerns began to surface, particularly regarding its default behavior of building packages in <code>/tmp</code> and its less robust handling of <code>makepkg</code> execution. Concurrently, new, more secure, and actively developed AUR helpers like <code>yay</code> and <code>paru</code> began to emerge, addressing many of <code>yaourt</code>'s shortcomings and offering more sophisticated features. As a result, <code>yaourt</code> was officially deprecated and is no longer recommended or supported by the Arch Linux community.


title: SYNOPSIS
content:
Since YARD is a Ruby gem, its invocation typically follows a subcommand pattern:<br><br><I>yard [global options] &lt;command&gt; [command options]</I><br><br>Common usage examples include:<br><I>yard doc [files...] [options]</I> (Generates documentation)<br><I>yard server [options]</I> (Starts a live documentation server)<br><I>yard stats [options]</I> (Shows documentation statistics)<br><I>yard config [options]</I> (Manages YARD configuration)


title: PARAMETERS
content:
<b><B>Global Options (applicable to any yard command):</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b><I>--help, -h</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message for YARD or a specific command.<br><br><b><I>--version, -v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the YARD version number.<br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output.<br><br><b><I>--profile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables profiling mode to show performance statistics.<br><br><b><I>--gem-home PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the RubyGems installation directory.<br><br><b><B>Common &quot;doc&quot; Command Options:</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br><br><b><I>--output FILE, -o FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output directory for generated documentation. Default is <I>doc/</I>.<br><br><b><I>--template TEMPLATE_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the template to use for rendering documentation (e.g., <I>default</I>, <I>fulldoc</I>).<br><br><b><I>--ext FILE_LIST</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of file extensions to parse as Ruby source.<br><br><b><I>--no-public</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes public methods from documentation.<br><br><b><I>--no-private</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes private methods from documentation.<br><br><b><I>--no-undoc</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes undocumented objects from the generated output.<br><br><b><I>--markup MARKUP_LANG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the markup language for all files (e.g., <I>markdown</I>, <I>rdoc</I>).<br><br>


title: DESCRIPTION
content:
<b>YARD</b> (Yet Another Ruby Documentation) is an advanced tool used primarily by Ruby developers to generate comprehensive API documentation from source code comments and structure. Unlike typical Linux commands, YARD is not a built-in utility; it is a <I>Ruby gem</I> that must be installed via the RubyGems package manager (e.g., <I>gem install yard</I>).<br><br>It parses Ruby code, including classes, modules, methods, and constants, along with specially formatted comments, to produce highly navigable documentation, most commonly in HTML format. YARD supports a rich markup language (including Markdown), custom tags, and a powerful plugin architecture, allowing users to extend its functionality and customize output extensively. It's widely adopted in the Ruby ecosystem for documenting libraries, frameworks, and applications.


title: CAVEATS
content:
YARD is <I>not</I> a standard Linux command or a pre-installed system utility. It is a Ruby-specific tool that requires a Ruby environment and must be installed separately as a gem (<I>gem install yard</I>). Its functionality is primarily relevant to Ruby development projects. Due to its extensive features and subcommand structure, it can have a steep learning curve for advanced customization.


title: CUSTOM TAGS AND PLUGINS
content:
One of YARD's most powerful features is its support for custom documentation tags (e.g., <I>@note</I>, <I>@example</I>, <I>@todo</I>) beyond the standard RDoc/JSDoc set. This allows developers to enrich their documentation with project-specific information. Furthermore, its plugin architecture enables extensive customization and extension of its parsing, processing, and output generation capabilities.


title: LIVE DOCUMENTATION SERVER
content:
The <I>yard server</I> command provides a local web server to view documentation live as you develop, automatically refreshing when changes are detected in your source files. This greatly streamlines the documentation writing and review process.


title: MARKUP LANGUAGE SUPPORT
content:
YARD allows developers to choose their preferred markup language for docstrings, supporting Markdown, RDoc, and other custom formats. This flexibility caters to different team preferences and existing documentation styles.


title: HISTORY
content:
YARD was created by Loren Segal and first released in the late 2000s, gaining popularity as a powerful and flexible alternative to Ruby's then-standard documentation tool, RDoc. It was designed to address limitations in RDoc, particularly around custom tags, extensibility, and better support for complex project structures. Over the years, YARD has evolved into the de-facto standard for documenting Ruby libraries and applications, known for its robust parsing capabilities and highly customizable output.


title: SEE ALSO
content:
Ruby, gem (1) (RubyGems package manager), Bundler (Ruby dependency manager), RDoc (Another Ruby documentation tool)


title: SYNOPSIS
content:
<b>yarn</b> <i>&lt;command&gt;</i> [<i>&lt;options&gt;</i>]<br><b>yarn</b> [<i>&lt;options&gt;</i>] (for default <b>install</b> action)


title: PARAMETERS
content:
<b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs all dependencies defined in the <i>package.json</i> file.<br><br><b>add &lt;package&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds one or more packages to the project dependencies.<br><br><b>remove &lt;package&gt;...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more packages from the project dependencies.<br><br><b>upgrade [&lt;package&gt;...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades packages to their latest compatible version based on version ranges.<br><br><b>run &lt;script&gt; [&lt;args&gt;...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a script defined in the <i>scripts</i> section of <i>package.json</i>.<br><br><b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a new Yarn project, creating a <i>package.json</i> file.<br><br><b>publish [&lt;tarball&gt;|<folder&gt;]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Publishes a package to a registry.<br><br><b>create &lt;starter-kit-package&gt; [&lt;args&gt;...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new project from a starter kit or template.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Yarn configuration settings.<br><br><b>set version &lt;version&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Yarn version for the current project, useful for project-specific Yarn versions.<br><br>


title: DESCRIPTION
content:
<b>Yarn</b> is a fast, reliable, and secure dependency management tool for JavaScript. It acts as a package manager, similar to <b>npm</b>, designed to help developers manage their project's dependencies efficiently.<br><br>Yarn caches downloaded packages, parallelizes operations, and uses checksums to ensure package integrity, leading to significantly faster and more reliable installations. It works with the <b>npm</b> registry and supports features like workspaces for monorepos, Plug'n'Play (PnP) for optimized installations, and deterministic <i>yarn.lock</i> files to ensure consistent builds across different environments. Yarn aims to provide a robust and predictable workflow for front-end and back-end JavaScript development, streamlining the process of adding, removing, updating, and running project scripts.


title: CAVEATS
content:
Requires Node.js to be installed on the system.<br>While compatible with the <b>npm</b> registry, its lockfile format (<i>yarn.lock</i>) is different from <b>npm</b>'s (<i>package-lock.json</i>), leading to potential conflicts if both package managers are used interchangeably on the same project without caution.<br>Yarn has evolved through several major versions (Yarn Classic, Yarn Berry/Modern) with significant differences in how it operates (e.g., PnP, zero-install, workspace support via <b>yarn dlx</b>). Users should be aware of the specific version they are using.


title: WORKSPACES
content:
Yarn workspaces allow developers to manage multiple packages within a single repository (monorepo), simplifying dependency management and cross-package linking. This feature is crucial for large projects composed of several interconnected modules.


title: YARN.LOCK
content:
This file is automatically generated and ensures deterministic installations by recording the exact versions and dependencies of every package installed in a project. It guarantees that anyone running <b>yarn install</b> will get the identical dependency tree.


title: PLUG'N'PLAY (PNP)
content:
Introduced in Yarn 2 (Berry), PnP is an experimental installation strategy that eliminates the <i>node_modules</i> folder. Instead, it generates a single <i>.pnp.cjs</i> file that maps module names to their locations, which can lead to faster startup times and more efficient disk usage.


title: HISTORY
content:
<b>Yarn</b> was developed by Facebook (now Meta) and released in October 2016. Its primary motivation was to address perceived shortcomings in <b>npm</b> at the time, particularly regarding performance, security, and determinism. It quickly gained popularity due to its speed, reliable installations through lockfiles and checksums, and improved offline mode.<br><br>Over the years, Yarn has continued to evolve, with the "Yarn Berry" (v2 and above) series introducing advanced features like Plug'n'Play (PnP), <b>yarn dlx</b>, and enhanced monorepo support, aiming to further optimize dependency management and reduce <i>node_modules</i> footprint.


title: PARAMETERS
content:
<b><I>package_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the package whose installation reason you want to investigate. This can be any package found within your project's dependency tree.<br><br><b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the result in a machine-readable JSON format. This option is particularly useful for scripting and integrating <i>yarn-why</i> into automated workflows or custom tooling.<br><br>


title: DESCRIPTION
content:
The <i>yarn-why</i> command is a powerful utility within the Yarn package manager, designed to help developers understand the dependency relationships within their JavaScript/TypeScript projects. When invoked with a specific package name, it traverses the project's dependency tree to identify and explain <b>why</b> that particular package has been installed. This includes both direct dependencies (explicitly listed in your `package.json`) and transitive dependencies (dependencies of your dependencies).<br><br>It's invaluable for debugging unexpected package installations, resolving version conflicts, identifying duplicate packages, or simply understanding the complex web of interconnected libraries that make up a modern web application. The output provides a clear path from a top-level dependency down to the queried package, making it easier to prune unnecessary dependencies or pinpoint the source of issues.


title: CAVEATS
content:
<b>Important Considerations:</b><br>It requires an existing <i>node_modules</i> directory or a Yarn Plug'n'Play (PnP) setup, along with a <i>yarn.lock</i> file, to accurately trace dependencies. Without these, the command cannot effectively determine the dependency tree.<br>The command's performance can vary on very large projects with extensive dependency trees, potentially taking longer to process.<br>It explains the <i>path</i> to a dependency, but not necessarily the <i>reason</i> a direct dependency was chosen by the project maintainers or application logic.


title: OUTPUT INTERPRETATION
content:
The command's typical output presents a hierarchical view, illustrating the dependency chain that leads to the specified package. It often includes details such as the required version specified by the parent dependency and the actual resolved version, which helps in identifying potential version conflicts or understanding how a specific version was chosen. For example, it might show that <i>your-app</i> requires <i>library-A</i>, and <i>library-A</i> in turn requires <i>target-package</i>, thereby explaining <i>target-package</i>'s presence in your project.


title: COMMON USE CASES
content:
<i>yarn-why</i> is frequently utilized for a variety of tasks, including:<br><b>1.</b> Debugging 'phantom dependencies,' which are packages that seem to be installed but are not explicitly listed as direct dependencies in your `package.json`.<br><b>2.</b> Resolving version conflicts by understanding which parent dependency requires a problematic or incompatible version of a package.<br><b>3.</b> Identifying unused or redundant packages by tracing back their origins and determining if they are still required by any active dependency.<br><b>4.</b> Understanding the full impact of upgrading or removing a dependency, by seeing all the packages that rely on it.


title: HISTORY
content:
Yarn was initially released by Facebook, Google, Exponent, and Tilde in 2016 to address shortcomings in the existing npm client, focusing on speed, reliability, and security. The `why` command was a crucial addition from its inception, providing a much-needed feature for deep dependency introspection that was less readily available or less intuitive in contemporary package managers. It has remained a core utility throughout Yarn's development, including the Yarn Berry (v2+) iterations, evolving to support new dependency management paradigms like Plug'n'Play (PnP) and respecting the `.pnp.cjs` file structure.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints Yazi's version information and exits.<br><br><b><b>-t</b> <I>TYPE</I>, <b>--type</b>=<I>TYPE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific tab type for interaction (e.g., <I>cd</I> to change directory upon exit).<br><br><b><b>-c</b> <I>FILE</I>, <b>--config-file</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the main configuration file.<br><br><b><b>-L</b> <I>FILE</I>, <b>--log-file</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a custom path for Yazi's log output.<br><br><b><b>-P</b> <I>FILE</I>, <b>--plugin-file</b>=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the plugin configuration file.<br><br><b><b>-s</b>, <b>--server</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Yazi in server-only mode, primarily for RPC communication.<br><br><b><b>-W</b>, <b>--wait</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Waits for the Yazi server process to terminate before exiting.<br><br><b>[<I>PATH</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more initial directories for Yazi to open.<br><br>


title: DESCRIPTION
content:
Yazi is a modern, <I>blazing-fast</I> terminal user interface (TUI) file manager written in Rust, designed for efficiency and a highly responsive user experience. It draws inspiration from established TUI file managers like <B>ranger</B> and <B>nnn</B> but differentiates itself with a focus on asynchronous I/O operations, ensuring the user interface remains fluid and interactive even during computationally intensive tasks like large file transfers or extensive directory scanning.<br><br>Key features include rich file preview capabilities (supporting images, videos, text, and more via external integrations), an extensible plugin system written in Rust and Lua, deep customizability through TOML configuration files, and seamless fuzzy searching. Yazi aims to provide a powerful yet intuitive way to navigate, manage, and interact with your filesystem directly from the command line, catering to power users who prioritize speed and keyboard-driven workflows. Its modern design and active development make it a compelling choice for terminal enthusiasts.


title: CAVEATS
content:
Yazi requires a modern terminal emulator for the best experience, especially for proper display of icons and colors, often leveraging <I>Nerd Fonts</I>.<br>While highly performant, certain resource-intensive operations, especially those relying on external previewers, might still have momentary delays.<br>As a relatively new project, its feature set and API might evolve, requiring occasional updates to custom configurations or plugins.


title: ASYNCHRONOUS OPERATIONS
content:
Yazi's core design leverages asynchronous I/O, ensuring that file operations (like copying large files or scanning directories) do not freeze the user interface, providing a consistently smooth experience.


title: EXTENSIBLE PLUGIN SYSTEM
content:
Beyond its core functionality, Yazi supports a powerful plugin system, allowing users to extend its capabilities with custom scripts written in Rust or Lua, enabling deep integration with other tools.


title: RICH FILE PREVIEWS
content:
Yazi offers extensive built-in file preview support for various formats, including images, videos, PDFs, and text, often utilizing external utilities (e.g., <B>ueberzug</B>, <B>chafa</B>, <B>exiftool</B>) for rich visual and textual previews directly within the terminal.


title: CONFIGURATION
content:
The behavior and appearance of Yazi are highly customizable through intuitive TOML-based configuration files, allowing users to tailor keybindings, colors, layouts, and external command integrations to their exact preferences.


title: HISTORY
content:
Yazi was created by Sxyu and introduced to the open-source community, quickly gaining traction for its innovative use of Rust to achieve unparalleled performance in a terminal file manager. Its development emphasizes a modern, asynchronous architecture, setting it apart from traditional tools. Since its initial release, Yazi has undergone continuous active development, with frequent updates introducing new features, optimizations, and community contributions, solidifying its position as a leading choice for terminal-based file management.


title: PARAMETERS
content:
<b>get</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays the current backlight brightness level.</i><br><br><br><b>set <I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the backlight brightness to the specified VALUE. VALUE can be an absolute integer (e.g., 500) or a percentage (e.g., "50%").</i><br><br><br><b>inc <I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Increases the backlight brightness by the specified VALUE. VALUE can be an absolute integer or a percentage (e.g., "10%").</i><br><br><br><b>dec <I>VALUE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Decreases the backlight brightness by the specified VALUE. VALUE can be an absolute integer or a percentage (e.g., "5%").</i><br><br><br><b>--device <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the backlight device to control (e.g., "intel_backlight", "amdgpu_bl0"). If omitted, it often attempts to find the primary or first available device in /sys/class/backlight.</i><br><br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a help message detailing usage and options.</i><br><br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays version information for the utility.</i><br><br><br>


title: DESCRIPTION
content:
<i>ybacklight</i> is a lightweight command-line utility designed for managing display backlight brightness on Linux systems. It typically operates by interacting directly with the <i>/sys/class/backlight</i> filesystem interface, allowing users to query, set, increase, or decrease the screen's illumination level. Unlike some more complex tools, <i>ybacklight</i> aims for simplicity and direct control, often serving as a reliable alternative when other utilities like <i>xbacklight</i> (which depends on Xorg) or <i>brightnessctl</i> (which might have different dependencies) are not available or preferred. It's particularly useful for console environments, server setups, or minimal desktop installations where a simple, direct method for backlight adjustment is desired.


title: CAVEATS
content:
<i>ybacklight</i> typically requires root privileges or appropriate <i>sudoers</i> configuration to write to files within <i>/sys/class/backlight</i>, which are necessary to change brightness settings.<br>It relies on the presence and proper functioning of the <i>/sys/class/backlight</i> interface, which might not be available or fully supported on all hardware or Linux distributions.<br>As <i>ybacklight</i> is often a user-contributed utility and not a standardized package, its exact options and behavior can vary slightly between different implementations found online.


title: PERMISSIONS
content:
To modify backlight settings, <i>ybacklight</i> usually requires write access to the <i>brightness</i> file within a specific backlight device directory (e.g., <i>/sys/class/backlight/intel_backlight/brightness</i>). This commonly necessitates running the command with <b>sudo</b> or configuring <i>udev</i> rules to grant non-root users write permissions to these specific files.


title: DEVICE DISCOVERY
content:
When no device is explicitly specified with <i>--device</i>, <i>ybacklight</i> typically scans the <i>/sys/class/backlight/</i> directory to discover available backlight devices. If multiple devices are present (e.g., integrated display and an external monitor), some versions may default to the first found or require the user to specify the target device manually.


title: HISTORY
content:
<i>ybacklight</i> is typically a user-contributed utility, often developed as a simple C program or shell script. Its emergence addresses the need for a straightforward backlight control method on Linux systems, especially those without Xorg (e.g., server consoles, minimal installs) or where other tools like <i>brightnessctl</i> are not preferred. Its development is often driven by individual system administrators or users seeking a lightweight and direct interface to the kernel's backlight control facilities.


title: PARAMETERS
content:
<b>-force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses certain error checks, attempting to force the conversion even if the input YBM file appears corrupted or non-standard. Use with caution.<br><br><b>-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the header of the input YBM file to standard error. Useful for debugging or understanding the YBM file structure.<br><br>


title: DESCRIPTION
content:
`ybmtopbm` is a specialized command-line utility from the comprehensive Netpbm image manipulation toolkit. Its primary function is to convert image files stored in the Yamaha Oki bitmap (YBM) format, an older and somewhat obscure proprietary bitmap standard, into the widely recognized and simpler Portable Bitmap (PBM) format. <br><br>The PBM format represents monochrome (black and white) images, where each pixel is either black or white. `ybmtopbm` reads the YBM image data from standard input by default, or from a specified file if provided, and then writes the converted PBM image to standard output. <br><br>This filter-like behavior makes `ybmtopbm` highly suitable for integration into Unix-style shell pipelines. Users can chain `ybmtopbm` with other Netpbm tools, such as `pbmtopgm` (to grayscale), `pbmtoppm` (to color), or `pnmtops` (to PostScript), to achieve further format conversions or processing. The utility handles the intricate details of parsing the YBM header and pixel data, translating it into the straightforward PBM structure, thereby enabling interoperability with modern image processing workflows.


title: CAVEATS
content:
The YBM format is relatively obscure, so input files might be rare. <br> `ybmtopbm` strictly produces monochrome PBM output; any color or grayscale information present in the original YBM (if applicable) will be lost during conversion. <br> While the <b>-force</b> option can help with problematic files, it does not guarantee successful conversion of severely corrupted or unknown YBM variants.


title: INPUT AND OUTPUT
content:
Like most Netpbm utilities, `ybmtopbm` functions as a filter. It reads YBM image data from <i>standard input</i> (<I>stdin</I>) unless a filename is explicitly provided as an argument. The resulting PBM image data is then written to <i>standard output</i> (<I>stdout</I>). This design facilitates seamless integration into command-line pipelines for complex image processing workflows.


title: MONOCHROME CONVERSION
content:
It's important to note that `ybmtopbm` exclusively converts to the Portable Bitmap (PBM) format, which is monochrome (black and white). If the source YBM file contained color or grayscale information, this data will be discarded during the conversion process, resulting in a binary (black or white only) image. Further Netpbm tools are needed for conversion to other color or grayscale formats.


title: HISTORY
content:
`ybmtopbm` is an integral part of the Netpbm project, a comprehensive toolkit for manipulating graphic files. Netpbm itself evolved from the `pbmplus` package, which was originally developed by Jef Poskanzer in the late 1980s. <br><br>Specifically, `ybmtopbm` was written by Bryan W. Headley in 1993. Its development was informed by Bryan W. Headley's prior work on `ybm2eps` and insights from Paul Hethmon's `okigen` source code, demonstrating its roots in earlier efforts to handle Yamaha-specific image data. It has since been maintained as part of the official Netpbm distribution.


title: SYNOPSIS
content:
<b>ydotool</b> [<i>OPTIONS</i>] <i>COMMAND</i> [<i>ARGUMENTS...</i>]<br><br><i>Common Command Examples:</i><br><b>ydotool type</b> <i>&lt;text&gt;</i><br><b>ydotool click</b> <i>&lt;button&gt;</i><br><b>ydotool key</b> <i>&lt;key&gt;</i><br><b>ydotool mousemove</b> <i>&lt;x&gt; &lt;y&gt;</i>


title: PARAMETERS
content:
<b>type <i>&lt;text&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate typing a given string of text on the console.<br><br><b>click <i>&lt;button&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate a mouse button click (e.g., 1 for left, 2 for middle, 3 for right).<br><br><b>mousemove <i>&lt;x&gt; &lt;y&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Move the mouse cursor by a specified relative <i>X</i> and <i>Y</i> offset.<br><br><b>mousemove_to <i>&lt;x&gt; &lt;y&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Move the mouse cursor to a specified absolute <i>X</i> and <i>Y</i> position.<br><br><b>keydown <i>&lt;key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate pressing a specific key down without releasing it.<br><br><b>keyup <i>&lt;key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate releasing a specific key previously held down.<br><br><b>key <i>&lt;key&gt;</i> [<i>&lt;delay&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulate pressing and then immediately releasing a specific key, optionally with a delay.<br><br><b>sleep <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pause execution for a specified number of seconds.<br><br><b>exec <i>&lt;command&gt;</i> [<i>&lt;args...&gt;</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute an external command.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the status of the <b>ydotoold</b> daemon.<br><br><b>monitor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitor and display input events from the virtual devices managed by <b>ydotool</b>.<br><br><b>command <i>&lt;raw_command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute raw commands directly via the <b>ydotoold</b> daemon (advanced usage).<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug logging for more verbose output from <b>ydotool</b> and its daemon.<br><br><b>-u, --user <i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a user to run <b>ydotool</b> commands as, typically when the daemon is run as root.<br><br>


title: DESCRIPTION
content:
<b>ydotool</b> is a command-line utility designed for simulating keyboard and mouse input events on the Linux console and framebuffer. Unlike tools such as <b>xdotool</b> which operate within the X Window System, <b>ydotool</b> functions independently of a graphical server, making it ideal for automation in environments like embedded systems, kiosks, or headless servers. It achieves this by interacting with the <b>uinput</b> kernel module, which allows user-space programs to create virtual input devices. Through these virtual devices, <b>ydotool</b> can inject a wide range of input events, including typing text, clicking mouse buttons, moving the cursor, and simulating key presses and releases. For <b>ydotool</b> to operate, the <b>uinput</b> kernel module must be loaded, and the user or its associated daemon (<b>ydotoold</b>) typically requires read/write access to <i>/dev/uinput</i>, often managed via specific udev rules or by running with elevated privileges.


title: CAVEATS
content:
<ul><li>Requires the <b>uinput</b> kernel module to be loaded on the system.</li><li>Demands appropriate permissions to <i>/dev/uinput</i> for <b>ydotool</b> or its daemon (<b>ydotoold</b>) to create virtual devices, often requiring root privileges or specific udev rules.</li><li>Primarily designed for use within the Linux console or framebuffer environment, not directly compatible with X11 or Wayland display servers.</li><li>Can potentially interfere with normal user input if used improperly or maliciously.</li><li>The key names used with <b>key</b>, <b>keydown</b>, <b>keyup</b> commands must correspond to Linux kernel input event codes.</li></ul>


title: THE <B>YDOTOOLD</B> DAEMON
content:
<b>ydotool</b> commands typically communicate with a background daemon process named <b>ydotoold</b>. This daemon is responsible for managing the virtual <b>uinput</b> device creation and actual event injection. Running <b>ydotoold</b>, often as root or via a systemd service with appropriate permissions, allows unprivileged users to send commands to <b>ydotool</b> without needing direct access to <i>/dev/uinput</i> for every single action.


title: PERMISSIONS SETUP
content:
For non-root users to utilize <b>ydotool</b>, it is common practice to set up <b>udev</b> rules. These rules can modify the permissions of the <i>/dev/uinput</i> device node (e.g., setting its group ownership to a dedicated 'uinput' group) and ensure that users belonging to that group have read and write access. This allows <b>ydotoold</b> to start and manage input without requiring root privileges for the client commands.


title: HISTORY
content:
<b>ydotool</b> emerged from the need for a command-line input automation tool in environments where a traditional X Window System (or later Wayland) server is not present or desired. While <b>xdotool</b> served this purpose for graphical desktops, a solution was required for embedded systems, kiosks, and bare-metal Linux console applications. By leveraging the kernel's <b>uinput</b> module, <b>ydotool</b> provides a direct interface to inject events into the kernel's input subsystem, allowing for low-level, server-independent input simulation. Its development addressed this specific gap, providing robust scripting capabilities for non-graphical Linux systems.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows general help options and exits.<br><br><b><b>--help-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all help options, including less common or debugging ones.<br><br><b><b>--help-gst</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows GStreamer-specific options, typically used for multimedia documentation.<br><br><b><b>--display=</b><i>DISPLAY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use for the graphical interface, useful in multi-display or remote X setups.<br><br><b><b>-s</b>, <b>--search=</b><i>TEXT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates a search for the specified <i>TEXT</i> within the loaded or default documentation.<br><br><b><b>-u</b>, <b>--uri=</b><i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the specified Uniform Resource Identifier (<i>URI</i>). This option is officially deprecated but still functional. It is recommended to pass URIs directly as arguments without the <b>-u</b> flag for newer usage.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <i>yelp</i> and exits.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more verbose output to the console for troubleshooting and development purposes.<br><br><b><i>URI...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more URIs to open. <i>yelp</i> supports various URI schemes like <b>help:</b> for local documentation (e.g., <b>help:yelp/index</b> or <b>help:gnome-terminal/index</b>) or standard web schemes like HTTP/HTTPS for online resources.<br><br>


title: DESCRIPTION
content:
<i>yelp</i> is the default help browser for the GNOME desktop environment, designed to display documentation in various formats, primarily Mallard (the official GNOME help format) and DocBook. Users can access help files for applications, system components, and general desktop usage through <i>yelp</i>. It provides a graphical interface for browsing, searching, and navigating help topics, often accessible via an application's "Help" menu or by directly invoking the <i>yelp</i> command with a URI. Its purpose is to provide an accessible and integrated help system for GNOME users, allowing for easy access to application-specific and general system help.


title: CAVEATS
content:
<i>yelp</i> is primarily designed for and integrated with the GNOME desktop environment. Its optimal functionality and primary support are for documentation written in Mallard and DocBook formats. While it can open other document types, its core strength lies in these structured help formats. The <b>-u</b> or <b>--uri</b> option is considered deprecated; passing URIs directly as arguments is the preferred method.


title: URI USAGE
content:
<i>yelp</i> extensively uses URIs to locate and display documentation. For local help, the <b>help:</b> scheme is common, e.g., <b>help:gnome-terminal/index</b> to open the help for GNOME Terminal, or <b>help:yelp/index</b> for <i>yelp</i>'s own help. These URIs often point to specific topics or the main index of an application's documentation. Users can also specify direct file paths (e.g., <b>file:///path/to/doc.xml</b>) or web URLs (e.g., <b>https://developer.gnome.org/</b>) for external resources.


title: SUPPORTED FORMATS
content:
The primary documentation formats natively supported and optimized by <i>yelp</i> are <b>Mallard</b> and <b>DocBook XML</b>. Mallard is the recommended GNOME help format, known for its topic-oriented approach and re-usability, making it ideal for software documentation. DocBook XML is a widely adopted standard for technical documentation, offering robust structuring capabilities. While these are its core strengths, <i>yelp</i> can also render basic HTML content and plain text files, and in some configurations, it might integrate with other viewers like <i>evince</i> to open PDF documents.


title: HISTORY
content:
<i>yelp</i> has served as the official help browser for the GNOME desktop environment since its early versions. It was developed to provide an integrated, user-friendly system for accessing application and system documentation, aiming to replace more disparate help solutions. Over time, its development has closely tracked the GNOME project's evolution, with a significant shift towards supporting modern web technologies for rendering and indexing help content. This led to the adoption of the Mallard format as its primary documentation standard, designed for topic-oriented and re-usable content, aligning with broader GNOME documentation efforts.


title: SYNOPSIS
content:
<b>yersinia</b> [<i>options</i>]<br><b>yersinia</b> -G | -I<br><b>yersinia</b> -p <<i>protocol</i>> [<i>protocol_options</i>]


title: PARAMETERS
content:
<b>-G</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Yersinia</i> in graphical user interface (GUI) mode.<br><br><b>-I</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>Yersinia</i> in interactive text-based console mode.<br><br><b>-p <protocol></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the protocol to attack. Examples: STP, DHCP, HSRP, VTP, DTP, CDP, ISL, 802.1Q.<br><br><b>-i <interface></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to use for sending/receiving packets.<br><br><b>-e <protocol_specific_option></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a protocol-specific command or attack option without entering interactive mode.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables daemonization, keeping <i>Yersinia</i> running in the foreground (useful with -e).<br><br><b>-r <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads packets from a pcap file for analysis or replay.<br><br><b>-w <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes captured or generated packets to a pcap file.<br><br><b>-l <log_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs output and events to the specified file.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>Yersinia</i> is a powerful network security tool designed to analyze and exploit vulnerabilities in various network protocols, primarily focusing on Layer 2 (Data Link Layer) and some Layer 3 protocols. It acts as a framework for performing active attacks against networking protocols like Spanning Tree Protocol (STP), Dynamic Host Configuration Protocol (DHCP), Hot Standby Router Protocol (HSRP), Virtual Trunking Protocol (VTP), and others. Its main purpose is to test the resilience and security posture of network devices and infrastructure against common protocol-based attacks. <i>Yersinia</i> can be used in graphical, interactive text-based, or command-line modes, making it versatile for different testing scenarios. It helps network administrators and security professionals identify weaknesses that could be exploited by malicious actors, such as Man-in-the-Middle (MITM) attacks, denial-of-service (DoS), or unauthorized network access through protocol manipulation.


title: CAVEATS
content:
<i>Yersinia</i> is a powerful tool capable of disrupting network services. It should only be used in controlled environments for authorized testing and educational purposes. Using it improperly or on networks you do not own or have explicit permission to test is illegal and unethical. It typically requires root privileges to operate network interfaces in raw mode.


title: MODES OF OPERATION
content:
<i>Yersinia</i> supports three primary modes: a <b>graphical user interface (-G)</b> for visual interaction, an <b>interactive text-based console (-I)</b> which is highly versatile for command-line users, and a <b>pure command-line mode</b> for scripting or executing specific attacks directly without an interactive session (often used with -e and -D).


title: SUPPORTED PROTOCOLS
content:
<i>Yersinia</i> can launch attacks against a variety of network protocols, including: <b>STP</b> (Spanning Tree Protocol), <b>DHCP</b> (Dynamic Host Configuration Protocol), <b>HSRP</b> (Hot Standby Router Protocol), <b>VTP</b> (VLAN Trunking Protocol), <b>DTP</b> (Dynamic Trunking Protocol), <b>CDP</b> (Cisco Discovery Protocol), <b>ISL</b> (Inter-Switch Link), and <b>802.1Q</b> (VLAN tagging).


title: HISTORY
content:
<i>Yersinia</i> was developed by the Black Hat community, with its initial public release at Black Hat Europe. It was created to provide a dedicated tool for performing Layer 2 attacks, which were often overlooked by broader security scanners. Its development aimed to highlight the vulnerabilities in common networking protocols that could lead to significant network disruptions or security breaches, thus promoting better network design and configuration practices.


title: PARAMETERS
content:
<b><i>STRING</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The string (or multiple strings separated by spaces) to be printed repeatedly to standard output, followed by a newline. If no <i>STRING</i> is provided, the command defaults to printing 'y' followed by a newline.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit. This option provides a brief overview of the command's usage and available options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output version information and exit. This shows the program's name, version, and licensing details.<br><br>


title: DESCRIPTION
content:
The <b>yes</b> command is a simple but powerful utility in Unix-like operating systems. Its primary function is to print a specified string, or the character 'y' by default, repeatedly to standard output until it is killed. This continuous output makes <b>yes</b> incredibly useful for automating responses to prompts from other commands. <br><br>For instance, it is often piped to commands that require user confirmation (e.g., 'y' or 'n'), effectively providing an automatic 'yes' answer to all prompts. This can be particularly helpful in scripts or automated environments where interactive input is not feasible. Beyond simple confirmations, <b>yes</b> can also be used to generate large files for testing purposes, or to flood a terminal with text, although these are less common applications. It's a fundamental tool for scripting and basic system automation.


title: CAVEATS
content:
<b>yes</b> outputs continuously and indefinitely, consuming CPU cycles and potentially filling output buffers or even disk space if redirected to a file, unless explicitly terminated (e.g., with <i>Ctrl+C</i>) or piped to a command that eventually finishes. <br><br>While useful for automation, piping <b>yes</b> to commands that prompt for confirmation (like <i>rm -i</i>) can be dangerous if not used with extreme caution, as it will automatically confirm every destructive operation without user review.


title: GENERATING LARGE FILES FOR TESTING
content:
The <b>yes</b> command can be effectively combined with other utilities like <i>head</i> or <i>dd</i> to quickly generate large files of repetitive content for testing disk I/O, file system performance, or network throughput. For example: <i>yes A | head -c 1G > 1GB_file.txt</i> would create a 1 Gigabyte file filled with the letter 'A'.


title: AUTOMATING CONFIRMATIONS
content:
One of the most common and powerful uses of <b>yes</b> is to provide automatic 'y' (yes) responses to commands that prompt for user confirmation. This is typically done by piping its output to the interactive command, allowing scripts to run non-interactively. For example: <i>yes | rm -i *.txt</i> would delete all .txt files without prompting for each one.


title: HISTORY
content:
The <b>yes</b> command is a fundamental Unix utility that has been part of the operating system since its early versions. Its simplicity reflects the philosophy of Unix tools doing 'one thing well'. It's a core component of the GNU Core Utilities package, ensuring its widespread availability across Linux distributions. While its function remains straightforward, its enduring utility in scripting and automation underscores its importance in the Unix toolkit.


title: DESCRIPTION
content:
The term "yesod" does not refer to a standard, standalone command found in typical Linux distributions. Instead, <I>Yesod</I> is a powerful, production-ready web framework written in the <I>Haskell</I> programming language. It is known for its type safety, performance, and robust features for building complex web applications. While Yesod applications can be deployed and run on Linux systems, and developers might use build tools like <B>stack</B> or <B>cabal</B> to compile or run Yesod projects on Linux, "yesod" itself is not a system utility or a command you would execute directly from the shell like <B>ls</B> or <B>grep</B>. Therefore, there is no man page or traditional command-line interface directly associated with a "yesod" command.


title: CAVEATS
content:
This entry describes that "yesod" is not a native Linux command. Attempts to execute "yesod" directly in a shell will result in a "command not found" error unless a specific alias or a custom script named "yesod" has been created or installed on the system.


title: WHAT IS YESOD?
content:
<I>Yesod</I> is a high-level, declarative, and type-safe framework for building web applications in <I>Haskell</I>. It provides features like routing, database integration (via <I>Persistent</I>), templating (<I>Hamlet</I>), forms (<I>Yesod.Form</I>), and client-side integration (<I>Julius</I> for JavaScript, <I>Cassius</I> for CSS). Its design philosophy emphasizes compile-time safety to prevent common web development errors, leading to more reliable and maintainable applications.


title: USAGE CONTEXT ON LINUX
content:
On a Linux system, a developer would interact with <I>Yesod</I> by setting up a <I>Haskell</I> development environment (e.g., with <B>ghcup</B>), installing build tools like <B>stack</B> or <B>cabal</B>, and then using these tools to create, build, and run Yesod projects. For example, <B>stack new my-yesod-app yesodweb/yesod-minimal</B> would create a new project, and <B>stack build</B> followed by <B>stack exec my-yesod-app</B> would build and run the application. The application itself would then typically run as a server process, listening on a specific port.


title: HISTORY
content:
The <I>Yesod</I> web framework was created by Michael Snoyman and and first publicly released around 2009-2010. Its development has been driven by the Haskell community's desire for a robust, high-performance web framework that leverages Haskell's strengths in type safety and concurrency. It has evolved significantly over the years, integrating modern web development practices and maintaining a strong focus on correctness and developer productivity. Its history is tied to the evolution of the Haskell ecosystem and its application in web development, rather than the history of a standalone shell command.


title: SEE ALSO
content:
stack(1) - Haskell build tool, often used with Yesod projects, cabal(1) - Haskell build tool, another option for Yesod projects, ghc(1) - The Glasgow Haskell Compiler, fundamental for Yesod development


title: SYNOPSIS
content:
<b>yetris</b><br><i>(Note: Specific implementations may offer additional command-line options not universally present.)</i>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>yetris</i> command, being primarily a game, typically does not accept command-line parameters for its core functionality. Interaction is performed through in-game key presses after the game starts. Some specific implementations might offer standard options like <i>--help</i> or <i>--version</i>, but these are not universally present across all <i>yetris</i> clones.<br><br>


title: DESCRIPTION
content:
The <i>yetris</i> command is not a standard Linux system utility, but rather a common name for various independent, open-source implementations of the popular Tetris puzzle game, designed to be played directly within a terminal or console. These versions typically replicate the core gameplay of falling blocks (tetrominoes) that players must rotate and position to form complete horizontal lines, which then clear from the board. <i>yetris</i> projects are often developed using libraries like ncurses for text-based graphics, providing a retro gaming experience. Due to its nature as a game, it does not interact with the filesystem or manage system resources in the way typical Linux commands do. Installation usually involves compiling from source code or installing via specific distribution repositories that package such games. It offers a simple, engaging way to play Tetris directly on the command line without a graphical desktop environment.


title: CAVEATS
content:
The <i>yetris</i> command is not part of the standard GNU/Linux core utilities or a universally pre-installed package. Its availability depends on whether a specific distribution packages a <i>yetris</i> clone or if a user compiles it from source. Functionality and features can vary significantly between different open-source implementations that share the name. It is intended solely for interactive gameplay and offers no scripting capabilities or system administration functions.


title: IN-GAME CONTROLS
content:
Since <i>yetris</i> is an interactive game, its primary 'parameters' are typically keyboard inputs during gameplay. Common controls usually include:<br><i>Arrow Keys</i>: Move left/right, soft drop (down).<br><i>Up Arrow Key</i> or <i>Spacebar</i>: Rotate block.<br><i>'P' Key</i>: Pause game.<br><i>'Q' Key</i>: Quit game.<br><i>'R' Key</i>: Restart game.<br><i>(Note: Specific key bindings may vary depending on the implementation and configuration.)</i>


title: HISTORY
content:
The concept of terminal-based Tetris clones like <i>yetris</i> emerged shortly after the original Tetris game gained widespread popularity. Developers often create their own versions as a programming exercise or for personal enjoyment, frequently utilizing text-based user interface libraries like ncurses or curses. As such, there isn't a single, definitive 'yetris' project with a linear development history, but rather numerous independent implementations that have been created and shared by various programmers over the years, each contributing to the legacy of command-line gaming.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print version information and exit.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug output for more detailed information during operation.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output.<br><br><b>-s, --short</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only essential information: serial number, firmware version, and OTP type.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress headers and only print the requested information, suitable for scripting.<br><br><b>-t, --token</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print information about the token in a format suitable for scripting, often key-value pairs.<br><br><b>-m, --monitor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continuously monitor for changes in YubiKey status (e.g., insertion or removal).<br><br><b>-u, --device=<I>NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify which YubiKey device to use when multiple are connected, by its device number (e.g., 0, 1).<br><br>


title: DESCRIPTION
content:
The <b>ykinfo</b> command is a utility from the YubiKey Personalization Tools suite designed to query and display various details about a connected YubiKey device.<br><br>It provides essential information such as the YubiKey's serial number, firmware version, device capabilities, and configuration status (e.g., whether OTP, challenge-response, or static password slots are programmed). This command is particularly useful for quickly verifying a YubiKey's identity, checking its basic health, or understanding its current settings without altering them.<br><br><b>ykinfo</b> can interact with the YubiKey over USB, typically via CCID or HID protocols. It's an indispensable tool for YubiKey administrators and users who need to confirm device specifics or troubleshoot common issues. While more comprehensive tools like <i>ykman</i> exist, <b>ykinfo</b> offers a simple and focused way to retrieve key device data.


title: CAVEATS
content:
<b>ykinfo</b> requires the <i>yubikey-personalization</i> package to be installed on the system.<br><br>Proper permissions (e.g., via udev rules) are necessary for the user to access USB devices like the YubiKey. Without correct permissions, the command may not detect connected devices or may report permission errors.<br><br>The exact output and supported features might vary slightly depending on the specific YubiKey model (e.g., YubiKey 5, YubiKey 4, YubiKey NEO) and its firmware version.


title: TYPICAL OUTPUT FIELDS
content:
When run without options, <b>ykinfo</b> typically displays:<br><b>Serial Number</b>: A unique identifier for the YubiKey.<br><b>Firmware Version</b>: The version of the firmware running on the device.<br><b>OTP Capabilities</b>: Information about the YubiKey's One-Time Password (OTP) generation capabilities.<br><b>Configuration Slot Status</b>: Indicates whether configuration slots (Slot 1 and Slot 2) are programmed or empty.<br><b>Formfactor</b>: The physical form factor of the YubiKey (e.g., USB-A, USB-C, Nano).


title: PERMISSIONS AND UDEV RULES
content:
For <b>ykinfo</b> to function correctly, the user often needs read/write access to the YubiKey's USB device file. This is typically managed through udev rules (e.g., <i>69-yubikey.rules</i>). If you encounter 'permission denied' errors, ensure your user is part of the appropriate group (e.g., <i>plugdev</i> or <i>users</i>) or that udev rules are correctly configured to grant access to YubiKeys.


title: HISTORY
content:
The <b>ykinfo</b> command is part of the original YubiKey Personalization Tools, a collection of utilities developed by Yubico to manage and configure YubiKey devices.<br><br>It has been a foundational tool for querying YubiKey status since the early days of YubiKey adoption. While newer, more comprehensive tools like <i>ykman</i> have emerged as the primary interface for YubiKey management in recent years, <b>ykinfo</b> remains a simple, standalone utility for quick informational lookups, often maintained for compatibility and its focused functionality.


title: SYNOPSIS
content:
<b>ykman</b> [<i>GLOBAL_OPTIONS</i>] <i>COMMAND</i> [<i>COMMAND_OPTIONS</i>] [<i>ARGUMENTS</i>]<br><br>Examples:<br><b>ykman info</b><br><b>ykman oath accounts add 'MyService' 'JBSWY3DPEHPK3PXP'</b><br><b>ykman piv change-pin</b>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message for <i>ykman</i> or a specific subcommand.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version information for <i>ykman</i>.<br><br><b><b>-d</b>, <b>--device</b> <i>SERIAL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a YubiKey by its serial number to operate on, useful when multiple YubiKeys are connected.<br><br><b><b>-l</b>, <b>--log-level</b> <i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging verbosity. Possible levels include <i>debug</i>, <i>info</i>, <i>warning</i>, <i>error</i>, or <i>critical</i>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information during command execution.<br><br><b><b>--full-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show comprehensive help, including less common commands and advanced options not always visible with <b>--help</b>.<br><br>


title: DESCRIPTION
content:
<i>ykman</i> is the official command-line tool for managing and configuring YubiKey hardware security keys. It provides a comprehensive interface for interacting with various YubiKey applications and features, including One-Time Password (OTP), FIDO2/WebAuthn, PIV (Smart Card), OATH (TOTP/HOTP), and OpenPGP. Users can perform tasks such as retrieving device information, configuring global settings, provisioning credentials, resetting applications, changing PINs, and managing USB interfaces. <i>ykman</i> is essential for power users, developers, and administrators who need fine-grained control over their YubiKeys, enabling automation and scripting of common management operations. Its modular design, utilizing subcommands, makes it versatile for different YubiKey functionalities.


title: CAVEATS
content:
Some operations, such as factory resetting the YubiKey or resetting specific applications, are destructive and irreversible. Always back up any critical data or credentials before performing such actions. Proper system permissions (e.g., udev rules or administrator/root privileges) might be required for <i>ykman</i> to access the YubiKey device, especially for write operations. Not all <i>ykman</i> features are available on all YubiKey models or firmware versions; consult YubiKey documentation for specific compatibility details.


title: KEY SUBCOMMANDS
content:
<i>ykman</i>'s functionality is organized into several key subcommands, each managing a specific aspect or application of the YubiKey:<br><b>info</b>: Displays general information about the connected YubiKey.<br><b>config</b>: Configures global YubiKey settings, such as USB interfaces and device capabilities.<br><b>otp</b>: Manages Yubico OTP credentials, including programming slots.<br><b>oath</b>: Manages OATH credentials for Yubico Authenticator (TOTP/HOTP).<br><b>piv</b>: Manages the PIV (Personal Identity Verification) smart card application, including certificates and PINs.<br><b>openpgp</b>: Manages the OpenPGP smart card application, including keys and administrative settings.<br><b>fido2</b>: Manages FIDO2/WebAuthn credentials and settings.<br><b>u2f</b>: Manages U2F (Universal 2nd Factor) settings.<br><b>calibrate</b>: Performs a touch calibration on the YubiKey (for models with touch sensors).<br><b>usb</b>: Configures the USB interfaces enabled on the YubiKey.


title: SECURITY CONSIDERATIONS
content:
When using <i>ykman</i>, particularly with commands that modify or reset the device, exercise extreme caution. Ensure you understand the implications of each command, especially those involving sensitive data, cryptographic keys, or device resets. Always use <i>ykman</i> from a trusted and secure environment to prevent unauthorized access or manipulation of your YubiKey. For new devices, it's advisable to factory reset and change default PINs before use.


title: HISTORY
content:
<i>ykman</i> is developed and maintained by Yubico, the creators of the YubiKey. It serves as the primary and official command-line interface for YubiKey management. Over time, it has evolved to consolidate various functionalities into a single, cohesive tool, streamlining the process of configuring and interacting with different YubiKey applications. Its continuous development reflects the expanding capabilities of YubiKeys and the need for a robust, scriptable management utility that integrates seamlessly with operating systems.


title: SYNOPSIS
content:
ykman config <I>subcommand</I> [<I>options...</I>]<br><br><I>Common subcommands:</I><br>&nbsp;&nbsp;ykman config <b>get</b> <I>SETTING</I><br>&nbsp;&nbsp;ykman config <b>set</b> <I>SETTING VALUE</I><br>&nbsp;&nbsp;ykman config <b>fido2</b> <b>set-pin-retries</b> <I>MAX_ATTEMPTS</I> <I>BLOCK_ATTEMPTS</I><br>&nbsp;&nbsp;ykman config <b>force-touch</b> <b>get</b> <I>APPLICATION</I><br>&nbsp;&nbsp;ykman config <b>usb</b> <b>disable</b> <I>APPLICATION</I>


title: PARAMETERS
content:
<b><b>get</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the current value of a specified device or global setting. Requires an additional subcommand (e.g., <b>fido2</b>, <b>nfc</b>, <b>usb</b>) to specify the setting category.<br><br><b><b>set</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a new value for a specified device or global setting. Requires an additional subcommand and a value to set (e.g., <b>fido2</b>, <b>nfc</b>, <b>usb</b>).<br><br><b><b>force-touch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages the force-touch policy for various YubiKey applications (e.g., FIDO2, OTP), determining when a physical touch is required.<br><br><b><b>fido2</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages FIDO2 (WebAuthn) specific settings, such as PIN retries, minimum PIN length, and the ability to reset FIDO2 credentials.<br><br><b><b>nfc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures settings related to the YubiKey's NFC interface, including NDEF URI configuration and enabling/disabling NFC.<br><br><b><b>usb</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures USB interface settings, allowing the user to enable or disable specific applications (e.g., OTP, FIDO, PIV) over the USB connection.<br><br>


title: DESCRIPTION
content:
<i>ykman config</i> is a powerful subcommand of the <i>ykman</i> (YubiKey Manager) utility, designed for managing various device-wide settings and global configurations of YubiKey hardware. It enables users to exercise fine-grained control over features such as FIDO2 (WebAuthn) settings, Universal 2nd Factor (U2F) touch policies, NDEF (NFC Data Exchange Format) capabilities, and general device information like serial number visibility or power-saving modes. This command provides a crucial interface for customizing the YubiKey's behavior to align with specific security requirements and usage scenarios, ensuring optimal performance and compliance with different protocols. It's an essential tool for administrators and advanced users who require deep control over their YubiKey's foundational settings, extending beyond typical application-specific configurations.


title: CAVEATS
content:
Using <i>ykman config</i> often requires the YubiKey to be connected to the system. Some configuration changes, especially security-sensitive ones like FIDO2 PIN settings or global resets, may require the management key or PIN for authentication. Changes made are permanent and device-specific. For some operations, elevated privileges (sudo) may be required to access the YubiKey device.


title: COMMON CONFIGURATION SETTINGS
content:
Some of the most frequently managed settings include enabling or disabling specific applications (like U2F) over USB or NFC, setting the maximum FIDO2 PIN retry counts, configuring the NDEF URI for NFC applications, and defining touch policies for OTP or FIDO operations. The available options depend significantly on the YubiKey model and its supported features.


title: IMPACT ON YUBIKEY APPLICATIONS
content:
The <i>ykman config</i> command can profoundly affect various YubiKey applications, including OTP (One-Time Password), FIDO2/U2F, PIV (Personal Identity Verification), OATH (HOTP/TOTP), and OpenPGP. Understanding which subcommand or option affects which application is crucial for effective device management.


title: HISTORY
content:
The <i>ykman</i> utility, including its <i>config</i> subcommand, was developed by Yubico as a comprehensive command-line tool to manage their range of YubiKey devices. It emerged to provide a programmatic interface for YubiKey management, complementing the graphical YubiKey Manager application. The <i>config</i> subcommand specifically addresses the growing complexity of YubiKey models, which now support multiple applications (FIDO2, PIV, OATH, etc.) and require robust tools for device-wide configuration, beyond simple key generation or credential enrollment.


title: SYNOPSIS
content:
<i>ykman fido</i> <I>command</I> [<I>options</I>] [<I>arguments</I>]<br><br>Common <i>commands</i> include:<br><br><i>ykman fido info</i><br><i>ykman fido reset</i> [--force]<br><i>ykman fido verify</i> [--pin <I>PIN</I>]<br><i>ykman fido change-pin</i> [--pin <I>PIN</I>] [--new-pin <I>NEW_PIN</I>]<br><i>ykman fido set-pin</i> [--pin <I>PIN</I>] [--new-pin <I>NEW_PIN</I>]<br><i>ykman fido credentials list</i> [--fingerprints]<br><i>ykman fido credentials delete</i> [--pin <I>PIN</I>] [--cred-id <I>CRED_ID</I>] [--rp-id <I>RP_ID</I>]


title: PARAMETERS
content:
<b>command</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The specific FIDO operation to perform (e.g., <i>info</i>, <i>reset</i>, <i>verify</i>, <i>change-pin</i>, <i>set-pin</i>, <i>credentials</i>).<br><br><b>-d, --device <SERIAL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the YubiKey device by its serial number if multiple devices are connected.<br><br><b>-l, --log-level <LEVEL></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging verbosity level (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL).<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message for the <i>ykman fido</i> command or its subcommands.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>reset</i> to bypass the confirmation prompt for destructive actions.<br><br><b>--pin <PIN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide the current FIDO PIN non-interactively.<br><br><b>--new-pin <NEW_PIN></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide the new FIDO PIN non-interactively when setting or changing the PIN.<br><br><b>--fingerprints</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>credentials list</i> to include credential fingerprints in the output.<br><br><b>--cred-id <CRED_ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>credentials delete</i> to specify the credential ID to remove.<br><br><b>--rp-id <RP_ID></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <i>credentials delete</i> to specify the Relying Party ID (domain) of the credential to remove.<br><br>


title: DESCRIPTION
content:
The <i>ykman-fido</i> command is a specialized subcommand of the YubiKey Manager (<i>ykman</i>) utility, dedicated to administering the FIDO2 (WebAuthn) and U2F applications on YubiKey devices. It provides functionalities to interact with the FIDO capabilities of the YubiKey, allowing users to view device information, manage discoverable credentials, and control access settings. Key operations include listing or deleting FIDO2 credentials, resetting the FIDO application (which is a destructive action), and managing the FIDO PIN, such as setting, changing, or verifying it. This tool is essential for users who leverage their YubiKeys for passwordless authentication or as a second factor using FIDO/WebAuthn standards.


title: CAVEATS
content:
<b>Destructive Operations:</b> The <i>ykman fido reset</i> command is highly destructive. It will factory reset the entire FIDO application on the YubiKey, deleting all FIDO2 credentials and U2F registrations, including any resident (discoverable) credentials. This action is irreversible and requires explicit confirmation unless the <i>--force</i> option is used.<br><b>PIN Management:</b> Providing PINs directly via command-line options (<i>--pin</i>, <i>--new-pin</i>) is less secure than interactive prompts, as the PIN may be exposed in shell history or process listings. Use with caution.<br><b>Credential Deletion:</b> When deleting FIDO2 credentials, ensuring you have the correct <i>--cred-id</i> and <i>--rp-id</i> is crucial to avoid unintended deletions.


title: DISCOVERABLE CREDENTIALS
content:
<i>ykman fido credentials</i> specifically manages "discoverable" (or "resident") credentials, which are stored directly on the YubiKey. These allow for passwordless login without needing a username or password, as the YubiKey can identify the user and prompt for a PIN or fingerprint.


title: U2F VS. FIDO2
content:
While <i>ykman fido</i> primarily focuses on FIDO2/WebAuthn, it implicitly manages the underlying U2F application as well, as FIDO2 is an evolution of U2F. A FIDO application reset will affect both.


title: HISTORY
content:
The <i>ykman</i> utility and its subcommands, including <i>ykman-fido</i>, are developed and maintained by Yubico, the creators of the YubiKey. As FIDO2 (WebAuthn) gained prominence as a modern, phishing-resistant authentication standard, the need for robust management tools directly integrated with the YubiKey became apparent. The <i>ykman-fido</i> subcommand was introduced to provide comprehensive command-line control over the YubiKey's FIDO capabilities, allowing advanced users and system administrators to script and automate FIDO application management tasks. Its functionality has evolved with new FIDO specifications and YubiKey models, offering increasingly granular control over discoverable credentials and device settings.


title: SYNOPSIS
content:
<b>ykman oath</b> <<i>subcommand</i>> [<<i>options</i>>] [<<i>arguments</i>>]<br><br>Common subcommands:<br>  <b>ykman oath accounts add</b> <<i>name</i>> [<<i>secret</i>>]<br>  <b>ykman oath accounts delete</b> <<i>name</i>><br>  <b>ykman oath accounts list</b><br>  <b>ykman oath code</b> [<<i>name</i>>]<br>  <b>ykman oath info</b><br>  <b>ykman oath reset</b>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit for the command or subcommand.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's version number and exit.<br><br><b><b>-d</b>, <b>--device</b> <<i>serial</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific YubiKey device by its serial number if multiple are connected.<br><br><b><b>-l</b>, <b>--log-level</b> <<i>level</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the log level for output (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL).<br><br><b><b>-p</b>, <b>--password</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompt for a password to unlock the OATH application on the YubiKey, if set.<br><br><b><b>accounts add</b> <<i>name</i>> [<<i>secret</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a new OATH credential to the YubiKey. <br>  <<i>name</i>>: The identifier for the credential (e.g., 'Google:user@example.com'). <br>  [<<i>secret</i>>]: The base32-encoded OATH secret. If omitted, the tool will prompt for it.<br><br><b><b>--totp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' to specify the credential is TOTP (Time-based One-Time Password). This is the default if neither --totp nor --hotp is specified.<br><br><b><b>--hotp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' to specify the credential is HOTP (HMAC-based One-Time Password).<br><br><b><b>-d</b>, <b>--digits</b> <<i>digits</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' to specify the number of digits for the generated code (6 or 8, default is 6).<br><br><b><b>-i</b>, <b>--period</b> <<i>seconds</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' for TOTP credentials to set the period in seconds (default is 30).<br><br><b><b>-c</b>, <b>--counter</b> <<i>counter</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' for HOTP credentials to set the initial counter value (default is 0).<br><br><b><b>-s</b>, <b>--touch-required</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts add' to configure the credential to require a physical touch on the YubiKey to generate a code.<br><br><b><b>accounts delete</b> <<i>name</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes an OATH credential specified by its name from the YubiKey.<br><br><b><b>accounts list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all OATH credentials stored on the YubiKey.<br><br><b><b>-s</b>, <b>--single</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts list' to only show single codes that do not require touch.<br><br><b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'accounts list' to show all accounts, including those requiring touch.<br><br><b><b>code</b> [<<i>name</i>>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates and prints the OATH code for a specified credential. If <<i>name</i>> is omitted and multiple accounts exist, it may prompt for selection.<br><br><b><b>info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general information about the OATH application on the connected YubiKey, such as version and password status.<br><br><b><b>reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the OATH application on the YubiKey, permanently deleting all stored OATH credentials and clearing any set password.<br><br>


title: DESCRIPTION
content:
<i>ykman-oath</i> is a powerful subcommand of the <i>ykman</i> (YubiKey Manager) tool, designed specifically for interacting with and managing OATH (Open AuTHentication) applications on a YubiKey. OATH applications typically involve Time-based One-Time Passwords (TOTP) and HMAC-based One-Time Passwords (HOTP), which are widely used for two-factor authentication (2FA). This command allows users to list, add, delete, and generate codes for these credentials directly from the command line.<br><br>It provides a convenient way to provision and use 2FA tokens stored securely on a YubiKey, integrating seamlessly into command-line workflows. It abstracts the complexities of the underlying CCID interface, offering a user-friendly interface for security-conscious individuals and system administrators. Whether you need to enroll a new TOTP secret for an online service or generate a one-time code for login, <i>ykman-oath</i> streamlines the process.


title: CAVEATS
content:
Resetting the OATH application using <b>ykman oath reset</b> will permanently delete all OATH credentials stored on your YubiKey. Ensure you have backups of all your secrets before performing this action.<br><br>The YubiKey has a limited number of slots for OATH credentials (typically 32).<br><br>Accessing the YubiKey with <i>ykman</i> often requires appropriate USB access permissions, which may necessitate running the command with <b>sudo</b> or configuring udev rules.


title: PASSWORD PROTECTION
content:
The OATH application on a YubiKey can be protected with a password. If a password is set, operations like listing accounts or generating codes will require you to provide it, either via the <b>--password</b> flag or by being prompted.


title: TOUCH REQUIREMENT FOR CODES
content:
For enhanced security, individual OATH credentials can be configured to require a physical touch on the YubiKey before a code is generated. This prevents unauthorized code generation even if your computer's software environment is compromised.


title: BASE32 ENCODING
content:
When adding new OATH credentials, the secret keys are typically provided in Base32 encoding. Many services that offer TOTP/HOTP secrets provide them in this format, which <i>ykman-oath</i> expects.


title: HISTORY
content:
The <i>ykman</i> tool, and consequently its <i>oath</i> subcommand, emerged as the official command-line interface for managing YubiKey devices. Prior to <i>ykman</i>, users often relied on separate, less integrated tools or third-party solutions to manage different YubiKey applications like PIV, OATH, or FIDO. The development of <i>ykman</i> aimed to provide a unified, user-friendly, and comprehensive toolset.<br><br>The <i>oath</i> subcommand specifically consolidates the functionality for provisioning and using HOTP/TOTP credentials, making the YubiKey an even more versatile hardware authenticator. Its continuous development reflects the evolving standards of multi-factor authentication and the increasing demand for seamless hardware security integration.


title: PARAMETERS
content:
<b><b>attest</b> <i>&lt;KEY_SLOT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates an attestation certificate for a key in a specific slot (e.g., <i>signature</i>, <i>encryption</i>, <i>authentication</i>).<br><br><b><b>change-pin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the user PIN for the OpenPGP application.<br><br><b><b>change-rc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the reset code (Admin PIN) for the OpenPGP application.<br><br><b><b>delete-key</b> <i>&lt;KEY_SLOT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a key from a specified key slot.<br><br><b><b>disable-button</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the button touch requirement for signature operations. Use with caution.<br><br><b><b>info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general status information about the OpenPGP application on the YubiKey, including firmware version, PIN status, and key attributes.<br><br><b><b>keys</b> <i>[COMMAND]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A subcommand for managing OpenPGP keys themselves. It includes:<br><i><b>import</b> &lt;SLOT&gt; &lt;FILE&gt;</i>: Imports a private key into a slot from a file.<br><i><b>export</b> &lt;SLOT&gt; &lt;FILE&gt;</i>: Exports a public key from a slot to a file.<br><i><b>list</b></i>: Lists keys on the device.<br><i><b>delete</b> &lt;SLOT&gt;</i>: Deletes a key from a specific slot.<br><i><b>set-touch</b> &lt;SLOT&gt; &lt;POLICY&gt;</i>: Sets touch policy for a specific key slot (e.g., <i>off</i>, <i>on</i>, <i>fixed</i>, <i>cached</i>).<br><br><b><b>reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the entire OpenPGP application to factory defaults. <b>Warning: This operation is destructive and irreversible, erasing all keys and settings.</b><br><br><b><b>set-consent</b> <i>&lt;TYPE&gt; &lt;POLICY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the consent for attestation (e.g., <i>attestation on</i> or <i>off</i>).<br><br><b><b>set-touch</b> <i>&lt;KEY_SLOT&gt; &lt;POLICY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets touch policy for a key slot (e.g., <i>signature on</i>). Note: For specific key slots, <i>keys set-touch</i> is often preferred in newer versions.<br><br><b><b>set-url</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the URL where the public key can be found, often used for key discovery.<br><br><b><b>unblock-pin</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unblocks the user PIN using the reset code (Admin PIN).<br><br>


title: DESCRIPTION
content:
The <b>ykman-openpgp</b> command is a subcommand of <b>ykman</b>, the YubiKey Manager tool, specifically designed to interact with and manage the OpenPGP application present on a YubiKey. It allows users to perform various cryptographic operations and administrative tasks related to PGP keys stored on the hardware security module.<br><br>This includes managing private keys (importing, deleting), setting touch policies for operations, changing PINs, unblocking PINs, generating attestations, and resetting the entire OpenPGP application. It provides a command-line interface to secure key management, ensuring that sensitive cryptographic material remains protected by the YubiKey's hardware security features. This tool is essential for users who rely on YubiKeys for PGP-based authentication, encryption, and digital signing.


title: CAVEATS
content:
<b>ykman-openpgp</b> requires the <b>ykman</b> tool to be installed and a YubiKey device to be connected.<br>Operations like <b>reset</b> are destructive and irreversible; ensure backups are made if needed.<br>Losing PINs or the reset code can lead to keys becoming inaccessible.<br>Touch policies affect security and user experience; understand their implications before changing.<br>This tool primarily manages <i>private</i> keys on the YubiKey; public key management and broader OpenPGP operations are typically handled by tools like <b>gpg</b>.


title: KEY SLOTS
content:
The OpenPGP application on a YubiKey typically has three dedicated key slots: <i>signature</i>, <i>encryption</i>, and <i>authentication</i>. These slots are used for different purposes in PGP and can store distinct private keys.


title: TOUCH POLICY
content:
This setting determines if a physical touch of the YubiKey button is required for certain sensitive operations (e.g., signing or decrypting). Common policies include <i>off</i> (no touch required), <i>on</i> (touch always required), <i>fixed</i> (always on, cannot be changed), and <i>cached</i> (touch required once per session).


title: HISTORY
content:
The <b>ykman</b> tool, including its <b>openpgp</b> subcommand, was developed by Yubico to provide a cross-platform, command-line interface for managing YubiKey devices. As YubiKeys evolved to support various applications, including OpenPGP (which became a standard feature on many models), a dedicated tool was needed beyond simple smart card utilities. <b>ykman-openpgp</b> provides a more user-friendly and YubiKey-specific way to interact with the OpenPGP application, complementing the more general <b>gpg</b> command-line tools which primarily interact with the OpenPGP application via the SmartCard interface. Its development reflects the growing need for robust hardware-backed security for PGP keys.


title: PARAMETERS
content:
<b>-i <file>, --input <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input file or data stream for immediate processing, without maintaining state.<br><br><b>-o <format>, --output <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output format (e.g., 'terse', 'json') for concise and immediate results.<br><br><b>-s, --speed-optimized</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prioritizes execution speed, potentially at the cost of granular detail or exhaustive analysis in its single pass.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages, showing only critical output or final results from the one-shot operation.<br><br><b>-c <count>, --count <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the output to a specified number of primary findings or items for a quick overview.<br><br><b>-d, --dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the command's execution without making actual changes, showing potential outcomes or detections in a single pass.<br><br>


title: DESCRIPTION
content:
The <I>yolo</I> command, while not a standard utility found in most Linux distributions, is conceived as a tool embodying the principle of 'You Only Look Once'—a philosophy borrowed from efficient real-time processing. It represents a conceptual approach to command-line operations where the primary goal is rapid, single-pass execution. Unlike traditional commands that might offer extensive configuration, interactive modes, or persistent state management, <I>yolo</I> is designed for immediate, 'fire-and-forget' tasks.<br><br>It's ideal for quick diagnostics, ephemeral data transformations, or swift system checks where a deep, iterative analysis is not required or even detrimental to performance. Its hypothetical implementation would prioritize speed and conciseness, providing relevant output from a single, optimized scan or action. This makes <I>yolo</I> suitable for scenarios requiring instantaneous feedback or for prototyping where setup time must be minimized. Users should recognize its non-standard status and understand that any actual <I>yolo</I> command would be a custom implementation tailored for specific use cases, focusing on delivering results with minimal overhead and without maintaining complex internal states.


title: CAVEATS
content:
<I>yolo</I> is not a standard Linux command and therefore its availability and functionality are entirely dependent on custom implementations. Users should be aware that, if implemented to reflect its 'you only live once' or 'look once' moniker, operations might be designed for ephemeral use, potentially leading to unrecoverable state changes or data loss if not used carelessly. Its single-pass nature means it might lack the depth, interactive features, or persistence of more traditional utilities. Always verify the specific implementation and its implications before use.


title: NON-STANDARD NATURE
content:
It is critical to reiterate that <I>yolo</I> is not a pre-installed or standard command. Any existing <I>yolo</I> utility would be a custom script or a component of a specialized application, requiring explicit installation or development, and its behavior would be defined by that specific implementation.


title: DESIGN PHILOSOPHY
content:
The core principle behind <I>yolo</I> is speed and immediacy. It's intended for scenarios where a quick, decisive action or observation is needed, without the overhead of extensive setup, complex configurations, or the expectation of persistent state management. It provides a 'snapshot' view or a rapid transformation.


title: HISTORY
content:
The conceptual <I>yolo</I> command draws its name and spirit from the popular 'You Only Look Once' (YOLO) family of object detection algorithms in machine learning, known for their remarkable speed and efficiency in real-time analysis.<br><br>While not a standard utility bundled with most Linux distributions, the idea of a 'yolo' command emerged from the need for swift, single-pass operations in various computing contexts—from rapid script execution and ephemeral data processing to 'fire-and-forget' system tasks. Its design philosophy emphasizes immediate results and minimal overhead, echoing the 'one-shot' nature of its namesake. Implementations would typically be custom scripts or specialized tools designed for specific, time-sensitive applications.


title: SYNOPSIS
content:
<i>you-get</i> <b>[OPTIONS]</b> <i>URL...</i><br>Example: <i>you-get -o ~/Videos "https://www.youtube.com/watch?v=..."</i>


title: PARAMETERS
content:
<b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all available video qualities and formats without downloading.<br><br><b><b>-o</b> <i>&lt;DIR&gt;</i>, <b>--output-dir</b> <i>&lt;DIR&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where downloaded files will be saved.<br><br><b><b>-O</b> <i>&lt;FILE&gt;</i>, <b>--output-file</b> <i>&lt;FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the specific filename for the downloaded content.<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;Provides login username for restricted content.<br><br><b><b>-p</b> <i>&lt;PASSWORD&gt;</i>, <b>--password</b> <i>&lt;PASSWORD&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides login password for restricted content.<br><br><b><b>--cookie-file</b> <i>&lt;FILE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses cookies loaded from a Netscape-formatted file for authentication.<br><br><b><b>-x</b> <i>&lt;HOST:PORT&gt;</i>, <b>--proxy</b> <i>&lt;HOST:PORT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures a proxy server for the download process.<br><br><b><b>--no-merge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>you-get</i> from merging downloaded parts into a single file (requires <i>ffmpeg</i>).<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output for debugging purposes.<br><br><b><b>--playlist</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads all items from a specified playlist URL.<br><br><b><b>--itag</b> <i>&lt;ID&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific video quality or format using its <i>itag</i> identifier.<br><br><b><b>-F</b> <i>&lt;FORMAT&gt;</i>, <b>--format</b> <i>&lt;FORMAT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly selects a video format from the available options.<br><br><b><b>-c</b>, <b>--continue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resumes an interrupted or partially completed download.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<i>you-get</i> is a powerful, open-source command-line utility for downloading various media content from websites. Written in Python, it excels at fetching videos, audio, and images from a wide array of platforms, including popular global sites like YouTube and Vimeo, as well as numerous Chinese streaming services such as Bilibili and Youku. Its primary function is to parse web pages, identify direct media links, and then download the content to your local machine. Key features include support for multiple video qualities, proxy configuration, resuming interrupted downloads, and handling login-required content. It serves as an invaluable tool for archiving media or enjoying content offline, making media accessible independent of internet connectivity.


title: CAVEATS
content:
<i>you-get</i> relies on parsing website structures, which can change frequently. This means an update to a website might temporarily break <i>you-get</i>'s functionality until the tool itself is updated. Users should also be aware of the legal implications of downloading copyrighted content, as this varies by jurisdiction and the terms of service of the respective website. <i>ffmpeg</i> is often required for merging downloaded video parts, which is a common dependency.


title: INSTALLATION
content:
<i>you-get</i> is typically installed via Python's package manager, pip: <br><i>`pip install you-get`</i>.<br>Ensure Python and pip are correctly set up on your system.


title: FFMPEG DEPENDENCY
content:
For <i>you-get</i> to merge fragmented video files or convert formats, the <i>ffmpeg</i> tool must be installed and accessible in your system's PATH. Without it, <i>you-get</i> might download parts but fail to produce a single playable file.


title: DISCOVERING FORMATS
content:
Before downloading, use the <b>-i</b> or <b>--info</b> option with a URL to display all available qualities and formats for a video. This helps in selecting the desired version using <b>--itag</b> or <b>--format</b>.


title: HISTORY
content:
<i>you-get</i> emerged as an open-source project primarily written in Python, initially gaining popularity for its strong support of Chinese video streaming platforms. Over time, its capabilities expanded to include a vast array of international sites, establishing it as a versatile tool for media downloading. Its development is community-driven, with ongoing contributions to adapt to changing website structures and add new features, making it a continuously evolving utility in the media downloading landscape.


title: SYNOPSIS
content:
<b>youtube-dl</b> <I>[OPTIONS]</I> <I>URL</I> [<I>URL</I>...]<br><br>This command allows users to download content from a specified URL. Multiple URLs can be provided, or a URL pointing to a playlist, which <b>youtube-dl</b> can process accordingly. Options control various aspects like format, output location, and post-processing.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print program version and exit.<br><br><b>-f, --format FORMAT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify video format code. Use '--list-formats' to see available formats.<br><br><b>-o, --output TEMPLATE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output filename template. Supports variables like '%(title)s', '%(ext)s'.<br><br><b>-a, --batch-file FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;File containing URLs to download (one URL per line).<br><br><b>-i, --ignore-errors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue on download errors, for example to skip unavailable videos in a playlist.<br><br><b>--playlist-start NUMBER</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Playlist video to start at (default is 1).<br><br><b>--playlist-end NUMBER</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Playlist video to end at (default is last).<br><br><b>--yes-playlist</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Confirm downloading entire playlist if URL points to one.<br><br><b>--no-playlist</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download only the video if the URL points to a playlist.<br><br><b>-x, --extract-audio</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Convert video files to audio-only files after downloading.<br><br><b>--audio-format FORMAT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify audio format (e.g., mp3, aac, flac). Requires --extract-audio.<br><br><b>--audio-quality QUALITY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify audio quality (0=best, 9=worst for VBR, or bitrate like 128K).<br><br><b>--embed-thumbnail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Embed thumbnail in the audio file when extracting audio.<br><br><b>--write-description</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write video description to a .description file.<br><br><b>--write-info-json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write video metadata to a .info.json file.<br><br><b>--write-thumbnail</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write thumbnail image to disk.<br><br><b>--skip-download</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not download the video; only extract information or list formats.<br><br><b>--list-formats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available formats for a video without downloading.<br><br><b>--proxy URL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specified HTTP/SOCKS proxy.<br><br><b>--rate-limit LIMIT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limit the download speed to a specific rate (e.g., 50K, 1M).<br><br><b>--no-warnings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress warning messages.<br><br><b>--geo-bypass-country CODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypass geographic restrictions via a VPN to a specific country code.<br><br><b>--download-archive FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Record and skip already downloaded videos in the given file.<br><br>


title: DESCRIPTION
content:
<b>youtube-dl</b> is a powerful, command-line program to download videos and audio from YouTube and thousands of other video hosting websites. It is cross-platform, running on Linux, macOS, and Windows, making it a versatile tool for media acquisition. Users can download individual videos, entire playlists, or specific clips based on various criteria.<br><br>Beyond simple downloading, <b>youtube-dl</b> offers extensive options for format selection, quality control, metadata extraction, and post-processing, such as converting videos to audio-only files (e.g., MP3) or embedding thumbnails. Its flexibility and broad site compatibility have made it a go-to utility for archivists, content creators, and everyday users looking to save online media for offline viewing or listening.


title: CAVEATS
content:
While <b>youtube-dl</b> is a powerful tool, users should be aware of several considerations:<br><br>1. <b>Legal and Copyright Issues:</b> Downloading copyrighted content without permission may violate terms of service or copyright laws in various jurisdictions. Users are responsible for ensuring their usage is legal.<br>2. <b>External Dependencies:</b> For many advanced features, such as merging formats, converting to audio, or embedding metadata, <b>ffmpeg</b> or <b>ffprobe</b> must be installed and accessible in your system's PATH.<br>3. <b>Site Changes:</b> Video hosting sites frequently update their structures, which can sometimes temporarily break <b>youtube-dl</b>'s ability to download from them until the tool is updated.<br>4. <b>Maintenance:</b> The original <b>youtube-dl</b> project has seen reduced maintenance in recent years. For more active development and better support for newer sites, consider using its community-maintained fork, <b>yt-dlp</b>.


title: INSTALLATION
content:
<b>youtube-dl</b> can be installed via Python's package manager <b>pip</b>: <br><code>pip install youtube-dl</code><br>or through system package managers on various Linux distributions (e.g., <code>sudo apt install youtube-dl</code> on Debian/Ubuntu). Users should ensure they have Python and pip installed.


title: POST-PROCESSING REQUIREMENTS
content:
For post-processing tasks such as merging separate video/audio streams, converting video to audio, or embedding metadata/thumbnails, <b>youtube-dl</b> relies on external tools, primarily <b><I>ffmpeg</I></b> and <b><I>ffprobe</I></b>. These tools must be installed and accessible in the system's PATH for these features to work correctly. Without them, you might be limited to downloading streams as they are presented by the source.


title: OUTPUT TEMPLATING
content:
One of <b>youtube-dl</b>'s powerful features is its output filename templating. The <code>-o</code> or <code>--output</code> option accepts a string that can include various variables extracted from the video's metadata, such as <code>%(title)s</code> (video title), <code>%(uploader)s</code> (channel name), <code>%(upload_date)s</code>, <code>%(id)s</code> (video ID), and <code>%(ext)s</code> (file extension). This allows for highly customized and organized file naming conventions for downloaded content.


title: HISTORY
content:
<b>youtube-dl</b> was initially released in 2006, making it one of the earliest and most enduring command-line tools for downloading online videos. Its open-source nature and continuous development allowed it to adapt to changes in video platforms and support an ever-growing list of websites.<br><br>The project gained significant attention in late 2020 when it faced a DMCA takedown notice from the RIAA, alleging copyright circumvention. This event sparked widespread debate about copyright and open-source software, leading to a massive community backlash and support, eventually resulting in GitHub restoring the repository.<br><br>Despite its historical significance and widespread adoption, the original <b>youtube-dl</b> project has experienced slowing development and maintenance in recent years. As a result, a highly active and feature-rich fork named <b>yt-dlp</b> emerged, which is now generally recommended for most users due to its more frequent updates and broader site support.


title: PARAMETERS
content:
<b>-s, --search <i>QUERY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for videos matching the specified query.<br><br><b>-p, --play <i>NUMBER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays the Nth video from the current search results or playlist.<br><br><b>-u, --url <i>URL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays the video from the given YouTube URL.<br><br><b>-q, --dl-quality <i>QUALITY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the download quality (e.g., 'medium', 'high', 'best').<br><br><b>-o, --order-by <i>ORDER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Orders search results by 'relevance', 'upload_date', 'view_count', 'rating'.<br><br><b>-m, --max-results <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the maximum number of search results to display.<br><br><b>--playlist-start <i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts playback from the Nth item in a playlist.<br><br><b>--no-colors</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colored output in the terminal.<br><br><b>--safe-search</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables safe search for filtered content.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays program version information and exits.<br><br>


title: DESCRIPTION
content:
<i>youtube-viewer</i> is a Linux command-line utility designed to browse, search, and play YouTube videos directly from your terminal. It offers an ncurses-based interactive interface, allowing users to navigate YouTube content without needing a web browser or graphical environment. This makes it particularly useful for remote servers, low-resource systems, or simply for users who prefer to stay within a terminal-centric workflow.<br><br>The command acts as a frontend, leveraging external tools like <b>youtube-dl</b> (or its successor, <b>yt-dlp</b>) to extract video information and stream URLs, and then piping these streams to a media player such as <b>mpv</b> for actual playback. Users can perform video searches, view search results, access video details, and initiate playback, all through text-based interactions. While it provides a convenient way to access YouTube, its functionality heavily relies on the stability of YouTube's API and the continuous updates of its backend dependencies.


title: CAVEATS
content:
<b><i>youtube-viewer</i></b> is largely considered a discontinued or unmaintained project. Due to frequent changes in YouTube's API and website structure, the command's functionality can often break without updates. Users are advised to ensure their <b>youtube-dl</b> or <b>yt-dlp</b> dependencies are up-to-date for the best chance of successful operation. It also relies heavily on external media players like <b>mpv</b> for playback, which must be installed and configured separately.


title: BACKEND OPERATION
content:
<b><i>youtube-viewer</i></b> functions primarily as an interactive frontend. When a user searches or selects a video, it internally calls <b>youtube-dl</b> (or a configured alternative like <b>yt-dlp</b>) to parse the YouTube page, extract direct video stream URLs, and retrieve metadata. Once a stream URL is obtained, it then pipes this URL to an external media player, most commonly <b>mpv</b>, for actual video and audio playback. This modular approach allows <b><i>youtube-viewer</i></b> to abstract the complexities of video fetching and playback, relying on specialized tools for those tasks.


title: HISTORY
content:
Developed as an elegant solution for terminal-based YouTube consumption, <b><i>youtube-viewer</i></b> gained popularity among power users and those working in SSH environments. Its design aimed to provide a lightweight, interactive experience for searching and playing videos without a full browser. However, the continuous evolution of YouTube's underlying technology, particularly its API and video serving mechanisms, posed a significant maintenance challenge. Keeping the project functional required constant updates to adapt to these changes. Over time, active development waned, leading to its current status as an unmaintained tool, with many users opting for direct `mpv` integration with `yt-dlp` as a more robust alternative.


title: SYNOPSIS
content:
ypbind [<b>-b</b> | <b>--broadcast</b>] [<b>-s</b> <I>server</I> | <b>--server</b> <I>server</I>] [<b>-d</b> <I>domain</I> | <b>--domain</b> <I>domain</I>] [<b>-p</b> <I>port</I> | <b>--port</b> <I>port</I>] [<b>-v</b> | <b>--version</b>] [<b>-V</b> | <b>--verbose</b>]


title: PARAMETERS
content:
<b><b>-b</b>, <b>--broadcast</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>ypbind</i> to find an NIS server by broadcasting on the local network.<br><br><b><b>-s</b> <I>server</I>, <b>--server</b> <I>server</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular NIS server to bind to, rather than broadcasting.<br><br><b><b>-d</b> <I>domain</I>, <b>--domain</b> <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the NIS domain name to which <i>ypbind</i> should attempt to bind.<br><br><b><b>-p</b> <I>port</I>, <b>--port</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a fixed port for <i>ypbind</i> to listen on, overriding dynamic port assignment.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i>ypbind</i> utility and exits.<br><br><b><b>-V</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed logging of <i>ypbind</i>'s operations.<br><br>


title: DESCRIPTION
content:
<i>ypbind</i> is the <b>Network Information Service (NIS)</b> binder daemon. Its primary function is to locate and bind a NIS client to an active <i>ypserv</i> (NIS server) on the network. When a client application requires NIS map data (e.g., user authentication or hostname resolution), it queries its local <i>ypbind</i> process. <i>ypbind</i> then broadcasts a request or queries a pre-configured server list to find a running <i>ypserv</i>. Once a server is identified, <i>ypbind</i> stores its address and port, enabling subsequent client requests to be directed efficiently. This dynamic discovery mechanism allows NIS clients to automatically connect to available NIS servers, enhancing system resilience. Typically run as a background service at system boot, <i>ypbind</i> is crucial for NIS client operations, serving as the bridge between NIS-enabled applications and the centralized directory service.


title: CAVEATS
content:
NIS (Network Information Service) is a <b>legacy protocol</b> with known security vulnerabilities, including <b>lack of encryption</b> and simple authentication. It is generally <b>not recommended for new deployments</b> over untrusted networks; alternatives like <b>LDAP</b> or <b>Kerberos</b> are preferred. <i>ypbind</i> also relies on the <i>rpcbind</i> (or <i>portmap</i>) service to be running, and its use of dynamic RPC ports can complicate firewall configurations.


title: PORT REQUIREMENTS
content:
<i>ypbind</i> registers itself with the <I>rpcbind</I> service and typically uses <b>dynamic ports</b> for its communication. NIS clients query <I>rpcbind</I> to discover the current port that <i>ypbind</i> is listening on. This dynamic port allocation, while flexible, can pose challenges when configuring network firewalls, often requiring broader port ranges to be opened.


