# CommandSection

title: GLOB PATTERNS
content:
<b>stylua</b> supports glob patterns for specifying files and directories to format, as well as for ignoring files. It uses a <i>.gitignore</i>-like syntax for ignore patterns, making it flexible for selective formatting of codebases.


title: HISTORY
content:
<b>stylua</b> was created by Johnny Morgan (JohnnyJayJay) in 2020 as a fast, opinionated code formatter for Lua, inspired by tools like <i>prettier</i> and <i>rustfmt</i>. Its development in Rust aimed to provide high performance and reliability, addressing the lack of a robust, modern, and widely adopted formatter in the Lua ecosystem at the time. It quickly gained traction among Lua developers, especially those using Neovim, due to its speed and ease of integration. The project continues to be actively maintained, with ongoing improvements and new features.


title: SYNOPSIS
content:
<pre><tt>su [<i>options</i>] [-] [<i>user</i> [<i>argument</i>...]]</tt></pre><i>Explanation:</i><br><tt><b>[<i>options</i>]</b></tt>: Various flags to modify <tt>su</tt>'s behavior.<br><tt><b>[-]</b></tt>: A single dash instructs <tt>su</tt> to simulate a full login, including environment setup.<br><tt><b>[<i>user</i>]</b></tt>: The username of the account to switch to. If omitted, defaults to <i>root</i>.<br><tt><b>[<i>argument</i>...]</b></tt>: Arguments passed to the new shell if a command is not specified with <b><tt>-c</tt></b>.


title: PARAMETERS
content:
<b>-c, --command=COMMAND</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a single <i>COMMAND</i> with the substituted user and group IDs, then exits.<br><br><b>-, -l, --login</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates a full login session. This resets environment variables, changes to the target user's home directory, and starts their login shell.<br><br><b>-m, -p, --preserve-environment</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the current environment variables, except for <tt>$HOME</tt>, <tt>$SHELL</tt>, <tt>$USER</tt>, <tt>$LOGNAME</tt>, and <tt>$PATH</tt>, which are still changed to reflect the target user. This option is overridden by <b><tt>--login</tt></b>.<br><br><b>-s, --shell=SHELL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>SHELL</i> to use instead of the default shell of the target user.<br><br><b>-g, --group=GROUP</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the primary <i>GROUP</i> to use instead of the default primary group of the target user.<br><br><b>-G, --supp-group=GROUP</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies supplementary <i>GROUP</i>s to add to the target user's group list. Multiple groups can be specified with a comma-separated list.<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 version information and exits.<br><br>


title: DESCRIPTION
content:
The <b><tt>su</tt></b> (substitute user) command in Linux allows a user to run commands with the privileges of another user account. Most commonly, it is used to gain the privileges of the <i>root</i> user, the system administrator account, to perform privileged tasks. When invoked without a specific target <i>user</i>, <b><tt>su</tt></b> defaults to <i>root</i>. The command prompts for the password of the <i>target user</i> (not the current user's password) before granting access. <br><br>A key distinction in <b><tt>su</tt></b> usage is between <tt>su</tt> and <tt>su -</tt>. When used simply as <tt>su <i>user</i></tt>, it changes the user ID but retains most of the current user's environment variables (like <tt>PATH</tt>). This can sometimes lead to issues if critical system binaries are not in the current user's PATH. In contrast, <tt>su - <i>user</i></tt> (or <tt>su --login <i>user</i></tt>) simulates a full login session for the target user. This means it sets a new environment, including a new <tt>PATH</tt>, <tt>HOME</tt> directory, and prompts for the target user's shell, making it safer for administrative tasks as it ensures the correct environment for the superuser.


title: CAVEATS
content:
<ul><li><b>Security Risk:</b> Granting root access via <b><tt>su</tt></b> requires sharing the root password. This is generally discouraged for multiple administrators as it makes auditing difficult. If the root password is compromised, the entire system is at risk.</li><li><b>Environment Differences:</b> Misunderstanding the difference between <tt>su</tt> and <tt>su -</tt> can lead to unexpected behavior or errors, especially when executing administrative scripts that rely on a specific environment.</li><li><b>PAM Configuration:</b> The behavior and authentication requirements of <b><tt>su</tt></b> are heavily influenced by the Pluggable Authentication Modules (PAM) configuration on the system, typically found in <tt>/etc/pam.d/su</tt>. This can include restrictions on which users are allowed to use <b><tt>su</tt></b> (e.g., via the <tt>wheel</tt> group).</li><li><b>Prefer <tt>sudo</tt>:</b> For most modern Linux distributions and multi-user environments, <b><tt>sudo</tt></b> is often preferred over <b><tt>su</tt></b>. <tt>sudo</tt> allows fine-grained control over which commands specific users can run as root (or another user) without knowing the target user's password, enhancing security and auditability.</li></ul>


title: AUTHENTICATION AND AUTHORIZATION
content:
<b><tt>su</tt></b> relies on the target user's password for authentication. On Linux systems, this process is handled by PAM (Pluggable Authentication Modules). The PAM configuration file for <b><tt>su</tt></b> (usually <tt>/etc/pam.d/su</tt>) dictates specific authentication methods, such as requiring users to be part of a particular group (e.g., <tt>wheel</tt> or <tt>sudo</tt> group on some systems) to use <b><tt>su</tt></b> for root access, or logging attempts.


title: WHEN TO USE <TT>SU -</TT> VS. <TT>SU</TT>
content:
Always prefer <tt>su - <i>user</i></tt> (or <tt>su --login <i>user</i></tt>) when switching to another user, especially <i>root</i>, for administrative tasks. The dash ensures a clean environment, resembling a fresh login, which is crucial for predictable script execution and avoiding conflicts with your original user's environment settings. Using <tt>su <i>user</i></tt> without the dash can lead to issues if the current user's <tt>$PATH</tt> or other environment variables override or hide system binaries or libraries required by the target user.


title: HISTORY
content:
The <b><tt>su</tt></b> command has been a fundamental part of Unix-like operating systems since their early days, providing a straightforward mechanism for privilege escalation. Its primary function was, and largely remains, to allow users to temporarily become the <i>root</i> user to perform system administration tasks. Before the widespread adoption of <tt>sudo</tt>, <b><tt>su</tt></b> was the standard tool for this purpose. Its simplicity in design - prompting for a password and then spawning a new shell or executing a command - has ensured its longevity. While <tt>sudo</tt> has gained popularity for its more granular control and better audit trails, <b><tt>su</tt></b> remains a crucial command, especially in single-user environments or when <tt>sudo</tt> is not configured or available. Modern implementations, like those from <tt>util-linux</tt>, have added more options for environment control and group management, but the core functionality has remained consistent over decades.


title: SYNOPSIS
content:
<I>subfinder</I> [<i>OPTIONS</i>] -d &lt;<i>domain</i>&gt; | -dL &lt;<i>domain_list_file</i>&gt;<br><I>subfinder</I> [<i>OPTIONS</i>] -h


title: PARAMETERS
content:
<b>-d, -domain <I>domain</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Target domain to find subdomains for.<br><br><b>-dL, -list <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of domains to find subdomains for (one per line).<br><br><b>-o, -output <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file to write the discovered subdomains to.<br><br><b>-nW, -no-wildcard</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude wildcard subdomains from the results.<br><br><b>-silent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only display subdomains in the output, suppressing other verbose messages.<br><br><b>-v, -verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show verbose output, including more details about the discovery process.<br><br><b>-r, -resolver <I>ip</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Custom DNS resolver(s) to use (comma-separated IP addresses).<br><br><b>-rL, -resolver-list <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file containing a list of custom DNS resolvers (one per line).<br><br><b>-t, -threads <I>count</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of concurrent goroutines to use for faster enumeration (default 10).<br><br><b>-timeout <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum DNS resolution timeout in seconds (default 30).<br><br><b>-config <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the subfinder configuration file (e.g., to load API keys).<br><br><b>-sources <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of specific sources to use (e.g., certsh,virustotal).<br><br><b>-exclude-sources <I>list</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Comma-separated list of sources to exclude from the enumeration.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current version of subfinder.<br><br><b>-h, -help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the help message and exit.<br><br>


title: DESCRIPTION
content:
<I>subfinder</I> is a powerful and efficient command-line tool designed for passive subdomain enumeration. It rapidly discovers valid subdomains for a given target domain by leveraging various online sources such as Certificate Transparency logs, VirusTotal, Shodan, Censys, and many others, without sending active probes to the target infrastructure.<br><br>This makes it a valuable asset for reconnaissance, bug bounty hunting, and penetration testing, providing a comprehensive list of subdomains that might otherwise be missed. It's built for speed and accuracy, supporting concurrent requests and allowing users to configure custom resolvers and API keys for enhanced performance and results.<br><br>Its strength lies in its ability to gather a vast array of subdomains from publicly available information, minimizing the footprint on the target. Users can specify a single domain or a list of domains, direct output to a file, and filter results based on specific criteria like excluding wildcard domains.


title: CAVEATS
content:
<I>subfinder</I>'s effectiveness relies heavily on the availability and accuracy of external data sources. Some sources require API keys (e.g., VirusTotal, Shodan, Censys) configured in its default or specified `config.yaml` file; without them, certain enumeration capabilities will be limited. Results may contain false positives or incomplete lists due to rate limiting by sources or network issues. As a passive tool, it does not actively probe target DNS servers, which means it might miss newly registered or internal-only subdomains not exposed publicly.


title: API KEY CONFIGURATION
content:
For optimal results and to unlock the full potential of <I>subfinder</I>, users should configure API keys for various third-party services (e.g., VirusTotal, Shodan, Censys) within the <I>subfinder</I> configuration file. This file is typically located at <I>~/.config/subfinder/config.yaml</I> (or specified with the <B>-config</B> flag), allowing <I>subfinder</I> to access more comprehensive datasets.


title: INTEGRATION WITH PROJECTDISCOVERY TOOLS
content:
<I>subfinder</I> is often used in conjunction with other ProjectDiscovery tools as part of a reconnaissance pipeline. For instance, its output can be piped directly into <I>httpx</I> (for quickly probing found subdomains for live HTTP/S servers) and subsequently into <I>nuclei</I> (for automated vulnerability scanning), forming a powerful and efficient workflow for security assessments.


title: HISTORY
content:
<I>subfinder</I> was developed by the ProjectDiscovery team, a prominent group of security researchers and developers known for creating open-source tools for bug bounty hunting and penetration testing. It was designed to be a fast, reliable, and highly configurable subdomain enumeration tool, leveraging a wide array of passive data sources. Since its initial release, it has undergone continuous development, with regular updates incorporating new data sources, performance improvements, and bug fixes, establishing itself as a staple in many reconnaissance workflows.


title: SYNOPSIS
content:
<b><I>subl</I></b> [<b><I>OPTIONS</I></b>] [<b><I>FILE</I></b>|<b><I>FOLDER</I></b>[:<b><I>LINE</I></b>[:<b><I>COLUMN</I></b>]]]...<br><b><I>subl</I></b> <b><I>-d</I></b> <<b><I>FILE1</I></b>> <<b><I>FILE2</I></b>>


title: PARAMETERS
content:
<b><b><I>-n</I></b>, <b><I>--new-window</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens files or folders in a new Sublime Text window, even if an existing window is open.<br><br><b><b><I>-a</I></b>, <b><I>--add</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds folders to the current Sublime Text window. If no window is open, a new one is created and the folders are added to it.<br><br><b><b><I>-w</I></b>, <b><I>--wait</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Waits for the opened files to be closed in Sublime Text before the command returns control to the terminal. Essential for use with Git commit messages or scripting.<br><br><b><b><I>-l</I></b> <<b><I>line</I></b>>, <b><I>--line</I></b> <<b><I>line</I></b>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified file at the given line number. This can also be achieved by using the <b><I>:LINE</I></b> suffix with the file path.<br><br><b><b><I>-c</I></b> <<b><I>column</I></b>>, <b><I>--column</I></b> <<b><I>column</I></b>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the specified file at the given column number. This option requires <b><I>-l</I></b> or the <b><I>:LINE:COLUMN</I></b> syntax to specify a line number first.<br><br><b><b><I>-e</I></b> <<b><I>encoding</I></b>>, <b><I>--encoding</I></b> <<b><I>encoding</I></b>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the character encoding to use when opening the file, e.g., <b><I>utf-8</I></b>, <b><I>latin1</I></b>.<br><br><b><b><I>-p</I></b> <<b><I>project</I></b>>, <b><I>--project</I></b> <<b><I>project</I></b>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the specified Sublime Text project file (typically with a <b><I>.sublime-project</I></b> extension) into a new or existing window.<br><br><b><b><I>-d</I></b>, <b><I>--diff</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares two files side-by-side in a Sublime Text window, highlighting their differences. Requires exactly two file paths as arguments.<br><br><b><b><I>--command</I></b> <<b><I>command</I></b>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specific Sublime Text internal command. This allows for advanced scripting and automation within the editor, e.g., <b><I>--command 'save_all'</I></b> or <b><I>--command 'build'</I></b>.<br><br><b><b><I>-h</I></b>, <b><I>--help</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message outlining all available command-line options and their usage.<br><br><b><b><I>-v</I></b>, <b><I>--version</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the installed Sublime Text version information to the terminal.<br><br>


title: DESCRIPTION
content:
The <b><I>subl</I></b> command provides a powerful command-line interface for the Sublime Text editor. It allows users to seamlessly open files, folders, and projects directly from their terminal, integrating Sublime Text into their command-line workflows. This utility is particularly useful for quickly accessing and editing code, navigating project structures, or performing operations like diffing files without leaving the shell environment. It enables scripting and automation, making it a versatile tool for developers and power users who prefer a hybrid approach of GUI and CLI interactions. The <b><I>subl</I></b> command is typically made available by creating a symbolic link during the Sublime Text installation process, often residing in <b><I>/usr/local/bin</I></b>.


title: CAVEATS
content:
The <b><I>subl</I></b> command relies on a symbolic link being correctly established from a directory in your <b><I>$PATH</I></b> (e.g., <b><I>/usr/local/bin</I></b>) to the Sublime Text executable. If Sublime Text was not installed in a standard way, or if this link was not created (or was removed), the <b><I>subl</I></b> command will not be found by your shell. On macOS, this link is conveniently created via the 'Tools -> Install Command Line Tool' menu option within Sublime Text itself. On Linux, it often requires manual creation or is handled by package managers during installation.


title: SETUP AND CONFIGURATION
content:
To ensure <b><I>subl</I></b> is available in your terminal, a symbolic link must point to your Sublime Text installation. For Linux users, a common setup involves: <b><I>sudo ln -s /opt/sublime_text/sublime_text /usr/local/bin/subl</I></b> (adjust path as necessary). macOS users can simply open Sublime Text, go to the 'Tools' menu, and select 'Install Command Line Tool'. This will set up the symlink automatically.


title: INTEGRATION WITH GIT AND SHELL ENVIRONMENTS
content:
The <b><I>subl</I></b> command is frequently used to set Sublime Text as the default editor for various command-line tools. For Git, you can configure it globally using: <b><I>git config --global core.editor 'subl -w'</I></b>. The <b><I>-w</I></b> (wait) option is crucial here, as it forces Git to pause until you save and close the file in Sublime Text. Users often create shell aliases like <b><I>alias st='subl'</I></b> in their <b><I>.bashrc</I></b> or <b><I>.zshrc</I></b> files for quicker access.


title: HISTORY
content:
Sublime Text first emerged in 2008, quickly gaining popularity for its speed, extensibility, and minimalist interface. From its inception, the command-line tool (<b><I>subl</I></b>) has been an integral part of the editor's offering, reflecting its design philosophy of empowering developers through efficient workflows. While the core functionality of opening files and folders has remained consistent, minor enhancements, such as the <b><I>--diff</I></b> and <b><I>--command</I></b> options, have been introduced in subsequent major versions (Sublime Text 2, 3, and 4) to broaden its utility and deepen its integration with external tools and scripts.


title: SYNOPSIS
content:
<I>subliminal</I> <B>[OPTIONS]</B> <B>FILE</B> <B>[FILE...]</B> <br> <I>subliminal</I> <B>[OPTIONS]</B> <B>--version</B> <br> <I>subliminal</I> <B>[OPTIONS]</B> <B>--help</B>


title: PARAMETERS
content:
<b><B>FILE</B> <B>[FILE...]</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to video files or directories to process. Subliminal will scan these paths for videos.<br><br><b><B>-l</B>, <B>--language</B> <B>LANGUAGE</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the language of the subtitles to download (e.g., 'en' for English, 'fr' for French). Can be specified multiple times for multiple languages.<br><br><b><B>-a</B>, <B>--add-descriptor</B> <B>DESCRIPTOR</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a video descriptor (e.g., 'series=TV Show' or 'season=1' for better matching on some providers). Can be specified multiple times.<br><br><b><B>-p</B>, <B>--add-provider</B> <B>PROVIDER</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable an additional subtitle provider (e.g., 'opensubtitles', 'thesubdb'). Can be specified multiple times.<br><br><b><B>-s</B>, <B>--single</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Download only one subtitle per video (the best match). By default, it downloads all good matches.<br><br><b><B>-m</B>, <B>--multi</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force multi-episode matching for episode files (e.g., when a single file contains multiple episodes).<br><br><b><B>-n</B>, <B>--dry-run</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not download any subtitles; just show what would be downloaded.<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>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show this help message and exit.<br><br><b><B>--no-opensubtitles</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable the OpenSubtitles provider explicitly.<br><br><b><B>--age</B> <B>DAYS</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only download subtitles for videos newer than N days. Use 0 for no age limit.<br><br><b><B>--max-downloads</B> <B>NUMBER</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Maximum number of subtitles to download per video. Defaults to 0 (all good matches).<br><br>


title: DESCRIPTION
content:
<I>subliminal</I> is a powerful and highly extensible Python library and command-line tool designed for finding, downloading, and managing subtitles for video files. It automates the process of fetching subtitles from various online providers like OpenSubtitles, TheSubDB, TVsubtitles.net, and more. Users can specify video files or directories, and <I>subliminal</I> will analyze them to find the best matching subtitles based on criteria like file name, hash, and language. It supports a wide range of video formats and integrates seamlessly into media server setups or personal workflows to ensure your media collection always has the right subtitles.


title: CAVEATS
content:
 <I>subliminal</I> requires Python to be installed on the system, as it is a Python library and application. It's typically installed via `pip`.<br>Subtitle availability and quality depend entirely on the external providers it connects to. Some providers may require registration or API keys.<br>Incorrect video file naming or metadata can lead to poor subtitle matches or no matches at all.<br>Frequent use might lead to rate limiting from some subtitle provider APIs.


title: PROVIDER CONFIGURATION
content:
<I>subliminal</I> allows for advanced configuration of subtitle providers, including setting up credentials for services like OpenSubtitles or others that require login. This can be done via configuration files or environment variables, enhancing the success rate of subtitle searches.


title: LIBRARY INTEGRATION
content:
Beyond its command-line interface, <I>subliminal</I> is fundamentally a Python library. This means it can be directly integrated into other Python applications, such as media servers (e.g., Plex, Jellyfin integration via plugins) or custom scripts, to add automated subtitle downloading capabilities.


title: VIDEO INFORMATION DESCRIPTORS
content:
For better subtitle matching, especially for TV shows or obscure movies, <I>subliminal</I> can utilize 'video descriptors'. These are pieces of information like 'series', 'season', 'episode', or 'year' that help the providers narrow down the search for accurate subtitles.


title: HISTORY
content:
<I>subliminal</I> was created by Antoine Bertin and has been actively developed as an open-source project since around 2012. Its primary goal was to provide a robust and extensible solution for automatic subtitle downloading, addressing the need for media server users and general consumers alike. It gained popularity for its comprehensive provider support and flexible command-line interface, becoming a go-to tool in the Python ecosystem for media management tasks. Development continues with contributions from a community of users and developers.


title: SYNOPSIS
content:
<i>sucrack</i> [<b>-s</b> <i>command</i>] [<b>-u</b> <i>user</i>] [<b>-w</b> <i>wordlist</i>] [<b>-a</b> <i>charset</i>] [<b>-b</b> <i>start</i>] [<b>-p</b> <i>pause</i>] [<b>-r</b>] [<b>-d</b>] [<b>-V</b>] [<b>-h</b>]


title: PARAMETERS
content:
<b><b>-s</b> <i>command</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the command to crack. Must be either <i>su</i> or <i>sudo</i>. Defaults to <i>su</i>.<br><br><b><b>-u</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target user whose password is to be cracked. Defaults to <i>root</i>.<br><br><b><b>-w</b> <i>wordlist</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to a wordlist file containing passwords to try. One password per line.<br><br><b><b>-a</b> <i>charset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies additional characters to use in brute-force mode. For example, <i>-a aA1!</i> will use lowercase, uppercase, numbers, and exclamation mark. This is used when brute-forcing or if the wordlist fails.<br><br><b><b>-b</b> <i>start_chars</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the starting characters for the brute-force attack. Useful for resuming or targeting specific password patterns.<br><br><b><b>-p</b> <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a pause duration (in seconds) between each password attempt. This can help avoid triggering account lockouts or reduce system load.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Resume cracking from the last saved state. This requires a previous interrupted session.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug mode, providing more verbose output for troubleshooting.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <i>sucrack</i>.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message and exits.<br><br>


title: DESCRIPTION
content:
<i>sucrack</i> is a command-line utility designed to perform brute-force or dictionary attacks against user passwords for the <i>su</i> and <i>sudo</i> commands on a Linux or Unix-like system. It works by repeatedly invoking either <i>su</i> or <i>sudo</i> as a specified user, attempting different passwords from a provided wordlist or by generating passwords in a brute-force manner. The tool then analyzes the output or return status of these commands to determine if a password attempt was successful or failed. It is primarily used by penetration testers and security professionals to audit the strength of passwords on systems where local access is available, helping to identify weak credentials that could be exploited. Due to its nature, <i>sucrack</i> is a resource-intensive tool and can generate numerous authentication failures, which may trigger account lockout policies or be logged by system monitoring tools.


title: CAVEATS
content:
<i>sucrack</i> requires local access to the system. It can be very slow due to the overhead of repeatedly spawning <i>su</i> or <i>sudo</i> processes. Excessive failed attempts may trigger security mechanisms like PAM's <i>faillock</i> or <i>pam_tally2</i>, leading to account lockouts or significant delays. Its use without explicit authorization on a system is illegal and unethical. All attempts will typically be logged in system authentication logs (e.g., <i>/var/log/auth.log</i> or <i>/var/log/secure</i>), making its activity easily detectable.


title: HISTORY
content:
<i>sucrack</i> is a relatively older but persistent tool in the arsenal of penetration testing utilities for local privilege escalation. Its development focuses on a direct approach to password cracking for the <i>su</i> and <i>sudo</i> commands, making it distinct from offline hash crackers. While not as actively developed as some other cracking tools, its simplicity and directness in targeting specific commands have kept it relevant for specific audit scenarios.


title: SYNOPSIS
content:
<b>sudo</b> [<i>-bEHklPSsV</i>] [<i>-p prompt</i>] [<i>-u user</i>] [<i>command ...</i>]<br><b>sudo</b> [<i>-i</i>] [<i>-u user</i>] [<i>command ...</i>]<br><b>sudo</b> [<i>-Kk</i>]


title: PARAMETERS
content:
<b><b>-u</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command as the specified <i>user</i> (default is root).<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the target user's password database entry as a login shell, setting appropriate environment variables and sourcing login shell resource files.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the SHELL environment variable or the invoking user's password database entry. No environment variables are changed, and resource files are not sourced.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the commands the user is allowed to run on the current host.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the version information or update the user's timestamp file, prolonging the effective password timeout.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invalidate the user's cached password timestamp, forcing re-authentication the next time <b>sudo</b> is used.<br><br><b><b>-K</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Like <b>-k</b>, but also removes any cached credentials entirely.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in the background. Standard input, output, and error streams are redirected to <i>/dev/null</i>.<br><br><b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve the user's environment variables when running the command. By default, <b>sudo</b> resets the environment to a safe minimal set.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the HOME environment variable to the home directory of the target user (root by default).<br><br><b><b>-p</b> <i>prompt</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a custom password <i>prompt</i> instead of the default.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read the password from standard input instead of the terminal.<br><br>


title: DESCRIPTION
content:
The <b>sudo</b> (<i>superuser do</i>) command allows a permitted user to execute a command as another user, typically the superuser (root). It provides a secure way to grant specific users administrative privileges without sharing the root password. When a user invokes <b>sudo</b>, they are prompted for <i>their own password</i>, not the root password. This authentication, combined with the configuration in the <i>/etc/sudoers</i> file, determines if the user is authorized to run the specified command with elevated privileges. <b>sudo</b> logs all successful and failed attempts, enhancing system accountability. It is a cornerstone of Unix-like system security and administration, enabling fine-grained control over who can perform privileged operations and which operations they can perform.<br><br>The primary benefit of <b>sudo</b> over directly using the root account is the principle of least privilege: users only gain elevated privileges for the specific tasks they need to perform, reducing the attack surface. It also allows administrators to delegate specific tasks to non-root users, improving workflow and maintainability.


title: CAVEATS
content:
<ul><li><b>Sudoers File Integrity</b>: Any syntax errors in the <i>/etc/sudoers</i> file can prevent anyone from using <b>sudo</b>, effectively locking out administrative access. Always use <b>visudo</b> to edit this file, as it performs syntax checking.</li><li><b>Environment Variables</b>: <b>sudo</b>, by default, cleans the environment to prevent malicious manipulation through environment variables (e.g., PATH, LD_PRELOAD). Using the <b>-E</b> option can reintroduce security risks if not carefully managed.</li><li><b>Password Caching</b>: For convenience, <b>sudo</b> caches authentication for a period (typically 5 minutes), meaning subsequent <b>sudo</b> commands within that timeframe may not require a password. This can be a security concern if a user leaves their session unattended. Use <b>sudo -k</b> or <b>sudo -K</b> to invalidate the cache.</li><li><b>Wildcard Use</b>: Overly broad rules in <i>/etc/sudoers</i> (e.g., allowing all commands or commands with wildcards) can inadvertently grant more privileges than intended.</li></ul>


title: THE <I>SUDOERS</I> FILE
content:
The behavior of <b>sudo</b> is entirely controlled by the <i>/etc/sudoers</i> file. This file specifies which users or groups can execute which commands, on which hosts, and as which target users. It supports aliases for users, hosts, commands, and runas users, providing highly flexible and granular control. It is critical to edit this file using the <b>visudo</b> command, which locks the file, checks for syntax errors before saving, and prevents accidental misconfigurations that could compromise system access.


title: AUTHENTICATION AND TIMESTAMPS
content:
When a user runs <b>sudo</b> for the first time, they are prompted for their own password. Upon successful authentication, a timestamp file is created or updated for that user in <i>/var/run/sudo</i> (or similar location). For a configurable period (defaulting to 5 minutes), the user can execute subsequent <b>sudo</b> commands without re-entering their password. This timestamp can be manually invalidated with <b>sudo -k</b> or <b>sudo -K</b>.


title: LOGGING
content:
<b>sudo</b> logs all successful and failed attempts to execute commands. These logs are typically sent to the system's logging daemon (e.g., syslog, rsyslog) and can be found in files like <i>/var/log/auth.log</i> or <i>/var/log/secure</i>, depending on the system configuration. This logging is crucial for auditing and security monitoring.


title: HISTORY
content:
The <b>sudo</b> command originated in the 1980s at the State University of New York at Buffalo. Its initial versions were developed by Bob Coggeshall and Cliff Spencer. It was designed to address the need for a mechanism to allow specific users to execute commands as root without giving them the root password directly. The current widely used version of <b>sudo</b> is primarily maintained and developed by Todd C. Miller, who took over the project in the mid-1990s. Over the decades, <b>sudo</b> has evolved significantly, adding features like logging, flexible configuration via the <i>sudoers</i> file, and robust security practices. It has become a standard utility in virtually all Unix-like operating systems, from Linux distributions to macOS, due to its effectiveness in managing privileged access and enhancing system security and accountability.


title: SYNOPSIS
content:
<b>sudo</b> [<i>options</i>] <i>command</i><br><b>sudo</b> [<i>options</i>] <b>-i</b><br><b>sudo</b> [<i>options</i>] <b>-s</b>


title: PARAMETERS
content:
<b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an askpass helper for password prompting.<br><br><b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command in the background.<br><br><b><b>-E</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserve the user's environment when running the command.<br><br><b><b>-H</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the HOME environment variable to the target user's home directory.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the target user's password file entry as a login shell. This implies <b>-H</b>, <b>-P</b>, <b>-S</b> and <b>-u</b>.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Invalidate the user's cached credentials. This forces a password prompt on the next <i>sudo</i> command.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the commands the user is allowed to run on the current host.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Non-interactive mode; no password prompt will be given.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the shell specified by the SHELL environment variable if it is set or the shell specified by the target user's password file entry.<br><br><b><b>-u</b> <i>user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run the command as the specified <i>user</i> instead of the default (root).<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the user's cached credentials, extending the grace period for another few minutes.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <i>sudo</i> version and exit.<br><br>


title: DESCRIPTION
content:
<i>sudo</i> (superuser do) allows a permitted user to execute a command as the superuser or another user, as specified by the security policy. It provides a secure and auditable way to delegate administrative privileges without sharing the root password directly. When invoked, <i>sudo</i> typically prompts for the user's own password, not the target user's, and caches these credentials for a short period to avoid repeated authentication. The behavior of <i>sudo</i> is meticulously controlled by the <i>/etc/sudoers</i> file, which defines who can run what commands, on which hosts, and as which users. It logs commands and arguments, making it easier to audit system activity, thereby enhancing system security and accountability.


title: CAVEATS
content:
Misconfiguration of the <i>/etc/sudoers</i> file can lead to serious security vulnerabilities, including granting unintended privileges or locking out administrative access. Always use <b>visudo</b> to edit the <i>sudoers</i> file to prevent syntax errors. Using options like <b>-E</b> to preserve the environment should be done cautiously, as it can potentially expose the target user to malicious environment variables.


title: THE <I>SUDOERS</I> FILE
content:
The behavior and permissions of <i>sudo</i> are controlled by the <i>/etc/sudoers</i> file. This file specifies which users or groups can execute which commands, as which users, on which hosts, and whether a password is required. It is critically important to edit this file only with the <b>visudo</b> command, which performs syntax checking to prevent errors that could render <i>sudo</i> unusable.


title: PASSWORD AUTHENTICATION
content:
Unlike <i>su</i>, which typically requires the target user's password (e.g., root's password), <i>sudo</i> by default prompts for the invoking user's own password. This enhances security as users do not need to know the root password. Once authenticated, <i>sudo</i> caches the credentials for a default period (usually 5 minutes), allowing subsequent <i>sudo</i> commands to be run without re-entering the password.


title: HISTORY
content:
<i>sudo</i> was originally written by Robert Coggeshall and Cliff Spencer in 1980 at the State University of New York at Buffalo. It was designed to allow users to execute commands with root privileges without directly sharing the root password. Over the decades, it has undergone multiple rewrites and significant feature additions, evolving into a fundamental and widely adopted utility across Unix-like operating systems for secure privilege management.


title: PARAMETERS
content:
<b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode. Do not print instructions at startup.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verbose mode. Show current time and number of moves.<br><br>


title: DESCRIPTION
content:
<i>sudoku</i> is a command-line utility that allows users to play the popular logic-based number placement puzzle, Sudoku. The game presents an 81-cell grid, partially filled with digits from 1 to 9. The objective is to fill the remaining cells such that every row, every column, and each of the nine 3x3 subgrids contains all digits from 1 to 9 exactly once.<br><br>The game supports interactive input where users can specify a cell by its row and column and provide a digit to fill it. It also offers commands to clear cells, show possible locations for a digit, start a new game, quit, and even solve the current puzzle. It provides a simple yet engaging text-based interface for Sudoku enthusiasts.


title: CAVEATS
content:
The game is text-based and relies on standard terminal input/output. It does not support graphical interfaces. The puzzle generation might not always produce the most challenging puzzles, and it only generates standard 9x9 Sudoku grids.


title: INTERACTIVE COMMANDS
content:
The game is played by entering commands at the prompt:<br><i>&lt;row&gt;&lt;column&gt;&lt;digit&gt;</i>: Fill in the cell at <i>row</i>,<i>column</i> with <i>digit</i> (e.g., '123' fills cell (1,2) with 3).<br><i>&lt;row&gt;&lt;column&gt;</i>: Clear the cell at <i>row</i>,<i>column</i> (e.g., '12' clears cell (1,2)).<br><i>&lt;digit&gt;</i>: Show only cells that could contain <i>digit</i>. This helps in finding single possible locations.<br><b>c</b>: Clear the current cell.<br><b>q</b>: Quit the game.<br><b>s</b>: Solve the puzzle and show the solution. This will end the current game.<br><b>?</b>: Display help.<br><b>n</b>: Start a new game (abandon current).


title: BUGS
content:
Bugs should typically be reported to the upstream maintainers, often via the email address <i>simon@tatham.org</i> as specified in the man page.


title: HISTORY
content:
The <i>sudoku</i> command is typically part of the <i>bsdgames</i> package, a collection of traditional Unix games. It was written by Simon Tatham, known for his work on PuTTY and other open-source projects. Its inclusion in <i>bsdgames</i> means it's widely available on Unix-like operating systems, contributing to the rich history of terminal-based entertainment utilities that have been a part of these systems for decades.


title: SYNOPSIS
content:
<b>sudoreplay</b> [-d directory] [-f format] [-i ID] [-F] [-l] [-L] [-P] [-s seconds] [-T seconds] [-z] [ID]


title: PARAMETERS
content:
<b>-d <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify an alternate base directory for session recordings. Defaults to <code>/var/log/sudo-io</code>.<br><br><b>-f <i>format</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format for listings. Typically 'log' for traditional format or 'json' for JSON output.<br><br><b>-i <i>ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Replay the session specified by its unique <i>ID</i>. The <i>ID</i> is a hexadecimal string (e.g., '012345ABCD').<br><br><b>-F</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fast-forward mode. Skip delays between commands and output, playing the session as quickly as possible.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available session IDs recorded in the specified directory. This is useful for identifying sessions to replay.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List available sessions with more verbose details, including user, host, command, and start time.<br><br><b>-P</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a progress indicator while playing back a session, showing the current time offset.<br><br><b>-s <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start playing the session at the specified time offset in seconds from the beginning.<br><br><b>-T <i>seconds</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stop playing the session at the specified time offset in seconds from the beginning.<br><br><b>-z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decompress recording files if they are stored in a compressed format (e.g., gzip).<br><br><b><i>ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique session ID to replay. This can be provided as a positional argument if <code>-i</code> is not used.<br><br>


title: DESCRIPTION
content:
<i>sudoreplay</i> is a command-line utility used to replay command sessions recorded by <i>sudo</i>. When <i>sudo</i> is configured to log all user input and output, <i>sudoreplay</i> can be used to reconstruct the exact terminal session, including keystrokes, screen output, and timings. This feature is invaluable for security auditing, incident response, training, and troubleshooting. It helps administrators understand what commands were executed, the context in which they were run, and the precise sequence of events during a privileged session. <i>sudoreplay</i> can play back sessions at normal speed, fast-forward, or even start/stop at specific time offsets within the recording.


title: CAVEATS
content:
For <i>sudoreplay</i> to function, <i>sudo</i> must be configured to log session I/O in the <code>/etc/sudoers</code> file (e.g., using the <code>log_output</code> and <code>log_input</code> options).<br><br>The user running <i>sudoreplay</i> must have appropriate read permissions to the session recording files and directories, which are typically restricted for security reasons.<br><br>Replaying very large or long sessions can consume significant system resources and time.


title: SESSION IDS
content:
Each recorded session is assigned a unique, timestamp-based hexadecimal ID (e.g., '20231027153012ABCD'). These IDs are crucial for specifying which session to replay.


title: RECORDING FORMAT
content:
Session recordings are stored as a series of files (e.g., <code>log</code>, <code>stdin</code>, <code>stdout</code>, <code>stderr</code>, <code>ttyin</code>, <code>timing</code>) within a directory structure, organized by the session ID. The <code>timing</code> file is especially important as it contains the precise delays between events, allowing for accurate replay.


title: HISTORY
content:
<i>sudoreplay</i> is an integral part of the <i>sudo</i> project, developed to enhance the auditing capabilities of privileged command execution. Its introduction provided a powerful mechanism for accountability and forensic analysis, moving beyond simple command logging to full session reconstruction. This feature became increasingly important for compliance with security standards and for detailed incident investigations, making its debut with <i>sudo</i> versions that supported I/O logging.


title: PARAMETERS
content:
<b><b>--address</b> <i>&lt;ADDRESS&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the recipient <i>Sui address</i> for the faucet tokens. If omitted, tokens are sent to the currently active address in the client configuration.<br><br><b><b>--amount</b> <i>&lt;AMOUNT&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired <i>amount</i> of SUI tokens to request from the faucet. Note that faucets typically have a maximum limit per request.<br><br><b><b>--url</b> <i>&lt;URL&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the <i>URL</i> of the faucet service to use. This is often pre-configured for standard networks like devnet or testnet.<br><br>


title: DESCRIPTION
content:
The <b>sui-client faucet</b> command is a crucial utility for developers and users interacting with Sui blockchain testnets or devnets. Its primary function is to request free test SUI tokens from a designated faucet service. In blockchain development, test tokens are essential for experimenting with smart contracts, deploying applications, and testing transaction flows without incurring real financial costs or using valuable mainnet assets.<br><br>This command simplifies the process of acquiring these test tokens, enabling rapid prototyping and debugging. Users typically specify the recipient address, and the faucet service then sends a predefined amount of SUI to that address. It is important to note that these tokens have <i>no real-world monetary value</i> and are solely for development and testing purposes on non-mainnet environments. The <b>sui-client</b> interacts with the configured network (e.g., <i>devnet</i>, <i>testnet</i>) to access its respective faucet.


title: CAVEATS
content:
The tokens received from the Sui faucet are solely for use on <b>testnet</b> or <b>devnet</b> environments and hold <i>no real-world monetary value</i>. Faucet services typically enforce <b>rate limits</b> and <b>maximum request amounts</b> to ensure fair distribution and prevent abuse. Users should be aware that the availability and functionality of the faucet depend on the network's status and the faucet service's operational health.


title: NETWORK CONFIGURATION
content:
The <b>sui-client</b> relies on its active network configuration (e.g., <i>devnet</i>, <i>testnet</i>) to determine which faucet service to connect to. Users can switch networks using other <b>sui-client</b> commands (e.g., <b>sui client switch --env</b> <i>&lt;ENVIRONMENT&gt;</i>), which in turn directs the <b>faucet</b> command to the correct endpoint.


title: PRIMARY USE CASES
content:
The <b>faucet</b> command is predominantly used by developers for: <br><i>deploying and testing smart contracts</i>, which require gas fees and initial funds; <br><i>testing dApp functionalities</i>, simulating real user interactions involving token transfers; and <br><i>experimenting with new Sui features</i> without risking real assets.


title: HISTORY
content:
The <b>sui-client faucet</b> command emerged as an essential component of the Sui blockchain's development toolkit during its early <i>devnet</i> and <i>testnet</i> phases. Introduced to empower developers and users with easy access to test SUI tokens, it played a critical role in fostering rapid application development, testing, and ecosystem growth before the Sui <i>mainnet</i> launch. Its integration ensured that developers could freely experiment with smart contracts and transactions without financial barriers, accelerating the iteration cycles and robust testing necessary for a new blockchain platform.


title: SYNOPSIS
content:
<b>"sui-move"</b> is not a direct command. It refers to subcommands under <code>sui client move</code>.<br><br><b>General Usage:</b><br><code>sui client move &lt;subcommand&gt; [options] [arguments]</code><br><br><b>Examples:</b><br><code>sui client move publish [options] &lt;path-to-package&gt;</code><br><i>(Publishes a Move package)</i><br><br><code>sui client move call [options] --package &lt;package-id&gt; --module &lt;module-name&gt; --function &lt;function-name&gt; --args &lt;arg1&gt; [&lt;arg2&gt; ...]</code><br><i>(Calls a function on a deployed Move module)</i>


title: PARAMETERS
content:
<b><b>--gas-budget</b> <i>[AMOUNT]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum gas amount (in Sui MIST) to be used for the transaction. This is a crucial parameter to prevent excessive transaction fees.<br><br><b><b>--sender</b> <i>[ADDRESS]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the sender's Sui address for the transaction. This address must be managed by the current client profile.<br><br><b><b>--gas-object</b> <i>[OBJECT_ID]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the ID of a specific gas object to be used for transaction fees. If not specified, the client will attempt to find a suitable gas object automatically.<br><br><b><b>--package</b> <i>[PACKAGE_ID]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'call' subcommand)</i> The object ID of the deployed Move package containing the target module and function.<br><br><b><b>--module</b> <i>[MODULE_NAME]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'call' subcommand)</i> The name of the Move module within the specified package.<br><br><b><b>--function</b> <i>[FUNCTION_NAME]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'call' subcommand)</i> The name of the function to be invoked within the specified module.<br><br><b><b>--args</b> <i>[ARG1 ARG2 ...]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(For 'call' subcommand)</i> A list of arguments to pass to the Move function. Arguments must be formatted according to Move's type system (e.g., '10u64', '0x...::module::Type', 'true').<br><br><b><b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the transaction response or command result in JSON format, useful for scripting and programmatic interactions.<br><br><b><b>-y</b>, <b>--yes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Bypasses all interactive confirmation prompts, automatically assuming 'yes' to proceed with the operation. Use with caution.<br><br>


title: DESCRIPTION
content:
The term <b>"sui-move"</b> does not refer to a standalone Linux command in the traditional sense. Instead, it conceptualizes a group of commands within the <i>Sui blockchain client</i> (<code>sui client</code>) that interact with <i>Move smart contracts</i>. The <i>Move language</i> is a secure and robust programming language designed for writing smart contracts on blockchain platforms like Sui.<br><br>These <code>sui client move</code> subcommands allow users and developers to perform essential operations such as publishing new Move packages (smart contracts) to the Sui network, calling specific functions within deployed Move modules, disassembling Move bytecode for inspection, and more. It's a core component for developing and managing decentralized applications (dApps) on the Sui blockchain.


title: CAVEATS
content:
It is critical to understand that <b>"sui-move"</b> is not a standalone executable or a universal Linux command. Its functionality is exclusively tied to the <i>Sui blockchain ecosystem</i> and requires the <i>Sui client CLI</i> to be installed and configured. Users looking for general file movement should use the standard Linux <code>mv</code> command.


title: OFFICIAL SUI DOCUMENTATION
content:
For comprehensive and up-to-date information on the Sui blockchain, the Sui client CLI, and Move development, refer to the official Sui documentation portal, which provides detailed guides, API references, and tutorials.


title: HISTORY
content:
The <i>Move programming language</i> was originally developed by Meta (formerly Facebook) for its Diem (Libra) blockchain project. After Diem was discontinued, Move found new life in independent blockchain projects, including <i>Sui</i>, developed by <i>Mysten Labs</i>. The `sui client move` commands are integral to Sui's design, enabling direct interaction with its smart contract layer, leveraging Move's security and expressiveness for asset management and decentralized applications.


title: SEE ALSO
content:
sui client CLI (The official command-line interface for the Sui blockchain), Move programming language (The smart contract language used on Sui), mv(1) (The standard Linux command for moving or renaming files and directories, distinct from 'sui-move')


title: PARAMETERS
content:
<b>-p, --putenv <i>NAME=VALUE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows adding or overriding environment variables in the form <i>NAME=VALUE</i>. Can be specified multiple times. These variables will be set in the shell spawned by <i>sulogin</i>.<br><br><b>-e, --force-exit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>sulogin</i> to exit on end-of-file (EOF) from standard input, even if the password prompt was not shown. This can be useful for automated scripts where immediate exit on input termination is desired.<br><br><b>-t, --timeout <i>SECONDS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a timeout in seconds. If no input is received within this time after the password prompt is displayed, <i>sulogin</i> will exit. A value of 0 means no timeout.<br><br><b>-r, --force-root</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>sulogin</i> to provide a root shell, even if it is not invoked with root privileges. This option is typically used in specific embedded systems or highly controlled recovery scenarios where <i>sulogin</i> might be started by a non-root process but still needs to grant root access for system repair.<br><br><b><i>TTY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the terminal device to open for input and output. For example, <i>/dev/tty1</i>. If not specified, <i>sulogin</i> uses the current controlling terminal.<br><br>


title: DESCRIPTION
content:
<i>sulogin</i> provides a single-user shell, typically the <b>root</b> shell, during system boot failures. It is commonly invoked by <i>init</i> or <i>systemd</i> when critical boot processes like filesystem checks (<i>fsck</i>) fail, or when the system enters an emergency or rescue mode. Its primary purpose is to allow system administrators to diagnose and repair issues that prevent the system from booting into multi-user mode.<br><br>It operates in a minimalistic environment, often before many services or filesystems are fully mounted. <i>sulogin</i> prompts for the root password, if one is configured, before granting access. If the root password is empty, access is usually granted immediately, making it a crucial tool for recovery operations even in severely damaged systems.


title: CAVEATS
content:
<i>sulogin</i> is typically invoked automatically by <i>init</i> or <i>systemd</i> during boot issues, rather than being manually run by users. <br><br>As it provides direct <b>root</b> access, often in a recovery context, it requires careful security considerations. If the <b>root</b> password is not set, <i>sulogin</i> might grant immediate root access, which is a security risk if the console is not physically secured. <br><br>The shell provided is usually a minimal environment, and not all system utilities or paths may be immediately available or fully functional until more filesystems are mounted or services started.


title: ENVIRONMENT VARIABLES
content:
<i>sulogin</i> can be influenced by the following environment variables:<br><b>SULOGIN_PROMPT</b>: If set, this variable overrides the default password prompt string displayed by <i>sulogin</i>.<br><b>SULOGIN_PASSWORD</b>: If set, this variable can be used to provide the <b>root</b> password directly. <b>Note</b>: This is generally insecure and should only be used in highly controlled, automated, and typically offline recovery scripts where direct user interaction is not possible and security risks are mitigated by other means.


title: EXIT STATUS
content:
<i>sulogin</i> returns the following exit status codes:<br><b>0</b>: success<br><b>1</b>: operation not permitted (e.g., failed authentication)<br><b>2</b>: usage error<br><b>3</b>: I/O error<br><b>4</b>: unable to open TTY<br><b>5</b>: timeout<br><b>6</b>: internal error


title: HISTORY
content:
<i>sulogin</i> is a long-standing utility, part of the <b>util-linux</b> project, which provides a collection of essential Linux system utilities. Its fundamental role as a system recovery mechanism has remained consistent throughout the evolution of Linux, adapting to work with different <i>init</i> systems like SysVinit and <i>systemd</i>. It continues to be a critical component for diagnosing and repairing boot-time issues.


title: PARAMETERS
content:
<b>-r, --sysv</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the System V algorithm for calculating the checksum. This algorithm may produce a different checksum than the default (BSD) algorithm for the same file.<br><br><b>-s, --bsd</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the BSD algorithm for calculating the checksum. This is often the default algorithm if not specified and is generally the older, simpler 16-bit sum.<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;Output version information and exit.<br><br><b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the file(s) for which to calculate the checksum and block count. If no <i>FILE</i> is specified, <b>sum</b> reads from standard input.<br><br>


title: DESCRIPTION
content:
The <b>sum</b> command is a traditional Unix utility designed to compute a 16-bit checksum for files and report the number of 1KB blocks they occupy. It reads each specified <i>FILE</i> (or standard input if no file is given) and outputs the checksum, the block count, and the filename. While historically useful for simple integrity checks and quick comparisons, its 16-bit checksum is very weak and easily susceptible to collisions, meaning different files can produce the same checksum.<br><br>For more robust and secure integrity verification, modern alternatives like <b>cksum</b> (which uses a 32-bit CRC checksum) or cryptographic hash functions like MD5 (<b>md5sum</b>) and SHA (<b>sha256sum</b>) are highly recommended. The <b>sum</b> command remains primarily for backward compatibility and specific legacy system interactions. It supports two main algorithms: the default BSD algorithm and the System V algorithm, which can be selected via options.


title: CAVEATS
content:
<i>Weak Checksum:</i> The 16-bit checksum provided by <b>sum</b> is not cryptographically secure and is prone to collisions. It should not be used for verifying file integrity where security or strong data assurance is required.<br><i>Block Size Inconsistency:</i> The block count reported is typically in 1KB blocks, but interpretation of "block" can vary across systems or utilities, leading to potential confusion.<br><i>Algorithm Dependence:</i> The checksum result depends on the specific algorithm used (BSD vs. System V), so comparing checksums requires knowing which algorithm was applied.


title: OUTPUT FORMAT
content:
The output of the <b>sum</b> command typically consists of three fields separated by spaces: the calculated 16-bit checksum, the number of 1KB blocks in the file, and the filename. For example, "<i>23456 123 filename.txt</i>". If reading from standard input, the filename field is omitted.


title: HISTORY
content:
The <b>sum</b> command is one of the oldest utilities in the Unix ecosystem, dating back to early versions of Unix. Its original purpose was to provide a quick way to verify that a file had not been accidentally corrupted during transfer or storage. As computing evolved and the need for more robust and secure integrity checks arose, its limitations (primarily the 16-bit checksum's susceptibility to collisions) became apparent.<br><br>This led to the development of commands like <b>cksum</b> (which uses a 32-bit CRC) and later, cryptographic hash functions (MD5, SHA). Despite its age and superseded functionality for modern use cases, <b>sum</b> has been retained in POSIX and various Linux distributions primarily for backward compatibility with older scripts and systems that might still rely on its specific output format and checksum algorithm.


title: PARAMETERS
content:
<b><i>iconfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the Sun icon file to convert. If this argument is omitted, <i>sunicontopnm</i> reads the Sun icon data from standard input.<br><br><b><b>-headerdump</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This is a common Netpbm option. When specified, <i>sunicontopnm</i> prints information about the header of the input file to standard error and then exits, without performing the actual image conversion. Useful for debugging or inspecting file metadata.<br><br><b><b>-help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;This is a common Netpbm option. Displays a concise help message detailing the command's usage and available options to standard output, then exits.<br><br>


title: DESCRIPTION
content:
<i>sunicontopnm</i> is a utility from the Netpbm package designed to convert Sun icon files into the portable anymap (PNM) image format. Sun icon files are a specific image format, typically found on SunOS/Solaris systems, used for small graphical elements such as desktop icons. <br><br>The PNM format is a family of simple, raw image formats (PBM for black & white, PGM for grayscale, and PPM for color) that serve as a common intermediary format within the Netpbm suite. <i>sunicontopnm</i> reads the input Sun icon data, either from a specified file or from standard input, and outputs the corresponding PNM image to standard output. This makes it particularly useful in shell pipelines, allowing users to convert legacy Sun icon files into a format that can then be processed further by other Netpbm tools or converted to more widely used modern image formats like PNG or JPEG.


title: CAVEATS
content:
<i>sunicontopnm</i> is specifically designed for Sun icon files; it will not correctly process other image formats. Malformed or corrupted Sun icon input may lead to errors or unpredictable output. The output is always written to standard output, necessitating redirection (e.g., <i>> output.pnm</i>) or piping to another command (e.g., <i>| pnmtopng</i>) for practical use.


title: TYPICAL USAGE
content:
As with many Netpbm tools, <i>sunicontopnm</i> is frequently used in a pipeline to convert and further process image data. <br><br><b>Example 1: Converting a Sun icon file to a PNM file.</b><br><i>sunicontopnm myicon.ic > myimage.pnm</i><br><br><b>Example 2: Converting a Sun icon file directly to a PNG image using a pipe.</b><br><i>sunicontopnm myicon.ic | pnmtopng > myimage.png</i><br><br><b>Example 3: Reading from standard input and converting to a GIF.</b><br><i>cat myicon.ic | sunicontopnm | pnmtopng | pngtogif > myimage.gif</i>


title: HISTORY
content:
<i>sunicontopnm</i> is an integral part of the Netpbm package, a powerful and venerable suite of graphics utilities. Netpbm originated from the Pbmplus package, developed by Jef Poskanzer in the late 1980s. Its evolution into Netpbm, led by Bryan Henderson, broadened its scope to include converters for a vast array of image formats, both common and obscure. The inclusion of <i>sunicontopnm</i> highlights Netpbm's commitment to interoperability and preserving the ability to work with legacy data formats, such as the Sun icon format prevalent on older SunOS and Solaris systems.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits, detailing available options.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed <i>sup</i> version and exits.<br><br><b>-c, --config <FILE></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to use instead of the default.<br><br><b>-u, --update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches new mail from configured sources and updates the local index, then exits.<br><br><b>-S, --sync</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes all mail folders (fetch new, mark read/delete) and updates the index, then exits.<br><br><b>-N, --no-index</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>sup</i> without building or updating the index for new messages. This can speed up startup but may miss recent mail.<br><br><b>-f, --fast</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens <i>sup</i> quickly by skipping initial indexing and loading, but may not show the absolute latest mail or fully updated views.<br><br><b>search_term</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately performs a search for the specified term upon starting <i>sup</i>, opening the search results view.<br><br>


title: DESCRIPTION
content:
The <i>sup</i> command refers to a fast, console-based Mail User Agent (MUA) designed for efficient email management directly from your terminal. It distinguishes itself by indexing all your email, allowing for lightning-fast full-text searches, flexible tagging, and robust threading capabilities across large mail archives. <i>sup</i> supports various mail storage formats including IMAP, Maildir, and mbox. Written in Ruby, it provides a modern, keyboard-driven interface optimized for users who prefer working in a command-line environment and need powerful tools for organizing and navigating extensive email collections. Its primary goal is to provide a responsive and powerful email experience without leaving the console.


title: CAVEATS
content:
<i>sup</i> requires the Ruby programming language and specific RubyGems to function, which must be installed separately. Its configuration is managed through a Ruby file, <i>~/.sup/config.rb</i>, which can be less intuitive for users unfamiliar with Ruby syntax. It is not pre-installed on most Linux distributions and usually requires manual installation.


title: CONFIGURATION
content:
<i>sup</i>'s behavior is highly customizable through its configuration file, typically located at <i>~/.sup/config.rb</i>. This file, written in Ruby, allows users to define mail accounts, configure keybindings, customize display options, set up indexing rules, and integrate with external commands for advanced mail processing.


title: HISTORY
content:
The <i>sup</i> mail client emerged as a modern alternative for console-based email management, developed with a strong focus on speed and efficient handling of large email archives. Written in Ruby, it was designed to provide advanced features like comprehensive indexing and robust searching capabilities. Its development aimed to fill a niche for users seeking a powerful, keyboard-driven MUA beyond traditional console clients like Mutt, reflecting a trend towards more dynamic and scriptable command-line tools in the Linux ecosystem.


title: SYNOPSIS
content:
<b>supervisorctl</b> [<i>options</i>] &lt;<i>action</i>&gt; [<i>action_arguments</i>]<br><i>Common Actions:</i><br><b>status</b> [<i>program_name</i>]<br><b>start</b> &lt;<i>program_name</i>&gt;|&lt;<i>group_name</i>&gt;:*|all<br><b>stop</b> &lt;<i>program_name</i>&gt;|&lt;<i>group_name</i>&gt;:*|all<br><b>restart</b> &lt;<i>program_name</i>&gt;|&lt;<i>group_name</i>&gt;:*|all<br><b>tail</b> &lt;<i>program_name</i>&gt; [<i>stdout</i>|<i>stderr</i>] [<i>bytes</i>]<br><b>reload</b><br><b>update</b><br><b>shutdown</b>


title: PARAMETERS
content:
<b><b>status</b> [<i>program_name</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the status of all managed processes, or a specific process if <i>program_name</i> is provided.<br><br><b><b>start</b> &lt;<i>name</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts a process or group of processes. <i>&lt;name&gt;</i> can be a program name, <i>group_name:*</i>, or the keyword <i>all</i>.<br><br><b><b>stop</b> &lt;<i>name</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops a process or group of processes.<br><br><b><b>restart</b> &lt;<i>name</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts a process or group of processes. This is equivalent to issuing a <i>stop</i> followed by a <i>start</i>.<br><br><b><b>tail</b> &lt;<i>name</i>&gt; [<i>stdout</i>|<i>stderr</i>] [<i>bytes</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the last part of a process's log output. Defaults to <i>stdout</i>. Optionally specify <i>stderr</i> or a number of <i>bytes</i>.<br><br><b><b>reload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads <i>supervisord</i> configuration without restarting the daemon. This makes changes effective for new programs.<br><br><b><b>update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads <i>supervisord</i> configuration and applies changes, starting or stopping processes as required to match the new configuration.<br><br><b><b>shutdown</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gracefully shuts down the <i>supervisord</i> daemon and all its managed processes.<br><br><b><b>-c</b> &lt;<i>config_file</i>&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternate configuration file for <i>supervisord</i> to connect to.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br>


title: DESCRIPTION
content:
<i>supervisorctl</i> is a command-line client for the <i>Supervisor</i> process control system. It allows users to interact with the <i>supervisord</i> daemon, which manages a group of processes. With <i>supervisorctl</i>, you can effectively monitor the status of running programs, start or stop individual processes or groups of processes, restart them, and view their log output. It provides a convenient interface to manage the lifecycle of applications, ensuring they run continuously and are automatically restarted if they crash. It connects to the <i>supervisord</i> server, typically via a Unix domain socket or a TCP port, to issue commands and retrieve information. This tool is essential for managing persistent services and applications, especially in server environments where reliable process uptime is critical.


title: CAVEATS
content:
<i>supervisorctl</i> requires the <i>supervisord</i> daemon to be running for it to function. Users must have appropriate permissions to connect to the <i>supervisord</i> socket or TCP port. Configuration changes made to <i>supervisord.conf</i> typically require a <i>reload</i> or <i>update</i> command for them to take effect on managed processes.


title: INTERACTIVE MODE
content:
When invoked without any arguments, <i>supervisorctl</i> enters an interactive shell. This allows users to issue multiple commands consecutively without retyping <i>supervisorctl</i> each time, facilitating efficient management of processes.


title: CONFIGURATION
content:
<i>supervisorctl</i> communicates with <i>supervisord</i> based on the configuration defined in <i>supervisord.conf</i> (or an alternative file specified with <i>-c</i>). This file dictates the processes to be managed, their restart policies, log locations, and more.


title: HISTORY
content:
<i>Supervisor</i>, including the <i>supervisorctl</i> client, was created by Chris McDonough and has been actively developed since the early 2000s. It was designed to provide a lightweight and robust process control system, particularly gaining popularity for managing long-running services and applications in environments where full-fledged init systems like <i>systemd</i> might be considered too heavy or are not available.


title: SYNOPSIS
content:
<I>surge</I> [<B>options</B>] [<B>project_directory</B>] [<B>custom_domain</B>]<br><br>Common usage examples:<br>  <I>surge</I><br>  <I>surge</I> <I>./my-awesome-site</I><br>  <I>surge</I> <I>--domain example.com</I><br>  <I>surge</I> <I>./dist example.com</I>


title: PARAMETERS
content:
<b><B>--project</B> &lt;path&gt;, <B>-p</B> &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the local directory containing the static files to be published. Defaults to the current working directory if not specified.<br><br><b><B>--domain</B> &lt;domain&gt;, <B>-d</B> &lt;domain&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a custom domain for the published project. If omitted, Surge provides a unique auto-generated URL.<br><br><b><B>--add</B> &lt;alias&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an alias (another custom domain) to an existing project.<br><br><b><B>--list</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a list of all projects deployed by the currently logged-in user account.<br><br><b><B>--whoami</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the email address of the currently logged-in Surge user.<br><br><b><B>--login</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prompts for email and password to log into your Surge account or create a new one.<br><br><b><B>--logout</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs out the current user from the Surge CLI.<br><br><b><B>--create</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the process to create a new Surge user account.<br><br><b><B>--force</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces a redeployment, overwriting existing files even if they appear unchanged.<br><br><b><B>--silent</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most of the CLI output during the deployment process.<br><br><b><B>--config</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Allows configuration of Surge CLI settings, such as default project path or domain.<br><br><b><B>--help</B>, <B>-h</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with available commands and options.<br><br><b><B>--version</B>, <B>-v</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the current version of the Surge CLI tool.<br><br>


title: DESCRIPTION
content:
The <b>surge</b> command, provided by the <I>surge.sh</I> Node.js CLI tool, is a popular utility for deploying static websites and front-end projects to a global Content Delivery Network (CDN) with minimal effort. It simplifies the process of publishing HTML, CSS, JavaScript, and image assets directly from your terminal. Users can deploy projects in seconds, automatically assign a unique Surge URL, and optionally configure custom domains and SSL certificates. Surge is particularly favored by front-end developers, designers, and educators for its simplicity and speed in showcasing web projects and single-page applications without requiring complex server setup. It abstracts away server configuration, making it accessible for quick prototyping and sharing.


title: CAVEATS
content:
The <I>surge</I> command is not a built-in Linux utility. It requires <I>Node.js</I> and <I>npm</I> (Node Package Manager) to be installed on your system first, as it is distributed as an <I>npm</I> package. It is designed exclusively for publishing static web content; it cannot host server-side applications or databases. While Surge offers a free tier, certain advanced features like custom SSL for some domains or increased bandwidth may require paid plans.


title: INSTALLATION INSTRUCTIONS
content:
To use the <I>surge</I> command, you first need to install <I>Node.js</I> and its package manager <I>npm</I> (Node Package Manager). Once <I>npm</I> is set up, you can install the Surge CLI globally using the following command in your terminal:<br><br><I>npm install -g surge</I>


title: TYPICAL WORKFLOW
content:
A common workflow for deploying a static site with Surge involves:<br>1. Navigating to your project directory in the terminal: <I>cd my-static-project</I><br>2. Running the <I>surge</I> command: <I>surge</I><br>3. If it's your first time, you'll be prompted to log in or create an account.<br>4. Surge will then suggest a project path (usually current directory) and a default domain. You can accept these or provide your own.<br>5. Once confirmed, Surge uploads your files and provides the live URL to your deployed site.


title: HISTORY
content:
The <I>surge.sh</I> service and its corresponding CLI tool were launched in 2014 by Surge, Inc. It quickly gained popularity for its straightforward approach to static site deployment, providing a much-needed simple solution for front-end developers. Its ease of use and 'just deploy' philosophy made it a go-to tool for prototyping and sharing web projects. In 2021, Surge was acquired by Netlify, a leading platform for modern web development, which continued to maintain and support the Surge service.


title: PARAMETERS
content:
<b>No direct parameters for 'suspend' action.</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The <code>suspend</code> action itself, when invoked via <code>systemctl</code>, does not typically accept direct parameters. However, the <code>systemctl</code> command, which is used to trigger suspend, supports various global options:<br><b><code>--force</code></b>: Force the action, even if it's considered unsafe or normally prevented. Use with caution.<br><b><code>--no-block</code></b>: Do not wait for the operation to finish. The command will return immediately.<br><b><code>--no-wall</code></b>: Do not send wall message before halting/rebooting/powering off.<br><br><br>


title: DESCRIPTION
content:
The <b>suspend</b> functionality in Linux refers to putting the system into a low-power state, typically Suspend-to-RAM (STR), also known as Sleep or Standby. In this state, the system powers down most components except RAM, where the current system state is preserved. This allows for a very quick resume (usually within seconds) back to the exact point where the system was suspended, consuming significantly less power than when running, but more than when hibernated or powered off.<br><br>While there isn't a single universal standalone <code>suspend</code> binary command for system-wide suspension across all Linux distributions (like <code>ls</code> or <code>grep</code>), the most common and recommended method in modern Linux systems utilizing <i>systemd</i> is to use the <code>systemctl</code> utility. Specifically, the command <code>systemctl suspend</code> triggers this power-saving mode. Older systems or those not using <i>systemd</i> might use tools like <code>pm-suspend</code> (part of <i>pm-utils</i>) or direct kernel interfaces.<br><br>The primary benefits of suspending are rapid startup and reduced power consumption, making it ideal for short breaks or closing a laptop lid. It's crucial to note that the system state is held in volatile RAM, so a complete power loss (e.g., battery depletion on a laptop) will result in loss of unsaved work.


title: CAVEATS
content:
<b>Requires Privileges</b>: Initiating a system suspend typically requires root privileges (e.g., using <code>sudo systemctl suspend</code>).<br><b>Volatile State</b>: The system state is stored in RAM. If power is lost (e.g., battery runs out), all unsaved work will be lost. This is a key difference from hibernation.<br><b>Potential for Failure</b>: Certain processes, open network connections, or mounted filesystems (especially NFS or CIFS) might prevent a clean suspend. Services can also block suspend via inhibitions.<br><b>Hardware/Driver Issues</b>: Suspend and resume functionality heavily relies on proper hardware and driver support. Issues with graphics drivers, USB devices, or other peripherals can sometimes prevent successful suspend or cause instability upon resume.<br><b>Shell Built-in vs. System Suspend</b>: Be aware that some shells (like <i>bash</i> or <i>zsh</i>) have a built-in <code>suspend</code> command, which, when executed directly, suspends the current shell or foreground job, not the entire system. This is invoked by Ctrl+Z and managed by <code>fg</code>/<code>bg</code>.<br>


title: THE <CODE>SUSPEND</CODE> SHELL BUILT-IN
content:
<b>The <code>suspend</code> Shell Built-in</b><br>It is important to distinguish the system-wide suspend functionality from the <code>suspend</code> command that is a built-in feature of many interactive shells, such as <i>bash</i> or <i>zsh</i>. When you type <code>suspend</code> in a shell, it attempts to suspend the current shell instance or the foreground job. This is equivalent to pressing <code>Ctrl+Z</code>. This action puts the shell or job into a stopped state, allowing you to use job control commands like <code>fg</code> (foreground) or <code>bg</code> (background) to resume or continue its execution. This built-in command does not affect the overall system's power state.


title: HISTORY
content:
The ability to suspend a Linux system has evolved significantly over time. Initially, direct interaction with ACPI (Advanced Configuration and Power Interface) interfaces or legacy tools like <code>apm</code> (Advanced Power Management) were used. With the advent of more sophisticated power management, utilities like <i>pm-utils</i>, which included the <code>pm-suspend</code> command, became standard for handling suspend and hibernate functionality across various hardware configurations.<br><br>With the widespread adoption of <i>systemd</i> as the init system for most major Linux distributions, power management was integrated into <i>systemd</i>'s functionalities. The <code>systemd-suspend.service</code> unit, triggered by the <code>systemctl suspend</code> command, became the modern and recommended way to manage system suspend. This integration provides a more robust and unified approach to power management, allowing services to react to suspend events and ensure a cleaner system state before entering the low-power mode.


title: PARAMETERS
content:
<b>up</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the service and ensures it stays running.<br><br><b>down</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the service and ensures it stays down.<br><br><b>once</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the service if it's down. It will not be restarted if it exits.<br><br><b>pause</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGSTOP signal to the service, pausing it.<br><br><b>cont</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGCONT signal to the service, resuming it.<br><br><b>hup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGHUP signal to the service.<br><br><b>alrm</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGALRM signal to the service.<br><br><b>int</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGINT signal to the service.<br><br><b>term</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGTERM signal to the service.<br><br><b>quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGQUIT signal to the service.<br><br><b>usr1</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGUSR1 signal to the service.<br><br><b>usr2</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGUSR2 signal to the service.<br><br><b>exit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tells the <i>runsv(8)</i> supervisor to exit for the service. Use with caution.<br><br><b>kill</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends a SIGKILL signal to the service, forcing termination.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reports the current status (up/down, PID, uptime) of the service.<br><br><b>check</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the service is running and correctly supervised.<br><br><b>start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for 'up'. Starts the service.<br><br><b>stop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for 'down'. Stops the service.<br><br><b>restart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends SIGTERM, waits, then restarts the service ('term' then 'up').<br><br><b>force-reload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for 'restart'. Re-reads service configuration and restarts.<br><br><b>force-restart</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends SIGKILL, waits, then restarts the service ('kill' then 'up').<br><br><b>force-stop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends SIGKILL to immediately stop the service.<br><br><b>reload</b><br>&nbsp;&nbsp;&nbsp;&nbsp;If a 'reload' script exists in the service directory, executes it. Otherwise, sends SIGHUP.<br><br><b>shutdown</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends SIGTERM to all supervised services, then SIGKILL after a delay. Used for system shutdown.<br><br>


title: DESCRIPTION
content:
<i>sv</i> is the service management command for the <i>runit</i> init scheme. It is used to control and query the status of services supervised by <i>runit</i>. Unlike traditional init systems, <i>runit</i> emphasizes simplicity, robustness, and speed, and <i>sv</i> embodies these principles by providing a straightforward interface to interact with supervised processes. <br> <br> <i>sv</i> can start, stop, restart, and check the status of services, as well as send various signals to them. It operates on service directories, typically located in <i>/etc/service</i> or <i>/service</i>, where each directory represents a supervised service and contains a 'run' script that <i>runit</i> executes. <i>sv</i> communicates with the <i>runsv(8)</i> supervisor process, which monitors the 'run' script and its associated log processes. <br> <br> Its design makes it particularly suitable for environments where minimal overhead and high reliability are paramount, such as embedded systems or servers where resource efficiency is critical.


title: CAVEATS
content:
<i>sv</i> is part of the <i>runit</i> init system, which is less common than <i>systemd</i> or <i>SysVinit</i> on mainstream Linux distributions. <br> It relies on a specific service directory structure (e.g., <i>/etc/service</i> or <i>/service</i>). <br> Its design is minimalist; it doesn't offer complex unit file configurations or dependency management like <i>systemd</i>. <br> All service control commands are synchronous; <i>sv</i> will wait for the service state change to occur or timeout.


title: SERVICE DIRECTORY STRUCTURE
content:
<i>runit</i> services are defined by directories, typically located in <i>/etc/service</i> or <i>/service</i>. Each service directory must contain an executable <i>run</i> script, which is executed by <i>runsv(8)</i> to start the service. Optionally, it can contain a <i>log/run</i> script for logging, and a <i>control/</i> directory for more advanced control scripts (e.g., <i>control/reload</i>, <i>control/down</i>).


title: HISTORY
content:
<i>sv</i> is an integral part of the <i>runit</i> init scheme, a cross-platform Unix init and service supervision suite. <i>runit</i> was originally developed by Daniel J. Bernstein (djb) and refined by Laurent Bercot and others. Its design prioritizes simplicity, small size, and robustness, making it an alternative to more complex init systems like <i>SysVinit</i> and later <i>systemd</i>. <i>runit</i>'s philosophy focuses on simple, independent services managed by <i>runsv</i> processes, with <i>sv</i> acting as the primary user interface to interact with these supervisors. It gained popularity in environments valuing reliability and minimal resource consumption, such as embedded systems or certain server deployments, often found in smaller or specialized Linux distributions.


title: SYNOPSIS
content:
<b>svgcleaner</b> [<i>OPTIONS</i>] <i><INPUT_FILE> <OUTPUT_FILE></i><br><b>svgcleaner</b> [<b>-c</b> <i>config_file</i>] [<b>-p</b> <i>precision</i>] [<b>-s</b> <i>style_level</i>] [<i>...more_options...</i>] <i>input_file</i> <i>output_file</i>


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br><b><b>--input</b> <i><file></i>, <b>-i</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input SVG file. Can also be provided as the first positional argument.<br><br><b><b>--output</b> <i><file></i>, <b>-o</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output SVG file. Can also be provided as the second positional argument.<br><br><b><b>--config</b> <i><file></i>, <b>-c</b> <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a JSON configuration file for detailed optimization settings, overriding command-line flags.<br><br><b><b>--force</b>, <b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites the output file if it already exists without prompting.<br><br><b><b>--pretty-print</b>, <b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the output SVG with indentation for readability, rather than minifying it.<br><br><b><b>--precision</b> <i><num></i>, <b>-p</b> <i><num></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of decimal places for numeric values (e.g., coordinates, dimensions) in the output.<br><br><b><b>--style-level</b> <i><level></i>, <b>-s</b> <i><level></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls how CSS styles are processed. Common levels include <i>none</i>, <i>stylesheet</i> (internal CSS), and <i>inline</i> (style attributes).<br><br><b><b>--apply-transforms</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies transformations (e.g., translations, rotations) directly to shape coordinates instead of keeping them as <i>transform</i> attributes.<br><br><b><b>--strip-comments</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes all XML comments from the SVG output.<br><br><b><b>--strip-metadata</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes metadata tags like <i><metadata></i> from the SVG document.<br><br><b><b>--remove-unreferenced-ids</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes IDs that are defined but not referenced elsewhere in the document (e.g., in <i><defs></i>).<br><br><b><b>--remove-empty-containers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes empty container elements like <i><g></i> or <i><defs></i> that have no content.<br><br><b><b>--group-elements</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to group elements into <i><g></i> tags where possible, which can sometimes aid in better compression or organization.<br><br><b><b>--ungroup-elements</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to ungroup elements from <i><g></i> tags, potentially simplifying the DOM structure.<br><br>


title: DESCRIPTION
content:
<i>svgcleaner</i> is a powerful command-line tool designed to optimize Scalable Vector Graphics (SVG) files. Its primary purpose is to reduce the file size of SVG images by removing unnecessary data and applying various optimizations without compromising visual quality. This includes stripping out unused definitions, comments, metadata, and redundant attributes. It can also simplify paths, merge groups, optimize transforms, and remove default or empty elements.<br><br>By making SVG files more compact, <i>svgcleaner</i> helps improve website loading times and overall performance, making it an essential tool for web developers and designers working with vector graphics. It supports various levels of cleaning and can be configured via JSON files for fine-grained control over the optimization process.


title: CAVEATS
content:
While <i>svgcleaner</i> is highly effective, users should always verify the output SVG, especially for complex or highly specific designs, to ensure no unintended visual changes occur. Extensive customization often requires understanding of its JSON configuration schema.


title: CONFIGURATION FILES
content:
<i>svgcleaner</i> offers extensive customization through JSON configuration files. These files allow users to specify exactly which optimization passes to apply, set numerical precision for coordinates, control style processing, and fine-tune many other aspects of the cleaning process, providing granular control beyond command-line flags.


title: PERFORMANCE AND IMPLEMENTATION
content:
Being written in Rust, <i>svgcleaner</i> is lauded for its speed and memory efficiency, making it well-suited for processing large batches of SVG files or integrating into automated build pipelines where performance is critical.


title: HISTORY
content:
<i>svgcleaner</i> is an open-source project primarily written in Rust, a language known for its performance and safety. It was developed to provide a fast, efficient, and robust command-line solution for optimizing SVG files, catering to the growing need for optimized web assets and streamlined build processes. Its development aligns with the broader trend of static asset optimization in web development workflows.


title: SYNOPSIS
content:
<b>svgo</b> [<i>options</i>] [<i>&lt;input_path&gt;</i>] [<i>&lt;output_path&gt;</i>]<br><b>svgo</b> <i>--input</i> <i>&lt;file&gt;</i> <i>--output</i> <i>&lt;file&gt;</i><br><b>svgo</b> <i>--folder</i> <i>&lt;folder&gt;</i> <i>--output</i> <i>&lt;folder&gt;</i><br><b>svgo</b> <i>--config</i> <i>&lt;path_to_config_file&gt;</i>


title: PARAMETERS
content:
<b><b>-i</b>, <b>--input</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input SVG file or folder for optimization. Use '<b>-</b>' for standard input.<br><br><b><b>-o</b>, <b>--output</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output path for the optimized SVG file or folder. Use '<b>-</b>' for standard output.<br><br><b><b>-f</b>, <b>--folder</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Processes all SVG files within the specified input folder, outputting to the corresponding folder.<br><br><b><b>-p</b>, <b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats the output SVG with human-readable indentation, making it easier to read.<br><br><b><b>-t</b>, <b>--multipass</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the optimization process multiple times until the SVG no longer changes, potentially achieving better compression.<br><br><b><b>-c</b>, <b>--config</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom configuration file (e.g., <i>svgo.config.js</i>) to control plugins and optimization settings.<br><br><b><b>--dataurl</b> <i>&lt;encoding&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the optimized SVG as a data URL, with optional encoding like '<i>base64</i>' or '<i>utf8</i>'.<br><br><b><b>--enable-plugin</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a specific optimization plugin by its name. Can be used multiple times to enable several plugins.<br><br><b><b>--disable-plugin</b> <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables a specific optimization plugin by its name. Can be used multiple times to disable several plugins.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most informational output, showing only critical errors.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the installed <b>svgo</b> version number.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the command-line help message with available options and usage examples.<br><br>


title: DESCRIPTION
content:
SVGO (SVG Optimizer) is a powerful, Node.js-based tool designed to significantly reduce the file size of SVG (Scalable Vector Graphics) images. It achieves this by intelligently identifying and removing various types of redundant and useless information embedded within SVG files. This includes eliminating editor metadata, comments, hidden elements, default values for attributes, empty groups, and unreferenced IDs. The optimization process results in smaller SVG files, which translates to faster loading times on websites, improved rendering performance in applications, and more efficient storage. SVGO is highly configurable, offering a robust plugin-based architecture that allows users to precisely control which optimizations are applied, making it adaptable for a wide range of use cases, from web development and icon processing to graphic design workflows.


title: CAVEATS
content:
<b>svgo</b> requires <i>Node.js</i> to be installed on the system to run. While highly effective, aggressive optimization settings or issues in the original SVG markup can, in rare cases, lead to minor rendering inconsistencies. Users should test optimized SVGs in their target environments.


title: CONFIGURATION FILES
content:
<b>svgo</b>'s behavior is extensively customizable through configuration files, typically named <i>svgo.config.js</i>. These files allow users to define which built-in plugins are active, configure their specific parameters, and even register custom plugins. This provides fine-grained control over the optimization process, tailoring it to specific project requirements.


title: PLUGIN SYSTEM
content:
The core of <b>svgo</b>'s functionality lies in its modular plugin system. Each plugin is responsible for a distinct optimization task, such as removing comments, converting shapes to paths, or collapsing redundant groups. This modularity ensures that users can selectively apply or disable optimizations, ensuring compatibility and desired output quality without sacrificing performance.


title: HISTORY
content:
<b>svgo</b> was initially developed by Kirill K. and first released around 2013, quickly gaining traction as a vital tool for web optimization. It transitioned to a community-maintained project under the <b>svg/svgo</b> organization. A significant update, <i>v2.0.0</i>, introduced a new plugin API and a shift from YAML to JavaScript-based configuration files, enhancing its flexibility and extensibility.


title: SYNOPSIS
content:
npx @svgr/cli [options] <i>&lt;input-path&gt;</i><br>svgr [options] <i>&lt;input-path&gt;</i> (if installed globally)<br><br><i>input-path</i> can be a file, directory, or glob pattern.


title: PARAMETERS
content:
<b>--help, -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays usage information and exits.</i><br><br><b>--version, -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs the current svgr package version.</i><br><br><b>--out-dir <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the output directory for generated components.</i><br><br><b>--filename <i>&lt;name&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets a specific output filename when processing a single input.</i><br><br><b>--ext <i>&lt;ext&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines the file extension for generated component files (e.g., .jsx, .tsx).</i><br><br><b>--icon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Treats the SVG as an icon, setting default width/height to '1em'.</i><br><br><b>--native</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates a React Native compatible component.</i><br><br><b>--typescript</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Outputs a TypeScript (.tsx) component.</i><br><br><b>--dimensions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Keeps width and height attributes in the SVG.</i><br><br><b>--no-dimensions</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Removes width and height attributes from the SVG.</i><br><br><b>--ref</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Wraps the component with React.forwardRef.</i><br><br><b>--memo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Wraps the component with React.memo.</i><br><br><b>--title-prop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds a 'title' prop to the SVG element.</i><br><br><b>--desc-prop</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Adds a 'desc' prop to the SVG element.</i><br><br><b>--expand-props</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Expands props onto the SVG element.</i><br><br><b>--no-svgo</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables SVG optimization using SVGO.</i><br><br><b>--no-prettier</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prevents code formatting with Prettier.</i><br><br><b>--config-file <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a custom configuration file path.</i><br><br><b>--config <i>&lt;key&gt;=&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Overrides configuration options directly.</i><br><br><b>--ignore-existing</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Skips processing files that already exist in the output directory.</i><br><br><b>--template <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses a custom template file for component generation.</i><br><br><b>--prettier-config <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Path to a custom Prettier configuration file.</i><br><br><b>--svgo-config <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Path to a custom SVGO configuration file.</i><br><br><b>--jsx-runtime <i>&lt;classic|automatic&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the JSX runtime mode (React 17+).</i><br><br><b>--filename-case <i>&lt;kebab|camel|pascal&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Controls the casing of output filenames.</i><br><br><b>--replace-attribute <i>&lt;attr&gt;=&lt;value&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Replaces an attribute's value in the SVG.</i><br><br>


title: DESCRIPTION
content:
<i>svgr</i> is a command-line tool within the <i>SVGR</i> ecosystem, designed to convert SVG (Scalable Vector Graphics) files into ready-to-use React components. It automates the process of importing vector assets into React applications, eliminating the need for manual conversion or complex SVG manipulation. The tool leverages <i>SVGO</i> for SVG optimization and <i>Prettier</i> for code formatting, ensuring efficient and readable output. It supports various configurations, allowing developers to control aspects like component naming, icon-specific attributes, TypeScript generation, and custom templates.<br><br>While not a native Linux command, <i>svgr</i> is executed via Node.js (typically with <i>npx</i> or as a globally installed package) and is widely adopted in modern front-end development workflows for its efficiency in handling SVG assets.


title: CAVEATS
content:
<i><code>svgr</code> is not a pre-installed Linux command. It requires a Node.js runtime and is typically installed via <code>npm</code> or <code>yarn</code>. Its primary use case is within web development, specifically for React applications, and may not be relevant for general-purpose system administration tasks. Complex transformations might require a deep understanding of SVG, SVGO, and Prettier configurations.</i>


title: <B>CONFIGURATION FLEXIBILITY</B>
content:
<i>svgr</i> offers extensive configuration options, allowing developers to define behaviors through command-line flags, dedicated configuration files (e.g., `.svgrrc.js`, `svgr.config.js`), or directly within `package.json`. This layered approach enables fine-grained control over SVG optimization (SVGO), code formatting (Prettier), and the generated React component structure.


title: <B>INTEGRATION WITH BUILD TOOLS</B>
content:
Beyond its standalone CLI usage, <i>svgr</i> is often integrated into front-end build pipelines using tools like Webpack (`@svgr/webpack`), Rollup (`@svgr/rollup`), or Vite. This allows SVG imports to be automatically transformed into React components during the bundling process, simplifying development and deployment.


title: HISTORY
content:
<i>The <code>SVGR</code> project, including the <code>svgr</code> CLI tool, was initiated and primarily developed by Greg Bergé. It gained significant traction around 2018-2019 as React development matured and the need for efficient SVG asset management became more apparent. Its adoption was fueled by its robust features, configurability, and seamless integration with popular build tools and frameworks, making it an essential utility for front-end developers working with SVG icons and graphics. It continues to be actively maintained and widely used in the JavaScript ecosystem.</i>


title: SYNOPSIS
content:
<b>svgtopam</b> [<i>-width=pixels</i>] [<i>-height=pixels</i>] [<i>-scale=float</i>] [<i>-background=color</i>] [<i>-opacity=float</i>] [<i>-antialias=boolean</i>] [<i>-invert</i>] [<i>-verbose</i>] [<i>file</i>]


title: PARAMETERS
content:
<b><b>-width=</b><i>pixels</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired width of the output image in pixels. If only width or height is given, the aspect ratio is maintained.<br><br><b><b>-height=</b><i>pixels</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the desired height of the output image in pixels. If only width or height is given, the aspect ratio is maintained.<br><br><b><b>-scale=</b><i>float</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scales the output image by the specified factor. A value of 1.0 means no scaling. This option is applied after <i>-width</i> or <i>-height</i> if specified.<br><br><b><b>-background=</b><i>color</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the background color for the output image. This can be a color name (e.g., "red"), a hexadecimal RGB value (e.g., "#FF0000"), or a Netpbm color specification.<br><br><b><b>-opacity=</b><i>float</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the global opacity for the entire image, a value between 0.0 (fully transparent) and 1.0 (fully opaque). This applies to the entire rendered SVG.<br><br><b><b>-antialias=</b><i>boolean</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls antialiasing during rendering. Use <i>TRUE</i> (default) to enable smooth edges or <i>FALSE</i> to disable it for sharper, potentially aliased, edges.<br><br><b><b>-invert</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inverts the colors of the resulting PAM image.<br><br><b><b>-verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose information about the conversion process to standard error, which can be useful for debugging.<br><br><b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the SVG input file. If omitted, <i><b>svgtopam</b></i> reads the SVG data from standard input.<br><br>


title: DESCRIPTION
content:
<i><b>svgtopam</b></i> is a utility within the Netpbm image manipulation toolkit that converts Scalable Vector Graphics (SVG) files into the Portable Arbitrary Map (PAM) format. PAM is a general-purpose Netpbm raster image format capable of representing various pixel depths and channel configurations, including transparency. The command reads an SVG image from standard input or a specified file and outputs the resulting PAM image to standard output. This allows for seamless integration of SVG content into workflows involving other Netpbm tools, which can then further process, transform, or convert the rasterized SVG image. <i><b>svgtopam</b></i> offers options to control the output image's dimensions, scaling, background color, opacity, and antialiasing, providing flexibility in how the vector graphic is rasterized.


title: CAVEATS
content:
<i><b>svgtopam</b></i> relies on an external SVG rendering library (commonly librsvg) for its core functionality. Therefore, the rendering quality, supported SVG features, and performance can be dependent on the capabilities and version of this underlying library. Complex or non-standard SVG features might not be fully supported.


title: INPUT AND OUTPUT
content:
By default, <i><b>svgtopam</b></i> reads SVG data from standard input, making it highly suitable for piping operations. The resulting PAM image is always written to standard output, enabling it to be easily piped to other Netpbm commands for further processing, such as format conversion (e.g., to PNG via <i><b>pamtopng</b></i>) or manipulation.


title: DEPENDENCIES
content:
This command is effectively a wrapper that utilizes an external SVG rendering library to perform the conversion. The most common dependency is the <i>librsvg</i> library, which must be installed on the system for <i><b>svgtopam</b></i> to function correctly. The behavior and capabilities of <i><b>svgtopam</b></i> are directly tied to the features supported by the installed SVG rendering library.


title: HISTORY
content:
<i><b>svgtopam</b></i> is an integral part of the Netpbm project, a venerable suite of graphics utilities for Unix-like systems. Its introduction reflects the Netpbm project's ongoing effort to support a wider array of image formats. It was developed to bridge the gap between the increasingly popular vector-based SVG format and Netpbm's raster-based image processing capabilities, leveraging existing open-source SVG rendering engines like librsvg to perform the actual rasterization.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all objects, including hidden or inactive ones.<br><br><b><b>-b</b>, <b>--brief</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display brief information for relevant objects.<br><br><b><b>-c</b>, <b>--clusters</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about configured clusters.<br><br><b><b>-C</b> <i>&lt;file&gt;</i>, <b>--css</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use a CSS file for output formatting (primarily for web-based views if applicable).<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable debug logging for more verbose output.<br><br><b><b>-f</b> <i>&lt;format&gt;</i>, <b>--format</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output format using a comma-separated list of field names.<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>-i</b> <i>&lt;seconds&gt;</i>, <b>--interval</b> <i>&lt;seconds&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the refresh interval in seconds for the interactive display.<br><br><b><b>-j</b>, <b>--jobs</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display job information (often the default view).<br><br><b><b>-n</b>, <b>--nodes</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display node information within the cluster.<br><br><b><b>-N</b>, <b>--no-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable colored output for terminals that do not support it or prefer monochrome.<br><br><b><b>-p</b>, <b>--partitions</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display partition information.<br><br><b><b>-q</b>, <b>--queue</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display queue information (jobs awaiting execution).<br><br><b><b>-s</b>, <b>--state</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display an overall cluster state summary.<br><br><b><b>-u</b>, <b>--users</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display information about users and their jobs.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the <i>sview</i> version number and exit.<br><br><b><b>-w</b> <i>&lt;width&gt;</i>, <b>--width</b> <i>&lt;width&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the display width, overriding auto-detection.<br><br><b><b>-x</b>, <b>--no-pager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not use a pager for output, sending all output directly to stdout.<br><br><b><b>-y</b> <i>&lt;key&gt;</i>, <b>--sort</b> <i>&lt;key&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the display by the specified field key.<br><br><b><b>-z</b> <i>&lt;tz&gt;</i>, <b>--timezone</b> <i>&lt;tz&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the display timezone for time-related fields.<br><br>


title: DESCRIPTION
content:
<i>sview</i> is a command-line utility for real-time monitoring and introspection of a SLURM workload manager cluster. Similar in concept to the <i>top</i> command, <i>sview</i> provides a dynamic, interactive display of various cluster components.<br><br>It allows users and administrators to quickly assess the status of jobs, nodes, partitions, and user activity within the SLURM environment. The display updates periodically, showing current states, resource utilization, and other critical metrics. Users can switch between different views (e.g., jobs, nodes, partitions, users) and apply sorting and filtering directly within the interactive interface, making it an invaluable tool for cluster management and troubleshooting. It provides a quick overview without needing to run multiple static <i>sinfo</i> or <i>squeue</i> commands.


title: CAVEATS
content:
<i>sview</i> requires a functional SLURM Workload Manager installation to operate. The information displayed is only as accurate as the <i>slurmctld</i> daemon provides. Users need appropriate permissions to access certain cluster details. Its primary utility is within SLURM environments; it has no function outside of them.


title: INTERACTIVE CONTROLS
content:
While running <i>sview</i>, users can interact with the display using various keyboard shortcuts. Pressing '<b>h</b>' or '<b>?</b>' typically brings up an in-application help screen detailing available commands, such as '<b>q</b>' to quit, '<b>j</b>' for job view, '<b>n</b>' for node view, '<b>p</b>' for partition view, and commands for sorting and filtering output.


title: DISPLAY MODES
content:
<i>sview</i> offers distinct display modes accessible via command-line options or interactive commands. The default mode often shows jobs. Other common modes include viewing cluster nodes, active partitions, a summary of the cluster state, or details about users. Each mode presents relevant metrics and statuses tailored to that specific aspect of the SLURM cluster.


title: HISTORY
content:
<i>sview</i> is an integral part of the SLURM (Simple Linux Utility for Resource Management) Workload Manager, which originated at Lawrence Livermore National Laboratory (LLNL). First released in 2002, SLURM was developed to manage and schedule large-scale computing clusters. <i>sview</i> evolved as a real-time, interactive monitoring tool within the SLURM suite, providing a dynamic alternative to static query commands for administrators and users to observe the fluctuating state of the cluster, jobs, nodes, and partitions. Its design reflects the need for immediate insight into cluster operations for efficient resource management and troubleshooting.


title: SYNOPSIS
content:
<i><b>swagger-codegen</b> <I>command</I> [<I>command-options</I>]<br><br>The primary command structure involves invoking <b>swagger-codegen</b> followed by a specific command and its associated options. The most frequently used command is `generate`.<br><br><b>Example for `generate` command:</b><br><I>swagger-codegen generate -i &lt;input_spec&gt; -l &lt;language&gt; -o &lt;output_dir&gt;</I></i>


title: PARAMETERS
content:
<b>-i, --input-spec <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the path or URL to the OpenAPI/Swagger definition file (JSON or YAML) used as input for code generation.</i><br><br><b>-l, --lang <generator></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Defines the target programming language or generator to use for code output (e.g., `java`, `typescript-angular`, `go`, `python`).</i><br><br><b>-o, --output <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the directory where the generated client SDK, server stub, or documentation files will be saved.</i><br><br><b>-c, --config <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides a path to a JSON or YAML configuration file that contains generator-specific options and properties.</i><br><br><b>--additional-properties <key=value,...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Allows passing additional, comma-separated properties directly to the generator, overriding or adding to its default configurations.</i><br><br><b>--skip-validate-spec</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables the default validation of the input OpenAPI/Swagger specification, useful for working with drafts or non-strict definitions.</i><br><br><b>--template-dir <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies a directory containing custom Mustache templates to override the default templates for code generation.</i><br><br>


title: DESCRIPTION
content:
<i><b>swagger-codegen</b> is a powerful command-line tool and library designed to automate the generation of API client SDKs, server stubs, and API documentation from an OpenAPI (formerly Swagger) specification. By consuming a JSON or YAML OpenAPI definition, it can produce boilerplate code in a multitude of programming languages and frameworks, significantly accelerating the development process for both API consumers and providers. Its primary goal is to minimize the amount of manual coding required for API integration, ensuring consistency between the API definition and its consuming/implementing code. This tool is instrumental in promoting an API-first development approach, allowing teams to define their APIs and then automatically generate the necessary code, reducing errors and improving efficiency across the software development lifecycle. It supports a wide array of generators, enabling flexible integration into diverse technology stacks.</i>


title: CAVEATS
content:
<i>It is important to note that the <b>swagger-codegen</b> project has been largely superseded by the <I>OpenAPI Generator</I>, which is a fork created due to differences in development philosophy and governance. As a result, <b>swagger-codegen</b> is less actively maintained and might not support the very latest OpenAPI specification versions or modern language features as comprehensively as its successor. Users seeking the most up-to-date features and ongoing support are often advised to consider OpenAPI Generator instead.</i>


title: KEY SUBCOMMANDS
content:
<i><b>swagger-codegen</b> supports several subcommands beyond `generate` for various tasks:<br><ul><li>`generate`: The most common command, used for generating code.</li><li>`langs`: Lists all available client and server generators supported by the tool. Run `swagger-codegen langs` to see the full list.</li><li>`config-help`: Provides detailed configuration options for a specific generator. For example, `swagger-codegen config-help -l java` shows all Java generator properties.</li><li>`validate`: Validates an OpenAPI/Swagger specification file for correctness.</li><li>`meta`: Generates a new template and configuration files to create a custom generator.</li></ul></i>


title: HISTORY
content:
<i>The <b>swagger-codegen</b> tool originated as a key component of the broader Swagger ecosystem, initially developed by Wordnik. It quickly became a popular choice for developers working with RESTful APIs, facilitating rapid code generation from Swagger (OpenAPI) definitions. Over time, as the OpenAPI Specification gained traction and community needs evolved, a significant portion of the community, including core contributors, forked the project to create the <I>OpenAPI Generator</I> in 2018. This fork aimed to accelerate development, improve governance, and better support the evolving OpenAPI Specification. While <b>swagger-codegen</b> continued to exist, its active development and maintenance significantly decreased in favor of the OpenAPI Generator.</i>


title: SYNOPSIS
content:
<i><B>swaks</B> [<I>options</I>]<br><B>swaks</B> <B>--to</B> <I>recipient@example.com</I> [<I>options</I>]<br><br>Example 1: Basic email send<br><B>swaks</B> <B>--to</B> <I>test@example.com</I> <B>--from</B> <I>sender@example.com</I> <B>--server</B> <I>mail.example.com</I><br><br>Example 2: Authenticated TLS connection<br><B>swaks</B> <B>--to</B> <I>user@example.com</I> <B>--server</B> <I>smtp.gmail.com:587</I> <B>--auth</B> <I>LOGIN</I> <B>--tls</B> <I>STARTTLS</I></i>


title: PARAMETERS
content:
<b>--to <address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the recipient's email address. Multiple <i>--to</i> options can be used to add more recipients.<br><br><b>--from <address></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the sender's email address.<br><br><b>--server <host[:port]></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the SMTP server to connect to. If port is omitted, defaults to 25 or 587 with STARTTLS.<br><br><b>--port <number></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the port number for the SMTP connection. Overrides port specified in <i>--server</i>.<br><br><b>--auth <method></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the authentication method (e.g., <i>LOGIN, PLAIN, CRAM-MD5, DIGEST-MD5, NTLM, GSSAPI, EXTERNAL</i>).<br><br><b>--auth-user <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the username for authentication.<br><br><b>--auth-password <password></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for authentication. Use with caution or consider <i>--auth-password-file</i>.<br><br><b>--tls <method></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls TLS/SSL usage. Options include <i>STARTTLS</i> (negotiate TLS), <i>SSL</i> (implicit SSL on typical SSL ports like 465), or <i>NO</i> (no TLS).<br><br><b>--data <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the email body from the specified file.<br><br><b>--body <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the email body directly from the command line.<br><br><b>--header <string></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an arbitrary header to the email. Can be used multiple times. E.g., '<i>Subject: Test</i>'.<br><br><b>--helo <domain></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the domain name used in the HELO/EHLO command. Defaults to the local hostname.<br><br><b>--debug</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables highly verbose debug output, showing the full SMTP conversation and internal workings.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides less verbose output than <i>--debug</i>, showing key parts of the SMTP conversation.<br><br><b>--quit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits immediately after the initial connection, without sending any commands. Useful for quick connectivity tests.<br><br><b>--protocol <type></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the protocol to use (<i>SMTP, ESMTP, LMTP</i>). Defaults to <i>ESMTP</i>.<br><br><b>--attach <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attaches a file to the email. Can be used multiple times.<br><br><b>--timeout <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the connection and read/write timeout in seconds.<br><br>


title: DESCRIPTION
content:
<i><b>swaks</b> (<b>S</b>wiss <b>A</b>rmy <b>K</b>nife for <b>S</b>MTP) is a powerful, flexible, and feature-rich command-line tool designed for testing and debugging SMTP (Simple Mail Transfer Protocol) servers. It allows users to send emails with precise control over every aspect of the SMTP conversation, making it invaluable for network administrators, developers, and testers working with mail systems. Unlike simple mail clients, <b>swaks</b> enables users to simulate complex scenarios, including various authentication methods (LOGIN, PLAIN, CRAM-MD5, DIGEST-MD5, NTLM), different TLS/SSL configurations (STARTTLS, implicit SSL), custom headers, specific data payloads, and even simulating various client behaviors. It supports a wide range of SMTP extensions and can provide verbose debug output, making it an essential utility for troubleshooting mail delivery issues, verifying server configurations, and developing mail-aware applications. Its versatility stems from its extensive set of command-line options, allowing for granular control over the entire SMTP transaction.</i>


title: CAVEATS
content:
<i>Due to its extensive options, <b>swaks</b> can have a steep learning curve for new users. A solid understanding of SMTP concepts, mail headers, and authentication mechanisms is beneficial for effective use. While designed for legitimate testing, its powerful capabilities could potentially be misused for sending unsolicited mail if not handled responsibly and ethically. Always ensure you have permission to test any mail server.</i>


title: COMMON USE CASES
content:
<i><br><b>swaks</b> is frequently used for:<br>- Testing email server connectivity and port accessibility.<br>- Verifying SMTP authentication methods and credentials.<br>- Debugging TLS/SSL negotiation issues.<br>- Sending test emails with specific headers or body content to check mail filtering rules.<br>- Simulating specific mail client behaviors for application development.<br>- Automating mail system health checks in scripts.<br></i>


title: INSTALLATION
content:
<i><br><b>swaks</b> is typically available in the package repositories of most Linux distributions. You can often install it using your distribution's package manager:<br>- On Debian/Ubuntu: <b>sudo apt-get install swaks</b><br>- On Red Hat/CentOS: <b>sudo yum install swaks</b> or <b>sudo dnf install swaks</b><br>- Alternatively, it can be downloaded as a Perl script from its official website and run directly.<br></i>


title: HISTORY
content:
<i><b>swaks</b>, standing for "<b>S</b>wiss <b>A</b>rmy <b>K</b>nife for <b>S</b>MTP", was created by Tony Finch. It is written in Perl and has been a staple in the toolkit of many system administrators and developers for over two decades. Its development has focused on providing comprehensive control over the SMTP protocol, enabling users to simulate almost any mail client behavior and debug complex server interactions. Its longevity and continued relevance stem from its adaptability to evolving SMTP standards and its robust feature set, making it a go-to utility for testing mail servers under various conditions.</i>


title: PARAMETERS
content:
<b>device</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block device representing the swap area (e.g., <i>/dev/sda2</i>, <i>/dev/nvme0n1p3</i>). This is a mandatory argument.<br><br><b>-L <label>, --label <label></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a new label for the swap area. The label can be up to 16 characters long.<br><br><b>-U <uuid>, --uuid <uuid></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a new UUID for the swap area. The UUID must be a valid 36-character UUID string (e.g., '12345678-abcd-ef01-2345-6789abcdef01').<br><br><b>-e, --erase-all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Erases both the label and UUID from the swap area's header. This makes the swap area identifiable only by its device path.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the operation to proceed, even if the specified device is mounted or in use. Use this option with <i>extreme caution</i> as it can lead to data corruption or system instability.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more details about the operation being performed.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command usage information and exits.<br><br><b>-V, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <i><b>swaplabel</b></i> utility and exits.<br><br>


title: DESCRIPTION
content:
<i><b>swaplabel</b></i> is a utility from the <i><b>util-linux</b></i> package used to display or modify the label and Universal Unique Identifier (UUID) of a Linux swap area. Unlike <i><b>mkswap</b></i>, which initializes a new swap partition from scratch, <i><b>swaplabel</b></i> operates on an <i>existing</i> swap area without reformatting it, preserving its contents. This command is particularly useful for identifying swap partitions by their human-readable labels or unique UUIDs.<br><br>Common use cases include:<br><br><i><b>1. Querying Information:</b></i> When invoked without any options, <i><b>swaplabel</b></i> displays the current label and UUID of the specified swap device. This helps in verifying the metadata of a swap partition.<br><i><b>2. Changing Metadata:</b></i> Users can assign a new label or UUID to a swap area. This is often necessary when cloning a disk, migrating a system, or fixing an <i><b>/etc/fstab</b></i> entry that relies on a specific label or UUID. If an <i><b>fstab</b></i> entry points to a non-existent or conflicting UUID/label, <i><b>swaplabel</b></i> can correct the swap partition's metadata to match.<br><i><b>3. Erasing Metadata:</b></i> The command also provides an option to erase both the label and UUID, effectively removing these identifiers from the swap header.<br><br>It's crucial to use <i><b>swaplabel</b></i> with caution, especially when the swap device is active, as incorrect modifications can lead to system instability or render the swap area unusable until corrected in <i><b>/etc/fstab</b></i>. It's generally recommended to deactivate the swap (<i><b>swapoff</b></i>) before making any changes.


title: CAVEATS
content:
<i><b>Data Loss Risk:</b></i> Modifying the label or UUID of an active swap area can lead to system instability or data corruption. Always deactivate the swap device using <i><b>swapoff</b></i> before making changes, if possible.<br><br><i><b>/etc/fstab Consistency:</b></i> If your system uses labels or UUIDs in <i><b>/etc/fstab</b></i> to identify swap partitions, any changes made with <i><b>swaplabel</b></i> must be manually updated in <i><b>/etc/fstab</b></i> to ensure the swap area is correctly recognized and activated on subsequent boots.<br><br><i><b>Permissions:</b></i> <i><b>swaplabel</b></i> typically requires root privileges to operate on block devices.


title: COMMON USE CASE: UPDATING /ETC/FSTAB
content:
If you clone a disk or move a system, and the original swap partition's UUID conflicts with another or is simply unknown, you might face issues activating swap on boot. <i><b>swaplabel</b></i> can resolve this.<br><br><i><b>1. Identify the swap partition:</b></i> Use <i><b>lsblk -f</b></i> or <i><b>blkid</b></i> to find your swap partition (e.g., <i>/dev/sdb2</i>) and its current UUID/label.<br><i><b>2. Deactivate swap:</b></i> <i><b>sudo swapoff /dev/sdb2</b></i><br><i><b>3. Generate a new UUID (optional but recommended):</b></i> <i><b>sudo swaplabel -U $(uuidgen) /dev/sdb2</b></i> (or use <i><b>-L</b></i> for a label).<br><i><b>4. Get the new UUID/label:</b></i> <i><b>sudo blkid /dev/sdb2</b></i><br><i><b>5. Update /etc/fstab:</b></i> Edit <i><b>/etc/fstab</b></i> to replace the old UUID/label with the new one. For example, change <i><b>UUID=old-uuid-here none swap sw 0 0</b></i> to <i><b>UUID=new-uuid-here none swap sw 0 0</b></i>.<br><i><b>6. Activate swap:</b></i> <i><b>sudo swapon -a</b></i> or <i><b>sudo swapon /dev/sdb2</b></i><br><i><b>7. Verify:</b></i> <i><b>cat /proc/swaps</b></i> to confirm the swap is active with the correct identifier.


title: HISTORY
content:
<i><b>swaplabel</b></i> is a part of the <i><b>util-linux</b></i> project, a standard collection of miscellaneous utilities for Linux. Its functionality complements other swap-related tools like <i><b>mkswap</b></i> and <i><b>swapon</b></i> by providing a mechanism to modify the metadata (label and UUID) of an <i>existing</i> swap area without requiring a full reformat. This capability became particularly important as Linux systems increasingly adopted UUIDs and labels for more robust and flexible device identification in configuration files like <i><b>/etc/fstab</b></i>, allowing systems to cope better with changes in device paths (e.g., <i>/dev/sda1</i> vs. <i>/dev/sdb1</i>). Its primary development and maintenance are handled within the <i><b>util-linux</b></i> project, ensuring its continued relevance and integration with core Linux functionalities.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deactivates all swap areas listed in <i>/etc/fstab</i>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the operation.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>swapoff</b> command is used to deactivate swap areas (partitions or files) on a Linux system. When swap is active, the kernel can move less-used pages of memory from RAM to the swap space on disk, freeing up physical memory for more active processes. Using <b>swapoff</b> reverses this process; it attempts to move all data from the specified swap area back into physical RAM and then marks the swap area as inactive. This can be necessary before modifying a swap partition, removing a swap file, or when troubleshooting memory issues. Running <b>swapoff</b> on a busy swap area can significantly impact system performance and may even lead to out-of-memory (OOM) conditions if there isn't enough physical RAM to hold all the data currently in swap. It requires root privileges to execute.


title: CAVEATS
content:
<i>swapoff</i> requires root privileges.<br>Deactivating swap can lead to out-of-memory (OOM) errors and system instability if insufficient physical RAM is available to hold the data currently stored in swap. It may also temporarily degrade system performance as data is moved from disk back into RAM.


title: USAGE EXAMPLES
content:
To deactivate a specific swap partition: <i>swapoff /dev/sdb2</i><br>To deactivate a specific swap file: <i>swapoff /mnt/swapfile.img</i><br>To deactivate all active swap areas: <i>swapoff --all</i>


title: SYNOPSIS
content:
<b>swapon</b> [<i>options</i>] <i>specialfile</i>...<br><b>swapon</b> -a [<i>options</i>]<br><b>swapon</b> -s


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates all swap areas marked with "sw" in <i>/etc/fstab</i>. This is the most common way to enable swap at boot.<br><br><b>-d, --discard</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Discards contents of the swap area before using it. Useful for SSDs to issue TRIM commands, potentially improving performance and lifespan.<br><br><b>-e, --ifup</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits quietly if the specified <i>specialfile</i> does not exist.<br><br><b>-p, --priority <priority></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the priority of the swap area. Higher numbers mean higher priority. Swap areas with higher priority are used before those with lower priority.<br><br><b>-s, --summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a concise summary of swap usage by device, similar to the <b>free</b> command's swap line.<br><br><b>--show</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a more detailed, column-formatted summary of swap usage, including priority and type.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity, showing more details about the actions being performed.<br><br>


title: DESCRIPTION
content:
The <b>swapon</b> command is used to enable devices or files for paging and swapping in Linux. It makes a specified swap area available to the system, expanding the effective virtual memory beyond the physical RAM. When the system runs out of physical memory, less frequently used data from RAM is moved to the swap space, allowing applications to continue running, albeit with a performance penalty. Swap areas can be dedicated disk partitions or regular files.<br>Typically, swap spaces are configured to activate automatically during system boot by listing them in the <i>/etc/fstab</i> file. The <b>swapon</b> command is crucial for managing the system's memory resources, especially in scenarios where applications demand more memory than physically available. It works in conjunction with <b>swapoff</b>, which disables swap areas.


title: CAVEATS
content:
While swap space is essential for system stability when RAM is scarce, it's significantly slower than physical memory. Excessive swapping can lead to poor system performance, often referred to as "thrashing."<br>Activating swap requires root privileges. Ensure that the designated swap area is correctly prepared (e.g., using <b>mkswap</b>) before enabling it. Using the <b>--discard</b> option on traditional HDDs offers no benefit and might even slightly decrease performance due to the overhead of issuing unnecessary TRIM commands.


title: SWAP PRIORITY
content:
Linux assigns priorities to swap areas. When multiple swap areas are active, the system prefers using higher-priority areas first. If two or more areas have the same priority, they are used in a round-robin fashion. Priorities can be set using the <b>-p</b> option or in <i>/etc/fstab</i>.


title: PERMANENT SWAP CONFIGURATION
content:
To make a swap area active automatically at boot, it must be listed in the <i>/etc/fstab</i> file. The typical entry for a swap partition looks like: <i>/dev/sda2 none swap sw 0 0</i>. For a swap file: <i>/swapfile none swap sw 0 0</i>. The <b>swapon -a</b> command then processes these entries during startup.


title: HISTORY
content:
The <b>swapon</b> command has been a fundamental utility in Linux since its early days, part of the standard <i>util-linux</i> package. Its core functionality of enabling swap areas has remained consistent, reflecting the stable nature of Linux's virtual memory management. Over time, options like <b>--discard</b> have been added to adapt to modern storage technologies like SSDs, enhancing its utility in contemporary computing environments.


title: PARAMETERS
content:
<b>-c <configfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file. Defaults to <i>~/.swatchrc</i> if not specified.<br><br><b>-t <tail_program></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>tail</i> program to use. Useful if your <i>tail</i> does not support <i>-f</i> or you want to use a different one (e.g., <i>logtail</i>).<br><br><b>-f <logfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the log file(s) to watch. Can be used multiple times to watch multiple files.<br><br><b>-i <interval></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the interval (in seconds) that <b>swatch</b> sleeps before checking for new input.<br><br><b>-P <pid_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the process ID (PID) of <b>swatch</b> to the specified file.<br><br><b>-r <restart_time></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts <b>swatch</b> at the specified time (e.g., <i>HH:MM</i>). Useful for refreshing configurations or clearing state.<br><br><b>--daemon</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>swatch</b> in the background as a daemon process.<br><br><b>--dump-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses the configuration file and prints the internal data structure used by <b>swatch</b>.<br><br><b>--parse-config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses the configuration file and exits, reporting any errors. Useful for validating configurations.<br><br><b>--script-dir <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory where <b>swatch</b> should look for its helper scripts (e.g., <i>mail_to</i>, <i>exec_shell</i>).<br><br><b>--awk-prog <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>awk</i> executable.<br><br><b>--perl-prog <path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>perl</i> executable.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of <b>swatch</b>.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command-line options.<br><br>


title: DESCRIPTION
content:
The <b>swatch</b> command, short for <i>Simple Logfile Watcher</i>, is a powerful and versatile tool used for monitoring log files (or any data stream) in real-time. It continuously scans specified log files for patterns defined in a flexible configuration file and performs predefined actions when a match is found. This makes it an invaluable asset for system administrators for proactive problem detection. Actions can include sending email alerts, executing custom commands, ringing a terminal bell, or writing to a different log file for further analysis. This allows for automated detection and response to critical events such as security breaches, application errors, or resource exhaustion without the need for constant manual log review. Its strength lies in its highly customizable, Perl-based configuration, enabling the use of complex regular expressions for pattern matching and a wide array of programmable actions to suit various operational needs.


title: CAVEATS
content:
<b>swatch</b> relies heavily on its configuration file, which uses Perl regular expressions. Misconfigured regular expressions or actions can lead to unexpected behavior, excessive resource consumption, or missed alerts. For high-volume log environments, its single-threaded nature might become a bottleneck. It's also important to manage the actions it performs; for instance, 'mail' actions can flood an inbox if not throttled properly, and 'exec' actions can pose security risks if not carefully constrained by permissions and input validation.


title: CONFIGURATION FILE STRUCTURE
content:
The core of <b>swatch</b>'s functionality lies in its configuration file, typically <i>~/.swatchrc</i> or specified by <i>-c</i>. This file defines a set of rules, each consisting of a regular expression pattern and associated actions to perform when that pattern is matched in the log file. Common actions include <i>echo</i> (print to screen), <i>bell</i> (ring terminal bell), <i>mail</i> (send email), <i>exec</i> (execute a command), <i>pipe</i> (pipe output to a command), <i>throttle</i> (limit action frequency), and <i>threshold</i> (limit actions based on count). Each rule can also specify options like <i>period</i> to define how often an action can be performed for a given pattern.


title: USE CASES
content:
<b>swatch</b> is commonly used for:<br>Real-time alerting on security events (e.g., failed login attempts, privilege escalations).<br>Monitoring application errors and warnings in custom log files.<br>Detecting resource exhaustion (e.g., disk full, low memory) from system logs.<br>Triggering automated responses to specific log entries, such as restarting a service or collecting diagnostic information.


title: HISTORY
content:
<b>swatch</b> originated in the early 1990s as a powerful tool for system administrators to automate monitoring of system logs. It was initially developed by Stephen E. Kochan and Steven R. Goodwin. Its design leverages Perl's strong regular expression capabilities, making it highly flexible for pattern matching. Over the years, it has remained a staple in many Unix/Linux environments for real-time log analysis due to its simplicity and effectiveness, preceding many modern log management solutions while still being relevant for its lightweight approach.


title: SYNOPSIS
content:
<b>sway</b> [<i>options</i>]<br><b>sway</b> <i>--version</i><br><b>sway</b> <i>--help</i><br><b>sway</b> <i>--debug</i><br><b>sway</b> <i>--validate</i> [<i>--config</i> <<i>file</i>>]


title: PARAMETERS
content:
<b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Sway version information and exits.<br><br><b><i>--debug</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug logging for Sway and its components, useful for troubleshooting.<br><br><b><i>--validate</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the specified or default configuration file for syntax errors without starting the compositor.<br><br><b><i>--config</i> <<i>file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative configuration file to load instead of the default (~/.config/sway/config or ~/.config/i3/config).<br><br><b><i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose logging output, providing more detailed information than default logging.<br><br><b><i>--quiet</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses all logging output to stderr during Sway's operation.<br><br><b><i>--exec</i> <<i>command</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a specified shell command after Sway has successfully initialized. Often used to start status bars or other session-specific applications.<br><br><b><i>--no-exec</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents Sway from executing any default session commands or commands specified with <i>--exec</i>.<br><br><b><i>--display</i> <<i>display</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Wayland display name to connect to. Typically handled by the environment, less common for direct manual use when starting a session.<br><br>


title: DESCRIPTION
content:
Sway is a tiling Wayland compositor designed as a direct replacement for the popular i3 window manager, but for the modern Wayland display server protocol instead of X11. It aims for full compatibility with i3's configuration file format and IPC interface, allowing users to seamlessly transition their existing i3 setups to a Wayland-native environment. Sway organizes application windows in a non-overlapping grid, maximizing screen real estate and facilitating efficient multi-tasking. It supports highly customizable keybindings, multiple workspaces, and a wide array of Wayland protocols, providing a secure and performant desktop experience. Leveraging Wayland's architectural benefits, Sway offers a contemporary alternative to traditional X11-based tiling window managers.


title: CAVEATS
content:
<i><b>Wayland-only:</b></i> Sway functions exclusively on the Wayland display protocol. While it supports X11 applications via Xwayland, a functional Wayland setup is a prerequisite.<br><i><b>GPU Drivers:</b></i> Optimal performance and stability heavily rely on properly configured hardware-accelerated GPU drivers. Software rendering can severely degrade the user experience.<br><i><b>Configuration:</b></i> Sway's behavior is entirely driven by its text-based configuration file. Errors in this file can prevent Sway from starting or functioning correctly, necessitating careful review and validation.


title: <B>CONFIGURATION FILE</B>
content:
Sway's entire behavior, including keybindings, workspace management, output settings, and auto-starting applications, is defined in a plain text configuration file. The default locations are typically <i>~/.config/sway/config</i> or <i>~/.config/i3/config</i>. Its syntax is nearly identical to i3's, providing extensive customization options.


title: <B>STARTING SWAY</B>
content:
Sway is commonly launched by a display manager (e.g., GDM, SDDM, Ly) as a user session. Alternatively, it can be started directly from a TTY by adding `<i>exec sway</i>` to a session script, such as a custom `.bash_profile` or an equivalent for Wayland-based environments, allowing it to take control of the display and manage applications.


title: HISTORY
content:
Sway was developed to port the acclaimed tiling window management paradigm of <b>i3</b> to the then-emerging <b>Wayland</b> display server protocol. Initiated as an open-source endeavor, its core design principle was to achieve complete compatibility with i3's configuration syntax and Inter-Process Communication (IPC) interface. This strategic choice enabled existing i3 users to effortlessly transition to a Wayland-native environment without needing to re-learn their desktop workflow or keybindings, significantly contributing to its rapid adoption and establishment as a robust Wayland compositor.


title: SYNOPSIS
content:
<b>swaybg</b> [<I>options</I>...] <br> <b>swaybg</b> <I>-m</I> <I>mode</I> <I>-i</I> <I>image_path</I> <br> <b>swaybg</b> <I>-c</I> <I>color</I>


title: PARAMETERS
content:
<b><b>-m</b>, <b>--mode</b> <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the scaling mode for the image. Possible values are <b>fill</b>, <b>fit</b>, <b>stretch</b>, <b>center</b>, and <b>tile</b>. This option is required when using an image.<br><br><b><b>-i</b>, <b>--image</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the image file to use as wallpaper. This option cannot be used with <b>--color</b>.<br><br><b><b>-c</b>, <b>--color</b> <I>color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a solid background color. The color can be specified as a hexadecimal value (e.g., <b>#RRGGBB</b> or <b>#AARRGGBB</b>) or a CSS color name. This option cannot be used with <b>--image</b>.<br><br><b><b>-o</b>, <b>--output</b> <I>output</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the output (e.g., <b>DP-1</b>, <b>HDMI-A-1</b>) to apply the background to. This option can be used multiple times to set different backgrounds for different outputs. If omitted, the background applies to all outputs.<br><br><b><b>-u</b>, <b>--update</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates an existing <b>swaybg</b> instance instead of starting a new one. This is useful for changing the wallpaper without flickering or restarting <b>swaybg</b>.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of <b>swaybg</b> and exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message describing command options and usage, then exits.<br><br>


title: DESCRIPTION
content:
<b>swaybg</b> is a command-line utility specifically designed to set backgrounds for outputs within the <I>Sway Wayland compositor</I>. It allows users to display image files as wallpapers or fill the background with a solid color. The tool supports various scaling modes for images, including <b>fill</b>, <b>fit</b>, <b>stretch</b>, <b>center</b>, and <b>tile</b>, providing flexibility in how backgrounds are presented across different screens.<br><br>It can apply distinct backgrounds to individual outputs or a single background across all active outputs. <b>swaybg</b> is a lightweight and efficient solution, often integrated directly into Sway's configuration file to automatically manage desktop backgrounds upon startup or when output configurations change. Its simplicity and native integration make it the standard wallpaper utility for the Sway environment.


title: CAVEATS
content:
<b>swaybg</b> is designed specifically for the <b>Sway Wayland compositor</b> and will not work with X11 or other Wayland compositors. When specifying multiple outputs using <b>-o</b>, each output must be immediately followed by its corresponding <b>-i</b> (image) or <b>-c</b> (color) option. For image backgrounds, ensure the image file path is correct and the file is accessible; otherwise, the background may not display.


title: USAGE WITH SWAY CONFIGURATION
content:
<b>swaybg</b> is most commonly invoked directly within the <I>Sway configuration file</I> (e.g., <I>~/.config/sway/config</I>) using the `output` command. For example, to set a background for all outputs, you might use: <br><code>output * bg /path/to/image.jpg fill</code> <br>or for a solid color: <br><code>output * bg #000000 solid_color</code><br><br>This method allows Sway to manage <b>swaybg</b> instances automatically. Alternatively, <b>swaybg</b> can be run as a standalone process via `exec`, for example: <br><code>exec swaybg -m fill -i /path/to/image.jpg</code>


title: BACKGROUND PROCESS BEHAVIOR
content:
When run, <b>swaybg</b> typically operates as a persistent background process, continuously managing the wallpaper for the specified outputs. If the <b>swaybg</b> process terminates, the wallpaper may disappear or revert to a default state. Using the <b>--update</b> (<b>-u</b>) flag is crucial for changing the wallpaper dynamically without stopping and restarting the process, which helps avoid screen flickering and conserves resources.


title: HISTORY
content:
<b>swaybg</b> was developed as an integral part of the <I>Sway</I> ecosystem to provide native wallpaper management for the Wayland compositor. Its creation addressed the incompatibility of traditional X11 wallpaper tools, like <b>feh</b>, with Wayland's display architecture. It aims to be a lightweight and efficient background setter, designed to integrate seamlessly with Sway's output management, and has evolved alongside the Sway project itself.


title: SYNOPSIS
content:
<b>swayidle</b> [<i>OPTIONS</i>] <b>-w</b> <I>EVENT_TYPE</I> <I>COMMAND...</I> [<b>-w</b> <I>EVENT_TYPE</I> <I>COMMAND...</I>]...


title: PARAMETERS
content:
<b><b>-w</b>, <b>--wait</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary option used to define a rule. It must be followed by an event type and its associated commands or actions. Multiple <b>-w</b> flags can be used to define various rules.<br><br><b><i>timeout &lt;seconds&gt; &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> after <i>seconds</i> of user inactivity. The <i>command</i> can be any shell command or the special <i>dpms</i> action.<br><br><b><i>resume &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> when user activity resumes, specifically after a <i>timeout</i> command has been triggered and potentially put the screen to sleep or locked it. This must follow a <i>timeout</i> rule.<br><br><b><i>lock &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> when the screen is locked (e.g., by <b>swaylock</b>).<br><br><b><i>unlock &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> when the screen is unlocked.<br><br><b><i>before-sleep &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> just before the system enters a sleep or suspend state.<br><br><b><i>after-lock &lt;command&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;An event type. Executes <i>command</i> immediately after the screen has been successfully locked.<br><br><b><i>dpms &lt;on|off&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special <b>swayidle</b> action keyword that can be used as a 'command' within <i>timeout</i> or <i>resume</i> rules. It controls Display Power Management Signaling for all outputs, turning them on or off.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <b>swayidle</b>.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with usage instructions and available options.<br><br>


title: DESCRIPTION
content:
<b>swayidle</b> is a daemon designed for the <I>Sway</I> Wayland compositor, allowing users to define actions that are triggered after periods of user inactivity. It integrates with the Wayland idle protocol to detect when the user has not interacted with input devices (keyboard, mouse, touchpad). Common uses include automatically locking the screen, turning off displays, or suspending the system after a specified idle duration.<br><br>It supports different idle states (idle, locked, screen-off) and allows chaining commands. For example, one might configure <b>swayidle</b> to lock the screen after 5 minutes of inactivity and then turn off the display after an additional 5 minutes. This makes it a crucial component for power management and security in a <I>Sway</I> environment.


title: CAVEATS
content:
<b>swayidle</b> requires a Wayland compositor that implements the idle protocol (like <I>Sway</I>). All commands specified are executed via <i>sh -c</i>, meaning they run in a subshell. Users should be careful with commands that might block or run indefinitely, as they could interfere with <b>swayidle</b>'s functionality or the system's responsiveness.


title: COMMAND EXECUTION CONTEXT
content:
All commands specified with <b>swayidle</b> are executed through <i>sh -c</i>. This implies that standard shell features such as pipes (<i>|</i>), redirections (<i>&gt;, &lt;</i>), and backgrounding (<i>&amp;</i>) can be utilized within the command strings, offering flexible scripting capabilities for idle actions.


title: CONFIGURING MULTIPLE RULES
content:
<b>swayidle</b> is designed to handle multiple rules concurrently. Users can define various <i>timeout</i> rules with different durations and commands, as well as combine them with <i>lock</i>, <i>unlock</i>, <i>before-sleep</i>, and <i>after-lock</i> events. This allows for sophisticated and layered idle management configurations tailored to specific user preferences and security requirements.


title: HISTORY
content:
<b>swayidle</b> was developed as an integral part of the <I>Sway</I> Wayland compositor ecosystem. It fills the role of idle management previously handled by tools like <I>xautolock</I> or <I>xidle</I> in Xorg environments, but adapted for Wayland's distinct architecture and security model. Its development is tightly coupled with <I>Sway</I>, aiming to provide a complete and native Wayland experience for desktop users by addressing essential power management and security needs.


title: PARAMETERS
content:
<b><b>-s, --socket</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Wayland socket to connect to, overriding the default. Useful for non-standard setups.<br><br><b><b>-c, --config</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration options from the specified file. Default path is typically <i>~/.config/sway/swaylock/config</i>.<br><br><b><b>-C, --no-config</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>swaylock</i> from loading any configuration file, relying solely on command-line arguments.<br><br><b><b>-u, --show-failed-attempts</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a counter or indicator for the number of failed authentication attempts.<br><br><b><b>-e, --indicator-caps-lock</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows an indicator on screen if the Caps Lock key is active.<br><br><b><b>-i, --image</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a background image for the lock screen. Can be specified multiple times for different outputs (monitors).<br><br><b><b>-m, --mode</b> <i>&lt;mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Determines how the background image is displayed (e.g., <i>fill</i>, <i>fit</i>, <i>stretch</i>, <i>tile</i>, <i>center</i>).<br><br><b><b>--color</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a solid background color for the lock screen. Color is specified in hexadecimal format (e.g., #RRGGBB or #AARRGGBB).<br><br><b><b>--ring-color</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color of the authentication indicator ring.<br><br><b><b>--inside-color</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color of the inside part of the authentication indicator.<br><br><b><b>--text-color</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color of the text displayed on the lock screen, such as the password prompt.<br><br><b><b>-f, --font</b> <i>&lt;font&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the font to use for all text displayed by <i>swaylock</i>.<br><br><b><b>-t, --font-size</b> <i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the font size for the selected font.<br><br><b><b>-P, --password-request-text</b> <i>&lt;text&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Customizes the text displayed when <i>swaylock</i> prompts for a password.<br><br><b><b>-w, --daemonize</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detaches <i>swaylock</i> from the terminal and runs it in the background after starting.<br><br><b><b>-h, --help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v, --version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>swaylock</i> is a lightweight and secure screen locker specifically designed for the Wayland display server protocol. It is part of the <I>Sway</I> window manager ecosystem but can be used independently with other Wayland compositors. When activated, <i>swaylock</i> obscures the screen, preventing access until the correct password is provided. It focuses on minimal features to maintain a small attack surface, offering customizable visuals such as background images, colors, font styles, and indicator appearance for user feedback during authentication. Its primary purpose is to protect your session from unauthorized access when you step away from your computer.


title: CAVEATS
content:
<i>swaylock</i> is designed for Wayland compositors. It will not work with X11-based display servers. Ensure your system's PAM (Pluggable Authentication Modules) configuration is correctly set up for user authentication, as <i>swaylock</i> relies on it. Incorrect PAM configuration can prevent unlocking or lead to security vulnerabilities. Multi-monitor setups may require specifying images per output using multiple <b>--image</b> arguments, or a single background color/image will span all outputs.


title: CUSTOMIZATION THROUGH CONFIGURATION FILE
content:
While many options can be passed via command-line arguments, <i>swaylock</i> strongly encourages the use of a configuration file (typically <i>~/.config/sway/swaylock/config</i>) for persistent settings. This allows users to define complex visual styles and behaviors without lengthy command-line invocations. The configuration file uses a simple key-value pair format, making it easy to manage a personalized lock screen appearance.


title: SECURITY CONSIDERATIONS
content:
<i>swaylock</i> is built with security in mind, leveraging PAM for authentication. It avoids unnecessary features to minimize its attack surface. However, its effectiveness relies on a well-configured PAM system and strong user passwords. Users should ensure their system is up-to-date and follows best security practices. It also supports optional key repeat disabling to prevent potential side-channel attacks during password entry.


title: HISTORY
content:
<i>swaylock</i> emerged as a core component of the <I>Sway</I> window manager project, an i3-compatible Wayland compositor. As Wayland gained traction and desktop environments moved away from X11, the need for native Wayland-based tools became apparent. <i>swaylock</i> was developed from scratch to provide a simple, secure, and Wayland-native screen locking solution, reflecting the minimalist and functional design philosophy of <I>Sway</I> itself. Its development is closely tied to the evolution of the <I>Sway</I> project, ensuring compatibility and integration with the Wayland ecosystem.


title: SYNOPSIS
content:
<b>swc</b> [<i>options</i>] &lt;<i>files...</i>&gt;<br><b>swc</b> [<i>options</i>] &lt;<i>input-file</i>&gt; -o &lt;<i>output-file</i>&gt;<br><b>swc</b> --help


title: PARAMETERS
content:
<b>-d, --out-dir &lt;dir&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile all input files and emit them into the specified output directory, preserving the directory structure.<br><br><b>-o, --out-file &lt;file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compile a single input file and emit the result to the specified output file. Not used with multiple input files.<br><br><b>-s, --source-maps [type]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable source map generation. 'type' can be <i>true</i>, <i>inline</i>, or <i>both</i>.<br><br><b>-w, --watch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Watch input files and directories for changes and recompile automatically.<br><br><b>--config &lt;path&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a path to an <i>swc</i> configuration file (e.g., <b>.swcrc</b>) to override the default lookup.<br><br><b>--minify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Minify the output code, reducing its size by removing whitespace, shortening variable names, etc.<br><br><b>--env-name &lt;name&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the environment name (e.g., 'development', 'production') to load environment-specific configurations from <b>.swcrc</b>.<br><br><b>--copy-files</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When using <i>--out-dir</i>, copy non-compilable files (e.g., CSS, images) to the output directory.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the current <i>swc</i> CLI version.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show usage instructions and available options.<br><br>


title: DESCRIPTION
content:
<i>swc</i> (Speedy Web Compiler) is an extremely fast, Rust-based toolkit for JavaScript and TypeScript. It provides core functionalities essential for modern web development, including transpilation (converting modern ECMAScript/TypeScript code to older versions compatible with various browsers or environments), minification (reducing code size for faster loading), and bundling. <br><br>Designed with performance in mind, <i>swc</i> is often used as a high-speed alternative to tools like Babel for transpilation or Terser for minification, significantly accelerating build times in large-scale projects. It processes code through a series of configurable plugins and can be extensively customized via a <b>.swcrc</b> configuration file. While primarily a library, its command-line interface via <b>@swc/cli</b> allows direct invocation for various development and build tasks.


title: CAVEATS
content:
<i>swc</i> is not a standard Linux system command and must be installed, typically via npm or yarn as part of a Node.js project (e.g., <b>npm install @swc/cli</b>). It's primarily used in web development workflows for JavaScript and TypeScript compilation. Its configuration often relies on a <b>.swcrc</b> file located in the project root, which defines compilation targets, plugins, and other transformations.


title: CONFIGURATION FILE (.SWCRC)
content:
<i>swc</i> heavily relies on a <b>.swcrc</b> JSON configuration file, usually located in the project root. This file specifies all compilation options, including presets (like <b>@swc/preset-env</b> for targeted environments) and plugins for various transformations (e.g., React JSX, TypeScript). Most complex configurations are managed through this file rather than command-line arguments.


title: INTEGRATION WITH BUILD TOOLS
content:
While <i>swc</i> provides a CLI, it's very commonly integrated into larger build systems and frameworks. For instance, Next.js uses <i>swc</i> internally for fast compilation, and bundlers like Webpack or Rollup can use <i>swc</i> loaders/plugins to accelerate their JavaScript processing steps. This integration makes it a powerful backend for many modern web development toolchains.


title: HISTORY
content:
<i>swc</i> was created by DongYoon Kang and is developed in Rust, a programming language known for its performance and memory safety. It emerged as a response to the need for faster build tools in the JavaScript ecosystem, aiming to provide a high-performance alternative to existing solutions like Babel, which are traditionally written in JavaScript. Its development focused on leveraging Rust's capabilities to deliver significantly faster compilation and minification times, quickly gaining traction in the modern web development community.


title: SYNOPSIS
content:
<b>swift <I>subcommand</I> [options]</b><br><b>swift <I>file</I>.swift [arguments...]</b><br><b>swift --version</b><br><b>swift --help [<I>subcommand</I>]</b><br><br><i>Common Subcommands:</i><br><b>swift build [options]</b><br><b>swift run [options] [<I>target</I> [<I>arguments</I>...]]</b><br><b>swift test [options]</b><br><b>swift package <I>subcommand</I> [options]</b>


title: PARAMETERS
content:
<b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Swift compiler version and associated toolchain information.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays general help or specific help for a given subcommand.<br><br><b><b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing detailed progress and commands being executed.<br><br><b><b>--configuration <I>config</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the build configuration (e.g., <i>debug</i> or <i>release</i>) for building or running targets. Common for <i>build</i>, <i>run</i>, <i>test</i>.<br><br><b><b>--build-path <I>path</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the custom path for the build products. Common for <i>build</i>.<br><br><b><b>--triple <I>target-triple</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target triple for cross-compilation.<br><br><b><b>--skip-build</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the build phase when running or testing, assuming artifacts are already built. Common for <i>run</i>, <i>test</i>.<br><br><b><b>--enable-test-discovery</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables automatic test discovery for Swift Package Manager tests. Common for <i>test</i>.<br><br>


title: DESCRIPTION
content:
The <b><I>swift</I></b> command is the primary command-line interface for interacting with the Swift programming language toolchain. It provides a versatile set of subcommands for building, running, testing, and managing Swift packages, making it an essential tool for Swift developers on Linux. Users can compile Swift source code into executables or libraries, execute Swift scripts directly, and manage dependencies for complex projects using the integrated Swift Package Manager (SPM). The command facilitates a smooth development workflow, from project initialization to deployment, by abstracting complex build processes and offering a unified interface for various development tasks. Its cross-platform nature allows Swift applications to be developed and deployed consistently across different operating systems, including Linux, macOS, and Windows.


title: CAVEATS
content:
The <b><I>swift</I></b> command is not a standard, pre-installed Linux utility; it requires the Swift toolchain to be manually installed or set up on the system. Its primary utility is for Swift language development, and it does not perform general system administration tasks like most other core Linux commands. Functionality heavily depends on the installed Swift version and associated libraries.


title: <B>SUBCOMMANDS STRUCTURE</B>
content:
The <b><I>swift</I></b> command operates primarily through a subcommand model, where the first argument specifies the action to perform (e.g., <i>build</i>, <i>run</i>, <i>test</i>, <i>package</i>). Each subcommand may have its own set of specific options and arguments, allowing for granular control over different aspects of Swift development.


title: <B>SWIFT PACKAGE MANAGER (SPM)</B>
content:
A significant part of the <b><I>swift</I></b> command's functionality is provided by the integrated Swift Package Manager. SPM is a tool for managing the distribution of Swift code, designed to make it easy to share code and automate its compilation. Commands like <b><I>swift build</I></b>, <b><I>swift run</I></b>, and <b><I>swift test</I></b> leverage SPM for dependency resolution and project configuration.


title: HISTORY
content:
The Swift programming language was introduced by Apple in 2014, initially as a proprietary language for Apple platforms. In December 2015, Apple open-sourced Swift, including the compiler and core libraries, under the Apache 2.0 license. This move was pivotal, making Swift available on Linux and other non-Apple platforms. The <b><I>swift</I></b> command-line tool emerged as part of this open-source initiative, evolving to provide a unified interface for building, testing, and managing Swift projects across different operating systems. Its development has focused on enhancing cross-platform compatibility, improving the Swift Package Manager (SPM) for dependency management, and streamlining the developer experience outside of Xcode.


title: SEE ALSO
content:
<b>clang</b> (1) - The Clang C, C++, and Objective-C compiler, often used as Swift's underlying compiler driver., <b>gcc</b> (1) - The GNU Compiler Collection, an alternative compiler suite., <b>make</b> (1) - A GNU tool for controlling the generation of executables and other non-source files of a program., <b>git</b> (1) - The popular distributed version control system, frequently used by Swift Package Manager for dependency resolution., <b>xcodebuild</b> (1) - (macOS only) Builds one or more targets in a project or workspace (analogous functionality on macOS).


title: PARAMETERS
content:
<b>-c++</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate C++ wrapper code. By default, SWIG generates C-compatible wrappers.<br><br><b>-java</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Java language bindings.<br><br><b>-python</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Python language bindings.<br><br><b>-perl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Perl language bindings.<br><br><b>-ruby</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Ruby language bindings.<br><br><b>-php</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate PHP language bindings.<br><br><b>-octave</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Octave language bindings.<br><br><b>-tcl</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Tcl language bindings.<br><br><b>-go</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate Go language bindings.<br><br><b>-o <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output C/C++ wrapper file. If not specified, SWIG generates a default name.<br><br><b>-outdir <directory></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output directory for generated language-specific files (e.g., Python <b>.py</b> files, Java <b>.java</b> files).<br><br><b>-I<path></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Add a directory to the SWIG include path, similar to <b>-I</b> in C/C++ compilers.<br><br><b>-D<symbol></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define a preprocessor symbol, equivalent to <b>#define</b>.<br><br><b>-U<symbol></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Undefine a preprocessor symbol.<br><br><b>-Wall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable all warnings generated by SWIG.<br><br><b>-Wextra</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable extra warnings (implies <b>-Wall</b>).<br><br><b>-module <name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the name of the generated module or package.<br><br><b>-version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display SWIG version information and exit.<br><br><b>-help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message with available options.<br><br>


title: DESCRIPTION
content:
<i>SWIG</i> (Simplified Wrapper and Interface Generator) is an open-source tool designed to connect programs and libraries written in C and C++ with various high-level scripting languages. It automates the tedious and error-prone process of writing "glue code" or "wrapper code" that enables seamless communication between different language environments.<br><br>Users provide SWIG with an interface file (typically ending in <b>.i</b>) that describes the C/C++ API to be exposed. SWIG then parses this file and generates both C/C++ wrapper code (which handles the low-level calls) and language-specific binding code (e.g., Python extension modules, Java JNI code, Perl XS modules, etc.). This makes it possible to leverage the performance and extensive libraries of C/C++ from the rapid development environments of languages like <i>Python</i>, <i>Perl</i>, <i>Ruby</i>, <i>Java</i>, <i>C#</i>, <i>PHP</i>, <i>R</i>, <i>Tcl</i>, and <i>Go</i>. It's widely used for creating language bindings for existing C/C++ libraries.


title: CAVEATS
content:
While powerful, SWIG can be complex to master, especially with advanced C++ features like templates, operator overloading, or complex inheritance hierarchies. Error messages can sometimes be cryptic, requiring a deep understanding of both C/C++ and the target scripting language. Users must also handle the compilation and linking of the generated C/C++ wrapper code manually, often requiring a separate build system (e.g., <b>make</b>, <b>cmake</b>, or specific language build tools like <b>setuptools</b> for Python).


title: INTERFACE FILES (<B>.I</B>)
content:
The core input to SWIG is an interface file, typically with a <b>.i</b> extension. This file is similar to a C/C++ header file but includes special SWIG directives (starting with <b>%</b>) that guide the wrapper generation process. These directives allow users to specify which functions, classes, and variables to expose, apply renaming rules, ignore certain declarations, or embed custom code for the target language. It serves as the primary mechanism for customizing the generated bindings.


title: TYPEMAPS
content:
<i>Typemaps</i> are one of SWIG's most powerful features. They define how data types are converted between C/C++ and the target scripting language. Typemaps allow developers to customize the marshaling and unmarshaling of complex data structures, handle memory management, manage pointers, and integrate custom data types. They provide fine-grained control over the generated interface, ensuring data is passed correctly and efficiently across language boundaries.


title: HISTORY
content:
SWIG was initially developed by <i>David Beazley</i> in the mid-1990s as a tool to simplify the process of interfacing C/C++ code with scripting languages, particularly Tcl and Python. Its development was driven by the need for a robust and automated solution to generate language bindings, avoiding the manual and error-prone process of writing glue code. Over the years, SWIG has grown significantly, adding support for a vast array of target languages and continuously improving its C++ parsing capabilities. It remains an actively maintained and widely adopted tool for high-performance language integration.


title: PARAMETERS
content:
<b><b>-s &lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads the specified <b>Prolog</b> source <i>file</i> into the environment. If no other goal is specified, the system enters the interactive top-level.<br><br><b><b>-g &lt;goal&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified <b>Prolog</b> <i>goal</i> immediately after loading any specified files. This is often used for non-interactive execution, exiting after the goal succeeds or fails.<br><br><b><b>-t &lt;goal&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>top-level goal</i> that is executed when the system is ready to accept user input. The default is <i>prolog</i>, which starts the interactive prompt.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in <i>quiet mode</i>, suppressing the initial welcome banner and other informational messages during startup.<br><br><b><b>--non-interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the system from entering the interactive top-level after execution. The interpreter exits after the specified goal completes or fails, making it ideal for scripting.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief summary of command-line options and usage information.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the <b>SWI-Prolog</b> version number, copyright information, and build details.<br><br>


title: DESCRIPTION
content:
<i>swipl</i> invokes the <b>SWI-Prolog</b> interpreter, a comprehensive and widely used <b>Prolog</b> implementation. <b>Prolog</b> is a general-purpose logic programming language often associated with artificial intelligence, knowledge representation, and computational linguistics. The command provides an interactive top-level environment (REPL) for developing and running <b>Prolog</b> programs. It supports a rich set of built-in predicates, modules, threads, and interfaces to other languages like <i>C</i> and <i>Java</i>. Users can load <b>Prolog</b> source files, query the knowledge base, and debug programs directly from the command line. It also allows for executing scripts in non-interactive mode, making it suitable for scripting and deploying <b>Prolog</b> applications.


title: CAVEATS
content:
<b>SWI-Prolog</b>, while powerful, can sometimes be resource-intensive for very large knowledge bases or complex computations due to its garbage collection and memory management. Debugging complex <b>Prolog</b> programs can have a steep learning curve, requiring familiarity with the execution model and effective use of the trace debugger. Path handling for modules and files can sometimes be tricky due to <b>Prolog</b>'s module search paths.


title: INTERACTIVE TOP-LEVEL
content:
When invoked without arguments, <i>swipl</i> starts an interactive shell where users can enter queries, load files, and debug programs directly. Queries are terminated with a period ('.') followed by Enter, and results (variable bindings) are displayed immediately.


title: CREATING EXECUTABLES (SAVED STATES)
content:
<b>SWI-Prolog</b> can create 'saved states' or standalone executables using predicates like <i>qsave_program/1</i> or <i>qsave_program/2</i>. These executables bundle a <b>Prolog</b> program and its required libraries into a single file, allowing for easy distribution and deployment without requiring a full <b>SWI-Prolog</b> installation.


title: HISTORY
content:
<b>SWI-Prolog</b> was initially developed in 1987 by <i>Jan Wielemaker</i> at the <i>University of Amsterdam (UvA)</i>. Its name originally stood for <i>"Socrates Workbench"</i> <b>Prolog</b>, referencing an early expert system shell. Over decades, it has evolved into a robust, feature-rich, and highly portable <b>Prolog</b> system, widely adopted in both academic and industrial settings due to its comprehensive library, extensibility, and active community support. It continues to be actively developed and maintained.


title: PARAMETERS
content:
<b><i>new_root</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the directory that will become the new root filesystem. This directory must already be mounted before calling <i><b>switch_root</b></i>.<br><br><b><i>init</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the initial program (e.g., <i>/sbin/init</i>) on the <i>new_root</i> filesystem that will be executed immediately after the root switch. This program takes over control of the system.<br><br><b>[<i>arg</i>...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional arguments that will be passed directly to the <i>init</i> program when it is executed.<br><br>


title: DESCRIPTION
content:
<i><b>switch_root</b></i> is a utility primarily used during the Linux boot process, specifically within an initramfs or initrd environment. Its main purpose is to change the current root filesystem from the temporary in-memory root (provided by the initramfs) to the actual, persistent root filesystem mounted from a disk. It achieves this by internally calling the <i>pivot_root(2)</i> system call, which shifts the current root to a new mount point and designates the new root as the system's actual root. After successfully pivoting, <i><b>switch_root</b></i> then executes the specified <i>init</i> program (typically <i>/sbin/init</i> or <i>/bin/systemd</i>) on the newly established root filesystem. This command is crucial for a seamless transition from the initial boot environment to the fully functional operating system, ensuring that the final root is correctly established before the main system services are launched.


title: CAVEATS
content:
<i><b>switch_root</b></i> is designed for a very specific use case: transitioning from an initramfs/initrd environment to the real root filesystem. It should be the last command executed in the initramfs script, as it uses <i>exec(2)</i> to launch the new <i>init</i>, meaning it does not return. The <i>new_root</i> must be properly mounted before execution. It relies on the <i>pivot_root(2)</i> system call, which requires specific kernel capabilities and permissions. The old root filesystem, if not explicitly unmounted by the new <i>init</i>, will typically become accessible under <i>new_root/old_root</i> or similar.


title: BOOT SEQUENCE ROLE
content:
<i><b>switch_root</b></i> plays a critical role in the Linux boot sequence. After the kernel loads and unpacks the <i>initramfs</i>, the <i>initramfs</i>'s <i>/init</i> script identifies and mounts the real root filesystem. Once the real root is prepared, <i><b>switch_root</b></i> is invoked. Its execution ensures that the system's perspective of the root changes from the temporary in-memory filesystem to the actual disk-based root, finally executing the system's designated <i>init</i> process to continue the boot process with the correct filesystem hierarchy and services.


title: COMPARISON WITH <I>PIVOT_ROOT</I>
content:
While <i><b>switch_root</b></i> uses the <i>pivot_root(2)</i> system call internally, it's more than just a direct wrapper. <i><b>switch_root</b></i> handles some setup and cleanup around the pivot operation specifically for the boot process, such as attempting to make the old root available at <i>/old_root</i> (though this often becomes <i>new_root/old_root</i>) and most importantly, it <i>exec</i>s the new <i>init</i> process. In contrast, <i>pivot_root(2)</i> is merely the low-level system call that changes the mount points, requiring manual handling of unmounting the old root and executing the subsequent processes.


title: HISTORY
content:
<i><b>switch_root</b></i> is a component of the <i>util-linux</i> project, a collection of essential utilities for Linux. Its development is closely tied to the evolution of the Linux boot process, particularly the widespread adoption of <i>initramfs</i>. It provides a more robust and standardized method for transitioning to the real root filesystem compared to earlier, more rudimentary scripts that might have used complex <i>chroot</i> and unmounting sequences. Its inclusion in <i>util-linux</i> ensures it's a standard tool available in almost all Linux distributions for managing the boot sequence from the temporary initramfs environment.


title: SYNOPSIS
content:
<code>swupd</code> [<I>global options</I>] <I>command</I> [<I>command arguments</I>]<br><br>Common commands:<br><code>swupd update</code><br><code>swupd bundle-add</code> <I>bundle_name</I> [<I>bundle_name</I> ...]<br><code>swupd bundle-remove</code> <I>bundle_name</I> [<I>bundle_name</I> ...]<br><code>swupd search</code> <I>keyword</I><br><code>swupd verify</code><br><code>swupd rollback</code> <I>version</I><br><code>swupd status</code>


title: PARAMETERS
content:
<b>update</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the system to the latest available version.<br><br><b>bundle-add <bundle(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs one or more specified software bundles.<br><br><b>bundle-remove <bundle(s)></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes one or more specified software bundles from the system.<br><br><b>search <keyword></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Searches for available software bundles matching the keyword.<br><br><b>verify</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Verifies the integrity of all installed files against the system's manifest.<br><br><b>rollback <version></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverts the system to a previously saved version specified by its version ID.<br><br><b>repair</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to repair the system's state, often after a failed update or verification.<br><br><b>diagnose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides diagnostic information about the <code>swupd</code> client and system update state.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current <code>swupd</code> client status, OS version, and update information.<br><br><b>info</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows information about the <code>swupd</code> client itself, including version and capabilities.<br><br><b>-V, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details during command execution.<br><br><b>-F, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an action, bypassing some safety checks or prompts.<br><br><b>--fix</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with 'verify' to attempt to fix corrupted files or missing links.<br><br><b>--disable-rollback</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the creation of a rollback point during an update.<br><br>


title: DESCRIPTION
content:
<code>swupd</code> is the primary command-line utility and daemon for managing software updates and bundles in the Clear Linux OS. Developed by Intel, it employs a unique, highly optimized update mechanism designed for speed, security, and reliability. Unlike traditional package managers, <code>swupd</code> operates on a "bundle" system, where collections of software are curated and updated atomically. This allows for incredibly fast delta updates, often downloading only the changes between versions, and ensures system consistency by applying updates as a single, all-or-nothing transaction. Key features include full system integrity verification, robust rollback capabilities to previous system versions, and a stateless design philosophy where user data is separated from the OS binaries. <code>swupd</code> is central to Clear Linux's mission of providing a secure, performant, and easily maintainable operating system. It simplifies system administration by providing a unified interface for installing software, updating the OS, and repairing corrupted installations.


title: CAVEATS
content:
<code>swupd</code> is exclusively designed for and operates only on the Clear Linux OS. It is not compatible with other Linux distributions. Its bundle-based approach differs significantly from traditional package managers (e.g., APT, DNF, YUM), meaning users from other distributions may need to adapt their workflow. Updates, while highly efficient, are typically whole-system updates rather than individual package updates, which can result in larger download sizes if the system is very outdated.


title: BUNDLE SYSTEM
content:
<code>swupd</code> manages software as curated collections called <i>bundles</i>, not individual packages. This simplifies dependency management, ensures software compatibility, and allows for efficient, atomic updates of entire functional units.


title: ATOMIC UPDATES
content:
Updates performed by <code>swupd</code> are atomic, meaning they either fully succeed or completely revert, leaving the system in a consistent, working state. This prevents partial updates and system corruption, even in the event of power loss during an update.


title: ROLLBACK CAPABILITY
content:
A core feature of <code>swupd</code> is its ability to easily rollback the entire system to a previous, known-good version. This provides a crucial safety net, allowing users to revert changes if an update introduces unforeseen issues, ensuring system resilience.


title: STATELESS DESIGN
content:
Clear Linux OS, and by extension <code>swupd</code>, adheres to a stateless design philosophy. This separates the operating system binaries and configurations (managed by <code>swupd</code>) from user data and mutable configurations, making system updates safer and more predictable.


title: HISTORY
content:
<code>swupd</code> was developed by Intel as an integral part of the Clear Linux OS from its inception. The design philosophy behind <code>swupd</code> was driven by the need for a highly performant, secure, and easily maintainable operating system, specifically for cloud and edge computing environments. Its development focused on achieving atomic updates, efficient delta downloads, and robust rollback capabilities to ensure system stability and rapid deployment of security patches and new features. It eschews traditional individual package management in favor of a curated "bundle" system to simplify dependency management and enhance system consistency, reflecting Clear Linux's "stateless" approach.


title: SEE ALSO
content:
<code>clr-debug-info(1)</code> - A utility for gathering debugging information in Clear Linux OS., <code>clr-installer(8)</code> - The Clear Linux OS installer, which utilizes <code>swupd</code> principles., <code>os-release(5)</code> - Standard file describing the operating system.


title: SYNOPSIS
content:
<b>swww init</b><br><b>swww img</b> [<i>OPTIONS</i>] <i>&lt;PATH&gt;</i><br><b>swww clear</b> [<i>OPTIONS</i>]<br><b>swww query</b><br><b>swww stop</b><br><b>swww kill</b>


title: PARAMETERS
content:
<b>-o, --output <i>&lt;NAME&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output(s) to apply the wallpaper. Use '<i>*</i>' for all, or a comma-separated list of monitor names.<br><br><b>-t, --transition-type <i>&lt;TYPE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the type of transition effect for changing wallpapers (e.g., '<i>fade</i>', '<i>wipe</i>', '<i>grow</i>', '<i>center</i>', '<i>outer</i>').<br><br><b>-d, --transition-duration <i>&lt;DURATION&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the duration of the transition in milliseconds.<br><br><b>-e, --transition-easing <i>&lt;EASING&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the easing function for the transition animation (e.g., '<i>linear</i>', '<i>ease</i>', '<i>ease-in</i>', '<i>ease-out</i>').<br><br><b>--resize <i>&lt;RESIZE_TYPE&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls how the image is resized to fit the screen (e.g., '<i>zoom</i>', '<i>crop</i>', '<i>fit</i>', '<i>center</i>').<br><br><b>--fill <i>&lt;COLOR&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a hexadecimal color to fill empty areas when the image doesn't cover the entire screen (e.g., with '<i>fit</i>' resize type).<br><br>


title: DESCRIPTION
content:
<i>swww</i> is a command-line utility designed to set wallpapers on Wayland compositors. Unlike traditional X11 wallpaper setters, <i>swww</i> is specifically built for the Wayland environment, providing robust support for various image formats including static images (PNG, JPEG, etc.), animated GIFs, and even video formats (with appropriate libraries). It leverages the <br><i>wlr-layer-shell</i> protocol for placement and <i>wlroots</i> for rendering, making it compatible with a wide range of Wayland compositors such as Sway, Hyprland, River, and others that use <i>wlroots</i>. <i>swww</i> also features wallpaper caching for faster loading, support for multiple outputs, and various animation styles for smooth transitions when changing wallpapers. It operates as a client that sends commands to a background daemon (<i>swww-daemon</i>) which handles the actual rendering and updates, ensuring persistent wallpapers and efficient resource usage.


title: CAVEATS
content:
<i>swww</i> is exclusively designed for Wayland compositors that implement the <i>wlr-layer-shell</i> protocol (e.g., Sway, Hyprland, River). It will <b>not</b> function in X11 environments. The <i>swww-daemon</i> must be running (usually initiated via '<b>swww init</b>') for the client commands like '<b>swww img</b>' to work. Support for certain video formats might require additional system libraries like <i>ffmpeg</i>.


title: DAEMON/CLIENT ARCHITECTURE
content:
<i>swww</i> operates in a two-part model: a long-running <b>swww-daemon</b> which handles the actual rendering and display of wallpapers, and a client <b>swww</b> command-line tool that sends instructions to the daemon. This architecture ensures efficient management and quick updates of wallpapers without restarting processes, and allows for continuous animation playback.


title: WAYLAND SPECIFICITY
content:
It is crucial to understand that <i>swww</i> is built from the ground up for Wayland. It leverages Wayland-specific protocols and libraries, meaning it is incompatible with traditional X11 display servers. Users migrating from X11 should note that familiar X11 wallpaper tools like <i>feh</i> or <i>nitrogen</i> will not work with Wayland, and <i>swww</i> serves as a native Wayland solution.


title: HISTORY
content:
<i>swww</i> emerged to fill a critical gap in Wayland's ecosystem: a robust and feature-rich wallpaper manager, particularly for animated backgrounds like GIFs. Unlike early Wayland wallpaper solutions such as <i>swaybg</i>, which lacked advanced animation and transition capabilities, <i>swww</i> provided dynamic desktop experiences. Its development has focused on seamless integration with <i>wlroots</i>-based compositors, performance optimization, and expanding its array of visual effects, making it a popular choice for modern Wayland desktop setups.


title: SEE ALSO
content:
sway(1), hyprctl(1), feh(1) <i>(X11 alternative)</i>, nitrogen(1) <i>(X11 alternative)</i>, wallutils(1)


title: SYNOPSIS
content:
<i><b>sxiv</b> [<b>-bfgqrtzDNeovV</b>] [<b>-G GEOMETRY</b>] [<b>-s SCALE</b>] [<b>-S STATUS</b>] [<b>-Z ZOOM</b>] [<b>-W WINDOWID</b>] [<b>-b COMMAND</b>] [<b>-e COMMAND</b>] [<b>-p PATH</b>] [<b>-q QUALITY</b>] [<b>-t THUMBSIZE</b>] [<b>--</b>] [<i>FILE...</i>]</i><br><br><i><b>sxiv</b> is typically invoked by providing one or more image files as arguments. If directories are provided, <b>sxiv</b> will display all image files within them.</i>


title: PARAMETERS
content:
<b><b>-b</b> <i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Execute <i>COMMAND</i> after loading an image.</i><br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start in fullscreen mode.</i><br><br><b><b>-g</b> <i>GEOMETRY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set initial window position and size using X geometry string (e.g., "800x600+50+50").</i><br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Suppress status bar output.</i><br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Recurse into subdirectories when displaying image files.</i><br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start in thumbnail mode.</i><br><br><b><b>-z</b> <i>PERCENT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set initial zoom level to <i>PERCENT</i>.</i><br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Start in daemon mode. This allows other tools like <b>sxiv-thumbnail</b> to interact with a running <b>sxiv</b> instance.</i><br><br><b><b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>No normal window; implies <b>-D</b>. Useful for scripting.</i><br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print the absolute paths of selected files (in thumbnail mode) to standard output and exit.</i><br><br><b><b>-e</b> <i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Execute <i>COMMAND</i> on selected files (in thumbnail mode) before exiting. The selected file paths are passed as arguments to <i>COMMAND</i>.</i><br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print version information to standard output and exit.</i><br><br>


title: DESCRIPTION
content:
<i><b>sxiv</b> (simple X image viewer) is a lightweight and highly efficient image viewer for the X Window System. True to the suckless.org philosophy, it prioritizes minimalism, speed, and keyboard-driven interaction over feature bloat. It provides a clean, borderless display of images, supporting various popular formats through standard X libraries. Users familiar with Vim will find its navigation and command shortcuts intuitive, allowing for quick browsing, zooming, and rotation without ever touching a mouse. Its unique thumbnail mode facilitates easy directory navigation, and its extensibility via external scripts (through its daemon mode) makes it a powerful tool for custom workflows, despite its apparent simplicity. <b>sxiv</b> is ideal for users who value performance and a keyboard-centric workflow.</i>


title: CAVEATS
content:
<i><b>sxiv</b> is built for minimalism and efficiency, which means it consciously omits features found in more bloated image viewers. It lacks graphical menus, advanced image manipulation tools, or a plugin system beyond its external command execution. Its entirely keyboard-driven interface can present a steep learning curve for users unfamiliar with Vim-like keybindings. As an X application, it is not suitable for framebuffer-only environments (e.g., Linux console without X). Configuration is primarily done by editing its <b>config.h</b> source file and recompiling, which might be a barrier for some users.</i>


title: KEYBINDINGS
content:
<i><b>sxiv</b> is operated almost entirely via keyboard shortcuts, often inspired by Vim. Some common examples include:<br><b>h</b>, <b>j</b>, <b>k</b>, <b>l</b> (or arrow keys): Navigate left, down, up, right in thumbnail mode.<br><b>n</b>, <b>p</b>: Next and previous image.<br><b>+</b>, <b>-</b>: Zoom in/out.<br><b>r</b>: Rotate image clockwise.<br><b>f</b>: Toggle fullscreen.<br><b>q</b>: Quit.<br><b>g</b>: Go to the first image.<br><b>G</b>: Go to the last image.<br><b>t</b>: Toggle thumbnail mode.<br><b>m</b>: Mark/unmark image in thumbnail mode for selection.<br><b>d</b>: Delete current image.<br>A comprehensive list of keybindings can be found in the <b>sxiv</b> man page or its source code's <b>config.h</b>.</i>


title: SCRIPTING AND EXTERNAL COMMANDS
content:
<i>One of <b>sxiv</b>'s powerful features is its ability to integrate with external scripts. The <b>-o</b> and <b>-e</b> options allow users to select images in thumbnail mode and then output their paths or execute a custom command on them, respectively. Additionally, the daemon mode (<b>-D</b>) enables advanced use cases where an external script can control a running <b>sxiv</b> instance, for example, to display images from a shell script or manage image collections dynamically.</i>


title: HISTORY
content:
<i><b>sxiv</b> was created by Anselm R. Garbe, a prominent developer associated with the <a href="https://suckless.org">suckless.org</a> community. The suckless philosophy emphasizes simplicity, clarity, and frugality in software design, often resulting in small, fast, and secure programs that do one thing well. <b>sxiv</b> embodies this spirit, providing a no-frills, highly efficient image viewing experience. Its development has focused on maintaining a minimal codebase while offering robust core functionality, making it a popular choice among users who prefer a streamlined, Unix-like approach to their desktop tools.</i>


title: SYNOPSIS
content:
<b>symfony</b> [<i>global-options</i>] &lt;<i>command</i>&gt; [<i>command-options</i>] [<i>arguments</i>]<br><br>Examples:<br>  <b>symfony</b> <i>new</i> <i>my_project</i> --<i>version</i>=<i>6.4</i><br>  <b>symfony</b> <i>serve</i> -<i>d</i><br>  <b>symfony</b> <i>help</i> <i>serve</i>


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help for the given command. When no command is given, display help for the <br><i>list</i><br> command.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not output any message.<br><br><b>-v|vv|vvv, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase the verbosity of messages: 1 for normal output, 2 for more verbose output, and 3 for debug.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display this application version.<br><br><b>-n, --no-interaction</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ask any interactive question.<br><br><b>--env=<env></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The environment the command should run in (e.g., <br><i>dev</i><br>, <br><i>prod</i><br>).<br><br><b>--no-ansi</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disable ANSI output.<br><br>


title: DESCRIPTION
content:
The <b>symfony</b> command-line tool, often referred to as Symfony CLI, is the official, global tool for developing and managing Symfony applications. It provides a local web server with HTTPS support, seamless integration with SymfonyCloud, and various utilities to enhance developer productivity. Unlike the project-specific <br><b>bin/console</b><br> command, which handles framework-level tasks (like database migrations or cache clearing), the <b>symfony</b> CLI is a standalone binary. It's designed to streamline common development tasks such as creating new projects (<br><i>symfony new</i><br>), serving local sites securely (<br><i>symfony serve</i><br>), managing environments, and deploying applications directly to SymfonyCloud. Its primary goal is to offer a secure, high-performance local development environment and simplify the entire Symfony application lifecycle, from setup to deployment.


title: CAVEATS
content:
The <b>symfony</b> command requires PHP and Composer to be installed and properly configured on your system. It is not a standard Linux distribution package and is typically installed via Composer or direct download. Its full functionality is realized when used within the context of a Symfony project.


title: HISTORY
content:
The <b>symfony</b> CLI was introduced to offer a more integrated and user-friendly experience for Symfony developers, complementing the existing project-specific <br><b>bin/console</b><br> command. It was developed to address common pain points such as setting up a local web server with automatic HTTPS, simplifying project creation, and providing seamless integration with SymfonyCloud for deployment. Its evolution has been driven by the Symfony core team, adding features like first-class support for SymfonyCloud, local TLS certificate management, and various developer utilities, making it a central and indispensable tool in the Symfony ecosystem since its initial release around 2018.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a summary of command-line options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the Synaptic version information.<br><br><b><b>--display=&lt;display&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the X display to use for the graphical interface.<br><br><b><b>--config-file=&lt;file&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use an alternative configuration file instead of the default.<br><br><b><b>--no-scaled-pixmaps</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent scaling of pixmaps in the interface.<br><br><b><b>--hide-main-window</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Start Synaptic with its main window hidden.<br><br><b><b>--set-filter=&lt;filter_name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply a predefined filter on startup (e.g., 'Broken', 'New', 'Upgradable').<br><br><b><b>--set-mode=&lt;mode_name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial view mode (e.g., 'Sections', 'Status', 'Origin').<br><br><b><b>--filter-parameter=&lt;parameter&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide a parameter for the specified filter (e.g., a section name for 'Section' filter).<br><br><b><b>--select-package=&lt;package_name&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select and highlight a specific package in the package list upon startup.<br><br><b><b>--with-package-details</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Open Synaptic with the package details pane visible upon selection.<br><br><b><b>--non-interactive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress interactive dialogs, useful for scripting but limited for a GUI application.<br><br><b><b>--update-at-startup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically refresh the package lists from repositories when Synaptic launches.<br><br>


title: DESCRIPTION
content:
Synaptic is a <i>graphical user interface (GUI)</i> package management tool for Debian, Ubuntu, and other Debian-based Linux distributions. It provides a user-friendly interface to the <b>Advanced Package Tool (APT)</b> system, allowing users to easily install, remove, upgrade, and manage software packages.<br><br>It offers features like searching, filtering, and browsing packages by category, status, or origin. Synaptic helps visualize package dependencies, resolve conflicts, and apply system updates with a few clicks, making complex package management tasks accessible to users who prefer a graphical approach over the command line.


title: CAVEATS
content:
Synaptic requires <b>root privileges</b> (typically obtained via <i>sudo</i>) to perform most package management operations such as installing, removing, or upgrading software.<br><br>It is primarily a <i>graphical application</i>, and its command-line options are mainly used to control its initial state or view, rather than for performing headless package operations. It is designed specifically for <b>Debian-based systems</b> and is not compatible with other package management systems like RPM or Pacman.


title: <B>GRAPHICAL INTERFACE</B>
content:
Synaptic provides a complete graphical environment for managing software, offering visual cues, progress bars, and an easy-to-navigate layout that abstracts the complexities of command-line package management.


title: <B>DEPENDENCY RESOLUTION</B>
content:
It automatically handles package dependencies, ensuring that all necessary libraries and components are installed when a new package is selected, and warning about potential conflicts.


title: <B>REPOSITORIES MANAGEMENT</B>
content:
Synaptic allows users to easily add, remove, and enable software repositories (sources of packages), providing access to a wider range of software or specific versions.


title: <B>MARKING CHANGES</B>
content:
Users can 'mark' packages for installation, removal, or upgrade, and then apply all changes in one go, providing a clear overview of pending actions before execution.


title: HISTORY
content:
Synaptic was developed by <i>Alfredo Kojima</i> and <i>Michael Vogt</i>. It emerged as a user-friendly graphical front-end for <b>APT (Advanced Package Tool)</b>, the robust command-line package management system used by Debian and its derivatives. Its development aimed to provide an intuitive interface for users less comfortable with command-line operations, simplifying tasks like searching, installing, and removing software packages.<br><br>Synaptic quickly became a popular choice in Debian-based distributions, especially Ubuntu, where it served as the default graphical package manager for many years before the Ubuntu Software Center gained prominence. Despite newer alternatives, Synaptic remains a reliable and powerful tool, favored by many for its comprehensive features and control over the package system.


title: DESCRIPTION
content:
The <b>sync</b> command is used to ensure that all data held in the operating system's memory buffers, which represents modifications to files, is written out to the physical storage devices (disks).<br><br>Modern Unix-like operating systems employ sophisticated caching mechanisms to improve performance. When an application writes data to a file, it's often initially written to an in-memory buffer (known as a 'dirty page') rather than directly to disk. This allows the system to bundle writes, reorder them, and avoid frequent, slow disk I/O operations. While this improves responsiveness, it also means that in the event of an unexpected system crash, power loss, or ungraceful shutdown, data residing only in memory buffers would be lost.<br><br><b>sync</b> forces the kernel to write these 'dirty' buffers to their respective disk blocks, thus ensuring data integrity and consistency. It's particularly crucial before critical operations like unmounting a filesystem or performing a system reboot or shutdown, though most modern utilities (like <b>umount</b>, <b>reboot</b>, <b>shutdown</b>) automatically invoke <b>sync</b> beforehand.


title: CAVEATS
content:
While <b>sync</b> flushes buffers to the device driver, it does not guarantee that the data has been physically written to the platter or flash memory before the command returns. Modern disk drives often have their own internal caches. For absolute assurance, a storage device might need to implement a 'flush cache' command (e.g., via SCSI 'SYNCHRONIZE CACHE' or ATA 'FLUSH CACHE' commands), which the kernel generally handles. However, <b>sync</b> itself doesn't wait for this deeper level of write completion.<br><br>On some older or BSD-derived systems, <b>sync</b> might offer options like <b>-d</b> (sync data only) or <b>-f</b> (sync filesystems). However, the common GNU Coreutils version on Linux typically does not support these options and simply flushes all dirty buffers.


title: COMMAND VS. SYSTEM CALL
content:
The <b>sync</b> command is a user-space utility that typically invokes the <b>sync()</b> system call. The system call instructs the kernel to write all buffered filesystem data to disk. While the command provides a convenient way for users to trigger this action, the real work is performed by the kernel's internal mechanisms in response to the system call.


title: KERNEL BUFFERS AND DIRTY PAGES
content:
The data that <b>sync</b> flushes is often referred to as 'dirty' data or 'dirty pages' in the kernel's page cache. When an application writes to a file, the kernel marks the corresponding memory pages as 'dirty'. These dirty pages are then periodically written to disk by a kernel background process (e.g., 'pdflush' or newer writeback threads), but <b>sync</b> allows for an explicit, on-demand flush.


title: HISTORY
content:
The <b>sync</b> command, along with its underlying <b>sync(2)</b> system call, has been a fundamental part of Unix-like operating systems since their early days. It emerged as a necessary utility to manage the trade-off between performance (via buffered I/O) and data integrity. Its basic function has remained consistent for decades, providing a reliable way for users and system scripts to ensure that volatile buffered data is committed to non-volatile storage.


title: DESCRIPTION
content:
The term '<b>sync-available</b>' does not refer to a standard, universally recognized Linux command or utility shipped with common distributions. Unlike commands such as <b>ls</b>, <b>grep</b>, or <b>sync</b> (which flushes filesystem buffers), '<b>sync-available</b>' is not part of the GNU Core Utilities or other standard package sets.<br><br>It is highly probable that '<b>sync-available</b>' is either: <br><i><b>1.</b></i> A custom script or alias created by a system administrator or developer for a specific purpose, often related to checking the status of a synchronization process or the readiness of data for syncing.<br><i><b>2.</b></i> An internal status indicator or message within a particular application (e.g., a file synchronization service like Syncthing, a backup solution, or a distributed system) indicating that certain data or a synchronization operation is ready to proceed.<br><i><b>3.</b></i> A conceptual term used in documentation or discussions to describe a state where synchronization can occur.<br><br>Therefore, there is no generic synopsis, set of parameters, or documented history for '<b>sync-available</b>' across Linux systems. Users encountering this term should investigate the specific context in which it is used, such as reviewing custom scripts, application documentation, or consulting the system administrator who deployed it.


title: CAVEATS
content:
The functionality, existence, and any associated limitations of '<b>sync-available</b>' are entirely dependent on its specific implementation within a custom script, application, or environment. Its behavior is not predictable or consistent across different systems. Reliance on this term without understanding its specific context is ill-advised.


title: HISTORY
content:
<i>Not applicable.</i> '<b>sync-available</b>' is not a standard command with a documented development history. Its origin would be specific to the custom script or application in which it is used.


title: SYNOPSIS
content:
<b>synclient</b> [<i>options</i>] [<i>parameter</i>=<i>value</i> ...]<br><b>synclient</b> [<i>parameter</i>]


title: PARAMETERS
content:
<b><b>-l</b> or <b>--list</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Lists all current parameter values set for the Synaptics TouchPad driver. This provides an overview of the active configuration.</i><br><br><b><b>-V</b> or <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Prints the version number of the <b>synclient</b> utility.</i><br><br><b><b>-h</b> or <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays a brief help message, outlining the command's usage and available options.</i><br><br><b><i>parameter</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>When used without an assigned value, this queries and displays the current value of the specified touchpad parameter.</i><br><br><b><i>parameter</i>=<i>value</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets the specified touchpad parameter to the given new value. Multiple parameters can be set simultaneously on a single command line by separating them with spaces.</i><br><br>


title: DESCRIPTION
content:
<i><b>synclient</b> is a command-line utility used to query, modify, and display the current settings of the Synaptics TouchPad driver. It provides a granular level of control over various aspects of a touchpad's behavior, such as enabling/disabling tapping, adjusting scroll speeds, configuring palm detection, and setting edge motion. This tool directly interacts with the X server's input device properties. While primarily designed for the <b>xf86-input-synaptics</b> driver, many of its parameters still offer analogous functionality or are emulated when <b>libinput</b> is in use, making it relevant for fine-tuning touchpad behavior in Xorg environments. It is especially useful for scripting touchpad configurations or for users requiring control beyond graphical settings.</i>


title: CAVEATS
content:
<i><b>synclient</b> primarily functions within Xorg environments and is less relevant for Wayland. Changes made with <b>synclient</b> are typically temporary and are lost upon reboot or X server restart. Persistent configuration requires settings to be placed in Xorg configuration files (e.g., <b>/etc/X11/xorg.conf.d/</b>) or startup scripts. Its effectiveness depends on the <b>xf86-input-synaptics</b> driver being loaded, or <b>libinput</b> providing Synaptics emulation.</i>


title: PERSISTENT CONFIGURATION
content:
<i>To make <b>synclient</b> settings permanent across reboots, they must be saved in Xorg configuration files. Typically, this involves creating or modifying a file in <b>/etc/X11/xorg.conf.d/</b> (e.g., <b>50-synaptics.conf</b>) and adding an <b>'InputClass'</b> section with <b>'Option'</b> lines for desired parameters.</i>


title: COMMONLY ADJUSTED PARAMETERS
content:
<i>Users frequently adjust parameters such as <b>TapButton1</b>, <b>TapButton2</b>, <b>TapButton3</b> (for defining tap-to-click behavior for left, middle, right clicks), <b>VertScrollDelta</b> and <b>HorizScrollDelta</b> (to control scrolling speed), <b>PalmDetect</b> (to prevent accidental touches from palms), and <b>ClickPad</b> (for integrated button touchpads).</i>


title: HISTORY
content:
<i><b>synclient</b> emerged as a dedicated command-line tool alongside the development of the <b>xf86-input-synaptics</b> driver for Linux. It quickly became the go-to utility for users needing to deeply customize their Synaptics touchpads within Xorg. While its prominence has somewhat shifted with the rise of <b>libinput</b> and Wayland, it remains a valuable tool for many existing Xorg setups and specific configuration needs, reflecting its long-standing role in Linux input device management.</i>


title: PARAMETERS
content:
<b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the Syncthing version and exits.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message detailing available command-line options and exits.<br><br><b>--home=<dir></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the home directory where Syncthing stores its configuration, keys, and index data. Defaults to `~/.config/syncthing` on Linux.<br><br><b>--no-browser</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents Syncthing from automatically opening the web GUI in a browser upon startup. Useful when running as a service or headless.<br><br><b>--gui-address=<addr></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the address for the web GUI. For example, `127.0.0.1:8384` for local access or `0.0.0.0:8384` for access from other devices on the network. Can be overridden in the GUI itself.<br><br><b>--disable-gui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Completely disables the web GUI, allowing Syncthing to run purely in the background without any web interface.<br><br><b>--log-file=<file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes log output to the specified file instead of standard output.<br><br><b>--log-no-stdout</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses logging to standard output when `--log-file` is also specified.<br><br><b>--paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints paths to various Syncthing directories (config, data, etc.) and exits. Useful for debugging or setting up service files.<br><br>


title: DESCRIPTION
content:
The <b>syncthing</b> command starts the Syncthing daemon, a powerful open-source, peer-to-peer file synchronization application. It allows users to synchronize files between multiple devices in real-time without relying on a central cloud server. All data transfer is direct between your devices, encrypted with <i>TLS</i>, ensuring your data remains private and under your control. Syncthing is highly configurable, offering features like selective folder syncing, versioning of changes, conflict resolution, and support for various network topologies. It's designed to be robust against network failures and operates efficiently across different operating systems, making it a versatile tool for maintaining consistent data across your personal and professional devices. Its decentralized nature means there's no single point of failure or an external party that can access your files.


title: CAVEATS
content:
Initial indexing of large folders can be CPU and disk intensive.<br>Firewall configuration is essential; Syncthing typically uses TCP ports 22000 (for data transfer) and 21027 (for discovery) by default, which may need to be opened.<br>For global device discovery across different networks, UPnP or port forwarding may be required on your router.


title: WEB-BASED GUI
content:
Syncthing is primarily configured and monitored through a responsive web-based graphical user interface, usually accessible at <i>http://localhost:8384</i>. This GUI allows users to add and remove folders, manage connected devices, and monitor synchronization status.


title: DECENTRALIZED ARCHITECTURE
content:
Unlike services that rely on a central server, Syncthing operates on a <i>peer-to-peer (P2P)</i> model. Devices connect directly to each other to synchronize files, eliminating the need for intermediaries. This enhances privacy and reduces potential bottlenecks or points of failure inherent in centralized systems.


title: HISTORY
content:
Syncthing was initially created by <i>Jakob Borg</i> and first released in 2013. It was developed as an open-source alternative to proprietary cloud-based file synchronization services, with a strong emphasis on privacy, security, and decentralization. Its development has been community-driven, leading to a robust, cross-platform application widely adopted by users seeking greater control over their data.


title: PARAMETERS
content:
<b><i>-i &lt;idle_time&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the idle time in seconds</i> after keyboard activity ceases before the touchpad is re-enabled. The default is 2.0 seconds.<br><br><b><i>-k</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Ignores modifier keys</i> (Shift, Ctrl, Alt, etc.) when checking for keyboard activity. If only modifier keys are pressed, the touchpad is not disabled.<br><br><b><i>-d</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Starts syndaemon as a daemon</i>, detaching it from the terminal and running in the background.<br><br><b><i>-t</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Disables tapping and scrolling only</i>, leaving the pointer movement enabled. This allows for basic pointer control while still preventing accidental clicks or scrolls.<br><br><b><i>-R</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses the XRecord extension</i> to detect keyboard activity. This is the recommended and more robust method for event monitoring compared to polling the root window.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uses the root window</i> to detect keyboard activity. This option is generally <i>deprecated</i> in favor of <i>-R</i>.<br><br>


title: DESCRIPTION
content:
<i>syndaemon</i> is a utility designed to prevent accidental cursor movements when typing on a laptop. It achieves this by temporarily disabling the touchpad while keyboard input is detected. Once keyboard activity ceases for a specified idle period, the touchpad is automatically re-enabled. This daemon is particularly useful for users who find their palm or thumb accidentally brushing the touchpad, leading to unintended clicks or cursor jumps. It typically runs in the background, continuously monitoring input devices and toggling touchpad state as needed, enhancing the typing experience on portable devices. It runs as a background process, ensuring a smoother and more efficient typing experience by intelligently managing touchpad state based on user input.


title: CAVEATS
content:
<i>syndaemon</i> relies on the X Window System and the <i>xf86-input-synaptics</i> driver (or compatible) for touchpad control. It <i>may not work</i> with Wayland sessions or non-Synaptics touchpads without specific configurations. The <i>-r</i> option is <i>deprecated</i>; it's recommended to use <i>-R</i> for more reliable keyboard activity detection. Incorrect <i>idle_time</i> settings might lead to the touchpad being disabled for too long or re-enabling too quickly.


title: AUTOSTARTING SYNDAEMON
content:
To ensure <i>syndaemon</i> runs automatically upon session startup, it can be added to your desktop environment's autostart applications, an <i>~/.xinitrc</i> file, or a custom script in <i>~/.config/autostart/</i>. A common invocation is <b>syndaemon -i 2.0 -d -k -R</b>.


title: XRECORD DEPENDENCY
content:
The <i>-R</i> option requires the XRecord extension to be available and typically implies a dependency on <i>xorg-xinput</i> or similar packages on your system.


title: HISTORY
content:
<i>syndaemon</i> emerged as part of the <i>xf86-input-synaptics</i> driver suite, addressing a common usability issue on laptops where accidental touchpad activation occurred during typing. Its initial versions often relied on polling the X root window for keyboard events. A significant development was the introduction of the <i>-R</i> option, leveraging the XRecord extension for more efficient and reliable keyboard event monitoring, reflecting an evolution in how input events are handled within the X environment. It remains a standard tool for managing touchpad behavior during typing on Linux.


title: SYNOPSIS
content:
Given that "synopkg" is not a universally documented standalone command, its exact syntax can vary depending on the Synology SDK version or specific community tools. However, if it were a command-line utility for package building, a typical pattern might involve specifying the source directory, output location, and metadata.<br><br><I>synopkg build --source=<src_dir> --output=<out_dir> [options]</I><br><br><I>synopkg [command] [options] [arguments]</I><br><br>This representation is generalized, assuming a utility designed for building packages. Actual usage often involves <I>make</I> commands within the Synology SDK, which in turn might invoke internal scripts or tools.


title: PARAMETERS
content:
<b><I>build</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Subcommand to initiate the package creation process.<br><br><b><I>--source=<src_dir></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the directory containing the source files and package definition (e.g., <I>INFO</I> file, scripts) for the application.<br><br><b><I>--output=<out_dir></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the destination directory where the resulting <B>.spk</B> package file will be saved.<br><br><b><I>--version=<version_string></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specific version string for the package being built.<br><br><b><I>--arch=<architecture></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the target CPU architecture for the package (e.g., <I>x64</I>, <I>armv7</I>, <I>armada38x</I>).<br><br><b><I>--platform=<platform_string></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the Synology platform or model compatibility for the package.<br><br><b><I>--sign</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;If supported, digitally signs the package for verification.<br><br><b><I>--clean</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans up intermediate build files or temporary directories.<br><br>


title: DESCRIPTION
content:
The term "synopkg" typically refers to utilities or processes involved in creating <B>.spk</B> (Synology Package) files for Synology DiskStation Manager (DSM). Unlike standard Linux package managers like <I>apt</I> or <I>dnf</I>, <I>synopkg</I> is not a general-purpose command for installing or managing software on a typical Linux distribution. Instead, it's specific to the Synology ecosystem, primarily used by developers to package applications and services that can then be installed via the DSM Package Center on Synology NAS devices. It encapsulates an application's binaries, scripts, configuration, and metadata into a single distributable archive. The exact command or script named "synopkg" often exists within the Synology Package SDK (Software Development Kit) and is part of a larger build system for compiling and bundling software for DSM.


title: CAVEATS
content:
<I>synopkg</I> is <B>not a standard Linux command</B> found in most distributions' repositories (e.g., Ubuntu, Debian, Fedora). It is almost exclusively related to the <B>Synology DiskStation Manager (DSM) ecosystem</B> and its Software Development Kit (SDK). Users will not typically find a <I>man synopkg</I> page on a general Linux system. Its primary role is in <B>developing and packaging applications</B> for Synology NAS devices, not for general software installation or management on other Linux systems. The exact implementation and available options depend heavily on the specific Synology SDK version or third-party tools used for <B>.spk</B> package creation.


title: <B>ROLE IN SYNOLOGY ECOSYSTEM</B>
content:
<I>synopkg</I>'s function is purely focused on the <B>creation of .spk files</B>. These files are then uploaded and installed on Synology NAS devices via the <B>DSM Package Center</B>. The Package Center is the user-facing interface for managing installed applications, whereas <I>synopkg</I> operates at the developer/build level.


title: <B>AVAILABILITY AND USAGE</B>
content:
This utility or process is typically found within the <B>Synology Package SDK</B>, which developers download from Synology's website. It is used in a development environment (often a Linux-based one) to cross-compile and package applications for different Synology NAS architectures. It is not something an end-user would typically execute directly on their NAS or a general Linux desktop.


title: HISTORY
content:
The concept and tools referred to as <I>synopkg</I> have evolved alongside the <B>Synology DiskStation Manager (DSM)</B> and its increasing support for third-party applications. As Synology NAS devices gained popularity, the need for a structured way to develop and distribute applications (<B>.spk</B> packages) became critical. While a specific command <I>synopkg</I> might not have a long public history like <I>apt</I> or <I>rpm</I>, the underlying methods for creating <B>.spk</B> packages have been a part of the Synology Package SDKs for many years, enabling developers to extend DSM's functionalities. Its development is tied directly to Synology's efforts to provide a robust and secure platform for applications on its NAS devices.


title: SYNOPSIS
content:
<b>synoupgrade</b> [<i>-h</i>]<br><b>synoupgrade</b> [<i>-p &lt;.pat file&gt;</i>] [<i>--no-reboot</i>]<br><b>synoupgrade</b> [<i>--online</i> | <i>--online_download</i> | <i>--online_install</i>]


title: PARAMETERS
content:
<b><i>-h</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive help information and usage instructions for the command.<br><br><b><i>-p &lt;.pat file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the absolute path to a DiskStation Manager Patch (<i>.pat</i>) file. This option initiates a manual, offline firmware upgrade using the provided package.<br><br><b><i>--no-reboot</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the Synology NAS system from automatically rebooting immediately after a successful firmware update installation. This allows administrators to perform other tasks or manually control the reboot time.<br><br><b><i>--online</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks Synology's online servers for the availability of new DSM updates. This option typically does not download or install any updates.<br><br><b><i>--online_download</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Downloads available online DSM updates to the Synology device's local storage. The update will be prepared for installation but not automatically applied.<br><br><b><i>--online_install</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initiates the installation of previously downloaded or currently available online DSM updates. This command will proceed with the update process, which may include a system reboot.<br><br>


title: DESCRIPTION
content:
The <b>synoupgrade</b> command-line utility is an essential tool exclusive to Synology DiskStation Manager (DSM) devices, enabling the core operating system to be updated. It empowers administrators with precise control over the firmware upgrade process, serving as the underlying mechanism for both manual and automated DSM updates. Users can leverage <b>synoupgrade</b> to apply new DSM versions from a specified <i>.pat</i> file—Synology's proprietary firmware package—which is particularly useful for offline upgrades or specific version installations. Additionally, it supports managing online update workflows, including checking for, downloading, and initiating the installation of the latest DSM versions directly from Synology's servers. This command is crucial for maintaining the security, stability, and feature set of Synology NAS devices, offering a robust alternative or complement to the web-based update interface for advanced users, scripting, or troubleshooting scenarios.


title: CAVEATS
content:
<b>Synology Specific:</b> This command is proprietary and exclusive to Synology NAS devices running DiskStation Manager (DSM). It is not part of standard Linux distributions.<br><b>Root Privileges:</b> Execution of <b>synoupgrade</b> requires root privileges to ensure proper system access and modification rights.<br><b>Data Integrity Risk:</b> Incorrect usage or any interruption during the upgrade process can potentially lead to system corruption, data loss, or render the device inoperable. It is imperative to back up all critical data before initiating any major system upgrade.<br><b>Firmware Format:</b> The command exclusively handles <i>.pat</i> files, which are Synology's unique firmware packages, and will not accept other archive or installer formats.<br><b>Web UI Alternative:</b> For most users, performing DSM updates through the graphical web interface is recommended due to its guided process and built-in safety mechanisms.


title: USAGE CONTEXT
content:
<b>synoupgrade</b> is primarily executed via SSH or within shell scripts directly on the Synology NAS device. It operates at a lower level than the graphical DSM web interface, providing direct control over the update process.


title: DSM UPDATE ECOSYSTEM
content:
While <b>synoupgrade</b> performs the core upgrade operation, it is part of a larger ecosystem of Synology update tools. The DSM web interface, for instance, often leverages this command or similar utilities internally to manage automatic and manual system updates.


title: SECURITY CONSIDERATIONS
content:
Users must exercise extreme caution when using <b>synoupgrade</b>, particularly when providing a manual <i>.pat</i> file. Only official Synology firmware files should be used, downloaded directly from Synology's official website, to prevent system corruption, security vulnerabilities, or loss of data.


title: HISTORY
content:
The <b>synoupgrade</b> utility is an integral component of the Synology DiskStation Manager (DSM) operating system, developed internally by Synology Inc. Its evolution has mirrored that of DSM itself, serving as the foundational command-line interface for applying system-wide updates. While the DSM web interface offers a user-friendly front-end for updates, <b>synoupgrade</b> was designed to provide a more direct, granular control over the update process. It is frequently utilized in scripting environments, for automated deployments, or by advanced users requiring specific upgrade procedures such as offline installations from <i>.pat</i> files or detailed troubleshooting. Over time, its core functionality has remained robust and consistent, adapting to support new DSM versions and evolving update mechanisms.


title: SYNOPSIS
content:
<b>sysbench</b> [<I>global_options</I>] <I>--test=<test_name></I> [<I>test_options</I>] <I>command</I><br><br>Where <I>command</I> can be <b>prepare</b>, <b>run</b>, <b>cleanup</b>, <b>help</b>, <b>version</b>, or <b>list</b>.


title: PARAMETERS
content:
<b><b>--test=</b><i><test_name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the benchmark test to run (e.g., <b>cpu</b>, <b>fileio</b>, <b>memory</b>, <b>oltp_read_write</b>). This is a mandatory option.<br><br><b><b>--num-threads=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of worker threads to simulate concurrent load.<br><br><b><b>--time=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the total execution time limit for the benchmark in seconds.<br><br><b><b>--events=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the total number of events (transactions/operations) to execute before stopping.<br><br><b><b>--percentile=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Calculates the specified percentile (e.g., 95 for 95th percentile) for latency measurements.<br><br><b><b>--verbosity=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the verbosity level of output (0=quiet, 5=debug).<br><br><b><b>--report-interval=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a progress report every <i><N></i> seconds.<br><br><b><b>--validate</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables result validation for certain tests where applicable.<br><br><b><b>--mysql-host=</b><i><host></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MySQL database host. Similar options exist for PostgreSQL, Oracle, etc.<br><br><b><b>--mysql-port=</b><i><port></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the MySQL database port.<br><br><b><b>--oltp-table-size=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For OLTP tests) Sets the number of rows per table to be used in the benchmark database.<br><br><b><b>--oltp-tables-count=</b><i><N></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(For OLTP tests) Sets the number of tables to create for the benchmark database.<br><br>


title: DESCRIPTION
content:
<b>sysbench</b> is a powerful, highly configurable benchmark suite designed to evaluate the performance of various hardware and software components crucial for database-intensive workloads. It is cross-platform and supports multi-threading to simulate realistic concurrent usage. Key benchmarks include CPU performance, file I/O throughput, memory bandwidth, and thread scheduler efficiency. Crucially, <b>sysbench</b> excels at simulating complex database workloads, such as OLTP (Online Transaction Processing), point selects, and update/delete operations, against popular relational databases like MySQL, PostgreSQL, Oracle, and others via generic ODBC. This allows administrators and developers to assess how a system will perform under stress, identify bottlenecks, and optimize configurations for maximum efficiency. It's an indispensable tool for capacity planning, performance tuning, and regression testing in database environments.


title: CAVEATS
content:
Benchmarking results can be significantly influenced by system background processes, caching, and other environmental factors; therefore, it's crucial to ensure a consistent test environment and run multiple iterations for reliable data. For database benchmarks, <b>sysbench</b> requires a pre-configured database server and often specific Lua scripts (e.g., for OLTP workloads). The <b>prepare</b> command must be run to populate data before the <b>run</b> command. Performance in virtualized environments might differ from bare-metal systems, and careful interpretation of results is advised.


title: BENCHMARK TEST TYPES
content:
<b>sysbench</b> supports a variety of built-in benchmark tests, including: <br><ul><li><b>cpu</b>: Measures integer and floating-point arithmetic performance.</li><li><b>fileio</b>: Benchmarks disk I/O performance (sequential read/write, random read/write).</li><li><b>memory</b>: Tests memory transfer speeds (read/write operations).</li><li><b>threads</b>: Evaluates thread creation and context switching overhead.</li><li><b>oltp_*</b>: A suite of tests for simulating Online Transaction Processing (OLTP) workloads against databases (e.g., <b>oltp_read_write</b>, <b>oltp_point_select</b>, <b>oltp_update_index</b>). These tests are highly configurable via various <b>--oltp-*</b> options.</li></ul>


title: TYPICAL WORKFLOW
content:
For database benchmarks (e.g., OLTP), the typical <b>sysbench</b> workflow involves three main steps:<br><ul><li><b>prepare</b>: Creates and populates the necessary tables and data in the target database according to specified parameters (e.g., table size, number of tables).</li><li><b>run</b>: Executes the actual benchmark operations against the prepared data for a specified duration or number of events.</li><li><b>cleanup</b>: Removes the benchmark-created tables and data from the database.</li></ul><br>For other tests like <b>cpu</b>, <b>fileio</b>, or <b>memory</b>, only the <b>run</b> command is generally required.


title: HISTORY
content:
<b>sysbench</b> was initially developed by Alexey Kopytov and released as open-source under the GNU GPL. It quickly became a standard tool for evaluating the performance of systems running MySQL, later extending its capabilities to other popular relational databases like PostgreSQL and Oracle. Over its development history, <b>sysbench</b> has evolved significantly, adding modularity, support for complex OLTP workloads via Lua scripts, and enhanced reporting features, cementing its position as a versatile and widely-used benchmark utility in the database and system administration communities.


title: SYNOPSIS
content:
sysctl [options] [variable[=value]...]<br>sysctl -a<br>sysctl net.ipv4.ip_forward<br>sysctl net.ipv4.ip_forward=1


title: PARAMETERS
content:
<b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all currently available kernel parameters and their values.<br><br><b>-e, --pattern <I>pattern</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display all parameters matching the specified pattern. Wildcards like '*' can be used.<br><br><b>-w, --write</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable writing of sysctl values, even if the value contains a colon. Often implied when setting a value directly.<br><br><b>-p, --load</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Load parameters from default sysctl configuration files (e.g., <I>/etc/sysctl.conf</I> and files in <I>/etc/sysctl.d/</I>).<br><br><b>-r, --print-write</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only print parameters that are writable.<br><br><b>-n, --values</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print variable names, only print their values.<br><br><b>-N, --names</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print values, only print variable names.<br><br><b>-X, --deprecated</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include deprecated parameters in the listing output.<br><br><b>-q, --quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print errors about unknown keys.<br><br><b>-v, --version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a brief help message and exit.<br><br>


title: DESCRIPTION
content:
<b>sysctl</b> is a command-line utility used to view and modify kernel parameters at runtime on Linux systems. These parameters reside in the virtual <I>/proc/sys</I> filesystem and control various aspects of the kernel's behavior, including network stack settings, virtual memory management, security features, and general system performance. System administrators frequently use <I>sysctl</I> to fine-tune a system's operation without needing to reboot or recompile the kernel. It offers a convenient interface to list all available parameters, query the current value of a specific parameter, or set a new value for a writable parameter. Changes made interactively with <I>sysctl</I> are temporary and will not persist across system reboots. For permanent modifications, parameters must be configured in files like <I>/etc/sysctl.conf</I> or within the <I>/etc/sysctl.d/</I> directory, which are loaded automatically during system startup.


title: CAVEATS
content:
Changes made with <I>sysctl</I> directly on the command line are not persistent across reboots unless explicitly saved in configuration files like <I>/etc/sysctl.conf</I> or those in <I>/etc/sysctl.d/</I>.<br>Incorrectly modifying kernel parameters can lead to system instability, performance degradation, or introduce security vulnerabilities. Always understand the implications of a parameter before changing its value.<br>Some parameters are read-only or require root privileges to modify.


title: CONFIGURATION FILES
content:
For persistent changes, kernel parameters should be configured in <I>/etc/sysctl.conf</I> or in separate <I>.conf</I> files placed in the <I>/etc/sysctl.d/</I> directory. These files are typically loaded automatically at boot time by system initialization scripts or services (e.g., <I>systemd-sysctl.service</I>).


title: /PROC/SYS FILESYSTEM
content:
<I>sysctl</I> directly interacts with the pseudo-filesystem <I>/proc/sys</I>. Each kernel parameter corresponds to a file within this directory structure (e.g., <I>net.ipv4.ip_forward</I> maps to <I>/proc/sys/net/ipv4/ip_forward</I>). Reading from or writing to these files manually via commands like <I>cat</I> or <I>echo</I> has the same effect as using the <I>sysctl</I> command.


title: HISTORY
content:
The ability to dynamically adjust kernel behavior is a long-standing feature in Unix-like operating systems. On Linux, <I>sysctl</I> serves as the primary user-space interface for interacting with kernel parameters exposed through the <I>/proc/sys</I> filesystem, which became a standard way to manage these tunable settings. Its development focused on providing system administrators with a consistent and easy-to-use tool to inspect and modify kernel states without requiring a system restart, significantly enhancing system flexibility and manageability.


title: SYNOPSIS
content:
<b>sysdig</b> [<i>options</i>] [<i>filter</i>]<br><b>sysdig</b> -c <<i>chisel_name</i>> [<i>chisel_args</i>] [<i>filter</i>]


title: PARAMETERS
content:
<b>-A <count></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dump <I>count</I> events and then exit.<br><br><b>-c <chisel_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run a specific <I>chisel</I> (Lua script) to analyze captured data.<br><br><b>-D</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Detach from the terminal and run <i>sysdig</i> in the background.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all available <I>chisels</I>.<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty print the output, often in JSON format for easier parsing.<br><br><b>-r <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read events from a previously saved <I>sysdig</I> capture <I>file</I>.<br><br><b>-S</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print system statistics every second (e.g., CPU, memory, I/O).<br><br><b>-s <seconds></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sleep for <I>seconds</I> after starting, useful for giving the system time to stabilize before capturing.<br><br><b>-w <file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write captured events to a <I>file</I> for later offline analysis.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of output, providing more detailed information.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help information and exit.<br><br>


title: DESCRIPTION
content:
<i>sysdig</i> is an open-source tool for deep system visibility and troubleshooting on Linux. It captures system state and activity from a running Linux instance by leveraging a kernel module or eBPF probes to intercept system calls and kernel events. Think of it as a powerful combination of <i>strace</i>, <i>tcpdump</i>, <i>lsof</i>, <i>top</i>, and <i>netstat</i>, but with advanced filtering, aggregation, and analysis capabilities.<br><br>Users can observe process activity, network connections, file I/O, and other system-wide events in real-time. <i>sysdig</i> allows for rich filtering of events using a powerful syntax, enabling users to focus on specific processes, network activity, or file operations. It also supports "chisels," which are Lua scripts providing higher-level, pre-built views and analysis of the captured data. Beyond real-time monitoring, <i>sysdig</i> can save captured events to a file for later offline analysis, making it invaluable for post-mortem forensics, performance troubleshooting, and security incident response in both traditional and containerized environments.


title: CAVEATS
content:
Requires root privileges or appropriate capabilities (e.g., <I>CAP_SYS_ADMIN</I>) to run due to its deep kernel interaction.<br>Installation typically involves a kernel module or eBPF, which may require compilation against specific kernel headers, potentially leading to compatibility issues across different kernel versions.<br>While generally low, there can be a performance overhead, especially under heavy system load or with very broad filters, as it intercepts every system call.<br>The powerful filtering language and <I>chisels</I> have a learning curve, requiring users to understand system call semantics and <i>sysdig</i>'s event model.


title: CHISELS
content:
<b>Chisels</b> are powerful Lua scripts that provide pre-built, high-level views and analysis of the raw system event stream. They transform low-level syscall data into actionable insights, such as "top processes by network I/O," "connections per process," or "files opened by a specific user." Users can also create custom <I>chisels</I> to tailor analysis to their specific needs, extending <i>sysdig</i>'s functionality.


title: FILTERING LANGUAGE
content:
<i>sysdig</i>'s powerful filtering language allows users to precisely specify which events to capture and display. Filters can be applied based on process properties (<I>proc.name</I>, <I>proc.pid</I>), file descriptors (<I>fd.name</I>, <I>fd.type</I>), event types (<I>evt.type</I>), and many more attributes. This enables highly granular observation, such as <I>"sysdig proc.name=nginx and evt.type=open"</I> to see all file open events specifically by the Nginx process. Filters support logical operators (AND, OR) and comparisons.


title: ARCHITECTURE
content:
At its core, <i>sysdig</i> operates by inserting a kernel module or leveraging eBPF probes into the Linux kernel. This allows it to capture system calls, context switches, and other kernel events at a very low level without modifying applications. The collected data is then streamed to user space where <i>sysdig</i> applies filters, processes it with <I>chisels</I>, and presents it to the user. This approach provides unparalleled depth and detail in system monitoring by observing the system from the kernel's perspective.


title: HISTORY
content:
<i>sysdig</i> was created by Loris Degioanni, who is also known for co-creating <i>Wireshark</i> and <i>nmap</i>. It was initially developed by Sysdig Inc. and open-sourced in 2014, quickly gaining traction in the DevOps and security communities. Its design aimed to provide unified observability for Linux systems, addressing the complexities of monitoring modern, distributed, and containerized applications. Over time, it evolved to support eBPF, reducing its reliance on a kernel module and improving compatibility and performance. It has become a foundational tool in the cloud-native security and observability stack.


title: PARAMETERS
content:
<b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install SYSLINUX boot sector.</i> Installs the SYSLINUX boot sector on a FAT filesystem. This is the most common use of the command to make a partition bootable.<br><br><b><b>-U</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Uninstall SYSLINUX boot sector.</i> Removes the SYSLINUX boot sector from a FAT filesystem, effectively making it non-bootable by SYSLINUX.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force operation.</i> Forces the installation even if the filesystem type is not recognized or the device appears to be in use. Use with extreme caution as it can lead to data loss.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Safe mode (deprecated for -i).</i> Installs the boot sector without touching the Master Boot Record (MBR). This option is largely superseded by <b>-i</b>.<br><br><b><b>-d</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify boot directory.</i> Specifies the directory on the target device where the <i>ldlinux.sys</i> file is expected to be found.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verbose output.</i> Provides more detailed information and progress messages during the installation process.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Quiet output.</i> Suppresses most output during the installation process, useful for scripting.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set active partition (MBR).</i> Marks the target partition as active in the Master Boot Record, a prerequisite for booting on some legacy systems.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install MBR (Master Boot Record).</i> Installs a generic MBR that chains to the SYSLINUX boot sector on the specified partition. Often used in conjunction with <b>-i</b>.<br><br><b><b>-e</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Install on Ext2/3/4 filesystem.</i> Installs the SYSLINUX (specifically EXTLINUX) boot sector on an Ext2, Ext3, or Ext4 filesystem, suitable for Linux installations.<br><br>


title: DESCRIPTION
content:
The <b>syslinux</b> command is a crucial utility within the SYSLINUX bootloader suite, primarily used to install the SYSLINUX boot sector onto a specified device, typically a floppy disk, USB drive, or a hard disk partition. SYSLINUX itself is a collection of lightweight bootloaders designed for various media, including FAT filesystems (like those found on USB sticks), Ext2/3/4 filesystems, CD/DVDs (ISOLINUX), and network booting (PXELINUX).<br><br>When invoked, <b>syslinux</b> writes the necessary boot code to the target device's boot sector, making it bootable. It prepares the partition to load the core SYSLINUX file, <i>ldlinux.sys</i>, which must also be present on the filesystem. This command does not typically copy the <i>ldlinux.sys</i> file itself or the configuration file (<i>syslinux.cfg</i>); these usually need to be copied manually or by another script after the boot sector installation. It is widely used for creating bootable live Linux distributions, rescue disks, and for scenarios requiring a simple and robust legacy BIOS bootloader.


title: CAVEATS
content:
Incorrect usage of <b>syslinux</b> can lead to severe data loss or an unbootable system. Always double-check the target <i>device</i> path before execution. This command primarily targets legacy BIOS booting environments; for UEFI systems, other bootloaders like GRUB2 or SYSLINUX's EFI components (installed differently) are generally preferred. Ensure the target filesystem is correctly formatted (e.g., FAT for traditional SYSLINUX, Ext for EXTLINUX) and accessible before attempting installation.


title: COMMON USAGE PATTERN
content:
To make a USB drive partition bootable with SYSLINUX, a common sequence involves first formatting the partition (e.g., <b>mkfs.fat /dev/sdb1</b>), then running <b>syslinux /dev/sdb1</b> (or <b>syslinux -i /dev/sdb1</b>). After this, the <i>ldlinux.sys</i> file and a configuration file (typically <i>syslinux.cfg</i>) must be manually copied to the root of the formatted partition for SYSLINUX to function correctly.


title: CONFIGURATION FILE
content:
SYSLINUX's behavior is dictated by a plain-text configuration file, most commonly named <i>syslinux.cfg</i> (or <i>extlinux.conf</i> for Ext filesystems). This file, located in the boot medium's root directory or a specified subdirectory, defines boot menu entries, default kernel and initramfs paths, boot parameters, and timeout settings. Without this file, SYSLINUX will not know what to boot.


title: HISTORY
content:
The SYSLINUX project, including the <b>syslinux</b> utility, was initiated by H. Peter Anvin. It began as a simple, small bootloader for floppy disks and quickly expanded to support various boot media. Its design philosophy emphasizes simplicity and minimalism, making it a popular choice for embedded systems, live Linux distributions, and rescue environments. Over time, it evolved to include ISOLINUX (for CD/DVDs), PXELINUX (for network booting), and EXTLINUX (for Ext2/3/4 filesystems), all under the SYSLINUX umbrella. The <b>syslinux</b> command remains a core component for installing the boot sector for these different variants, though its primary focus is on FAT and now Ext filesystems. While UEFI has gained prominence, SYSLINUX continues to be a vital tool for legacy BIOS compatibility and specialized boot scenarios.


title: SEE ALSO
content:
extlinux(1), isohybrid(1), pxelinux(1), memdisk(1), grub-install(8), dd(1), fdisk(8), parted(8), mkfs.fat(8)


title: PARAMETERS
content:
<b><b>-s</b>, <b>--safe</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only install if no valid SYSLINUX boot sector is found. Prevents accidental overwrites.<br><br><b><b>-f</b>, <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force installation, overwriting any existing boot sector. Use with caution.<br><br><b><b>-r</b>, <b>--root</b> <i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the root directory of the SYSLINUX installation.<br><br><b><b>-d</b>, <b>--directory</b> <i>DIRECTORY</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Look for <i>ldlinux.sys</i> in this directory on the target filesystem.<br><br><b><b>-m</b>, <b>--mbr</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Install SYSLINUX into the Master Boot Record (MBR) of the device, making the entire disk bootable.<br><br><b><b>-o</b>, <b>--offset</b> <i>SECTOR</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When installing to MBR, specify the MBR offset in sectors (typically 0).<br><br><b><b>-C</b>, <b>--check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a check of the boot sector without writing anything.<br><br><b><b>-i</b>, <b>--install</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly indicates an install operation (default).<br><br><b><b>-U</b>, <b>--uninstall</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uninstall SYSLINUX from the boot sector, restoring the original boot sector if possible.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the installation process.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b><b>-V</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b><i>DEVICE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The target device (e.g., <i>/dev/sda1</i>, <i>/dev/sdb</i>, <i>/dev/fd0</i>) where SYSLINUX should be installed.<br><br>


title: DESCRIPTION
content:
<i>syslinux-legacy</i> is a utility from the SYSLINUX project used to install the SYSLINUX bootloader on various storage devices. Its primary function is to write the necessary boot sector code to either the Master Boot Record (MBR) of a hard disk or the Volume Boot Record (VBR) of a specific partition. This makes the device bootable using SYSLINUX. As the name suggests, this command refers to the older, more direct installation method, contrasting with potentially newer or more abstract installation methods found in later SYSLINUX versions. <br><br>The command prepares the target device (e.g., a floppy disk, USB drive, or hard drive partition) to load the <i>ldlinux.sys</i> file, which must be present on the filesystem of the target device. <i>syslinux-legacy</i> handles the low-level writing of the boot sector, making it an essential tool for setting up minimalistic and efficient boot environments for Linux or other operating systems, particularly on older BIOS-based systems. It is often used for creating live USBs, rescue disks, or simple embedded systems.


title: CAVEATS
content:
Incorrect usage of <i>syslinux-legacy</i> can render a disk or partition unbootable. Always double-check the target <i>DEVICE</i>.<br><br>This command primarily targets BIOS-based systems and FAT filesystems. While SYSLINUX itself supports other filesystems (like Ext2/3/4 via EXTLINUX) and boot methods (PXE, ISO), <i>syslinux-legacy</i>'s direct boot sector installation is most robust for FAT.<br><br>The <i>ldlinux.sys</i> file (and potentially <i>syslinux.cfg</i>) must be present and correctly located on the target filesystem for SYSLINUX to function after installation.<br><br>Being "legacy," it might not receive as much active development or support as the main SYSLINUX tools.


title: THE <I>LDLINUX.SYS</I> FILE
content:
For SYSLINUX to function correctly, the <i>ldlinux.sys</i> file, which contains the core bootloader stages and modules, must reside in the root directory (or a specified directory) of the filesystem on the target device. <i>syslinux-legacy</i> writes a small boot sector that points to and loads this file, making its presence crucial for a successful boot.


title: THE <I>SYSLINUX.CFG</I> CONFIGURATION FILE
content:
After <i>syslinux-legacy</i> installs the boot sector, SYSLINUX relies on a configuration file, typically named <i>syslinux.cfg</i> (or <i>extlinux.conf</i> for Ext filesystems), located in the root or a specified directory of the boot device. This file defines the boot menu entries, kernel parameters, timeout, and other boot-time options. Without a valid configuration file, SYSLINUX may fail to present a boot menu or load an operating system.


title: HISTORY
content:
The SYSLINUX project, initiated by H. Peter Anvin, began in the mid-1990s as a lightweight bootloader primarily for floppy disks. <i>syslinux-legacy</i> represents the original, direct method of installing the SYSLINUX boot sector. Over time, as boot environments diversified (e.g., Ext filesystems, PXE, ISOs, and later UEFI), the SYSLINUX project expanded into <i>EXTLINUX</i>, <i>ISOLINUX</i>, and <i>PXELINUX</i>, and the main <i>syslinux</i> command evolved to handle these various targets. The <i>syslinux-legacy</i> designation typically indicates a package or executable that preserves the original, simpler, direct-to-sector installation mechanism, often for compatibility with older systems or specific use cases where the more generalized <i>syslinux</i> command might have different behaviors or dependencies. Its continued existence ensures that the foundational SYSLINUX boot sector installation method remains available.


title: SYNOPSIS
content:
<b>syslinux2ansi</b> [<i>-n</i>] [<i>-c</i>] [<i>-m MAX_ENTRIES</i>] [<i>-u</i>] [<i>-w WIDTH</i>] [<i>FILE...</i>]


title: PARAMETERS
content:
<b><b>-n</b>, <b>--no-colors</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables ANSI color escape sequences, resulting in plain text output.<br><br><b><b>-c</b>, <b>--compact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables a compact output mode, reducing vertical spacing between menu entries.<br><br><b><b>-m</b> <i>MAX_ENTRIES</i>, <b>--max-entries</b> <i>MAX_ENTRIES</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Limits the number of menu entries displayed in the output.<br><br><b><b>-u</b>, <b>--unicode</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables Unicode support, attempting to render Unicode characters correctly if the terminal supports them.<br><br><b><b>-w</b> <i>WIDTH</i>, <b>--width</b> <i>WIDTH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the maximum line width for the output, wrapping lines that exceed this width.<br><br><b><i>FILE...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more SYSLINUX or ISOLINUX configuration files to be processed. If no files are specified, input is read from standard input.<br><br>


title: DESCRIPTION
content:
syslinux2ansi is a utility designed to convert SYSLINUX and ISOLINUX menu configuration files into standard ANSI escape sequences. This conversion makes the boot menus displayable on a wider range of terminals and consoles that do not natively support the more advanced, pseudo-graphical rendering of SYSLINUX. This is particularly crucial for environments such as serial consoles, embedded systems, or virtual machine setups where only basic text mode is available.<br><br>The command parses the specified SYSLINUX or ISOLINUX configuration files, extracting essential information like menu labels, descriptions, and associated commands for each entry. It then applies ANSI formatting, including colors, bold text, and other attributes, either based on the SYSLINUX configuration's definitions or default ANSI styles. By providing a fallback, text-based, yet visually formatted menu, syslinux2ansi ensures that users can still navigate and interact with the boot options even in constrained display environments, enhancing compatibility and accessibility for SYSLINUX/ISOLINUX-based boot media.


title: CAVEATS
content:
This utility primarily targets simple SYSLINUX menu structures. Complex features such as chained menus, included configurations, or advanced graphical modes might not be fully translated or may result in incomplete representations. It focuses on rendering the textual content and basic formatting of menus.


title: INPUT AND OUTPUT
content:
The command can process one or more SYSLINUX/ISOLINUX configuration files specified as arguments. If no files are provided, it reads from standard input. The output consists of standard ANSI escape sequences, ensuring compatibility with most modern terminal emulators and serial consoles.


title: HISTORY
content:
SYSLINUX is an open-source bootloader suite, initially developed by H. Peter Anvin. The <b>syslinux2ansi</b> utility emerged as part of this project to address compatibility challenges in diverse booting environments. As SYSLINUX gained popularity for creating bootable media (CDs, DVDs, USB drives) for Linux, the need arose to ensure its menu interface was accessible across all console types, especially those without advanced graphics capabilities like serial consoles or basic text-mode virtual machines. <b>syslinux2ansi</b> specifically fulfills this role by providing a text-based, ANSI-formatted representation of the menu, allowing for robust and universally readable boot menus, which is critical for headless servers and remote management. Its development aligns with the broader goal of making SYSLINUX versatile and reliable in various deployment scenarios.


title: PARAMETERS
content:
<b>-b, --boot[=ID]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;View messages from a specific boot. Can use a numerical offset (e.g., -b -1 for previous boot) or a specific boot ID.<br><br><b>-k, --dmesg</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only kernel messages, equivalent to filtering by priority 'err' to 'emerg' and origin kernel.<br><br><b>-u, --unit=UNIT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show messages from a specific systemd unit (service). For example, journalctl -u sshd.<br><br><b>-p, --priority=PRIORITY</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter messages by priority or a range of priorities (e.g., 'err', 'warning', 'info' or numbers 0-7).<br><br><b>--since=DATE, --until=DATE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter logs by a specific time range. Dates can be 'YYYY-MM-DD HH:MM:SS', 'yesterday', 'now -1 hour', etc.<br><br><b>-f, --follow</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display new messages as they are written, similar to 'tail -f'.<br><br><b>-o, --output=FORMAT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control the output format. Common formats include 'short' (default), 'short-iso', 'verbose', 'json', 'json-pretty', 'cat'.<br><br><b>_PID=PID</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter messages by the process ID.<br><br><b>_COMM=NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter messages by the command name of the process.<br><br><b>_EXE=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter messages by the absolute path of the executable.<br><br><b>--list-boots</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all recorded boots with their IDs and timestamps.<br><br><b>--disk-usage</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the current disk usage taken by the journal files.<br><br><b>--vacuum-size=SIZE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reduce journal file size by removing oldest archived files until the total size is below SIZE (e.g., '1G').<br><br><b>--vacuum-time=TIME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reduce journal file size by removing oldest archived files older than TIME (e.g., '2weeks').<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager, useful for scripting or when output is small.<br><br>


title: DESCRIPTION
content:
While "syslog" typically refers to a standard for message logging or the traditional daemon (like <i>syslogd</i>, <i>rsyslogd</i>, or <i>syslog-ng</i>) that implements it, there isn't a single executable command named "syslog" itself for viewing logs.<br>On modern Linux distributions utilizing <i>systemd</i>, the primary command for querying and displaying system logs is <b><i>journalctl</i></b>. It interacts with the <i>systemd</i> journal, which unifies and stores various log messages, including those traditionally handled by <i>syslog</i> daemons, kernel messages (like from <i>dmesg</i>), and application-specific logs.<br><i>journalctl</i> offers powerful filtering, paging, and formatting options, making it an essential tool for examining system events, errors, and informational messages in a structured and efficient manner. It represents a more advanced approach to log management compared to direct parsing of plain text <i>syslog</i> files.


title: CAVEATS
content:
<i>journalctl</i> requires <i>systemd</i> to be running and managing the system logs; it is not available on Linux distributions using other init systems. The journal files are stored in a binary format, meaning they cannot be directly read or easily parsed with standard text utilities like <i>grep</i> or <i>cat</i> without <i>journalctl</i>. Proper management of journal file sizes (e.g., using <i>--vacuum-size</i>) is important to prevent excessive disk space consumption.


title: JOURNAL STORAGE AND VOLATILITY
content:
The <i>systemd</i> journal can store logs persistently (typically in <i>/var/log/journal/</i>) across reboots, or only in memory (volatile storage, in <i>/run/log/journal/</i>), which means logs are lost after a reboot. Persistent storage is the default and recommended configuration on most distributions.


title: BOOT IDS AND NAVIGATION
content:
<i>journalctl</i> assigns unique IDs to each system boot. This feature allows users to easily navigate and filter logs across different system reboots, providing a clear historical view, which is a significant improvement over traditional log management.


title: HISTORY
content:
<b><i>journalctl</i></b> was introduced as part of the <i>systemd</i> project, which began development around 2010. Its aim was to modernize and centralize Linux's logging infrastructure, moving beyond the limitations of traditional text-based <i>syslog</i> files. It became the primary log viewing utility on distributions adopting <i>systemd</i> as their init system, starting roughly from 2012-2015, fundamentally changing how system administrators and users interact with logs on these systems.


title: PARAMETERS
content:
<b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Debug mode</b></i>.<br>Runs the daemon in the foreground and prints debug messages to standard output. Useful for troubleshooting configuration.<br><br><b>-f <i>configfile</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Configuration file</b></i>.<br>Specifies an alternative configuration file to use instead of the default, which is usually <i>/etc/syslog.conf</i>.<br><br><b>-m <i>interval</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Mark interval</b></i>.<br>Sets the number of minutes between Mark messages. These messages are logged at <i>LOG_INFO</i> priority to show that the syslog daemon is still alive. Default is 20 minutes.<br><br><b>-p <i>socket</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Socket path</b></i>.<br>Specifies an alternate path for the UNIX domain socket that <i>syslogd</i> listens on for local messages. Default is usually <i>/dev/log</i>.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Receive remote messages</b></i>.<br>Enables receiving log messages from remote hosts via UDP port 514. This option is often disabled by default for security reasons.<br><br><b>-s <i>domains</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>DNS lookup exclusion</b></i>.<br>Specifies a comma-separated list of domain names for which <i>syslogd</i> will not perform DNS lookups when processing remote messages. This can speed up processing and prevent DNS-related issues.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i><b>Version information</b></i>.<br>Prints the version of <i>syslogd</i> and exits.<br><br>


title: DESCRIPTION
content:
<i>syslogd</i> is the traditional Unix and Linux system logging daemon. Its primary function is to collect log messages generated by various system processes, applications, and kernel components. It operates by listening for log messages on a UNIX domain socket (typically <i>/dev/log</i>) and optionally on a UDP port (port 514) for remote messages. Based on rules defined in its configuration file (historically <i>/etc/syslog.conf</i>), <i>syslogd</i> filters these messages by facility (e.g., <i>mail</i>, <i>kern</i>, <i>auth</i>) and priority (e.g., <i>info</i>, <i>warning</i>, <i>crit</i>). It then directs them to specified destinations, which can include local log files (like <i>/var/log/messages</i>, <i>/var/log/auth.log</i>), the console, user terminals, or even other remote syslog servers. While foundational, <i>syslogd</i> has largely been superseded by more advanced and feature-rich logging systems like <i>rsyslogd</i> and <i>syslog-ng</i> in modern Linux distributions.


title: CAVEATS
content:
<i><b>Obsolete in Modern Distributions</b></i>:<br>The traditional <i>syslogd</i> has been largely replaced by more robust and feature-rich alternatives like <i>rsyslogd</i> and <i>syslog-ng</i> in most contemporary Linux distributions. These newer daemons offer better performance, security features (e.g., TLS encryption), and more flexible configuration options.<br><br><i><b>Security Concerns</b></i>:<br>The original <i>syslogd</i>, especially when configured to receive remote messages without encryption, is susceptible to spoofing and tampering of log data, as messages are typically sent over UDP in plain text.<br><br><i><b>Limited Features</b></i>:<br>It lacks advanced features present in newer log managers, such as message queuing, database integration, or complex filtering rules beyond basic facility/priority.


title: CONFIGURATION FILE
content:
The primary configuration for <i>syslogd</i> is found in <i>/etc/syslog.conf</i>. This file defines "selectors" (combinations of facilities and priorities) and "actions" (where messages matching the selector should be sent).


title: LOG DESTINATIONS
content:
<i>syslogd</i> can direct logs to various destinations:<br>&#x2022; Local files (e.g., <i>/var/log/messages</i>, <i>/var/log/mail.log</i>)<br>&#x2022; Named pipes<br>&#x2022; User terminals or consoles<br>&#x2022; Remote syslog servers<br>&#x2022; Executing programs (less common with traditional <i>syslogd</i>)


title: HISTORY
content:
The <i>syslogd</i> daemon originated in the early days of Unix and was a fundamental component for centralized logging. It was introduced as part of the Berkeley Software Distribution (BSD) to standardize how system and application messages were recorded. Its configuration file format, based on facilities and priorities, became a de-facto standard. Over time, as systems grew more complex and security concerns increased, the limitations of the original <i>syslogd</i> became apparent. This led to the development of more advanced logging solutions like <i>syslog-ng</i> (System Logger Next Generation) and <i>rsyslogd</i> (Rocket-fast SYStem LOGger), which aimed to address performance, security, and flexibility shortcomings. While the concept of syslog remains, the specific <i>syslogd</i> implementation has been largely superseded.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits, showing available command-line options.<br><br><b><b>--host</b> <i>HOST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the CUPS server hostname or IP address to connect to, instead of the local server.<br><br><b><b>--port</b> <i>PORT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the port number to use when connecting to the CUPS server (default is 631).<br><br><b><b>--dialog</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the main printer configuration dialog to open. This is often the default behavior when run from a desktop environment menu.<br><br><b><b>--install-driver</b> <i>DRIVER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to install a specified printer driver. Requires the driver name as an argument.<br><br><b><b>--default-printer</b> <i>PRINTER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specified printer as the system's default printer.<br><br>


title: DESCRIPTION
content:
<i>system-config-printer</i> is a graphical user interface (GUI) tool designed to simplify the management and configuration of printers on Linux systems that utilize the Common Unix Printing System (CUPS).<br><br>It provides an intuitive way for users to add, remove, and modify printer settings, as well as manage print jobs. This utility abstracts the complexities of direct CUPS configuration, offering a user-friendly interface for tasks such as setting up network printers (including IPP, Samba, and LPD), local USB printers, and configuring printer drivers.<br><br>It's commonly found in Red Hat-based distributions like Fedora and CentOS, and is also widely available on Debian/Ubuntu systems, serving as a primary tool for desktop printer administration.


title: CAVEATS
content:
<b>Caveats:</b><br>1. Requires the Common Unix Printing System (CUPS) to be installed and running on the system.<br>2. Most configuration changes, such as adding or removing printers, require administrative (root) privileges.<br>3. Primarily a graphical application; while it has command-line options, its core functionality is accessed through its GUI.<br>4. Its exact appearance and some minor features might vary slightly across different Linux distributions and versions.


title: GUI FIRST
content:
While <i>system-config-printer</i> offers various command-line options for specific tasks, its primary and most common usage is as a graphical application for interactive printer configuration. Users typically launch it from their desktop environment's system settings or applications menu.


title: UNDERLYING SYSTEM
content:
All configurations made through <i>system-config-printer</i> are ultimately managed by the CUPS daemon. Therefore, understanding basic CUPS concepts and configurations (like those in /etc/cups/) can be helpful for advanced troubleshooting or specific use cases not covered by the GUI.


title: HISTORY
content:
<i>system-config-printer</i> was developed primarily for Red Hat-based systems to provide a user-friendly graphical interface for printer management, complementing the underlying CUPS system. It emerged as a robust tool to simplify printer setup and configuration for desktop users, integrating well with desktop environments like GNOME.<br><br>Its development is closely tied to the evolution of CUPS and the ongoing need for more accessible printer administration on Linux desktops, moving away from purely command-line or less intuitive tools. It has since been widely adopted by various distributions due to its reliability and ease of use in managing printing resources.


title: PARAMETERS
content:
<b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits, detailing command-line options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the program's version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>system-config-printer-applet</b> command launches a small graphical utility designed to reside in the system tray or notification area of a desktop environment. Its primary purpose is to provide quick and convenient access to printer status and configuration.<br><br>It monitors the print queues managed by the Common Unix Printing System (CUPS) and can display notifications about print job status, such as successful completion, errors, or a printer being offline. When clicked, it typically launches the more comprehensive <b>system-config-printer</b> application, allowing users to add or remove printers, configure printer properties, and manage print jobs directly from a graphical interface. This applet enhances user experience by making printer management accessible without needing to open full system settings.


title: CAVEATS
content:
This applet primarily functions within a graphical desktop environment (e.g., GNOME, KDE, XFCE) that supports a system tray or notification area. It relies heavily on the CUPS (Common Unix Printing System) daemon being installed and actively running on the system to perform any printer management tasks. Appropriate user permissions are also necessary to interact with and modify printer configurations via the applet or the main configuration utility it launches.


title: GRAPHICAL NATURE
content:
It is important to note that this command initiates a graphical application designed to run in the background within a desktop session, rather than being a command-line utility for direct interaction in a terminal.


title: CUPS INTEGRATION
content:
The applet serves as a convenient front-end and notification system for CUPS. All actual printer operations, such as adding printers, managing jobs, or applying settings, are handled by the underlying CUPS daemon, with the applet providing the graphical interface for these interactions.


title: HISTORY
content:
The <b>system-config-printer-applet</b> is an integral component of the broader <i>system-config-printer</i> project. This project was initiated to offer a user-friendly graphical interface for managing printers under Linux, primarily by interfacing with CUPS. It has evolved over time to become a standard tool bundled with many popular Linux distributions (such as Fedora, Ubuntu, and Debian), significantly simplifying printer setup, monitoring, and job management for end-users, moving away from purely command-line driven approaches.


title: SYNOPSIS
content:
systemctl [<i>OPTIONS...</i>] {<i>COMMAND</i>} [<i>NAME...</i>]<br>systemctl [<i>OPTIONS...</i>] {<i>COMMAND</i>} {<i>UNIT...</i>}<br>systemctl [<i>OPTIONS...</i>] {<i>COMMAND</i>} {<i>--type=TYPE...</i>}<br>systemctl [<i>OPTIONS...</i>] {<i>COMMAND</i>} {<i>--all</i> | <i>--user</i> | <i>--failed</i>}


title: PARAMETERS
content:
<b><i>start</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts one or more specified <i>systemd</i> units immediately.<br><br><b><i>stop</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops one or more specified <i>systemd</i> units immediately.<br><br><b><i>restart</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts one or more specified <i>systemd</i> units.<br><br><b><i>reload</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reloads the configuration of one or more specified <i>systemd</i> units.<br><br><b><i>enable</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables one or more <i>systemd</i> units to start automatically at boot.<br><br><b><i>disable</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables one or more <i>systemd</i> units from starting automatically at boot.<br><br><b><i>status</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the runtime status of one or more specified <i>systemd</i> units.<br><br><b><i>is-active</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if one or more <i>systemd</i> units are currently active.<br><br><b><i>is-enabled</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if one or more <i>systemd</i> units are configured to start at boot.<br><br><b><i>list-units</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently active <i>systemd</i> units, filtered by default to show only loaded units.<br><br><b><i>list-unit-files</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all installed <i>systemd</i> unit files and their enabled/disabled state.<br><br><b><i>cat</i> &lt;unit&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the content of the specified <i>systemd</i> unit file.<br><br><b><i>reboot</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the entire system.<br><br><b><i>poweroff</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shuts down and powers off the system.<br><br><b><i>suspend</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suspends the system into a low-power state.<br><br><b><i>isolate</i> &lt;target&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates a specified <i>systemd</i> target, deactivating all others.<br><br><b><i>--user</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the per-user <i>systemd</i> instance instead of the system instance.<br><br><b><i>--system</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the system <i>systemd</i> instance (this is the default).<br><br><b><i>--failed</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists only units that are in a 'failed' state.<br><br><b><i>--type=&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters unit output by unit type (e.g., <i>service</i>, <i>socket</i>, <i>mount</i>).<br><br><b><i>--state=&lt;state&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters unit output by unit state (e.g., <i>active</i>, <i>inactive</i>, <i>failed</i>).<br><br><b><i>--no-pager</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents output from being piped into a pager like <i>less</i>.<br><br>


title: DESCRIPTION
content:
<b>systemctl</b> is the primary command-line utility for controlling the <b>systemd</b> system and service manager. It provides a unified interface to manage various aspects of a <b>systemd</b>-based Linux system. Users can leverage <b>systemctl</b> to inspect and control the <b>systemd</b> runtime, including crucial operations such as starting, stopping, restarting, reloading, enabling, and disabling services. Beyond services, it extends its functionality to manage other <b>systemd</b> unit types like mount points, sockets, timers, devices, and slice units. <b>systemctl</b> also facilitates control over the system's power state, allowing for reboots, shutdowns, and suspension. It offers a comprehensive overview of the system's current state, active units, and their dependencies, making it an indispensable tool for system administrators and users alike. Its introduction marked a significant shift from older init systems like SysVinit and Upstart, consolidating many disparate management tasks into a single, powerful command.


title: CAVEATS
content:
<b>systemctl</b> is designed exclusively for systems running <b>systemd</b> as their init system; it is incompatible with traditional SysVinit or OpenRC systems.<br>Many operations, especially those affecting system-wide services or power states, require root (superuser) privileges to execute successfully.<br>Correct unit file naming (e.g., appending <i>.service</i>, <i>.target</i>) is crucial for proper command functionality.


title: UNIT FILES
content:
<b>systemctl</b> directly interacts with <i>systemd</i> 'unit files', which are plain text configuration files defining how <i>systemd</i> manages a specific resource or process. These files typically end with suffixes like <i>.service</i>, <i>.socket</i>, <i>.mount</i>, <i>.target</i>, etc., and are usually located in directories such as <i>/etc/systemd/system/</i> (for custom or overridden units) and <i>/usr/lib/systemd/system/</i> (for default system units).


title: TARGETS
content:
Instead of traditional runlevels, <i>systemd</i> employs 'targets'. A target is a special <i>systemd</i> unit that groups other units, defining a desired system state or a set of functionalities. For instance, <i>multi-user.target</i> represents a command-line interface with network services, while <i>graphical.target</i> includes a graphical desktop environment. <b>systemctl</b> can be used to switch between targets (e.g., <i>systemctl isolate graphical.target</i>) or to query and set the default boot target (e.g., <i>systemctl get-default</i>, <i>systemctl set-default</i>).


title: HISTORY
content:
<b>systemctl</b> is an integral component of the <b>systemd</b> project, which first emerged in 2010 and was initially adopted by Fedora 15 in 2011. Its development aimed to address limitations of traditional init systems like SysVinit, focusing on faster boot times, parallel service startup, and robust dependency management using Linux cgroups. <b>systemctl</b> rapidly gained widespread adoption, becoming the default init system in most major Linux distributions (e.g., Debian, Ubuntu, CentOS, RHEL, Arch Linux), effectively replacing commands like <i>service</i> and <i>chkconfig</i> for service management.


title: SEE ALSO
content:
systemd(1), journalctl(1), systemd.unit(5), systemd.service(5), systemd.target(5), bootctl(1), init(1)


title: PARAMETERS
content:
<b>--now</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately stops the specified units in addition to disabling them. This option combines the effects of `disable` and `stop`.<br><br><b>--runtime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the change only for the current runtime, meaning it will not persist across a reboot. The symbolic links are created in `/run/systemd/system/` instead of `/etc/systemd/system/`.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides specific checks. For `disable`, this can be used to remove links even if the unit is not explicitly recognized as being 'enabled' in the traditional sense, though its primary use is more common with `enable`.<br><br><b>--quiet</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages during the operation, making the command execute silently.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the user systemd instance instead of the system-wide manager. This is used for managing user-specific services.<br><br><b>UNIT...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more names of systemd units to be disabled (e.g., `apache2.service`, `network.target`).<br><br>


title: DESCRIPTION
content:
The `systemctl disable` command is used to prevent one or more systemd units, typically services, from starting automatically when the system boots. When a unit is <I>disabled</I>, systemd removes the symbolic links that connect the unit file (e.g., `my-service.service`) from the appropriate target's `.wants` or `.requires` directory (e.g., `/etc/systemd/system/multi-user.target.wants/`).<br><br>This action makes the change persistent across reboots. It's important to note that `systemctl disable` <B>does not stop a service if it is currently running</B>; it only affects its state for future boots. To stop a running service, you would use `systemctl stop`. To prevent a service from being started manually or automatically, the `systemctl mask` command is used, which creates a symbolic link to `/dev/null` for the unit file, making it impossible to start.


title: CAVEATS
content:
Disabling a service only prevents it from auto-starting at boot. It <B>does not stop a service that is currently running</B>. You must use `systemctl stop UNIT` to halt a running service.<br><br>Also, `systemctl disable` is different from `systemctl mask`. While `disable` prevents auto-start, `mask` completely prevents a unit from being started, even manually, by linking its unit file to `/dev/null`.


title: STATIC UNITS
content:
Some unit types, particularly `target` units or specific `mount` units, are considered 'static'. This means they do not have a traditional enable/disable mechanism because they are typically pulled in by other units or are fundamental to the system's operation. Attempting to `disable` a static unit may result in a message indicating it's static and cannot be disabled in the usual way.


title: DEPENDENCY MANAGEMENT
content:
When you disable a unit, systemd removes its symlinks from `.wants` or `.requires` directories. This action primarily affects how that specific unit is brought up. However, if other units explicitly depend on the disabled unit using `Requires=` or `Wants=` directives in their own unit files, those units might still attempt to start it, or their startup behavior might be affected if the dependency is no longer met automatically. Always consider the dependency chain when disabling critical services.


title: HISTORY
content:
The `systemctl` command is the primary control interface for <B>systemd</B>, the init system and service manager that has largely replaced older systems like SysVinit and Upstart in many Linux distributions. `systemd` was first introduced in Fedora in 2010 and adopted by many major distributions thereafter. The `disable` command, along with `enable`, `start`, and `stop`, is a fundamental part of `systemd`'s design for managing the lifecycle of services and other system units, providing a more structured and efficient way to handle system startup and runtime processes.


title: SEE ALSO
content:
systemctl enable(1), systemctl start(1), systemctl stop(1), systemctl mask(1), systemctl status(1), systemctl is-enabled(1)


title: SYNOPSIS
content:
<b>systemctl enable</b> [<i>OPTIONS...</i>] <i>UNIT...</i><br><b>systemctl enable</b> [<i>OPTIONS...</i>] <i>PATH...</i>


title: PARAMETERS
content:
<b>UNIT...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more unit names (e.g., <i>nginx.service</i>, <i>apache2.service</i>, <i>network.target</i>). These are the services, sockets, targets, mounts, etc., that you want to enable.<br><br><b>PATH...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;An absolute path to a unit file (e.g., <i>/etc/systemd/system/mycustom.service</i>). Used for symlinking a unit file into an enable directory.<br><br><b>--now</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simultaneously enables and starts the specified units. This is a convenient shortcut for running <i>systemctl enable UNIT</i> followed by <i>systemctl start UNIT</i>.<br><br><b>--runtime</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables the unit only until the next system reboot. The symbolic links created are placed in <i>/run/systemd/system</i> instead of <i>/etc/systemd/system</i>, making the change temporary.<br><br><b>--force or -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <i>enable</i>, it ensures that all symlinks created point to the correct unit file, even if a symlink by the same name already exists and points elsewhere.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the systemd system manager. This is the default behavior and typically manages services available to all users.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Connects to the systemd user session manager. Used to enable services specific to the current logged-in user, which run independent of root privileges.<br><br><b>--preset</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables units based on a "preset" policy. Presets are defined in <i>/etc/systemd/system-preset/</i> or similar directories and can be used to apply a default enabling/disabling policy.<br><br><b>--root=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the specified root directory. Useful for chroot environments or managing services on an unmounted filesystem.<br><br>


title: DESCRIPTION
content:
<i>systemctl enable</i> is a core command in systemd, used to configure a service or unit to start automatically at boot time. When you enable a unit, <i>systemctl</i> creates symbolic links from the appropriate systemd target's <i>.wants</i> or <i>.requires</i> directory (e.g., <i>/etc/systemd/system/multi-user.target.wants/</i>) to the unit's actual file (e.g., <i>/usr/lib/systemd/system/nginx.service</i>). This ensures that when the system reaches that target (typically <i>multi-user.target</i> for most services), the enabled unit is started as part of the boot process.<br><br>It's crucial to understand that <i>enable</i> does not start the service immediately; it merely configures it for future boots. To start the service right away, you would use <i>systemctl start UNIT</i> or combine both actions with <i>systemctl enable --now UNIT</i>. The inverse command, <i>systemctl disable UNIT</i>, removes these symbolic links, preventing the service from starting automatically. This command replaces older methods like <i>chkconfig</i> or manual <i>update-rc.d</i> in SysVinit-based systems, offering a more unified and dependency-aware approach to service management.


title: CAVEATS
content:
Most system-wide services require <i>root privileges</i> to enable or disable them.<br>Enabling a service <i>does not start it immediately</i> unless the <i>--now</i> option is used. It only configures it for automatic startup on subsequent boots.<br>A "static" unit, which is typically a unit that is pulled in by another unit's <i>Wants=</i> or <i>Requires=</i> dependency and does not have an <i>[Install]</i> section itself, cannot be directly enabled or disabled.<br>The actual behavior of <i>enable</i> involves creating symbolic links. If these links are manually altered or corrupted, <i>systemctl enable</i> might not behave as expected.<br>Be cautious when enabling services on critical systems. Always understand what a service does before enabling it, as it could introduce security vulnerabilities or resource consumption issues.


title: UNDERSTANDING UNIT TYPES
content:
The <i>UNIT</i> argument can refer to various types of systemd units, not just services (<i>.service</i>). This includes sockets (<i>.socket</i>), mount points (<i>.mount</i>), devices (<i>.device</i>), swap devices (<i>.swap</i>), paths (<i>.path</i>), timers (<i>.timer</i>), slices (<i>.slice</i>), and targets (<i>.target</i>). Enabling a target unit (e.g., <i>multi-user.target</i>) primarily ensures that its dependencies (other units that it "Wants" or "Requires") are pulled in.


title: DIFFERENCE BETWEEN ENABLE AND START
content:
It's a common misconception that <i>systemctl enable</i> also starts a service.<br><b>systemctl enable</b> configures a unit to launch automatically at system boot or when a specific target is reached. It sets up persistent links.<br><b>systemctl start</b> initiates a unit immediately in the current runtime session. This action is not persistent across reboots unless the unit is also enabled. For persistence and immediate action, use <i>systemctl enable --now UNIT</i>.


title: USER VS. SYSTEM UNITS
content:
By default, <i>systemctl</i> operates on system-wide units (managed by the systemd daemon, usually requiring root privileges). However, users can run their own systemd instances to manage user-specific services (e.g., background applications) by using the <i>--user</i> flag. These units typically reside in <i>~/.config/systemd/user/</i> or <i>~/.local/share/systemd/user/</i> and are enabled by creating symlinks in <i>~/.config/systemd/user.control/default.target.wants/</i> or similar user-specific target directories.


title: HISTORY
content:
The <i>systemctl enable</i> command is an integral part of <i>systemd</i>, a modern init system and service manager that began development in 2010. It was created to overcome limitations and complexities of traditional SysVinit and Upstart systems. <i>systemd</i> was first adopted by Fedora in 2011, followed by major distributions like Red Hat Enterprise Linux, CentOS, Debian, Ubuntu, openSUSE, and Arch Linux over the subsequent years, making <i>systemctl</i> the de-facto standard for service management.<br><br><i>systemctl enable</i> specifically streamlined the process of configuring services for boot, replacing often cumbersome and distribution-specific scripts like <i>chkconfig</i> or direct manipulation of runlevel directories. Its declarative approach, based on unit files and symbolic links, significantly simplified service dependency management and overall system startup configuration.


title: SEE ALSO
content:
systemctl(1), systemctl disable(1), systemctl start(1), systemctl stop(1), systemctl status(1), systemctl mask(1), systemctl is-enabled(1), systemd.unit(5), systemd.service(5), systemd.target(5), systemd.preset(5)


title: PARAMETERS
content:
<b>--no-block</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not wait for the operation to finish. The command returns immediately after the reboot request has been sent to <i>systemd</i>, allowing the calling script or user to continue execution while the system prepares to reboot in the background.<br><br><b>--force or <i>-f</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When specified once, this option bypasses the normal graceful shutdown procedure. It causes <i>systemd</i> to immediately terminate all processes and unmount filesystems without invoking <b>shutdown(8)</b>. This can be useful in situations where a clean shutdown is stuck or not possible, but it carries a higher risk of data loss.<br><br><b>--force --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When specified twice (e.g., <b>systemctl --force --force reboot</b>), this command executes an immediate reboot without even transitioning through different runlevels or targets. This is the most abrupt way to reboot the system and should only be used as a last resort, for example, if the system is completely unresponsive.<br><br>


title: DESCRIPTION
content:
The <b>systemctl reboot</b> command is the standard and recommended method for initiating a system restart on Linux distributions that utilize <i>systemd</i> as their init system. As a subcommand of <b>systemctl</b>, it interacts directly with the <i>systemd</i> manager to orchestrate a clean and orderly shutdown of all running services, unmount filesystems, and then reboot the machine. <br><br>Unlike older methods or direct kernel calls, <b>systemctl reboot</b> ensures that all system processes are given time to terminate gracefully, minimizing the risk of data corruption or application state loss. This command is part of the <i>systemd</i> suite, which manages the system and service startup process, lifecycle, and shutdown. Its adoption signifies a modern approach to system management, integrating reboot functionality seamlessly within the broader <i>systemd</i> ecosystem for enhanced reliability and control. <br><br>It is crucial to save all open work and notify other users if the system is shared before executing this command, as it will disrupt all active sessions and processes. While other commands like <b>reboot</b> or <b>shutdown -r now</b> exist, they often internally invoke <b>systemctl reboot</b> or are considered legacy.


title: CAVEATS
content:
Requires root privileges or appropriate <i>sudo</i> configuration to execute.<br>Unsaved data will be lost. Always ensure all critical work is saved before initiating a reboot.<br>Disrupts all active network connections and user sessions. Inform other users on shared systems before proceeding.<br>Using <i>--force</i> or <i>--force --force</i> can lead to data corruption if filesystems are not properly unmounted or services are abruptly terminated. Use with extreme caution.


title: COMPARISON WITH <I>SHUTDOWN -R NOW</I>
content:
While <b>shutdown -r now</b> achieves a similar immediate reboot, <b>systemctl reboot</b> is generally preferred on <i>systemd</i> systems because it directly leverages <i>systemd</i>'s internal mechanisms for state transitions, ensuring better integration with service management and logging. <b>shutdown</b> might still be useful for scheduling future reboots.


title: REBOOT TARGET
content:
When <b>systemctl reboot</b> is executed, <i>systemd</i> activates the <i>reboot.target</i>. This target pulls in other services and targets necessary for a clean shutdown, such as <i>shutdown.target</i>, ensuring that services are stopped in the correct order and filesystems are unmounted before the final reboot instruction is issued to the kernel.


title: HISTORY
content:
The concept of rebooting a Unix-like system has existed since its inception. Traditionally, commands like <b>reboot</b> and <b>shutdown</b> were used, often interacting directly with the kernel or the <i>init</i> process. With the rise of <i>systemd</i> as the default init system in major Linux distributions (such as Fedora, RHEL, Debian, Ubuntu) starting in the early 2010s, a new paradigm for system management emerged. <b>systemctl</b> was introduced as the primary command-line interface to <i>systemd</i>. The <b>systemctl reboot</b> command supplanted many of the legacy methods by providing a unified, <i>systemd</i>-native way to manage system states, including reboot. This transition aimed to provide more consistent and robust system control, leveraging <i>systemd</i>'s sophisticated service management capabilities for a cleaner and more reliable system restart. For backward compatibility, the standalone <b>reboot</b> command is often symlinked to <b>systemctl reboot</b> on <i>systemd</i>-based systems.


title: SYNOPSIS
content:
<br><b>systemd</b> [<i>OPTIONS...</i>]<br>(Note: <b>systemd</b> is primarily the PID 1 daemon; direct user invocation is rare for system management.)


title: PARAMETERS
content:
<b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tells <b>systemd</b> to run as the system-wide manager, which is its default role (PID 1).<br><br><b><b>--user</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Tells <b>systemd</b> to run as a user-specific manager, handling user sessions and services.<br><br><b><b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs <b>systemd</b> in a test mode, useful for debugging configuration files without affecting the running system.<br><br><b><b>--log-level=<i>level</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum log level for messages written to the journal, e.g., <i>info</i>, <i>debug</i>, <i>warning</i>.<br><br><b><b>--log-target=<i>target</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the destination for log messages, e.g., <i>console</i>, <i>journal</i>, <i>syslog</i>.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version of <b>systemd</b>.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message with available command-line options.<br><br>


title: DESCRIPTION
content:
<b>systemd</b> is the foundational building block of many modern Linux distributions, acting as the primary <b>init</b> system and service manager. It is the first user-space process started during boot (PID 1) and is responsible for bringing up and maintaining the entire operating system. Its core responsibilities include initializing the system, managing system services, handling mount points, devices, and sockets, and shutting down the system gracefully. <b>systemd</b> employs a dependency-based boot process, allowing services to start in parallel, significantly speeding up boot times compared to older <i>SysVinit</i> or <i>Upstart</i> systems. It uses "unit" files (e.g., <i>service</i>, <i>socket</i>, <i>device</i>, <i>mount</i>, <i>target</i>, <i>timer</i>) to define and manage system resources, providing a consistent and declarative way to configure system behavior. While <b>systemd</b> itself is the daemon, users typically interact with it via the <b>systemctl</b> command to manage services, inspect status, and control the system state.


title: CAVEATS
content:
<b>systemd</b> is a comprehensive and deeply integrated system, which has led to some controversy. Its extensive scope, replacing functionalities previously handled by separate tools (e.g., networking, logging, DNS resolution), can make it complex to understand for newcomers. Troubleshooting often requires familiarity with its unit-based structure and specific tools like <b>systemctl</b> and <b>journalctl</b>. Its binary journal logging can also be a point of contention for those accustomed to plain text logs.


title: UNIT FILES
content:
<b>systemd</b> manages system resources and services using configuration files called "unit files." These plain-text files describe various types of resources, such as <i>service units</i> (.service) for daemons, <i>socket units</i> (.socket) for socket-activated services, <i>mount units</i> (.mount) for filesystems, and <i>target units</i> (.target) for grouping other units and defining system states (e.g., `multi-user.target`, `graphical.target`). Unit files enable declarative and powerful dependency management.


title: THE JOURNAL
content:
<b>systemd</b> includes its own logging system, known as the <b>systemd Journal</b>. It collects log data from various sources—kernel, initrd, services, standard output/error—into a centralized, indexed, binary database. This allows for powerful querying and filtering of logs using the <b>journalctl</b> command, providing a more structured and efficient way to analyze system events compared to traditional plain-text log files.


title: HISTORY
content:
Development of <b>systemd</b> began in 2010 by <i>Lennart Poettering</i> and <i>Kay Sievers</i> at <i>Red Hat</i>, aiming to provide a more modern, efficient, and integrated replacement for the traditional <i>SysVinit</i> system. It was designed to address limitations such as slow, sequential boot processes and lack of robust dependency management. <b>systemd</b> was first adopted by <i>Fedora</i> in 2011 and quickly gained traction, becoming the default init system for most major Linux distributions, including <i>Arch Linux</i>, <i>openSUSE</i>, <i>Debian</i>, and <i>Ubuntu</i>, by the mid-2010s. Its adoption sparked significant debate within the Linux community due to its design philosophy and broad scope.


title: SEE ALSO
content:
<b>systemctl</b>(1)<br>, <b>journalctl</b>(1)<br>, <b>bootctl</b>(1)<br>, <b>loginctl</b>(1)<br>, <b>hostnamectl</b>(1)<br>, <b>timedatectl</b>(1)<br>, <b>localectl</b>(1)<br>, <b>networkctl</b>(1)<br>


title: SYNOPSIS
content:
As a <I>systemd</I> target, <I>ac-power.target</I> does not have a traditional command-line synopsis with options and arguments. It represents a state that the system enters. Its status can be observed or its dependencies managed using the <I>systemctl(1)</I> command, for example:<br><br><b>systemctl status ac-power.target</b><br><b>systemctl list-dependencies ac-power.target</b>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>ac-power.target</I> is a <I>systemd</I> target unit and does not accept command-line parameters or options in the manner of a traditional executable program. Its state is determined by the system's hardware detection capabilities, primarily managed by <I>systemd-logind</I>.<br><br>


title: DESCRIPTION
content:
<i>ac-power.target</i> is a special <I>systemd</I> target unit designed to signal when the system is connected to an alternating current (AC) power source. It is not an executable command that you run directly from the terminal with arguments. Instead, it represents a specific power state of the system.<br><br>This target is automatically activated by <I>systemd-logind(8)</I> when it detects that the machine is operating on AC power. Its primary purpose is to provide a standardized, abstract mechanism for other <I>systemd</I> units, services, or scripts to react to the presence of AC power. For instance, a service might be configured to only run or operate at full performance when <I>ac-power.target</I> is active, thus preventing excessive battery drain. It simplifies power management by allowing developers to express dependencies on the power source rather than directly polling hardware interfaces.


title: CAVEATS
content:
It is crucial to understand that <I>ac-power.target</I> is <B>not</B> an executable command. It is a conceptual systemd target unit. Its activation and deactivation are managed internally by <I>systemd-logind</I> based on hardware power supply events. Its functionality relies entirely on <I>systemd-logind</I> being active and correctly detecting the power source. There might be a slight delay between a physical power source change and the target's state update due to event processing.


title: PURPOSE AND ACTIVATION
content:
<I>ac-power.target</I> serves as a vital component for power-aware applications and services. When <I>systemd-logind</I> detects that the system is plugged into an AC power source, it activates this target. Conversely, when AC power is disconnected and the system runs on battery, this target is deactivated. Services can declare a dependency on <I>ac-power.target</I> (e.g., using <B>Wants=</B> or <B>Requires=</B> in their unit files) to ensure they only run or modify their behavior when AC power is available. This is particularly useful for tasks that consume significant power, such as background indexing, software updates, or high-performance computing tasks.


title: DISTINCTION FROM COMMANDS AND SERVICES
content:
The name 'systemd-ac-power' might lead to confusion, suggesting an executable command. However, it's essential to differentiate between <I>systemd</I> targets (like <I>ac-power.target</I>) and actual executable commands or template services (e.g., <I>systemd-ac-power@.service</I> which might exist in some contexts to perform actions based on this target). <I>ac-power.target</I> itself is purely a state indicator, a logical 'flag' that other <I>systemd</I> units can check or depend upon, rather than a program that performs an action when invoked.


title: HISTORY
content:
<I>ac-power.target</I> was introduced as part of the broader <I>systemd</I> initiative to unify and streamline system management, including power management. Prior to this, managing power-aware behaviors often involved custom scripts polling <I>/sys</I> files or relying on desktop environment-specific mechanisms. Its inclusion provides a consistent and declarative way for services and applications to integrate with the system's power state, reducing complexity and improving reliability.


title: PARAMETERS
content:
<b>time</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the time spent in the kernel, initrd, and userspace during boot.<br><br><b>blame</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows unit initialization times, ordered by the time they took.<br><br><b>critical-chain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a tree of the most critical dependencies that slow down the boot process.<br><br><b>plot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates an SVG image showing the boot process time sequence. Requires Graphviz <i>dot</i>.<br><br><b>dot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a dependency graph in Graphviz dot format. Requires Graphviz <i>dot</i>.<br><br><b>verify [UNIT...]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks the specified unit files for correctness and potential issues.<br><br><b>dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the internal state of the <i>systemd</i> service manager.<br><br><b>log-level [LEVEL]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gets or sets the <i>systemd</i> manager's log level (e.g., 'debug', 'info').<br><br><b>log-target [TARGET]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Gets or sets the <i>systemd</i> manager's log target (e.g., 'console', 'journal').<br><br><b>unit-paths</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists the directories from which <i>systemd</i> loads unit files.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the user's <i>systemd</i> instance instead of the system instance.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the system-wide <i>systemd</i> instance (this is the default).<br><br><b>--json=[MODE]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats output as JSON (e.g., <i>pretty</i>, <i>short</i>, <i>full</i>).<br><br>


title: DESCRIPTION
content:
<i>systemd-analyze</i> is an essential command-line utility for understanding and optimizing the <i>systemd</i> system and service manager. It provides a suite of subcommands to inspect various aspects of system behavior, with a primary focus on boot-up performance. Users can identify bottlenecks by analyzing the time spent in the kernel, initrd, and userspace, or by listing services ordered by their initialization time. The command can also generate detailed graphical representations of the boot process, aiding in visual debugging. Beyond performance, <i>systemd-analyze</i> assists in verifying <i>systemd</i> unit files, examining service dependencies, and dumping the internal state of the service manager, making it an indispensable tool for system administrators and developers troubleshooting <i>systemd</i>-related issues or aiming to improve system startup efficiency.


title: CAVEATS
content:
Requires <i>systemd</i> to be the active init system on the Linux distribution.<br>The <i>plot</i> and <i>dot</i> subcommands rely on Graphviz (the <i>dot</i> command) being installed for generating visual graphs; without it, these commands will not produce output.<br>Boot times reported by <i>systemd-analyze</i> can exhibit slight variations across different reboots due to factors like disk caching, kernel updates, or background system activities.<br>The <i>blame</i> output, while useful, primarily reflects sequential initialization times and might not fully capture the benefits of parallel execution or complex inter-service dependencies.


title: <B>BOOT PERFORMANCE VISUALIZATION</B>
content:
The <i>plot</i> subcommand is particularly powerful for visualizing the entire boot sequence as an SVG image. This graphical representation makes it much easier to identify overlaps, gaps, and specific services contributing to delays, providing an intuitive understanding of boot performance bottlenecks.


title: <B>UNIT FILE DEBUGGING</B>
content:
The <i>verify</i> subcommand is invaluable for developers and system administrators creating or modifying custom <i>systemd</i> unit files. It performs syntax checks and highlights potential errors or deprecated settings, helping to ensure units function correctly before deployment and preventing issues during system operation.


title: <B>JSON OUTPUT FOR SCRIPTING</B>
content:
Many of <i>systemd-analyze</i>'s subcommands support a <i>--json</i> output option. This allows for easy parsing of command output in scripts or automated tools, enabling advanced analysis and integration with monitoring systems and other programs that can consume structured data.


title: HISTORY
content:
<i>systemd-analyze</i> emerged as a crucial utility alongside the development and widespread adoption of <i>systemd</i>, which began replacing the traditional <i>SysVinit</i> system in many major Linux distributions starting in the early 2010s. Its primary purpose was to provide visibility into the new, often complex, dependency-based boot process managed by <i>systemd</i>. Over time, its functionalities expanded from basic boot time reporting to sophisticated tools for dependency visualization, unit file validation, and detailed internal state inspection, reflecting the growing needs of administrators managing <i>systemd</i>-powered systems.


title: PARAMETERS
content:
<b><i>PROMPT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional string used as the prompt for the user. If omitted, a default prompt is used.<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>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package version and exit.<br><br><b><b>-s</b>, <b>--no-tty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevent asking for the password on a TTY, requiring a graphical password agent instead.<br><br><b><b>-p</b>, <b>--echo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Echo characters while typing the password. This option is generally not recommended for sensitive passwords due to security implications.<br><br><b><b>-P</b>, <b>--no-confirm</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not ask the user to confirm the password by typing it twice.<br><br><b><b>--timeout=</b><i>SECS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a timeout in seconds after which the password query will be aborted if no input is received.<br><br><b><b>--repeat-until-ok</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Continuously repeat the password query until a valid password is provided.<br><br><b><b>--key-slot=</b><i>SLOT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a key slot to use, typically for LUKS volumes. This option is passed directly to the password agent.<br><br><b><b>--max-attempts=</b><i>N</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the maximum number of password entry attempts allowed before giving up.<br><br><b><b>--max-delay=</b><i>SECS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the maximum delay in seconds between password query attempts when retrying.<br><br><b><b>--retry-delay=</b><i>SECS</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial delay in seconds between password query attempts when retrying.<br><br>


title: DESCRIPTION
content:
<i>systemd-ask-password</i> is a utility designed to securely obtain a password or passphrase from a user. It acts as an interface between a requesting program (e.g., a system service, a script needing a password for an encrypted volume) and a password agent, such as <i>systemd-tty-ask-password-agent</i> for terminal environments or graphical agents in desktop environments. When invoked, it sends a request to the registered password agent, which then displays a prompt to the user, collects the input, and returns the password to <i>systemd-ask-password</i>.<br><br>This tool ensures that sensitive information like passwords are not directly handled by the requesting application, promoting better security practices within the systemd ecosystem. It's commonly used during boot for unlocking encrypted file systems (like LUKS volumes) or by services that require authentication credentials. The command exits with status 0 on success, printing the password to standard output, and a non-zero status on failure or user cancellation.


title: CAVEATS
content:
<i>systemd-ask-password</i> relies on a password agent being active and correctly configured. If no agent is running or accessible, the password prompt may fail. The <b>--echo</b> option should be used with extreme caution, as it exposes the password directly on the screen while typing. When used for LUKS volumes or other critical system components, ensure the password agent is robust and secure, as it handles sensitive data.


title: INTERACTION WITH PASSWORD AGENTS
content:
This command does not directly prompt the user. Instead, it communicates with a <i>password agent</i> (like <i>systemd-tty-ask-password-agent</i> for terminal interaction or a graphical agent in a desktop environment). The agent then handles the actual display of the prompt and input collection from the user, ensuring secure handling of credentials.


title: RETURN VALUE
content:
On successful password acquisition, <i>systemd-ask-password</i> exits with a status code of 0 and prints the collected password to its standard output. If the operation fails (e.g., user cancellation, timeout, incorrect password after multiple attempts), it exits with a non-zero status code and prints an error message to standard error.


title: HISTORY
content:
<i>systemd-ask-password</i> is an integral part of the systemd init system, which replaced the traditional SysVinit in many Linux distributions. It was introduced as part of systemd's broader strategy to standardize and centralize system management, including secure password handling. Its development is tied to the evolution of systemd itself, aiming to provide a robust and extensible mechanism for services to acquire user credentials without direct terminal interaction or insecure methods. Its reliance on password agents reflects systemd's design philosophy of modularity and separation of concerns.


title: PARAMETERS
content:
<b><b>--all</b>, <b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all journal fields, including internal and less commonly shown ones.<br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses informational messages and empty lines, producing a cleaner output.<br><br><b><b>--output</b>=<i>FORMAT</i>, <b>-o</b> <i>FORMAT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output format. Common formats include <i>short</i> (default), <i>verbose</i>, <i>json</i>, <i>json-pretty</i>, among others.<br><br><b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b><i>FILES</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to journal files or directories to be concatenated and displayed. If no files are specified, it reads from standard input.<br><br>


title: DESCRIPTION
content:
<b>systemd-cat</b> is a utility designed to concatenate and print entries from the systemd journal. It offers a simpler, <i>cat</i>-like interface compared to <b>journalctl</b>, which is the primary tool for querying and displaying the live journal.<br><br><b>systemd-cat</b> is particularly useful for processing journal data from specific journal files or directories, or when piping journal entries from standard input. While it doesn't offer the extensive filtering and live monitoring capabilities of <b>journalctl</b>, it excels at presenting journal content in a straightforward, stream-oriented manner. It can display various structured journal fields alongside the main log message, providing valuable context. The command is often employed when you need to treat journal data like any other text stream, enabling easy integration with standard Unix text processing tools.


title: CAVEATS
content:
<b>systemd-cat</b> is less powerful than <b>journalctl</b> for live querying or complex filtering of the active journal. It is primarily designed for concatenating existing journal files or standard input, not for real-time log analysis with advanced filtering capabilities.


title: INPUT SOURCES
content:
<b>systemd-cat</b> can read journal entries from specified journal files, directories, or standard input. When invoked without <i>FILES</i>, it reads from standard input, expecting journal entries in a format that it can parse (e.g., from <b>journalctl --output=export</b>).


title: OUTPUT FORMATS
content:
The <b>--output</b> option is crucial for controlling how journal entries are presented. For example, <i>short</i> provides a traditional log-like output, <i>verbose</i> adds more fields for debugging, and <i>json</i> or <i>json-pretty</i> are useful for programmatic processing and integration with other tools.


title: HISTORY
content:
<b>systemd-cat</b> was introduced as part of the <b>systemd</b> suite, which aimed to modernize the Linux init system and provide a comprehensive set of tools for system management. It offers a familiar <i>cat</i>-like interface for journal entries, complementing <b>journalctl</b>'s more robust querying capabilities. Its design reflects the <b>systemd</b> philosophy of offering specialized, composable tools for specific tasks related to system logging and management.


title: PARAMETERS
content:
<b><b><code>-h</code></b>, <b><code>--help</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a short help text to the console and exits.<br><br><b><b><code>--version</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a short version string of <code>systemd-cgls</code> and exits.<br><br><b><b><code>-a</code></b>, <b><code>--all</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows all control groups, including empty ones. By default, empty cgroups are not displayed in the output.<br><br><b><b><code>-M</code></b>, <b><code>--machine=</code></b><i>CONTAINER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on a local container. The specified <i>CONTAINER</i> is the name of a <code>machinectl</code> container where the cgroup hierarchy should be inspected.<br><br><b><b><code>-l</code></b>, <b><code>--full</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not abbreviate unit names or cgroup paths in the output. By default, long names might be truncated for better readability.<br><br><b><b><code>--unit=</code></b><i>UNIT</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows only processes that are part of the specified systemd <i>UNIT</i> (e.g., <code>apache2.service</code>) and its cgroup path.<br><br><b><b><code>--root</code></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts displaying the cgroup tree from the root of the cgroup hierarchy, even if systemd is not managing the entire root. This provides a complete view of all cgroups on the system.<br><br>


title: DESCRIPTION
content:
<code>systemd-cgls</code> is a command-line utility that recursively lists the contents of the Linux control groups (cgroups) managed by systemd. It provides a tree-like view of the hierarchy, showing which processes belong to which cgroup. Cgroups are a Linux kernel feature that allows for the organization of processes into hierarchical groups for the purpose of resource management, such as CPU, memory, and I/O. <code>systemd</code> extensively uses cgroups to manage resources for services, scopes, and slices. This command helps administrators understand the resource isolation and allocation applied by systemd, troubleshoot resource issues, and identify processes within specific systemd units or other cgroup paths. It's particularly useful for visualizing the relationship between systemd units (like services, sockets, devices, mounts) and the underlying processes and their resource containers.


title: CAVEATS
content:
<code>systemd-cgls</code> provides a snapshot of the cgroup hierarchy at the time of execution; it does not update dynamically. Its output relies on the kernel's cgroup filesystem, and its behavior might slightly vary between cgroup v1 and cgroup v2 environments, though it generally adapts to the active cgroup version. It typically requires appropriate permissions (e.g., running as root) to access the cgroup filesystem for a complete view.


title: OUTPUT FORMAT
content:
The command presents a hierarchical, tree-like view of the cgroup structure. Each line typically shows the cgroup path, followed by the process ID (PID) and the command name of processes residing within that cgroup. This visual representation makes it intuitive to understand the nesting of cgroups and the processes they contain, making it easy to trace processes to their associated systemd units.


title: TYPICAL USE CASES
content:
Administrators commonly use <code>systemd-cgls</code> to verify that processes are correctly placed into their intended systemd slices, scopes, or services. <br>It's also invaluable for identifying which unit a specific process belongs to, or for troubleshooting resource management issues by observing the cgroup structure and identifying processes consuming resources within a particular group. <br>It serves as a foundational tool for understanding and debugging systemd's resource control mechanisms.


title: HISTORY
content:
<code>systemd-cgls</code> was introduced as part of the <code>systemd</code> suite, which began its development in 2010. As <code>systemd</code> rapidly adopted and became the standard init system for many Linux distributions, its reliance on and management of Linux cgroups increased significantly. <code>systemd-cgls</code> emerged as an essential tool to inspect and debug <code>systemd</code>'s cgroup organization, providing a human-readable representation of process placement within the cgroup hierarchy. Its core functionality has remained relatively stable, evolving primarily in parallel with the underlying cgroup kernel interfaces and systemd's cgroup management capabilities.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b>-p, --_pretty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pretty print output, using human-readable units (e.g., '1.5G' instead of '1500000000').<br><br><b>-b, --batch</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Run in batch mode, printing output once and exiting. Useful for scripting and redirecting output.<br><br><b>-d, --delay=<I>SEC</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the update delay in seconds for interactive mode. The default is 3 seconds.<br><br><b>-M, --json=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in JSON format. <I>MODE</I> can be 'pretty', 'short', or 'off'.<br><br><b>-c, --color</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable colored output, enhancing readability.<br><br><b>-k, --kill-cgroup=<I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Immediately kill all processes within the specified cgroup <I>PATH</I>. Use with extreme caution.<br><br><b>-P, --no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager, showing it directly in the terminal.<br><br><b>-n, --lines=<I>NUMBER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;In batch mode, show the top <I>NUMBER</I> of cgroups. (Implies --batch).<br><br><b>-u, --user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show cgroups belonging to user sessions (scope units).<br><br><b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show recursive cgroup usage, including all descendants. This is the default behavior.<br><br><b>-a, --all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all cgroups, including those with zero resource usage.<br><br><b>-m, --memory</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by memory usage.<br><br><b>-i, --io</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by I/O usage.<br><br><b>-T, --tasks</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by the number of tasks (PIDs) in each cgroup.<br><br><b>-C, --cpu</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sort the output by CPU usage. This is the default sort order.<br><br>


title: DESCRIPTION
content:
<I>systemd-cgtop</I> is a command-line utility provided by the <B>systemd</B> init system. It offers a real-time, interactive overview of resource usage (CPU, memory, I/O, PIDs) categorized by control groups (cgroups). Similar to <I>top</I> but focused on the hierarchical cgroup structure, it allows system administrators and developers to quickly identify resource-intensive services, slices, and other systemd units.<br><br>It's an invaluable tool for diagnosing performance bottlenecks, understanding resource consumption patterns, and ensuring fair resource allocation across different applications and services managed by <B>systemd</B>. By default, it sorts by CPU usage, but can be configured to sort by other metrics or operate in a non-interactive batch mode for scripting and reporting.


title: CAVEATS
content:
Viewing all cgroups and their detailed resource usage often requires <B>root</B> privileges or specific capabilities. The <B>-k, --kill-cgroup</B> option is extremely powerful and can immediately terminate critical system services if misused, potentially leading to system instability or crashes. Output on very busy systems can be extensive; judicious use of sorting and filtering options is recommended.


title: INTERACTIVE MODE AND KEYBOARD SHORTCUTS
content:
By default, <I>systemd-cgtop</I> runs in an interactive mode, providing a dynamic, refreshing display. Users can interact with the view using various keyboard shortcuts: for example, pressing <B>'m'</B> will sort by memory, <B>'c'</B> by CPU, <B>'i'</B> by I/O, and <B>'q'</B> will quit the application. This interactivity makes it highly suitable for real-time monitoring and troubleshooting.


title: CGROUP V2 FOCUS
content:
The command is designed to work seamlessly with cgroup V2, the unified cgroup hierarchy, which <B>systemd</B> primarily uses for resource control. It provides a clear, hierarchical representation of resource consumption, making it easier to understand how resources are being used across different levels of the <B>systemd</B> unit tree (slices, scopes, services).


title: HISTORY
content:
<I>systemd-cgtop</I> is an integral part of the <B>systemd</B> init system, which first emerged in 2010. Its development is closely tied to <B>systemd</B>'s increasing reliance on and management of Linux control groups (cgroups), particularly with the adoption of cgroup V2 for resource isolation and accounting. It was introduced to provide a more native and detailed view into <B>systemd</B>'s resource management features, offering insights into how services and other units utilize system resources within their defined cgroup hierarchies.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short help text and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a short version string and exit.<br><br><b>--json=MODE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output in JSON format. 'pretty' for human-readable, 'short' for compact, 'off' for default (non-JSON) output. Default is 'off'.<br><br><b>--toplevel=FIELD</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show the configuration for the specified top-level field name.<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b>--plain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print output without line-drawing or other control characters.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Abort with an error if unknown fields are encountered in unit files.<br><br><b>--root=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a specified root directory instead of the host's root.<br><br><b>--unit-path=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A colon-separated list of directories to search for unit files.<br><br><b>--dropin-path=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A colon-separated list of directories to search for drop-in files.<br><br><b>--empty</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show sections even if they would be empty after parsing.<br><br><b>--full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all fields, not just those explicitly defined or overridden in the unit files. This includes implicit and default values.<br><br><b>--with-dropins</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly include drop-in configuration files (usually included by default if found).<br><br><b>--section=NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show the configuration for a specific section within the unit file, e.g., '[Service]'.<br><br><b>--field=NAME</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show the value for a specific field within a specified section, e.g., 'ExecStart'.<br><br>


title: DESCRIPTION
content:
<i>systemd-confext</i> is a low-level utility within the systemd suite, designed to extract and display the *effective* configuration of systemd unit files. It processes the specified unit files, including any associated drop-in configuration directories (.d files), and applies the same merging logic that systemd itself uses. This means it resolves overrides and consolidates settings from all relevant configuration sources into a single, cohesive representation.<br><br>While not typically invoked directly by end-users, <i>systemd-confext</i> serves as a crucial backend component for tools like <i>systemd-analyze</i>, particularly for its <code>verify</code> and <code>dot</code> subcommands. It allows these tools to accurately inspect and analyze the final state of a unit's configuration, which is essential for debugging, dependency graphing, and understanding how system services are configured and interact. The output is highly structured, often in a machine-readable format, reflecting systemd's internal understanding of the unit's settings.


title: CAVEATS
content:
<i>systemd-confext</i> is primarily an internal tool for systemd analysis. It is generally not intended for direct interactive use by administrators or users. Its output format, while structured, is optimized for machine parsing rather than easy human readability, especially without the <code>--json=pretty</code> option. Understanding its output requires familiarity with <i>systemd</i> unit file syntax and configuration principles.


title: INTENDED USE
content:
This command is predominantly used internally by other <i>systemd</i> tools, such as <code>systemd-analyze verify</code>, to parse and understand unit configuration without needing to replicate <i>systemd</i>'s complex configuration loading logic. It ensures that any analysis is based on the exact same configuration that <i>systemd</i> itself would use.


title: CONFIGURATION MERGING
content:
A key function of <i>systemd-confext</i> is to simulate <i>systemd</i>'s configuration merging process. This includes handling multiple unit files for the same service (e.g., <code>foo.service</code> and <code>foo.service.d/*.conf</code>), where settings from later files or drop-ins can override or augment those from earlier ones. The output reflects the final, merged configuration.


title: HISTORY
content:
As an integral part of the <i>systemd</i> project, <i>systemd-confext</i> was developed to provide a standardized and reliable mechanism for extracting and normalizing unit file configurations. Its emergence is tied to the increasing complexity and centrality of <i>systemd</i> in modern Linux distributions. It allows <i>systemd</i>'s diagnostic and analysis tools to consistently interpret and represent the effective state of unit files, crucial for validating configurations and troubleshooting service behavior.


title: PARAMETERS
content:
<b><b>COMMAND</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the operation to perform. Common commands include:<br><b>list</b>: Lists all available credentials.<br><b>get</b> <i>NAME</i>: Retrieves the value of a specific credential by its name.<br><b>set</b> <i>NAME</i>: Sets or updates the value of a credential. If not specified via <b>--file</b>, it reads from standard input.<br><b>rm</b> <i>NAME</i>: Removes a specific credential.<br><br><b><b>--file=</b><i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with the <b>set</b> command to specify a file from which to read the credential's value. If omitted, the value is read from standard input.<br><br><b><b>--raw</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>get</b>, outputs the raw credential value without any metadata. When used with <b>set</b>, indicates that the input is a raw credential value, bypassing any automatic JSON parsing.<br><br><b><b>--json=</b><i>pretty|yes|no</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls JSON output. <b>pretty</b> formats output for readability. <b>yes</b> outputs compact JSON. <b>no</b> (default) uses plain text for relevant commands.<br><br><b><b>--no-pager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b><b>--no-legend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the legend (column headers) for table output.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br>


title: DESCRIPTION
content:
The <b>systemd-creds</b> command-line utility is designed to manage sensitive credentials (such as API keys, passwords, and certificates) within the systemd ecosystem. It provides a secure mechanism for services to access this data without hardcoding it or relying on less secure methods like environment variables.<br><br>Credentials are stored in an encrypted format, typically in <i>/etc/systemd/creds</i> for system-wide services or <i>~/.config/systemd/creds</i> for user services. Services declare their need for specific credentials in their unit files using the <b>Credential=</b> option, allowing <b>systemd</b> to provide the decrypted data to the service at runtime, often via a temporary file descriptor.<br><br>This tool helps enforce the principle of least privilege and reduces the attack surface by centralizing credential management and ensuring sensitive data is not exposed unnecessarily.


title: CAVEATS
content:
<b>Permissions</b>: Managing system-wide credentials typically requires root privileges. User-specific credentials can be managed by the respective user.<br><br><b>Encryption</b>: Credentials are encrypted using system-specific or user-specific keys. This means credentials might not be easily portable between different systems or users without manual decryption and re-encryption.<br><br><b>Security Implications</b>: While <b>systemd-creds</b> enhances security by centralizing management, the underlying system's security (e.g., key protection, physical access) remains paramount. Credentials are only as secure as the system hosting them.


title: CREDENTIAL STORAGE LOCATION
content:
System-wide credentials are typically stored in <i>/etc/systemd/creds/</i>, while user-specific credentials reside in <i>~/.config/systemd/creds/</i>. These directories contain encrypted blobs of data, which <b>systemd-creds</b> decrypts and manages.


title: USAGE BY SERVICES
content:
Services declare their need for specific credentials in their <b>.service</b> unit files using the <b>Credential=</b> directive (e.g., <i>Credential=api-key:/path/to/api-key.txt</i>). <b>systemd</b> then provides the decrypted credential to the service, often via a temporary file descriptor or a file path in a secure, ephemeral filesystem, which the service can then read.


title: HISTORY
content:
<b>systemd-creds</b> was introduced as part of the <b>systemd</b> suite in version 249 (released around 2021). Its development aimed to provide a more robust and standardized method for managing sensitive data used by services, addressing limitations of prior approaches like environment variables or hardcoded paths, and integrating credential management directly into the <b>systemd</b> ecosystem.


title: SYNOPSIS
content:
While primarily managed by <code>systemctl</code> as a service unit, <code>systemd-cryptsetup</code> can be directly invoked for specific operations or debugging.<br><br><b><I>Service Unit Invocation (common):</I></b><br><b>systemctl [start|stop|status] systemd-cryptsetup@<I>name</I>.service</b><br><br><b><I>Direct Command Invocation:</I></b><br><b>systemd-cryptsetup [--help|--version]</b><br><b>systemd-cryptsetup <I>attach</I> <I>NAME</I> <I>DEVICE</I> <I>KEY_FILE</I> [<I>OPTIONS</I>]</b><br><b>systemd-cryptsetup <I>detach</I> <I>NAME</I></b>


title: PARAMETERS
content:
<b><b>-h, --help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b><b><I>attach</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operation to attach (open) an encrypted device. It requires specific arguments: <I>NAME</I>, <I>DEVICE</I>, <I>KEY_FILE</I>, and optionally <I>OPTIONS</I>.<br><br><b><b><I>detach</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operation to detach (close) an encrypted device, taking <I>NAME</I> as an argument.<br><br><b><b><I>NAME</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The desired device-mapper name for the decrypted volume (e.g., 'root', 'home').<br><br><b><b><I>DEVICE</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the encrypted backing block device (e.g., '/dev/sda2', '/dev/disk/by-uuid/...').<br><br><b><b><I>KEY_FILE</I></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to a key file used for unlocking the device. Use '-' to prompt for a passphrase interactively.<br><br><b><b>[<I>OPTIONS</I>]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated list of <code>cryptsetup</code> options, such as 'cipher=aes-xts-plain64', 'hash=sha256', 'keyslot=1', or '_netdev' for network-dependent devices. These are passed directly to <code>cryptsetup</code>.<br><br>


title: DESCRIPTION
content:
<code>systemd-cryptsetup</code> is a service manager that handles the activation and deactivation of LUKS-encrypted block devices during the system boot and shutdown processes. It integrates seamlessly with <code>systemd</code>'s dependency system, ensuring that encrypted devices are unlocked and available before services requiring them are started, and properly closed before shutdown is complete.<br><br>Its primary function is to interpret entries in the <code>crypttab(5)</code> file, which defines encrypted partitions and their unlocking parameters. For each entry, <code>systemd-cryptsetup-generator(8)</code> creates a corresponding <code>systemd-cryptsetup@.service</code> unit. When these units are activated (typically during boot), <code>systemd-cryptsetup</code> invokes <code>cryptsetup(8)</code> to open the specified encrypted device, prompts for a passphrase if necessary (e.g., when a key file is not provided), and creates the decrypted device-mapper mapping.<br><br>This command replaces older init-script based methods for managing encrypted volumes, offering improved parallelism, robust error handling, and better integration with the rest of the systemd ecosystem. It is crucial for systems that utilize encrypted root filesystems or other critical encrypted storage.


title: CAVEATS
content:
Debugging issues with <code>systemd-cryptsetup</code> can be challenging, especially during early boot phases, as logs might not be fully accessible or verbose enough. Care must be taken when modifying <code>crypttab(5)</code> entries, as incorrect configurations can lead to unbootable systems. Network-bound encryption devices (<code>_netdev</code> option) require network connectivity, which might not be readily available during very early boot, potentially leading to delays or boot failures if not properly managed (e.g., via <code>initramfs</code> network setup).


title: INTEGRATION WITH CRYPTTAB(5)
content:
The primary configuration source for <code>systemd-cryptsetup</code> is the <code>/etc/crypttab</code> file. Each line in this file describes an encrypted block device, its underlying physical device, a key file or passphrase source, and various options. <code>systemd-cryptsetup-generator(8)</code> reads this file during boot and creates instanced <code>systemd-cryptsetup@.service</code> units dynamically for each entry, which <code>systemd</code> then activates.


title: BOOT PROCESS ROLE
content:
<code>systemd-cryptsetup</code> services are typically pulled in very early during the boot process by targets like <code>cryptsetup.target</code> and <code>local-fs.target</code>. This ensures that encrypted file systems are unlocked and mounted before user-space services or applications requiring access to these file systems are started. This early execution requires it to operate effectively even before the full system environment is available.


title: SERVICE UNITS
content:
For each entry in <code>/etc/crypttab</code>, a dedicated <code>systemd-cryptsetup@<I>name</I>.service</code> unit is generated. For example, if you have an entry for a device named <code>data_vol</code>, a service unit <code>systemd-cryptsetup@data_vol.service</code> will be created. These units handle the actual <code>attach</code> and <code>detach</code> operations for the respective encrypted devices, allowing <code>systemctl</code> to manage them individually.


title: HISTORY
content:
<code>systemd-cryptsetup</code> emerged as part of the <code>systemd</code> project, aiming to modernize and streamline the boot process for Linux systems. Before <code>systemd</code>, encrypted volumes were typically handled by various init scripts (e.g., <code>cryptdisks</code> on Debian/Ubuntu, <code>cryptsys</code> on Red Hat based systems). <code>systemd-cryptsetup</code> (along with <code>systemd-cryptsetup-generator</code>) provides a unified, declarative, and dependency-aware mechanism for managing LUKS volumes, aligning with systemd's principles of parallelization and robust service management. Its development has focused on tighter integration with the kernel's device-mapper and <code>udev</code> subsystems, ensuring reliable device activation and deactivation.


title: SEE ALSO
content:
cryptsetup(8), crypttab(5), systemctl(1), systemd(1), systemd-cryptsetup-generator(8), systemd.special(7), udev(7)


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br><b><b>--diff</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a full diff for modified files, similar to the output of the <b>diff</b> command.<br><br><b><b>--diff-color[=WHEN]</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls color output for diffs. <b>WHEN</b> can be 'always', 'never', or 'auto' (default is 'auto').<br><br><b><b>--no-pager</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b><b>--no-legend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the legend for the output symbols.<br><br><b><b>--no-summary</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not print the summary of differences found.<br><br><b><b>--check-vendor</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Compares vendor configuration files with each other (e.g., within <i>/usr/lib/systemd/</i>) to find potential conflicts or overrides from different vendor paths, in addition to the default comparison.<br><br><b><b>--type=<i>TYPE</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only show files of a specific configuration type. Common types include 'service', 'socket', 'mount', 'timer', 'scope', 'slice', 'path', 'swap', 'automount', 'device', 'target', 'link', 'preset', 'journal-remote', 'journal-upload', 'logind', 'resolved', 'timesyncd', 'coredump', 'hostnamed', 'localectl', 'machined', 'networkd', 'nss-mymachines', 'oom', 'portabled', 'quotamgr', 'sleep', 'system', 'sysusers', 'tmpfiles', 'user', 'userdb', 'udev', 'units'.<br><br><b><b>--root=<i>PATH</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on an alternate root directory. All paths will be relative to this root.<br><br>


title: DESCRIPTION
content:
<i>systemd-delta</i> is a utility designed to identify and highlight differences between the vendor-supplied systemd configuration files and those that have been modified or created locally by the system administrator. It is an invaluable tool for understanding how local overrides affect system behavior, diagnosing configuration issues, and maintaining system consistency.<br><br>The command primarily compares files found in <i>/etc/systemd/</i> (and <i>/run/systemd/</i>) with their corresponding default versions in <i>/usr/lib/systemd/</i>. It can display whether a file is <i>new</i> (exists locally but not in vendor defaults), <i>deleted</i> (exists in vendor defaults but not locally), or <i>modified</i> (exists in both but has different content). For modified files, it can optionally show a detailed <i>diff</i>. This helps administrators quickly pinpoint which configurations have been altered from the system's defaults.


title: CAVEATS
content:
<i>systemd-delta</i> specifically targets <i>systemd</i> configuration files and does not analyze other system configurations. Its output can be extensive on systems with numerous local modifications, potentially requiring careful review. While it helps identify deviations, it does not suggest solutions or automatically revert changes.


title: OUTPUT SYMBOLS
content:
The command's output uses specific symbols to indicate the status of configuration files:<br><b>+</b>: Indicates a <i>new</i> file, found in <i>/etc/systemd/</i> or <i>/run/systemd/</i> but not in <i>/usr/lib/systemd/</i>.<br><b>-</b>: Indicates a <i>deleted</i> file, found in <i>/usr/lib/systemd/</i> but absent from <i>/etc/systemd/</i> and <i>/run/systemd/</i>.<br><b>!</b>: Indicates a <i>modified</i> file, present in both <i>/usr/lib/systemd/</i> and <i>/etc/systemd/</i> (or <i>/run/systemd/</i>) but with differing content.


title: HISTORY
content:
<i>systemd-delta</i> was introduced as part of the <i>systemd</i> suite, evolving alongside its development to provide administrators with enhanced introspection and troubleshooting capabilities for complex system configurations. It became available in <i>systemd</i> version 214 (released in 2014), reflecting <i>systemd</i>'s focus on robust configuration management and transparency.


title: PARAMETERS
content:
<b><b>--help</b>, <b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show a brief help message and exit.</I><br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Show the package version string and exit.</I><br><br><b><b>--quiet</b>, <b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Do not print the detected virtualization type to standard output. Instead, the exit code indicates the result: 0 if virtualization is detected, 1 otherwise.</I><br><br><b><b>--vm</b>, <b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Only detect classic hardware virtualization environments (virtual machines). Containerization technologies are ignored.</I><br><br><b><b>--container</b>, <b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Only detect software containerization environments. Classic hardware virtualization environments are ignored.</I><br><br><b><b>--chroot</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Only detect if the system is running inside a <b>chroot()</b> environment. This is considered a specific type of containerization and implies <b>--container</b>.</I><br><br>


title: DESCRIPTION
content:
<I><b>systemd-detect-virt</b> is a utility provided by the systemd project designed to identify whether the operating system is running inside a virtualized environment or a container. It can pinpoint the specific hypervisor or container technology in use, such as QEMU, KVM, VMware, Microsoft Hyper-V, Oracle VirtualBox, Xen, Docker, LXC, systemd-nspawn, and others.</I><br><br><I>The command outputs the detected virtualization type to standard output, or 'none' if no virtualization is found. It's an essential tool for scripts and applications that need to adapt their behavior based on the execution environment, allowing for optimizations or specific configurations whether on bare metal, within a VM, or inside a container. It employs various heuristics including DMI information, CPU flags, and device presence for its determination.</I>


title: CAVEATS
content:
<I><b>systemd-detect-virt</b> relies on various heuristics which, while generally robust, might not always be foolproof or could potentially be spoofed in highly controlled or malicious environments. The accuracy of detection can also be influenced by the hypervisor's configuration, as some allow guests to appear more like bare metal. In nested virtualization setups, the command might report the outer hypervisor depending on how virtualization is exposed to the inner guest.</I>


title: EXIT CODES
content:
<I><b>0</b>: Virtualization or containerization was detected, or no specific type was requested with filtering options.</I><br><I><b>1</b>: No virtualization or containerization was detected.</I><br><I><b>2</b>: An invalid command line argument was specified.</I>


title: HISTORY
content:
<I><b>systemd-detect-virt</b> emerged as part of the systemd project, which began around 2010 as a modern replacement for the traditional SysVinit daemon in Linux. As systemd's scope expanded to encompass more aspects of operating system management, the need for reliable environment detection became critical, particularly with the widespread adoption of cloud computing, containers, and virtual machines. This utility was developed to provide a standardized and consistent method for systemd components and other applications to query their execution environment, ensuring seamless integration within the systemd ecosystem.</I>


title: SYNOPSIS
content:
<b>systemctl disable</b> [<I>OPTIONS</I>...] <I>UNIT</I>...<br><b>systemctl disable</b> [<I>OPTIONS</I>...] <I>PATH</I>...


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of <b>systemd</b> and exits.<br><br><b><b>--root=</b><I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on a specific root directory <I>PATH</I> instead of the default root directory.<br><br><b><b>--runtime</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes changes only in the runtime directory (<b>/run/systemd/system</b>), which are lost on reboot.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overrides specific refusals to disable units, such as disabling units that are masked.<br><br><b><b>--now</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the unit(s) and also stops them immediately.<br><br><b><b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages from the command.<br><br>


title: DESCRIPTION
content:
The action of "systemd-disable" refers to preventing systemd units (like services, sockets, or timers) from being automatically started at system boot. This operation is primarily performed using the <b>systemctl disable</b> command. When a unit is disabled, <b>systemd</b> removes the symbolic links from the appropriate <b>.wants/</b> or <b>.requires/</b> directories in the systemd configuration (e.g., <b>/etc/systemd/system/*.wants/</b>). This ensures that during subsequent boot processes, <b>systemd</b> will not activate the disabled unit automatically. It's the opposite of <b>systemctl enable</b>, which creates these links to ensure a unit starts automatically. Disabling a unit only affects its auto-start behavior; it does not stop the unit if it is currently running. To stop a running unit, <b>systemctl stop</b> must be used.


title: CAVEATS
content:
The command "systemd-disable" itself does not exist as a standalone executable. The functionality to disable <b>systemd</b> units is provided by the <b>systemctl disable</b> command, which is the standard utility for controlling the <b>systemd</b> system and service manager. Disabling a unit prevents its automatic startup on subsequent boots but does not stop it if it is currently running. To stop a running unit, the <b>systemctl stop</b> command must be used separately, or the <b>--now</b> option can be used with <b>systemctl disable</b>.


title: HOW DISABLING WORKS INTERNALLY
content:
When a unit is disabled using <b>systemctl disable</b>, <b>systemd</b> removes the symbolic links that point from <b>/etc/systemd/system/*.wants/</b> or <b>/etc/systemd/system/*.requires/</b> (or their equivalents in <b>/usr/lib</b> or <b>/run</b>) to the unit's definition file. These symlinks are what <b>systemd</b> uses to determine which units to activate automatically when a specific target (like <b>multi-user.target</b>) is reached during boot. Removing these links ensures the unit is no longer automatically pulled into the boot process.


title: HISTORY
content:
The <b>systemd</b> initialization system, and consequently the <b>systemctl</b> utility, were introduced to Linux distributions starting in the early 2010s, gradually replacing older init systems like <b>SysVinit</b> and <b>Upstart</b>. <b>systemctl</b> was designed as the central command-line interface for controlling and querying the state of the <b>systemd</b> manager, making operations like enabling and disabling units a fundamental part of system administration in modern Linux environments.


title: SEE ALSO
content:
systemctl(1), systemctl enable(1), systemctl start(1), systemctl stop(1), systemctl status(1), systemd.unit(5)


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package version information.<br><br><b>--json=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Format output as JSON. Modes include <i>full</i>, <i>pretty</i>, <i>short</i>, <i>off</i> (default).<br><br><b>--suffix=<I>SUFFIX</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a suffix for temporary files created during analysis.<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b>--no-legend</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppress the legend (header) from the output.<br><br><b>--timestamp=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Control how timestamps are formatted in the output (<i>pretty</i>, <i>raw</i>, <i>off</i>).<br><br><b>--unit=<I>UNIT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze a specific system unit.<br><br><b>--user-unit=<I>UNIT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze a specific user unit.<br><br><b>--service-type=<I>TYPE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filter analysis by service type (e.g., <i>simple</i>, <i>forking</i>).<br><br><b>--wait=<I>BOOL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for the specified unit to finish before analyzing (default <i>yes</i>).<br><br><b>--no-block</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not wait for the unit to finish.<br><br><b>--list-paths=<I>BOOL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List paths for systemd-homed or systemd-machined instances.<br><br><b>--root=<I>PATH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a different root directory (like a chroot environment).<br><br><b>--machine=<I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on a specific machine or container by name.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze the user <b>systemd</b> instance.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze the system <b>systemd</b> instance (default).<br><br><b>--boot-id=<I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze a specific boot by its ID.<br><br><b>--this-boot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze the currently running boot.<br><br><b>--on-this-machine</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyze the currently running machine or container.<br><br><b>--full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dissect full, verbose information.<br><br><b>--no-full</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not dissect full information (less verbose).<br><br><b>--log-level=<I>LEVEL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the logging verbosity level.<br><br>


title: DESCRIPTION
content:
<b>systemd-dissect</b> is a powerful diagnostic tool for inspecting the internal state and configuration of various <b>systemd</b> instances. It can analyze the boot sequence of a running system, or delve into the specifics of an inactive system, a disk image, or even specific <b>systemd</b> components like <b>systemd-homed</b> encrypted homes, <b>systemd-machined</b> virtual machines, or <b>systemd-nspawn</b> containers. Its primary purpose is to aid in debugging and understanding the intricate workings of <b>systemd</b>, providing detailed insights into unit states, dependencies, and overall system behavior. It's an essential utility for system administrators and developers troubleshooting <b>systemd</b>-related issues.


title: CAVEATS
content:
The command might require elevated privileges (root) to access certain system states or disk images. Analyzing large images or complex states can consume significant system resources and time. Its output can be very detailed, requiring careful interpretation.


title: HISTORY
content:
<b>systemd-dissect</b> was introduced as part of the <b>systemd</b> project, designed to provide deeper introspection capabilities beyond what <b>systemd-analyze</b> offers. It allows for offline analysis of various <b>systemd</b> contexts, which is crucial for forensic analysis, debugging boot failures in unbootable systems, or examining the state of virtualized environments and containers managed by <b>systemd</b>. Its development reflects the increasing complexity of <b>systemd</b>-managed systems and the need for robust debugging tools.


title: SEE ALSO
content:
systemd(1), systemd-analyze(1), bootctl(1), systemd-homed(8), systemd-machined(8), systemd-nspawn(1)


title: PARAMETERS
content:
<b><b>-p</b>, <b>--path</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escapes the input <i>STRING</i> for use in file system paths. This is useful when a unit name needs to be derived directly from a path.<br><br><b><b>-u</b>, <b>--unit</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Escapes the input <i>STRING</i> for use in systemd unit names. This is the default mode if neither <b>--path</b> nor <b>--unit</b> is specified and the input contains path separators.<br><br><b><b>--suffix=</b><i>SUFFIX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When escaping for a unit name, append the specified <i>SUFFIX</i> (e.g., '.service', '.mount') to the escaped string.<br><br><b><b>--template=</b><i>TEMPLATE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When escaping for a unit name, use the specified <i>TEMPLATE</i> unit name (e.g., 'getty@.service'). The escaped string will be inserted into the template.<br><br><b><b>--unescape</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the reverse operation: unescapes the input <i>STRING</i>. This converts a systemd-escaped string back to its original form.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help text and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br>


title: DESCRIPTION
content:
<i>systemd-escape</i> is a utility command designed to escape or unescape strings for use in systemd unit names, paths, or other systemd-specific contexts. Systemd units often need to be dynamically generated or referenced based on arbitrary strings, such as file paths or network interface names. However, not all characters are valid within unit names or filenames, especially when using paths directly as unit identifiers. This command ensures that any problematic characters (like '/', ':', or spaces) are converted into a safe, unambiguous format that systemd can correctly interpret and reverse. It's particularly useful when creating instantiated unit files (e.g., service@.service) where the instance name is derived from a path or other string containing special characters. By providing an escaped string, systemd can reliably map it to a valid unit name or file path.


title: CAVEATS
content:
The escaping rules used by <i>systemd-escape</i> are specific to systemd's internal conventions and may differ significantly from other escaping mechanisms (e.g., URL encoding, shell escaping, JSON escaping). It should only be used for strings intended for systemd unit names or path components. Attempting to use this for general string escaping or for systems not managed by systemd will likely lead to incorrect results.


title: ESCAPING RULES
content:
<i>systemd-escape</i> replaces characters that are not alphanumeric or '.', '-', '_' with C-style backslash escapes. For example, '/' becomes '\x2f', and a space becomes '\x20'. This ensures that the resulting string is valid for use as a filename or unit name and can be unambiguously reversed.


title: COMMON USE CASES
content:
One common use case is creating 'template' units (e.g., <code>systemd-escape --template='my-service@.service' /path/to/resource</code>) which generate specific unit names like <code>my-service@path-to-resource.service</code>. This allows scripts to dynamically activate units based on external factors without manually managing complex escaping logic.


title: HISTORY
content:
<i>systemd-escape</i> is an integral part of the systemd suite, which was initially released in 2010. Its necessity arose from systemd's design philosophy of allowing dynamic and flexible unit management, often tying unit names to real-world entities like file paths, mount points, or device names. To achieve this safely and reliably, a consistent method for converting arbitrary strings into valid, unique, and predictable unit identifiers was required, leading to the development of this dedicated escape utility.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a short help text and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the version string and exit.<br><br><b>--root=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the specified root directory <i>PATH</i> instead of the system root (/). This is useful for configuring disk images or chrooted environments.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces systemd-firstboot to run even if the first boot setup has already been completed, indicated by the absence of the first-boot marker file.<br><br><b>--reboot</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reboots the system after successful execution of all first boot tasks.<br><br>


title: DESCRIPTION
content:
systemd-firstboot is a utility designed to perform initial system setup tasks during the first boot of a newly installed or reset operating system.<br><br>Its primary purpose is to automate common post-installation configurations, ensuring that the system is ready for use without manual intervention. It checks for a specific "first boot" state, typically indicated by the presence of a file like <i>/etc/.firstboot</i> or an empty <i>/etc</i> directory. If this state is detected, systemd-firstboot proceeds to apply various configurations, which might include setting up initial system users and groups via systemd-sysusers(8), creating temporary files and directories via systemd-tmpfiles(8), or applying service preset configurations via systemd-preset(8).<br><br>After successful execution, systemd-firstboot typically clears the "first boot" indicator to prevent subsequent runs, ensuring that these one-time setup tasks are not repeated. This command plays a crucial role in creating a consistent and automated initial system environment for various Linux distributions.


title: CAVEATS
content:
systemd-firstboot relies on specific markers (e.g., <i>/etc/.firstboot</i> or an empty <i>/etc</i> directory) to determine if it should run. If these markers are manually removed or not present, the first boot setup will not occur.<br><br>Forcing its execution with <i>--force</i> on an already configured system might lead to unintended changes or conflicts with existing configurations. It's designed for a specific initial state and might not handle subsequent re-runs gracefully without <i>--force</i>.


title: EXECUTION TRIGGER
content:
systemd-firstboot is typically invoked by a <b>systemd</b> service unit (e.g., <i>systemd-firstboot.service</i>) which is enabled to run very early in the boot process, conditioned on the presence of the first-boot marker.


title: FIRST BOOT MARKER
content:
The presence of the file <i>/etc/.firstboot</i> (or an empty <i>/etc</i> directory, depending on configuration) acts as the primary trigger for systemd-firstboot. Upon successful completion, this file is removed to prevent subsequent runs.


title: HISTORY
content:
systemd-firstboot was introduced as part of the <b>systemd</b> project, which aimed to replace the traditional <i>SysVinit</i> system on Linux.<br><br>Its development emerged from the need to standardize and streamline the initial system setup process across different Linux distributions. Prior to systemd-firstboot, initial setup was often handled by disparate, distribution-specific scripts. By integrating this functionality into systemd, it provides a more robust, consistent, and declarative way to manage first-boot configurations, aligning with systemd's broader goal of unified system management.


title: SEE ALSO
content:
systemd(1), systemctl(1), systemd-sysusers(8), systemd-tmpfiles(8), systemd-preset(8), useradd(8), passwd(1)


title: SYNOPSIS
content:
<code><b>systemd-hostnamed.service</b></code> is a background service managed by <code><b>systemd</b></code>. User interaction for its functionality is primarily via the <code><b>hostnamectl</b></code> utility:<br><br><pre><code><b>hostnamectl</b> [<i>OPTIONS</i>] [<i>COMMAND</i>]</code></pre>


title: PARAMETERS
content:
<b><b>status</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current system hostname, icon name, chassis, machine ID, boot ID, and other system information.<br><br><b><b>set-hostname</b> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the system's static hostname. This name is stored in <i>/etc/hostname</i>.<br><br><b><b>set-pretty-hostname</b> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a human-readable "pretty" hostname, often used in graphical user interfaces.<br><br><b><b>set-machine-id</b> <i>ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the machine's unique ID. This ID is typically stored in <i>/etc/machine-id</i>.<br><br><b><b>--static</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <code>set-*</code> commands to ensure the change is persistent and saved to disk.<br><br><b><b>--transient</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <code>set-hostname</code> to set a hostname that is only valid until the next reboot.<br><br><b><b>--pretty</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used with <code>set-hostname</code> to simultaneously set the pretty hostname to the same value as the static hostname.<br><br><b><b>-H</b>, <b>--host</b> <i>USER@HOST</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on a remote host via SSH, allowing remote management of hostname properties.<br><br>


title: DESCRIPTION
content:
<code>systemd-hostnamed.service</code> is a core <code>systemd</code> service responsible for managing various host-specific identifiers. This includes the system's static hostname (e.g., <i>mycomputer.local</i>), the pretty hostname (a more descriptive and human-readable name like "My Laptop"), and the unique machine ID. It provides a D-Bus interface, allowing other system components and user utilities like <code>hostnamectl(1)</code> to query and modify these properties dynamically and persistently.<br><br>The service ensures consistency of hostname information across the system, updating relevant configuration files like <i>/etc/hostname</i> and <i>/etc/machine-id</i> when changes are made. It also handles transient hostnames, which are active only until the next reboot, alongside static ones that persist across reboots. By centralizing hostname management, <code>systemd-hostnamed.service</code> streamlines system configuration and provides a robust API for applications needing to identify the host. It runs automatically in the background as part of the <code>systemd</code> init system.


title: CAVEATS
content:
<code>systemd-hostnamed.service</code> requires the D-Bus message bus to operate and expose its API. <br><br>Direct interaction with the <code>systemd-hostnamed.service</code> process is generally not required or recommended; instead, use the <code>hostnamectl(1)</code> utility, which communicates with the service via its D-Bus interface. <br><br>Modifying system identifiers like the hostname or machine ID requires appropriate administrative privileges (e.g., root access or PolicyKit permissions). Changes made without explicitly specifying <code>--static</code> or <code>--transient</code> typically apply to both the static and transient hostnames if applicable.


title: D-BUS INTERFACE
content:
<code>systemd-hostnamed.service</code> exposes a well-defined D-Bus interface (<i>org.freedesktop.hostname1</i>) that allows other processes and applications to programmatically interact with and modify host-related properties without direct file manipulation.


title: CONFIGURATION FILES
content:
The service manages and interacts with standard configuration files such as <i>/etc/hostname</i> (for the static hostname) and <i>/etc/machine-id</i> (for the unique machine identifier). It also supports managing the "pretty hostname" which is not stored in a traditional file but via other <code>systemd</code> mechanisms or D-Bus properties.


title: HISTORY
content:
<code>systemd-hostnamed.service</code> was introduced as part of the <code>systemd</code> project, aiming to modernize and centralize the management of system hostnames and related identifiers. Prior to <code>systemd</code>, hostname management was often handled by simpler scripts or directly by the <code>hostname(1)</code> command, sometimes leading to inconsistencies between different system components. <br><br>With <code>hostnamed</code>, a consistent D-Bus API became available, allowing applications to reliably query and set these properties. Its development aligned with <code>systemd</code>'s broader goal of providing well-defined APIs for common system tasks, improving interoperability and robustness across Linux distributions.


title: SYNOPSIS
content:
<b>systemd-id128</b> [<i>OPTIONS...</i>] <i>COMMAND</i> [<i>ID...</i>]<br><br>Examples:<br><b>systemd-id128 new</b><br><b>systemd-id128 machine-id</b><br><b>systemd-id128 encode</b> <i>fedcba9876543210fedcba9876543210</i><br>


title: PARAMETERS
content:
<b>new</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates and prints a new, truly random 128-bit ID in hexadecimal format.<br><br><b>machine-id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the unique machine ID of the current system, typically read from <i>/etc/machine-id</i>.<br><br><b>boot-id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the unique ID of the current system boot, generated per boot.<br><br><b>varvfs-id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the 128-bit ID identifying the random seed file in <i>/var/lib/systemd/random</i>.<br><br><b>uuid</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the 128-bit ID associated with the current user, based on their UID.<br><br><b>list [<NAME...>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists known 128-bit IDs. If <i><NAME...></i> is provided, lists specific IDs; otherwise, lists common system IDs.<br><br><b>encode <HEX></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Encodes a 32-character hexadecimal 128-bit ID string into a 22-character base64-encoded string.<br><br><b>decode <BASE64></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Decodes a 22-character base64-encoded 128-bit ID string back into its 32-character hexadecimal representation.<br><br><b>print-id [--pretty|--global|--uuid|--machine-id|--boot-id]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a specific ID. <i>--pretty</i> formats it with hyphens. Can specify which ID to print.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of the machine ID, including its persistence and any issues.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br><b>--json=pretty|full|short|compact</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats output as JSON, with different levels of verbosity and formatting.<br><br><b>--no-pager</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not pipe output into a pager.<br><br><b>--strict</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables strict parsing of command line arguments, failing on unknown options.<br><br>


title: DESCRIPTION
content:
<i>systemd-id128</i> is a utility included with the <i>systemd</i> suite that provides functionality for generating, managing, and converting 128-bit IDs, also known as UUIDs (Universally Unique Identifiers) or GUIDs (Globally Unique Identifiers). These IDs are crucial for <i>systemd</i>'s internal operations, identifying machines, boots, users, and various system components uniquely. The command allows users to retrieve the system's machine ID, the current boot ID, and even a user's unique ID. Beyond simple display, <i>systemd-id128</i> can generate new random 128-bit IDs, and offers conversion utilities to encode these IDs from their standard hexadecimal representation to a base64 format and vice-versa. This tool is fundamental for <i>systemd</i>-based systems requiring robust and unique identification for logging, configuration, and service management.


title: CAVEATS
content:
The <i>machine-id</i> is persistent across reboots unless manually changed or regenerated. Exposing it publicly could potentially allow tracking of a specific machine.<br>The <i>boot-id</i> is unique for each boot, but generally not globally unique across all boots of all machines.<br>Care should be taken when using the <i>new</i> command, as generating excessive IDs or replacing critical system IDs without understanding the implications can lead to system instability.


title: ID TYPES EXPLAINED
content:
<i>systemd-id128</i> interacts with several types of 128-bit IDs:<br><b>Machine ID</b>: A unique identifier for the entire system, persistent across reboots, stored in <i>/etc/machine-id</i>. It's crucial for systemd-journald and other services.<br><b>Boot ID</b>: A unique identifier for each system boot. It changes every time the system is restarted.<br><b>User UUID</b>: A UUID derived from a user's UID, providing a stable identifier for a user account across sessions.


title: ID FORMAT AND ENCODING
content:
128-bit IDs are typically represented as 32 hexadecimal characters (e.g., <i>1234567890abcdef1234567890abcdef</i>).<br><i>systemd-id128</i> provides <i>encode</i> and <i>decode</i> commands to convert these IDs to and from a compact 22-character base64 representation, which is useful for situations where shorter strings are preferred, such as in DNS records or command-line arguments.


title: HISTORY
content:
<i>systemd-id128</i> is an integral part of the <i>systemd</i> project, introduced early in its development lifecycle. Its functionality underpins <i>systemd</i>'s robust system identification scheme, which relies heavily on 128-bit IDs for various purposes, including logging, journal entries, and service instance identification. It formalizes and provides a standardized way to interact with these crucial identifiers within the <i>systemd</i> ecosystem, rather than relying on external tools like <i>uuidgen</i> for system-level ID management.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the systemd suite and exits.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all currently active inhibition locks on the system.<br><br><b>--what=<I>WHAT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies what actions to inhibit. Multiple values can be separated by colons, e.g., 'shutdown:sleep:idle'.<br><br><b>--who=<I>WHO</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A short, descriptive string identifying who is requesting the inhibition, typically an application or user.<br><br><b>--why=<I>WHY</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A human-readable reason for the inhibition, explaining why the lock is needed.<br><br><b>--mode=<I>MODE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the inhibition mode: <I>block</I> (default, prevents action), <I>delay</I> (delays action for a short period), or <I>kick</I> (forces session termination).<br><br><b>--scope=<I>SCOPE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the scope of the inhibition: <I>user</I> (default, tied to the user session via <I>logind</I>) or <I>system</I> (system-wide via <I>systemd</I>).<br><br><b>--terminate-on-close</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Ensures the inhibited <I>COMMAND</I> is terminated if its standard input, output, or error streams are closed.<br><br><b>--no-block</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acquires the inhibition lock and then immediately exits. The lock remains active as long as the client process is running or its controlling TTY is open.<br><br><b>--kill-when-unused</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Releases the inhibition lock when the executed <I>COMMAND</I> exits or is terminated, even if <I>systemd-inhibit</I> was started with <I>--no-block</I>.<br><br><b>--dump</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the internal state of active inhibition locks in a machine-readable format.<br><br>


title: DESCRIPTION
content:
<I>systemd-inhibit</I> is a command-line utility used to execute a program while holding a system inhibition lock. This lock prevents critical system actions such as <I>shutdown</I>, <I>sleep</I>, <I>idle</I>, or the handling of power and lid-switch keys from occurring. It's particularly useful for ensuring uninterrupted operation during sensitive tasks like data backups, system updates, media burning, or presentations, where an unexpected system state change could lead to data loss or disruption.<br><br>When run with a <I>COMMAND</I>, <I>systemd-inhibit</I> acquires the specified inhibition lock(s) via the <I>systemd-logind</I> service and then executes the <I>COMMAND</I>. The lock is automatically released when the <I>COMMAND</I> terminates. If no <I>COMMAND</I> is provided, <I>systemd-inhibit</I> will hold the lock indefinitely until it is manually terminated, effectively blocking the specified actions until the process exits.<br><br>The command offers granular control over what is inhibited (<I>--what</I>), who is requesting the lock (<I>--who</I>), the reason for the lock (<I>--why</I>), and the behavior mode of the lock (<I>--mode</I>), such as <I>block</I> (default), <I>delay</I>, or <I>kick</I>. It also allows listing current active locks using the <I>--list</I> option.


title: CAVEATS
content:
While <I>systemd-inhibit</I> is effective for preventing unintended system actions, it relies on the cooperative nature of <I>systemd</I> and its components like <I>logind</I>. It is not a security measure and can potentially be overridden by root privileges or direct D-Bus calls. Misuse or improper termination of the <I>systemd-inhibit</I> process or its child <I>COMMAND</I> (especially when using <I>--no-block</I> without <I>--kill-when-unused</I> properly) could lead to a persistent inhibition lock, preventing legitimate system power management actions until the lock is manually released or the associated process is terminated.


title: HISTORY
content:
The <I>systemd-inhibit</I> command is an integral part of the <I>systemd</I> init system, which gained widespread adoption in Linux distributions as a replacement for SysVinit and Upstart. Its development reflects the modern approach to power management and session control on Linux, primarily managed through the <I>systemd-logind</I> service and D-Bus. It provides a standardized and robust mechanism for applications and scripts to temporarily prevent system-wide power-related actions, moving away from disparate or less integrated inhibition methods used in older Linux environments.


title: SYNOPSIS
content:
To manage the <b>systemd-localed.service</b> unit:<br><b>systemctl</b> <i>command</i> <b>systemd-localed.service</b><br><br>Examples:<br><b>systemctl status systemd-localed.service</b><br><b>systemctl start systemd-localed.service</b><br><b>systemctl stop systemd-localed.service</b><br><b>systemctl enable systemd-localed.service</b><br><b>systemctl disable systemd-localed.service</b>


title: PARAMETERS
content:
<b>N/A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;systemd-localed.service itself, when managed via <b>systemctl</b>, does not accept direct command-line parameters. The underlying <b>systemd-localed</b> daemon also does not expose user-configurable command-line options; its behavior is controlled through D-Bus calls and system configuration files.<br><br>


title: DESCRIPTION
content:
systemd-localed.service is a core systemd service responsible for managing the system's locale settings, keyboard layout, and console font. It provides a D-Bus interface for other services and applications to query and modify these configurations. Instead of directly editing configuration files like /etc/locale.conf or /etc/vconsole.conf, users and tools are encouraged to interact with systemd-localed via the <b>localectl</b> command-line utility. This service ensures a consistent and centralized approach to locale management across the system. It is typically activated on demand (socket-activated) when a client requests its services, rather than running continuously as a background daemon from boot. Its primary role is to bridge the gap between user-friendly tools and the underlying system configuration files, ensuring proper validation and application of locale-related settings.


title: CAVEATS
content:
While <b>systemd-localed.service</b> manages locale settings, the actual locale data (e.g., character sets, collation rules) must be installed on the system (often provided by <i>glibc-locale</i> or similar packages).<br>Changes made via <b>localectl</b> (which uses <b>systemd-localed</b>) are typically applied immediately but may require a reboot or logging out and back in for some applications to fully recognize the new settings, especially for GUI environments.<br>For per-user locale settings, environment variables like <b>LANG</b> or <b>LC_*</b> should be set in user-specific shell configuration files (e.g., <i>~/.bashrc</i>, <i>~/.profile</i>), which override system-wide settings.


title: CONFIGURATION FILES
content:
<b>systemd-localed</b> primarily interacts with the following files:<br><b>/etc/locale.conf</b>: Defines the system-wide locale settings.<br><b>/etc/vconsole.conf</b>: Defines the system-wide console keyboard layout and font.<br>Changes made via <b>localectl</b> are written to these files by <b>systemd-localed</b>.


title: D-BUS INTERFACE
content:
The service exposes a D-Bus interface (on the system bus, at <i>org.freedesktop.locale1</i>) that allows applications and tools like <b>localectl</b> to query and set system locale, keyboard, and console font settings. This programmatic interface ensures that all tools use a consistent method for managing these critical system properties.


title: HISTORY
content:
Before systemd, locale settings were primarily managed by directly editing configuration files such as <i>/etc/locale.conf</i> (or distribution-specific files like <i>/etc/default/locale</i>) and <i>~/.bashrc</i>. Console keyboard layouts and fonts were often configured via <i>/etc/vconsole.conf</i>. With the advent of systemd, the management of these settings was centralized under the <b>systemd-localed</b> daemon and its <b>systemd-localed.service</b> unit. This shift aimed to provide a more robust, D-Bus-enabled, and programmatically accessible interface for system-wide locale configuration, ensuring consistency and simplifying administration. It integrates closely with the <b>localectl</b> command-line tool, which became the preferred method for users to interact with these settings.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show a help message and exit.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show package version information and exit.<br><br><b>--commit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write a new machine ID to <i>/etc/machine-id</i>. This is the default action if no other action-specific options like <i>--template</i> are provided.<br><br><b>--root=PATH</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operate on an alternate root directory specified by <i>PATH</i> instead of the real root directory. Useful for chroot or container environments.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force the generation and writing of a new machine ID, even if <i>/etc/machine-id</i> already exists and contains a valid ID. This will overwrite the existing ID without prompting.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without actually writing any changes to disk. It shows what actions would be taken.<br><br><b>--template</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate a new random machine ID and print it to standard output. This ID is not written to <i>/etc/machine-id</i> or any other file.<br><br>


title: DESCRIPTION
content:
The <b>systemd-machine-id-setup</b> command is a utility provided by <i>systemd</i> to manage the unique machine ID of a system. This ID is stored in the <i>/etc/machine-id</i> file and serves as a stable, unique identifier for the host. It's crucial for various system services like D-Bus, the <i>systemd</i> journal, and DHCP clients that rely on a consistent host identifier.<br><br>If the <i>/etc/machine-id</i> file is missing or empty, this command can be used to generate a new, random 32-character hexadecimal ID and write it to the file. It ensures that each system installation has a distinct identity, which is important for network services and logging aggregation. Typically, this setup happens automatically during the operating system installation or first boot through tools like <i>systemd-firstboot(1)</i>, but it can be manually invoked if the ID needs to be regenerated or if the file was inadvertently deleted.


title: CAVEATS
content:
Care should be taken when regenerating the machine ID on an already running system, especially if it's integrated with services or monitoring systems that rely on the existing ID. While regenerating is safe for most services, some distributed systems might require re-registration or configuration changes. It's generally recommended to set the machine ID once during installation and avoid changing it unless absolutely necessary. Using <i>--force</i> will overwrite any existing ID without warning.


title: THE /ETC/MACHINE-ID FILE
content:
This file contains a 32-character hexadecimal string that uniquely identifies the host. It should be kept consistent across reboots and is used by various system components for stable identification. If the file is empty or missing, <b>systemd-machine-id-setup</b> or other <i>systemd</i> tools will typically generate a new one during early boot.


title: MACHINE ID AND PRIVACY
content:
While the machine ID provides unique identification for system services, it does not contain any personally identifiable information and is generated randomly. It's a local identifier and not designed for external tracking, though it could potentially be used in conjunction with other data for such purposes if exposed externally.


title: HISTORY
content:
The <b>systemd-machine-id-setup</b> command is an integral part of the <i>systemd</i> initialization system, which largely replaced the traditional SysVinit in many Linux distributions. The concept of a unique machine ID (<i>/etc/machine-id</i>) became central with <i>systemd</i>'s design for better host identification, especially for journaling and networking. This command was introduced as part of the broader <i>systemd</i> suite to ensure the proper and consistent setup of this critical system identifier, simplifying boot-time configuration and system-level unique identification.


title: SYNOPSIS
content:
<b>systemd-mount</b> [<i>OPTIONS...</i>] <i>WHAT</i> [<i>WHERE</i>]<br><b>systemd-mount</b> [<i>OPTIONS...</i>] <b>--list</b>


title: PARAMETERS
content:
<b>WHAT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source of the mount operation. This can be a device path (e.g., <i>/dev/sdb1</i>), a UUID (e.g., <i>UUID=...</i>), a label (e.g., <i>LABEL=...</i>), a network share (e.g., <i>//server/share</i>), or a source path for a bind mount.<br><br><b>WHERE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the absolute path to the mount point directory. This directory will be created if it doesn't exist and <b>--mkdir</b> is used.<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short help message and exits.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows a short version string and exits.<br><br><b>--list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists existing mount and automount units, including those derived from <i>/etc/fstab</i>, and exits.<br><br><b>--automount</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates an automount unit instead of a mount unit. The filesystem will be mounted only when it is first accessed.<br><br><b>--fsck=[yes|no|auto]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls whether to run a filesystem check (fsck) before mounting. Defaults to 'auto'.<br><br><b>--options=STRING</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A comma-separated string of mount options to pass to the mount command (e.g., '<i>ro,nosuid</i>').<br><br><b>--property=ASSIGNMENT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a systemd unit property for the generated mount unit (e.g., '<i>TimeoutSec=30</i>'). Can be specified multiple times.<br><br><b>--description=TEXT</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the description for the generated mount unit.<br><br><b>--mkdir[=MODE]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates the mount point directory if it does not exist. An optional mode (octal) can be specified; defaults to <i>0755</i>.<br><br><b>--timeout=SECS</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a timeout for the mount operation. If the mount does not complete within this time, the operation fails.<br><br><b>--no-block</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Does not wait for the mount operation to finish. The command returns immediately.<br><br><b>--force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the creation and start of the unit, even if the mount point or device is already in use. Can unmount existing mounts if needed.<br><br><b>--discover</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Discovers existing mount points defined in <i>/etc/fstab</i> and attempts to create and activate corresponding units. Use with <b>--list</b> or without WHAT/WHERE.<br><br>


title: DESCRIPTION
content:
<b>systemd-mount</b> is a utility for creating and managing transient systemd <i>mount</i> and <i>automount</i> units from the command line. It provides a convenient way to temporarily mount file systems without needing to manually write .mount unit files. This command integrates seamlessly with the systemd ecosystem, allowing for advanced control over mount options, dependencies, and lifecycle management. It can handle various sources like device nodes, UUIDs, labels, and network shares, and mount them to specified directories. While primarily designed for transient operations, <b>systemd-mount</b> can also discover and manage existing mount points defined in <i>/etc/fstab</i>, making it a versatile tool for both temporary and persistent filesystem management within a systemd environment.


