# CommandSection

title: PARAMETERS
content:
<b>-o <I>Field[,Field...]</I>, --options <I>Field[,Field...]</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects specific fields to display in the output. Common fields include <I>vg_name</I>, <I>vg_size</I>, <I>vg_free</I>, <I>lv_count</I>, <I>pv_count</I>.<br><br><b>--noheadings</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of column headings in the output.<br><br><b>--aligned</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces column alignment in the output, which can be useful when piping the output to other commands.<br><br><b>--units <I>Unit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the units to use for size fields (e.g., <I>b</I> for bytes, <I>k</I> for kilobytes, <I>m</I> for megabytes, <I>g</I> for gigabytes, <I>t</I> for terabytes). Defaults to human-readable units if not specified.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of messages during command execution.<br><br><b>--reportformat <I>basic|json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the output format for the report. <I>basic</I> is the default human-readable format, <I>json</I> outputs data in JSON format for programmatic use.<br><br><b><I>VolumeGroup</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name(s) of the volume group(s) for which to display information. If no volume group is specified, information for all active volume groups is shown.<br><br>


title: DESCRIPTION
content:
The <b>vgs</b> command is a crucial utility within the LVM (Logical Volume Manager) suite in Linux. It's designed to display concise information about LVM volume groups, which are a fundamental building block in LVM's storage abstraction hierarchy. <br><br>It provides a quick, tabular overview of key attributes such as the volume group's name, size, free space, number of physical volumes, and number of logical volumes. <b>vgs</b> is frequently used for system monitoring, scripting, and quickly assessing the state and capacity of LVM storage on a system. Its output can be easily customized to include specific fields, making it highly versatile for various administrative tasks.


title: CAVEATS
content:
<b>vgs</b> typically requires root privileges (or sudo) to run, especially to access detailed or sensitive LVM metadata. Output may not reflect the very latest disk changes until LVM metadata is updated (e.g., after adding/removing physical disks that are not yet known to LVM).


title: COMMON USAGE EXAMPLES
content:
<ul><li><b>vgs</b><br>Displays a default summary of all volume groups.</li><li><b>vgs MyVolumeGroup</b><br>Shows information specifically for the volume group named 'MyVolumeGroup'.</li><li><b>vgs -o vg_name,vg_size,vg_free --units g</b><br>Displays the name, total size, and free space of all volume groups, with sizes in gigabytes.</li><li><b>vgs --noheadings --options vg_name,vg_size</b><br>Outputs only the volume group name and size without headers, useful for scripting.</li></ul>


title: LVM HIERARCHY CONTEXT
content:
In LVM, storage is organized hierarchically: <br>1. <I>Physical Volumes (PVs)</I>: Raw disk partitions or whole disks. <br>2. <I>Volume Groups (VGs)</I>: Pools of PVs. <b>vgs</b> reports on these pools. <br>3. <I>Logical Volumes (LVs)</I>: Flexible partitions carved out of VGs. <br>Understanding this hierarchy is key to interpreting <b>vgs</b> output and managing LVM storage effectively.


title: HISTORY
content:
<b>vgs</b> is part of the LVM2 suite, the second generation of Logical Volume Manager for Linux, which succeeded the original LVM1. LVM2 was designed to be more robust, scalable, and feature-rich. Commands like <b>vgs</b> were developed to provide a consistent, scriptable interface for querying LVM components, complementing the more detailed, human-readable output of commands like <b>vgdisplay</b>. Its focus is on providing structured data that can be easily parsed and used in automation scripts.


title: SEE ALSO
content:
lvm(8), pvcreate(8), vgcreate(8), lvcreate(8), pvs(8), lvs(8), vgdisplay(8), pvdisplay(8), lvdisplay(8)


title: SYNOPSIS
content:
<b>vgscan</b> [<i>OPTIONS</i>] [<i>DEVICES...</i>]<br><br>Common options include:<br><b>vgscan</b> <i>--mknodes</i><br><b>vgscan</b> <i>--cache</i><br><b>vgscan</b> <i>--refresh</i><br><b>vgscan</b> <i>--verbose</i><br><b>vgscan</b> <i>--debug</i>


title: PARAMETERS
content:
<b><i>--mknodes</i>, <i>-e</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create LVM device nodes in <i>/dev</i> for discovered logical volumes.<br><br><b><i>--cache</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the LVM metadata cache file (<i>/etc/lvm/cache/.cache</i>).<br><br><b><i>--refresh</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refresh the kernel device cache and update the LVM cache. This implies <i>--cache</i>.<br><br><b><i>--verbose</i>, <i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide more detailed output during execution.<br><br><b><i>--debug</i>, <i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide extensive debug output.<br><br><b><i>--partial</i>, <i>-P</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allow processing of volume groups that are only partially available or configured.<br><br><b><i>--ignorelockingfailure</i>, <i>-K</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continue execution even if LVM locking failures occur.<br><br><b><i>--noudevsync</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not wait for udev synchronisation. Potentially faster but less robust.<br><br><b><i>--reportformat {basic|json}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for reports. Can be <i>basic</i> (default) or <i>json</i>.<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output report data in JSON format.<br><br><b><i>--columns</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display report in a column format (for <i>basic</i> report format).<br><br><b><i>--devices <PV|VG|LV></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict scanning to specific physical volumes, volume groups, or logical volumes.<br><br><b><i>--devicesfile <File></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restrict scanning to devices listed in the specified file.<br><br><b><i>--ignore-suspended-devices</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skip devices that are currently in a suspended state.<br><br><b><i>--shared</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report on LVM devices that are identified as shared (e.g., in a clustered environment).<br><br><b><i>--foreign</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report on LVM devices that are detected but do not belong to the local system ID.<br><br><b><i>--readonly</i>, <i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in a read-only mode, preventing any metadata changes.<br><br><b><i>--setautoactivation {y|n}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set or clear the autoactivation flag on volume groups during the scan.<br><br><b><i>--commandprofile <ProfileName></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specified command profile for configuration.<br><br><b><i>--config <ConfigurationFile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific LVM configuration file instead of the default.<br><br><b><i>--driverloaded {y|n}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indicate whether the LVM kernel driver is loaded (used by LVM scripts).<br><br><b><i>--longnames</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display full, long names for LVM components.<br><br><b><i>--lockopt <LockOptions></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass specific options to the locking module.<br><br><b><i>--systemid <SystemID></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the system ID for filtering or processing volume groups.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the LVM version information.<br><br><b><i>--select <SelectionString></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select objects for processing based on specific criteria.<br><br>


title: DESCRIPTION
content:
<b>vgscan</b> is an essential LVM (Logical Volume Manager) command used to scan all block devices on a system for LVM physical volumes and volume groups. Upon finding LVM metadata, it rebuilds and updates the LVM cache file, typically located at <i>/etc/lvm/cache/.cache</i>. This cache is crucial for other LVM commands to quickly identify and manage LVM components without rescanning every device. It also populates the <i>/dev</i> directory with the necessary device nodes for LVM components if they are not already present or if the <i>--mknodes</i> option is used (though often handled by udev).<br><br>This command is frequently executed during system boot to discover LVM volumes, after adding new disks, or during recovery operations when LVM metadata might be inconsistent or lost. It helps ensure that the LVM infrastructure is correctly recognized and ready for further operations like activating volume groups with <b>vgchange</b> or listing logical volumes with <b>lvscan</b>.


title: CAVEATS
content:
<b>vgscan</b> requires root privileges to scan system block devices and update LVM metadata.<br><br>While it scans for LVM components, it does <i>not</i> activate volume groups; this task is performed by the <b>vgchange</b> command.<br><br>On systems with a large number of disks or complex LVM setups, <b>vgscan</b> can take a significant amount of time to complete.<br><br>In modern Linux distributions, device node creation is typically handled by udev; however, the <i>--mknodes</i> option can be used to force creation if needed, particularly in environments without a fully functional udev.


title: METADATA CACHE AND BACKUP
content:
<b>vgscan</b> primarily updates the LVM metadata cache, usually at <i>/etc/lvm/cache/.cache</i>, which speeds up subsequent LVM operations. It also implicitly interacts with metadata backups stored in <i>/etc/lvm/backup</i> and <i>/etc/lvm/archive</i> directories for recovery purposes.


title: UDEV INTEGRATION
content:
In modern Linux systems, <b>vgscan</b> works closely with udev. Udev automatically creates and manages device nodes in <i>/dev</i> based on kernel events and LVM's udev rules, often making the explicit use of <i>--mknodes</i> unnecessary. <b>vgscan</b> ensures LVM's view of devices aligns with the kernel's and udev's.


title: HISTORY
content:
LVM (Logical Volume Manager) was originally developed for Linux by Heinz Mauelshagen, with LVM1 first released in 1999. <b>vgscan</b> has been a core component since its inception, essential for discovering and managing LVM structures. The more robust LVM2, released in 2002, brought significant improvements in scalability, performance, and metadata handling, where <b>vgscan</b> continued its critical role in scanning and rebuilding the LVM metadata cache. Its functionality has remained largely consistent, adapting to modern kernel and udev integrations to ensure reliable device discovery.


title: PARAMETERS
content:
<b>OldVGName</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the <b>existing Volume Group</b> that will be split. This VG will retain any Logical Volumes not explicitly moved to the new VG.<br><br><b>NewVGName</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name for the <b>new Volume Group</b> that will be created. The specified Logical Volumes and their associated Physical Volumes will be moved into this new VG.<br><br><b>LV_Path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more <b>full paths to Logical Volumes</b> (e.g., <i>/dev/OriginalVG/my_lv</i>) that will be moved from <i>OldVGName</i> to <i>NewVGName</i>. If multiple LVs are to be moved, list them separated by spaces.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation, bypassing some interactive confirmations or sanity checks. Use with caution.<br><br><b>-t, --test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the command in <b>test mode</b>. It simulates the split operation without making any actual changes to the Volume Groups or data, displaying what <i>would</i> happen.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides <b>more detailed output</b> during the command's execution, showing steps and status.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages, showing only critical errors.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a <b>help message</b> and exits.<br><br>


title: DESCRIPTION
content:
<i>vgsplit</i> is a powerful LVM2 command used to reorganize storage by dividing a single existing Volume Group (VG) into two distinct new VGs. When executed, it transfers a specified set of Logical Volumes (LVs) from the <i>OriginalVG</i> to a <i>NewVGName</i>. The <i>OriginalVG</i> retains its name and keeps all LVs not explicitly moved. Simultaneously, a new Volume Group is created with the <i>NewVGName</i>, inheriting the specified LVs and their underlying Physical Volumes (PVs). This operation is atomic and ensures data integrity, as LVs are moved by updating LVM metadata rather than copying data blocks. It's an essential tool for re-structuring storage for administrative separation, performance isolation, or preparing for migration, allowing administrators to logically separate workloads or departments into their own volume groups without disrupting existing data.


title: CAVEATS
content:
<b>Data Integrity:</b> While <i>vgsplit</i> updates LVM metadata without data loss, it's best practice to unmount any filesystems residing on the LVs to be moved and deactivate them before running the command to prevent data corruption during active I/O.<br><b>PV Association:</b> Physical Volumes (PVs) that contain extents belonging to the moved Logical Volumes will automatically be reassigned to the <i>NewVGName</i>. PVs are not themselves "split"; their association is updated based on the LVs they host.<br><b>Root VG:</b> Splitting the Volume Group that contains your root filesystem is highly risky and generally not recommended without a comprehensive understanding of LVM and system boot processes.<br><b>Post-Split Actions:</b> After a successful split, the new Volume Group (<i>NewVGName</i>) might need to be explicitly activated using <i>vgchange -ay NewVGName</i>. Filesystems on the moved LVs will also require updates to their mount points in <i>/etc/fstab</i> to reflect the new VG name.


title: HOW <I>VGSPLIT</I> WORKS
content:
When <i>vgsplit</i> is executed, it meticulously updates the LVM metadata on the involved Physical Volumes. It identifies the Physical Extents (PEs) that belong to the specified Logical Volumes (LVs) to be moved. These PEs, along with their associated LVs, are then logically transferred from the metadata of the <i>OriginalVGName</i> to the newly created <i>NewVGName</i>. The command ensures that the mapping from LVs to PEs remains consistent. It's a metadata-only operation for the LVs themselves; the actual data blocks on disk are not moved or copied, which makes the operation very fast and minimizes the risk of data loss compared to block-level migrations.


title: COMMON USE CASES
content:
<i>vgsplit</i> is particularly useful in scenarios where a single large Volume Group has grown to encompass diverse workloads or departments, and a clearer separation is desired for administrative, security, or performance reasons. For example, an administrator might split a VG to: isolate production LVs from development LVs; move specific database LVs to a dedicated VG for better management; or prepare a subset of LVs and their PVs for migration to a different storage system by first creating a standalone VG.


title: HISTORY
content:
The <i>vgsplit</i> command is an integral part of the <b>LVM2 (Logical Volume Manager version 2)</b> suite of utilities for Linux. LVM2 was a significant re-architecture of the original LVM, introduced to provide greater scalability, flexibility, and robustness for managing storage. While LVM has been a core component of Linux storage for decades, <i>vgsplit</i> specifically emerged in the LVM2 context to provide a dedicated, atomic operation for reorganizing Volume Groups. Prior to such a command, achieving a similar separation of LVs would often involve more manual steps, such as creating new VGs, moving Physical Extents with <i>pvmove</i>, and then re-creating or re-assigning Logical Volumes, which was more complex and prone to error. <i>vgsplit</i> streamlines this advanced storage reorganization task.


title: SYNOPSIS
content:
<b>vhs</b> <I>tapefile</I><br><b>vhs</b> build <I>tapefile</I> [<I>options</I>]<br><b>vhs</b> test <I>tapefile</I><br><b>vhs</b> validate <I>tapefile</I><br><b>vhs</b> version


title: PARAMETERS
content:
<b>-o, --output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output GIF, MP4, or WebM file. If not specified, a temporary file is used.<br><br><b>-f, --frame-rate <fps></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the frame rate (frames per second) for the output video or GIF. Higher values result in smoother animations.<br><br><b>-p, --padding <value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds padding (in pixels) around the terminal content within the output. Can be a single value (for all sides) or four values (top, right, bottom, left).<br><br><b>--no-cursor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the blinking cursor in the recorded terminal output.<br><br><b>--no-optimize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents GIF palette optimization, which can result in larger file sizes but may preserve more color fidelity.<br><br><b>--no-compositor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the use of a compositor during rendering, which might improve performance on some systems or for specific use cases.<br><br><b>--shell <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the shell executable to use for the terminal sessions (e.g., <i>/bin/bash</i>, <i>/usr/bin/zsh</i>). Defaults to your system's default shell.<br><br><b>--config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a path to a custom configuration file for <b>vhs</b> settings, overriding default behaviors.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging, which is useful for troubleshooting issues with the recording or rendering process.<br><br>


title: DESCRIPTION
content:
<b>vhs</b> (or "VHS") is a modern command-line tool designed for recording and rendering terminal sessions into high-quality animated GIFs, MP4, or WebM videos. It operates by interpreting a <i>Tapefile</i>, which is a simple, declarative scripting language that defines a sequence of terminal actions, such as typing commands, setting delays, resizing the terminal, and applying visual themes. Internally, <b>vhs</b> leverages a headless browser to simulate the terminal environment, capture frames, and then utilizes external tools like FFmpeg for efficient video and GIF encoding. Its primary goal is to empower developers and content creators to produce visually appealing and easily shareable demonstrations of command-line interfaces or code execution.


title: CAVEATS
content:
<b>vhs</b> is not a standard Linux utility and must be installed separately (typically via Go). It requires a Go runtime environment and often depends on external tools like <i>ffmpeg</i> for video encoding. The rendering process can be resource-intensive, especially for long or high-resolution recordings, and may require sufficient CPU and RAM. It relies on a custom <i>Tapefile</i> syntax, which requires learning a new scripting language for defining terminal actions.


title: TAPEFILE SCRIPTING
content:
The core functionality of <b>vhs</b> is driven by a <i>Tapefile</i>, a simple text file containing a sequence of declarative commands. These commands include <i>Output</i> (to specify the output file), <i>Set</i> (to configure global options like theme, font size, or dimensions), and actions like <i>Type</i> (to simulate typing), <i>Sleep</i> (to pause execution), <i>Enter</i>, <i>Backspace</i>, and various key presses (e.g., <i>Ctrl+C</i>). This scripting approach allows for precise control over the recording process, ensuring consistent and reproducible demonstrations.


title: OUTPUT FORMATS
content:
Beyond animated GIFs, <b>vhs</b> supports generating MP4 and WebM video formats, offering flexibility for different use cases. MP4 and WebM generally provide better compression and quality for longer recordings compared to GIFs, making them suitable for more extensive demonstrations or web embedding.


title: HISTORY
content:
Developed by <I>Charmbracelet</I>, a team renowned for creating elegant and powerful command-line tools (e.g., <i>Glow</i>, <i>Bubble Tea</i>), <b>vhs</b> emerged as a modern, open-source solution for terminal recording. Its development leverages Go, a language well-suited for building performant CLI applications, and integrates with headless browser technologies to achieve high-fidelity visual output. It gained popularity for its ease of use in creating polished demonstrations for documentation, tutorials, and presentations, quickly becoming a go-to tool for CLI content creation.


title: SYNOPSIS
content:
<b>vi</b> [<i>options</i>] [<i>file ...</i>]<br>The <b>vi</b> command starts the visual editor. If <i>file</i> arguments are provided, <b>vi</b> opens them for editing. If no files are specified, <b>vi</b> opens an empty buffer.


title: PARAMETERS
content:
<b><i>-r file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recovers <i>file</i> after a system crash, attempting to restore unsaved changes.<br><br><b><i>-R</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the file in read-only mode, preventing accidental writes and protecting the file.<br><br><b><i>-c command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> (an <b>ex</b> command) immediately upon starting <b>vi</b>, useful for initial setup.<br><br><b><i>-t tag</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Jumps to the specified <i>tag</i> (defined in a tags file, usually generated by <b>ctags</b>) within the appropriate file.<br><br><b><i>-s script</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the <b>ex</b> <i>script</i> commands from the specified file after starting, useful for automation.<br><br>


title: DESCRIPTION
content:
<b>vi</b> (<i>visual editor</i>) is a screen-oriented text editor originally created for the Unix operating system. Developed by Bill Joy in 1976 for an ADM-3A terminal, it was built upon the <b>ex</b> line editor, which itself was based on <b>ed</b>. Unlike contemporary editors that operate in a single mode, <b>vi</b> is famous for its <i>modal editing</i> paradigm, primarily distinguishing between <i>command mode</i> and <i>insert mode</i>.<br><br>In command mode, keystrokes are interpreted as commands (e.g., for navigation, deletion, copying); in insert mode, they are interpreted as text to be inserted into the document. This design allows for highly efficient text manipulation once mastered, as users can perform complex operations with minimal keystrokes without needing to use a mouse. <b>vi</b> became a standard component of all Unix and Unix-like systems, including Linux, making it an essential tool for system administrators and developers due to its availability even in minimal environments, its speed, and its low resource footprint. While its learning curve is steep, its power and ubiquity ensure its continued relevance.


title: CAVEATS
content:
<b>vi</b> has a notably steep learning curve due to its unique modal interface, which can be confusing for beginners accustomed to single-mode editors. Users must constantly switch between command and insert modes, which requires memorizing a significant number of commands. Its text-based interface lacks graphical elements like menus or scrollbars, making navigation and operation less intuitive without prior knowledge. Original <b>vi</b> implementations also offered limited undo capabilities compared to modern editors, and its command syntax can be very terse and cryptic.


title: MODES OF OPERATION
content:
<b>vi</b> primarily operates in three distinct modes:<br><b><i>Command Mode:</i></b> The default mode upon opening <b>vi</b>. Keystrokes are interpreted as commands for navigation, deletion, copying, pasting, and other operations. You return to this mode by pressing the <i><kbd>Esc</kbd></i> key.<br><b><i>Insert Mode:</i></b> Entered by commands like <i>i</i> (insert), <i>a</i> (append), <i>o</i> (open new line), or <i>R</i> (replace). Keystrokes are inserted directly into the text buffer as content. All text input occurs in this mode.<br><b><i>Last-Line / Ex Mode:</i></b> Entered by typing <i>:</i> (colon) or <i>/</i> (forward slash) from command mode. This allows executing <b>ex</b> commands (e.g., saving, quitting, search/replace, executing shell commands) which are typed at the bottom of the screen.


title: BASIC NAVIGATION AND EDITING
content:
Fundamental <b>vi</b> commands, executed from command mode, include:<br><b><i>hjkl:</i></b> (left, down, up, right) for cursor movement.<br><b><i>i, a, o:</i></b> (insert, append, open) to enter insert mode.<br><b><i>x:</i></b> delete character under cursor.<br><b><i>dd:</i></b> delete current line.<br><b><i>yy:</i></b> yank (copy) current line.<br><b><i>p:</i></b> put (paste) after cursor/line.<br><b><i>:/pattern:</i></b> search forward for a pattern.<br><b><i>:w:</i></b> write (save) changes.<br><b><i>:q:</i></b> quit.<br><b><i>:wq or ZZ:</i></b> save and quit.


title: HISTORY
content:
<b>vi</b> was created by Bill Joy at the University of California, Berkeley, in the late 1970s as the visual interface for the <b>ex</b> line editor. It quickly became part of the BSD Unix distribution. Its efficiency, low resource usage, and the ability to work over slow terminal connections made it indispensable in the early days of Unix. While many modern alternatives exist, <b>vi</b>'s core design principles and ubiquity across Unix-like systems ensure its continued relevance, especially in system administration, scripting, and embedded environments where full-featured editors like <b>vim</b> might not be available. Its influence is seen in numerous text editors that incorporate <b>vi</b>-like key bindings and modes.


title: PARAMETERS
content:
<b>-</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads a list of file paths from standard input or command line arguments instead of scanning a directory. This allows <i>vidir</i> to operate on a custom set of files.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the commands that would be executed without actually performing any file system modifications. This is highly recommended for reviewing changes before committing them.<br><br><b>--no-sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables fsyncing of the temporary file before opening the editor. This is generally not recommended as it might lead to data loss if the system crashes before the editor flushes its changes, but can offer minor performance gains on some systems.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise help message detailing usage and options, then exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information for <i>vidir</i> and exits.<br><br>


title: DESCRIPTION
content:
<i>vidir</i> is a powerful utility that allows you to manage files and directories by editing their names and structure directly within your preferred text editor. When invoked, it generates a temporary file containing a list of all items (files and subdirectories) in the specified directory, or the current directory if none is given.<br><br>This list is then opened in your <b>EDITOR</b> (or <b>VISUAL</b>) environment variable's assigned editor. You can rename files by changing their names, delete files by removing their lines, and even reorder them (though reordering doesn't directly affect the filesystem, it can help organize your editing task). Upon saving and exiting the editor, <i>vidir</i> parses the modified list and performs the necessary file operations (renames, deletions, or creations for new directories), providing a batch-like interface for filesystem manipulation. It's especially useful for renaming many files consistently or performing complex cleanup tasks interactively.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br><i>vidir</i> requires a text editor to be defined in the <b>EDITOR</b> or <b>VISUAL</b> environment variables; otherwise, it will fall back to a default like <i>vi</i>.<br>Changes are applied irreversibly upon saving and exiting the editor, unless the <b>--dry-run</b> option is used. Exercise caution.<br>Deleting a line in the editor will result in the corresponding file or directory being deleted on the filesystem.<br>While you can rename files to include new directory components (e.g., 'file.txt' to 'newdir/file.txt'), directly moving files between *existing* distinct subdirectories by changing their paths in the editor is not supported, as <i>vidir</i> primarily operates on the context of its initial directory scan.


title: ENVIRONMENT VARIABLES
content:
<i>vidir</i> heavily relies on the <b>EDITOR</b> or <b>VISUAL</b> environment variables to determine which text editor to open. If neither is set, it typically defaults to <i>vi</i>. Setting these variables to your preferred editor (e.g., <I>export EDITOR=nano</I> or <I>export VISUAL=code --wait</I>) is crucial for <i>vidir</i> to function as expected with your workflow.


title: BATCH OPERATIONS
content:
One of <i>vidir</i>'s most significant strengths is its ability to facilitate batch operations. Instead of executing multiple <i>mv</i>, <i>rm</i>, or <i>mkdir</i> commands individually, you can consolidate all your changes into a single editing session. This allows for a visual review of all intended modifications before applying them instantly, significantly reducing the chance of errors in repetitive or complex file management tasks.


title: HISTORY
content:
<i>vidir</i> is a prominent utility within the <b>moreutils</b> package, a collection of small, yet powerful and useful Unix utilities. It was created by Joey Hess, the package's maintainer, with the aim of providing an intuitive and interactive way to manage files and directories that goes beyond typical command-line tools. Its development continues as part of the <b>moreutils</b> project, ensuring its adaptability and relevance in modern Linux environments.


title: PARAMETERS
content:
<b><i>file ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more files to be opened in read-only mode. If multiple files are specified, <b>view</b> will open them in separate buffers.<br><br><b><b>-c</b> <i>{command}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <i>command</i> immediately after the first file is loaded. This is useful for jumping to a specific line (e.g., <b>view -c '100' myfile.txt</b> to go to line 100) or performing a search on startup.<br><br><b><b>+</b><i>{num}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts editing at the line number <i>num</i>. Equivalent to <b>-c '{num}'</b>.<br><br><b><b>-S</b> <i>{scriptfile}</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sources the commands from <i>scriptfile</i> after loading the first file. This allows for automated setup or viewing operations.<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly sets read-only mode. While <b>view</b> implicitly does this, this option is generally associated with <b>vi</b>/<b>vim</b> and is the mechanism <b>view</b> uses.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of command-line options and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>view</b> command is a specialized invocation of the <b>vi</b> or <b>vim</b> text editor, designed specifically for read-only file viewing. Its primary purpose is to allow users to inspect the contents of a file without the risk of accidentally making or saving modifications. When invoked, <b>view</b> automatically sets the <i>'readonly'</i> option within the editor, preventing write operations unless explicitly overridden (e.g., using <i>:w!</i>).<br><br>This command is particularly useful for examining configuration files, log files, or source code where no changes are intended. It provides all the powerful navigation, searching, and syntax highlighting features of <b>vi</b> or <b>vim</b>, but with an added layer of safety. While <b>view</b> might appear to be a separate utility, it is often a symbolic link to <b>vi</b> or <b>vim</b> with the <i>-R</i> (read-only) option enabled by default, making it a convenient shortcut for secure file inspection.


title: CAVEATS
content:
Although <b>view</b> enables read-only mode, it is not foolproof. A determined user can still force a write operation using commands like <i>:w!</i> (write forcefully) or by disabling the <i>'readonly'</i> option (<i>:set noro</i>) from within the editor. Its primary purpose is to prevent accidental modifications, not to enforce strict access control. The exact behavior and available options of <b>view</b> are dependent on the underlying <b>vi</b> or <b>vim</b> installation it links to.


title: EXITING READ-ONLY MODE (INTERNALLY)
content:
While <b>view</b> enforces read-only by default, it's possible to override this from within the editor. To save changes (if any were made despite the warning), you can use <i>:w!</i>. To completely disable the read-only flag for the current buffer, type <i>:set noro</i> and press Enter. This will allow normal write operations without force-writing. Conversely, <i>:set ro</i> will re-enable read-only mode.


title: VISUAL CONFIRMATION OF READ-ONLY
content:
When a file is opened with <b>view</b> (or <b>vi -R</b>), <b>vim</b> typically indicates the read-only status in the status line at the bottom of the screen, often showing <i>[RO]</i> or <i>[readonly]</i> next to the filename. This provides a clear visual cue to the user that modifications are restricted.


title: HISTORY
content:
The <b>view</b> command emerged as a convenient wrapper around the <b>vi</b> (Visual editor) and later <b>vim</b> (Vi IMproved) text editors. <b>vi</b> itself originated in the late 1970s, based on the <b>ex</b> line editor. As text editors evolved, the need for a simple, safe way to view files without risk of modification became apparent. Rather than creating a separate viewing utility with an entirely different interface, it was more practical to leverage the existing, powerful features of <b>vi</b>/<b>vim</b> and simply default to read-only mode. Thus, <b>view</b> was implemented, often as a symbolic link to <b>vi</b> or <b>vim</b> with the <i>-R</i> (read-only) flag automatically set, providing a familiar interface for secure file inspection.


title: PARAMETERS
content:
<b>-s, --slideshow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Viewnior in slideshow mode. If multiple files are given, it cycles through them.<br><br><b>-f, --fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts Viewnior in fullscreen mode, occupying the entire screen.<br><br><b>-c, --copy</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Copies the specified image to the clipboard and exits immediately.<br><br><b>-p, --print</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the specified image to the default printer and exits immediately.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message showing all available command-line options and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the Viewnior application version information and exits.<br><br><b>FILE...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to image files. Viewnior will open the first specified file and allow navigation through others if multiple are provided or if they are in the same directory.<br><br>


title: DESCRIPTION
content:
Viewnior is a minimalist and lightweight image viewer for the GTK+ desktop environment, designed for speed and simplicity. It offers a clean user interface, focusing on displaying images without unnecessary clutter. Beyond basic viewing, Viewnior provides essential image manipulation features such as rotating, flipping, and cropping images. Users can navigate through images in a folder, start slideshows, view images in fullscreen, and perform actions like copying an image to the clipboard or printing it directly from the application. Its efficiency makes it a good choice for systems where resources are a concern, or for users who prefer a straightforward viewing experience over a feature-rich image editor.


title: CAVEATS
content:
Viewnior is primarily a viewer with basic manipulation capabilities. It does not offer advanced image editing features like layers, filters, or complex adjustments found in more comprehensive graphic software. Its development has seen varying levels of activity, but it remains a functional and stable choice for its intended purpose.


title: IMAGE FORMATS
content:
Viewnior supports a wide range of common image formats, including JPEG, PNG, GIF, TIFF, WebP, and BMP, among others. This broad compatibility is achieved through its reliance on the GDK-Pixbuf library, which handles various image decoding tasks.


title: KEYBOARD SHORTCUTS
content:
Viewnior offers numerous keyboard shortcuts to enhance user efficiency. Common shortcuts include: <br><i>Arrow Keys</i> for navigating between images.<br><i>F</i> for toggling fullscreen mode.<br><i>S</i> for starting/stopping a slideshow.<br><i>Esc</i> to exit fullscreen or slideshow modes.<br><i>R</i> for rotating the image.


title: HISTORY
content:
Viewnior emerged as a fast and simple alternative to more complex image viewers in the Linux ecosystem, particularly catering to users seeking a lightweight GTK-based application. Its development has focused on providing core image viewing functionalities with a clean interface, making it a popular choice for default image viewing in many minimalist desktop setups. It was designed to be quick to launch and responsive, a key differentiator from some other viewers that might have a larger footprint or longer startup times.


title: PARAMETERS
content:
<b><i>-all</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes all specified resource files and the <i>RESOURCE_MANAGER</i> property when displaying resources, providing a comprehensive view.<br><br><b><i>-top</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays resources specifically for the top-level application shell, useful for debugging root application resources or global settings.<br><br><b><i>-variable</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only the variable part of resource specifications (e.g., <i>*background</i> instead of <i>xterm.background</i>), simplifying the display for pattern-based resources.<br><br><b><i>-override</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prioritizes the display of overridden resources, highlighting how specific settings might be taking precedence over general ones.<br><br><b><i>-v</i>, <i>-verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing additional diagnostic information and progress messages during execution, typically sent to standard error.<br><br><b><i>-s</i>, <i>-standard</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes standard X Toolkit resources in the display, in addition to application-specific ones, offering a complete picture of all resolved resources.<br><br><b><i>-width <pixels></i>, <i>-height <pixels></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial width and height of the <i>viewres</i> window in pixels, controlling its initial size on the screen.<br><br><b><i>-x <pixels></i>, <i>-y <pixels></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial X and Y position of the <i>viewres</i> window on the screen, defining its starting location.<br><br><b><i>resourcefile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional path to a file containing additional X resource specifications. These resources are loaded and displayed alongside the standard ones.<br><br><b><i>-toolkitoption ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Represents common X Toolkit command-line options such as <i>-display</i>, <i>-geometry</i>, <i>-bg</i> (background), <i>-fg</i> (foreground), and <i>-xrm</i> (specify resource string). These options configure the graphical environment or provide additional resource settings directly.<br><br>


title: DESCRIPTION
content:
<i>viewres</i> is an X Toolkit utility designed to graphically display the resource specifications that Xt (the X Toolkit Intrinsics) would use for a given class hierarchy. It serves as a crucial tool for developers and advanced users to understand how X resources are loaded, merged, and applied to X applications. The utility can show resources originating from various sources, including application defaults files, the <i>RESOURCE_MANAGER</i> property on the root window, and user-specific resource files like <i>.Xdefaults</i>. By providing a hierarchical view, <i>viewres</i> is particularly useful for debugging resource conflicts, allowing you to visually inspect the exact resource values Xt would resolve for widgets and application components, including intricate inheritance and override mechanisms. Its graphical interface facilitates navigation through the resource tree and inspection of individual resource values, making the complex X resource system more transparent.


title: CAVEATS
content:
<i>viewres</i> is an X11 application and requires a running X server to function. It is primarily a debugging and development tool for X Toolkit applications, not typically intended for general end-user daily tasks. While it visualizes resource resolution, it doesn't solve all potential resource-related issues, especially those stemming from application-specific code that might bypass or override Xt's resource manager. Its graphical interface is functional but reflects an older aesthetic.


title: RESOURCE PRECEDENCE AND RESOLUTION
content:
The X resource manager resolves resources from multiple sources in a specific order of precedence: application defaults, the <i>RESOURCE_MANAGER</i> property (managed by <i>xrdb</i>), <i>.Xdefaults</i> files, and command-line options. <i>viewres</i> helps visualize this complex hierarchy, showing which resource values are ultimately applied after all merging and overriding rules have been evaluated. This is invaluable for understanding why a particular widget might not be adopting the expected color, font, or other attributes.


title: DEBUGGING X APPLICATIONS
content:
For developers and system administrators, <i>viewres</i> is an essential debugging tool. It allows for quick identification of resource conflicts, typos in resource specifications, or issues with resource loading paths. By providing an interactive tree view of resolved resources, it simplifies the process of diagnosing unexpected visual behaviors or configuration problems in X Toolkit-based applications, saving significant time compared to manual inspection of configuration files.


title: HISTORY
content:
<i>viewres</i> has been a component of the X Window System utilities since its early development. It emerged alongside the X Toolkit Intrinsics (Xt) library, serving its core purpose of visualizing the X resource management system—a fundamental aspect of X11 application configuration. While it doesn't see active feature development in modern times, it remains a stable and maintained utility within the X.Org distribution, crucial for understanding legacy X Toolkit applications.


title: PARAMETERS
content:
<b>-c <i><command></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute <i>command</i> after startup.<br><br><b>-f <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read filenames from <i>file</i> and select them in visual mode.<br><br><b>-i <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Import list of files from <i>file</i> to current directory view.<br><br><b>-o <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write selected file paths to <i>file</i> on exit.<br><br><b>-O <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write selected file paths to <i>file</i> and quit immediately.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start in diff mode to compare two directories.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start in view mode (single pane).<br><br><b>--select-from <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read files from <i>file</i> and select them.<br><br><b>--choose-dir</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the chosen directory path to stdout and exit.<br><br><b>--choose-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print selected file paths to stdout and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><i><path>...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initial directory paths to open.<br><br>


title: DESCRIPTION
content:
<i>vifm</i> is a powerful, curses-based file manager that brings the efficiency and modal editing paradigm of the <i>Vim</i> text editor to file management in your terminal. It features a dual-pane interface, enabling seamless navigation and manipulation of files and directories.<br><br>Users familiar with <i>Vim</i> will find its keyboard-centric workflow, including Normal, Visual, and Command-line modes, highly intuitive. <i>vifm</i> offers robust capabilities such as file and directory comparisons (diff mode), extensive file filtering, customizable file associations, and the ability to execute external commands directly on selected items.<br><br>Designed for speed and productivity, it allows for deep customization through its configuration files, making it a preferred choice for power users who prioritize keyboard control and an efficient, scriptable environment for managing their filesystem.


title: CAVEATS
content:
Due to its <i>Vim</i>-like nature, <i>vifm</i> has a steep learning curve for users unfamiliar with modal editing. It is primarily keyboard-driven, with minimal mouse support. Extensive customization requires editing text configuration files, which can be complex.


title: CONFIGURATION FILES
content:
<i>vifm</i> is highly configurable through files like <i>vifmrc</i> (main configuration) and <i>vifminfo</i> (session information), typically located in <i>~/.config/vifm/</i> or <i>~/.vifm/</i>. These files allow for extensive customization of keybindings, commands, filetype associations, and more.


title: VIM-LIKE MODES
content:
Similar to <i>Vim</i>, <i>vifm</i> operates in distinct modes:<br><b>Normal mode</b>: For navigation and basic file operations.<br><b>Visual mode</b>: For selecting files and applying actions to multiple items.<br><b>Command-line mode</b>: For executing commands, searching, and filtering.


title: HISTORY
content:
<i>vifm</i> development began around 2008-2009 by Xie Qiang, driven by the desire for a powerful, keyboard-driven file manager for Unix-like systems, emulating the efficient workflow of the <i>Vim</i> text editor. It has since seen continuous active development by various contributors, solidifying its position as a robust tool for power users.


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;Displays version information and exits.<br><br><b>--root <i>CHROOT_DIR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies changes within the specified <i>CHROOT_DIR</i> directory, allowing operation on group files in a chroot environment.<br><br>


title: DESCRIPTION
content:
The <b>vigr</b> command provides a secure and robust method for editing the system's group database files, specifically <i>/etc/group</i> and <i>/etc/gshadow</i>.<br><br>It operates by first locking these critical files to prevent simultaneous modifications and data corruption. Subsequently, it creates temporary copies of the files, which are then opened in the user's preferred text editor (defaulting to <i>vi</i> or the editor specified by the <i>EDITOR</i> or <i>VISUAL</i> environment variables).<br><br>After the user completes editing and saves the temporary files, <b>vigr</b> performs essential syntax checks on the modified content to ensure validity. If these checks pass, the temporary files atomically replace the original system files, and the locks are released. This meticulous process guarantees that the group database remains consistent, valid, and uncorrupted, which is vital for system security and user management. Use of <b>vigr</b> requires superuser (root) privileges.


title: CAVEATS
content:
Editing system configuration files directly without proper tools like <b>vigr</b> can lead to severe system instability or security vulnerabilities.<br><br>Incorrect syntax or invalid entries introduced during editing can render the group database unusable, potentially preventing users from logging in or causing other system failures.<br><br>Always exercise extreme caution and ensure you understand the changes being made. Requires root privileges to execute.


title: EDITOR PREFERENCE
content:
<b>vigr</b> respects the <i>EDITOR</i> or <i>VISUAL</i> environment variables to determine which text editor to launch. If neither of these variables is set, it defaults to using <i>vi</i> for editing the files.


title: ATOMIC OPERATIONS AND SAFETY
content:
The command ensures atomicity by implementing a robust file locking mechanism and utilizing temporary files for editing. This prevents race conditions and ensures that either the entire set of changes is successfully applied, or none at all, thus maintaining the integrity of the group database even in the event of system crashes or power failures.


title: SYNTAX VALIDATION
content:
Before committing changes from the temporary files back to the original system files, <b>vigr</b> performs essential syntax checks. This validation step helps to catch common errors or malformed entries that could potentially corrupt the group database or make it unreadable by other system utilities.


title: HISTORY
content:
The <b>vigr</b> command is an integral part of the <i>shadow-utils</i> suite, which originated from the need to enhance the security of Unix-like systems. This suite was developed to separate sensitive password hashes into a restricted-access <i>/etc/shadow</i> file and group password hashes into <i>/etc/gshadow</i>.<br><br><b>vigr</b> was specifically created as the safe editing utility for these group-related files, mirroring the functionality of <b>vipw</b> for password files. Its design principle emphasizes atomicity, data integrity, and validation when modifying critical system configuration files, reflecting best practices for system administration.


title: SEE ALSO
content:
vipw(8), group(5), gshadow(5), groupadd(8), groupmod(8), groupdel(8), grpck(8), passwd(5), shadow(5)


title: SYNOPSIS
content:
<b>tslint</b> [<I>options</I>] [<I>files...</I>]<br><b>tslint</b> --init<br><b>tslint</b> --test <I>rules-directory</I>


title: PARAMETERS
content:
<b><b>-c</b>, <b>--config</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a <i>tslint.json</i> configuration file. If not provided, <b>tslint</b> will search for one in the current directory or parent directories.<br><br><b><b>-p</b>, <b>--project</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a <i>tsconfig.json</i> file. When used, <b>tslint</b> will lint all files included in the TypeScript project.<br><br><b><b>-t</b>, <b>--format</b> <I>formatter</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output format for linting results. Common formatters include <i>stylish</i>, <i>json</i>, <i>pmd</i>, and <i>msbuild</i>.<br><br><b><b>-r</b>, <b>--rules-dir</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a directory containing custom linting rules. These rules are loaded in addition to those defined in the configuration file.<br><br><b><b>-e</b>, <b>--exclude</b> <I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes files or directories matching the provided glob pattern from linting. Can be specified multiple times.<br><br><b><b>--fix</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to automatically fix linting errors where possible. Not all rules support auto-fixing.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <b>tslint</b> to exit with a 0 status code even if linting errors are found. Useful in CI/CD environments where a non-zero exit code might halt the build.<br><br><b><b>--init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a default <i>tslint.json</i> configuration file in the current directory, providing a starting point for rule configuration.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of <b>tslint</b>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and a list of available options.<br><br>


title: DESCRIPTION
content:
The <b>tslint</b> command is a static analysis tool used to check TypeScript code for readability, maintainability, and functional errors. It helps enforce a consistent coding style and best practices across a codebase, identifying potential issues before runtime. Users typically define coding rules in a <i>tslint.json</i> configuration file, which the tool then applies to specified TypeScript files or projects.<br><br>While powerful, <b>tslint</b> has been officially deprecated by its creators, Palantir, in favor of ESLint with TypeScript support. This transition was driven by ESLint's broader adoption in the JavaScript ecosystem and its more flexible plugin architecture. Although still functional for existing projects, new TypeScript projects are strongly advised to adopt ESLint.


title: CAVEATS
content:
<b>tslint</b> has been officially deprecated by its creators since 2019. While it remains functional for existing projects, active development has ceased, and no new features or rule updates are being provided.<br><br>For new TypeScript projects, migrating to ESLint with the <i>typescript-eslint</i> parser and plugins is the recommended approach, as it offers a more robust and actively maintained linting solution for TypeScript.


title: CONFIGURATION FILES
content:
<b>tslint</b> relies heavily on a <i>tslint.json</i> file to define its linting rules and configurations. This JSON file specifies which rules are enabled, their severity (e.g., <i>warning</i>, <i>error</i>), and any specific options for those rules. It can extend configurations from other shared <i>tslint.json</i> files and include or exclude specific files. The <b>--init</b> option can generate a basic configuration file to get started.


title: RULE SETS
content:
<b>tslint</b> provides a comprehensive set of built-in rules covering various aspects of code quality, from formatting and style to potential bugs. Users can choose to enable or disable these rules and configure their behavior. Additionally, it supports custom rules, allowing developers to enforce project-specific coding standards or integrate with internal tools.


title: HISTORY
content:
<b>tslint</b> was created by Palantir and quickly became the de facto standard linter for TypeScript projects after its initial release. It gained significant popularity due to TypeScript's growing adoption and the need for code quality enforcement.<br><br>However, with the rise of ESLint's ecosystem and its increasing support for parsing various JavaScript dialects (including TypeScript via plugins), Palantir decided to officially deprecate <b>tslint</b> in 2019. They encouraged users to migrate to ESLint, recognizing the community's preference for a unified linting solution across JavaScript and TypeScript codebases. This decision marked a significant shift, leading to the development of <i>typescript-eslint</i>, which effectively became the successor for TypeScript linting.


title: PARAMETERS
content:
<b>-i, --interval <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the measurement interval in seconds. Defaults to 5 seconds.<br><br><b>-c, --cpu <list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitor only the specified CPUs (e.g., 0-3,5). Defaults to all CPUs.<br><br><b>-s, --system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report system-wide statistics (average across all CPUs/sockets). This is the default.<br><br><b>-S, --socket</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report statistics per CPU socket/package.<br><br><b>-P, --package</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for --socket.<br><br><b>-C, --core</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Report statistics per CPU core.<br><br><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;Display version information and exit.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the header line. Useful for scripting.<br><br><b>-r, --raw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw MSR values instead of decoded human-readable metrics.<br><br><b>-j, --json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in JSON format (available in newer versions).<br><br><b>--csv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in CSV format.<br><br><b>--no-header</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress printing the header row only (unlike -q which suppresses all informational output).<br><br><b>--show <columns></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a comma-separated list of columns to display.<br><br><b>--hide <columns></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a comma-separated list of columns to hide.<br><br><b>--enable <columns></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable specific columns that might be disabled by default.<br><br><b>--disable <columns></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable specific columns.<br><br><b>--msr <msr_list></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw values of specified MSRs (e.g., 0x199,0x610).<br><br><b>--msr-range <start-end></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw values of MSRs within a specified range.<br><br><b>--dump-msr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump all known MSRs. Very verbose.<br><br><b>--debug-msr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show additional debug information about MSR access.<br><br><b>--output <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirect output to a specified file.<br><br><b>--x2apic</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use x2APIC IDs for CPU enumeration.<br><br><b>--poll-msr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use polling MSR access instead of /dev/cpu/*/msr (slower).<br><br><b>--cpu-top</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the top power-consuming CPUs when combined with --interval.<br><br>


title: DESCRIPTION
content:
<i><b>turbostat</b></i> is a Linux command-line utility that provides detailed, real-time statistics about processor activity, including frequencies, idle states (C-states), temperature, and power consumption. It operates by directly reading Model Specific Registers (MSRs) available on modern Intel and some AMD CPUs, offering a very low-overhead way to monitor CPU behavior. This tool is invaluable for performance tuning, power optimization, and diagnosing issues like CPU throttling or unexpected power usage. It can report system-wide, per-socket, or per-core statistics, making it highly flexible for various analysis needs. Its output is typically tabular, presenting metrics such as average frequency, busy percentage, C-state residency, core temperature, and package/DRAM power usage.


title: CAVEATS
content:
<i><b>turbostat</b></i> requires root privileges or the <code>CAP_SYS_RAWIO</code> capability to access Model Specific Registers (MSRs), which are essential for its operation. The availability and accuracy of certain metrics, especially power consumption (RAPL) and specific C-states, depend heavily on the underlying CPU architecture and model. Not all metrics are supported on all processors, and some readings might be estimates. Running <i><b>turbostat</b></i> continuously can have a minor, though generally negligible, overhead.


title: UNDERSTANDING OUTPUT COLUMNS
content:
Key columns in <i><b>turbostat</b></i> output provide insights into CPU behavior:<br><b>Avg_MHz</b>: Average CPU clock speed during the interval.<br><b>Busy%</b>: Percentage of time the CPU was not in an idle state (C0).<br><b>Bzy_MHz</b>: Average clock speed when the CPU was busy (in C0 state).<br><b>TSC_MHz</b>: Nominal Turbo Speed Clock (TSC) frequency.<br><b>C1, C3, C6, C7%</b>: Percentage of time spent in various C-states. Higher C-state numbers indicate deeper idle states, saving more power but with higher wake-up latency.<br><b>PkgTmp</b>: Package temperature in Celsius.<br><b>PkgWatt</b>: Total package power consumption in Watts (via RAPL).<br><b>RAMWatt</b>: DRAM power consumption in Watts (if supported).<br><b>GFXWatt</b>: Integrated graphics power consumption in Watts (if supported).


title: MODEL SPECIFIC REGISTERS (MSRS)
content:
<i><b>turbostat</b></i> operates by reading and interpreting Model Specific Registers (MSRs). MSRs are control registers specific to a particular processor family or model, used to configure, enable, and gather data from various CPU features, including power management, thermal sensors, and performance counters. Direct MSR access is why <i><b>turbostat</b></i> requires elevated privileges.


title: HISTORY
content:
<i><b>turbostat</b></i> was primarily developed by Intel engineers, notably Len Brown, as part of the <code>linux-tools</code> or <code>kernel-tools</code> package. Its development has closely tracked new CPU architectures and their features, with continuous updates to incorporate support for new MSRs, power management features (like RAPL), and improved C-state reporting. It has become a standard utility for low-level CPU performance and power analysis in the Linux ecosystem, particularly favored for its direct MSR access and minimal overhead.


title: SYNOPSIS
content:
<b><code>twurl</code></b> <I>[options]</I> <I>&lt;path&gt;</I> <I>[parameters]</I><br><b><code>twurl</code></b> <I>authorize</I><br><b><code>twurl</code></b> <I>accounts</I><br><b><code>twurl</code></b> <I>config</I> <I>&lt;key&gt;</I> <I>&lt;value&gt;</I>


title: PARAMETERS
content:
<b><b><code>-X</code></b>, <b><code>--request</code></b> <I>&lt;METHOD&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the HTTP request method (e.g., GET, POST, PUT, DELETE). Default is GET.<br><br><b><b><code>-H</code></b>, <b><code>--header</code></b> <I>&lt;HEADER&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass custom header(s) to the request in the format "Header: Value".<br><br><b><b><code>-d</code></b>, <b><code>--data</code></b> <I>&lt;DATA&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;HTTP POST data for the request (e.g., "status=Hello+World").<br><br><b><b><code>-A</code></b>, <b><code>--auth</code></b> <I>&lt;METHOD&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the authentication method to use (e.g., <b><code>oauth</code></b>, <b><code>bearer</code></b>).<br><br><b><b><code>-u</code></b>, <b><code>--user</code></b> <I>&lt;USERNAME&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific user's credentials if multiple accounts are configured.<br><br><b><b><code>-P</code></b>, <b><code>--profile</code></b> <I>&lt;PROFILE&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a profile name to use from the configuration.<br><br><b><b><code>-v</code></b>, <b><code>--verbose</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Make the operation more talkative, showing request details.<br><br><b><b><code>-s</code></b>, <b><code>--silent</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't show progress meter or error messages.<br><br><b><b><code>-t</code></b>, <b><code>--trace</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show detailed HTTP request and response headers and body.<br><br><b><b><code>--consumer-key</code></b> <I>&lt;KEY&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the configured consumer key for the current request.<br><br><b><b><code>--consumer-secret</code></b> <I>&lt;SECRET&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the configured consumer secret for the current request.<br><br><b><b><code>--token</code></b> <I>&lt;TOKEN&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the configured access token for the current request.<br><br><b><b><code>--secret</code></b> <I>&lt;SECRET&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Override the configured access token secret for the current request.<br><br><b><b><code>--bearer</code></b> <I>&lt;TOKEN&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specified bearer token for application-only authentication.<br><br><b><b><code>--version</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version number and exit.<br><br><b><b><code>--help</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show help message and exit.<br><br><b><b><code>--clear-cache</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear the authentication cache for all users.<br><br><b><b><code>--no-cache</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use the authentication cache for the current request.<br><br><b><b><code>--proxy</code></b> <I>&lt;PROXY_URL&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified proxy for HTTP requests.<br><br><b><b><code>--config</code></b> <I>&lt;FILE&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an alternative configuration file instead of the default.<br><br><b><b><code>--daemon</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <b><code>twurl</code></b> as a daemon for streaming API endpoints.<br><br><b><b><code>--json-stream</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parse incoming JSON stream and pretty-print each JSON object.<br><br><b><b><code>--rate-limit</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show Twitter API rate limit information for the requested endpoint.<br><br><b><b><code>--user-cache</code></b> <I>&lt;PATH&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a specific path for user credentials cache.<br><br>


title: DESCRIPTION
content:
<b><code>twurl</code></b> is a powerful command-line tool that provides a convenient interface for interacting with the Twitter API. Developed by Twitter engineers, it simplifies the process of making authenticated requests by handling the OAuth 1.0a and OAuth 2.0 authentication flows automatically. Users can easily send HTTP requests (GET, POST, PUT, DELETE) to any Twitter API endpoint, making it ideal for testing, debugging, and scripting interactions with Twitter. It abstracts away the complexities of signing requests, allowing developers to focus on the API endpoints and parameters. <b><code>twurl</code></b> is particularly useful for exploring the Twitter API, quickly prototyping applications, or performing administrative tasks without needing to write extensive code. It supports various authentication methods including user-based OAuth and application-only bearer tokens.


title: CAVEATS
content:
<b>Twitter API Changes:</b> <br>The Twitter API (now known as the X API) undergoes frequent changes (e.g., v1.1 vs. v2), which may affect the behavior or availability of certain endpoints used with <b><code>twurl</code></b>.<br><b>Rate Limits:</b> <br>All requests to the Twitter API are subject to strict rate limits. Exceeding these limits can result in temporary blocking of your application or user account.<br><b>Deprecation:</b> <br>Older API versions, features, or endpoints might be deprecated and eventually removed by Twitter, requiring users to update their <b><code>twurl</code></b> commands and scripts.


title: INSTALLATION
content:
<b><code>twurl</code></b> is typically installed as a Ruby gem: <br><b><code>gem install twurl</code></b><br>It requires Ruby to be installed on your system.


title: AUTHENTICATION
content:
Before making authenticated requests, you usually need to authorize <b><code>twurl</code></b>. This is commonly done with: <br><b><code>twurl authorize</code></b><br>This command will open a browser window for you to grant access to your Twitter account and then prompt for a verification PIN. Alternatively, you can manually configure consumer keys and secrets using <b><code>twurl config</code></b>.


title: HISTORY
content:
<b><code>twurl</code></b> was developed by Twitter engineers, primarily for internal use, and was later released as an open-source Ruby gem. Its primary motivation was to simplify interaction with the complex and evolving Twitter API, especially handling the intricacies of OAuth 1.0a authentication. It quickly gained popularity among developers and scripters for its ease of use in testing API endpoints, debugging issues, and automating Twitter interactions directly from the command line, without needing to write full-fledged applications. Its continuous development reflects ongoing changes and additions to the Twitter API.


title: SEE ALSO
content:
<b><code>curl</code></b>(1), <b><code>wget</code></b>(1), <b><code>httpie</code></b>(1), <b><code>jq</code></b>(1)


title: DESCRIPTION
content:
<b>tzselect</b> is an interactive utility designed to help users determine the correct timezone string for their geographical location. It guides the user through a series of hierarchical menus, first prompting for a continent or ocean, and then progressively narrowing down the selection to specific regions or major cities within that area. Once a selection is made, <b>tzselect</b> outputs the corresponding canonical timezone identifier (e.g., <i>"America/Los_Angeles"</i>) to standard output. This output is typically used to configure the system's timezone, often by setting the <i>TZ</i> environment variable or by creating a symbolic link from <i>/etc/localtime</i> to the appropriate timezone data file found in <i>/usr/zoneinfo</i>. It simplifies the process of timezone configuration, especially for new users or systems without a graphical interface, by abstracting away the need to know the exact timezone string format. It relies on the <i>tzdata</i> package for its comprehensive timezone information.


title: CAVEATS
content:
<b>tzselect</b> only outputs the recommended timezone string to standard output; it does <i>not</i> automatically set the system's timezone. The user must manually use its output to configure the system (e.g., by creating a symbolic link for <i>/etc/localtime</i> or setting the <i>TZ</i> environment variable).<br>Being an interactive command, it is generally unsuitable for direct use within automated scripts without advanced input redirection techniques.<br>Its functionality is entirely dependent on the presence and up-to-date nature of the <i>tzdata</i> (timezone data) package on the system.


title: INTERACTIVE NATURE
content:
<b>tzselect</b> functions as an interactive shell script, guiding the user through a sequence of numbered menus. It first prompts for a continent or ocean, followed by more specific regions or cities. This interactive approach ensures an accurate timezone selection without requiring prior knowledge of specific timezone identifiers. Due to its interactive nature, it does not accept command-line arguments or options.


title: OUTPUT USAGE
content:
The primary utility of <b>tzselect</b> lies in its ability to output the canonical timezone name to standard output upon successful selection. Users typically capture this output using command substitution (e.g., <i>$(tzselect)</i>) to then manually configure their system's timezone. Common configuration methods include updating the <i>/etc/localtime</i> symbolic link (e.g., <i>sudo ln -sf /usr/share/zoneinfo/$(tzselect) /etc/localtime</i>) or setting the <i>TZ</i> environment variable for specific shell sessions or applications.


title: HISTORY
content:
<b>tzselect</b> is an integral part of the <i>tzdata</i> (timezone data) distribution, also widely known as the IANA Time Zone Database or the Olson database. This comprehensive database was initially created by Arthur David Olson in 1987 and subsequently maintained by Paul Eggert. <b>tzselect</b> was developed to provide a user-friendly, interactive method for navigating this extensive and often complex database. Its primary purpose is to allow system administrators and users to easily identify and configure their correct local time, a crucial aspect for globally distributed systems. Its design prioritizes simplicity and interactivity, abstracting the underlying file system structure of the timezone data to make configuration accessible.


title: PARAMETERS
content:
<b><i>PROBLEM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the subject of the bug report. This can be the name of an installed package (e.g., <b>firefox</b>), a process ID (PID) of a running application, or the path to an existing <I>apport</I> problem report file. If omitted, <b>ubuntu-bug</b> attempts to find the most recently crashed application or initiates a general bug report.<br><br><b><b>--bug-id</b>=<i>BUG_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an existing Launchpad bug ID to which the collected information should be attached. If not provided, a new bug report will be created.<br><br><b><b>--attach-file</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches an additional file (e.g., a screenshot or log file) to the bug report. This option can be specified multiple times to attach several files.<br><br><b><b>--launchpad-url</b>=<i>URL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides the default Launchpad URL (e.g., for testing or development instances).<br><br><b><b>--save</b>=<i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the generated problem report to the specified file path instead of uploading it to Launchpad. This allows for review or manual submission.<br><br><b><b>--private</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the bug report as private on Launchpad, limiting its visibility to the bug reporter and Launchpad administrators. Use this option if the report contains sensitive information.<br><br><b><b>--no-info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the collection of detailed system information (like package versions, kernel logs) which are usually included in bug reports. Use with caution as this may hinder debugging efforts.<br><br><b><b>--no-ui</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>ubuntu-bug</b> in a non-interactive mode without graphical user interface prompts. This is useful for scripting but typically requires a <i>PROBLEM</i> argument or <b>--bug-id</b> to proceed.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message outlining the command's usage and options, then exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version number and exits.<br><br>


title: DESCRIPTION
content:
<b>ubuntu-bug</b> is the standard command-line utility for reporting software bugs on Ubuntu systems directly to Launchpad. It automates the process of gathering relevant system information, such as crash logs, package versions, and system configuration, which is crucial for developers to diagnose and fix issues efficiently. When executed, it typically prompts the user for details about the bug and then uploads the collected information to a new or existing bug report on Launchpad. This command simplifies the bug reporting workflow, ensuring that necessary diagnostic data is included, thereby improving the efficiency of the bug resolution process within the Ubuntu ecosystem. It integrates closely with the <I>apport</I> framework to provide detailed crash reports and system state information.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br><br><b>1. Internet Connection Required:</b> Submitting bug reports to Launchpad requires an active internet connection.<br><br><b>2. Apport Dependency:</b> <b>ubuntu-bug</b> relies on the <I>apport</I> framework and its associated packages being correctly installed and configured on the Ubuntu system.<br><br><b>3. Potential for User Interaction:</b> While options like <b>--no-ui</b> exist, some complex issues or missing critical information might still prompt for user interaction.<br><br><b>4. Data Privacy Concerns:</b> The command collects extensive system information. Users should be aware of the data being shared and consider using the <b>--private</b> option for sensitive information or reviewing the data before submission.


title: INTERACTIVE VS. NON-INTERACTIVE USE
content:
<b>ubuntu-bug</b> primarily functions interactively, guiding users through the bug reporting process with prompts for details and confirmation. For automated scripts or specific use cases where user interaction is undesirable, the <b>--no-ui</b> option can be used. However, non-interactive use typically requires more specific command-line arguments (like a package name or bug ID) to proceed without user input.


title: DATA COLLECTION AND PRIVACY CONSIDERATIONS
content:
The command collects a wide array of system information, including package versions, hardware details, kernel logs, and potentially sensitive crash data. Users are typically given an opportunity to review this data before submission. The <b>--private</b> option can be used to mark the bug report as private on Launchpad, limiting its visibility to the bug reporter and Launchpad administrators, which is advisable for highly sensitive information.


title: INTEGRATION WITH APPORT
content:
<b>ubuntu-bug</b> relies heavily on <I>apport</I>, Ubuntu's automated crash reporting and debugging tool. <I>Apport</I> is responsible for detecting software crashes, generating detailed problem reports containing system state and diagnostic information, and providing the underlying data that <b>ubuntu-bug</b> then uploads to Launchpad. This deep integration ensures comprehensive and actionable bug reports.


title: HISTORY
content:
<b>ubuntu-bug</b> is an integral part of Ubuntu's bug reporting infrastructure, deeply tied to the <I>apport</I> framework. Introduced early in Ubuntu's history, <I>apport</I> aimed to automate and simplify the process of reporting software crashes and bugs, making it easier for users to contribute to the distribution's stability. <b>ubuntu-bug</b> acts as the primary user-facing command-line interface for this system, evolving alongside Ubuntu's development to enhance integration with Launchpad, the project's chosen bug tracking and development platform. Its continuous development reflects Ubuntu's commitment to robust bug reporting and community involvement.


title: SYNOPSIS
content:
<b>ucf</b> [<i>options</i>] <I>new-package-file</I> <I>config-file</I><br><b>ucf</b> [<i>options</i>] --install <I>new-package-file</I> <I>config-file</I><br><b>ucf</b> [<i>options</i>] --purge <I>config-file</I><br><b>ucf</b> [<i>options</i>] --remove-dead-links <I>config-file</I>


title: PARAMETERS
content:
<b>--install <new-package-file> <config-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs or updates a configuration file, managing differences with the currently installed version.<br><br><b>--purge <config-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Purges (removes) a configuration file and its associated backup/tracking files.<br><br><b>--remove-dead-links <config-file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes dead symbolic links associated with the configuration file.<br><br><b>--xattr</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets extended attributes on the configuration files.<br><br><b>--new-package <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the new configuration file provided by the package.<br><br><b>--config-file <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the currently installed configuration file to be managed.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operations being performed.<br><br><b>--no-action, -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a dry run; shows what would be done without making any actual changes.<br><br><b>--debconf-compatible</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the output and interaction style more compatible for scripting with Debconf.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <i>ucf</i> (Update Configuration File) command is a powerful utility primarily used in Debian-based Linux distributions to handle configuration files during package installations and upgrades. Its main purpose is to prevent the loss of user-modified settings when a package provides a new version of a configuration file. <i>ucf</i> intelligently compares the new configuration file from the package with the currently installed version and the original version installed by the package.<br><br>Based on this comparison, it can prompt the user to decide whether to keep their local changes, install the new version, or view the differences. This interactive approach ensures that system administrators retain control over their configurations while benefiting from package updates. <i>ucf</i> is often invoked by package maintainer scripts (e.g., in `postinst` scripts) to manage configuration files like <i>/etc/ssh/sshd_config</i> or <i>/etc/default/grub</i>, making the upgrade process smoother and safer for system administrators.


title: CAVEATS
content:
<i>ucf</i> is primarily designed for and used within Debian-based Linux distributions. Its functionality heavily relies on `dpkg`'s file tracking mechanisms. In interactive mode, it may pause package upgrades to prompt for user input, which can be mitigated using `debconf`'s pre-seeding capabilities. Incorrect usage, particularly manual invocation, can lead to unintended configuration changes or loss of data.


title: INTERACTION MODEL
content:
When <i>ucf</i> detects differences between the new package file, the original installed file, and the user's current file, it typically prompts the user for a decision. The user can choose to install the maintainer's version, keep their local version, view the differences, or perform a three-way merge. This interaction is often mediated through <i>debconf</i>, which allows for pre-seeding answers to ensure unattended upgrades.


title: INTEGRATION WITH PACKAGING
content:
<i>ucf</i> is commonly invoked by maintainer scripts (e.g., `postinst` or `prerm`) within Debian packages. Package maintainers specify which configuration files <i>ucf</i> should manage, allowing for consistent and predictable behavior across the distribution. This integration ensures that package upgrades handle configuration files gracefully, balancing system stability with user customization.


title: HISTORY
content:
<i>ucf</i> was developed specifically for the Debian project to address the complex challenge of configuration file management during package upgrades. Before utilities like <i>ucf</i>, package upgrades often involved overwriting user-modified configuration files or leaving `.dpkg-old` files, which could lead to manual merging nightmares. <br><br><i>ucf</i> aims to automate and streamline this process by providing a robust mechanism for tracking and merging changes, giving users options without breaking their custom setups. It became an integral part of the Debian packaging ecosystem, significantly improving the user experience for system administrators maintaining their systems. Its design philosophy centers around preserving user choices while ensuring that systems benefit from updated configurations.


title: SYNOPSIS
content:
<b>unattended-upgrade</b> [<i>-d</i>|<i>--debug</i>] [<i>--dry-run</i>] [<i>-v</i>|<i>--verbose</i>]


title: PARAMETERS
content:
<b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables extensive debug output, useful for troubleshooting the upgrade process.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the upgrade process without actually making any changes to the system. Shows what would happen.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, showing more detailed information about the upgrade process.<br><br>


title: DESCRIPTION
content:
<i>unattended-upgrade</i> is a powerful utility designed to automate the installation of security updates and, optionally, other package upgrades on Debian-based Linux systems (like Ubuntu). Its primary purpose is to ensure that systems remain secure by applying critical patches without requiring manual intervention. This is particularly useful for servers or systems where continuous uptime and security are paramount.<br><br>The command typically runs as a background process, often scheduled via <i>cron</i> or <i>systemd timers</i>, and silently downloads and installs updates. While it primarily focuses on security updates, its configuration can be adjusted to include other types of updates or even automatically reboot the system if necessary. Proper configuration via files in <i>/etc/apt/apt.conf.d/</i> is crucial for its safe and effective operation, allowing administrators to define which updates are applied and how the system behaves post-upgrade.


title: CAVEATS
content:
<ul><li>Requires careful configuration in <i>/etc/apt/apt.conf.d/</i> to define update sources, automatic reboots, and email notifications.</li><li>While convenient, automatic updates can occasionally introduce unforeseen issues or breakages, especially if not restricted to security-only updates.</li><li>It's recommended to regularly monitor system logs (e.g., <i>/var/log/unattended-upgrades/</i>) to track upgrade activity and potential problems.</li></ul>


title: CONFIGURATION FILES
content:
The primary configuration for <i>unattended-upgrade</i> is managed through files in the <i>/etc/apt/apt.conf.d/</i> directory. Key files include <i>20auto-upgrades</i> (to enable/disable automatic updates) and <i>50unattended-upgrades</i> (to define specific update policies, allowed origins, automatic reboots, and email notifications).


title: LOGGING
content:
All actions performed by <i>unattended-upgrade</i> are logged to files located in <i>/var/log/unattended-upgrades/</i>. These logs are crucial for auditing and troubleshooting, providing details on what packages were upgraded and any errors encountered.


title: SCHEDULING
content:
The execution of <i>unattended-upgrade</i> is typically scheduled by system timers. On modern systems, this is often handled by a <i>systemd timer</i> (e.g., <i>apt-daily.timer</i>), which periodically triggers the update check and installation process.


title: HISTORY
content:
<i>unattended-upgrade</i> is part of the <i>unattended-upgrades</i> package, which was developed primarily for Debian and Ubuntu systems. Its introduction addressed the critical need for automated security patch management, particularly for servers that require high availability and continuous security. It evolved as a robust solution to ensure systems remain updated against known vulnerabilities without manual intervention, leveraging the existing APT package management system.


title: SYNOPSIS
content:
<pre>unix2dos [options] [file ...]</pre><pre>unix2dos [options] -o &lt;outfile&gt; &lt;infile&gt;</pre><pre>unix2dos [options] &lt; &lt;infile&gt; &gt; &lt;outfile&gt;</pre>The most common usage is <b>unix2dos &lt;filename&gt;</b> for in-place conversion or <b>unix2dos -n &lt;infile&gt; &lt;outfile&gt;</b> for converting to a new file.


title: PARAMETERS
content:
<b>-b, --add-bom</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a Byte Order Mark (BOM) to UTF-8 output files.<br><br><b>-c, --convmode CONVMODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set conversion mode: <i>ascii</i>, <i>7bit</i>, <i>iso</i>, <i>mac</i>, <i>utf8</i>, <i>utf16le</i>, <i>utf16be</i>, <i>utf32le</i>, or <i>utf32be</i>.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force conversion even if the file is not a regular file or appears binary.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>-i, --in-place</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit files in place. Converts the original file directly.<br><br><b>-k, --keep-date</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep the original modification timestamp of the output file.<br><br><b>-n, --newfile</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write to a new file. Requires the <b>-o</b> option.<br><br><b>-o, --outfile &lt;outfile&gt; &lt;infile&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write converted output to &lt;outfile&gt; from &lt;infile&gt;.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warning and error messages.<br><br><b>-s, --suffix &lt;SUFFIX&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Append a suffix to backup files created during in-place conversion.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat subsequent arguments as file names, even if they begin with a hyphen.<br><br>


title: DESCRIPTION
content:
The <b>unix2dos</b> command converts text files from the Unix-style line ending format (a single Line Feed, <b>LF</b>) to the DOS/Windows-style line ending format (a Carriage Return followed by a Line Feed, <b>CRLF</b>). This utility is indispensable for ensuring cross-platform compatibility, especially when transferring text files created on Unix-like systems to Windows environments, where applications typically expect <b>CRLF</b> line endings. <br><br>It can process multiple files, operate in-place, or write to a new output file. <b>unix2dos</b> intelligently handles various character encodings, including ASCII, UTF-8, and UTF-16, with options to specify the conversion mode. By default, it operates in "ascii" mode, but users can specify more complex conversions for international character sets. Part of the widely used <b>dos2unix</b> package, it provides a straightforward solution to a common interoperability challenge.


title: CAVEATS
content:
<ul><li><b>Binary Files:</b> Using <b>unix2dos</b> on binary files will likely corrupt them, as it treats all input as text and modifies byte sequences that resemble line endings.</li><li><b>In-Place Conversion:</b> While convenient, the <b>-i</b> (in-place) option overwrites the original file. Always ensure you have backups or use the <b>-n</b> / <b>-o</b> options for critical files.</li><li><b>Encoding Issues:</b> If the input file's character encoding is not correctly detected or specified (via <b>-c</b>), text may be corrupted, especially for non-ASCII characters.</li></ul>


title: LINE ENDING DIFFERENCES
content:
Unix systems use '<b>\n</b>' (LF, ASCII 10), while DOS/Windows systems use '<b>\r\n</b>' (CRLF, ASCII 13 followed by ASCII 10). This difference is the core problem <b>unix2dos</b> solves.


title: STANDARD INPUT/OUTPUT
content:
When no files are specified, <b>unix2dos</b> reads from standard input and writes to standard output, allowing it to be used in shell pipelines (e.g., <code>cat file | unix2dos > newfile</code>).


title: HISTORY
content:
The <b>unix2dos</b> command is a component of the `dos2unix` package, which emerged to address the fundamental challenge of incompatible line ending conventions across different operating systems. Unix-like systems adopted the Line Feed (<b>LF</b>) character, while DOS and Windows systems standardized on the Carriage Return + Line Feed (<b>CRLF</b>) pair. <br><br>This divergence frequently caused issues like files appearing as a single long line or having extra blank lines when moved between environments. The `dos2unix` suite, including <b>unix2dos</b>, was developed to provide a robust and widely available utility for seamless conversion, making cross-platform file exchange much more manageable for developers, system administrators, and users alike. Its design has evolved to handle various encodings and provide flexible conversion options.


title: PARAMETERS
content:
<b><I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the user whose password is to be verified. The command will then internally check a provided password (typically read from standard input or through other secure communication channels) against this user's stored credentials in <I>/etc/shadow</I>.<br><br>


title: DESCRIPTION
content:
The <I>unix_chkpwd</I> command is a low-level utility primarily used by the Pluggable Authentication Modules (PAM) framework, specifically by the <I>pam_unix.so</I> module, to verify a user's password. It is an integral part of the standard Unix password authentication mechanism.<br><br>When a user attempts to log in or authenticate, PAM directs the request to modules like <I>pam_unix.so</I>, which then internally calls <I>unix_chkpwd</I>. This command checks the provided password (usually passed via secure means like standard input or internal memory) against the hashed password stored in the system's password database, typically <I>/etc/shadow</I>.<br><br>It returns a success or failure status, indicating whether the password is correct for the specified user. It is not intended for direct interactive use by end-users.


title: CAVEATS
content:
This command is a security-sensitive, low-level utility. It is not designed for direct invocation by general users and typically resides with restricted permissions. Misuse or tampering with this command can lead to severe security vulnerabilities or system instability. Its primary role is to be called by privileged processes (like PAM modules) for authentication purposes, and it should never be executed directly by unprivileged users.


title: RETURN CODES
content:
<I>unix_chkpwd</I> typically returns an exit status of 0 on successful password verification, and a non-zero status (e.g., 1 for authentication failure, other values for system errors) otherwise. Specific non-zero values might indicate different types of errors or conditions.


title: SECURITY CONTEXT
content:
This executable is usually installed with the set-user-ID (SUID) root permission, allowing it to temporarily gain root privileges to read the sensitive <I>/etc/shadow</I> file. This privilege escalation is tightly controlled and minimized to perform only the necessary password comparison in a secure and isolated manner.


title: HISTORY
content:
The <I>unix_chkpwd</I> command evolved as part of the standard Unix password management suite, particularly with the introduction of shadow passwords to enhance security by storing hashed passwords in a file readable only by root. Its functionality became even more crucial with the advent of PAM (Pluggable Authentication Modules) in the mid-1990s.<br><br>As systems transitioned to more modular authentication frameworks, <I>unix_chkpwd</I> solidified its role as a core component of the <I>pam_unix.so</I> module, providing the fundamental password verification service for systems using traditional Unix password authentication methods.


title: PARAMETERS
content:
<b>-d <directory>, --dest <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the destination directory for extracted files.</i><br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Overwrite existing files without prompting.</i><br><br><b>-i, --info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display information about the SquashFS image, but do not extract.</i><br><br><b>-l, --ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>List the contents of the SquashFS image, but do not extract.</i><br><br><b>-p <processors>, --processors <processors></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Use a specified number of processors for parallel decompression.</i><br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress most output during extraction.</i><br><br><b>-s, --stat</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display statistics about the extraction process, such as decompression rates and total bytes.</i><br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Produce verbose output during extraction, showing files as they are processed.</i><br><br><b>-o <offset>, --offset <offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify an offset in bytes at the start of the image to skip. Useful for images embedded within other files.</i><br><br>


title: DESCRIPTION
content:
<i>unsquashfs</i> is a utility used to extract the contents of a SquashFS filesystem image. SquashFS is a highly compressed, read-only filesystem for Linux, primarily used for live CDs, embedded systems, and general purpose data archiving. <i>unsquashfs</i> allows users to decompress and access the files and directories stored within a SquashFS image, effectively reversing the squashing process. It can extract to the current directory or a specified target directory, preserving file metadata like permissions and timestamps where possible. It's an essential tool for inspecting, modifying (indirectly), or accessing data within SquashFS archives often found in system recovery partitions, firmware, or live operating system environments.


title: CAVEATS
content:
<i>unsquashfs</i> requires sufficient disk space to store the uncompressed contents. The original file permissions and timestamps are preserved if the extracting user has the necessary privileges; otherwise, permissions might be adjusted to match the current user's capabilities. It cannot modify a SquashFS image directly; to alter contents, one must extract, modify, and then re-create the image using <i>mksquashfs</i>. Corrupted SquashFS images might lead to incomplete or failed extractions.


title: USAGE WITH SPECIFIC FILES/DIRECTORIES
content:
You can extract only specific files or directories by listing them as arguments after the SquashFS image path. For example: <b>unsquashfs image.sqfs /path/to/file.txt /another/directory/</b>. This allows for selective extraction, saving time and disk space when only a few items are needed.


title: EMBEDDING SQUASHFS IMAGES
content:
The <b>-o</b> or <b>--offset</b> option is particularly useful when a SquashFS image is appended to another file (e.g., a kernel or bootloader) or embedded within a larger archive. This allows <i>unsquashfs</i> to start reading the SquashFS data from the correct position, ignoring the preceding data.


title: HISTORY
content:
SquashFS and its accompanying tools, including <i>unsquashfs</i>, were developed to provide a highly compressed, read-only filesystem suitable for various uses, particularly in embedded systems, live Linux distributions (like Knoppix, Ubuntu Live CDs), and for distributing software. The first public release was around 2002. <i>unsquashfs</i> has evolved with the SquashFS format, supporting newer compression algorithms and features over time. Its utility lies in enabling easy access to the contents of these often-large compressed archives without needing to mount the entire filesystem.


title: PARAMETERS
content:
<b><b>-d</b>, <b>--decompress</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress the input file(s). This is the default operation for <b>unzstd</b> and is often implied.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwrite of existing output files without prompting for confirmation.<br><br><b><b>-k</b>, <b>--keep</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep (do not delete) the input files after successful decompression. By default, <b>unzstd</b> deletes the original compressed file.<br><br><b><b>-o</b> <i>&lt;file&gt;</i>, <b>--output</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the decompressed output to the specified <i>&lt;file&gt;</i> instead of standard output or a derived filename.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all warning and informational messages, showing only critical errors.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose mode, displaying more detailed information during the decompression process, such as compression ratio.<br><br><b><b>--rm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove source files after successful decompression. This is the default behavior unless <b>-k</b> is specified.<br><br><b><b>-c</b>, <b>--stdout</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write all decompressed data to standard output. This is automatically set if multiple input files are specified or if the output is redirected to a terminal.<br><br><b><b>-D</b> <i>&lt;dir&gt;</i>, <b>--output-directory</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress input files into the specified directory <i>&lt;dir&gt;</i>, maintaining original filenames (without the <i>.zst</i> suffix).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with command options and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of <b>zstd</b> (which <b>unzstd</b> is part of) and exit.<br><br>


title: DESCRIPTION
content:
<b>unzstd</b> is a command-line utility specifically designed to decompress files that have been compressed using the Zstandard (zstd) compression algorithm. It typically functions as a convenient symbolic link or hard link to the <b>zstd</b> command, implicitly setting the decompression mode. When executed, <b>unzstd</b> reads compressed data from a specified file or standard input, efficiently decompresses it, and writes the uncompressed data to standard output or a specified output file. Zstandard is widely recognized for its exceptional balance of high compression ratios and remarkably fast decompression speeds, making <b>unzstd</b> an essential tool for quickly restoring data from zstd archives, particularly in environments where rapid data retrieval is critical. By default, it automatically identifies and processes files with the <i>.zst</i> extension or other common Zstandard suffixes, outputting the decompressed content with the suffix removed.


title: CAVEATS
content:
<b>unzstd</b> expects its input to be valid Zstandard-compressed data. Providing malformed or non-Zstandard input may result in decompression errors or corrupted output.<br>By default, <b>unzstd</b> deletes the original compressed file upon successful decompression. To retain the original file, use the <b>-k</b> or <b>--keep</b> option.<br>The command does not preserve original file permissions, ownership, or timestamps on the decompressed output file; these attributes will be set according to the user's umask and current system time.


title: INPUT AND OUTPUT BEHAVIOR
content:
If no input files are specified, <b>unzstd</b> reads compressed data from standard input (<i>stdin</i>) and writes the decompressed data to standard output (<i>stdout</i>).<br>When a single input file with a <i>.zst</i> extension (e.g., <i>archive.zst</i>) is provided, <b>unzstd</b> decompresses it and creates an output file with the <i>.zst</i> suffix removed (e.g., <i>archive</i>).<br>If multiple input files are specified, or if the output is redirected to a terminal, <b>unzstd</b> will automatically write all decompressed output to standard output, unless the <b>-o</b> or <b>-D</b> option is used to specify an output file or directory.


title: HISTORY
content:
<b>unzstd</b> is not an independent command but rather a functional alias or symbolic link provided by the <b>zstd</b> compression utility suite. The Zstandard algorithm and its accompanying tools were developed by Yann Collet at Facebook (now Meta) and publicly released as open-source software in 2016. The primary motivation behind <b>zstd</b> was to create a new compression standard that offers superior performance in both compression ratio and speed, particularly decompression speed, compared to existing algorithms like zlib and gzip. The inclusion of <b>unzstd</b> as a distinct command name from the outset aimed to provide users with a familiar decompression interface, mirroring the convention established by tools such as <b>gunzip</b> and <b>bunzip2</b>, thereby ensuring ease of adoption and integration into existing workflows.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the command and exits.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all output messages, making it suitable for silent execution in scripts or cron jobs.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an update only if the installed USB ID list is older than the one available online. This is often the default behavior.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the download and installation of the USB ID list, even if the local version is newer or the same as the remote one.<br><br><b>-s <I>URL</I>, --source=<I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative URL from which to download the <I>usb.ids</I> file. Useful if the default source is unavailable or a local mirror is preferred.<br><br><b>-o <I>FILE</I>, --output=<I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom output file path where the downloaded <I>usb.ids</I> list should be saved, overriding the default system location (e.g., /usr/share/hwdata/usb.ids).<br><br>


title: DESCRIPTION
content:
The <b>update-usbids</b> command is a utility designed to download and update the local <I>usb.ids</I> file. This file contains a comprehensive list of known USB vendor, product, and interface IDs, along with their corresponding human-readable names.<br><br>Tools like <I>lsusb</I> rely on this database to display meaningful information about connected USB devices, rather than just raw hexadecimal IDs. As new USB devices are constantly released, the <I>usb.ids</I> file needs to be regularly updated to ensure that these devices are correctly identified.<br><br><b>update-usbids</b> typically fetches the latest version of the <I>usb.ids</I> list from a designated online source (often the Linux USB ID repository). By default, it performs an update only if the remote version is newer than the currently installed one. This command is frequently scheduled to run automatically via cron jobs to keep the system's USB ID database current, preventing <I>lsusb</I> and other utilities from showing 'Unknown' devices for new hardware.


title: CAVEATS
content:
Using <b>update-usbids</b> requires network connectivity to download the latest USB ID list. To install the updated file to system directories (e.g., <I>/usr/share/hwdata/usb.ids</I>), the command typically needs to be executed with root privileges.


title: AUTOMATIC UPDATES AND CRON JOBS
content:
<b>update-usbids</b> is frequently configured to run as a daily or weekly cron job. This ensures that the system's USB ID database is always up-to-date without requiring manual execution. For example, a common cron entry might look like:<br><br><I>0 3 * * * /usr/sbin/update-usbids --quiet</I><br><br>This command would run quietly at 3:00 AM every day, checking for and installing the latest USB ID list.


title: THE IMPORTANCE OF USB.IDS
content:
The <I>usb.ids</I> file acts as a dictionary for USB devices. Without it, tools like <I>lsusb</I> would only show generic vendor and product IDs (e.g., <I>ID 1234:5678</I>). The <I>usb.ids</I> file translates these into human-readable names (e.g., <I>ID 1234:5678 Microsoft Corp. Optical Mouse</I>), significantly improving system administration and troubleshooting by making device identification straightforward.


title: HISTORY
content:
The <b>update-usbids</b> command is part of the <I>usbutils</I> or <I>hwdata</I> package, which provides utilities for inspecting USB devices. Its development is tied to the need for human-readable identification of USB hardware. As the number of USB devices proliferated, maintaining an up-to-date database became essential. This command was created to automate the process of keeping the <I>usb.ids</I> file current, ensuring that new devices are recognized without manual intervention. It has been a standard component in many Linux distributions for years, facilitating robust USB device management.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br>


title: DESCRIPTION
content:
<i>updpkgsums</i> is an Arch Linux utility designed to simplify the maintenance of <B>PKGBUILD</B> files. It automates the process of updating source checksums (MD5, SHA1, SHA256, SHA512, B2) when upstream source files for a package change. This command is particularly useful when <B>makepkg</B> fails during the integrity check step, indicating that the locally stored checksums in the <B>PKGBUILD</B> no longer match the downloaded source files. By executing <i>updpkgsums</i> in the directory containing the <B>PKGBUILD</B>, it fetches the new checksums directly from the sources and updates the <B>PKGBUILD</B> file in place. This eliminates the need for manual inspection and recalculation of checksums, streamlining the package building process for developers and users of the Arch User Repository (AUR). It relies on <B>makepkg</B> to perform the actual source fetching and checksum calculation, then parses the output to modify the <B>PKGBUILD</B>.


title: CAVEATS
content:
<i>updpkgsums</i> modifies the <B>PKGBUILD</B> file directly and in-place. It is highly recommended to back up your <B>PKGBUILD</B> before running the command, especially for critical or complex build files. The utility requires the <B>PKGBUILD</B> file to be present in the current working directory or accessible. It also relies on the source URLs in the <B>PKGBUILD</B> being valid and accessible for fetching new checksums. If a source URL has changed or is no longer available, <i>updpkgsums</i> may fail to update the checksums correctly. Ensure you have an active internet connection if sources are remote.


title: INTERACTION WITH MAKEPKG AND SRCINFO
content:
Internally, <i>updpkgsums</i> executes <b>makepkg --printsrcinfo</b> to generate a <B>.SRCINFO</B> file, which contains the calculated checksums for the sources. It then parses this <B>.SRCINFO</B> output to extract the correct checksums and updates the corresponding <B>md5sums</B>, <B>sha1sums</B>, <B>sha256sums</B>, <B>sha512sums</B>, or <B>b2sums</B> arrays within the <B>PKGBUILD</B>. This method ensures consistency with how <B>makepkg</B> itself verifies integrity.


title: COMMON USE CASE
content:
This command is invaluable for anyone managing packages from the Arch User Repository (AUR). When an AUR package fails to build with a 'validating source files with <I>checksum</I>... FAILED' error, <i>updpkgsums</i> is often the first command to try. Running it in the package's directory typically resolves the checksum mismatch, allowing <B>makepkg</B> to proceed with the build.


title: HISTORY
content:
<i>updpkgsums</i> is part of the <B>pacman-contrib</B> package, a collection of useful scripts and tools complementing the <B>pacman</B> package manager in Arch Linux. Its development is closely tied to the Arch Linux ecosystem's philosophy of source-based packaging via <B>PKGBUILD</B>s. It was introduced to address the common challenge faced by package maintainers and users of the Arch User Repository (AUR) when upstream software updates lead to checksum mismatches, simplifying the maintenance workload.


title: PARAMETERS
content:
<b>-o &lt;<i>file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write output to the specified <i>file</i> instead of modifying the original.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress the specified <i>UPX</i>-compressed files.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List information about <i>UPX</i>-compressed files without decompressing them.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test the integrity of <i>UPX</i>-compressed files.<br><br><b>-9 (or --best)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply the best possible compression ratio, which can be slower but results in smaller files.<br><br><b>-0 (or --no-compress)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not compress; simply copy the files. Useful for testing or changing formats.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the <i>UPX</i> version information and exit.<br><br><b>-k (or --keep-section-info)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keep additional section information, which can be useful for debugging purposes but slightly increases file size.<br><br><b>-f (or --force)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force overwriting existing files without prompting.<br><br><b>-q (or --quiet)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress most output messages during operation.<br><br><b>-v (or --verbose)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the compression/decompression process.<br><br><b>-V (or --very-verbose)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable very verbose output, providing even more detailed information.<br><br><b>--ultra-fast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the fastest compression method available, sacrificing some compression ratio for speed.<br><br><b>--ultra-brute</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Try all available compression methods to achieve the highest possible compression, which can be extremely slow.<br><br><b>-c &lt;<i>method</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select a specific compression method, e.g., <b>lzma</b>, <b>NRV</b>, <b>zlib</b>.<br><br>


title: DESCRIPTION
content:
<i>UPX</i>, the <b>Ultimate Packer for eXecutables</b>, is a free, portable, and high-performance executable packer.<br><br>It employs a unique decompression method that allows executables to be compressed without requiring any runtime libraries or temporary files. When an <i>UPX</i>-compressed program starts, it rapidly decompresses itself directly into memory, ensuring fast startup times. This tool is widely used to significantly reduce the size of executables, often by 50-80%, which is beneficial for distribution, reducing download times, and saving disk space.<br><br><i>UPX</i> supports a broad array of executable formats across various operating systems, including <b>Linux</b>, <b>Windows</b>, <b>macOS</b>, and <b>DOS</b>, making it a versatile utility for developers and system administrators.


title: CAVEATS
content:
<b><i>Antivirus Flagging:</i></b> <i>UPX</i>-compressed executables can sometimes be flagged by antivirus software as suspicious due to their runtime self-decompression mechanism, which is also utilized by some malware.<br><br><b><i>Debugging Challenges:</i></b> Debugging an <i>UPX</i>-packed executable can be more challenging. Debuggers initially see the compressed code, potentially requiring special tools or manual unpacking.<br><br><b><i>Platform/Format Specificity:</i></b> While highly versatile, <i>UPX</i> does not support every single executable format or platform permutation. Always test compressed binaries thoroughly on target systems.<br><br><b><i>Performance Overhead:</i></b> Although <i>UPX</i>'s decompression overhead is minimal, for extremely small and frequently executed programs, it could theoretically introduce a negligible performance impact during startup.


title: HOW <I>UPX</I> WORKS
content:
<i>UPX</i> operates by compressing the executable code and data, then appending a small decompression stub to the beginning of the modified file. When the packed executable is run, this stub takes control, decompresses the original executable data directly into memory, and then transfers control to the original entry point. This entire process is self-contained, meaning no temporary files are created on disk, and no external decompression libraries are needed. The executable remains fully functional and directly runnable after compression.


title: SUPPORTED FORMATS (EXAMPLES)
content:
<i>UPX</i> supports a wide variety of executable formats across different operating systems and architectures. Key examples include:<br><ul><li><b>ELF</b> (Executable and Linkable Format) for Linux and Unix-like systems.</li><li><b>PE</b> (Portable Executable) for Windows operating systems.</li><li><b>Mach-O</b> for macOS.</li><li>Various <b>DOS</b> formats (COM, EXE, SYS).</li></ul>It also supports architectures such as <b>x86</b>, <b>x64</b>, <b>ARM</b>, and <b>PowerPC</b>.


title: HISTORY
content:
<i>UPX</i> was originally created by <b>Markus Oberhumer</b> and <b>Laszlo Molnar</b>, with its first public release in 1999.<br><br>It quickly gained popularity for its exceptionally high compression ratios and extremely fast in-memory decompression, even on older hardware. <i>UPX</i>'s design eliminated the need for a separate decompressor or runtime library, making it a highly desirable tool for reducing executable sizes for distribution and storage. The project continues to be actively maintained and updated, supporting new executable formats and operating systems.


title: SEE ALSO
content:
<b>gzip(1)</b>: General-purpose file compression utility., <b>tar(1)</b>: Archiving utility often used in conjunction with compression tools., <b>objdump(1)</b>: Displays information from object files., <b>readelf(1)</b>: Displays information about ELF format files.


title: PARAMETERS
content:
<b><b>-f</b>, <b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not daemonize; run in the foreground. Useful for debugging.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase logging verbosity. Can be used multiple times (e.g., <b>-vvv</b>).<br><br><b><b>-u</b> <I>USER</I>, <b>--user</b> <I>USER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Drop privileges to the specified user after startup.<br><br><b><b>-U</b> <I>UUID</I>, <b>--uuid</b> <I>UUID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listen only for a device with the specified unique identifier.<br><br><b><b>-x</b>, <b>--exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exit the daemon when the last connected device is detached.<br><br><b><b>-p</b> <I>PORT</I>, <b>--port</b> <I>PORT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Listen on a specific TCP port instead of the default <b>27015</b>.<br><br><b><b>-P</b> <I>FILE</I>, <b>--pid-file</b> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write the process ID (PID) to the specified file.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i>usbmuxd</i> is a crucial background service (daemon) that facilitates communication between Linux systems and Apple iOS devices (iPhones, iPads, iPods) via USB. It acts as a <i>multiplexer</i>, allowing multiple programs on the host computer to simultaneously connect to various services running on a single iOS device over a single USB cable.<br><br>When an iOS device is connected, <i>usbmuxd</i> detects it, establishes a USB connection, and then exposes the device's services (like file transfer, debugging, backup, etc.) as TCP ports on the local machine (e.g., <b>localhost:4000</b>). This abstraction allows user-space applications to interact with the device as if it were a network service, simplifying development and usage for tools like <i>libimobiledevice</i> utilities, iTunes alternatives, and development environments. It's an essential component for any non-Apple operating system to properly interact with iOS devices.


title: CAVEATS
content:
Requires correct <i>udev</i> rules for proper device detection and permissions.<br>Potential conflicts with other USB or device management software if not configured properly.<br>Relies heavily on the <i>libimobiledevice</i> ecosystem; issues often relate to its dependencies or setup.


title: DAEMON OPERATION
content:
<i>usbmuxd</i> typically runs as a system daemon, automatically starting at boot and monitoring USB ports for iOS device connections. It ensures continuous connectivity for applications.


title: DEFAULT PORT
content:
By default, <i>usbmuxd</i> listens on TCP port <b>27015</b> on <b>localhost</b> for connections from other <i>libimobiledevice</i> tools and applications.


title: UDEV INTEGRATION
content:
Proper operation requires <i>udev</i> rules to grant <i>usbmuxd</i> the necessary permissions to access USB devices and trigger its startup or operation upon device connection/disconnection events.


title: HISTORY
content:
<i>usbmuxd</i> is a core component of the <i>libimobiledevice</i> project, an open-source software library developed to communicate with Apple iOS devices natively. It was created to provide a free and cross-platform alternative to Apple's proprietary iTunes and associated libraries, enabling Linux and other non-Apple operating systems to interact with iPhones, iPads, and iPod touches.<br><br>Its development began in the late 2000s as the popularity of iOS devices grew, filling a critical gap for users and developers outside the Apple ecosystem who needed to manage or develop for these devices. It abstracts the complexities of USB communication, making it possible for higher-level tools to function reliably.


title: SYNOPSIS
content:
The <B>uuidd</B> is a system daemon and is typically not invoked directly by end-users to generate UUIDs. Instead, it runs in the background and is managed by system service managers like <I>systemd</I> (e.g., <I>systemctl start uuidd</I>). For system administrators, the daemon can be started with specific options for configuration or debugging purposes. The general syntax for direct daemon invocation (primarily for internal use or troubleshooting) is:<br><br><I>uuidd [OPTIONS]</I>


title: PARAMETERS
content:
<b>-r, --random</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Requests a new seed for the random number generator. This can be used to re-seed the daemon's internal random pool for better entropy.<br><br><b>-s <path>, --socket-path <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate Unix domain socket path where the daemon should listen for client connections. The default path is typically <I>/var/run/uuidd/request</I>.<br><br><b>-d, --debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug messages, providing more verbose output to the system log, useful for troubleshooting daemon behavior.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <B>uuidd</B> daemon and then exits.<br><br>


title: DESCRIPTION
content:
The <B>uuidd</B> command refers to the UUID generation daemon, a background service that provides high-quality, efficient UUIDs (Universally Unique Identifiers) to applications. It is part of the <I>libuuid</I> library from the <I>util-linux</I> project. Unlike <I>uuidgen</I>, which is a command-line tool for users to generate a single UUID, <B>uuidd</B> is designed to serve multiple concurrent requests from various system applications. Its primary purpose is to centralize the management of entropy sources for UUID generation, ensuring better randomness and preventing resource contention and duplicate UUIDs when many applications need to generate them frequently. By maintaining a pool of high-quality random data, <B>uuidd</B> can rapidly provide UUIDs, improving system performance and reliability for services that rely on unique identifiers. It operates as a socket-based service, allowing client applications to request UUIDs without direct access to the underlying random number generators.


title: CAVEATS
content:
It is crucial to understand that <B>uuidd</B> is a background service and not a user-facing command for generating UUIDs. End-users should use the <I>uuidgen</I>(1) command for on-demand UUID generation. Attempting to run <B>uuidd</B> manually as a regular user is generally not recommended and typically results in permission errors or unexpected behavior, as it requires system-level privileges and proper service management.


title: DAEMON VS. COMMAND-LINE TOOL
content:
<B>uuidd</B> runs continuously in the background, providing a service to other programs. This differs significantly from command-line tools like <I>uuidgen</I>, which execute once and terminate after performing their task. Applications connect to <B>uuidd</B> via a Unix domain socket to request UUIDs, leveraging the daemon's internal state for high-quality random data and improved performance.


title: SYSTEM SERVICE MANAGEMENT
content:
On modern Linux distributions, <B>uuidd</B> is typically managed by <I>systemd</I>. Its status can be checked with <I>systemctl status uuidd</I>, started with <I>systemctl start uuidd</I>, and stopped with <I>systemctl stop uuidd</I>. This ensures proper initialization, logging, and dependency management within the operating system.


title: HISTORY
content:
<B>uuidd</B> is part of the <I>libuuid</I> library, which itself is a component of the broader <I>util-linux</I> project. The <I>libuuid</I> library provides an API for generating and parsing UUIDs, and <B>uuidd</B> was introduced to provide a more robust and performant way for multiple applications to request UUIDs without each application needing to manage its own entropy pool. This centralized daemon approach helps in situations where high volumes of UUIDs are required, reducing contention and ensuring the quality of generated identifiers.


title: PARAMETERS
content:
<b>install <I>VERSION_SPEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specified Python interpreter version (e.g., <i>3.9</i>, <i>3.10.12</i>). uv will download and install the requested version if not already present.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the Python interpreter versions managed or known by uv on your system.<br><br><b>pin <I>VERSION_SPEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pins a specific Python interpreter version for the current directory by creating a <i>.python-version</i> file, similar to <i>pyenv local</i>.<br><br><b>find</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Locates Python interpreters available on the system, including those installed by uv or other means.<br><br><b>--with <I>TOOL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Common Option for 'install') Installs additional tools alongside the Python interpreter, such as 'pip' or 'venv'. Example: <i>--with pip</i>.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Common Option) Forces an operation, such as re-installing an interpreter that already exists.<br><br><b>--target <I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Common Option for 'install') Specifies the directory where the Python interpreter should be installed. By default, uv manages interpreters in a central location.<br><br>


title: DESCRIPTION
content:
<i><b>uv python</b></i> is a subcommand of the <I>uv</I> tool, a high-performance Python package installer and resolver written in Rust. While <I>uv</I> itself primarily replaces <I>pip</I> and <I>venv</I>, the <I>uv python</I> subcommand extends its capabilities to directly manage Python interpreters. It offers functionality to install specific Python versions, list available or installed interpreters, and pin project-specific Python versions, similar to tools like <I>pyenv</I>. This integration streamlines the entire Python development workflow, allowing users to manage both environments and packages with a single, incredibly fast utility. Its focus on speed and reliability makes it an attractive alternative for developers seeking a more efficient way to handle their Python toolchain.<br><br>It aims to be a modern, all-in-one replacement for many common Python environment and package management tasks.


title: CAVEATS
content:
<i><b>uv</b></i> and its <i><b>uv python</b></i> subcommand are relatively new tools, actively under development. While extremely fast and robust, they may not yet cover all niche use cases or offer the full configurability of more established tools like <I>pyenv</I> or <I>conda</I>.<br><br>Ensure you have the necessary system dependencies (like build tools for some Python versions) if installing from source.


title: SPEED AND PERFORMANCE
content:
Built in Rust, <I><b>uv python</b></I> inherits the performance benefits of <I>uv</I>, offering significantly faster Python interpreter installation and management compared to traditional methods. This speed is a core design principle, making it ideal for CI/CD pipelines and developer workflows.


title: INTEGRATION WITH UV ECOSYSTEM
content:
The <I><b>uv python</b></I> command is seamlessly integrated into the broader <I>uv</I> ecosystem. This means you can use <I>uv</I> to install packages into Python environments managed by <I><b>uv python</b></I>, providing a cohesive and high-performance experience for your entire Python development setup.


title: HISTORY
content:
<I><b>uv</b></I> was developed by Astral, the creators of the popular Rust-based linter and formatter <I>Ruff</I>. It was publicly announced in early 2024, aiming to address the performance shortcomings of existing Python packaging and environment management tools. The <I><b>uv python</b></I> subcommand was introduced to further consolidate Python tooling, allowing developers to manage both Python interpreters and packages with a single, highly optimized utility.


title: PARAMETERS
content:
<b><b>-l</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available controls and their current values for the selected device.<br><br><b><b>-g</b> <i><control_name></i>, <b>--get</b> <i><control_name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Retrieves the current value of the specified control (e.g., 'Brightness').<br><br><b><b>-s</b> <i><control_name></i> <i><value></i>, <b>--set</b> <i><control_name></i> <i><value></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specified control to the given value (e.g., 'Brightness' 128).<br><br><b><b>-d</b> <i><device_node></i>, <b>--device</b> <i><device_node></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the V4L2 device node to operate on (e.g., <i>/dev/video1</i>). Defaults to <i>/dev/video0</i>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information during operations.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>-f</b>, <b>--list-formats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists supported video formats (resolutions and pixel formats) for the device.<br><br><b><b>-i</b>, <b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general information about the connected UVC device.<br><br><b><b>-L</b>, <b>--list-presets</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists available camera presets that have been saved.<br><br><b><b>-P</b> <i><preset_id></i>, <b>--set-preset</b> <i><preset_id></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a previously saved camera preset by its ID.<br><br><b><b>-S</b> <i><preset_id></i>, <b>--save-preset</b> <i><preset_id></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current camera settings as a new preset with the specified ID.<br><br><b><b>-p</b> <i><preset_file></i>, <b>--load-preset</b> <i><preset_file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads camera settings from a specified XML preset file.<br><br><b><b>-o</b> <i><output_file></i>, <b>--output-file</b> <i><output_file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current device settings to an XML file.<br><br>


title: DESCRIPTION
content:
<i>uvcdynctrl</i> is a command-line utility designed for dynamically controlling USB Video Class (UVC) devices, commonly webcams. It provides an interface to list, get, and set various video properties such as brightness, contrast, exposure, and white balance. This tool interacts directly with the Linux Video4Linux2 (V4L2) kernel interface, allowing users to manipulate device controls that might not be easily accessible through graphical user interfaces. It's particularly useful for scripting camera adjustments, debugging video input, or fine-tuning webcam behavior for specific applications. While <i>v4l2-ctl</i> offers broader V4L2 control, <i>uvcdynctrl</i> focuses specifically on the dynamic capabilities of UVC compliant devices, making it a powerful tool for custom camera configurations.


title: CAVEATS
content:
<ul><li>Requires appropriate permissions to access <i>/dev/videoX</i> devices; often requires <i>sudo</i>.</li><li>Not all controls are supported by every UVC device, as devices implement a subset of the UVC standard.</li><li>Control names might be case-sensitive or vary slightly depending on the device and kernel version.</li><li>For broader V4L2 device control and more active development, <i>v4l2-ctl</i> is often recommended as an alternative.</li></ul>


title: COMMON USAGE EXAMPLES
content:
<ul><li><i>List all available controls and their current values:</i><br><b>uvcdynctrl -l</b></li><br><li><i>Set the 'Brightness' control to a value of 128:</i><br><b>uvcdynctrl -s "Brightness" 128</b></li><br><li><i>Get the current value of the 'Exposure, Auto' control:</i><br><b>uvcdynctrl -g "Exposure, Auto"</b></li><br><li><i>Operate on a specific device (e.g., /dev/video1) to set 'Contrast':</i><br><b>uvcdynctrl -d /dev/video1 -s "Contrast" 100</b></li></ul>


title: HISTORY
content:
<i>uvcdynctrl</i> emerged as a command-line tool within the <i>libwebcam</i> project, specifically designed to offer detailed control over USB Video Class (UVC) compliant cameras. Its development aimed to bridge the gap in easily accessible controls for webcam settings, leveraging the Video4Linux2 (V4L2) API in the Linux kernel. It provided a direct method for users and scripts to manipulate dynamic properties of UVC devices, which were often not exposed through standard graphical applications. While <i>v4l2-ctl</i> has since become a more general-purpose and widely adopted tool for V4L2 devices, <i>uvcdynctrl</i> played a crucial role in enabling fine-grained control for UVC-specific functionalities.


title: PARAMETERS
content:
<b>-d, --device <dev></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the V4L2 device node to operate on, e.g., <I>/dev/video0</I>. If not specified, <I>/dev/video0</I> is used by default.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all available information for the selected device, including capabilities, formats, and controls.<br><br><b>-l, --list-ctrls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all V4L2 controls (e.g., brightness, contrast, exposure) available for the device, along with their current values, ranges, and types.<br><br><b>-c, --get-ctrl <ctrl_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gets the current value of a specific control by its name.<br><br><b>-C, --set-ctrl <ctrl_name>=<value></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the value of a specific control. Multiple controls can be set by separating them with commas (e.g., <I>brightness=128,contrast=64</I>).<br><br><b>-P, --list-formats</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all supported video capture formats (pixel formats and resolutions) that the device can provide.<br><br><b>-V, --get-fmt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current video input format (resolution, pixel format, field, etc.) being used by the device.<br><br><b>-v, --set-fmt <width>x<height>,<pixelformat></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the video input format. Pixel format can be specified by fourcc code (e.g., <I>YUYV</I>) or name (e.g., <I>YUYV</I>).<br><br><b>-S, --set-stream <on|off></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts or stops video streaming from the device. Requires <I>on</I> or <I>off</I> as an argument.<br><br><b>--list-devices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all detected V4L2 devices and their associated device nodes, providing an overview of available hardware.<br><br><b>--info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about the device's capabilities, driver, and kernel modules.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the command's help message and a summary of available options.<br><br>


title: DESCRIPTION
content:
The <B>v4l2-ctl</B> command is a versatile utility from the <B>v4l-utils</B> package, designed to interact with and configure Video4Linux2 (V4L2) compliant devices. These devices typically include webcams, TV tuners, capture cards, and other video input/output hardware. It provides a command-line interface to the V4L2 API, allowing users to query device capabilities, list supported video formats, set resolution and frame rates, adjust image controls (like brightness, contrast, exposure, white balance), manage video inputs/outputs, and perform basic streaming operations. It's an indispensable tool for debugging, scripting, and fine-tuning the behavior of video devices on Linux systems, particularly when graphical interfaces are unavailable or insufficient for specific configurations.


title: CAVEATS
content:
Some operations, such as changing system-wide device parameters or certain video modes, may require root privileges. Device behavior can vary significantly based on the specific hardware and its V4L2 driver implementation. Not all options or controls are supported by all V4L2 devices. Always consult the device's documentation or experiment cautiously.


title: COMMON CONTROL TYPES
content:
V4L2 controls are categorized by type, such as <I>integer</I> (e.g., brightness, contrast), <I>boolean</I> (e.g., auto exposure), <I>menu</I> (e.g., power line frequency), <I>bitmask</I>, or <I>string</I>. When setting controls using <B>--set-ctrl</B>, ensure the provided value matches the expected type for that control, which can be determined by first listing controls with <B>--list-ctrls</B>.


title: STREAMING OPTIONS
content:
While <B>v4l2-ctl</B> can initiate basic streaming using <B>--set-stream</B>, it also supports more advanced streaming options for testing purposes. These include <B>--stream-to <file></B> for saving raw video data to a file, <B>--stream-count <num></B> for limiting the number of frames to capture, and specifying buffer memory types with <B>--stream-mmap</B> or <B>--stream-userptr</B>.


title: HISTORY
content:
The <B>v4l2-ctl</B> command is part of the <I>v4l-utils</I> project, which provides a collection of tools for the Video4Linux2 API. V4L2 itself is the second generation of the Linux kernel's video device interface, superseding the original Video4Linux (V4L) API. It was developed to offer a more robust and flexible framework for handling video capture, output, and processing devices. <B>v4l2-ctl</B> emerged as the primary command-line interface for testing, debugging, and configuring these devices, reflecting the ongoing evolution of multimedia support in the Linux kernel.


title: SYNOPSIS
content:
<b>vagrant plugin install</b> <i>&lt;name&gt;</i> [<i>&lt;name2&gt;</i> ...] [<b>--plugin-version</b> <i>&lt;version&gt;</i>] [<b>--plugin-source</b> <i>&lt;source&gt;</i>] [<b>--local</b>] [<b>--no-install-deps</b>] [<b>--system</b>]<br><b>vagrant plugin uninstall</b> <i>&lt;name&gt;</i> [<i>&lt;name2&gt;</i> ...] [<b>--system</b>]<br><b>vagrant plugin list</b><br><b>vagrant plugin update</b> [<i>&lt;name&gt;</i> [<i>&lt;name2&gt;</i> ...]] [<b>--plugin-version</b> <i>&lt;version&gt;</i>] [<b>--plugin-source</b> <i>&lt;source&gt;</i>] [<b>--system</b>]<br><b>vagrant plugin license</b> <i>&lt;name&gt; &lt;path_to_license_file&gt;</i>


title: PARAMETERS
content:
<b><i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <b>name of the plugin</b> (Ruby gem) to install, uninstall, update, or license. Multiple names can be specified for `install`, `uninstall`, and `update` subcommands.<br><br><b><b>--plugin-version</b> <i>&lt;version&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a <b>specific version</b> of the plugin to install or update to. If omitted, the latest compatible version is used. Applicable to `install` and `update`.<br><br><b><b>--plugin-source</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an <b>alternative RubyGems source</b> URL from which to download the plugin. This is useful for private gem servers or custom repositories. Applicable to `install` and `update`.<br><br><b><b>--local</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the `install` subcommand to treat <i>&lt;name&gt;</i> as a <b>local gem file path</b> (e.g., <code>/path/to/my-plugin-1.0.0.gem</code>) rather than a remote gem name from RubyGems.org.<br><br><b><b>--no-install-deps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When installing, this flag prevents Vagrant from automatically installing <b>plugin dependencies</b>. Use with caution, as this may lead to broken or non-functional plugins if dependencies are missing. Applicable to `install`.<br><br><b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Advanced)</i> Installs or uninstalls the plugin into the <b>system-wide Ruby environment</b> instead of Vagrant's isolated environment. This is generally discouraged for typical usage due to potential conflicts with other Ruby installations.<br><br><b><i>&lt;path_to_license_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;For the `license` subcommand, this is the <b>absolute path</b> to the license file required by a commercial plugin to unlock its full functionality.<br><br>


title: DESCRIPTION
content:
The `vagrant plugin` command is a powerful subcommand of Vagrant that allows users to <i>seamlessly manage extensions</i> to Vagrant's core functionality. These plugins significantly expand Vagrant's capabilities, enabling support for new virtualization providers (e.g., Hyper-V, VMware), integrating additional provisioners (e.g., Puppet Apply, Chef Solo), facilitating different communication methods, and offering custom synced folder types. This command provides a unified and user-friendly interface to <b>install new plugins</b> from remote sources or local files, <b>uninstall existing ones</b>, <b>list currently installed plugins</b> with their versions, and <b>update them</b> to their latest compatible versions. Underneath, it leverages the RubyGems package manager to handle the actual gem installation and management, abstracting away the complexities from the user. It's an essential tool for customizing and extending your Vagrant workflows.


title: CAVEATS
content:
<b>Key considerations and limitations:</b><br><br><i>1. Internet Dependency:</i> Most plugin operations (install, update) require an active internet connection to download gems from RubyGems.org or specified sources.<br><br><i>2. RubyGems Reliance:</i> Plugins are Ruby gems and operations rely on the underlying RubyGems ecosystem. Issues with RubyGems configuration or network connectivity can prevent successful operations.<br><br><i>3. System Flag Caution:</i> Using the <b>--system</b> flag can lead to conflicts with other Ruby installations or system-wide gems and is generally not recommended for typical Vagrant usage. Use with extreme caution.<br><br><i>4. Compatibility:</i> Always ensure plugin compatibility with your specific Vagrant version before installation to avoid unexpected behavior.


title: PLUGIN DISCOVERY
content:
Plugins are primarily discovered on <b>RubyGems.org</b>, the official gem hosting service. You can search for 'vagrant-' prefixed gems, or consult the official Vagrant documentation and community resources for recommended plugins. The `<b>vagrant plugin list</b>` command shows all plugins currently installed in your Vagrant environment, including their versions.


title: COMMERCIAL PLUGINS AND LICENSING
content:
While a vast majority of Vagrant plugins are open-source and free, some are commercial offerings (e.g., the Vagrant VMware Fusion provider). For these, you typically need to purchase a license. The `<b>vagrant plugin license</b>` subcommand is specifically designed to apply these license files to your installed commercial plugins, thereby unlocking their full functionality.


title: HISTORY
content:
Plugin support has been a cornerstone of Vagrant's extensibility since its early versions. Initially, users might have manually installed RubyGems. The dedicated `vagrant plugin` subcommand was introduced to <b>streamline and standardize</b> this process, making it significantly easier for users to extend Vagrant's functionality without deep knowledge of RubyGems. This command has continuously evolved to provide a robust and user-friendly interface for managing the rich ecosystem of Vagrant plugins, solidifying its role as a key feature.


title: SYNOPSIS
content:
<b>VBoxClient</b> [<i>OPTIONS</i>] [<i>COMMANDS</i>]<br><i>Examples</i>:<br>&nbsp;&nbsp;<b>VBoxClient --clipboard --draganddrop</b><br>&nbsp;&nbsp;<b>VBoxClient --seamless</b>


title: PARAMETERS
content:
<b><b>--clipboard</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables and manages the shared clipboard functionality between the host and guest operating systems, allowing text and other data to be copied and pasted across the virtual machine boundary.<br><br><b><b>--draganddrop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates the drag and drop feature, enabling users to move files and folders directly between the host desktop and the guest desktop environment.<br><br><b><b>--seamless</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables seamless window mode, which allows individual windows from the guest operating system to appear on the host desktop as if they were native host applications, providing a more integrated experience.<br><br><b><b>--display-auto-resize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Monitors the guest display resolution and automatically resizes it to match the VirtualBox viewer window size, providing a fluid and adaptable display experience.<br><br><b><b>--checkhostsystem</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Queries the host system for capabilities related to certain guest integration features and reports them to the guest.<br><br><b><b>--vmsvga</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates specific enhancements for the VMSVGA 3D graphics controller, improving graphics performance and features within the guest operating system.<br><br><b><b>--vbgcc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables guest control functionality, which allows the host to execute commands and manage processes within the guest operating system.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>VBoxClient</i> utility and then exits.<br><br><b><b>-d</b> <i>&lt;display_string&gt;</i>, <b>--display</b> <i>&lt;display_string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to connect to, which is typically used in X11 environments for graphical features managed by <i>VBoxClient</i>.<br><br><b><b>-n</b>, <b>--nodisplay</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>VBoxClient</i> from attempting to connect to an X display, useful for non-graphical or headless environments where display features are not required.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output messages from <i>VBoxClient</i>, making it run more silently without verbose feedback.<br><br>


title: DESCRIPTION
content:
<i>VBoxClient</i> is a crucial component of VirtualBox Guest Additions, installed within a guest operating system. It facilitates seamless integration between the guest and host machines, enhancing the user experience by providing essential features such as shared clipboard, drag and drop support, automatic display resizing, and seamless window mode. This utility typically runs in the background, often started automatically as part of the Guest Additions services upon the guest's desktop environment startup. Without <i>VBoxClient</i> and its associated processes, many of the convenient integration features that improve the usability of VirtualBox virtual machines would not function, limiting interaction between the host and guest.


title: CAVEATS
content:
<i>VBoxClient</i> relies entirely on the presence and proper installation of VirtualBox Guest Additions within the guest operating system. If Guest Additions are not installed, are outdated, or are corrupted, <i>VBoxClient</i> functionalities will be unavailable or unstable. Some features might also require specific VirtualBox machine settings (e.g., shared clipboard enabled for bidirectional) or a compatible host environment. Ensure that the <i>VBoxService</i> daemon is running in the guest for optimal operation, as <i>VBoxClient</i> often interacts with it.


title: AUTOMATIC STARTUP
content:
<i>VBoxClient</i> processes (such as for clipboard, drag and drop, and seamless mode) are typically initiated automatically upon the guest user's login to their desktop environment. This automatic startup is managed either by the <i>VBoxService</i> daemon or through desktop environment autostart entries that are configured during the VirtualBox Guest Additions installation. This ensures that the various integration features are immediately available without requiring manual user intervention after the guest OS boots, contributing to a seamless user experience.


title: HISTORY
content:
<i>VBoxClient</i> has been an integral part of VirtualBox Guest Additions since the early versions of VirtualBox, which first saw a public release in 2007. It has continuously evolved alongside VirtualBox itself, receiving updates and new features to improve guest-host integration as the virtualization platform developed its capabilities and extended support to a wider array of operating systems and hardware configurations. Its development is closely tied to Oracle's ongoing maintenance and enhancement of the VirtualBox virtualization platform.


title: SYNOPSIS
content:
<pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <i>&lt;command&gt;</i> [<i>arguments</i>]</pre><br><i>Common commands:</i><br><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>poweroff</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>reset</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>pause</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>resume</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>savestate</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>acpipowerbutton</b></pre><pre><b>VBoxControl</b> <i>&lt;vmname|uuid&gt;</i> <b>acpisleepbutton</b></pre>


title: PARAMETERS
content:
<b><i>&lt;vmname|uuid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name or UUID of the virtual machine to control. The VM must be registered with VirtualBox.<br><br><b><b>poweroff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately powers off the virtual machine. This is equivalent to pulling the plug and can lead to data loss if the guest OS is not properly shut down.<br><br><b><b>reset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a hard reset of the virtual machine, similar to pressing the reset button on a physical computer.<br><br><b><b>pause</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pauses the execution of the virtual machine, freezing its current state.<br><br><b><b>resume</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resumes the execution of a previously paused virtual machine from its frozen state.<br><br><b><b>savestate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the current state of the virtual machine to disk, allowing it to be restored later exactly where it left off.<br><br><b><b>acpipowerbutton</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends an ACPI power button signal to the guest operating system. This allows for a graceful shutdown if the guest OS supports ACPI and VirtualBox Guest Additions are installed.<br><br><b><b>acpisleepbutton</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends an ACPI sleep button signal to the guest operating system, prompting it to enter a sleep or suspend state. Requires Guest Additions.<br><br>


title: DESCRIPTION
content:
<b>VBoxControl</b> is a command-line utility provided with Oracle VirtualBox that allows users to manage the operational state of VirtualBox virtual machines. Unlike the broader <b>VBoxManage</b> command, <b>VBoxControl</b> primarily focuses on runtime control actions such as powering off, resetting, pausing, resuming, or saving the state of a VM. It is an essential tool for scripting and automating VirtualBox environments, enabling unattended management of VMs for tasks like testing, server management, or continuous integration pipelines. This command provides a direct interface to manipulate a VM's lifecycle without needing the VirtualBox GUI.


title: CAVEATS
content:
<ul><li><b>VBoxControl</b> requires Oracle VirtualBox to be installed on the system.</li><li>For graceful shutdown (<b>acpipowerbutton</b>) and sleep (<b>acpisleepbutton</b>) commands to function correctly, VirtualBox Guest Additions must be installed within the guest operating system.</li><li>Using <b>poweroff</b> can lead to data corruption or loss within the guest OS if the system is not properly shut down before the command is issued. Use with caution.</li><li>The command expects the VM name or UUID to uniquely identify the target virtual machine. If multiple VMs have the same name, it is advisable to use the UUID.</li></ul>


title: USAGE IN SCRIPTING
content:
<b>VBoxControl</b> is frequently used in shell scripts for automating VM operations. For instance, it can be integrated into CI/CD pipelines to start, test, and then shut down virtual environments, or used in system administration tasks for scheduled backups or maintenance. Its simple syntax makes it ideal for quick command-line invocations.


title: DISTINCTION FROM GUESTCONTROL
content:
While <b>VBoxControl</b> manipulates the VM from the host, VirtualBox also offers <b>VBoxManage guestcontrol</b> which allows execution of commands <i>within</i> the guest OS (if Guest Additions are running) and file transfer. <b>VBoxControl</b> operates at a lower level, managing the VM's hardware-level state.


title: HISTORY
content:
<b>VBoxControl</b> has been an integral part of the VirtualBox command-line toolkit since early versions. While <b>VBoxManage</b> provides a comprehensive suite of management functions, <b>VBoxControl</b> specifically addresses the need for straightforward, direct control over a VM's power and runtime state. Its consistent availability across VirtualBox versions underscores its utility in scripting and automation workflows, reflecting VirtualBox's commitment to providing robust command-line interfaces for all core operations.


title: SEE ALSO
content:
VBoxManage(1): The primary command-line tool for managing all aspects of VirtualBox, including VM creation, modification, network settings, and broader control. <b>VBoxControl</b>'s functions are a subset of <b>VBoxManage</b>'s capabilities, specifically focused on VM runtime state., VBoxSDL(1): A utility to run VirtualBox VMs in an SDL window.


title: PARAMETERS
content:
<b><b>list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists registered VMs, host-only interfaces, host-only adapters, running VMs, etc.<br><br><b><b>createvm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new virtual machine definition, but does not configure it.<br><br><b><b>registervm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Registers an existing virtual machine definition (<i>.vbox</i> file).<br><br><b><b>unregistervm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unregisters a virtual machine, optionally deleting its associated files.<br><br><b><b>startvm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts an existing virtual machine, either with a GUI or in headless mode.<br><br><b><b>controlvm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends control commands to a running VM (e.g., <i>poweroff</i>, <i>reset</i>, <i>savestate</i>, <i>pause</i>).<br><br><b><b>modifyvm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies the settings of a virtual machine (e.g., memory, CPU count, network adapters).<br><br><b><b>showvminfo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific virtual machine.<br><br><b><b>snapshot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages snapshots for a virtual machine (e.g., <i>take</i>, <i>restore</i>, <i>delete</i>).<br><br><b><b>storageattach</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a storage medium (hard disk, CD/DVD, floppy) to a VM's controller.<br><br><b><b>hostonlyif</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages host-only network interfaces (create, remove, configure).<br><br><b><b>natnetwork</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages NAT networks, allowing VMs to share a private network and access the host network.<br><br><b><b>guestproperty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages guest properties for a running VM (read, write, wait for).<br><br><b><b>clonevm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clones an existing virtual machine, creating a duplicate instance.<br><br><b><b>import</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports a virtual appliance (<i>.ova</i> or <i>.ovf</i> file).<br><br><b><b>export</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exports a virtual machine to an appliance (<i>.ova</i> or <i>.ovf</i> file).<br><br>


title: DESCRIPTION
content:
<i>vboxmanage</i> is a powerful command-line tool that allows users to fully control and manage Oracle VirtualBox virtual machines (VMs) and their associated resources. It provides a comprehensive set of subcommands to perform tasks such as creating, starting, stopping, configuring, cloning, and deleting VMs. Users can also manage virtual hard disks, optical drives, network adapters, shared folders, snapshots, and various other VirtualBox settings directly from the terminal. This command is invaluable for scripting and automating VirtualBox operations, enabling headless server management, and integrating VM control into larger systems. It offers fine-grained control over every aspect of a VM's lifecycle and configuration, making it an essential utility for developers, system administrators, and anyone working extensively with VirtualBox.


title: CAVEATS
content:
Due to its extensive functionality, <i>vboxmanage</i> can be complex. Subcommand-specific options and their nuances often require consulting the VirtualBox manual. Error messages, while informative, can sometimes be cryptic, requiring careful interpretation. Correct paths for VM configuration files and disk images are crucial for successful operations. Interaction with the guest operating system for features like shared folders and clipboard often relies on VirtualBox Guest Additions being installed within the VM.


title: EXIT STATUS
content:
<i>vboxmanage</i> typically returns an exit status of <b>0</b> on successful execution of a subcommand. A non-zero exit status indicates an error or failure during the operation, with specific codes often indicating the nature of the issue. This allows for scripting and error handling in automated workflows.


title: HISTORY
content:
<i>vboxmanage</i> has been an integral part of Oracle VirtualBox since its early development by Innotek GmbH, continuing through Sun Microsystems' acquisition and now under Oracle. It was conceived as the primary command-line interface to allow headless operation and programmatic control of VirtualBox features. Its evolution has mirrored that of VirtualBox itself, constantly adding new subcommands and options to support an ever-expanding set of virtualization capabilities, making it indispensable for automation and server environments.


title: SYNOPSIS
content:
<i>command1</i> [<i>options</i>] [<i>arguments</i>] <b>|</b> <i>command2</i> [<i>options</i>] [<i>arguments</i>]


title: DESCRIPTION
content:
The vertical bar, <b>|</b>, is a powerful Linux shell operator known as the <i>pipe</i>. It serves as a conduit, redirecting the standard output (stdout) of the command on its left to become the standard input (stdin) of the command on its right. This allows for the creation of complex command pipelines, where the results of one program can be directly processed by another, without needing intermediate files.<br><br>This mechanism embodies the Unix philosophy of building small, sharp tools that do one thing well. By chaining these tools with pipes, users can perform sophisticated data manipulation, filtering, and transformation tasks. For instance, `ls -l | grep "\.txt" | wc -l` first lists directory contents, then filters for lines containing ".txt", and finally counts those lines. Pipes are fundamental for automation, scripting, and efficient command-line workflows.


title: CAVEATS
content:
The pipe operator itself does not have command-line options or parameters. However, the commands connected by the pipe operator will have their own distinct sets of options and arguments. Each command in a pipeline runs as a separate process, which can introduce some overhead. If any command in the pipeline fails, the subsequent commands may receive unexpected or no input, potentially leading to errors. Error messages from individual commands are typically sent to standard error (stderr) and are not piped, appearing directly on the terminal.


title: STANDARD STREAMS
content:
Understanding pipes requires knowledge of standard streams: <b>stdin</b> (standard input, typically keyboard), <b>stdout</b> (standard output, typically terminal screen), and <b>stderr</b> (standard error, also typically terminal screen). The pipe operator specifically redirects <i>stdout</i> of the left command to <i>stdin</i> of the right command. <i>stderr</i> is not piped and usually remains connected to the terminal.


title: UNIX PHILOSOPHY AND COMPOSABILITY
content:
Pipes are a prime example of the Unix philosophy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." This promotes the creation of small, specialized tools that can be combined in countless ways to achieve complex tasks, fostering reusability and flexibility.


title: HISTORY
content:
The concept of pipes was introduced by Douglas McIlroy at Bell Labs during the development of Unix in the early 1970s. It was a groundbreaking innovation that significantly contributed to the modularity and power of the Unix operating system. The pipe mechanism was inspired by McIlroy's observation that shell users frequently used temporary files to pass data between programs. The pipe provided a more elegant and efficient in-memory alternative, becoming a cornerstone of the Unix philosophy and design, allowing simple tools to be combined into powerful pipelines.


title: SYNOPSIS
content:
vim [<i>options</i>] [<i>file ...</i>]<br>vim [<i>options</i>] -<br>vim [<i>options</i>] -t <i>tag</i><br>vim [<i>options</i>] -q [<i>errorfile</i>]


title: PARAMETERS
content:
<b>+<i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start editing at line number <i>N</i>.<br><br><b>+<i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute <i>command</i> after the first file is read.<br><br><b>-c <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like +<i>command</i>, execute <i>command</i> after the first file is read.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Binary mode. Edit a binary file (sets 'binary' option).<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Diff mode. Start in diff mode, comparing up to four files.<br><br><b>-g</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start in GVim (graphical Vim) if available.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a brief help message and exit.<br><br><b>-i <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>file</i> for `viminfo` instead of the default.<br><br><b>-o[N]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open N windows, one for each file, arranged horizontally. If N is omitted, one window per file.<br><br><b>-O[N]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open N windows, one for each file, arranged vertically. If N is omitted, one window per file.<br><br><b>-R</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read-only mode. The 'readonly' option is set.<br><br><b>-s <i>scriptin</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read commands from the script file <i>scriptin</i> (like :source!).<br><br><b>-S <i>sessionfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Source <i>sessionfile</i> after loading the first file (like :source!).<br><br><b>-t <i>tag</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit the tag <i>tag</i> (uses a tags file to jump to the definition).<br><br><b>-u <i>vimrc</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use <i>vimrc</i> for initialization instead of default `~/.vimrc`.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b>-Z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restricted mode (only if compiled in). Disables shell commands and writing files.<br><br>


title: DESCRIPTION
content:
Vim, short for "Vi IMproved," is a highly configurable text editor built to enable efficient text editing. It's a modal editor, meaning it operates in different modes for specific tasks (e.g., normal, insert, visual, command-line). This modal design, while presenting a steep learning curve for newcomers, allows experienced users to perform complex editing tasks with remarkable speed and precision, often without needing to touch the mouse. <br><br>Originally developed by Bram Moolenaar in 1991 as an extension of the classic <i>vi</i> editor, Vim has evolved into a ubiquitous tool across Unix-like operating systems. Its power comes from its extensive command set, a rich plugin ecosystem, powerful scripting capabilities, and deep integration with the terminal environment. Vim is ideal for programmers, system administrators, and anyone who deals with large volumes of text or code, offering features like syntax highlighting, multi-level undo, visual mode selection, and robust search-and-replace functionalities. It's renowned for its efficiency, stability, and keyboard-centric workflow.


title: CAVEATS
content:
Vim has a <i>steep learning curve</i> due to its unique modal editing paradigm, which can be counter-intuitive for users accustomed to traditional "insert-always" editors. Mastering Vim requires dedicated practice and a willingness to learn a new way of interacting with text. Its extensive configuration options, while powerful, can also be overwhelming for beginners.


title: MODAL EDITING
content:
Vim operates in distinct modes. The primary modes are: <br><b>Normal mode</b> (command mode): For navigation and executing commands. <br><b>Insert mode</b>: For typing text. <br><b>Visual mode</b>: For selecting blocks of text. <br><b>Command-line mode</b>: For executing `ex` commands (e.g., saving, quitting, search/replace) by typing `:`.


title: CONFIGURATION (<I>.VIMRC</I>)
content:
Vim is highly customizable. Most user preferences, key mappings, and plugin configurations are stored in a plain-text file, typically `~/.vimrc` (or `_vimrc` on Windows), allowing users to tailor the editor precisely to their workflow.


title: EXTENSIBILITY (PLUGINS)
content:
Vim supports a vast ecosystem of plugins, written in Vimscript, Python, Ruby, and other languages. These plugins extend Vim's functionality, adding features like advanced file browsing, language-specific IDE features, version control integration, and much more.


title: HISTORY
content:
Vim's origins trace back to Bill Joy's <i>vi</i> editor, released in 1976 as part of the Berkeley Software Distribution (BSD) Unix. While `vi` was revolutionary, it lacked several modern features. <br><br>In 1991, Bram Moolenaar released <i>Vi IMproved</i> (Vim) for the Amiga computer, aiming to add new functionalities like multi-level undo, syntax highlighting, and a visual mode, which `vi` lacked. Over the years, Vim was ported to various platforms, including Unix, Linux, and Windows, and continuously enhanced with features like graphical user interfaces (GVim), scripting capabilities (Vimscript), and a robust plugin architecture. Its development has been driven by a strong community, making it one of the most mature, stable, and widely used text editors in the world.


title: PARAMETERS
content:
<b><i>file1 file2</i> [<i>file3</i> [<i>file4</i>]]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>The paths to the files you wish to compare. <i>vimdiff</i> supports comparing two, three, or four files simultaneously.<br><br><b><b>-O</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Opens windows vertically, splitting them side-by-side. This is often the default behavior for <i>vimdiff</i> when comparing two files.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Opens windows horizontally, splitting them one above the other.<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Opens all files in read-only mode, preventing accidental modifications while reviewing differences.<br><br><b><b>-c <i>{command}</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Executes the specified <i>{command}</i> after the first file has been loaded. This is useful for setting specific Vim options or executing functions at startup.<br><br><b><b>--clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Starts Vim in a 'clean' mode, ignoring the user's <i>.vimrc</i> and plugins. Useful for troubleshooting or ensuring a consistent diff view across different environments.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>This flag explicitly tells Vim to start in diff mode. <i>vimdiff</i> is typically a script wrapper that automatically passes this flag to the underlying <i>vim</i> executable.<br><br>


title: DESCRIPTION
content:
<b>vimdiff</b> is a powerful and interactive tool built upon the Vim text editor, specifically designed for comparing and merging differences between two, three, or even four files. It provides a visual representation of file disparities, highlighting lines that have been added, deleted, or changed. Unlike simple command-line `diff`, <b>vimdiff</b> allows users to navigate between differences, directly edit files, and interactively transfer changes (merge) from one buffer to another using intuitive commands like `<b>:diffput</b>` and `<b>:diffget</b>`. It typically opens files side-by-side or stacked, automatically scrolling them together to maintain alignment. This makes <b>vimdiff</b> an indispensable tool for tasks such as code review, resolving merge conflicts in version control systems, and efficiently understanding modifications between file versions within a highly editable environment.


title: CAVEATS
content:
<ul><li><i>vimdiff</i> requires Vim to be compiled with the <i>+diff</i> feature enabled. Most modern Vim installations include this by default.</li><li>For very large files or an extremely high number of differences, <i>vimdiff</i> can consume significant system resources (CPU and memory), potentially leading to slower performance.</li><li>The comparison is primarily line-based. While it highlights character-level differences within a line, the primary unit of change detection is the line itself.</li><li>Merging complex changes, especially in three or four-way diffs, requires careful attention and understanding of the file contents to avoid unintended data loss or incorrect merges.</li></ul>


title: INTERACTIVE DIFF COMMANDS
content:
<i>vimdiff</i> offers several crucial commands for navigating and merging differences within the editor: <br>- <b>dp</b> or <b>:diffput</b>: Copies the current difference from the active buffer to the corresponding buffer.<br>- <b>do</b> or <b>:diffget</b>: Retrieves the current difference from the corresponding buffer into the active buffer.<br>- <b>]c</b>: Jumps to the next difference (change) block.<br>- <b>[c</b>: Jumps to the previous difference (change) block.<br>- <b>zo</b>: Opens (unfolds) a folded difference block.<br>- <b>zc</b>: Closes (folds) a difference block.<br>- <b>:diffupdate</b>: Re-scans the files for differences and updates the display, useful if one of the files has been externally modified.


title: THREE-WAY AND FOUR-WAY DIFFS
content:
While commonly used for two files, <i>vimdiff</i> fully supports three-way and four-way comparisons, which are particularly useful for resolving complex merge conflicts where a common ancestor file might be involved. This allows for a more informed merge decision by visualizing the changes from a common base.


title: HISTORY
content:
The <i>diff</i> mode, which <b>vimdiff</b> leverages, was introduced in <i>Vim version 6.0</i>, released in September 2001. Prior to this, users typically relied on external `diff` tools and manually applied changes within Vim. The integration of a native, interactive diff and merge capability significantly enhanced Vim's utility for developers and system administrators, making it a robust solution for managing code versions and resolving conflicts directly within the editor environment. Its development was a natural progression to provide a more visual and editable alternative to traditional command-line diff utilities.


title: PARAMETERS
content:
<b><i>language</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional argument specifying the desired language for the tutorial. If omitted, <i>vimtutor</i> attempts to use the system's default language settings or defaults to English. Common values include 'en' for English, 'fr' for French, 'de' for German, etc. The availability of specific languages depends on the Vim installation.<br><br>


title: DESCRIPTION
content:
<i>vimtutor</i> is a command-line utility that provides a comprehensive, interactive tutorial for new users of the Vim text editor.<br>It guides beginners through the fundamental concepts and commands necessary to effectively use Vim, which is renowned for its powerful modal editing capabilities. The tutorial is designed to be self-paced, allowing users to practice commands directly within the <i>vimtutor</i> interface on a temporary copy of the lesson file.<br>Users learn essential operations such as navigating text, inserting and deleting characters, copying and pasting, searching, and saving changes. <i>vimtutor</i> intelligently tracks progress and provides immediate feedback, reinforcing learned concepts. It ensures a hands-on learning experience, making the steep learning curve often associated with Vim more manageable. By the end of the tutorial, users gain a foundational understanding of Vim's modes and core commands, empowering them to begin using the editor for everyday tasks.<br>It is an indispensable resource for anyone looking to master this highly efficient and customizable editor.


title: CAVEATS
content:
The <i>vimtutor</i> command operates by creating a temporary, writable copy of the tutorial file. Any changes made during the session are applied to this temporary copy and are not saved to the original tutorial file.<br>This ensures that the tutorial remains pristine for subsequent uses but also means that user progress or notes are not persistent across sessions.<br>Furthermore, <i>vimtutor</i> focuses solely on foundational Vim concepts; advanced features, plugins, or customization options are outside its scope.


title: TEMPORARY FILE USAGE
content:
<i>vimtutor</i> automatically creates a temporary, writable copy of the tutorial file in a user-specific temporary directory (e.g., <i>/tmp</i>). This allows users to freely edit and experiment with Vim commands without modifying the original tutorial content.<br>The temporary file is automatically deleted upon exiting <i>vimtutor</i>, ensuring a clean slate for future sessions.


title: INTERACTIVE LEARNING
content:
Unlike static documentation, <i>vimtutor</i> is designed for hands-on, interactive learning. Users are prompted to perform specific actions directly within the editor window. The tutorial then checks if the action was performed correctly and provides the next set of instructions.<br>This immediate feedback loop is crucial for reinforcing learning and building muscle memory for Vim commands.


title: LANGUAGE SUPPORT
content:
<i>vimtutor</i> supports multiple languages, allowing users to learn Vim in their native tongue. The availability of specific language versions depends on the Vim installation and the presence of corresponding language files (e.g., <i>tutor.fr</i>, <i>tutor.de</i>).<br>Users can specify their preferred language using the <i>language</i> argument when launching the command.


title: HISTORY
content:
The <i>vimtutor</i> utility is distributed as an integral part of the Vim (Vi IMproved) text editor package. Vim itself was created by Bram Moolenaar and first publicly released in 1991, building upon the foundations of the traditional <i>vi</i> editor.<br>Recognizing that <i>vi</i> and by extension Vim, presented a steep learning curve for new users due to its modal editing paradigm, <i>vimtutor</i> was developed as an accessible, interactive, and self-contained learning tool.<br>Its inclusion alongside the editor made it easier for new adopters to grasp the fundamental concepts and commands, significantly contributing to Vim's widespread adoption and enduring popularity among developers and power users.


title: SYNOPSIS
content:
<B>command</B> <I>...</I> <B>|</B> <B>vipe</B> <B>|</B> <B>another_command</B> <I>...</I><br><br>Less commonly: <B>vipe</B> <B>[options]</B> <B>[command]</B><br><br>The most common usage is within a pipeline, where <I>vipe</I> acts as an interactive filter for piped data.


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>


title: DESCRIPTION
content:
<I>vipe</I> is a utility that allows you to edit the data flowing through a Unix pipeline using your preferred text editor. Instead of directly piping the output of one command to another, you can insert <I>vipe</I> in between. <I>vipe</I> captures the input, opens it in an editor (usually determined by the <B>EDITOR</B> or <B>VISUAL</B> environment variables), waits for you to make changes and save, and then sends the modified content to its standard output. This is particularly useful for ad-hoc data manipulation, filtering, or reformatting before passing it to a subsequent command. It provides an interactive step in an otherwise non-interactive pipeline.<br><br>For example, <B>ls | vipe | grep ".txt"</B> would let you edit the <B>ls</B> output before it's filtered by <B>grep</B>.


title: CAVEATS
content:
<I>vipe</I> is not part of the standard GNU Core Utilities and might not be available on all systems by default; it's typically provided by the <B>moreutils</B> package.<br><br>It relies on the <B>EDITOR</B> or <B>VISUAL</B> environment variables to determine which editor to launch. If these are not set, it usually defaults to <B>vi</B> or <B>nano</B>.<br><br>It creates a temporary file to store the data while editing, which is then deleted upon completion. This makes it less suitable for very large data streams due to potential disk I/O and editor memory limits.


title: HOW IT WORKS
content:
<I>vipe</I> operates by reading all data from its standard input into a temporary file. It then launches the editor (specified by <B>EDITOR</B> or <B>VISUAL</B>) to open this temporary file. Once the user saves and exits the editor, <I>vipe</I> reads the (potentially modified) content of the temporary file and writes it to its standard output, finally deleting the temporary file.


title: ENVIRONMENT VARIABLES
content:
The behavior of <I>vipe</I> is heavily influenced by the <B>EDITOR</B> and <B>VISUAL</B> environment variables. If <B>VISUAL</B> is set, it takes precedence over <B>EDITOR</B>. If neither is set, <I>vipe</I> will typically fall back to a default editor like <B>vi</B> or <B>nano</B>, depending on the system configuration and its own internal defaults.


title: HISTORY
content:
<I>vipe</I> is part of the <B>moreutils</B> package, a collection of small, useful, and commonly desired Unix utilities that are not part of the traditional Core Utilities. It was created to fill common gaps in pipeline functionality, providing an interactive "pipe editor" for on-the-fly data manipulation.


title: PARAMETERS
content:
<b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Edit the shadow password file (<i>/etc/shadow</i>) instead of the standard password file (<i>/etc/passwd</i>).<br><br>


title: DESCRIPTION
content:
<b>vipw</b> provides a secure and robust method for editing the system's critical user account files: <i>/etc/passwd</i> and <i>/etc/shadow</i>. When invoked, it first locks the relevant file to prevent concurrent modifications by other processes or users, thereby avoiding file corruption. It then opens the file in the user's preferred text editor, which is determined by the <i>VISUAL</i> or <i>EDITOR</i> environment variables, defaulting to <i>vi</i> if neither is set.<br><br>Upon exiting the editor, <b>vipw</b> performs essential syntax checks on the modified file. If the syntax is valid, it saves the changes and releases the lock. This entire process ensures that these crucial system files remain in a consistent and valid state, which is paramount for user authentication and overall system security. It is an indispensable utility for system administrators managing user accounts.


title: CAVEATS
content:
Only the <i>root</i> user can execute <b>vipw</b>. Incorrect modifications to the password or shadow files can lead to serious system issues, including the inability for users (even root) to log in. Always be extremely cautious when making changes. While <b>vipw</b> includes syntax checking, it cannot prevent logical errors (e.g., deleting critical user accounts).


title: EDITOR PREFERENCE
content:
<b>vipw</b> honors the <i>VISUAL</i> and <i>EDITOR</i> environment variables to determine which text editor to launch. If <i>VISUAL</i> is set, it takes precedence. Otherwise, <i>EDITOR</i> is used. If neither variable is set, <b>vipw</b> defaults to using the <i>vi</i> editor.


title: FILE LOCKING MECHANISM
content:
To ensure exclusive access and prevent corruption, <b>vipw</b> employs a lock file (e.g., <i>/etc/ptmp</i> or <i>/etc/passwd.lock</i>) before opening the target file for editing. If <b>vipw</b> crashes or is interrupted unexpectedly, this lock file might be left behind, preventing subsequent runs until it is manually removed by the <i>root</i> user. Modern implementations are generally more robust in handling lock file cleanup.


title: SYNTAX VALIDATION
content:
After you finish editing the file and exit the editor, <b>vipw</b> parses the modified content to verify its adherence to the expected format and content rules for password or shadow files. If syntax errors are detected, it will prompt you with options to either re-edit the file to correct the errors or discard the changes and exit without saving. This crucial step prevents the installation of a malformed password file that could potentially prevent user logins or cause other system instability.


title: HISTORY
content:
<b>vipw</b> has been a fundamental utility in Unix-like operating systems for decades, providing a secure mechanism for direct manipulation of user account files. It was developed to address the critical need for safely editing sensitive system configuration files without risking corruption, especially in multi-user environments where concurrent access could lead to inconsistencies. Its design, incorporating file locking and syntax validation, established a standard for handling such critical files long before many modern configuration management tools existed. On Linux systems, it is typically part of the <i>shadow-utils</i> package, which provides essential tools for managing user and group accounts and their associated password files.


title: PARAMETERS
content:
<b>-c <I>URI</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the specified hypervisor <I>URI</I> (e.g., <I>qemu:///system</I> for local KVM).<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the hypervisor in read-only mode.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational output, showing only errors or requested data.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints timing information for operations.<br><br><b><I>command</I> (e.g., <B>list</B>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<B>virsh</B> operates as a shell, executing various subcommands. Here are some of the most commonly used subcommands:<br><br><b>list [--all | --inactive | --active]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists virtual machines (domains). Options filter by status (all, inactive, or active).<br><br><b>start <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts an inactive virtual machine by its name or ID.<br><br><b>shutdown <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gracefully shuts down a running virtual machine.<br><br><b>destroy <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forcefully stops a running virtual machine, without graceful shutdown.<br><br><b>define <I>file.xml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines a virtual machine from an XML configuration file, but does not start it.<br><br><b>undefine <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the definition of an inactive virtual machine from libvirt.<br><br><b>create <I>file.xml</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates (defines and starts) a virtual machine from an XML file.<br><br><b>dominfo <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays detailed information about a specific virtual machine.<br><br><b>net-list [--all]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists virtual networks configured in libvirt.<br><br><b>vol-list <I>pool</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists storage volumes within a specified storage pool.<br><br><b>pool-list [--all]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists storage pools managed by libvirt.<br><br><b>capabilities</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the capabilities of the hypervisor and host system.<br><br><b>version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays libvirt, hypervisor, and driver version information.<br><br><b>console <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the serial console of a running virtual machine.<br><br><b>dumpxml <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the XML configuration of a specified virtual machine.<br><br>


title: DESCRIPTION
content:
<B>virsh</B> is a powerful command-line interface tool used to manage virtual machines and hypervisors. It acts as the primary interface for the <I>libvirt</I> virtualization management library, providing a unified way to control various virtualization technologies, most notably KVM/QEMU, but also Xen, LXC, and others. Administrators use <B>virsh</B> to perform a wide range of tasks, including creating, starting, stopping, pausing, and deleting virtual machines (domains), managing virtual networks, storage pools, and storage volumes, and monitoring the status of guests and the hypervisor itself.<br><br>It supports both interactive and non-interactive modes, making it highly suitable for scripting automation. Its versatility and comprehensive feature set make it an essential tool for virtualization administrators working with libvirt-managed environments.


title: CAVEATS
content:
<ul><li><B>libvirtd Service:</B> <B>virsh</B> relies on the <I>libvirtd</I> service running on the host. Ensure it's active.</li><li><B>Permissions:</B> Many operations require root privileges or membership in the <I>libvirt</I> system group.</li><li><B>XML Configuration:</B> Advanced management often necessitates a deep understanding of libvirt's XML format for domain, network, and storage definitions.</li><li><B>Connection:</B> Default connection is to the local system (e.g., <I>qemu:///system</I>). Remote management requires proper URI specification and authentication setup.</li></ul>


title: INTERACTIVE MODE
content:
When invoked without any arguments (simply <B>virsh</B>), the command enters an interactive shell mode, allowing users to type subcommands at a prompt.


title: SCRIPTING CAPABILITIES
content:
Due to its clear command structure and the ability to suppress verbose output with <B>-q</B>, <B>virsh</B> is exceptionally well-suited for shell scripting and automation of virtualization tasks.


title: XML CONFIGURATION
content:
Libvirt extensively uses an XML format for defining virtual machines (domains), networks, and storage. <B>virsh</B> commands like <B>define</B>, <B>dumpxml</B>, and <B>edit</B> directly interact with these XML definitions, providing powerful configuration options.


title: HISTORY
content:
<B>virsh</B> is an integral part of the <I>libvirt</I> project, which was initiated in 2005. Libvirt was conceived to provide a stable and unified API for managing diverse virtualization technologies, abstracting away hypervisor-specific complexities. <B>virsh</B> quickly became the primary command-line interface for interacting with this powerful API. Its development has consistently mirrored the evolution of libvirt itself, continuously expanding its capabilities to support new hypervisors (like KVM/QEMU, Xen), features, and storage backends. Today, it stands as a de facto standard for command-line virtualization management on Linux.


title: PARAMETERS
content:
<b><i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the connection URI for the hypervisor. This can be a local connection (e.g., <i>qemu:///system</i>, <i>xen:///</i>) or a remote connection (e.g., <i>qemu+ssh://user@host/system</i>, <i>xen://remote-host/</i>). If omitted, <b>virsh-connect</b> attempts to use a default URI sourced from system configuration files or environment variables.<br><br><b><i>VIRSH_COMMAND_ARGS...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any additional arguments provided after the URI are passed directly to the underlying <b>virsh</b> command. This allows users to execute <b>virsh</b> subcommands immediately after connecting, for example, <i>virsh-connect qemu:///system list --all</i>.<br><br>


title: DESCRIPTION
content:
The <b>virsh-connect</b> command is a convenience wrapper script that simplifies establishing a connection for the <b>virsh</b> command-line utility to a hypervisor. While <b>virsh</b> directly supports connection URIs via its <i>-c</i> or <i>--connect</i> option (e.g., <i>virsh -c qemu:///system</i>), <b>virsh-connect</b> automates this process.<br><br>It can default to a URI defined in system configuration files (like <i>/etc/sysconfig/libvirtd</i> or <i>/etc/default/libvirtd</i>) or the <i>LIBVIRT_DEFAULT_URI</i> environment variable. Any arguments provided after an optional URI are passed directly to the underlying <b>virsh</b> command, making it easy to chain connection and subsequent <b>virsh</b> operations. It is particularly useful for quickly switching between different hypervisor connections without repeatedly typing long URIs.


title: CAVEATS
content:
<b>virsh-connect</b> is a shell script wrapper and might not be present on all Linux distributions by default; its availability and exact behavior can vary.<br><br>It relies on the <b>virsh</b> command being installed and accessible in the system's PATH.<br><br>The default connection URI can be influenced by environment variables (e.g., <i>LIBVIRT_DEFAULT_URI</i>) or system-specific configuration files, which might lead to unexpected connections if not aware of these settings.


title: HISTORY
content:
The <b>virsh-connect</b> helper script emerged as part of the <i>libvirt-client</i> tools to provide a more user-friendly way to manage connections for the <b>virsh</b> command. Its development focuses on simplifying the workflow for administrators who frequently switch between different hypervisor instances or need to quickly connect to a remote host, building upon the <b>virsh -c</b> functionality. It abstracts away the need to remember or type complex connection URIs by leveraging default configurations.


title: SYNOPSIS
content:
<i>virsh domblklist</i> <I>domain</I> [--details] [--paths] [--source] [--device] [--target] [--type <I>type</I>] [--config] [--live] [--persistent] [--inactive] [--all] [--driver] [--address] [--io] [--bytes] [--physical]


title: PARAMETERS
content:
<b><I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name, UUID, or ID of the virtual machine to query.<br><br><b>--details</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show detailed information for each block device, including bus type and device type.<br><br><b>--paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the source paths of the block devices on the host.<br><br><b>--source</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only display the host-side source paths of the devices.<br><br><b>--device</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only display the target device names as seen within the guest.<br><br><b>--target</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alias for --device, showing target device names.<br><br><b>--type <I>type</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter devices by a specific type (e.g., 'disk', 'cdrom', 'floppy').<br><br><b>--config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show devices from the domain's persistent XML configuration.<br><br><b>--live</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show devices currently attached to the running domain instance.<br><br><b>--persistent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to --config, shows devices from the persistent configuration.<br><br><b>--inactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show devices that are part of the inactive (pending) configuration.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all devices, combining live and configured devices.<br><br><b>--driver</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the storage driver used for the device (e.g., 'qcow2', 'raw').<br><br><b>--address</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the PCI or controller address of the device.<br><br><b>--io</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display I/O statistics for the device (requires --live).<br><br><b>--bytes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display byte statistics for the device (requires --live).<br><br><b>--physical</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the physical source details of the underlying storage, where applicable.<br><br>


title: DESCRIPTION
content:
The <i>virsh domblklist</i> command provides a comprehensive overview of the block devices associated with a specified virtual machine (domain) managed by <i>libvirt</i>. It's a crucial tool for administrators to inspect the storage configuration of their virtualized environments. This command can enumerate virtual disks, CD-ROM drives, and other storage-related devices. Depending on the options used, it can display details such as the host-side source path (e.g., a file path or a LVM volume), the target device name within the guest operating system, the device type, and various operational flags like whether the device is currently active or part of the persistent configuration. It's particularly useful for verifying storage mappings, troubleshooting disk-related issues, or gathering information before performing storage-related operations like resizing or migrating disks.


title: CAVEATS
content:
Some options like <i>--io</i> or <i>--bytes</i> only provide data for live domains and may require specific driver support or a running guest agent to be accurate. The output format can vary slightly between different <i>libvirt</i> versions. Accurate information requires appropriate permissions to query domain details.


title: <B>OUTPUT INTERPRETATION</B>
content:
The default output typically shows the 'Target' (the device name inside the guest, e.g., "vda", "sdb") and 'Source' (the path to the disk image or device on the host, e.g., "/var/lib/libvirt/images/myvm.qcow2", "/dev/vg/lv_data"). The <i>--details</i> option adds columns like "Bus" (e.g., virtio, sata, ide) and "Type" (e.g., disk, cdrom).


title: <B>USAGE SCENARIOS</B>
content:
Commonly used to quickly verify if a new disk has been correctly attached to a VM, to identify the host path for a guest's disk for backup or inspection purposes, or to troubleshoot issues related to disk visibility within the guest.


title: HISTORY
content:
The <i>virsh domblklist</i> command is an integral part of the <i>libvirt</i> project, which began development in 2005. As <i>libvirt</i> evolved to support a wider range of hypervisors and advanced virtualization features, <i>domblklist</i>, along with other <i>dom*</i> commands, matured to provide increasingly detailed and granular control over virtual machine configurations. Its development closely parallels the general progress of <i>libvirt</i> itself, incorporating new options and capabilities as underlying virtualization technologies (like QEMU/KVM) added more sophisticated block device management features.


title: SEE ALSO
content:
virsh(1), virsh domblkinfo(1), virsh domblkstat(1), virsh domblkresize(1), virsh domattachdevice(1), virsh domdetachdevice(1), lsblk(8)


title: PARAMETERS
content:
<b><i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The optional name of a specific <I>virsh</I> subcommand for which to display detailed help. If this argument is omitted, <b><I>virsh help</I></b> will list all available <I>virsh</I> commands with their brief descriptions.<br><br>


title: DESCRIPTION
content:
The <b><I>virsh help</I></b> command is an essential utility for navigating and understanding the extensive capabilities of the <I>virsh</I> command-line tool, which manages virtual machines and hypervisors. When invoked without any arguments, <b><I>virsh help</I></b> provides a comprehensive list of all available <I>virsh</I> commands, each accompanied by a concise, one-line description of its function.<br><br>Alternatively, by providing a specific <I>virsh</I> command name as an argument (e.g., <b><I>virsh help list</I></b>), the command delivers detailed usage information for that particular subcommand. This detailed output typically includes the command's syntax (synopsis), a breakdown of its various options, and descriptions of its arguments. It serves as an immediate, in-terminal reference, making it easy for users to quickly look up how to use a specific <I>virsh</I> function without needing to consult external documentation or man pages. It is a cornerstone for discovery and efficient interaction with the <I>libvirt</I> ecosystem.


title: CAVEATS
content:
The output of <b><I>virsh help</I></b> can be quite extensive, especially when listing all commands. While it provides quick summaries, for the most in-depth and authoritative documentation on <I>virsh</I> and its commands, consulting the <I>man virsh</I> page or the official <I>libvirt</I> documentation is recommended. Some complex commands may have more detailed usage examples and explanations available externally.


title: USAGE FOR COMMAND DISCOVERY
content:
One of the primary uses of <b><I>virsh help</I></b> is for command discovery. Users who are new to <I>virsh</I> or are looking for a specific functionality without knowing the exact command name can run <b><I>virsh help</I></b> to browse through the list of all available commands and their brief descriptions, making it easy to find the relevant function.


title: DIFFERENCE FROM <I>MAN VIRSH</I>
content:
While <I>man virsh</I> provides a comprehensive manual page for the entire <I>virsh</I> suite, often including detailed sections on configuration, environment variables, and more, <b><I>virsh help</I></b> offers more concise, in-terminal assistance focused purely on the usage syntax and options of individual <I>virsh</I> commands. It's designed for quick reference rather than exhaustive documentation.


title: HISTORY
content:
The <b><I>virsh help</I></b> command, as a fundamental part of the <I>virsh</I> CLI, has been present since the early development stages of the <I>libvirt</I> project (which began around 2005). Its inclusion is standard for any robust command-line utility, providing essential on-demand documentation. As <I>virsh</I> has grown over the years with new commands and features, the <b><I>help</I></b> command has continually evolved by incorporating updated and expanded help texts for these additions, ensuring users always have access to current usage information directly from the terminal.


title: SYNOPSIS
content:
<b>virsh list</b> [<b>--all</b> | <b>--active</b> | <b>--inactive</b>] [<b>--detail</b>] [<b>--state</b> <i>&lt;state&gt;</i>] [<b>--persistent</b> | <b>--transient</b>] [<b>--autostart</b> | <b>--no-autostart</b>]


title: PARAMETERS
content:
<b><b>--all</b> | <b>-all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all domains, including both active (running) and inactive (e.g., shut off) ones. This provides a comprehensive view of all configured VMs.<br><br><b><b>--active</b> | <b>-active</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only active (running) domains. This is the default behavior when no options are specified.<br><br><b><b>--inactive</b> | <b>-inactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only inactive domains, which are configured but currently not running (e.g., 'shut off', 'crashed').<br><br><b><b>--persistent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only persistent domains. These domains have their configuration saved and are designed to survive host reboots.<br><br><b><b>--transient</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only transient domains. These domains' configurations are not saved persistently and are typically destroyed when they shut down or the host reboots.<br><br><b><b>--autostart</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only domains configured to automatically start when the Libvirt daemon or host boots.<br><br><b><b>--no-autostart</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only domains that are explicitly not configured for autostart.<br><br><b><b>--state</b> <i>&lt;state&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter domains by a specific operational state. Common states include <i>running</i>, <i>paused</i>, <i>shutoff</i>, <i>crashed</i>, <i>pmsuspended</i>, and <i>nostate</i>.<br><br><b><b>--detail</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display more detailed information about each domain, such as virtual CPUs, memory allocation, and current time, in addition to the standard ID, Name, and State.<br><br>


title: DESCRIPTION
content:
<i>virsh list</i> is a fundamental subcommand of the <i>virsh</i> command-line utility, which serves as the primary management interface for the Libvirt virtualization library. This command is used to display a concise summary of virtual machines, also known as 'domains', currently managed by the Libvirt daemon on the connected host. By default, <i>virsh list</i> shows active (running) domains, including their unique numeric ID, name, and current state (e.g., 'running', 'paused'). The 'Id' column represents a transient identifier assigned by Libvirt while the VM is active. The 'Name' is the domain's user-defined name, and 'State' indicates its operational status. Options allow users to filter the list by state (e.g., inactive, all) or by configuration (e.g., autostart). It's an essential tool for administrators to quickly ascertain the status of their virtualized environments.


title: CAVEATS
content:
<b>virsh list</b> requires the Libvirt daemon (<i>libvirtd</i>) to be running and accessible. Users must have appropriate permissions, typically by being root or a member of the 'libvirt' user group, to interact with the daemon. The 'Id' column for running VMs is a dynamic identifier and may change across reboots or when VMs are stopped and restarted. This command only shows VMs managed by the currently connected Libvirt instance; if multiple hypervisors or remote Libvirt hosts are in use, separate connections might be needed to view all VMs.


title: INTERPRETING OUTPUT COLUMNS
content:
When executing <b>virsh list</b>, the default output typically includes three columns: <br><i>Id</i>: A unique, transient integer identifier for the domain while it is running. This ID can change.<br><i>Name</i>: The user-defined name of the virtual machine, which is persistent.<br><i>State</i>: The current operational status of the VM, such as 'running', 'paused', 'shut off', 'crashed', etc.<br>For inactive domains, the 'Id' column will often display a '-' as they are not currently assigned an active runtime ID.


title: CONNECTING TO REMOTE LIBVIRT
content:
By default, <b>virsh list</b> connects to the local Libvirt daemon. To list VMs on a remote host, you can specify the connection URI using the <b>-c</b> or <b>--connect</b> option with the <i>virsh</i> command, e.g., <b>virsh -c qemu+ssh://user@remotehost/system list --all</b>. This allows centralized management of virtual environments.


title: HISTORY
content:
The <i>virsh</i> command-line tool, including its <i>list</i> subcommand, emerged as part of the broader Libvirt project, which began development in 2005. Libvirt was created to provide a single, stable, and long-term API for managing various virtualization technologies on Linux. As virtualization became a cornerstone of data centers and cloud computing, <i>virsh</i> quickly became an indispensable tool for system administrators and developers to interact with and oversee their virtual environments directly from the command line, offering consistent control across different hypervisors like KVM, Xen, and LXC.


title: SEE ALSO
content:
virsh(1), virsh dominfo(1), virsh start(1), virsh shutdown(1), virsh destroy(1), libvirtd(8), virt-manager(1)


title: PARAMETERS
content:
<b><i><pool-name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique name of the libvirt storage pool to configure. This name must correspond to an existing, defined storage pool.<br><br><b><b>--enable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the autostart property for the specified storage pool to 'yes'. The pool will automatically start when the libvirt daemon initializes.<br><br><b><b>--disable</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the autostart property for the specified storage pool to 'no'. The pool will not automatically start and will require manual startup using <b><I>virsh pool-start</I></b>.<br><br>


title: DESCRIPTION
content:
The phrase "virsh-pool-autostart" commonly refers to the functionality provided by the <b><I>virsh pool-autostart</I></b> command. This command is a crucial part of managing libvirt-based virtualization environments, primarily KVM and QEMU. Its purpose is to configure whether a defined storage pool should automatically start when the libvirt daemon (<b><I>libvirtd</I></b>) service initializes. <br><br>By enabling autostart for a storage pool, administrators ensure that the storage resources required by virtual machines are automatically available upon system boot or libvirt service restart, thus improving the availability and reliability of the virtualized environment. Conversely, disabling autostart prevents a pool from starting automatically, requiring manual intervention to bring it online. This command modifies the persistent configuration of the storage pool.


title: CAVEATS
content:
<b><I>Permissions:</I></b> This command typically requires root privileges or appropriate permissions configured within libvirt's PolicyKit rules. Running it as a non-privileged user may result in permission denied errors.<br><b><I>Resource Consumption:</I></b> Autostarting numerous or large storage pools can increase system boot time and resource consumption (e.g., memory, disk I/O) as libvirt attempts to activate them.<br><b><I>External Dependencies:</I></b> For storage pools that rely on external resources (e.g., NFS shares, iSCSI targets), ensure these dependencies are available and mounted/connected before libvirt attempts to start the pool at boot. Failure to do so can lead to pool startup failures.


title: CHECKING AUTOSTART STATUS
content:
To verify the autostart status of a storage pool, you can use the <b><I>virsh pool-list --all</I></b> command. The 'Autostart' column will show 'yes' or 'no' for each pool. Alternatively, <b><I>virsh pool-info <pool-name></I></b> will display detailed information, including the autostart setting.


title: LISTING STORAGE POOLS
content:
Before using <b><I>virsh pool-autostart</I></b>, you might need to identify the exact name of the storage pool. This can be done with <b><I>virsh pool-list --all</I></b>, which lists all defined storage pools, whether active or inactive.


title: HISTORY
content:
The <b><I>virsh</I></b> command-line tool and its subcommands, including <b><I>pool-autostart</I></b>, are integral parts of the <b><I>libvirt</I></b> project. Libvirt was started in 2005 to provide a common management API for various virtualization technologies (KVM, QEMU, Xen, LXC, etc.). The storage pool management features, including autostart capabilities, were developed to provide robust and automated handling of storage resources essential for virtual machines, making it easier for administrators to deploy and manage persistent virtualized environments.


title: SEE ALSO
content:
virsh(1), virsh-pool-list(1), virsh-pool-start(1), virsh-pool-destroy(1), virsh-pool-define(1), libvirtd(8)


title: PARAMETERS
content:
<b><i>&lt;pool-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <i>name</i> of the storage pool to be built or formatted. This pool must already be defined in libvirt.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds all storage pools that are currently defined but not yet built. Use with caution as this can be a destructive operation for multiple pools.<br><br>


title: DESCRIPTION
content:
The <b>virsh pool-build</b> command is used to format or 'build' a defined libvirt storage pool, making it ready for use. This operation is typically performed after a storage pool has been defined using <b>virsh pool-define</b> (or <b>virsh pool-create</b> with a definition) but before it is started (<b>virsh pool-start</b>).<br><br>The 'build' operation varies depending on the type of storage pool. For 'dir' or 'fs' type pools, it might involve creating the necessary directory structure or formatting the underlying block device (if specified to be formatted during definition). For other pool types like 'iscsi' or 'logical', it prepares the pool for volume creation. It's crucial to understand that <b>pool-build</b> can be a destructive operation, potentially erasing data on the target storage if it involves formatting.<br><br>This command is a critical step in the lifecycle of a libvirt storage pool, ensuring the storage is properly initialized and accessible for creating and managing virtual disk images (volumes).


title: CAVEATS
content:
<i><b>Data Loss:</b></i> The <b>pool-build</b> command, especially for 'dir' or 'fs' type pools that involve formatting, can be a destructive operation. Ensure you have backed up any necessary data before proceeding, as it may erase existing content on the target storage.<br><i><b>Pre-requisite:</b></i> The pool must first be <i>defined</i> using <b>virsh pool-define</b> or created with a definition, before it can be built.<br><i><b>Purpose:</b></i> This command initializes the pool for libvirt's use, but it does not necessarily create the underlying physical storage (e.g., a partition or LVM volume). That typically needs to be done beforehand.


title: POOL TYPES AND BUILD BEHAVIOR
content:
The exact action performed by <b>pool-build</b> depends on the type of storage pool being built. For example:<br><ul><li><i>'dir' type:</i> If the target directory does not exist, it will be created. If specified in the definition XML, it might also format an underlying block device.</li><li><i>'fs' type:</i> If configured to format a device, it will perform the filesystem creation (e.g., mkfs.ext4) on the specified underlying device.</li><li><i>'logical' (LVM) type:</i> It prepares the LVM volume group for creating logical volumes within it, typically without formatting the VG itself.</li><li><i>'iscsi' or 'rbd' (Ceph) type:</i> These typically don't involve a 'build' step in the same way, as the underlying storage is already managed externally. The 'build' operation for these types primarily ensures libvirt can connect and manage them.</li></ul>


title: HISTORY
content:
The <b>virsh</b> command-line utility is the primary interface for managing libvirt virtualization. <b>libvirt</b> itself was initially released in 2005 and has evolved significantly to become a standard management layer for various hypervisors. The storage pool management capabilities, including <b>pool-build</b>, have been a core part of <b>libvirt</b>'s functionality, providing robust ways to manage persistent storage for virtual machines since their early implementations.


title: SEE ALSO
content:
virsh(1), virsh pool-define(1), virsh pool-create(1), virsh pool-start(1), virsh pool-list(1), virsh pool-destroy(1), libvirt(7)


title: SYNOPSIS
content:
<b>virsh</b> <b>pool-define-as</b> <b>--name</b> <i>&lt;string&gt;</i> <b>--type</b> <i>&lt;string&gt;</i> [<b>--target</b> <i>&lt;string&gt;</i>] [<b>--source-host</b> <i>&lt;string&gt;</i>] [<b>--source-path</b> <i>&lt;string&gt;</i>] [<b>--source-dev</b> <i>&lt;string&gt;</i>] [<b>--source-name</b> <i>&lt;string&gt;</i>] [<b>--source-format</b> <i>&lt;string&gt;</i>] [<b>--source-auth</b> <i>&lt;string&gt;</i>] [<b>--source-protocol</b> <i>&lt;string&gt;</i>] [<b>--source-device-path</b> <i>&lt;string&gt;</i>] [<b>--source-adapter</b> <i>&lt;string&gt;</i>] [<b>--source-pool</b> <i>&lt;string&gt;</i>] [<b>--source-vol</b> <i>&lt;string&gt;</i>] [<b>--build</b>] [<b>--overwrite</b>] [<b>--print-xml</b>] [<b>--sparse</b>]


title: PARAMETERS
content:
<b>--name <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the unique name for the new storage pool. This name will be used to refer to the pool in other <b>virsh</b> commands.<br><br><b>--type <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the type of storage pool. Common types include: <br><i>dir</i>: A simple directory on the host filesystem.<br><i>fs</i>: A mounted filesystem.<br><i>netfs</i>: A network-mounted filesystem (e.g., NFS, CIFS).<br><i>logical</i>: A Logical Volume Management (LVM) volume group.<br><i>disk</i>: A physical disk or partition.<br><i>iscsi</i>: An iSCSI target.<br><i>scsi</i>: A SCSI host bus adapter.<br><i>mpath</i>: A multipath device.<br><i>rbd</i>: A Ceph RBD volume.<br><i>gluster</i>: A GlusterFS volume.<br><i>zfs</i>: A ZFS filesystem or volume.<br><br><b>--target <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target path for the pool. Required for 'dir', 'fs', and 'netfs' types, indicating where the pool's volumes will reside.<br><br><b>--source-host <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The hostname or IP address of the remote server for network-based pools (e.g., 'netfs', 'iscsi', 'rbd', 'gluster').<br><br><b>--source-path <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path on the source host for 'netfs', 'rbd', 'gluster' types, or the device path/name for 'logical', 'disk', 'iscsi', 'scsi', 'mpath', 'zfs'.<br><br><b>--source-dev <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An alternative or additional way to specify the source device, typically for block-based types like 'logical', 'disk', 'iscsi', 'scsi', 'mpath', 'rbd', 'gluster', 'zfs'.<br><br><b>--source-name <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the iSCSI target, RBD volume name, or Gluster volume name.<br><br><b>--source-format <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The filesystem format for 'fs' type pools (e.g., 'ext4', 'xfs').<br><br><b>--source-auth <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to an XML file containing authentication credentials for 'iscsi', 'rbd', or 'gluster' pools.<br><br><b>--source-protocol <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The protocol for 'netfs' type pools (e.g., 'nfs', 'cifs').<br><br><b>--source-device-path <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifically the full path to a physical device (e.g., /dev/sdb) for 'disk' type pools.<br><br><b>--source-adapter <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The SCSI adapter device path (e.g., /dev/sga) for 'scsi' type pools.<br><br><b>--source-pool <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the ZFS pool for 'zfs' type pools.<br><br><b>--source-vol <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the ZFS volume or dataset within the specified ZFS pool.<br><br><b>--build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately builds the storage pool after defining it. This is equivalent to running <b>virsh pool-build</b> separately.<br><br><b>--overwrite</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>--build</b> for 'fs' type, it will format and overwrite any existing data on the specified filesystem. Use with extreme caution.<br><br><b>--print-xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of defining the pool, prints the generated XML definition to standard output. This is useful for inspection or for creating XML files manually.<br><br><b>--sparse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For 'logical' (LVM) type pools, creates sparse logical volumes (thinly provisioned) by default.<br><br>


title: DESCRIPTION
content:
The <b>virsh pool-define-as</b> command is a powerful utility within the <b>virsh</b> command-line interface for <b>libvirt</b>. Its primary purpose is to create a <i>definition</i> for a new storage pool without immediately activating or building it. This allows administrators to prepare storage configurations beforehand, which can then be started or autostarted at a later time using <b>virsh pool-start</b> or <b>virsh pool-autostart</b>.<br><br>The command takes various parameters to describe the storage pool's type (e.g., directory, filesystem, network filesystem, iSCSI, LVM, ZFS, etc.) and its source location or device. By specifying these parameters directly on the command line, users avoid the need to manually craft complex XML configuration files, making the process of defining storage pools quicker and less error-prone. The generated definition is persistent across reboots until explicitly undefined, ensuring the storage resources are consistently available for virtual machines. This command is a foundational step in <b>libvirt</b>'s storage management, enabling flexible and robust allocation of storage for virtual environments.


title: CAVEATS
content:
<ul><li>The command only <i>defines</i> the pool, creating its persistent XML configuration. It does not automatically <i>start</i> the pool or make it active. Use <b>virsh pool-start &lt;name&gt;</b> to activate it.</li><li>Admin privileges (root or <b>sudo</b>) are typically required to define storage pools, as it involves system-level resource management.</li><li>Careful use of <b>--overwrite</b> is crucial as it can lead to data loss on the target device if used incorrectly with 'fs' type pools.</li><li>The specific <b>source-*</b> parameters required vary significantly based on the <b>--type</b> of the storage pool. Refer to <b>libvirt</b> documentation for detailed type-specific requirements.</li></ul>


title: XML DEFINITION BEHIND THE SCENES
content:
When you use <b>virsh pool-define-as</b>, <b>libvirt</b> internally generates an XML definition file for the storage pool. This XML file is then stored persistently, usually in <i>/etc/libvirt/storage/</i> on Linux systems. You can view this generated XML using <b>virsh pool-dumpxml &lt;pool_name&gt;</b> or by using the <b>--print-xml</b> option with <b>pool-define-as</b>. Understanding the structure of this XML can be beneficial for advanced configurations or troubleshooting.


title: STORAGE POOL TYPES AND USE CASES
content:
The variety of storage pool types supported by <b>virsh pool-define-as</b> allows <b>libvirt</b> to manage virtually any storage backend for virtual machines. For instance, 'dir' and 'fs' types are suitable for simple file-based storage, while 'logical' (LVM), 'iscsi', 'rbd' (Ceph), and 'gluster' are used for enterprise-grade, shared, or high-performance storage solutions. Choosing the correct type depends on the specific storage infrastructure and performance requirements of your virtual machines.


title: HISTORY
content:
<b>libvirt</b> itself, which <b>virsh</b> interacts with, has been under active development since 2005, providing a stable and robust virtualization management layer. The storage pool management features, including the ability to define pools from the command line, have evolved as <b>libvirt</b>'s capabilities expanded to support diverse storage backends beyond basic file-based storage. Commands like <b>pool-define-as</b> were introduced to simplify the creation of these complex storage definitions, abstracting away the need for users to manually write intricate XML files, thus improving usability and reducing potential configuration errors. Its development reflects <b>libvirt</b>'s continuous effort to provide comprehensive and user-friendly management of virtualized environments.


title: SEE ALSO
content:
virsh(1), virsh pool-start(1), virsh pool-autostart(1), virsh pool-destroy(1), virsh pool-undefine(1), virsh pool-list(1), virsh pool-edit(1), virsh pool-build(1)


title: PARAMETERS
content:
<b><I>pool-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage pool to be deleted. This is a mandatory argument that identifies the specific pool to be targeted for complete removal.<br><br><b>--metadata-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional flag. When this flag is specified, the <B>virsh pool-delete</B> command will only remove the pool's definition from libvirt's configuration. It will <I>not</I> attempt to destroy or delete the actual underlying storage data, files, or devices associated with the pool. This is useful when the physical storage is managed externally or needs to be preserved.<br><br>


title: DESCRIPTION
content:
The <B>virsh pool-delete</B> command is a powerful and destructive operation used to completely remove a previously defined storage pool from libvirt and, by default, its underlying storage resources. A storage pool represents a managed collection of physical storage, such as directories, LVM volume groups, or iSCSI targets, from which virtual machine disks (volumes) are allocated.<br><br>When this command is executed, libvirt first attempts to stop and destroy the pool's operations (e.g., unmount a filesystem, deactivate an LVM volume group) and then proceeds to permanently delete the actual data and resources associated with the pool (e.g., recursively delete a directory for a 'dir' type pool). Finally, the pool's definition is removed from the libvirt daemon.<br><br>The <I>--metadata-only</I> option is crucial for scenarios where you only wish to remove the pool's definition from libvirt while leaving the actual physical storage data and associated files or devices completely intact. It is paramount to ensure that no virtual machines are actively using volumes from the targeted pool before executing <B>pool-delete</B> without <I>--metadata-only</I>, as this will lead to irreversible data loss and potential corruption or failure of those virtual machines.


title: CAVEATS
content:
<b>Irreversible Data Loss</b>: By default, <B>virsh pool-delete</B> is a highly destructive command. It will attempt to permanently remove the underlying storage resources (e.g., delete directories, unmount filesystems, remove LVM logical volumes) managed by libvirt for the specified pool. This action is irreversible and will lead to permanent data loss for anything stored within that pool. Always ensure you have comprehensive backups or explicitly use the <I>--metadata-only</I> option if you intend to preserve the physical storage.<br><br><b>Impact on Virtual Machines</b>: If virtual machines are actively using storage volumes residing within the pool being deleted, executing <B>pool-delete</B> without the <I>--metadata-only</I> option will result in immediate failure, data corruption, or inability to boot for those virtual machines. It is absolutely critical to verify that no VMs are dependent on the pool's volumes before proceeding. Use commands such as <B>virsh vol-list</B> <I>pool-name</I> to list volumes and <B>virsh domblklist</B> <I>domain-name</I> to check VM disk usage. Migrate or delete dependent VMs/volumes beforehand.<br><br><b>Distinction from <I>pool-undefine</I></b>: It is crucial to understand that <B>virsh pool-delete</B> is <I>not</I> the same as <B>virsh pool-undefine</B>. <B>pool-undefine</B> solely removes the pool's definition from libvirt without touching the underlying storage, making it a much safer operation for simply tidying up libvirt's configuration. <B>pool-delete</B>, conversely, is a full destructive removal.


title: DRY RUN / VERIFICATION
content:
Libvirt does not typically offer a 'dry run' option for destructive commands like <B>pool-delete</B>. Always carefully review the target pool's name and its contents (<B>virsh vol-list</B> <I>pool-name</I>) before execution to prevent accidental data loss.


title: AUTOMATIC DEACTIVATION
content:
If the pool is active when <B>pool-delete</B> is executed, libvirt will attempt to automatically destroy (deactivate) it before proceeding with the deletion of its contents and definition. However, if the pool is in use or encounters unresolvable issues during deactivation, the <B>pool-delete</B> command might also fail.


title: HISTORY
content:
The <B>virsh</B> command-line tool is the primary interface for managing libvirt, the open-source virtualization management library. Libvirt was first released in 2005 and has since become a standard API for interacting with various virtualization technologies, including KVM, QEMU, Xen, VMware ESX, and more. The <B>pool-delete</B> subcommand, like other storage pool management commands (<B>pool-define</B>, <B>pool-start</B>, <B>pool-list</B>, etc.), was introduced as part of libvirt's comprehensive storage management capabilities, designed to provide a unified way to manage heterogeneous storage backends for virtual machines. Its development reflects the critical need for robust and flexible control over VM disk provisioning and lifecycle.


title: SEE ALSO
content:
virsh(1), virsh pool-list(1), virsh pool-define(1), virsh pool-start(1), virsh pool-destroy(1), virsh pool-undefine(1), virsh vol-list(1), virsh vol-delete(1)


title: PARAMETERS
content:
<b><I>pool-name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage pool to be destroyed. This name is case-sensitive and must correspond to an active pool managed by <I>libvirt</I>.<br><br>


title: DESCRIPTION
content:
The <b>virsh pool-destroy</b> command is used to destroy an existing storage pool managed by <I>libvirt</I>. Destroying a pool means it will be stopped (deactivated) and its association with <I>libvirt</I> removed. Crucially, depending on the pool type and its configuration, this action can also lead to the deletion of its underlying data (e.g., a directory pool might have its directory removed, an LVM pool might have its logical volumes deleted). This is an irreversible action and must be used with extreme caution to prevent unintended data loss. The pool must be active (started) for this command to succeed. If the pool is not started, <I>virsh pool-undefine</I> is the correct command to remove its definition from <I>libvirt</I> without affecting the underlying storage.


title: CAVEATS
content:
<b><I>Data Loss Warning:</I></b> Destroying a storage pool can result in the irreversible deletion of all data contained within that pool. Always ensure you have backups or are certain you no longer need the data before proceeding.<br/><b><I>Active Pool Requirement:</I></b> This command only works on active (started) storage pools. If the pool is inactive, you must use <I>virsh pool-undefine</I> instead to remove its definition.<br/><b><I>No Confirmation:</I></b> <I>virsh</I> commands, including <I>pool-destroy</I>, typically do not prompt for confirmation before executing. Exercise extreme caution.


title: DIFFERENCE FROM <I>POOL-UNDEFINE</I>
content:
It's crucial to distinguish between <I>pool-destroy</I> and <I>pool-undefine</I>.<br/><br/><b><I>pool-destroy</I></b>: Stops an <B>active</B> pool and potentially deletes its underlying data and resources. It targets the physical storage.<br/><b><I>pool-undefine</I></b>: Removes the <B>definition</B> (XML configuration) of an <B>inactive</B> pool from <I>libvirt</I>'s configuration without touching the underlying physical data or resources. It targets <I>libvirt</I>'s knowledge of the pool.


title: TYPICAL WORKFLOW FOR COMPLETE REMOVAL
content:
To completely remove a storage pool and its data, a common workflow involves:<br/>1. <I>virsh pool-destroy <pool-name></I> (to stop the active pool and potentially clear data)<br/>2. <I>virsh pool-undefine <pool-name></I> (to remove its XML definition from <I>libvirt</I>)


title: HISTORY
content:
The <I>libvirt</I> project, and its command-line interface <I>virsh</I>, have been foundational for virtualization management on Linux systems for many years. Storage pool management commands, including <I>pool-destroy</I>, have been core components since the early days of <I>libvirt</I>'s development and widespread adoption. Their functionality has remained consistent, adapting to new storage technologies while maintaining the fundamental actions of defining, activating, and destroying storage resources.


title: SEE ALSO
content:
virsh(1), virsh pool-define(1), virsh pool-undefine(1), virsh pool-start(1), virsh pool-list(1), virsh pool-build(1)


title: PARAMETERS
content:
<b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all storage pools, including both active and inactive ones.<br><br><b>--active</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only active storage pools.<br><br><b>--inactive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only inactive storage pools.<br><br><b>--persistent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only persistent storage pools (those defined permanently).<br><br><b>--transient</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only transient storage pools (those defined temporarily and lost on host reboot).<br><br><b>--autostart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only storage pools configured to autostart with the libvirt daemon.<br><br><b>--no-autostart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List only storage pools not configured to autostart.<br><br><b>--details</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide more detailed information about each listed pool, such as path, type, and capacity.<br><br><b>--tree</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display pools in a tree-like format, useful for visualizing hierarchical relationships (less common for basic listing).<br><br><b>--uuid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output only the UUIDs of the storage pools.<br><br><b>--name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output only the names of the storage pools.<br><br>


title: DESCRIPTION
content:
The command <b>virsh pool-list</b> is a subcommand of the <b>virsh</b> utility, which is the main management interface for the libvirt virtualization management system. While <b>virsh-pool-list</b> itself is not a standalone command, it is commonly used to refer to <b>virsh pool-list</b>, which provides a way to list and query the status of configured storage pools.<br><br>Storage pools are abstract containers for physical storage devices (like directories, LVM volumes, iSCSI targets, etc.) that libvirt uses to manage virtual disk images for guests. This command helps administrators quickly ascertain which storage pools are defined, their current state (active or inactive), and other properties like autostart settings. It's crucial for monitoring the storage infrastructure supporting your virtual machines.


title: CAVEATS
content:
The literal command <b>virsh-pool-list</b> does not exist as a standalone executable; users typically mean <b>virsh pool-list</b>.<br>To execute this command, you typically need root privileges or be a member of the <i>libvirt</i> user group, as it interacts directly with the libvirt daemon.


title: OUTPUT COLUMNS
content:
When executed without specific formatting options, <b>virsh pool-list</b> typically outputs information in columns:<br><b>Name</b>: The user-defined name of the storage pool.<br><b>State</b>: Indicates whether the pool is <i>active</i> or <i>inactive</i>.<br><b>Autostart</b>: Shows if the pool is configured to autostart (<i>yes</i> or <i>no</i>) with the libvirt daemon.<br><b>Persistent</b>: Indicates if the pool definition is permanent (<i>yes</i>) or transient (<i>no</i>).


title: HISTORY
content:
The <b>virsh</b> command-line utility has been the standard interface for managing libvirt-based virtualization environments since its early inception. Storage pool management, including listing pools, has been a fundamental feature of libvirt and <b>virsh</b> from the beginning, evolving alongside the various storage backends supported by the system. The <b>pool-list</b> subcommand has been a stable and essential tool for administrators to monitor their virtual machine storage infrastructure.


title: SEE ALSO
content:
virsh(1), <i>Related subcommands:</i>, <b>virsh pool-define</b> (define a new storage pool), <b>virsh pool-start</b> (activate a storage pool), <b>virsh pool-destroy</b> (deactivate a storage pool), <b>virsh pool-delete</b> (delete a storage pool from disk), <b>virsh pool-info</b> (display information about a specific storage pool)


title: PARAMETERS
content:
<b><i>&lt;pool-name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of the storage pool to be activated. This name must correspond to a storage pool that has already been defined in Libvirt.<br><br>


title: DESCRIPTION
content:
The command, correctly written as <b>virsh pool-start</b>, is used to activate a previously defined but inactive storage pool within the Libvirt virtualization management system. When a storage pool is started, its underlying storage (e.g., a directory, a block device, an LVM volume group, or an iSCSI target) becomes accessible to Libvirt, and any virtual disk volumes associated with that pool can then be used by virtual machines. It's a crucial step for making storage available after a system reboot or if the pool was explicitly stopped. The pool must be defined using <b>virsh pool-define</b> or <b>virsh pool-define-as</b> before it can be started, and it needs to be in a <i>'stopped'</i> or <i>'inactive'</i> state to be successfully started.


title: CAVEATS
content:
Please note that the command is correctly spelled <b>virsh pool-start</b> (with a space), not <b>virsh-pool-start</b> (with a hyphen). Using the hyphenated version as a standalone command will likely result in a 'command not found' error unless it's a custom script or alias defined in your environment. This analysis assumes the user intended to inquire about the standard Libvirt command <b>virsh pool-start</b>.<br><br>Furthermore, a storage pool must be defined before it can be started. Starting a pool only activates it for the current session; to make it start automatically on host boot, you would use the <b>virsh pool-autostart</b> command.


title: USAGE EXAMPLE
content:
To start a storage pool named <i>'default'</i>, you would execute:<br><b>virsh pool-start default</b><br><br>After starting, you can verify its status using:<br><b>virsh pool-list --all</b>


title: HISTORY
content:
The <b>virsh</b> command-line utility is the primary interface for managing virtual machines and other Libvirt objects, including storage pools. Libvirt itself is an open-source API, daemon, and management tool for managing platform virtualization. Its development began in 2005, aiming to provide a common way to manage various virtualization technologies like KVM, Xen, VMware ESX, etc. The storage pool management capabilities, including the ability to start and stop pools, are fundamental features that have been part of Libvirt and <b>virsh</b> since their early stages, evolving with the growing needs for robust virtualization infrastructure management.


title: SEE ALSO
content:
virsh(1), virsh pool-define(1), virsh pool-create(1), virsh pool-list(1), virsh pool-destroy(1), virsh pool-autostart(1), virsh pool-info(1)


title: DESCRIPTION
content:
The <i>virsh pool-undefine</i> command removes the definition of a storage pool from the libvirt daemon's configuration. This action makes libvirt "forget" about the pool, meaning it will no longer manage or display it in its list of pools. It is crucial to understand that <i>pool-undefine</i> does <b>not</b> delete or modify the actual data residing on the storage device or path associated with the pool; the underlying storage remains untouched. Before a pool can be undefined, it must be in an inactive (destroyed) state. This command is typically used when you no longer want libvirt to manage a particular storage location, perhaps because you are decommissioning it, migrating it, or managing it manually outside of libvirt. It requires one mandatory argument: the name of the storage pool to be undefined.


title: CAVEATS
content:
The storage pool must be inactive (stopped) before it can be undefined. Use <i>virsh pool-destroy &lt;pool-name&gt;</i> first if it's currently active.<br>This command does <b>not</b> delete any data on the underlying storage. The data remains intact. To delete the data, you would typically use <i>virsh pool-delete</i> (if supported for the pool type and contents) or manually delete the storage after undefining.<br>Any virtual machines that were configured to use storage volumes from this pool will no longer be able to access those volumes via libvirt once the pool is undefined. You might need to update or redefine those VMs' storage configurations.


title: DISTINCTION FROM <I>POOL-DELETE</I>
content:
It is crucial to differentiate <i>virsh pool-undefine</i> from <i>virsh pool-delete</i>. <i>Undefine</i> merely removes the pool's definition from libvirt's configuration, leaving the underlying data untouched. <i>Delete</i>, on the other hand, attempts to remove the pool's definition <b>and</b> any data or devices associated with it (e.g., deleting LVM volumes, unmounting filesystems). The <i>delete</i> operation is often more destructive and not supported for all pool types or configurations. Generally, the workflow is to <i>destroy</i> (deactivate) a pool, then <i>undefine</i> it. If you also wish to remove the underlying storage, you would then manually remove it or, in specific cases, use <i>pool-delete</i>.


title: HISTORY
content:
The <i>virsh</i> command-line tool is the primary interface for managing <i>libvirt</i> virtualization. Storage pool management, including the <i>pool-undefine</i> command, has been a core feature of <i>libvirt</i> since its early versions. Its development has focused on providing a standardized and abstracted way to manage various storage backends for virtual machines, allowing users to configure and manipulate different storage types (e.g., directories, LVM, NFS, iSCSI) through a consistent interface. This command reflects <i>libvirt</i>'s design principle of separating configuration from data lifecycle management.


title: SEE ALSO
content:
virsh(1), virsh pool-define(1), virsh pool-list(1), virsh pool-start(1), virsh pool-destroy(1), virsh pool-delete(1), virsh pool-info(1)


title: SYNOPSIS
content:
virsh undefine <i>&lt;domain&gt;</i> [--nvram] [--managed-save] [--snapshots-metadata] [--check-connected] [--storage]


title: PARAMETERS
content:
<b><i>&lt;domain&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name or UUID of the virtual machine (domain) to be undefined. This is a mandatory argument.<br><br><b>--nvram</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, deletes the Non-Volatile RAM (NVRAM) file associated with the domain. This is typically used for UEFI-based virtual machines.<br><br><b>--managed-save</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, deletes any managed save image for the domain. A managed save image is created when a VM is suspended with <b>virsh save</b>.<br><br><b>--snapshots-metadata</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, deletes all snapshot metadata associated with the domain. This does not delete the snapshot disk images themselves, but rather the libvirt-managed metadata.<br><br><b>--check-connected</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, the command will fail if any active remote connections to the domain are detected.<br><br><b>--storage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If specified, this option will also undefine any storage volumes that are reported as belonging to the domain and are managed by libvirt. Depending on the storage pool type and volume format, this <b>can result in the deletion of the actual disk image files themselves</b>. Use this option with extreme caution.<br><br>


title: DESCRIPTION
content:
The <b>virsh undefine</b> command is used to remove the <i>definition</i> of a virtual machine (domain) from the libvirt daemon's configuration. This means libvirt will no longer recognize or manage the specified VM. <br><br>It's important to understand that, by default, <b>virsh undefine</b> only removes the XML configuration file associated with the domain from libvirt's registry. It <i>does not</i> delete the virtual machine's disk images or other associated data files from the storage system. These files remain on your host, allowing you to re-define the VM later using its original XML configuration if needed. <br><br>This command is typically used when a virtual machine is no longer needed, needs to be completely reconfigured from scratch, or when moving its definition to another libvirt host. To successfully undefine a domain, the virtual machine must be in an inactive state (e.g., shut off or paused).


title: CAVEATS
content:
<b><I>VM State Requirement</I></b><br>The virtual machine targeted for undefinition <i>must</i> be in an inactive state (e.g., shut off, paused, or saved). If the VM is running, you must first stop it using commands like <b>virsh shutdown</b> (for graceful shutdown) or <b>virsh destroy</b> (for immediate, forceful termination).<br><br><b><I>Disk Image Preservation (Default)</I></b><br>By default, <b>virsh undefine</b> only removes the VM's configuration. It does <i>not</i> delete its disk images or other associated files. These files remain on your storage system. If you wish to remove these, you must do so manually or use the <b>--storage</b> option with caution.<br><br><b><I>Extreme Caution with --storage</I></b><br>The <b>--storage</b> option is powerful and potentially destructive. It can lead to the <i>permanent deletion of your virtual machine's disk image files</i> if they are managed by libvirt and the storage pool type allows it. Always double-check which volumes are linked and confirm you genuinely want to delete the underlying data before using this option.


title: EFFECT OF UNDEFINE
content:
Undefining a domain primarily removes its XML configuration from libvirt's active management. The VM will no longer appear in <b>virsh list --all</b> (unless it was autostarted and that autostart record is still active, in which case it will appear as 'inactive'). This operation is equivalent to removing a VM's entry from a hypervisor's inventory without touching its underlying storage.


title: RE-DEFINING A VM
content:
A virtual machine that has been undefined can be re-defined using its original XML configuration file via the <b>virsh define &lt;path/to/xml&gt;</b> command, assuming its disk images and other dependencies are still intact.


title: SEE ALSO
content:
virsh define(1), virsh start(1), virsh destroy(1), virsh shutdown(1), virsh list(1), virsh autostart(1), virsh vol-delete(1)


title: SYNOPSIS
content:
<br><b>virt-clone</b> <i>--original</i> <I>ORIGINAL_NAME</I> <i>--name</i> <I>NEW_NAME</I> [<I>OPTION</I>...]


title: PARAMETERS
content:
<b>--original ORIGINAL_NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies the name of the existing virtual machine to be cloned. This VM must be defined in libvirt.<br><br><b>--name NEW_NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Sets the name for the new cloned virtual machine. This name must be unique.<br><br><b>--file TARGET_FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Defines the path for the new disk image file(s) for the cloned VM. Can be specified multiple times for multiple disks.<br><br><b>--preserve-data</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Instructs <i>virt-clone</i> to reuse the original disk image(s) rather than copying them. Useful for creating a new VM configuration pointing to existing data, but be cautious of data corruption if both VMs run simultaneously.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Proceed with the cloning even if it would overwrite an existing disk image or domain configuration. Use with caution.<br><br><b>--check-only</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Performs a dry run, checking if the cloning operation is possible without actually making any changes.<br><br><b>--print-xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Prints the generated XML configuration for the new VM to standard output instead of defining it in libvirt.<br><br><b>--connect URI</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Connects to a specific libvirt hypervisor URI. Defaults to the system default.<br><br><b>--auto-clone</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Automatically attempts to choose unique names and file paths for the cloned VM and its disks.<br><br><b>--keep-storage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Reuses the original storage volume or path without creating a new copy. Similar to <i>--preserve-data</i> but specifically for storage definition.<br><br><b>--replace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>If a VM with <i>--name</i> already exists, replace it. Requires <i>--force</i>.<br><br><b>--sparse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>When cloning raw disk images, create them as sparse files (allocate space only as needed).<br><br><b>--nonsparse</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>When cloning raw disk images, create them as non-sparse files (full allocation).<br><br><b>--nvram NVRAM_PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies a new NVRAM file for UEFI firmware configuration of the cloned VM.<br><br><b>--disk SOURCE=...,TARGET=...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Fine-grained control over disk cloning, e.g., specifying a new pool or path for a specific disk. Can be used multiple times for multiple disks.<br><br><b>--mac AA:BB:CC:DD:EE:FF</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Sets a specific MAC address for the new VM's first network interface. Can be specified multiple times for additional interfaces.<br><br><b>--os-variant VARIANT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Specifies the OS variant for the cloned VM, helping libvirt optimize performance for that OS.<br><br><b>--reflink</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Use Btrfs or XFS reflink cloning if supported by the filesystem and disk format, for instant, space-efficient copies without duplicating data blocks.<br><br><b>--template</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<br>Treat the original VM as a template, which might affect how certain attributes (like persistent disk IDs) are handled during cloning.<br><br>


title: DESCRIPTION
content:
virt-clone is a command-line tool that facilitates the creation of new virtual machines (VMs) by cloning an existing one. It is part of the <b>libvirt</b> virtualization management framework, providing a high-level abstraction over various hypervisors like KVM, Xen, and LXC. The primary function of virt-clone is to copy the virtual machine's disk images and create a new XML configuration file, adjusting parameters such as the MAC addresses and UUIDs to prevent conflicts. This utility streamlines the process of deploying multiple identical or nearly identical VMs, making it invaluable for development, testing, and creating template-based environments. It intelligently handles various storage formats and can be used to duplicate a VM without needing to reinstall the operating system, significantly reducing deployment time. While virt-clone handles the virtualization layer, it's crucial to note that it does not perform operating system-level customization (like changing hostname or IP address) within the cloned VM; this typically requires post-cloning steps or tools like virt-sysprep.


title: CAVEATS
content:
<br><b>Operating System Customization</b>: virt-clone only handles the virtualization layer. It <i>does not modify</i> the operating system inside the cloned VM. Critical post-cloning steps include changing the hostname, regenerating SSH host keys, modifying IP addresses, and handling application-specific configurations to prevent conflicts. For automated OS preparation, consider using <b>virt-sysprep</b>.<br><b>MAC Address Conflicts</b>: By default, virt-clone generates new MAC addresses. However, if using <i>--preserve-data</i> or specific network configurations, ensure no MAC address conflicts arise on your network.<br><b>Storage Type Limitations</b>: While it supports various storage types (qcow2, raw, LVM), the behavior with complex storage configurations or shared storage might require careful planning. <i>--reflink</i> only works on supporting filesystems (Btrfs, XFS) and disk formats.


title: POST-CLONING STEPS
content:
<br>After cloning, it is almost always necessary to boot the new VM and perform operating system-level adjustments. This includes setting a unique hostname, configuring network interfaces (IP addresses, DNS), and regenerating any unique identifiers such as SSH host keys or machine IDs (e.g., <i>/etc/machine-id</i> on Linux).


title: DISK IMAGE HANDLING
content:
<br>By default, virt-clone creates a full copy of the original VM's disk images. This ensures data integrity and isolation between the original and cloned VMs. Options like <i>--preserve-data</i> and <i>--keep-storage</i> are advanced features that should be used with a clear understanding of their implications on data sharing and potential conflicts if both VMs are run simultaneously.


title: RESOURCE ALLOCATION
content:
<br>While virt-clone copies the VM configuration, it typically retains the original CPU and memory allocations. You might need to use <i>virsh edit NEW_NAME</i> or <i>virt-manager</i> to adjust these resources for the new VM based on your requirements.


title: HISTORY
content:
<br>virt-clone emerged as part of the <b>virt-manager</b> project, developed primarily by Red Hat, aiming to provide higher-level, user-friendly tools for managing virtual machines via <b>libvirt</b>. Its development focused on simplifying repetitive tasks like VM duplication that would otherwise require manual manipulation of complex XML definitions or low-level disk operations. It has evolved over time to support new libvirt features, storage technologies, and hypervisor capabilities, becoming a staple for virtual machine administrators.


title: SYNOPSIS
content:
<b>virt-install</b> [<i>OPTION</i>]...<br><br>Common usage:<br><b>virt-install</b> --name <i>VM_NAME</i> --ram <i>RAM_MB</i> --vcpus <i>NUM_CPUS</i> \<br>  --disk path=<i>DISK_PATH</i>,size=<i>DISK_GB</i> --os-variant <i>OS_TYPE</i> \<br>  --network network=default --location <i>LOCATION_URL</i> [<i>ADDITIONAL_OPTIONS</i>]


title: PARAMETERS
content:
<b><b>--name</b> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the name for the new virtual machine. This name must be unique on the hypervisor.<br><br><b><b>--ram</b> <i>MB</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum memory (RAM) in MiB to allocate to the guest VM.<br><br><b><b>--vcpus</b> <i>NUM</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the number of virtual CPUs to assign to the guest VM.<br><br><b><b>--disk</b> [<i>OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures a disk device for the VM. Can specify path, size, format, bus type, etc. Example: <i>path=/var/lib/libvirt/images/vm.qcow2,size=10</i><br><br><b><b>--network</b> [<i>OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures a network interface for the VM. Can specify bridge, network, mac, model. Example: <i>network=default</i> or <i>bridge=br0</i><br><br><b><b>--location</b> <i>URL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the installation source, typically an HTTP/FTP/NFS URL to an installation tree or an ISO file path.<br><br><b><b>--cdrom</b> <i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a local CD-ROM device or ISO image as the installation source.<br><br><b><b>--pxe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the guest to boot from PXE, looking for a network boot server.<br><br><b><b>--os-variant</b> <i>VARIANT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimizes the guest configuration for a specific operating system, like <i>rhel8.0</i> or <i>ubuntu20.04</i>.<br><br><b><b>--graphics</b> [<i>OPTIONS</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the graphical console. Common types are <i>vnc</i> or <i>spice</i>. Use <i>none</i> for no graphical console.<br><br><b><b>--import</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Imports an existing disk image without running an installer, assuming the image is bootable.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the generated libvirt XML without actually creating the VM.<br><br><b><b>--connect</b> <i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific hypervisor identified by its URI, e.g., <i>qemu:///system</i>.<br><br><b><b>--virt-type</b> <i>TYPE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the hypervisor type to use, such as <i>kvm</i>, <i>qemu</i>, or <i>xen</i>.<br><br>


title: DESCRIPTION
content:
<i>virt-install</i> is a command-line utility used for provisioning new virtual machines on a <i>libvirt</i> managed hypervisor. It simplifies the process of creating VMs by automating steps like disk image creation, network configuration, and kickstarting the installation process.<br><br>It supports various installation methods including local CD/DVD, ISO images, network locations (HTTP, FTP, NFS), and PXE boot. <i>virt-install</i> is a powerful tool for system administrators and developers to quickly set up virtualized environments, especially in headless servers where a graphical interface like <i>virt-manager</i> is not available. It can create VMs for different architectures and hypervisors, primarily KVM and Xen, and integrates seamlessly with <i>libvirt</i> for lifecycle management.


title: CAVEATS
content:
<b>Requires libvirt:</b> Ensures the <i>libvirt</i> daemon is running and hypervisor modules (e.g., KVM) are loaded.<br><b>Resource Allocation:</b> Verify sufficient free disk space and memory on the host system.<br><b>Disk Paths:</b> Always use absolute paths for disk images to avoid issues.<br><b>SELinux Contexts:</b> Critical for KVM guests; ensure correct SELinux contexts (e.g., <i>virt_image_t</i>) are applied to disk images.<br><b>Console Access:</b> Initial console access may require <i>virsh console</i> or <i>virt-viewer</i> depending on graphics configuration.


title: LIBVIRT XML OUTPUT
content:
<i>virt-install</i> internally generates a <i>libvirt</i> XML domain definition. This XML can be viewed with <i>--dry-run</i> and is the underlying configuration used by <i>libvirt</i> to manage the VM. Understanding this XML is key for advanced customization and troubleshooting.


title: POST-INSTALLATION MANAGEMENT
content:
After a VM is successfully installed by <i>virt-install</i>, its lifecycle (start, stop, reboot, destroy, undefine) is managed using the <i>virsh</i> command-line tool. <i>virt-manager</i> can also be used for graphical management.


title: HISTORY
content:
<i>virt-install</i> is an integral part of the <i>virt-manager</i> project, initiated by Red Hat. It was developed to provide a robust command-line interface for provisioning virtual machines utilizing the <i>libvirt</i> daemon. Its development has closely tracked the evolution of KVM and QEMU virtualization technologies, making it a standard and widely adopted tool in Linux virtualization environments for automated and scripting-based VM creation.


title: PARAMETERS
content:
<b>--connect=<i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to a specified libvirt URI. Examples include <i>qemu:///system</i> for local KVM, or <i>qemu+ssh://user@host/system</i> for a remote KVM host.<br><br><b>--no-fork</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent the application from forking into the background, useful for debugging or when running from a script.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print extensive debug information to standard output, aiding in troubleshooting.<br><br><b>--show-domain=<i>NAME|ID|UUID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately open the details dialog for a specific virtual machine identified by its name, numeric ID, or UUID.<br><br><b>--show-host=<i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately open the host details dialog for a specific connection URI, showing hypervisor and system information.<br><br><b>--no-main-window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not display the main connection browser window upon startup. This is useful when directly opening a specific domain or host.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the program's version number and then exit.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message listing all available command-line options and then exit.<br><br>


title: DESCRIPTION
content:
<i>virt-manager</i> is a desktop user interface for managing virtual machines through the <b>libvirt</b> library. It provides a comprehensive graphical overview of virtual machines, supporting various hypervisors like <b>KVM</b>, <b>Xen</b>, and <b>LXC</b>. With <i>virt-manager</i>, users can easily perform a wide range of virtualization tasks, including creating new virtual machines, configuring their hardware resources, and managing their lifecycle (start, stop, pause, resume, migrate). It offers features like real-time performance graphs, direct console access to VMs, and management of virtual networks, storage pools, and host devices. This powerful and intuitive tool greatly simplifies complex virtualization administration, making it an essential asset for anyone working with virtualized environments on Linux desktops.


title: CAVEATS
content:
<i>virt-manager</i> relies on the <b>libvirt</b> daemon being installed and running on the host system. Users must have appropriate permissions (e.g., membership in the 'libvirt' group or root privileges) to connect to and manage virtual machines. While powerful for graphical management, it is not designed for scripting or headless server environments, where command-line tools like <b>virsh</b> are typically preferred.


title: REMOTE CONNECTION CAPABILITIES
content:
<i>virt-manager</i> can connect to and manage virtual machines on remote hosts using various protocols, most commonly <b>SSH</b>. This allows for centralized management of multiple virtualization servers from a single desktop interface, enhancing administrative efficiency and flexibility.


title: INTEGRATION WITH LIBVIRT
content:
The strength of <i>virt-manager</i> lies in its deep integration with the <b>libvirt</b> virtualization management library. <b>libvirt</b> provides a stable, consistent, and hypervisor-agnostic API, allowing <i>virt-manager</i> to interact seamlessly with different virtualization technologies (KVM, Xen, LXC) through a unified and powerful interface.


title: HISTORY
content:
<i>virt-manager</i> was developed by <b>Red Hat</b> as a key component of the <b>libvirt</b> virtualization ecosystem. Its initial release aimed to provide a user-friendly graphical interface for managing virtual machines, particularly those powered by <b>KVM</b> and <b>Xen</b>. Over the years, its development has closely followed the advancements in <b>libvirt</b> and underlying hypervisors, continuously adding support for new features and improving usability. It has become a standard tool in many Linux distributions for desktop virtualization management, significantly simplifying the administration of virtualized environments.


title: PARAMETERS
content:
<b>-a <i>file</i>, --add <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an extra disk image to the guest. This disk will be accessible during the command execution.<br><br><b>-A <i>file</i>, --add-ro <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add an extra disk image as read-only to the guest environment.<br><br><b>--arch <i>guest-arch</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the guest architecture (e.g., x86_64, i686). Defaults to the host architecture.<br><br><b>-c <i>URI</i>, --connect <i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to a specified libvirt URI. This is usually only needed for debugging libvirt drivers.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug messages, showing verbose information about the internal operations.<br><br><b>--extra-args <i>args</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pass extra arguments to the guest kernel command line.<br><br><b>--filesystem <i>type</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specify the filesystem type for the primary disk image (e.g., ext4, xfs).<br><br><b>-g, --gui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the QEMU graphical interface. This is rarely useful for <i>virt-qemu-run</i>.<br><br><b>--ignore-timestamps</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not update the disk image's timestamps, useful for testing.<br><br><b>-i, --iso</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treat the primary disk image as an ISO filesystem image.<br><br><b>--key <i>device:key</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a decryption key for a LUKS-encrypted device within the disk image.<br><br><b>--label <i>device:label</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount a device with a specific filesystem label instead of its path.<br><br><b>-m <i>memsize</i>, --memsize <i>memsize</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the guest memory size in megabytes (MB).<br><br><b>--ro</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount the primary disk image read-only, preventing any modifications.<br><br><b>--rw</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mount the primary disk image read-write (this is the default behavior).<br><br><b>--selinux</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable SELinux support within the guest environment.<br><br><b>--trace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable libguestfs API tracing, showing all calls to the libguestfs API.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose messages during operation.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version number of <i>virt-qemu-run</i> and exit.<br><br>


title: DESCRIPTION
content:
<i>virt-qemu-run</i> is a specialized tool within the <b>libguestfs</b> suite designed to execute commands directly inside a virtual machine's disk image without requiring a full VM boot. It achieves this by leveraging QEMU's capabilities to access and manipulate disk contents directly. Primarily used for testing <b>libguestfs</b> itself, it's generally not recommended for typical users who should instead use higher-level tools like <i>guestfish</i>. The command creates a minimal guest environment, redirects standard I/O, and uses the guest's kernel and initrd to run the specified command. It's a lightweight way to interact with a disk image's internal operating system.


title: CAVEATS
content:
<i>virt-qemu-run</i> is primarily an internal tool for <b>libguestfs</b> development and testing. <br>It does not provide a full virtual machine environment; networking or complex hardware interactions are not typically supported. <br>Running arbitrary commands on untrusted disk images could pose security risks, as the command is executed with significant privileges within the minimal guest environment. <br>It requires a guest kernel and initrd to be available on the host system to boot the minimal environment.


title: DEFAULT COMMAND EXECUTION
content:
If no <i>COMMAND</i> is specified, <i>virt-qemu-run</i> will default to executing a small helper script named <i>virt-qemu-run-helper</i> inside the guest, typically running <code>/bin/sh -c 'virt-qemu-run-helper'</code>. This script is provided by <b>libguestfs</b> and sets up the minimal environment.


title: EXIT STATUS
content:
The command exits with <code>0</code> upon successful execution of the specified command within the guest. A non-zero exit status indicates an error or a failure in executing the command inside the guest, or an issue with <i>virt-qemu-run</i> itself.


title: HISTORY
content:
<b>libguestfs</b>, which includes <i>virt-qemu-run</i>, was initiated by Richard Jones around 2008. This utility serves as a low-level testing component within the project, designed to validate the core functionalities of <b>libguestfs</b> which involve direct manipulation of virtual machine disk images. Its development is closely tied to the evolution and expansion of the <b>libguestfs</b> library itself, ensuring the reliability of disk image operations without the overhead of full VM emulation.


title: SYNOPSIS
content:
<b>virt-sparsify</b> [<I>OPTION</I>...] <I>INFILE</I> <I>OUTFILE</I><br><b>virt-sparsify</b> [<I>OPTION</I>...] <b>--in-place</b> <I>FILE</I>


title: PARAMETERS
content:
<b>--convert <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts the disk image to a specified format (e.g., qcow2, raw) during sparsification.<br><br><b>--in-place</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Modifies the disk image directly without creating a new output file. This option is experimental and requires sufficient temporary free space on the same filesystem.<br><br><b>--compress</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compresses the output image if the target format supports compression (e.g., qcow2).<br><br><b>--check-zero <bool></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether to explicitly check for all-zero blocks for sparsification. Setting this to 'false' can make the process faster but potentially less thorough.<br><br><b>--format <format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the format of the input disk image. Useful when autodetection fails or for clarity.<br><br><b>--tmpdir <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific temporary directory for sparse data and other operational files instead of the default.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses progress messages, showing only errors or critical information.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the sparsification process, including debug information.<br><br>


title: DESCRIPTION
content:
<b>virt-sparsify</b> is a utility designed to optimize virtual machine disk images by converting unused blocks within the image into 'holes' or sparse regions. This process, known as sparsification, allows the underlying host filesystem to reclaim storage space that was allocated but not actively used by the guest operating system. It's particularly useful after large files have been deleted inside a guest VM, or when converting a thickly provisioned disk image to a thinly provisioned format. <b>virt-sparsify</b> can operate on various disk image formats and can also perform format conversions (e.g., from raw to qcow2), optionally compressing the output. The tool accesses the guest filesystem directly using <b>libguestfs</b> to identify free blocks, ensuring a safe and efficient sparsification without needing the guest to be running. It typically operates by reading the input and writing a new, sparse output file, though an experimental in-place option is available.


title: CAVEATS
content:
<b>virt-sparsify</b> operates by accessing the guest filesystem and typically creating a new sparse copy of the disk image. The experimental <b>--in-place</b> option, while convenient, requires a substantial amount of temporary free space (up to twice the original image size) on the same filesystem for its operation and should be used with caution, ideally after backing up the original image. The input disk image should have a clean filesystem (e.g., no pending fsck issues). This tool reduces the physical size on disk, not the logical size as seen by the guest operating system. It relies on the correct functioning of <b>libguestfs</b>, which in turn depends on <b>qemu</b> and other virtualization components.


title: EXIT STATUS
content:
The command typically returns <b>0</b> on success. A non-zero exit status indicates an error, which can be useful for scripting and automation to determine if the sparsification process failed. Specific error codes might provide more granular information about the nature of the failure.


title: HISTORY
content:
<b>virt-sparsify</b> is a core component of the <b>libguestfs</b> project, a suite of tools developed primarily by Red Hat since 2008. It was created to address the critical need for efficient offline management of virtual machine disk images, particularly for space optimization. Its design leverages <b>libguestfs</b>'s ability to safely access and modify guest filesystems, making it a reliable solution for sparsifying disk images across various virtualization platforms and formats. The tool has evolved to include features like in-place sparsification and format conversion, reflecting ongoing development in virtual disk management.


title: SYNOPSIS
content:
<b>virt-sysprep</b> [<i>OPTION...</i>] <b>-a</b> <i>DISK_IMAGE</i><br><b>virt-sysprep</b> [<i>OPTION...</i>] <b>--add</b> <i>DISK_IMAGE</i><br><b>virt-sysprep</b> [<i>OPTION...</i>] <b>-d</b> <i>GUEST_NAME</i><br><b>virt-sysprep</b> [<i>OPTION...</i>] <b>--domain</b> <i>GUEST_NAME</i>


title: PARAMETERS
content:
<b><b>-a</b> <i>DISK_IMAGE</i>, <b>--add</b> <i>DISK_IMAGE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the guest disk image to be modified. The VM must be shut down or the disk detached.<br><br><b><b>-d</b> <i>GUEST_NAME</i>, <b>--domain</b> <i>GUEST_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the libvirt guest whose disk image will be modified. The guest must be shut down.<br><br><b><b>--enable</b> <i>OPERATION[,...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables specific system preparation operations (e.g., <i>ssh-hostkeys</i>, <i>network-configuration</i>). Use <b>--list-operations</b> to see all available operations.<br><br><b><b>--operations</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads sysprep operations and their arguments from a specified <i>FILE</i>, allowing complex or repeatable setups.<br><br><b><b>--ssh-inject</b> <i>USER:KEY_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Injects an SSH public key from <i>KEY_FILE</i> into the specified <i>USER</i>'s <i>~/.ssh/authorized_keys</i> within the guest.<br><br><b><b>--root-password</b> <i>PASSWORD_FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the root user's password using the content from <i>PASSWORD_FILE</i> (can be a plain text password or hashed).<br><br><b><b>--hostname</b> <i>HOSTNAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the guest operating system's hostname to the specified <i>HOSTNAME</i>.<br><br><b><b>--run</b> <i>SCRIPT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a shell <i>SCRIPT</i> within the guest environment after all other sysprep operations are completed.<br><br><b><b>--delete</b> <i>/PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes a file or directory located at <i>/PATH</i> inside the guest filesystem.<br><br><b><b>--upload</b> <i>FILE:PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads a <i>FILE</i> from the host filesystem to a specific <i>PATH</i> within the guest filesystem.<br><br><b><b>--network</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resets the network configuration of the guest, typically setting it to use DHCP for the primary network interface.<br><br><b><b>--timezone</b> <i>TIMEZONE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the guest operating system's timezone (e.g., 'America/New_York').<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays verbose output, showing more details about the operations being performed.<br><br>


title: DESCRIPTION
content:
<i>virt-sysprep</i> is a command-line tool that modifies a virtual machine's disk image <b>offline</b> to prepare it for cloning and deployment as a template. It removes machine-specific identifiers and data that would cause conflicts if multiple VMs were deployed from the same image without modification.<br><br>This includes deleting SSH host keys, UIDs, machine IDs, user histories, DHCP client leases, and other unique system information. Beyond cleaning, <i>virt-sysprep</i> can also perform customization tasks, such as adding SSH public keys, resetting root passwords, configuring networking, and executing custom shell scripts or <i>virt-sysprep</i> operations from a file. This ensures that new instances cloned from the prepared image are unique and ready for initial boot without manual intervention, making it an essential tool for automated VM provisioning in cloud and virtualization environments. It utilizes the <i>libguestfs</i> library to safely access and modify the guest filesystem.


title: CAVEATS
content:
<b>Requires</b> the <i>libguestfs</i> library and associated tools to be installed.<br><b>Operates only</b> on <b>offline</b> disk images; the virtual machine associated with the image must not be running.<br><b>Modifies the disk image directly and irreversibly</b>; it is highly recommended to back up the image before running <i>virt-sysprep</i>.<br><b>Requires root privileges</b> to access and modify disk images or libvirt domains.


title: DEFAULT OPERATIONS
content:
When no specific operations are enabled with <b>--enable</b> or <b>--operations</b>, <i>virt-sysprep</i> runs a default set of clean-up tasks. These typically include removing SSH host keys, user history, DHCP client state, machine IDs, log files, package manager caches, and other unique identifiers that could cause conflicts when cloning. Users should be aware of these automatic actions.


title: OFFLINE OPERATION
content:
A crucial aspect of <i>virt-sysprep</i> is that it always operates on an <b>offline</b> disk image. This means the virtual machine must be shut down or its disk detached before <i>virt-sysprep</i> can modify it. This design ensures data consistency and prevents conflicts with a running operating system.


title: HISTORY
content:
<i>virt-sysprep</i> emerged as part of the broader <i>libguestfs</i> project, which began development around 2008-2009. Its purpose was to provide a robust, programmatic, and secure way to generalize Linux virtual machine images, mirroring the functionality of Microsoft's Sysprep for Windows. By leveraging <i>libguestfs</i>, it can directly manipulate guest filesystems without booting the VM, making it a powerful tool for automated VM provisioning and template management in virtualization and cloud environments.


title: SYNOPSIS
content:
<b>virt-viewer</b> [<i>OPTIONS</i>] <i>&lt;domain&gt;</i><br><b>virt-viewer</b> [<i>OPTIONS</i>] <b>--connect</b> <i>URI &lt;domain&gt;</i><br><b>virt-viewer</b> [<i>OPTIONS</i>] <b>--direct</b> <i>&lt;SPICE|VNC&gt;://HOST:PORT</i>


title: PARAMETERS
content:
<b><b>&lt;domain&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the virtual machine by its name or UUID when connecting via <b>libvirt</b>.<br><br><b><b>--connect</b> <i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to a specific hypervisor URI (e.g., qemu:///system, xen:///). Defaults to the system default if not specified.<br><br><b><b>--direct</b> <i>URI</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects directly to a graphics server URI (e.g., <i>spice://localhost:5900</i> or <i>vnc://remotehost:5901</i>) without involving <b>libvirt</b>.<br><br><b><b>--full-screen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the viewer in full-screen mode. Can be toggled with F11 (or Shift+F11).<br><br><b><b>--auto-resize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables automatic resizing of the guest display to fit the window size (requires SPICE guest tools).<br><br><b><b>--no-cursor-restraint</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the automatic grabbing of the mouse cursor when the viewer window is focused.<br><br><b><b>--spice</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the viewer to use the SPICE protocol. If not specified, the protocol is auto-detected or defaults to SPICE if available.<br><br><b><b>--vnc</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the viewer to use the VNC protocol.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output for troubleshooting.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help message and exits.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>virt-viewer</i> is a lightweight graphical viewer for virtual machines managed by the <b>libvirt</b> virtualization management library. It provides a simple yet powerful interface to interact with the guest operating system's console, supporting both the <b>SPICE</b> and <b>VNC</b> display protocols. While <i>virt-viewer</i> can connect directly to a graphics server using a URI, its primary strength lies in its tight integration with <b>libvirt</b>. This integration allows users to easily connect to virtual machines by their domain name or UUID, letting <b>libvirt</b> handle the underlying connection details. It's an essential component for users needing direct visual access to their QEMU/KVM, Xen, or other libvirt-managed virtual machines, offering features like full-screen mode, automatic guest display resizing, and, with proper guest agents, clipboard sharing and USB device redirection.


title: CAVEATS
content:
For optimal performance and features like clipboard sharing and USB redirection, it's highly recommended to install the respective <b>SPICE guest tools</b> (for SPICE connections) or equivalent VNC guest agents within the virtual machine. Without them, some advanced features might be unavailable or have limited functionality. Direct connections using <b>--direct</b> bypass <b>libvirt's</b> management and might not offer the same level of integration and features as connections managed by <b>libvirt</b>.


title: PROTOCOL SUPPORT
content:
<i>virt-viewer</i> supports both <b>SPICE</b> (Simple Protocol for Independent Computing Environments) and <b>VNC</b> (Virtual Network Computing). <b>SPICE</b> is generally preferred for its richer feature set, including better video playback, audio support, clipboard sharing, and USB device redirection, making it ideal for desktop-like experiences. <b>VNC</b> is a more generic and widely compatible protocol, often used when SPICE is not available or desired.


title: LIBVIRT INTEGRATION
content:
One of <i>virt-viewer's</i> key strengths is its tight integration with <b>libvirt</b>. When connecting to a domain (VM) via <b>libvirt</b>, <i>virt-viewer</i> leverages <b>libvirt's</b> APIs to discover the VM's display details (protocol, port, address), simplifying the connection process. This means you don't need to manually specify IP addresses or ports for VMs managed by <b>libvirt</b>; just the domain name or UUID is sufficient.


title: INTERACTION AND FEATURES
content:
Beyond simply displaying the console, <i>virt-viewer</i> allows full keyboard and mouse interaction with the guest OS. Features like full-screen mode (toggle with F11), automatic guest display resizing (with SPICE guest tools), and clipboard synchronization greatly enhance the user experience. It also provides options for USB device redirection, enabling the host's USB devices to be passed through to the virtual machine, which is crucial for tasks requiring hardware access.


title: HISTORY
content:
<i>virt-viewer</i> is an integral part of the <b>virt-manager</b> project, which is primarily developed by Red Hat. It emerged as a dedicated and optimized tool for viewing virtual machine consoles, specifically designed to work seamlessly within the <b>libvirt</b> ecosystem. Prior to dedicated tools like <i>virt-viewer</i>, users often relied on generic VNC clients. <i>virt-viewer</i> improved upon this by offering deeper integration with <b>libvirt's</b> capabilities, enabling automatic discovery of VM display details, better handling of protocols like SPICE, and enhanced features over generic viewers. Its development reflects the continuous effort to provide robust and user-friendly tools for Linux virtualization.


title: SYNOPSIS
content:
<b>virt-xml</b> [<I>domain</I>] [<I>action-option</I>...] [<I>generic-option</I>...]<br><b>virt-xml</b> --build-xml [<I>xml-modifier</I>...] [<I>generic-option</I>...]


title: PARAMETERS
content:
<b><b>--add-device</b> <I>type</I>[,<I>option</I>=<I>value</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a new device to the domain. Examples include <I>disk</I>, <I>network</I>, <I>hostdev</I>, <I>controller</I>, <I>channel</I>, <I>input</I>, <I>rng</I>, <I>tpm</I>, <I>memballoon</I>, <I>vsock</I>, etc. Each type has specific options.<br><br><b><b>--remove-device</b> <I>type</I>[,<I>option</I>=<I>value</I>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove a device matching the specified type and options. Used to identify which instance of a device to remove.<br><br><b><b>--edit</b> <I>xpath</I>=<I>value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a specific XPath edit to the domain's XML. This allows for precise modifications to any part of the XML.<br><br><b><b>--delete</b> <I>xpath</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Delete the XML element or attribute specified by the XPath.<br><br><b><b>--cpu</b> <I>model</I>[,<I>options</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the CPU model and topology for the guest. Options include <I>sockets</I>, <I>cores</I>, <I>threads</I>, <I>mode</I> (e.g., <I>host-model</I>, <I>host-passthrough</I>).<br><br><b><b>--memory</b> <I>amount</I>,unit=<I>unit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the guest's maximum memory allocation (e.g., 2048,unit=MiB). Units can be <I>KiB</I>, <I>MiB</I>, <I>GiB</I>.<br><br><b><b>--current-memory</b> <I>amount</I>,unit=<I>unit</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the guest's current memory, useful for memory hotplug. Requires hypervisor and guest support.<br><br><b><b>--disk</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure or add a disk device. Common options: <I>path</I>, <I>size</I>, <I>bus</I>, <I>format</I>, <I>device</I> (disk|cdrom|floppy), <I>serial</I>, <I>readonly</I>, <I>snapshot</I>, <I>cache</I>.<br><br><b><b>--network</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure or add a network interface. Common options: <I>network</I>, <I>bridge</I>, <I>mac</I>, <I>model</I>, <I>type</I> (direct|hostdev|ethernet|network|bridge), <I>source</I>.<br><br><b><b>--hostdev</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure or add a host device passthrough (PCI, USB, etc.). Options: <I>pci_address</I>, <I>usb_address</I>, <I>managed</I>, <I>mode</I>.<br><br><b><b>--graphics</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure the guest's graphical console. Options: <I>type</I> (vnc|spice|sdl|egl-headless|none), <I>port</I>, <I>autoport</I>, <I>listen</I>, <I>keymap</I>, <I>password</I>, <I>gl</I>.<br><br><b><b>--console</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure the guest's serial console. Options: <I>type</I> (pty|dev|null), <I>target_type</I> (serial|virtio), <I>target_port</I>, <I>path</I>.<br><br><b><b>--boot</b> <I>options</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configure boot devices and order. Options: <I>path</I> (e.g., <I>hd</I>, <I>cdrom</I>, <I>network</I>), <I>menu=on|off</I>, <I>order</I>.<br><br><b><b>--os-variant</b> <I>variant</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the guest OS variant (e.g., <I>rhel8</I>, <I>win10</I>) to optimize domain settings.<br><br><b><b>--connect</b> <I>URI</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connect to a specified hypervisor URI (e.g., <I>qemu:///system</I>).<br><br><b><b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply changes to an inactive domain by redefining it. This is the default action if no other output option is specified.<br><br><b><b>--replace</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replace the domain's XML entirely. This first undefines the domain, then redefines it with the new XML. Use with caution.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show what changes would be applied without actually making them. Useful for testing.<br><br><b><b>--print-xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the resulting XML to standard output instead of applying changes. Useful for review or piping.<br><br><b><b>--build-xml</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate new XML based on the provided arguments, rather than modifying an existing domain. Requires <I>--print-xml</I> or an output target.<br><br><b><b>--autolearn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to derive device configuration (like <I>bus</I> type) from the VM's existing configuration if not specified.<br><br>


title: DESCRIPTION
content:
<b>virt-xml</b> is a powerful command-line utility for manipulating the XML configuration of virtual machines managed by Libvirt. It provides a simplified interface to modify common aspects of a domain's XML without directly editing the verbose XML file. Users can add, remove, or edit devices such as disks, network interfaces, USB devices, and host devices. It also facilitates changes to core VM parameters like CPU topology, memory allocation, and various other domain settings. This tool is invaluable for automation, scripting, and quickly adjusting VM configurations without launching a full graphical interface like <b>virt-manager</b>. It integrates seamlessly with <b>virsh</b> commands, allowing for flexible management of virtualized environments. The command can apply changes directly to an inactive or active domain (if supported), or output the modified XML to stdout for review or further processing. Its primary goal is to make common Libvirt XML modifications more accessible and less error-prone.


title: CAVEATS
content:
Incorrect usage of <b>virt-xml</b> can lead to unbootable or misconfigured virtual machines. Always back up domain XML before making significant changes.<br>Hotplugging devices and changes to active domains are dependent on hypervisor and guest operating system support, and may not work for all device types or configurations.<br>While simplifying common tasks, complex XML modifications or debugging may still require direct XML knowledge or usage of <b>virsh edit</b>.


title: XML MANIPULATION LOGIC
content:
<b>virt-xml</b> intelligently parses the existing domain XML (or builds a new one with <b>--build-xml</b>), applies the requested modifications, and then either outputs the result or redefines the domain. It attempts to place new XML elements in logical and consistent locations within the domain definition.<br>Many operations are designed to be idempotent, meaning applying the same command multiple times will result in the same final configuration, preventing duplicate entries for common device types unless specifically intended.


title: HISTORY
content:
<b>virt-xml</b> is part of the <b>virt-manager</b> project, initially developed by Red Hat. It was created to provide a robust command-line interface for common Libvirt domain XML modifications, addressing the need for automation and streamlined configuration management. Its development has progressed alongside the evolution of Libvirt and KVM, becoming an essential tool for administrators and developers working with virtualized environments on Linux.


title: SYNOPSIS
content:
<b>virt-xml-validate</b> [<i>OPTIONS</i>] <i>FILE</i> [<i>SCHEMA_FILE</i>]<br><b>virt-xml-validate</b> [<i>OPTIONS</i>] --stdin [<i>SCHEMA_FILE</i>]


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all standard output upon successful validation. Only error messages are printed.<br><br><b>--stdin</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the XML document for validation from standard input instead of a specified file.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <b>virt-xml-validate</b> utility and exits.<br><br><b>--schema <SCHEMA_TYPE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces validation against a specific schema type, overriding the automatic inference. Common types include 'domain', 'network', 'pool', 'volume', 'nodedev', 'secret', 'interface', 'nwfilter', etc.<br><br><b><FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the XML file to be validated. This is typically a libvirt XML definition.<br><br><b>[SCHEMA_FILE]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An optional path to a custom XML schema (XSD) file to use for validation. If omitted, <b>virt-xml-validate</b> attempts to infer the schema from the XML content.<br><br>


title: DESCRIPTION
content:
<b>virt-xml-validate</b> is a crucial command-line utility within the <i>libvirt</i> ecosystem, designed to verify the structural and semantic correctness of libvirt XML configuration files. It ensures that various libvirt object definitions&mdash;such as domains (virtual machines), networks, storage pools, storage volumes, node devices, secrets, and more&mdash;adhere to their respective XML schemas. By validating these files, <b>virt-xml-validate</b> helps prevent configuration errors and ensures that libvirt can parse and apply the settings correctly. When a schema file is not explicitly provided, the tool intelligently infers the appropriate schema based on the root element of the XML document, making its usage straightforward for common scenarios. It leverages <i>libxml2</i>'s powerful validation capabilities, providing clear error messages if the XML does not conform to the schema. A successful validation returns an exit code of 0, while any non-zero code indicates an error, making it suitable for scripting and automated deployment pipelines.


title: CAVEATS
content:
<b>virt-xml-validate</b> primarily validates against XML Schemas (XSD). While it can check the structural correctness and adherence to the schema, it does not perform semantic checks that require deeper understanding of libvirt's runtime state or specific hardware capabilities. For example, it won't verify if a specified bridge actually exists or if a CPU feature is supported by the host. It also relies on the <i>libxml2</i> library; issues or limitations within <i>libxml2</i>'s schema validation engine could indirectly affect <b>virt-xml-validate</b>.


title: EXIT STATUS
content:
The command returns an exit status of <b>0</b> on successful validation, indicating that the XML file conforms to the schema. A non-zero exit status (typically <b>1</b>) signifies a validation failure, meaning the XML is malformed or does not adhere to the specified or inferred schema. This makes it highly suitable for use in shell scripts for automated checking.


title: SCHEMA INFERENCE
content:
When no explicit <i>SCHEMA_FILE</i> or <i>--schema</i> type is provided, <b>virt-xml-validate</b> intelligently attempts to determine the correct XML schema based on the root element of the XML document. For example, if the root element is <i>&lt;domain&gt;</i>, it will automatically attempt to validate against the libvirt domain schema. This simplifies usage for most common libvirt XML types.


title: HISTORY
content:
<b>virt-xml-validate</b> is an integral part of the <i>libvirt</i> project, an open-source virtualization management toolkit. It was introduced to provide a robust method for validating XML configurations, which are central to <i>libvirt</i>'s declarative approach to managing virtual machines and other virtualization resources. As <i>libvirt</i> evolved and its XML schemas became more complex with new features and objects, the need for a dedicated validation tool grew. Its development paralleled <i>libvirt</i>'s growth, ensuring that administrators and developers could reliably verify their configurations against the continually updated and refined schemas. Its simple command-line interface makes it a staple for both manual debugging and automated CI/CD pipelines where configuration integrity is paramount.


title: SYNOPSIS
content:
virtualenv [OPTIONS] <ENV_DIR><br><i><br>ENV_DIR</i>: The path to the directory where the new virtual environment will be created.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show program's help message and exit.<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>-p PYTHON_EXE</b>, <b>--python=PYTHON_EXE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The Python interpreter to use for the new environment. Can be an absolute path or the name of a Python executable in your PATH (e.g., <i>python3.8</i>).<br><br><b><b>--no-site-packages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not inherit packages from the global <i>site-packages</i> directory. This is the default behavior in modern <i>virtualenv</i> versions.<br><br><b><b>--system-site-packages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Give the virtual environment access to the global <i>site-packages</i> directory.<br><br><b><b>--clear</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Clear out the <i>virtualenv</i> environment if it already exists, before recreating it.<br><br><b><b>--symlinks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Try to use symlinks rather than copies, when possible. This is typically the default on Unix-like systems.<br><br><b><b>--always-copy</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Always copy files instead of symlinking, even if symlinking is possible.<br><br><b><b>--no-setuptools</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install <i>setuptools</i> in the new virtual environment.<br><br><b><b>--no-pip</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install <i>pip</i> in the new virtual environment.<br><br><b><b>--no-wheel</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not install <i>wheel</i> in the new virtual environment.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress output during environment creation.<br><br>


title: DESCRIPTION
content:
<i>virtualenv</i> is a powerful tool for Python developers that creates <i>isolated Python environments</i>. It allows you to have multiple Python projects on your system, each with its own independent set of installed packages, without conflicts. When you create a <i>virtualenv</i>, it sets up a directory containing a copy of the Python interpreter, <i>pip</i>, and a <i>site-packages</i> directory. This isolation is crucial because different projects often require different versions of the same library, or entirely different sets of libraries. Without <i>virtualenv</i>, installing packages globally could lead to dependency hell, where installing a new package for one project breaks another.<br><br>By activating a <i>virtualenv</i>, your shell's <b>PATH</b> is temporarily modified to point to the <i>virtualenv</i>'s Python and <i>pip</i> executables. This ensures that any packages you install using <i>pip</i> within that environment are installed locally to that specific <i>virtualenv</i>, leaving your global Python installation clean and untouched. This capability promotes <i>reproducible development environments</i> and simplifies project dependency management.


title: CAVEATS
content:
<i>Relocating an environment</i> created with <i>virtualenv</i> can be problematic and is generally discouraged. Paths are often hardcoded, leading to issues if the environment directory is moved. It's best practice to delete and recreate the environment in the new location.<br><br>While <i>virtualenv</i> is highly effective, Python 3.3 and newer versions include a built-in module called <i>venv</i> that provides similar core functionality. For simple use cases with recent Python versions, <i>venv</i> might be sufficient. <i>virtualenv</i> remains more feature-rich and supports older Python versions not supported by <i>venv</i>.


title: ACTIVATION AND DEACTIVATION
content:
After creating a virtual environment, you need to <i>activate</i> it to use its isolated Python interpreter and packages. This is done by sourcing an activation script:<br><i>For Linux/macOS:</i> <b>`source /path/to/your/env/bin/activate`</b><br><i>For Windows (cmd.exe):</i> <b>`/path/to/your/env/Scripts/activate.bat`</b><br><i>For Windows (PowerShell):</i> <b>`/path/to/your/env/Scripts/Activate.ps1`</b><br>Once activated, your shell prompt usually changes to indicate the active environment. To <i>deactivate</i>, simply run the command <b>`deactivate`</b>.


title: USE CASES
content:
<i>virtualenv</i> is ideal for:<br><ul><li>Working on multiple Python projects simultaneously, each with different dependency versions.</li><li>Preventing pollution of your global Python installation.</li><li>Creating reproducible build environments for continuous integration/deployment.</li><li>Testing packages against different Python versions or dependency sets.</li></ul>


title: HISTORY
content:
The <i>virtualenv</i> tool was originally created by <i>Ian Bicking</i> in 2007. It rapidly became an essential utility for Python development, addressing the critical need for isolated development environments long before such functionality was integrated into Python itself. Its widespread adoption and success directly influenced the development of the <i>venv module</i>, which was introduced into the Python standard library in version 3.3. Despite the existence of <i>venv</i>, <i>virtualenv</i> continues to be actively maintained and widely used, especially for projects requiring compatibility with older Python versions, more advanced configuration options, or specific CPython builds. Its development has consistently aimed to provide a robust and flexible solution for Python environment management.


title: SYNOPSIS
content:
<i>virtualenvwrapper</i> is not a single executable command but a collection of shell functions. Once sourced in your shell profile (e.g., <i>~/.bashrc</i>), it provides the following common commands:<br><br><b>mkvirtualenv</b> [<i>options</i>] <i>&lt;env_name&gt;</i><br><b>workon</b> [<i>&lt;env_name&gt;</i>]<br><b>rmvirtualenv</b> <i>&lt;env_name&gt;</i><br><b>deactivate</b><br><b>lsvirtualenv</b><br><b>cdvirtualenv</b><br><b>cpvirtualenv</b> [<i>options</i>] <i>&lt;source_env&gt;</i> <i>&lt;new_env&gt;</i>


title: PARAMETERS
content:
<b><i>&lt;env_name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired name for the virtual environment. Used by commands like <b>mkvirtualenv</b>, <b>workon</b>, and <b>rmvirtualenv</b>.<br><br><b>--python=<i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Python executable to use for the new environment (e.g., <i>--python=/usr/bin/python3.9</i>). Primarily used with <b>mkvirtualenv</b>.<br><br><b>--system-site-packages</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Grants the virtual environment access to the global site-packages directory. Used with <b>mkvirtualenv</b> and <b>cpvirtualenv</b>.<br><br><b><i>&lt;source_env&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The name of an existing virtual environment to copy from. Used with <b>cpvirtualenv</b>.<br><br><b><i>&lt;new_env&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired name for the new virtual environment being created as a copy. Used with <b>cpvirtualenv</b>.<br><br>


title: DESCRIPTION
content:
<i>virtualenvwrapper</i> is a set of shell functions that extend Doug Hellmann's <i>virtualenv</i> (or Python 3's built-in <i>venv</i> module) to simplify the process of creating, deleting, and switching between Python virtual environments. It provides a convenient wrapper around the often verbose <i>virtualenv</i> commands, offering a streamlined workflow for developers managing multiple projects with distinct dependencies.<br><br>Key features include standardizing the location of all virtual environments (defaulting to <i>~/.virtualenvs</i>), providing quick commands for common tasks like <b>mkvirtualenv</b> (create), <b>workon</b> (activate/switch), <b>rmvirtualenv</b> (delete), and <b>deactivate</b> (deactivate current environment). It also offers utilities such as <b>lsvirtualenv</b> (list environments), <b>cdvirtualenv</b> (change to active environment's directory), and <b>cpvirtualenv</b> (copy an environment). By integrating seamlessly with your shell (Bash, Zsh, Ksh), <i>virtualenvwrapper</i> ensures a consistent and efficient way to isolate project dependencies, preventing conflicts and maintaining a clean development setup.


title: CAVEATS
content:
<i>virtualenvwrapper</i> relies on either the standalone <i>virtualenv</i> package or Python 3's built-in <i>venv</i> module being installed. It must be sourced in your shell's startup file (e.g., <i>.bashrc</i>, <i>.zshrc</i>) to make its commands available permanently. If not sourced, the commands will only be available in the current terminal session. Users should be aware that it modifies the shell environment, which can sometimes interact with other shell configurations if not set up carefully.


title: INSTALLATION AND CONFIGURATION
content:
To install, use pip: <b>pip install virtualenvwrapper</b>. After installation, add the following lines to your shell's startup file (e.g., <i>~/.bashrc</i>, <i>~/.zshrc</i>), ensuring <b>WORKON_HOME</b> is set to your preferred directory for virtual environments:<br><br><b>export WORKON_HOME=$HOME/.virtualenvs</b><br><b>export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3</b> (<i>optional</i>)<br><b>source /usr/local/bin/virtualenvwrapper.sh</b><br><br>Reload your shell (e.g., <b>source ~/.bashrc</b>) for the changes to take effect.


title: IMPORTANT ENVIRONMENT VARIABLES
content:
<b>WORKON_HOME</b>: Specifies the directory where all virtual environments will be stored (defaults to <i>~/.virtualenvs</i>).<br><b>VIRTUALENVWRAPPER_PYTHON</b>: Sets the default Python interpreter to use when creating new environments with <b>mkvirtualenv</b>.<br><b>VIRTUALENVWRAPPER_VIRTUALENV</b>: Specifies the path to the <i>virtualenv</i> executable, if it's not in your PATH or you want to use a specific one.<br><b>VIRTUALENVWRAPPER_HOOK_DIR</b>: Defines a directory for custom shell scripts (hooks) that run before or after <i>virtualenvwrapper</i> commands.


title: HISTORY
content:
Developed by Doug Hellmann, <i>virtualenvwrapper</i> emerged as a solution to streamline the management of Python virtual environments, which could be cumbersome using <i>virtualenv</i> directly. It was first released in 2009 and quickly gained popularity within the Python community due to its intuitive interface and powerful features. Its development closely paralleled the increasing adoption of <i>virtualenv</i> and <i>pip</i> for dependency management, becoming an almost indispensable tool for Python developers seeking clean, isolated development environments. While initially a separate project, its functionality is now often considered a standard component of a well-configured Python development setup, continuously adapting to changes in Python versions and packaging tools.


title: SYNOPSIS
content:
<b>visidata</b> [<i>-h</i> | <i>--help</i>] [<i>-v</i> | <i>--version</i>] [<i>-f</i>] [<i>-c COMMAND</i>] [<i>-p PLUGIN</i>] [<i>file ...</i>]


title: PARAMETERS
content:
<b><i>file ...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to one or more files to open. <i>Visidata</i> attempts to auto-detect the file type.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the program's version number and exit.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force raw opening of files, bypassing automatic file type detection. Useful for files with unusual extensions or structure.<br><br><b><b>-c</b> <i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Execute a <i>Visidata</i> command string immediately after opening files. Useful for scripting automated operations.<br><br><b><b>-p</b> <i>PLUGIN</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load a specified <i>Visidata</i> plugin. Plugins extend <i>Visidata</i>'s functionality.<br><br>


title: DESCRIPTION
content:
<i>Visidata</i> is a powerful, interactive, and fast command-line tool for exploring and manipulating tabular data. Inspired by <I>vim</I>, it operates as a modal terminal spreadsheet, allowing users to navigate, filter, sort, aggregate, and transform datasets directly within the terminal.<br><br>It supports a wide range of data formats, including CSV, TSV, JSON, Excel, Feather, Parquet, SQLite databases, and more, making it an incredibly versatile tool for data analysis, cleaning, and reporting. Users can quickly identify patterns, calculate statistics, generate pivot tables, and even create basic plots without leaving the terminal environment. Its intuitive keybindings and extensible architecture (through Python scripting) make it a favorite among developers, data scientists, and anyone who needs to quickly inspect and work with structured data.


title: CAVEATS
content:
While powerful, <i>Visidata</i> has a notable learning curve due to its <I>vim</I>-like modal interface. It is primarily designed for interactive exploration and may not be suitable for extremely large datasets that exceed available memory, or for complex, non-tabular data transformations best handled by dedicated scripting languages or database tools.


title: KEYBINDINGS AND MODES
content:
<i>Visidata</i> operates using a modal interface, similar to <i>vim</i>. It has various modes (e.g., normal, sheet, column) and uses single-key commands for navigation, filtering, sorting, and other operations. Familiarity with <I>vim</I> can greatly accelerate the learning process.


title: EXTENSIBILITY WITH PYTHON
content:
One of <i>Visidata</i>'s strengths is its extensibility. Users can write custom Python scripts and plugins to add new commands, data sources, or functionalities, tailoring the tool to specific needs and workflows.


title: HISTORY
content:
<i>Visidata</i> was created by Saul Pwanson, with its initial public release occurring around 2018. It is written in Python and has quickly gained popularity among developers and data professionals for its unique approach to data interaction in the terminal. The project continues to be actively developed and maintained by a growing community.


title: PARAMETERS
content:
<b>-f <I>sudoers_file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate <i>sudoers</i> file path to edit instead of the default <i>/etc/sudoers</i>.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check-only mode. Parses the <i>sudoers</i> file for syntax errors without opening it for editing.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode. Suppresses non-essential output, particularly useful when checking for syntax errors with <i>-c</i>.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Strict mode. Enables stricter syntax checking of the <i>sudoers</i> file, potentially catching more subtle issues.<br><br>


title: DESCRIPTION
content:
<i>visudo</i> is a command-line utility used to safely edit the <i>sudoers</i> file, which controls who can run what commands as whom on a Linux system.<br>It functions similarly to <i>sudo</i> by allowing only authorized users (typically root or those with <i>sudo</i> privileges) to modify this critical configuration file. The main advantage of <i>visudo</i> over directly editing <i>/etc/sudoers</i> is its built-in syntax checking. Before saving changes, <i>visudo</i> parses the file for errors. If an error is found, it prompts the user to either re-edit, quit without saving, or save anyway (which is highly discouraged as a broken <i>sudoers</i> file can lock out all <i>sudo</i> access).<br>It also applies a file lock to prevent multiple users from editing simultaneously and ensures the file permissions are correct upon saving. This preventative approach helps maintain system security and prevents accidental lockouts.


title: CAVEATS
content:
Always use <i>visudo</i> to edit the <i>sudoers</i> file. Directly editing can lead to syntax errors that lock out <i>sudo</i> access, potentially requiring a boot into single-user mode to fix.<br>A broken <i>sudoers</i> file can render <i>sudo</i> unusable, which is a critical security and administrative issue. Ensure proper permissions when using <i>visudo -f</i> on non-standard files.


title: DEFAULT EDITOR
content:
<i>visudo</i> determines which editor to launch based on the <i>VISUAL</i> or <i>EDITOR</i> environment variables. If neither is set, it defaults to <i>vi</i>.


title: FILE LOCKING
content:
During editing, <i>visudo</i> applies a lock to the <i>sudoers</i> file to prevent multiple concurrent modifications, ensuring data integrity.


title: SYNTAX VALIDATION
content:
Upon exiting the editor, <i>visudo</i> rigorously checks the <i>sudoers</i> file for syntax errors. If errors are found, it provides options to re-edit, quit without saving, or save with errors (the last option is highly discouraged due to the risk of locking out <i>sudo</i> access).


title: HISTORY
content:
The <i>sudo</i> project and <i>visudo</i> were developed to provide a secure and auditable way for privileged users to grant specific command execution rights to unprivileged users. <i>visudo</i> emerged as the standard tool to manage the <i>sudoers</i> file, integrating critical features like syntax checking and file locking to prevent common configuration errors and simultaneous edits, which were significant issues in earlier, less structured privilege management systems. Its design philosophy emphasizes safety and robustness in managing critical system configurations.


title: SYNOPSIS
content:
As Vite is not a native Linux command, it's typically invoked via <I>npx</I> or within project scripts defined in <I>package.json</I>:<br><br><b><I>npx vite [command] [options]</I></b><br><b><I>npm run [script]</I></b> (e.g., <I>npm run dev</I>, <I>npm run build</I>)<br><br>Common options applicable to various commands:<br><br>  <I>--host</I>          Specify hostname<br>  <I>--port <port></I>   Specify port for the server<br>  <I>--mode <mode></I>   Specify environment mode (e.g., <I>development</I>, <I>production</I>)


title: PARAMETERS
content:
<b>dev</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the development server. Provides lightning-fast Hot Module Replacement (HMR) for a smooth development workflow.<br><br><b>build</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bundles the application for production deployment. Optimizes assets and code with <I>Rollup</I> for efficient loading and performance.<br><br><b>preview</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Serves the production build locally for testing and verification before actual deployment. Useful for checking the optimized output.<br><br><b>create [project-name]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scaffolds a new Vite project using a chosen template (e.g., <I>vue</I>, <I>react</I>, <I>vanilla</I>, <I>lit</I>). This is often run via <I>npm create vite@latest</I> or <I>yarn create vite</I>.<br><br><b>optimize</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly pre-bundles dependencies. This command is rarely needed as Vite automatically handles dependency pre-bundling on startup for performance.<br><br>


title: DESCRIPTION
content:
<b>Vite</b> (<I>French for "fast"</I>) is a build tool that significantly improves the frontend development experience. It consists of a dev server that provides rich feature enhancements over native <I>ES modules</I>, such as incredibly fast Hot Module Replacement (<I>HMR</I>), and a build command that bundles your code with <I>Rollup</I> for production. Unlike traditional bundler-based setups, Vite leverages the browser's native ES modules support for development, allowing it to start instantly and apply updates almost instantaneously. It's designed to be framework-agnostic, supporting <I>Vue</I>, <I>React</I>, <I>Preact</I>, <I>Svelte</I>, <I>Lit</I>, and vanilla JavaScript/TypeScript projects. Vite is primarily used via <I>npm</I> or <I>yarn</I> scripts and requires <I>Node.js</I> to run.


title: CAVEATS
content:
Vite is a <I>JavaScript build tool</I> and a development server, not a standalone Linux command-line utility. It requires <I>Node.js</I> and a package manager like <I>npm</I> or <I>yarn</I> to be installed and run. Its usage is confined to web development projects and is typically invoked via project-specific scripts defined in <I>package.json</I> or using <I>npx</I>.


title: INSTALLATION & PROJECT SETUP
content:
Vite itself is not typically installed globally as a Linux command. Instead, it's added as a development dependency to your project. The most common way to start a new project with Vite is to use its scaffolding tool:<br><br><b><I>npm create vite@latest [project-name]</I></b><br><b><I>yarn create vite [project-name]</I></b><br><b><I>pnpm create vite [project-name]</I></b><br><br>This command sets up a new project with Vite configured. Inside an existing project, Vite is usually listed in <I>devDependencies</I> in <I>package.json</I>.


title: CONFIGURATION
content:
Vite is configured via a <I>vite.config.js</I> (or <I>.ts</I>, <I>.mjs</I>, <I>.mts</I>) file located in the project root. This file allows developers to customize various aspects of the dev server, build process, integrate plugins, define aliases, and much more. It supports JavaScript, TypeScript, or ESM syntax for flexible configuration.


title: HISTORY
content:
Vite was created by <I>Evan You</I>, the creator of <I>Vue.js</I>, and was initially released in 2020. It emerged from the need for a faster development experience for large <I>Vue</I> projects, directly addressing the performance bottlenecks of traditional JavaScript bundlers during development. By leveraging native <I>ES Modules</I> in the browser and highly optimized build processes, Vite quickly gained traction as a modern and efficient alternative for frontend tooling across various frameworks, emphasizing speed and developer experience.


title: SYNOPSIS
content:
<b>vitest</b> [<i>command</i>] [<i>options</i>] [<i>files...</i>]<br><i>command</i>: Optional subcommand (e.g., run, watch, ui, coverage). 'watch' is default.<br><i>options</i>: Global or command-specific options (e.g., --config, --environment).<br><i>files...</i>: Optional list of test files or glob patterns to run.


title: PARAMETERS
content:
<b>--root <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the project root directory where tests are located.<br><br><b>--config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a custom path to the Vitest configuration file.<br><br><b>--environment <env></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the test environment, e.g., 'node' for server-side or 'jsdom'/'happy-dom' for browser-like DOM.<br><br><b>--globals</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exposes test APIs (like 'describe', 'it', 'expect') globally, avoiding explicit imports.<br><br><b>--passWithNoTests</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows the test suite to pass even if no test files are found or executed.<br><br><b>--reporter <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the test result reporter, e.g., 'default', 'verbose', 'json', 'dot'.<br><br><b>--watch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs tests in interactive watch mode, re-running affected tests on file changes (default behavior).<br><br><b>--run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes tests once and then exits, typically used in CI/CD environments.<br><br><b>--coverage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables code coverage reporting for the test run, requiring a coverage provider.<br><br><b>--ui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the Vitest UI, providing a visual interface for test results.<br><br><b>--threads</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether tests are run in worker threads (default true), improving performance.<br><br><b>--shard <shard>/<total></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Distributes tests across multiple parallel CI jobs by sharding.<br><br>


title: DESCRIPTION
content:
<i>Vitest</i> is a blazing-fast unit test framework powered by <i>Vite</i>, designed for seamless integration into modern JavaScript and TypeScript projects. It offers a familiar API inspired by <i>Jest</i>, but with significant performance advantages, especially within the <i>Vite</i> ecosystem. Key features include instant <b>Hot Module Replacement (HMR)</b> for tests, out-of-the-box support for TypeScript and JSX, a smart and instant watch mode, and a highly configurable environment. It aims to provide an exceptional developer experience by significantly speeding up the test feedback loop, making it an ideal choice for contemporary web development workflows.


title: CAVEATS
content:
<i>Vitest</i> is a Node.js-based tool and must be installed as a development dependency via a package manager (npm, yarn, pnpm) within a project. It is not a system-level command available by default on Linux. Its optimal performance and seamless integration are primarily realized within <i>Vite</i>-powered projects, where it leverages shared infrastructure. Configuration often resides in <i>vitest.config.ts</i> or extends <i>vite.config.ts</i>.


title: CONFIGURATION FLEXIBILITY
content:
<i>Vitest</i> offers extensive configuration options via <i>vitest.config.ts</i> (or by extending <i>vite.config.ts</i>). This allows developers to fine-tune every aspect of the testing environment, including test glob patterns, reporters, test environments (e.g., JSDOM), setup files, mocks, and coverage thresholds, ensuring adaptability to diverse project requirements.


title: HOT MODULE REPLACEMENT (HMR) FOR TESTS
content:
A core differentiator is <i>Vitest</i>'s integration with <i>Vite</i>'s <b>HMR</b>. When source code or test files change, <i>Vitest</i> intelligently re-runs only the affected tests almost instantaneously. This dramatically reduces waiting times during development, providing immediate feedback and significantly enhancing developer productivity compared to traditional test runners.


title: HISTORY
content:
<i>Vitest</i> was publicly announced in late 2021 by the creators of <i>Vite</i>, quickly gaining momentum throughout 2022. Its inception aimed to fill the gap for a rapid, modern testing solution that integrates natively with the <i>Vite</i> development server, offering a similar developer experience. Inspired by <i>Jest</i>'s API but built with <i>Vite</i>'s underlying architecture, it addresses the need for faster test feedback loops in contemporary web development. Its rapid adoption underscores its effectiveness and the growing demand for highly optimized developer tools.


title: PARAMETERS
content:
<b><b>-w</b> &lt;<i>width</i>&gt;, <b>--width</b> &lt;<i>width</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum width of the output image in characters.<br><br><b><b>-h</b> &lt;<i>height</i>&gt;, <b>--height</b> &lt;<i>height</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum height of the output image in lines.<br><br><b><b>-s</b>, <b>--stretch</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stretches the image to fill the available width/height of the terminal, potentially ignoring the aspect ratio.<br><br><b><b>-t</b>, <b>--truecolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces 24-bit true color output, providing better color fidelity if supported by the terminal. Overrides block character mode.<br><br><b><b>-b</b>, <b>--blocks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces rendering using Unicode block characters. This is generally more compatible across terminals but offers less detail than true color.<br><br><b><b>-c</b> &lt;<i>contrast</i>&gt;, <b>--contrast</b> &lt;<i>contrast</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the output contrast. Use a float value (e.g., <i>1.5</i> for increased contrast, <i>0.5</i> for decreased).<br><br><b><b>--transparent</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders transparent images with proper transparency, blending with the terminal background.<br><br><b><b>--upscale</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows small images to be upscaled to fit the specified dimensions or terminal size, rather than only downscaling.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>viu</b> version information and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<b>viu</b> is a lightweight, command-line image viewer that renders images directly within the terminal emulator using Unicode block characters and true-color support. Written in Rust, it leverages modern terminal capabilities to provide a surprisingly clear representation of images without needing a graphical display server.<br><br>It's particularly useful for quick image previews on remote servers, headless environments, or for integrating image display into shell scripts. <b>viu</b> supports various common image formats and can automatically scale images to fit the terminal window, making it a versatile tool for developers, system administrators, and anyone who needs to interact with images purely from the command line. Its focus is on speed and simplicity, providing a no-frills way to visualize images within a text-based interface.


title: CAVEATS
content:
Performance can be limited by terminal capabilities and network speed (e.g., SSH). Rendering quality is highly dependent on your terminal emulator's support for true colors and Unicode characters. <b>viu</b> is designed for display, not interactive manipulation, so it lacks features like zooming, panning, or editing.<br><br>While it attempts to preserve aspect ratio by default, using <b>--stretch</b> or specific width/height values may distort the image.


title: RENDERING MODES
content:
<b>viu</b> offers different rendering modes: <i>true color</i> for high fidelity (requiring a compatible terminal) and <i>block character</i> mode for broader compatibility and a more 'pixelated' appearance. You can explicitly choose between them using the <b>-t</b> and <b>-b</b> options; <b>-b</b> takes precedence if both are specified.


title: TYPICAL USE CASES
content:
Beyond simple image viewing, <b>viu</b> is invaluable for scripting image processing workflows, quick previews of generated graphics in CI/CD pipelines, or inspecting datasets on remote machines without needing to transfer files or set up X forwarding. It seamlessly integrates into shell scripts for automated image verification or display.


title: HISTORY
content:
<b>viu</b> emerged from the growing need to visualize images directly within command-line environments, especially prevalent in server management and scripting where a graphical desktop might be absent. Developed in Rust, it benefits from the language's performance characteristics and cross-platform compatibility. It represents a modern approach to terminal image rendering, moving beyond ASCII art to leverage true color and Unicode block elements. Its development reflects a broader trend in the Linux community to enhance the capabilities of the terminal, making it a more versatile and visually rich environment.


title: SYNOPSIS
content:
<b>vivaldi</b> [<i>OPTIONS</i>] [<i>URL</i>]<br>
<b>vivaldi</b> (Launches the browser with default settings)<br>
<b>vivaldi</b> <i>https://example.com</i> (Opens a specific URL)


title: PARAMETERS
content:
<b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of available command-line options and their descriptions.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the Vivaldi browser version number and build information.<br><br><b>--new-window</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the opening of a new browser window, even if an instance is already running.<br><br><b>--incognito</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches a new window in private browsing (incognito) mode, where browsing history and cookies are not saved.<br><br><b>--app=<I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified URL in a simplified, application-mode window without typical browser UI elements.<br><br><b>--profile-directory=<I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user profile directory to use. For example, 'Profile 1' for the second profile.<br><br><b>--no-sandbox</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the browser's sandbox security feature. <b>Use with caution and only for debugging.</b><br><br><b>--disable-gpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables GPU hardware acceleration, which can be useful for troubleshooting rendering issues.<br><br><b>--start-maximized</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the browser window in a maximized state.<br><br><b>--start-fullscreen</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Launches the browser window in fullscreen mode.<br><br>


title: DESCRIPTION
content:
Vivaldi is a feature-rich, highly customizable web browser developed by Vivaldi Technologies. Founded by Jon von Tetzchner, co-founder and former CEO of Opera Software, Vivaldi aims to cater to power users who felt abandoned by Opera's transition from Presto to Blink and its change in focus. Built on the Chromium open-source project, Vivaldi distinguishes itself with a unique user interface and a plethora of innovative features. These include advanced tab management, a built-in mail client, calendar, and feed reader, custom keyboard shortcuts, mouse gestures, and a highly configurable interface that allows users to tailor almost every aspect of their browsing experience. It prioritizes privacy and offers robust synchronization options. While benefiting from Chromium's rendering engine and web compatibility, Vivaldi focuses on adding value through its distinctive feature set and commitment to user control, providing a powerful and flexible alternative in the crowded browser market.


title: CAVEATS
content:
Vivaldi is primarily a graphical user interface (GUI) application, and its command-line interface (CLI) is mainly for launching the browser with specific configurations or for debugging purposes, rather than for direct interaction with web content. Most of its advanced features are accessed through the GUI. Many command-line options are inherited directly from the Chromium project, meaning they are numerous and often undocumented specifically for Vivaldi, requiring familiarity with Chromium's flags. While efficient, like all modern browsers, it can be resource-intensive, particularly with many tabs or extensions. Vivaldi is proprietary software, although it leverages the open-source Chromium project.


title: SETTING AS DEFAULT BROWSER
content:
While <b>vivaldi</b> can be launched from the command line, setting it as the system's default browser is typically done through the browser's internal settings (<i>Settings > General > Default Browser</i>) or via your desktop environment's preferences (e.g., GNOME Settings, KDE System Settings) for handling web links.


title: USER PROFILES MANAGEMENT
content:
Vivaldi supports multiple user profiles, allowing different sets of bookmarks, history, extensions, and settings. These can be managed within the browser GUI (<i>File > Manage Profiles</i>). The <b>--profile-directory</b> command-line option is useful for launching a specific profile directly without switching within the browser, e.g., <b>vivaldi --profile-directory="Profile 1"</b>.


title: HISTORY
content:
Vivaldi Technologies was founded by Jon von Tetzchner and Tatsuki Tomita in 2013. Von Tetzchner, co-founder and former CEO of Opera Software, started Vivaldi in response to Opera's shift from its own Presto rendering engine to Blink (Chromium-based) and its decision to simplify its feature set, which many power users felt abandoned them. The first technical preview of Vivaldi was released in January 2015, with the first stable version (1.0) launching in April 2016. Vivaldi's development has consistently focused on bringing back and enhancing features popular among advanced users, such as extensive customization, tab stacks, mouse gestures, and built-in tools like a mail client, calendar, and notes. Its aim has been to provide a highly flexible browser that adapts to the user's workflow, rather than forcing the user to adapt to the browser.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the script's version information and exits.<br><br><b>-t <i>&lt;token&gt;</i>, --token <i>&lt;token&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the VK API access token required for authentication. This token grants the script permission to access and modify your VK account data.<br><br><b>-u <i>&lt;user_id&gt;</i>, --user <i>&lt;user_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used specifically when purging messages, targeting a conversation with a particular user ID.<br><br><b>--type <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mandatory. Specifies the type of content to purge. Common types include <b>`messages`</b>, <b>`photos`</b>, <b>`posts`</b>, <b>`friends`</b>, or <b>`groups`</b>.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with `--type`, indicates that all items of the specified content type should be purged (e.g., all messages, all photos).<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the purge operation without actually deleting any data. Useful for verifying what would be deleted.<br><br><b>--confirm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses the interactive confirmation prompt before deletion, proceeding directly with the purge. Use with extreme caution.<br><br><b>--after <i>&lt;date&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Purge content created after the specified date (format typically YYYY-MM-DD or Unix timestamp).<br><br><b>--before <i>&lt;date&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Purge content created before the specified date (format typically YYYY-MM-DD or Unix timestamp).<br><br><b>--album <i>&lt;album_id&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When purging photos, specifies a particular album ID from which to delete photos.<br><br>


title: DESCRIPTION
content:
The `vkpurge` command, typically implemented as a Python script, is a utility designed to automate the mass deletion of various content types from a Vkontakte (VK) social network account. Its primary purpose is to provide users with a programmatic way to manage their digital footprint on the VK platform, which can be time-consuming and tedious to do manually through the web interface. <br><br>Common use cases include purging old private messages, removing uploaded photos or albums, deleting posts from one's wall, or leaving numerous groups. It operates by interacting with the VK API (Application Programming Interface), requiring an access token for authentication. Due to the irreversible nature of deletion, `vkpurge` usually incorporates safety mechanisms such as confirmation prompts and a "dry-run" mode to prevent accidental data loss. It's an indispensable tool for users looking to perform a comprehensive cleanup of their VK profile.


title: CAVEATS
content:
<ul><li><b>Irreversible Data Loss:</b> Content deleted using `vkpurge` is permanently removed and cannot be recovered. Always use the `--dry-run` option first.</li><li><b>API Token Security:</b> Your VK API access token grants significant control over your account. Keep it secure and do not hardcode it directly into scripts or expose it publicly.</li><li><b>Not a Standard Linux Command:</b> `vkpurge` is typically a community-developed, third-party Python script, not a utility pre-installed with most Linux distributions. Its availability, features, and behavior may vary depending on the specific implementation.</li><li><b>VK API Rate Limits:</b> Frequent or excessive API requests can lead to temporary blocking by VK's API, preventing further operations.</li><li><b>Evolving VK API:</b> The VK API can change, which might break older versions of `vkpurge` scripts, requiring updates from the developer.</li></ul>


title: INSTALLATION
content:
As `vkpurge` is usually a Python script, it is commonly installed via pip. For example, `pip install vk_api` might provide a library, and the `vkpurge` script itself could be part of that package or a separate download from a repository like GitHub. Ensure you have Python and pip installed on your system first.


title: AUTHENTICATION
content:
To use `vkpurge`, you need a VK API access token. This token can often be obtained through the VK Developers website (e.g., via Implicit Flow for client-side applications) or by using specific libraries that handle the OAuth authentication process. The token must have the necessary permissions (scopes) for the actions you intend to perform (e.g., `messages`, `photos`, `wall`).


title: HISTORY
content:
The concept of `vkpurge` arose from the need for automated VK content management, driven by users desiring to quickly clean up their extensive digital footprint on the platform. Early versions were often simple, personal scripts, typically written in Python, to delete specific types of content like old messages. Over time, these scripts evolved into more generalized and robust tools, often shared on platforms like GitHub, incorporating features such as different content type support, date filtering, dry-run modes, and user authentication via VK API tokens. Its development has largely been decentralized, reflecting community efforts to address a common user need rather than a single official project.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message with all available command-line options.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the installed <i>VLC</i> player.<br><br><b><b>-L</b>, <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available <i>VLC</i> modules and interfaces.<br><br><b><b>-p</b>, <b>--play-and-exit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays the specified item(s) and then automatically exits <i>VLC</i> upon completion.<br><br><b><b>-f</b>, <b>--fullscreen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>VLC</i> immediately in full-screen video mode.<br><br><b><b>-I</b> <i>&lt;interface&gt;</i>, <b>--interface</b> <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the interface module to use (e.g., <i>qt</i>, <i>ncurses</i>, <i>rc</i>, <i>dummy</i>).<br><br><b><b>--no-video</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables video output, playing only the audio portion of a media file.<br><br><b><b>--no-audio</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables audio output, playing only the video portion of a media file.<br><br><b><b>--rate</b> <i>&lt;float&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the playback speed. For example, <i>2.0</i> for double speed, <i>0.5</i> for half speed.<br><br><b><b>--loop</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continuously loops the playback of the specified media item or playlist.<br><br><b><b>--run-time</b> <i>&lt;float&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Plays for a specific duration in seconds and then stops or exits.<br><br><b><b>--sub-file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads an external subtitle file for the currently playing media.<br><br><b><b>--start-time</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts playback from a specific time offset in seconds.<br><br><b><b>--stop-time</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops playback at a specific time offset in seconds.<br><br><b><b>--volume</b> <i>&lt;integer&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial volume level (0-256), where 256 is 100%.<br><br><b><b>--playlist-enqueue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds the specified item(s) to the current playlist without clearing existing items.<br><br><b><b>--sout</b> <i>&lt;string&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures stream output. This is a very powerful and complex option for streaming and transcoding media.<br><br>


title: DESCRIPTION
content:
<i>VLC Media Player</i> is a free, open-source, and highly portable multimedia player and streaming server. Developed by the VideoLAN project, it stands out for its exceptional ability to play a vast array of audio and video formats, including DVDs, CDs, and various streaming protocols, without requiring external codecs. It can stream media across networks, transcode files, and offers extensive customization via plugins. Its robust command-line interface extends its utility beyond the graphical user interface, enabling powerful scripting and automation for tasks ranging from simple playback to complex streaming operations. VLC is widely recognized for its 'play anything' capability, making it a go-to choice for users across Windows, macOS, Linux, and mobile platforms.


title: CAVEATS
content:
<i>VLC</i>'s command-line interface offers immense power but can be complex, especially for advanced streaming (<b>--sout</b>) and transcoding configurations, which often require detailed knowledge of syntax. While generally robust, playback performance and hardware acceleration capabilities can vary significantly across different systems and media formats. Certain codecs or specialized hardware may require additional system-level drivers or configurations for optimal performance.


title: NETWORK STREAMING & TRANSCODING CAPABILITIES
content:
Beyond simple playback, <i>VLC</i>'s command-line interface excels in network streaming and media transcoding. Using the <b>--sout</b> option, users can stream content over various network protocols (e.g., HTTP, RTP, RTSP) or convert media files between different formats and codecs. This makes it an invaluable tool for server-side applications, broadcasting, and media conversion workflows.


title: REMOTE CONTROL & AUTOMATION
content:
<i>VLC</i> supports various remote control interfaces, including an HTTP interface (<b>--http-intf</b>) and a remote control interface (<b>--rc-intf</b>), allowing it to be controlled programmatically or via dedicated remote apps. This capability is particularly useful for integrating <i>VLC</i> into home automation systems, kiosks, or custom media playback solutions, enabling advanced automation and unattended operation.


title: HISTORY
content:
Originating in 1996 as the <i>VideoLAN Client</i> at École Centrale Paris, <i>VLC</i> was initially conceived for streaming video across the campus network. It was open-sourced under the GPL in 2001, a pivotal moment that propelled its adoption due to its ability to play virtually any media format without needing external codecs. Its development has been community-driven ever since, continually evolving to support new formats, protocols, and platforms, solidifying its status as a ubiquitous and highly respected media player.


title: SYNOPSIS
content:
<b>vlc-wrapper</b> [<i>options</i>] [<i>file(s)</i>]<br><i>Note: It generally accepts the same options and arguments as the underlying <b>vlc</b> command.</i>


title: PARAMETERS
content:
<b>[VLC_OPTIONS]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any and all options and arguments that would normally be passed to the main <code>vlc</code> command are accepted by <code>vlc-wrapper</code> and forwarded directly. Refer to <code>vlc(1)</code> for a complete list of parameters.<br><br>


title: DESCRIPTION
content:
<code>vlc-wrapper</code> is a utility script that acts as an intermediary for launching the main <b>VLC</b> media player application. Its primary purpose is often to set up the correct environment before <b>VLC</b> starts, such as configuring library paths (e.g., <code>LD_LIBRARY_PATH</code>), handling specific display server settings (e.g., Wayland vs. X11), or integrating with sandboxed environments like Snap or Flatpak.<br><br>While it executes the <code>vlc</code> binary, <code>vlc-wrapper</code> ensures that all necessary prerequisites and configurations are in place, making the launch of VLC more robust and compatible with various system setups or packaging methods. Users typically interact with <code>vlc-wrapper</code> unknowingly when launching <b>VLC</b>, as it might be the default command linked to by desktop shortcuts or command-line aliases.


title: CAVEATS
content:
<ul><li>The exact behavior and existence of <code>vlc-wrapper</code> can vary significantly across Linux distributions and packaging methods (e.g., native <code>.deb</code>/<code>.rpm</code>, Snap, Flatpak, AppImage).</li><li>It's a wrapper, not a standalone application. Issues might originate from the underlying <code>vlc</code> binary or the wrapper script itself.</li><li>Debugging issues often requires inspecting the wrapper script (usually located in <code>/usr/bin/</code> or similar paths) to understand its environment setup.</li><li>Directly calling <code>vlc</code> instead of <code>vlc-wrapper</code> might bypass certain environment configurations or sandboxing, potentially leading to different behavior or errors.</li></ul>


title: INSPECTING THE WRAPPER SCRIPT
content:
To understand precisely what <code>vlc-wrapper</code> does on your system, you can inspect its contents. It is typically a shell script located in <code>/usr/bin/</code> or similar directories. Using <code><b>cat /usr/bin/vlc-wrapper</b></code> or <code><b>less /usr/bin/vlc-wrapper</b></code> can reveal the environment variables it sets, the actual <code>vlc</code> binary it calls, and any other pre-execution commands.


title: COMMON USE CASES
content:
Beyond simple environment setup, <code>vlc-wrapper</code> is often employed to enforce specific security policies, redirect log output, or manage resource limits before the main <b>VLC</b> application begins execution, especially in managed or sandboxed computing environments.


title: HISTORY
content:
<code>vlc-wrapper</code> doesn't have a distinct historical development separate from the <b>VLC</b> media player itself. Its genesis is tied more to operating system packaging conventions and the evolution of application distribution methods on Linux. Historically, it emerged as a practical solution for packagers to ensure <b>VLC</b> runs correctly out-of-the-box, particularly when dealing with specific library dependencies or runtime environments that differ from a pure system-wide installation.<br><br>With the rise of containerized or sandboxed application formats like Snap and Flatpak, wrappers like <code>vlc-wrapper</code> became even more critical for setting up the isolated environments and ensuring proper access to system resources while maintaining security. Its usage is primarily an implementation detail for distribution maintainers, rather than a user-facing historical milestone.


title: SYNOPSIS
content:
<B>vlock</B> [<I>options</I>]<br><B>vlock</B> <B>-a</B> [<I>options</I>]<br><B>vlock</B> <B>-u</B> [<I>options</I>]


title: PARAMETERS
content:
<b><B>-a</B>, <B>--all</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Locks all virtual consoles. Only the console from which <i>vlock</i> was invoked can be unlocked. This option typically requires root privileges.<br><br><b><B>-c</B>, <B>--current</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Locks only the current virtual console. This is often the default behavior if no other console options are specified.<br><br><b><B>-n</B>, <B>--no-beep</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the audible beep sound that typically occurs when an incorrect password is entered.<br><br><b><B>-s</B>, <B>--silent</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not print the "Password:" prompt to the console, which can be useful when scripting or integrating <i>vlock</i> into automated processes.<br><br><b><B>-u</B>, <B>--unlock-all</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unlocks all previously locked virtual consoles. This option typically requires root privileges or the password of the user who initiated the lock.<br><br><b><B>-o</B> <I>owner</I>, <B>--owner</B> <I>owner</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the owner for the lock file. This is an advanced option and not commonly used in typical console locking scenarios.<br><br><b><B>-d</B> <I>descriptor</I>, <B>--descriptor</B> <I>descriptor</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the descriptor for the lock file. Similar to <B>-o</B>, this is an advanced option for specific use cases.<br><br>


title: DESCRIPTION
content:
<i>vlock</i> is a powerful yet straightforward command-line utility in Linux, specifically designed to secure one or all virtual consoles (TTYs). Its primary function is to prevent unauthorized access to an active console session. When you execute <i>vlock</i>, it prompts you for a password—either your user password or the root password, depending on the command's options and your system's configuration. Upon successful authentication, <i>vlock</i> effectively freezes the console, disabling all keyboard and mouse input until the correct password is re-entered. This makes it an indispensable tool in multi-user environments, protecting your open applications, shell sessions, and data when you step away from the physical machine. Unlike graphical screen lockers that secure desktop environments, <i>vlock</i> operates at the foundational virtual console level, making it a robust security measure for text-based interfaces.


title: CAVEATS
content:
<i>vlock</i> is designed exclusively for virtual consoles (text-mode TTYs); it offers no protection for graphical desktop environments (e.g., Xorg, Wayland). For securing graphical sessions, users should employ dedicated screen lockers provided by their desktop environment or tools like <i>xscreensaver</i>. Using <B>-a</B> (lock all) or <B>-u</B> (unlock all) typically requires root privileges. A regular user running <i>vlock</i> without these flags can usually only lock and unlock their own current console.


title: SECURITY CONTEXT AND LIMITATIONS
content:
While effective at preventing casual access to a physical console, <i>vlock</i> is a basic security measure and not designed to thwart sophisticated attacks. An attacker with physical access might bypass <i>vlock</i> through system reboot, removal of power, or other hardware-level interventions. It provides a deterrent against opportunistic peeking rather than an impenetrable barrier.


title: PRIVILEGE AND UNLOCK BEHAVIOR
content:
When a non-root user executes <i>vlock</i> without the <B>-a</B> or <B>-u</B> options, it typically locks only their current console and can be unlocked using their own user password. However, to lock or unlock all available virtual consoles, <i>vlock</i> generally requires root privileges, often invoked with <i>sudo</i>, to ensure system-wide control.


title: HISTORY
content:
<i>vlock</i> has been a consistent and reliable utility within the Linux ecosystem for many years. It is often included as part of the <i>kbd</i> package, which encompasses various tools for managing the keyboard and console. Its development has focused on maintaining a simple yet effective mechanism for basic console security, with its core functionality remaining largely unchanged over time.


title: DESCRIPTION
content:
The <b>vmmouse_detect</b> command is a utility primarily associated with <i>VMware Tools</i> or <i>open-vm-tools</i>, designed to ascertain if the operating system is currently running within a VMware virtual machine environment and if the specialized <i>vmmouse</i> input driver is suitable for use. This driver provides optimized mouse performance, including features like seamless cursor integration and reduced input lag, crucial for a smooth user experience in a virtualized setting.<br><br>When executed, <b>vmmouse_detect</b> typically performs a check for specific VMware-related hardware or software signatures within the guest OS. Its primary purpose is to inform other system components, particularly the X Window System (Xorg), whether to load and configure the <i>vmmouse</i> kernel module and its associated Xorg driver. This automation helps in dynamically adjusting the input device configuration without manual intervention, ensuring that the guest OS utilizes the most efficient mouse handling method provided by the virtualization platform.


title: CAVEATS
content:
The <b>vmmouse_detect</b> command is specifically relevant to virtual machines running on VMware virtualization platforms. It requires <i>VMware Tools</i> or <i>open-vm-tools</i> to be installed and fully functional within the guest operating system.<br><br>Its utility is primarily for configuring the <i>vmmouse</i> Xorg input driver. In environments using Wayland or alternative display servers, or with modern Xorg auto-detection (e.g., via <i>evdev</i>), its direct influence might be less pronounced, though it may still be called internally by virtualization integration packages. Failure to properly detect the VMware environment can lead to suboptimal mouse performance, such as cursor stuttering or imprecise movement, within the virtual machine.


title: HISTORY
content:
The <b>vmmouse_detect</b> utility emerged as an integral part of <i>VMware Tools</i>, a suite of utilities designed to enhance the performance and manageability of guest operating systems within VMware virtual machines. In the early days of Linux guest support, configuring the mouse and graphics drivers often required manual editing of <i>xorg.conf</i>. <b>vmmouse_detect</b> automated the process of determining if the optimized <i>vmmouse</i> driver should be used, significantly simplifying the setup for users.<br><br>Over time, with the advent of more sophisticated auto-detection mechanisms in Xorg (like <i>udev</i> and <i>evdev</i>) and the rise of <i>open-vm-tools</i> (an open-source implementation), the explicit need for users to run or interact with <b>vmmouse_detect</b> directly diminished. However, it continues to serve as a foundational component within the virtualization integration stack, ensuring that the guest environment leverages the specialized VMware input capabilities for optimal user experience.


title: SYNOPSIS
content:
<b>vmstat</b> [<i>options</i>] [<i>delay</i> [<i>count</i>]]<br><br><i>delay</i>: Delay between updates in seconds.<br><i>count</i>: Number of updates to display.


title: PARAMETERS
content:
<b><i>delay</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the delay in seconds between each successive report. If not provided, <i>vmstat</i> prints a single report with averages since boot.<br><br><b><i>count</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of reports to generate. If a delay is specified but count is not, <i>vmstat</i> will report continuously.<br><br><b><b>-a</b>, <b>--active</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays active and inactive memory statistics. Active memory is memory in use, while inactive memory is eligible for reclaim.<br><br><b><b>-d</b>, <b>--disk</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports statistics for disk activity, including total reads/writes, merged reads/writes, and time spent on I/O.<br><br><b><b>-f</b>, <b>--forks</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports the number of forks since boot. This indicates how many processes have been created.<br><br><b><b>-m</b>, <b>--slabs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports slabinfo, showing kernel slab cache statistics. Useful for tracking kernel memory usage.<br><br><b><b>-n</b>, <b>--one-shot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the header only once, even with continuous reporting. Useful for piping output to other tools.<br><br><b><b>-p</b> <i>partition</i>, <b>--partition</b> <i>partition</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports statistics for a specific disk partition, e.g., <i>/dev/sda1</i>.<br><br><b><b>-s</b>, <b>--stats</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays event counters and various memory statistics in a single-report format, useful for quick overviews.<br><br><b><b>-t</b>, <b>--timestamp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a timestamp to each report, which is helpful for historical analysis or logging.<br><br><b><b>-S</b> <i>unit</i>, <b>--unit</b> <i>unit</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the unit for memory display. Common units include <i>k</i> (kilobytes), <i>M</i> (megabytes), <i>G</i> (gigabytes).<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information for <i>vmstat</i>.<br><br><b><b>-w</b>, <b>--wide</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a wider output format, which can prevent truncation of some columns, especially on systems with many CPUs.<br><br>


title: DESCRIPTION
content:
<i>vmstat</i> is a powerful command-line utility used for monitoring system performance on Linux and other Unix-like operating systems. It provides a concise summary of various system activities, including virtual memory statistics, process activity, block I/O, traps, and CPU utilization. By default, it displays an average report since the last reboot. However, it can be run in a continuous mode by specifying a delay and optionally a count, which allows users to observe system behavior changes over time.<br><br>The information provided by <i>vmstat</i> is crucial for identifying performance bottlenecks and resource exhaustion. For instance, high swap activity (<i>si</i>, <i>so</i> columns) can indicate memory pressure, while high CPU idle time (<i>id</i>) might suggest I/O bottlenecks if other CPU metrics are low but I/O is high. Its output is categorized into several sections, making it a versatile tool for system administrators and developers alike to diagnose system health and tune performance.


title: CAVEATS
content:
Interpreting <i>vmstat</i> output requires a good understanding of system architecture and typical resource usage patterns. Misinterpreting metrics can lead to incorrect conclusions about performance bottlenecks. For instance, high swap activity is often a sign of memory pressure, but it can also be normal during certain operations.<br><br>The data presented by <i>vmstat</i> in continuous mode represents averages over the specified interval, not instantaneous values. This means short bursts of activity might be smoothed out, and it might not capture very transient issues.<br><br>While useful, <i>vmstat</i> provides a high-level view. For deep-dive analysis, it often needs to be combined with other tools like <i>strace</i>, <i>perf</i>, or more specific profiling tools.


title: OUTPUT COLUMNS EXPLAINED
content:
The default <i>vmstat</i> output is divided into several main sections:<br><i>procs</i>:<br>&nbsp;&nbsp;<b>r</b>: The number of processes waiting for run time.<br>&nbsp;&nbsp;<b>b</b>: The number of processes in uninterruptible sleep (waiting for I/O).<br><i>memory</i>:<br>&nbsp;&nbsp;<b>swpd</b>: The amount of virtual memory used.<br>&nbsp;&nbsp;<b>free</b>: The amount of idle memory.<br>&nbsp;&nbsp;<b>buff</b>: The amount of memory used as buffers.<br>&nbsp;&nbsp;<b>cache</b>: The amount of memory used as cache.<br><i>swap</i>:<br>&nbsp;&nbsp;<b>si</b>: Amount of memory swapped in from disk (/s).<br>&nbsp;&nbsp;<b>so</b>: Amount of memory swapped out to disk (/s).<br><i>io</i>:<br>&nbsp;&nbsp;<b>bi</b>: Blocks received from a block device (blocks/s).<br>&nbsp;&nbsp;<b>bo</b>: Blocks sent to a block device (blocks/s).<br><i>system</i>:<br>&nbsp;&nbsp;<b>in</b>: The number of interrupts per second, including the clock.<br>&nbsp;&nbsp;<b>cs</b>: The number of context switches per second.<br><i>cpu</i>:<br>&nbsp;&nbsp;<b>us</b>: Time spent running non-kernel code (user time).<br>&nbsp;&nbsp;<b>sy</b>: Time spent running kernel code (system time).<br>&nbsp;&nbsp;<b>id</b>: Time spent idle.<br>&nbsp;&nbsp;<b>wa</b>: Time spent waiting for I/O completion.<br>&nbsp;&nbsp;<b>st</b>: Time stolen from a virtual machine by the hypervisor.


title: INTERPRETING OUTPUT FOR BOTTLENECKS
content:
When diagnosing performance issues with <i>vmstat</i>, look for certain patterns:<br><b>High 'r' (runqueue length)</b>: Indicates CPU contention. If 'r' is consistently higher than the number of CPU cores, your system is CPU-bound.<br><b>High 'b' (blocked processes) combined with high 'wa' (I/O wait)</b>: Suggests an I/O bottleneck. Processes are waiting for disk operations to complete.<br><b>High 'si' and 'so' (swap in/out)</b>: Indicates memory pressure. The system is actively swapping pages between RAM and disk, which is slow and impacts performance.<br><b>Low 'free' memory with high 'buff'/'cache'</b>: This is often normal; Linux uses free memory for buffers and cache to improve performance. Only a problem if 'si'/'so' are also high.<br><b>High 'cs' (context switches)</b>: Can indicate a large number of processes frequently switching, potentially leading to CPU overhead.


title: HISTORY
content:
<i>vmstat</i> has been a fundamental utility in Unix-like operating systems for decades, providing insights into system performance. It is part of the <i>procps</i> package (or <i>procps-ng</i> for more modern Linux distributions), which provides a suite of tools for monitoring and managing processes and system resources. Over time, new options and metrics have been added to <i>vmstat</i> to reflect evolving system architectures and provide more granular insights, such as detailed disk statistics, slabinfo, and active/inactive memory reporting, solidifying its role as an indispensable diagnostic tool for system administrators.


title: SEE ALSO
content:
<i>iostat(1)</i>: Reports CPU utilization and I/O statistics for devices and partitions.<br>, <i>mpstat(1)</i>: Reports individual or combined processor activity.<br>, <i>sar(1)</i>: Collects, reports, or saves system activity information, offering historical data.<br>, <i>free(1)</i>: Displays the amount of free, used, and swap memory in the system.<br>, <i>top(1)</i>: Provides a dynamic real-time view of running processes.<br>, <i>htop(1)</i>: An interactive, colorful, and more user-friendly process viewer than <i>top</i>.


title: PARAMETERS
content:
<b>-t, --touch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load file(s) into the page cache. This is the default action if no other action option is specified.<br><br><b>-e, --evict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Evict (remove) file(s) from the page cache, freeing up memory.<br><br><b>-d, --daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run <i>vmtouch</i> as a daemon process, continuously monitoring and keeping the specified files in cache. Less commonly used.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing statistics about cache hits, misses, and overall status.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress all output except for error messages.<br><br><b>-m, --max-threads <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum number of threads <i>vmtouch</i> can use for I/O operations, improving performance on multi-core systems.<br><br><b>-p, --percentage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with -v, reports only the percentage of the file(s) currently in cache, rather than full statistics.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
<i>vmtouch</i> is a command-line utility for interacting with the Linux kernel's file system page cache. Its primary function is to "touch" or load the entire contents of specified files or directories into memory, making subsequent reads from these files significantly faster as they are served directly from RAM rather than requiring slower disk I/O. This is achieved by reading the files efficiently without buffering them in user-space.<br><br>The utility is highly valuable for performance optimization, such as warming up caches for frequently accessed data in database systems, content delivery networks, or virtual machine images. It helps ensure critical data is resident in memory, especially after a system reboot or during periods of high memory pressure that might lead to cache eviction. Beyond loading, <i>vmtouch</i> can also report on the cache status of files (how much is currently cached) or explicitly evict files from the cache, providing administrators granular control over system memory utilization related to file caching. Its straightforward interface makes it a go-to tool for preloading data and improving application responsiveness by minimizing disk access latency.


title: CAVEATS
content:
<b>Root Privileges</b>: <i>vmtouch</i> often requires root privileges (or the <i>CAP_SYS_ADMIN</i> capability) to effectively manipulate the page cache, especially for eviction operations (<code>-e</code>).<br><br><b>Temporary Cache</b>: Loading files into the cache does not guarantee they will remain there indefinitely. The kernel's cache eviction policies will eventually remove less recently used or lower-priority pages if system memory pressure arises.<br><br><b>Memory Consumption</b>: Using <i>vmtouch</i> to load large files or directories can consume significant amounts of RAM, potentially impacting other processes if the system is memory-constrained.


title: CACHING MECHANISM
content:
<i>vmtouch</i> efficiently populates the page cache by internally utilizing system calls such as <i>mincore(2)</i> to check cache status, <i>madvise(2)</i> with flags like <i>MADV_WILLNEED</i> or <i>MADV_DONTNEED</i> for hinting, and reading data using <i>read(2)</i> into a temporary buffer to force it into memory. For eviction, it often leverages <i>posix_fadvise(2)</i> with <i>POSIX_FADV_DONTNEED</i>.


title: DIRECTORY HANDLING
content:
When a directory is specified as an argument, <i>vmtouch</i> recursively processes all files and subdirectories within it. This feature is particularly convenient for warming up entire datasets or application installations with a single command.


title: HISTORY
content:
<i>vmtouch</i> has been a valuable tool in the Linux ecosystem for system administrators and performance engineers since its inception. It was developed to provide a dedicated and efficient way to manage the page cache, distinguishing itself from general-purpose utilities like <i>cat</i> or <i>dd</i> that involve user-space buffering overhead. Its utility for warming up application data and optimizing I/O performance has made it a common inclusion in performance tuning guides and benchmark setups, particularly for database servers and high-throughput file systems.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's help message and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command's version information and exits.<br><br>


title: DESCRIPTION
content:
<i>vmware-checkvm</i> is a command-line utility included as part of the <b>VMware Tools</b> suite, primarily installed on Linux guest operating systems running within a <b>VMware</b> virtualized environment. Its core function is to programmatically determine whether the system on which it is executed is currently operating inside a <b>VMware</b> virtual machine.<br><br>The command typically performs checks by looking for specific virtualization signatures, hardware characteristics, or DMI information that are unique to <b>VMware</b> hypervisors. It is widely used in automated scripts and system configurations that require different behaviors or optimizations based on the execution environment. For instance, a script might install <b>VMware-specific</b> drivers or enable certain features only if the system is detected as a <b>VMware VM</b>. The command's simplicity and directness make it a reliable tool for environment detection within <b>VMware</b> ecosystems. Its primary output mechanism is its exit code: <b>0</b> for a <b>VMware VM</b>, <b>1</b> if not, and higher values for errors.


title: CAVEATS
content:
<ul><li>Requires <i>VMware Tools</i> to be installed and running in the guest OS for the command to be available and function correctly.</li><li>The command specifically detects <i>VMware</i> virtualization; it will return <b>1</b> (not a <i>VMware VM</i>) if run in other virtualization environments (e.g., <i>VirtualBox</i>, <i>KVM</i>, <i>Hyper-V</i>) or on physical hardware.</li><li>It only indicates the presence of a <i>VMware VM</i>, not its specific configuration (e.g., vCPU count, memory, VM name).</li><li>Sophisticated evasion techniques or nested virtualization configurations might sometimes influence its detection accuracy, though this is rare for typical use cases.</li></ul>


title: EXIT CODES
content:
<i>vmware-checkvm</i> communicates its result primarily through its exit code:<br><ul><li><b>0</b>: The command successfully detected that the system is running inside a <i>VMware</i> virtual machine.</li><li><b>1</b>: The command determined that the system is <b>not</b> running inside a <i>VMware</i> virtual machine (e.g., it's a physical machine or another type of hypervisor).</li><li><b>>1</b>: An error occurred during the execution of the command.</li></ul>


title: HISTORY
content:
The <i>vmware-checkvm</i> utility has been a standard component of <i>VMware Tools</i> for Linux guest operating systems for many years, dating back to early versions of <i>VMware Workstation</i> and <i>ESX/ESXi</i>. Its consistent inclusion underscores its utility in scripting and automated deployments within <i>VMware</i> environments. While its core functionality has remained stable, it has evolved alongside <i>VMware Tools</i> to maintain compatibility with newer Linux kernels and <i>VMware</i> hypervisor versions, ensuring reliable detection across various <i>VMware</i> product lines. It is a fundamental part of the guest operating system's ability to recognize its virtualized context.


title: SYNOPSIS
content:
<b>vncserver</b> [<i>:<display#></i>] [<i>options</i>]<br><b>vncserver -kill</b> <i>:<display#></i><br><b>vncserver -list</b>


title: PARAMETERS
content:
<b><b>-geometry</b> <i>WxH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial desktop width and height, e.g., <code>1024x768</code>.<br><br><b><b>-depth</b> <i>D</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color depth for the session, commonly <code>8</code>, <code>16</code>, or <code>24</code> bits.<br><br><b><b>-name</b> <i>"Desktop Name"</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a descriptive name to the VNC desktop window shown in the viewer.<br><br><b><b>-kill</b> <i>:<display#></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Terminates the VNC server session running on the specified display number.<br><br><b><b>-list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all currently running VNC server sessions.<br><br><b><b>-randr</b> <i>WxH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(<i>TigerVNC specific</i>) Changes the resolution of an existing VNC session.<br><br><b><b>-rfbport</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative RFB (Remote FrameBuffer) port to listen on.<br><br><b><b>-clean</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes stale lock files or socket files that might prevent a new session from starting.<br><br><b><b>-localhost</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures the VNC server to only accept connections from the local machine (127.0.0.1). Ideal for SSH tunneling.<br><br><b><b>-noxstartup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the execution of the user's <code>~/.vnc/xstartup</code> script upon session start.<br><br><b><b>-xstartup</b> <i>SCRIPT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative script to execute instead of <code>~/.vnc/xstartup</code>.<br><br><b><b>-fg</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the VNC server in the foreground, useful for debugging or systemd service management.<br><br><b><b>-verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides more detailed output during the command execution.<br><br><b><i>:<display#></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a new VNC session on the specified display number (e.g., <code>:1</code>).<br><br>


title: DESCRIPTION
content:
<b>vncserver</b> is a command-line utility used to start, stop, and manage VNC (Virtual Network Computing) server sessions on a Unix-like system. It creates a virtual X server desktop environment that can be remotely accessed by a VNC client (<b>vncviewer</b>). This allows users to establish graphical sessions on a headless server or access a separate desktop instance from their local machine. Upon its first execution, <b>vncserver</b> prompts the user to set a password for the VNC session. It typically manages display numbers, allocates appropriate TCP ports (usually <code>5900 + display_number</code>), and executes the <code>~/.vnc/xstartup</code> script to initialize the desktop environment (e.g., GNOME, KDE, XFCE). While powerful for remote access, direct VNC connections are unencrypted, necessitating the use of secure tunnels like SSH for production environments.


title: CAVEATS
content:
<b>Security</b>: VNC's RFB protocol itself does not provide encryption. For secure connections, always use an SSH tunnel (e.g., <code>ssh -L 5901:localhost:5901 user@remote-host</code>) when connecting to <b>vncserver</b> over an untrusted network.<br><b>Configuration</b>: The graphical environment and applications launched within a VNC session are largely controlled by the <code>~/.vnc/xstartup</code> script. Users often need to customize this script to launch their preferred desktop environment or window manager.<br><b>Implementation Differences</b>: <b>vncserver</b> implementations vary slightly between different VNC distributions (e.g., TigerVNC, TightVNC, RealVNC), which may lead to minor differences in options or behavior.


title: PASSWORD SETUP
content:
The first time <b>vncserver</b> is run by a user, it will prompt to set a VNC access password. This password is then stored in <code>~/.vnc/passwd</code>. To change or set the password later, use the <b>vncpasswd</b> command.


title: <CODE>XSTARTUP</CODE> SCRIPT
content:
The <code>~/.vnc/xstartup</code> file is a shell script executed by <b>vncserver</b> when a new session starts. It defines what desktop environment or window manager (e.g., GNOME, XFCE, Openbox) will be launched. If this file is missing or incorrectly configured, users might see a blank gray screen upon connecting. It requires execute permissions (<code>chmod +x ~/.vnc/xstartup</code>).


title: STOPPING A SESSION
content:
To terminate a running VNC session, use the <b>vncserver -kill</b> <i>:<display#></i> command, where <i>:<display#></i> is the number displayed when the server was started (e.g., <code>:1</code>).


title: FIREWALL CONFIGURATION
content:
If connecting directly without an SSH tunnel, ensure that the firewall on the server allows incoming connections to the VNC port. VNC servers typically listen on ports <code>5900 + <display_number></code> (e.g., 5901 for display <code>:1</code>, 5902 for <code>:2</code>).


title: HISTORY
content:
VNC (Virtual Network Computing) was originally developed at AT&T Laboratories Cambridge in the late 1990s. <b>vncserver</b> emerged as a fundamental utility within VNC distributions, simplifying the management of remote X server sessions. Its design allowed users to easily spin up virtual desktops accessible over the network, making it a popular choice for remote administration and development environments on Unix-like systems. Over time, various forks and implementations like TightVNC and TigerVNC have continued its development, adapting to modern operating system features like <b>systemd</b> integration.


title: SYNOPSIS
content:
<b>vncviewer</b> [<i>options</i>] [<i>host</i>][:<i>display</i>]<br><b>vncviewer</b> [<i>options</i>] [<i>host</i>][::<i>port</i>]<br><b>vncviewer</b> [<i>options</i>] [<i>vnc://host:port/</i>]


title: PARAMETERS
content:
<b><i>host</i>[:<i>display</i>] or <i>host</i>[::<i>port</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the VNC server to connect to. <i>display</i> is a number (e.g., :1 for port 5901), and <i>port</i> is the direct TCP port (e.g., 5901).<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options.<br><br><b><b>-version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version of the vncviewer application.<br><br><b><b>-config</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration options from the specified file.<br><br><b><b>-via</b> <i>gateway</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the VNC server via an SSH gateway machine, enabling secure, tunneled connections.<br><br><b><b>-passwd</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the VNC password from the specified file, useful for scripting.<br><br><b><b>-fullscreen</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the viewer in full-screen mode, occupying the entire display.<br><br><b><b>-ViewOnly</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects in view-only mode, preventing local keyboard and mouse input from affecting the remote server.<br><br><b><b>-Shared</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows other VNC viewers to connect to the same server display simultaneously.<br><br><b><b>-encodings</b> <i>enc</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the preferred encoding types for screen updates (e.g., <i>tight</i>, <i>hextile</i>, <i>raw</i>) to optimize performance.<br><br><b><b>-compresslevel</b> <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the ZLib compression level (0-9) for compressed encodings.<br><br><b><b>-quality</b> <i>level</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the JPEG quality level (0-9) for lossy encodings like Tight, balancing image quality and bandwidth.<br><br><b><b>-sendclipboard</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables sending the local clipboard content to the VNC server.<br><br><b><b>-acceptclipboard</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables receiving clipboard content from the VNC server to the local machine.<br><br>


title: DESCRIPTION
content:
<b>vncviewer</b> is the client application for the Virtual Network Computing (VNC) system, enabling users to remotely view and control a desktop environment running on a VNC server. It functions by transmitting local keyboard and mouse events to the server and receiving screen updates in return, effectively creating a virtual remote display. It's widely employed for tasks such as remote administration, technical support, and accessing graphical applications on distant machines. The viewer can connect to servers specified by hostname and display number (e.g., <i>host:1</i>) or by IP address and explicit port (e.g., <i>host::5901</i>). It supports various encoding types to optimize performance across different network conditions and offers options for secure connections via SSH tunneling.


title: CAVEATS
content:
VNC itself is inherently unencrypted. For secure communication, it is highly recommended to use <b>vncviewer</b> with SSH tunneling (via the <b>-via</b> option) or a VPN. Firewall configurations on both client and server sides must allow connections on the VNC port (default 5900 + display number). Performance can vary significantly based on network speed and selected encoding methods.


title: KEYBOARD SHORTCUTS
content:
A common shortcut is pressing <b>F8</b> (or <b>Ctrl+Alt+Shift+F8</b>) during a session to bring up a menu with options like full-screen toggle, sending special key combinations (e.g., Ctrl+Alt+Del), or disconnecting.


title: SECURITY BEST PRACTICES
content:
Always prioritize securing your VNC connection. Using <b>vncviewer -via</b> <i>sshuser@sshserver</i> is the most common and recommended method to encrypt VNC traffic and protect your remote sessions from eavesdropping and unauthorized access.


title: HISTORY
content:
VNC (Virtual Network Computing) was originally developed at AT&T Laboratories Cambridge in the late 1990s. <b>vncviewer</b> is the essential client-side component of this system. Following the closure of AT&T Labs Cambridge, the core developers formed RealVNC, continuing to develop and maintain the software. Numerous open-source implementations, such as TightVNC and TurboVNC, have since emerged, each with their own <b>vncviewer</b> variants, all building upon the foundational RFB (Remote FrameBuffer) protocol.


title: SYNOPSIS
content:
<b>vnstat</b> [<i>options</i>]<br><b>vnstat</b> [<i>-h | -d | -m | -w | -t | -s | -l | -u</i>] [<i>-i &lt;interface&gt;</i>]<br><b>vnstat</b> [<i>--json | --xml</i>] [<i>-h | -d | -m | -w | -t | -s | -l</i>] [<i>-i &lt;interface&gt;</i>]<br><b>vnstat</b> [<i>--create | --add | --remove | --enable | --disable</i>] [<i>-i &lt;interface&gt;</i>]<br><b>vnstat</b> [<i>--version | --help</i>]


title: PARAMETERS
content:
<b>-q, --query</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates query mode (default if no other mode option is given).<br><br><b>-h, --hours</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show hourly traffic statistics for the last 24 hours.<br><br><b>-d, --days</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show daily traffic statistics for the last 30 days.<br><br><b>-m, --months</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show monthly traffic statistics for the last 12 months.<br><br><b>-w, --weeks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show weekly traffic statistics. Week number changes on Monday.<br><br><b>-t, --top</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show top 10 traffic days.<br><br><b>-s, --short</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short summary of current traffic stats.<br><br><b>-l, --live</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show real-time traffic statistics. Press Ctrl+C to exit.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the database for the selected interface. Usually handled by <i><b>vnstatd</b></i>.<br><br><b>-i &lt;interface&gt;, --iface &lt;interface&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select the network interface to query or modify (e.g., <i>eth0</i>, <i>wlan0</i>).<br><br><b>--json</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in JSON format for programmatic parsing.<br><br><b>--xml</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output data in XML format for programmatic parsing.<br><br><b>--create</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a new database for the specified interface.<br><br><b>--add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <i>--create</i>, used to add an interface to monitoring.<br><br><b>--remove</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove the database for the specified interface.<br><br><b>--enable &lt;interface&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable data collection for the specified interface.<br><br><b>--disable &lt;interface&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable data collection for the specified interface.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br>


title: DESCRIPTION
content:
<i><b>vnstat</b></i> is a console-based network traffic monitor that keeps a log of network usage for selected interfaces. Unlike real-time tools, <i><b>vnstat</b></i> focuses on collecting and aggregating historical data, making it ideal for tracking long-term bandwidth consumption. It gathers statistics directly from the kernel, meaning it consumes minimal system resources and doesn't sniff packets. The data is stored persistently, ensuring that statistics are preserved across reboots.<br><br><i><b>vnstat</b></i> provides various views, including hourly, daily, monthly, and yearly summaries of traffic transferred, both incoming and outgoing. It's commonly used by users and administrators to monitor bandwidth usage, identify trends, and manage data caps. A background daemon (<i><b>vnstatd</b></i>) is often used to automate data collection, while the <i><b>vnstat</b></i> command line tool is used to query and display the collected statistics. Its simplicity and effectiveness make it a popular choice for light to medium network monitoring needs.


title: CAVEATS
content:
Initial setup, such as creating or enabling databases for interfaces, often requires root privileges. <i><b>vnstat</b></i> is not a real-time packet sniffer; it reads kernel counters, which might have a slight delay or aggregation. For continuous and accurate data collection, it's highly recommended to run the <i><b>vnstatd</b></i> daemon. Data loss can occur if the database file (`/var/lib/vnstat/`) becomes corrupted or is accidentally deleted.


title: DATABASE LOCATION
content:
By default, <i><b>vnstat</b></i> stores its database files in <i>/var/lib/vnstat/</i>. Each monitored network interface typically has its own database file within this directory, named after the interface (e.g., <i>eth0</i>).


title: VNSTATD DAEMON
content:
For continuous and automated data collection, the <i><b>vnstatd</b></i> daemon is typically used. This daemon runs in the background and periodically updates the <i><b>vnstat</b></i> databases. Users generally interact with the <i><b>vnstat</b></i> command-line tool primarily to query and display the statistics collected by <i><b>vnstatd</b></i>.


title: HISTORY
content:
<i><b>vnstat</b></i> was originally written by Teemu Toivola, with the first version released around 2002. It was designed to be a lightweight and persistent alternative to other network monitoring tools, focusing on long-term data collection rather than real-time sniffing. Its development has been continuous, adapting to new Linux kernel features and user demands, while maintaining its core principle of simplicity and efficiency. It has become a staple tool for monitoring bandwidth on servers and personal machines due to its low resource usage and persistent data storage.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--summary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a summary of all network interfaces.<br><br><b><b>-h</b>, <b>--hourly</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows hourly traffic statistics for the current day.<br><br><b><b>-d</b>, <b>--daily</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows daily traffic statistics for the current month.<br><br><b><b>-m</b>, <b>--monthly</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows monthly traffic statistics for the current year.<br><br><b><b>-t</b>, <b>--top10</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the top 10 days with the highest traffic usage.<br><br><b><b>-w</b>, <b>--weekly</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows weekly traffic statistics for the current year.<br><br><b><b>-p</b>, <b>--pages</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates all available statistics (daily, monthly, top, hourly, summary) as individual images.<br><br><b><b>-i</b> <i>&lt;interface&gt;</i>, <b>--iface</b> <i>&lt;interface&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the network interface to query (e.g., <i>eth0</i>).<br><br><b><b>-o</b> <i>&lt;file&gt;</i>, <b>--output</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Saves the generated image to the specified file path. For <b>-p</b>, use <i>%x</i> to auto-name files.<br><br><b><b>-l</b> <i>&lt;level&gt;</i>, <b>--level</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the image color level (0-3), affecting the visual appearance.<br><br><b><b>-nh</b>, <b>--noheaders</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of image headers.<br><br><b><b>-nt</b>, <b>--nototal</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Hides the total traffic row in summary views.<br><br><b><b>-nm</b>, <b>--nocolor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables color output in the generated image.<br><br><b><b>-ne</b>, <b>--noedge</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes the edges from the graph bars in the image.<br><br><b><b>--altdate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an alternative date format (MM/DD instead of DD.MM).<br><br><b><b>--locale</b> <i>&lt;locale&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the locale for date and time formatting within the image.<br><br><b><b>--style</b> <i>&lt;style&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output style for the image (0-2), affecting graph aesthetics.<br><br><b><b>--dbdir</b> <i>&lt;directory&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative directory for the <i>vnstat</i> database files.<br><br><b><b>--footer</b> <i>&lt;text&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds custom text to the footer of the generated image.<br><br><b><b>--label</b> <i>&lt;text&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds custom text above the graph, acting as a label.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>vnstati</i> version information.<br><br><b><b>-?</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a concise help message.<br><br><b><b>--longhelp</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a more detailed help message, including advanced options.<br><br><b><b>--dumpconfig</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the currently used configuration settings for <i>vnstati</i>.<br><br><b><b>--enable-http</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables HTTP header output, primarily for use in CGI environments.<br><br>


title: DESCRIPTION
content:
<i>vnstati</i> is a companion utility to the <i>vnstat</i> network traffic monitor. It creates visually appealing PNG images from the data collected by the <i>vnstat</i> daemon. These images can display various network usage statistics, including daily, weekly, monthly, and hourly traffic, as well as top 10 usage days and a summary of all interfaces. It's widely used in web interfaces, custom dashboards, or scripting environments to provide an at-a-glance overview of network consumption. The command offers extensive options to customize the output, such as selecting specific interfaces, defining output file names, adjusting color schemes, and adding custom text to the images.


title: CAVEATS
content:
<i>vnstati</i> requires the <i>vnstat</i> daemon to be running and collecting data. If the database is empty or corrupted, images may not generate correctly or show no data. Ensure sufficient permissions to write to the specified output directory when using the <i>-o</i> option.


title: OUTPUT FORMATS
content:
<i>vnstati</i> exclusively generates PNG image files. It does not support other image formats or direct text output. The generated image can be saved to a file or piped to standard output.


title: USAGE WITH WEB SERVERS
content:
Often used in conjunction with web servers (like Apache or Nginx) and CGI scripts to dynamically display network statistics on a webpage, by piping the image output directly to the browser. This allows for real-time, graphical network usage monitoring via a web interface.


title: HISTORY
content:
<i>vnstati</i> is part of the <i>vnstat</i> project, which was originally created by Teemu Toivola. It emerged as a solution for visualizing the network traffic data collected by the <i>vnstat</i> daemon, providing a user-friendly graphical representation that could be easily integrated into web pages or monitoring dashboards. Its development has focused on providing flexible output options and maintaining compatibility with various system environments.


title: SYNOPSIS
content:
<b>volatility</b> [<i>GLOBAL_OPTIONS</i>] <b>-f</b> <i><MEMORY_DUMP_FILE></i> [<b>--profile=</b><i><PROFILE_NAME></i>] <i><PLUGIN_NAME></i> [<i>PLUGIN_OPTIONS</i>]


title: PARAMETERS
content:
<b><b>-f</b> <i>FILE</i>, <b>--file</b> <i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the memory dump file to be analyzed.<br><br><b><b>--profile=</b><i>PROFILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Volatility 2)</i> Specifies the KDBG profile that matches the operating system, service pack, and architecture of the memory dump. This is crucial for accurate analysis.<br><br><b><b>--plugins=</b><i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds a directory to the plugin search path, allowing custom or additional plugins to be loaded.<br><br><b><b>--output=</b><i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines the output format of the plugin results (e.g., <i>text</i>, <i>json</i>, <i>csv</i>).<br><br><b><b>--output-file=</b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the plugin output to the specified file instead of standard output.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information during execution.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates debugging mode, useful for troubleshooting issues or understanding internal operations.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the global help message or specific help for a given plugin.<br><br><b><b>--info</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays information about available plugins, profiles, and configurations.<br><br>


title: DESCRIPTION
content:
<b>Volatility</b> is a powerful, open-source memory forensics framework written in Python. It's designed for extracting digital artifacts from volatile memory (RAM) dumps, enabling incident responders and forensic analysts to analyze the runtime state of a system. Unlike disk-based forensics, memory forensics allows for the discovery of volatile data that might not be written to disk or could be easily manipulated. <br><br>It supports a wide range of operating systems including Windows, Linux, and macOS, providing a unified platform for memory analysis across different environments. <b>Volatility</b> can reveal crucial information such as running processes, open network connections, loaded kernel modules, hidden processes, injected code, registry keys, command history, and much more, making it an indispensable tool for identifying malicious activity, understanding attack methodologies, and gathering evidence during a security incident.


title: CAVEATS
content:
<ul><li><b>Installation Required:</b> <b>Volatility</b> is not a standard Linux command and must be installed separately, typically via Python's package manager (pip) or by cloning its GitHub repository.</li><li><b>Memory Dumps Only:</b> <b>Volatility</b> analyzes existing memory dumps; it does not acquire them. Separate tools like LiME (Linux), WinPMEM (Windows), or F-Response are used for memory acquisition.</li><li><b>Profile Dependency (Volatility 2):</b> For <b>Volatility 2</b>, selecting the correct OS profile matching the memory dump is critical. An incorrect profile will lead to erroneous or no results. <b>Volatility 3</b> has improved profile auto-detection.</li><li><b>Steep Learning Curve:</b> Due to its extensive number of plugins and the complex nature of memory forensics, understanding and effectively using <b>Volatility</b> can have a steep learning curve.</li><li><b>Legal & Ethical Considerations:</b> Acquiring and analyzing memory dumps involves sensitive data and raises significant legal and ethical considerations regarding privacy and data handling.</li></ul>


title: PLUGINS SYSTEM
content:
The power of <b>Volatility</b> lies in its modular plugin system. Each plugin is designed to perform a specific forensic task, such as listing processes (<i>pslist</i>), enumerating network connections (<i>netscan</i>), extracting command history (<i>cmdscan</i>), or finding hidden rootkits. Users select a plugin based on the information they wish to extract from the memory dump.


title: VOLATILITY 2 VS. VOLATILITY 3
content:
There are two major versions in active use: <b>Volatility 2</b> and <b>Volatility 3</b>. <b>Volatility 3</b> (often invoked as <i>vol.py</i>) is a complete rewrite, offering a more unified codebase for different operating systems and an improved plugin architecture. While <b>Volatility 2</b> still sees use, particularly for older profiles or specific plugins, <b>Volatility 3</b> is the actively developed and recommended version for new work due to its enhancements and future-proofing.


title: HISTORY
content:
<b>Volatility</b> originated as a research project at BlackHat USA 2007 by Aaron Walters. It quickly evolved into an open-source project, becoming the de-facto standard framework for memory forensics. The Volatility Foundation was established to support its continued development and community. The project saw a major architectural rewrite with the release of <b>Volatility 3 (vol.py)</b>, aiming for improved performance, extensibility, and a unified API across different operating systems, moving away from the need for explicit profiles for every dump. This rewrite addressed many limitations of <b>Volatility 2</b> while maintaining its core functionality.


title: PARAMETERS
content:
<b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Display the current volume label before setting a new one.</i><br><br><b>device</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>The path to the block device (e.g., /dev/sda1) containing the filesystem.</i><br><br><b>new_volume_label</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Optional) The new label to assign to the filesystem. Maximum 16 characters.</i><br><br>


title: DESCRIPTION
content:
<b>volname</b> is a utility designed to interact with the volume labels of <I>ext2</I>, <I>ext3</I>, and <I>ext4</I> filesystems. When invoked with only a <i>device</i> argument, it will display the current volume label associated with that filesystem. If an optional <i>new_volume_label</i> is also provided, <b>volname</b> will then proceed to set the filesystem's volume label to the specified string.<br><br>It's important to note that volume labels are limited to a maximum of 16 characters. Any label exceeding this length will be truncated by the command. The <b>volname</b> utility exists primarily for backward compatibility, specifically with the <I>minix</I> filesystem. For modern <I>ext2/3/4</I> filesystems, the <I>e2label(8)</I> command is the recommended tool for managing volume labels due to its more robust and feature-rich implementation.


title: CAVEATS
content:
The <b>volname</b> command is primarily maintained for backward compatibility with the <I>minix</I> filesystem. For <I>ext2</I>, <I>ext3</I>, and <I>ext4</I> filesystems, it is strongly recommended to use the more modern and robust <I>e2label(8)</I> utility instead. Volume labels are limited to a maximum of 16 characters; longer labels will be truncated without warning.


title: TRUNCATION BEHAVIOR
content:
When a <I>new_volume_label</I> longer than 16 characters is provided, <b>volname</b> will silently truncate it to 16 characters. Users should be aware of this limitation and ensure their labels fit the specified length.


title: HISTORY
content:
The <b>volname</b> command originated for managing volume labels on <I>minix</I> filesystems. With the advent and widespread adoption of <I>ext2</I>, <I>ext3</I>, and <I>ext4</I> filesystems, its functionality was extended to support these, mainly for backward compatibility rather than being the primary tool. Modern <I>e2fsprogs</I> utilities like <I>e2label</I> superseded it for <I>ext</I> family filesystems, offering more comprehensive and safer label management.


title: PARAMETERS
content:
<b><b>-f</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads VPD from the specified <i>file</i> instead of the default kernel interface (<i>/sys/firmware/vpd/</i>).<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the decoded VPD data in a human-readable format. This is often the default behavior.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the raw VPD data in a canonical (byte-per-line) hexadecimal and ASCII format.<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the raw VPD data in a simple hexadecimal dump format.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode. Suppresses output if no VPD is found or decoded, returning only an exit status.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br>


title: DESCRIPTION
content:
<b>vpddecode</b> is a command-line utility used to parse and display Vital Product Data (VPD) stored on IBM and Lenovo systems. VPD is a set of configuration and identification data permanently programmed into a device or system component, often in an EEPROM or Flash memory.<br><br>This data typically includes information like part numbers, serial numbers, FRU (Field Replaceable Unit) numbers, engineering levels, and manufacturing dates. The primary purpose of VPD is for hardware inventory, asset management, and troubleshooting, allowing support personnel to quickly identify specific components without physical inspection. <b>vpddecode</b> reads this data, usually from the <i>/sys/firmware/vpd/</i> directory exposed by the Linux kernel, or directly from a specified file, and presents it in a human-readable format. It's an essential tool for administrators managing a fleet of IBM or Lenovo servers and workstations.


title: CAVEATS
content:
<b>vpddecode</b> is primarily designed for and effective on IBM and Lenovo hardware systems that implement VPD storage. It may not provide meaningful output on systems from other manufacturers.<br><br>The availability of VPD data depends on the system's firmware and kernel support (specifically, the VPD sysfs interface).<br><br>The accuracy and completeness of the displayed information are dependent on the data programmed by the hardware manufacturer.


title: VPD DATA LOCATION
content:
On Linux, Vital Product Data is typically exposed by the kernel through the <i>/sys/firmware/vpd/</i> directory, which <b>vpddecode</b> reads by default. This directory contains files representing different VPD components.


title: PURPOSE OF VPD
content:
VPD serves crucial purposes in hardware management, including asset tracking, inventory management, warranty validation, and facilitating quick identification of Field Replaceable Units (FRUs) during maintenance or troubleshooting.


title: HISTORY
content:
<b>vpddecode</b> emerged as a specialized tool within the Linux ecosystem, particularly relevant to users and administrators of IBM and Lenovo server and workstation hardware. Its development is closely tied to the need for efficient hardware inventory and support on platforms that utilize Vital Product Data for component identification. It is often distributed as part of the <b>dmidecode</b> package, sharing its focus on system firmware and hardware information extraction. Its continuous usage underscores the importance of standardized identification data in enterprise hardware management.


title: SYNOPSIS
content:
<b>vpnc</b> [<i>OPTION</i>...] [<i>CONFIG_FILE</i>]<br><b>vpnc</b> [<i>OPTION</i>...] [<i>KEYWORD VALUE</i>...]


title: PARAMETERS
content:
<b>-c <file>, --config <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use. If omitted, <i>/etc/vpnc/default.conf</i> is used.<br><br><b>--no-detach</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents vpnc from forking into the background. Useful for debugging or running within a script.<br><br><b>--no-route</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents vpnc from adding routes. Useful if you want to manage routing manually.<br><br><b>--script <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an external script to handle network configuration. By default, <i>/etc/vpnc/vpnc-script</i> is used.<br><br><b>--pid-file <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the process ID (PID) of the vpnc daemon to the specified file.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output, showing more details about the connection process.<br><br><b>--non-interact</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents vpnc from interactively asking for passwords. It will only use passwords found in the configuration.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>vpnc</b> command is an open-source VPN client designed to connect to Cisco-compatible VPN Concentrators and other IPSec VPN servers that support IKEv1 with XAuth (Extended Authentication). It provides a secure way to access private networks, commonly used for corporate VPNs. When connected, vpnc establishes a virtual network interface (e.g., <i>tun0</i>) and configures routing to direct traffic through the encrypted tunnel. It supports various authentication methods, including group passwords, Xauth username/password, and certificate-based authentication. Configuration is typically managed through a configuration file (like <i>/etc/vpnc/default.conf</i>) or by passing parameters directly on the command line.


title: CAVEATS
content:
<b>vpnc</b> primarily supports Cisco-compatible IPSec/IKEv1 with XAuth VPNs and does not support newer protocols like IKEv2 or Cisco AnyConnect (SSL VPNs, for which <i>openconnect</i> is the preferred client). It requires root privileges to configure network interfaces and routing. Configuration can sometimes be complex, and conflicts with other network managers might occur. The project's active development might be less frequent compared to more modern VPN solutions.


title: CONFIGURATION PARAMETERS
content:
<b>vpnc</b> can be configured using a dedicated configuration file (e.g., <i>/etc/vpnc/default.conf</i>) or by passing key-value pairs directly on the command line. Common configuration parameters include:<br><b>IPSec ID</b>: The IPSec group name.<br><b>IPSec secret</b>: The shared secret for the IPSec group.<br><b>Xauth username</b>: Your username for Xauth authentication.<br><b>Xauth password</b>: Your password for Xauth authentication.<br><b>Local Port</b>: Specifies the local UDP port to use for IPSec negotiations (default 500 or 4500).<br><b>IKE Authmode</b>: Specifies the IKE authentication mode (e.g., hybrid, psk).<br><b>Enable IP forwarding</b>: Can be set to <i>1</i> to enable IP forwarding on the client.<br>These parameters are often read from the config file but can be overridden by command-line arguments.


