# CommandSection

title: DESCRIPTION
content:
<i>flashrom</i> is a versatile, open-source utility for identifying, reading, writing, verifying, and erasing flash ROM chips. It's widely used for managing BIOS/UEFI firmware on motherboards, but also supports firmware on network cards, FPGAs, and various embedded devices. By supporting a broad range of hardware programmers (like internal mainboard programmers, external SPI, and parallel port devices) and thousands of flash chips, <i>flashrom</i> provides a free and open-source alternative to proprietary vendor-specific tools. It's a critical tool for projects like coreboot and Libreboot, enabling users to install, update, or back up custom or alternative firmware. Due to its direct hardware access, extreme caution is advised during use.


title: CAVEATS
content:
Using <i>flashrom</i> carries significant risks. Incorrect usage, unsupported hardware, or power interruptions during flashing can permanently 'brick' your device, rendering it unusable. Always ensure you have a backup of your existing firmware before attempting any write or erase operations. <i>flashrom</i> often requires root privileges to access hardware directly, which adds another layer of risk if not used carefully. Verify chip and programmer compatibility meticulously before proceeding.


title: SUPPORTED PROGRAMMERS
content:
<i>flashrom</i> supports a wide range of hardware programmers, including internal (mainboard) programmers (e.g., Intel FWH/LPC, AMD SPI, Intel SPI), external SPI programmers (e.g., CH341A, FT2232-based devices, Bus Pirate), parallel port programmers (e.g., BLC-style, DediProg), and others like Raspberry Pi GPIO, Arduino, and various USB-based devices. The exact list depends on the <i>flashrom</i> build and connected hardware.


title: SUPPORTED CHIPS
content:
<i>flashrom</i> boasts support for thousands of flash ROM chips from numerous manufacturers, encompassing NOR flash chips (like those from Macronix, Winbond, Spansion, SST) and certain NAND flash chips. It supports chips with various interfaces, including SPI, Parallel, and FWH/LPC. The continuous development ensures ongoing support for new and legacy hardware.


title: TYPICAL USE CASES
content:
The primary uses for <i>flashrom</i> include backing up existing BIOS/UEFI firmware, updating firmware to newer versions (especially for custom or open-source firmware like coreboot/Libreboot), restoring corrupted firmware, or flashing firmware onto network cards, embedded systems, and other devices containing flashable ROMs.


title: HISTORY
content:
Development of <i>flashrom</i> began around 2007, primarily driven by the coreboot project community. Its creation aimed to provide a robust, free, and open-source tool for flashing various firmware chips, circumventing the need for proprietary and often Windows-only vendor utilities. It quickly evolved to support a vast array of flash ROM chips and hardware programmers, becoming an indispensable tool for firmware enthusiasts, developers, and those seeking to install open-source firmware like coreboot or Libreboot.


title: PARAMETERS
content:
<b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the operation on the system-wide installation.<br><br><b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the operation on the per-user installation.<br><br><b>--installation=<I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform the operation on a specific named installation (default: system).<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show command-line help for the command or subcommand.<br><br><b>--version</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show the Flatpak version.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print debug information during operation.<br><br><b>--ostree-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print OSTree debug information during operation.<br><br>


title: DESCRIPTION
content:
<i>flatpak</i> is a cutting-edge universal software packaging and distribution system for Linux. It aims to revolutionize how applications are built, distributed, and run, solving the long-standing challenge of application fragmentation across diverse Linux distributions. <br><br>Unlike traditional package managers (like apt or dnf) that install applications directly into the system, <i>flatpak</i> packages applications with all their necessary dependencies, including specific library versions, into self-contained bundles. These bundles are then run in isolated sandboxes, enhancing security by limiting an application's access to the rest of the system. <br><br>Key benefits include distribution independence, consistent application behavior, improved security through sandboxing, and simplified updates. Developers can package their applications once and expect them to run consistently across any <i>flatpak</i>-enabled Linux environment. Users gain access to the latest software, often directly from upstream developers, without waiting for distribution-specific packaging.


title: CAVEATS
content:
While <i>flatpak</i> offers significant advantages, there are some considerations. Applications often have larger disk footprints due to bundling dependencies that might already exist on the system. Some applications may exhibit theme inconsistencies or limited integration with system-wide features. Initial setup might require adding remote repositories before installing applications. Network access is often required for installation and updates.


title: COMMON SUBCOMMANDS
content:
The <i>flatpak</i> command operates primarily through subcommands, which are essential for its functionality. Some of the most frequently used include: <br><b>install</b>: Installs an application or runtime. <br><b>update</b>: Updates installed applications and runtimes. <br><b>run</b>: Executes an installed Flatpak application. <br><b>remove</b>: Removes an installed application or runtime. <br><b>list</b>: Lists installed applications and runtimes. <br><b>info</b>: Displays detailed information about a Flatpak application or runtime. <br><b>search</b>: Searches for applications in configured Flatpak remotes. <br><b>remote</b>: Manages Flatpak remote repositories.


title: HISTORY
content:
<i>flatpak</i> originated as 'xdg-app', developed by Alexander Larsson at Red Hat, aiming to provide a robust framework for desktop application distribution on Linux. It was first officially released in 2016 under the new name <i>flatpak</i>, becoming a key component of the freedesktop.org initiative. Its development was driven by the need for a unified solution to the challenges faced by application developers targeting a fragmented Linux ecosystem, offering a stable runtime environment independent of the underlying distribution.


title: SYNOPSIS
content:
<b>flatpak mask</b> [<I>OPTIONS</I>]<br><b>flatpak mask --set</b> [<I>OPTIONS</I>] <I>APPLICATION_ID</I>...<br><b>flatpak mask --unset</b> [<I>OPTIONS</I>] <I>APPLICATION_ID</I>...<br><b>flatpak mask --remove</b> [<I>OPTIONS</I>] <I>APPLICATION_ID</I>...<br><b>flatpak unmask</b> [<I>OPTIONS</I>] <I>APPLICATION_ID</I>... (alias for <b>flatpak mask --remove</b>)


title: PARAMETERS
content:
<b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply the mask operation to the system-wide Flatpak installation. This usually requires root privileges.<br><br><b><b>--user</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Apply the mask operation to the current user's Flatpak installation. This is the default if neither <b>--system</b> nor <b>--user</b> is specified.<br><br><b><b>--set</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set a mask for the specified Flatpak <I>APPLICATION_ID</I>s. This prevents them from being updated or installed.<br><br><b><b>--unset</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unset a specific mask entry for the specified Flatpak <I>APPLICATION_ID</I>s. This makes the application eligible for updates again, but only removes an exact match.<br><br><b><b>--remove</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove all mask entries for the specified Flatpak <I>APPLICATION_ID</I>s, completely unmasking them.<br><br><b><b>--arch</b>=<I>ARCH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When setting a mask, apply it only for a specific architecture (e.g., <i>x86_64</i>, <i>aarch64</i>).<br><br><b><I>APPLICATION_ID</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more Flatpak application IDs (e.g., <i>org.gnome.GEdit</i>, <i>org.mozilla.Firefox</i>). Required for <b>--set</b>, <b>--unset</b>, and <b>--remove</b> operations.<br><br>


title: DESCRIPTION
content:
Masking in Flatpak prevents specific applications from being updated or even installed, effectively hiding them from the system's normal update and listing processes. This command is primarily used by administrators or advanced users to maintain specific versions of applications, prevent automatic updates of certain apps, or temporarily hide an application without uninstalling it. When an application is masked, Flatpak's update operations will ignore it, and it won't appear in lists of available updates. The <b>flatpak mask</b> command can be used to list currently masked applications, as well as to set, unset, or remove masks for specific application IDs. Masking can be applied system-wide or per-user.


title: CAVEATS
content:
Masking an application will prevent it from receiving important security updates and bug fixes, potentially leaving your system vulnerable or leading to unexpected behavior.<br>Masking only affects updates and installations; it does not uninstall the application if it is already installed.<br>System-wide masking (<b>--system</b>) requires administrative privileges (root).<br>Be cautious when masking core components or dependencies, as this could break other applications that rely on them.


title: LISTING MASKS
content:
When invoked without <b>--set</b>, <b>--unset</b>, or <b>--remove</b> and without specific <I>APPLICATION_ID</I>s, the <b>flatpak mask</b> command will list all currently active masks, indicating whether they are applied system-wide or per-user. This is useful for auditing what applications are being intentionally prevented from updating.


title: HISTORY
content:
The `flatpak-mask` functionality has been a part of the Flatpak project since its relatively early stages, designed to give users and administrators granular control over application lifecycle beyond simple installation and uninstallation. Its inclusion reflects the need for more sophisticated management features in containerized application environments, allowing for version control and selective update policies.


title: PARAMETERS
content:
<b>--user</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the per-user installation.<br><br><b>--system</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the system-wide installation (default).<br><br><b>--installation=<name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a named installation to operate on.<br><br><b>--show-sizes</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the download and installed sizes of components when querying a <B>&lt;REF&gt;</B>.<br><br><b>--no-summary</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the display of the remote's summary information.<br><br><b>--no-fsck</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the file system consistency check of the remote during information retrieval.<br><br><b>--mirror</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows additional mirror-related information if the remote is configured as such.<br><br><b>--bare-ref</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interprets the provided <B>&lt;REF&gt;</B> as a bare Flatpak reference string.<br><br><b>--cached</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses only cached remote information without attempting to download new data from the network.<br><br><b>--columns=FIELD,...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a comma-separated list of fields to output when querying a specific <B>&lt;REF&gt;</B> (e.g., 'name,description,version').<br><br><b>--arch=<arch></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the information to show details for a specific architecture.<br><br><b>--all</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows information for all available architectures (implies <B>--columns</B>).<br><br><b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command usage and available options.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose debugging information during execution.<br><br><b>--ostree-verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints verbose debugging information specifically for OSTree operations.<br><br>


title: DESCRIPTION
content:
The <b>flatpak-remote-info</b> command provides detailed information about a configured Flatpak remote or a specific Flatpak reference (application or runtime) within that remote. It allows users to inspect properties such as the remote's URL, GPG key, collection ID, and whether it's enabled. When a <B>&lt;REF&gt;</B> (like <I>org.kde.Kdenlive</I>) is specified, it retrieves metadata for that particular application or runtime, including its description, version, size, dependencies, and available architectures. This command is crucial for understanding the contents and configuration of Flatpak repositories, aiding in debugging, verifying remote setup, or exploring available software before installation. It can operate on user-specific or system-wide installations, and provides options to filter or format the output.


title: CAVEATS
content:
Using <B>--cached</B> might provide outdated information if the remote has been updated recently and the local cache hasn't been refreshed.<br>Information for a specific <B>&lt;REF&gt;</B> might vary based on the available architectures and branches on the remote.<br>The command requires network access to fetch up-to-date information unless <B>--cached</B> is used.<br>Output formatting can be extensive when querying a <B>&lt;REF&gt;</B> without <B>--columns</B>, making it challenging to parse programmatically.


title: EXAMPLES
content:
<B>To display general information about a remote named "flathub":</B><br><I>flatpak-remote-info flathub</I><br><br><B>To display information about a specific application (GIMP) from "flathub":</B><br><I>flatpak-remote-info flathub org.gimp.GIMP</I><br><br><B>To display only the name, description, and version of an application from "flathub":</B><br><I>flatpak-remote-info --columns=name,description,version flathub org.gimp.GIMP</I><br><br><B>To display information including sizes for an application:</B><br><I>flatpak-remote-info --show-sizes flathub org.gimp.GIMP</I><br><br><B>To query a user-specific remote:</B><br><I>flatpak-remote-info --user my-user-remote</I>


title: HISTORY
content:
The <I>flatpak-remote-info</I> command is an integral part of the Flatpak ecosystem, which originated as <I>xdg-app</I> around 2014-2015 and was officially renamed to Flatpak in 2016. Its functionality has been core since the early days, providing transparency into the contents of Flatpak repositories. As Flatpak evolved, this command gained more options like <B>--show-sizes</B> and <B>--columns</B> to provide more granular control over the displayed information, reflecting the growing complexity and adoption of the Flatpak packaging system. It has consistently served as a vital tool for repository management and application discovery within the Flatpak framework.


title: SEE ALSO
content:
flatpak(1), flatpak-remote-add(1), flatpak-remote-delete(1), flatpak-remote-list(1), flatpak-install(1)


title: SYNOPSIS
content:
<b>flatpak run</b> [<i>OPTIONS...</i>] <i>APPLICATION_ID</i> [<i>ARGUMENTS...</i>]<br><b>flatpak run</b> --command=<i>COMMAND</i> <i>APPLICATION_ID</i> [<i>ARGUMENTS...</i>]


title: PARAMETERS
content:
<b><i>APPLICATION_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique identifier of the Flatpak application to run (e.g., <i>org.mozilla.Firefox</i>). This ID can include optional architecture and branch information (e.g., <i>org.mozilla.Firefox/x86_64/stable</i>).<br><br><b><i>ARGUMENTS...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Any arguments supplied after the <i>APPLICATION_ID</i> are passed directly to the application being launched.<br><br><b>--command=<i>COMMAND</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs a specific <i>COMMAND</i> inside the Flatpak application's sandbox instead of the default executable defined in its metadata. This is useful for running development tools or alternative executables packaged within the Flatpak.<br><br><b>--file-forwarding</b><br>&nbsp;&nbsp;&nbsp;&nbsp;A special mode used primarily by desktop environments or other Flatpak applications to pass file descriptors to the application being launched, enabling seamless file opening or interaction.<br><br><b>--verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, displaying debug information useful for troubleshooting issues with Flatpak or the application's sandbox setup.<br><br><b>--arch=<i>ARCH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the architecture for the application to run, if multiple architectures are available for the same <i>APPLICATION_ID</i> (e.g., <i>x86_64</i>, <i>aarch64</i>).<br><br><b>--branch=<i>BRANCH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the branch of the application to run, if multiple branches (e.g., <i>stable</i>, <i>beta</i>, <i>nightly</i>) are available for the same <i>APPLICATION_ID</i>.<br><br><b>--filesystem=<i>PATH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Grants the application read-only or read/write access to a specific <i>PATH</i> on the host filesystem beyond its default sandbox permissions. This is a common option for granting access to user data directories or specific external drives.<br><br><b>--socket=<i>SOCKET_NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Grants the application access to a specific system socket, such as <i>x11</i>, <i>pulseaudio</i>, or <i>wayland</i>. This is typically managed by the Flatpak manifest, but can be overridden or granted ad-hoc for debugging or specific use cases.<br><br>


title: DESCRIPTION
content:
<i>flatpak-run</i> is a core subcommand of the Flatpak system, designed to execute an installed Flatpak application within its isolated sandbox environment. This process automatically sets up the necessary permissions and resource limitations as defined by the application's manifest, ensuring that the application operates securely without direct access to the host system or other applications. This strong isolation is a cornerstone of Flatpak's security model. When invoked, <i>flatpak-run</i> launches the application's main executable or a specified command within this confined space. It's the primary method for command-line execution of Flatpak applications, providing a controlled and secure execution environment while protecting the integrity of your operating system.


title: CAVEATS
content:
Due to the sandboxing, Flatpak applications launched with <i>flatpak-run</i> have restricted access to the host system. This means they may not be able to access files outside their designated directories, interact with arbitrary system services, or use certain hardware devices unless explicitly granted permission. While this enhances security, it can sometimes lead to unexpected behavior or limitations compared to natively installed applications. Performance overhead is generally minimal but can be noticeable in resource-intensive scenarios.


title: SANDBOX ISOLATION
content:
The primary function of <i>flatpak-run</i> is to enforce strong sandbox isolation. Each application runs in a containerized environment with a predefined set of permissions. This prevents applications from accessing or modifying system resources without explicit consent, significantly enhancing system security and stability by isolating potential vulnerabilities or malicious behavior within the application's own sandbox.


title: APPLICATION ARGUMENTS
content:
It's important to note that any arguments provided after the <i>APPLICATION_ID</i> in the <i>flatpak run</i> command line are passed directly to the application's executable. For example, <code>flatpak run org.kde.krita --debug</code> would launch Krita and pass <code>--debug</code> as an argument to Krita itself, allowing you to control the application's specific behavior.


title: HISTORY
content:
Flatpak, initially known as xdg-app, was conceived by Lennart Poettering in 2015. <i>flatpak-run</i> has been a foundational component since its inception, embodying the core principle of executing applications within a robustly contained environment. Its evolution closely mirrors the development of Flatpak itself, continuously refining its sandboxing capabilities and integration with the broader Linux desktop ecosystem to provide a secure and consistent application distribution model.


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information about the command.<br><br><b><b>--user</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the user-specific Flatpak installation, typically located in <i>~/.local/share/flatpak/</i>.<br><br><b><b>--system</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Operates on the system-wide Flatpak installation, usually in <i>/var/lib/flatpak/</i>. This is the default behavior if neither <b>--user</b> nor <b>--system</b> is specified.<br><br><b><b>--noninteractive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs the update without prompting for user confirmation, useful for scripting or automated environments.<br><br><b><b>--commit=COMMIT</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the specified application or runtime to a particular commit ID instead of the latest available version.<br><br><b><b>--appstream</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Updates the AppStream metadata, which provides rich information about applications like descriptions, screenshots, and categories for software centers.<br><br><b><b>--no-related</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the command from updating related extensions or dependencies that are not explicitly specified.<br><br><b><b>--allow-downgrade</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permits updating to an older version of an application or runtime, which can be useful in specific debugging or compatibility scenarios.<br><br><b><i>APPLICATION/RUNTIME...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optional argument(s) to specify one or more application or runtime IDs to update. If omitted, all installed Flatpaks are updated.<br><br>


title: DESCRIPTION
content:
<i><b>flatpak update</b></i> is a fundamental command within the Flatpak ecosystem, designed to ensure that all installed applications and their underlying runtimes are kept current. When executed, it connects to configured Flatpak remotes (repositories) to check for newer versions of software. If updates are available, it downloads and applies them, replacing older versions while preserving user data and application settings.<br><br>This process is crucial for maintaining system security, as updates often include critical bug fixes and security patches that address vulnerabilities. Beyond security, updating provides access to new features, performance improvements, and compatibility enhancements. The command intelligently handles dependencies, ensuring that runtimes required by applications are also updated to compatible versions.<br><br>Users can choose to update all installed Flatpaks at once or specify particular applications or runtimes for targeted updates. The update mechanism leverages OSTree technology, which allows for efficient, atomic updates, meaning an update either succeeds completely or reverts cleanly, preventing system corruption in case of interruptions. This atomicity ensures system stability and reliability, making <i><b>flatpak update</b></i> a robust tool for software maintenance.


title: CAVEATS
content:
<i><b>Internet Connection:</b> An active internet connection is required to download updates from configured Flatpak remotes.<br><b>Disk Space & Bandwidth:</b> Updates, especially for runtimes, can be substantial in size, requiring significant disk space and bandwidth.<br><b>Application State:</b> While Flatpak updates are atomic, it's generally recommended to close applications being updated before running the command to ensure a smooth transition and avoid potential conflicts.<br><b>Remote/GPG Issues:</b> Outdated remote configurations or GPG key issues can prevent successful updates, requiring manual intervention to resolve.</i>


title: OFFLINE UPDATES
content:
While <i><b>flatpak update</b></i> primarily operates online, Flatpak supports mechanisms for preparing updates offline using commands like <i><b>flatpak pull</b></i> with <i><b>--bare</b></i>, allowing for staged updates in environments with limited or no internet access.


title: SECURITY BEST PRACTICES
content:
Regularly running <i><b>flatpak update</b></i> is a critical security best practice. It ensures that applications and their underlying runtimes receive the latest security patches, mitigating vulnerabilities and protecting the system from potential exploits. Users should integrate this command into their routine system maintenance.


title: HISTORY
content:
<i>Flatpak, initially known as xdg-app, was conceived by Lennart Poettering and first publicly announced in 2015. The <b>flatpak-update</b> command has been a core component of the Flatpak framework from its early development, central to its mission of providing a robust, sandboxed, and self-contained application distribution system for Linux. Its design leverages the OSTree content-addressable filesystem, enabling atomic updates and efficient storage of application and runtime versions. Over time, <b>flatpak-update</b> has evolved alongside the Flatpak project, incorporating improvements in performance, dependency resolution, and user experience, solidifying its role as the primary method for maintaining up-to-date Flatpak installations.</i>


title: SEE ALSO
content:
<b>flatpak(1)</b>, <b>flatpak-install(1)</b>, <b>flatpak-uninstall(1)</b>, <b>flatpak-list(1)</b>, <b>flatpak-remote(1)</b>, <b>ostree(1)</b>


title: PARAMETERS
content:
<b><b>-o</b> <i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output filename for the generated C code, overriding the default <i>lex.yy.c</i>.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Makes the generated scanner case-insensitive, allowing patterns to match regardless of character casing.<br><br><b><b>-P</b> <i>prefix</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the default <i>yy</i> prefix of all scanner functions and variables (e.g., <i>yylex</i>, <i>yytext</i>).<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the generated scanner C code to standard output instead of creating the default <i>lex.yy.c</i> file.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the generation of <i>#line</i> directives in the output file, which can simplify debugging of the generated code itself.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a summary of the generated scanner's statistics, such as table sizes and number of states, to standard error.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Optimizes the generated scanner for speed (Fast Tables) at the cost of potentially larger memory usage for internal tables.<br><br>


title: DESCRIPTION
content:
<b>flex</b> (Fast Lexical Analyzer Generator) is a powerful tool that generates C source code for programs that perform pattern matching on text. It is a free and faster re-implementation of the classic <b>lex</b> utility. Given a specification file (typically with a <i>.l</i> or <i>.lex</i> extension) containing a set of regular expressions and corresponding C code actions, <b>flex</b> generates a C source file (by default <i>lex.yy.c</i>). This output file contains a function, <i>yylex()</i>, which reads input, identifies tokens based on the defined patterns, and executes the associated C actions. Widely used in conjunction with parser generators like <b>bison</b> (or <b>yacc</b>), <b>flex</b> is a fundamental component for building compilers, interpreters, and advanced text processing utilities, efficiently breaking input streams into meaningful sequences of characters known as tokens.


title: CAVEATS
content:
Understanding regular expressions is crucial for effective use. The generated code can be verbose, and debugging complex lexical rules or interactions with parser generators requires careful attention to error handling within actions.


title: INTEGRATION WITH PARSERS
content:
<b>flex</b> scanners are most often used as the frontend for parsers generated by tools like <b>bison</b> or <b>yacc</b>. The <i>yylex()</i> function, generated by <b>flex</b>, reads input and returns integer token codes (and optionally semantic values via <i>yylval</i>) that correspond to the terminal symbols expected by the parser.


title: SPECIFICATION FILE STRUCTURE
content:
A <b>flex</b> specification file is divided into three sections, separated by <i>%%</i>: the definitions section (macros, included C code), the rules section (regular expressions and corresponding C actions), and the user code section (additional C functions or data for the actions).


title: HISTORY
content:
<b>flex</b> is a free software re-implementation of the original <b>lex</b> program. <b>lex</b> was initially developed at Bell Labs in the 1970s. <b>flex</b> was created in 1987 by Vern Paxson under the GNU project to provide a more robust, faster, and freely distributable alternative to <b>lex</b>, while maintaining backward compatibility with existing <b>lex</b> specifications. It has since become the standard lexical analyzer generator in Unix-like environments due to its performance and feature set.


title: SYNOPSIS
content:
<b>flexget</b> [<i>global-options</i>] &lt;<i>command</i>&gt; [<i>command-options</i>] [<i>arguments</i>]<br><br><i>Common usage examples:</i><br><b>flexget</b> <b>execute</b><br><b>flexget</b> <b>--test</b> <b>execute</b> <b>--tasks</b> <i>my_task</i><br><b>flexget</b> <b>--config</b> <i>/path/to/my_config.yml</i> <b>daemon</b> <b>start</b>


title: PARAMETERS
content:
<b><b>-c</b> <i>CONFIG</i>, <b>--config=</b><i>CONFIG</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the configuration file. Defaults to <i>config.yml</i> in the data directory.<br><br><b><b>--logfile=</b><i>LOGFILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Directs logging output to the specified file instead of the default location.<br><br><b><b>--log-level=</b><i>LEVEL</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the minimum logging level. Options include <i>debug</i>, <i>verbose</i>, <i>info</i>, <i>warning</i>, <i>error</i>, <i>critical</i>. Defaults to <i>info</i>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases output verbosity. Use twice (<b>-vv</b>) for debug level output.<br><br><b><b>-q</b>, <b>--quiet</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses most output, showing only critical errors.<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debug level logging and verbose output.<br><br><b><b>--test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the command in 'test mode', preventing any actual changes (e.g., file downloads or database modifications) from occurring. Useful for dry runs.<br><br><b><b>--learn</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Used in conjunction with <b>--test</b> to allow database changes (e.g., marking entries seen) without performing actual downloads. Useful for backfilling history.<br><br><b><b>--profile</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables profiling of FlexGet execution, useful for performance analysis.<br><br><b><b>--no-cache</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables caching for the current run, forcing all sources to be re-fetched.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the FlexGet version and exits.<br><br>


title: DESCRIPTION
content:
FlexGet is a powerful, open-source automation tool designed to manage and download various types of content, such as TV shows, movies, podcasts, and more. It works by monitoring RSS feeds, websites, or other sources, applying user-defined filters, and then instructing external download clients (like BitTorrent clients, Usenet downloaders, or traditional download managers) to fetch the content. Its highly flexible and extensible plugin-based architecture allows users to customize its behavior extensively, from sophisticated content filtering rules to managing downloaded media libraries. FlexGet excels at automating repetitive downloading tasks, ensuring users get the content they want as soon as it becomes available, based on their specific criteria.


title: CAVEATS
content:
FlexGet's power comes with complexity; its configuration file (<i>config.yml</i>) uses YAML and can become intricate for advanced setups, requiring a good understanding of its various plugins and their interactions. It relies heavily on external applications (e.g., BitTorrent clients, Usenet downloaders) for actual content retrieval, which must be separately installed and configured. Misconfigurations can lead to unintended downloads or inefficient operation.


title: CONFIGURATION FILE (<I>CONFIG.YML</I>)
content:
FlexGet's behavior is entirely controlled by its YAML-based configuration file, typically named <i>config.yml</i>. This file defines tasks, inputs (sources), filters, outputs (destinations), plugins to use, and various other settings. Understanding its structure is crucial for effective use of FlexGet.


title: PLUGIN SYSTEM
content:
The core strength of FlexGet lies in its extensive plugin system. Almost every feature, from parsing RSS feeds to interacting with download clients or renaming files, is implemented as a plugin. This modular design allows users to combine functionalities and extend FlexGet's capabilities to suit virtually any content automation scenario.


title: SCHEDULING
content:
For continuous operation, FlexGet can be scheduled to run periodically. This is commonly achieved by using a system scheduler like <b>cron</b> on Linux/macOS, or by running FlexGet in <b>daemon</b> mode (<b>flexget daemon start</b>), which keeps it running in the background and executes tasks based on defined schedules within its own configuration.


title: HISTORY
content:
FlexGet originated from a project called "<i>r-a-d</i>" (RSS Auto Downloader), which focused primarily on automating RSS feed processing. As the project grew in scope and flexibility, supporting more diverse content sources and output destinations, it was rebranded as <i>FlexGet</i>, emphasizing its adaptable, plugin-driven architecture. Since its inception, it has evolved into a robust and widely used open-source tool, continuously updated with new features and plugins by its active community, maintaining its core focus on highly customizable content automation.


title: PARAMETERS
content:
<b><b>--help</b> (<b>-h</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a usage message and exits.<br><br><b><b>--version</b> (<b>-v</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br><b><b>--silent</b> (<b>-s</b>), <b>--quiet</b> (<b>-q</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses warning messages during processing.<br><br><b><b>--force</b> (<b>-f</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>flipdiff</i> to proceed even if warnings are encountered, attempting to generate output despite potential issues.<br><br><b><b>--check</b> (<b>-c</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if the reversed patch contains any reversed chunks, which can indicate issues if the intention was to truly reverse the patch's effect.<br><br><b><b>--no-check</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the check for reversed chunks, even if default behavior would include it.<br><br><b><b>FILE...</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more patch files to process. If no files are specified, <i>flipdiff</i> reads the patch from standard input.<br><br>


title: DESCRIPTION
content:
<i>flipdiff</i> is a utility from the <i>patchutils</i> suite designed to reverse the direction of a patch. When provided with a patch generated by <i>diff -u old new</i>, <i>flipdiff</i> produces a new patch that effectively swaps the 'old' and 'new' file contexts in the diff header, making it suitable for operations expecting <i>diff -u new old</i>. This operation is functionally similar to preparing a patch to be undone using <i>patch -R</i>, as it sets up the diff to indicate the original 'new' file as the 'old' and vice versa. It reads the patch from standard input or specified files and writes the reversed patch to standard output.


title: CAVEATS
content:
While <i>flipdiff</i> reverses the order of files in a diff header (e.g., from 'a/old' to 'b/new' to 'b/new' to 'a/old'), it does not inherently reverse the *effect* of the patch. For example, if a patch adds lines, <i>flipdiff</i> will produce a diff that still shows those lines, but from the perspective of the original 'new' file being the 'old' file. To truly *undo* a patch's changes, the <i>patch -R</i> command is typically used. <i>flipdiff</i> is primarily useful for manipulating the directionality of diffs for comparison or reapplication purposes.


title: <B>EXIT STATUS</B>
content:
<i>flipdiff</i> returns an exit status of <b>0</b> on successful execution. An exit status of <b>1</b> indicates minor problems, such as warnings that occurred during processing (unless suppressed by <b>--silent</b> or <b>--force</b>). A status of <b>2</b> signifies serious errors that prevented the command from processing the patch.


title: <B>USAGE</B>
content:
The command typically takes a patch as input via standard input (e.g., `cat patchfile | flipdiff`) or directly from one or more specified files (e.g., `flipdiff patchfile.diff`). The resulting reversed patch is then printed to standard output, which can be redirected to a new file or piped to another command.


title: HISTORY
content:
<i>flipdiff</i> is part of the <i>patchutils</i> package, a suite of small, specialized utilities for manipulating and analyzing diff files. This collection was developed by Simon Michael to address common needs in patch management workflows that were not covered by standard tools like <i>diff</i> and <i>patch</i> alone. Its development, like the rest of <i>patchutils</i>, has been community-driven within the open-source ecosystem, aiming to provide robust and flexible tools for developers working with patches.


title: SEE ALSO
content:
<i>patch(1)</i>, <i>diff(1)</i>, <i>interdiff(1)</i>, <i>lsdiff(1)</i>, <i>combinediff(1)</i>, <i>splitdiff(1)</i>, <i>recountdiff(1)</i>


title: SYNOPSIS
content:
<b>flips</b> <i>--apply</i> [<i>--bps</i> | <i>--ips</i> | <i>--ups</i>] <i>&lt;patch_file&gt; &lt;input_file&gt; &lt;output_file&gt;</i><br><b>flips</b> <i>--create</i> [<i>--bps</i> | <i>--ips</i> | <i>--ups</i>] <i>&lt;original_file&gt; &lt;modified_file&gt; &lt;output_patch&gt;</i><br><b>flips</b> <i>--verify</i> <i>&lt;patch_file&gt; &lt;input_file&gt;</i><br><b>flips</b> <i>--version</i> | <i>--help</i>


title: PARAMETERS
content:
<b><i>--apply</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies the specified patch file to an `<i>input_file</i>`, generating a new `<i>output_file</i>`.<br><br><b><i>--create</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a patch file (`<i>output_patch</i>`) by comparing an `<i>original_file</i>` with a `<i>modified_file</i>`.<br><br><b><i>--verify</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks if a given `<i>patch_file</i>` can be correctly applied to an `<i>input_file</i>` without errors, often including checksum validation.<br><br><b><i>--bps</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies or forces the patch format to be BPS (Binary Patching System). This is the default for creation.<br><br><b><i>--ips</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies or forces the patch format to be IPS (International Patching System).<br><br><b><i>--ups</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Explicitly specifies or forces the patch format to be UPS (Universal Patching System).<br><br><b><i>--json</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs results, such as verification outcomes or errors, in JSON format for programmatic parsing.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays comprehensive help information about the command's usage and options.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the current version of the `flips` utility.<br><br><b><i>&lt;patch_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the binary patch file to be applied or verified.<br><br><b><i>&lt;input_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the original file that will be patched or against which a patch will be verified.<br><br><b><i>&lt;output_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the newly generated, patched file will be saved.<br><br><b><i>&lt;original_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the unmodified base file used when creating a patch.<br><br><b><i>&lt;modified_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the altered version of the file, used in conjunction with the original file to create a patch.<br><br><b><i>&lt;output_patch&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path where the newly created patch file will be saved.<br><br>


title: DESCRIPTION
content:
The `flips` command (Free Lossless Image Patcher System) is a cross-platform command-line utility designed for applying and creating lossless binary patches. It is commonly used in the context of video game ROM hacking and preservation, but can be utilized for patching any arbitrary file. `flips` supports various patch formats, including its robust native BPS (Binary Patching System) format, as well as the older IPS (International Patching System) and UPS (Universal Patching System) formats.<br><br>The utility emphasizes data integrity and efficiency. When applying patches, `flips` ensures that the process is robust, minimizing the risk of data corruption. For creating patches, it uses delta-encoding to generate compact patch files. Its features make it a reliable choice for situations where precise, error-free file modification is critical, particularly for large binary files.


title: CAVEATS
content:
`flips` is not a standard utility bundled with most mainstream Linux distributions. It typically needs to be downloaded, compiled, or installed separately. Its primary application lies in binary patching, particularly for ROM files, as opposed to general-purpose text file differencing (like `patch(1)`). Users must ensure the correct patch format (`BPS`, `IPS`, `UPS`) is either explicitly specified or correctly inferable by `flips` to avoid errors. While robust, improper usage (e.g., applying a patch to the wrong base file) can still lead to corrupt output, though `flips` often includes integrity checks to mitigate this.


title: <B>PATCH FORMATS EXPLAINED</B>
content:
`flips` provides support for several binary patch formats. The <b>BPS</b> (Binary Patching System) format is `flips`'s native and most advanced format, offering robust features like checksums for both original and patched files, support for file sizes beyond 4GB, and atomic patching (all-or-nothing application). <b>IPS</b> (International Patching System) is an older, simpler format widely used, but limited to patching files up to 16MB and lacking integrity checks. <b>UPS</b> (Universal Patching System) is another older format that removed the 16MB size limit of IPS but still lacks built-in checksums for robust integrity verification.


title: <B>INTEGRITY AND VERIFICATION</B>
content:
A core strength of `flips`, particularly when utilizing BPS patches, is its strong emphasis on data integrity. BPS patches embed CRC32 checksums of both the expected original file and the intended patched file. This allows `flips` to perform critical pre-application checks, ensuring the patch is being applied to the correct original file, and post-application verification, confirming that the resulting patched file is free from corruption. This level of verification significantly enhances reliability and reduces the risk of distributing or applying faulty modifications.


title: HISTORY
content:
The `flips` utility was developed by <i>Alcaro</i> as a modern binary patching solution, addressing limitations present in older formats and tools. It emerged from the need for more robust, efficient, and reliable patching, particularly within the ROM hacking and fan translation communities. Its native BPS format was designed to overcome issues such as the 16MB file size limit of IPS patches and the lack of integral checksums in UPS patches, which could lead to undetected data corruption. Since its inception, `flips` has gained significant traction for its reliability and advanced features, becoming a preferred tool for distributing modifications to large binary files like video game ROMs.


title: SYNOPSIS
content:
<b>flite</b> [<i>options</i>] [<b>-t</b> <<i>text</i>> | <b>-f</b> <<i>file</i>>] [<b>-o</b> <<i>output_file.wav</i>>]<br><b>flite</b> <b>-l</b><br><b>flite</b> <b>-i</b>


title: PARAMETERS
content:
<b><b>-t</b> <<i>text</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synthesizes speech from the provided text string.<br><br><b><b>-f</b> <<i>file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synthesizes speech from text read from the specified input file.<br><br><b><b>-o</b> <<i>output_file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs the synthesized speech to the specified WAV audio file. If omitted, audio may be played directly or raw samples output to stdout.<br><br><b><b>-v</b> <<i>voice</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the voice to be used for synthesis. Use <b>-l</b> to list available voices.<br><br><b><b>-s</b> <<i>float</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the speech rate. A value of 1.0 is normal, higher values increase speed, lower values decrease speed.<br><br><b><b>-p</b> <<i>float</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the speech pitch. A value of 1.0 is normal, higher values increase pitch, lower values decrease pitch.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all available voices installed with <b>flite</b>.<br><br><b><b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enters interactive mode, reading text from standard input until EOF.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information and exits.<br><br>


title: DESCRIPTION
content:
<b>flite</b> (Festival-Lite) is a small, fast, run-time text-to-speech (TTS) synthesis engine. Developed at Carnegie Mellon University (CMU), it's designed specifically for embedded systems and applications where a full-featured TTS system like Festival would be too resource-intensive or slow. It converts text input, either from the command line or a file, into spoken audio. <b>flite</b> prioritizes efficiency and a compact footprint, making it ideal for devices with limited memory and processing power. While its voice quality might not always match larger, more complex synthesizers, it provides a highly functional and remarkably fast solution for generating speech programmatically.


title: CAVEATS
content:
<b>flite</b> is designed for speed and a small footprint, which can sometimes come at the cost of the most natural-sounding voice quality compared to larger, more complex TTS systems. It primarily supports English voices, and its prosodic control is more limited than research-grade synthesizers. Performance can vary depending on the specific voice chosen and the underlying system's audio configuration.


title: TYPICAL USAGE SCENARIOS
content:
Due to its small size and efficiency, <b>flite</b> is commonly used in embedded Linux devices, mobile applications (though less common now with cloud TTS), interactive voice response (IVR) systems, and lightweight command-line utilities requiring quick speech output. It's often bundled with minimalist Linux distributions or custom device firmwares.


title: HISTORY
content:
<b>flite</b> (Festival-Lite) was developed by Alan W. Black and others at Carnegie Mellon University (CMU) as a lightweight, faster version of the Festival Speech Synthesis System. The project aimed to create a robust and efficient text-to-speech engine suitable for embedded systems and applications where resource constraints or real-time performance were critical. Its development focused on optimizing the synthesis process to minimize memory usage and CPU cycles, making it a prominent choice for integrating speech capabilities into small devices and applications.


title: SYNOPSIS
content:
<I>flock</I> [<I>options</I>] <I>file</I>|<I>directory</I> <I>command</I> [<I>arguments</I>...]<br><I>flock</I> [<I>options</I>] <I>file</I>|<I>directory</I>


title: PARAMETERS
content:
<b><B>-s</B>, <B>--shared</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acquire a shared lock. Multiple processes can hold shared locks on the same file simultaneously.<br><br><b><B>-x</B>, <B>--exclusive</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Acquire an exclusive lock (default behavior). Only one process can hold an exclusive lock at a time.<br><br><b><B>-u</B>, <B>--unlock</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Remove an existing lock. This is typically used for explicit unlocking or clean-up.<br><br><b><B>-n</B>, <B>--nb</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Non-blocking mode. Fail immediately with a non-zero exit status if the lock cannot be obtained.<br><br><b><B>-w</B> <I>seconds</I>, <B>--wait</B> <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wait for a specified number of seconds to acquire the lock. Returns failure if the timeout is reached.<br><br><b><B>-E</B> <I>seconds</I>, <B>--timeout</B> <I>seconds</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alias for <B>--wait</B>.<br><br><b><B>-o</B>, <B>--close</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Close the file descriptor of the locked file after acquiring the lock and before executing the command. The lock remains active.<br><br><b><B>-c</B> <I>command</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Command to execute while holding the lock. This is the default behavior if a command follows the file argument.<br><br><b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b><B>-V</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <I>flock</I> command provides a mechanism for managing advisory locks on files or directories. It is an indispensable tool in shell scripting for ensuring inter-process synchronization and preventing race conditions. By applying a lock, <I>flock</I> helps guarantee that only one process (or multiple processes with shared locks) can access a critical section or shared resource at a time, thus maintaining data integrity. <I>flock</I> supports two types of locks: <B>shared</B> (allowing multiple readers) and <B>exclusive</B> (allowing only one writer). When <I>flock</I> is used to execute a command, the lock is held for the duration of that command's execution and is automatically released upon its completion. It also offers options for non-blocking lock attempts and setting timeouts for lock acquisition, making it flexible for various scripting needs.


title: CAVEATS
content:
<ul><li><I>Advisory Locks</I>: <B>flock</B> implements advisory locks, meaning processes must explicitly cooperate by also using <B>flock</B> to respect the lock. Non-cooperating processes can still access the file.</li><li><I>Deadlocks</I>: Improper use can lead to deadlocks if multiple processes attempt to acquire locks in a circular fashion.</li><li><I>File Descriptors</I>: Locks are associated with open file descriptors. If the file descriptor is closed (e.g., when the command exits), the lock is automatically released. Be mindful of how <B>-o</B> works.</li><li><I>Filesystem Support</I>: Locks may not work reliably or as expected on all network filesystems (e.g., NFS), as they might not fully support <I>flock</I>(2) semantics.</li></ul>


title: <B>LOCKING MECHANISM</B>
content:
<I>flock</I> operates by associating a lock with a specific open file descriptor for a given file or directory. The actual file content is not modified by the lock itself; instead, the kernel tracks the lock status. The lock is automatically released when the file descriptor is closed (e.g., when the process holding the lock terminates or explicitly closes the file) or when another lock is applied to the same file descriptor.


title: <B>EXIT STATUS</B>
content:
If <I>flock</I> successfully acquires the lock and executes a command, its exit status will be that of the <I>command</I> it executed. If <I>flock</I> itself fails to acquire the lock (e.g., due to <B>-n</B> or <B>-w</B> timeout) or encounters an error, it will return a non-zero exit status.


title: HISTORY
content:
The <I>flock</I> utility is a standard component of Unix-like operating systems, derived from the <I>flock</I>(2) system call first introduced in 4.2BSD. Its primary purpose is to provide a simple, portable, and widely adopted method for inter-process synchronization using file-based advisory locks. It gained significant usage in shell scripting for managing access to shared resources and preventing concurrent execution of critical tasks.


title: PARAMETERS
content:
<b>-f <format_file></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a custom output format file for flow records.<br><br><b>-F <format_tag></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a predefined output format tag (e.g., 'compact', 'long').<br><br><b>-m</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Includes milliseconds in timestamps for more precise timing.<br><br><b>-o <output_filename></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Writes the decoded flow output to the specified file instead of standard output.<br><br><b>-s <sort_fields></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sorts output by comma-separated fields, e.g., 'srcip,dstip'.<br><br><b>-t <time_format></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the timestamp output format (e.g., 'iso', 'unix').<br><br><b>-x</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints extended or verbose output for each flow record.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases verbosity level, showing more operational details.<br><br><b><FILES...></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input flow files to process. If omitted, reads from standard input.<br><br>


title: DESCRIPTION
content:
<i>The command "flow" is not a standard, standalone Linux command.</i><br><br>However, "flow" is widely used to refer to network flow data, such as NetFlow, IPFIX, and sFlow, which are protocols used for collecting IP traffic information. In the Linux ecosystem, handling this data typically involves specialized tool suites like <b>flow-tools</b> or <b>nfdump</b>.<br><br>This analysis describes <b>flow-print</b>, a prominent utility from the <b>flow-tools</b> suite, which is commonly used to decode and display captured network flow records. It serves as a representative example of how "flow" data is processed and presented on Linux systems.


title: CAVEATS
content:
<i>The command "flow" itself is not a standalone executable in most standard Linux distributions.</i> The information provided here describes <b>flow-print</b>, a specific command from the <b>flow-tools</b> suite, which is a common set of utilities for handling network flow data. Users should install the <b>flow-tools</b> package to use <b>flow-print</b>.


title: UNDERSTANDING NETWORK FLOW DATA
content:
Network flow data represents aggregated records of network communication, rather than raw packet data. Each record typically includes source/destination IP addresses, ports, protocol, timestamps, and byte/packet counts for a specific flow. This high-level summary is invaluable for network monitoring, security analysis (e.g., detecting anomalies or DDoS attacks), billing, and capacity planning, as it provides insights into "who communicated with whom, when, and how much data was exchanged."


title: HISTORY
content:
The <b>flow-tools</b> suite, from which <b>flow-print</b> originates, was developed to collect, process, and analyze NetFlow data. NetFlow, originally a Cisco-specific protocol, became a de facto standard for network traffic monitoring. The <b>flow-tools</b> project provided essential open-source utilities for working with these flow records outside of proprietary solutions, evolving with various NetFlow versions and later IPFIX (IP Flow Information Export). Its development peaked in the early 2000s, offering robust command-line tools for network administrators and security analysts to gain insights into network traffic patterns.


title: SYNOPSIS
content:
<b>fls</b> [<i>options</i>] <i>image</i> [<i>image_offset</i>]<br><br><i>image</i>: Path to the disk image file.<br><i>image_offset</i>: Optional byte offset from the start of the image to the beginning of the file system to analyze.


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display '.' and '..' directory entries.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display directory entries for deleted files.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display directory entries for <i>only</i> deleted files.<br><br><b><b>-f</b> <i>fstype</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the file system type (e.g., ext3, ntfs, fat). Auto-detection is usually sufficient.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display file entries for only directories.<br><br><b><b>-i</b> <i>imgtype</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the disk image type (e.g., raw, ewf, aff). Auto-detection is usually sufficient.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the long version of the directory entries, including inode and size (similar to <i>ls -l</i>).<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the contents of deleted directories (FAT and NTFS only).<br><br><b><b>-o</b> <i>offset</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the sector offset from the start of the image to the beginning of the file system.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the full path for the directory entries.<br><br><b><b>-P</b> <i>pragma</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a pragma for printing deleted entries (e.g., 'all', 'alloc', 'unalloc').<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively list all directory entries.<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Recursively list all directory entries, including unallocated ones, showing full paths.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display directory entries for only special files (e.g., '.' and '..').<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display only unallocated (orphaned) files and directories.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output to stderr.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display tool version information.<br><br><b><b>-z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display time in the local timezone.<br><br>


title: DESCRIPTION
content:
<i>fls</i> is a command-line utility from <i>The Sleuth Kit (TSK)</i>, a comprehensive collection of open-source digital forensics tools. Its primary function is to list directory entries from a given disk image or a specific file system within that image. Unlike standard <i>ls</i>, <i>fls</i> operates directly on forensic images and can recover information about deleted files and directories if their metadata (directory entries) still exists on the file system.<br><br>It supports various file systems including FAT, NTFS, HFS+, Ext2/3/4, and UFS. Forensic analysts use <i>fls</i> to gain insight into the file system structure, identify active and deleted files, and investigate file activity without mounting the image, thereby preserving its integrity. It's a crucial step in understanding the layout of a compromised or evidence disk before deeper analysis.


title: CAVEATS
content:
<i>fls</i> operates on disk images, not live file systems. It requires the installation of <i>The Sleuth Kit</i>. While it can list deleted entries, the actual content of deleted files may not be recoverable if overwritten. Understanding its output often requires knowledge of file system structures and forensic analysis principles. Performance can vary significantly with image size and file system complexity.


title: OUTPUT INTERPRETATION
content:
The default output of <i>fls</i> provides inode numbers, allocation status (allocated/deleted), and file names. The <b>-l</b> option provides a more detailed <i>ls -l</i>-like output including permissions, owner/group, size, and modification times. The <b>-d</b> and <b>-D</b> options are crucial for identifying deleted files and their associated directory entries.


title: FORENSIC WORKFLOW INTEGRATION
content:
<i>fls</i> is commonly used early in a forensic investigation to survey the contents of a disk image. It helps identify files of interest, reconstruct directory structures, and locate evidence of data deletion or tampering, often preceding deeper analysis with tools like <i>icat</i> (to recover file content) or <i>blkls</i> (to list blocks).


title: HISTORY
content:
<i>fls</i> is an integral part of <i>The Sleuth Kit (TSK)</i>, an open-source collection of command-line tools for digital forensics. TSK was originally developed by <i>Brian Carrier</i> as an enhancement to <i>The Coroner's Toolkit (TCT)</i> in the early 2000s. <i>fls</i> specifically provides a non-invasive way to examine file system contents, including deleted data, which is fundamental for forensic investigations. Its continuous development reflects the evolving needs of digital evidence analysis, maintaining compatibility with new file system types and improving performance and feature sets.


title: PARAMETERS
content:
<b><b>-a</b>, <b>--audio-driver=<driver></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the audio output driver (e.g., alsa, pulseaudio, jack, portaudio, oss).<br><br><b><b>-m</b>, <b>--midi-driver=<driver></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the MIDI input driver (e.g., alsa_seq, portmidi, jack).<br><br><b><b>-s</b>, <b>--server</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i>fluidsynth</i> in server mode, without an interactive shell.<br><br><b><b>-i</b>, <b>--no-shell</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the interactive shell from starting when <i>fluidsynth</i> runs.<br><br><b><b>-o</b>, <b>--option=<name>=<value></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific configuration option, such as <i>audio.alsa.period-size=64</i>.<br><br><b><b>-c</b>, <b>--conf=<filename></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loads configuration settings from the specified file.<br><br><b><b>-F</b>, <b>--fifo=<filename></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses a named pipe for receiving MIDI events, allowing external programs to send MIDI data.<br><br><b><b>-g</b>, <b>--gain=<value></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the global gain (0.0 to 10.0) of the audio output.<br><br><b><b>-R</b>, <b>--reverb=<type></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the reverb effect type for the output audio.<br><br><b><b>-C</b>, <b>--chorus=<type></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the chorus effect type for the output audio.<br><br><b><b>-z</b>, <b>--channels=<num></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of audio output channels.<br><br><b><b>-r</b>, <b>--samplerate=<rate></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the audio sample rate for processing.<br><br><b><b>-D</b>, <b>--dump</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps information about loaded SoundFonts and then exits.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
<i>fluidsynth</i> is a real-time software synthesizer that can play MIDI data using SoundFont 2 (SF2) files. It acts as a powerful and flexible sound engine, capable of generating high-quality audio from MIDI input. It's often used as a standalone application, an embedded library, or a sound server for other programs.<br><br>Key features include support for various audio drivers (such as ALSA, PulseAudio, JACK, and PortAudio) and MIDI input methods (like ALSA, PortMidi, and JACK). This makes it highly versatile and adaptable to different Linux audio setups. Users can load multiple SoundFonts simultaneously, apply effects like reverb and chorus, and configure various mixing and routing options.<br><br><i>fluidsynth</i> is widely appreciated in the Linux audio community for its low latency capabilities, making it suitable for live performance and interactive music applications. It empowers users to bring MIDI compositions to life with a wide array of instrument sounds provided by SoundFont files.


title: CAVEATS
content:
<b>Resource Usage</b>: <i>fluidsynth</i> can be CPU and RAM intensive, especially when using large SoundFonts or enabling multiple effects (reverb, chorus). Performance can vary significantly depending on the system hardware and the complexity of the MIDI input.<br><br><b>Latency</b>: While designed for low-latency operation, the actual latency depends heavily on the selected audio driver, its buffer settings, and overall system load. Optimizing these settings is crucial for live performance.<br><br><b>SoundFont Quality</b>: The output sound quality is directly dependent on the quality of the SoundFont 2 (SF2) files used. Low-quality or poorly sampled SoundFonts will result in poor audio output, regardless of <i>fluidsynth</i>'s capabilities.


title: MIDI INPUT AND CONNECTIONS
content:
<i>fluidsynth</i> doesn't automatically detect MIDI input devices. You typically need to connect a MIDI source (e.g., a MIDI keyboard, another software application, or a MIDI file player) to <i>fluidsynth</i>'s MIDI input port. On Linux, this is often done using ALSA's <b>aconnect</b> utility (e.g., <b>aconnect 20:0 128:0</b> to connect a MIDI keyboard to <i>fluidsynth</i>'s default ALSA port). If using JACK, connections can be made via `qjackctl` or `jack_connect`.


title: SOUNDFONT FILES
content:
SoundFont 2 (SF2) files are crucial for <i>fluidsynth</i> as they contain the actual instrument samples and synthesis parameters. These files usually have a <i>.sf2</i> extension. You can specify one or more SoundFont files on the command line when starting <i>fluidsynth</i>. Many free and commercial SoundFonts are available online, offering a vast library of sounds from realistic instruments to synthetic textures.


title: INTERACTIVE SHELL
content:
When run without the <b>--no-shell</b> or <b>--server</b> options, <i>fluidsynth</i> starts an interactive shell, allowing users to control parameters, load/unload SoundFonts, play notes, and manage effects in real-time. This provides a powerful environment for experimentation and live performance without restarting the application.


title: HISTORY
content:
<i>fluidsynth</i> was originally developed by Peter Hanappe and first released in 2000. Its primary goal was to create an open-source, high-quality SoundFont 2 compliant software synthesizer. It quickly became a cornerstone of the Linux audio ecosystem due to its robust performance, low latency, and ability to use freely available SoundFont files to produce a wide range of instrument sounds. Over the years, it has evolved with contributions from a dedicated community, adding support for various audio and MIDI drivers, improving efficiency, and expanding its feature set, solidifying its role as a versatile and essential tool for musicians and developers on Linux.


title: SYNOPSIS
content:
<b>flutter</b> <i>[global-options]</i> <b>&lt;command&gt;</b> <i>[arguments]</i><br><i>Common commands:</i><br>&nbsp;&nbsp;<b>flutter create</b> <i>&lt;project_name&gt;</i><br>&nbsp;&nbsp;<b>flutter run</b> <i>[options]</i><br>&nbsp;&nbsp;<b>flutter build</b> <i>&lt;apk|ios|web|windows|macos|linux&gt;</i> <i>[options]</i><br>&nbsp;&nbsp;<b>flutter test</b> <i>[options]</i><br>&nbsp;&nbsp;<b>flutter doctor</b> <i>[options]</i><br>&nbsp;&nbsp;<b>flutter upgrade</b> <i>[options]</i>


title: PARAMETERS
content:
<b>create <project_name></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new Flutter project in the specified directory. Includes project structure, basic code, and necessary configuration files.<br><br><b>run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs your Flutter application on a connected device (simulator, emulator, physical device) or in a web browser/desktop window. Supports hot reload for rapid development.<br><br><b>build <target></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Builds a production-ready artifact for the specified target platform (e.g., APK for Android, IPA for iOS, JavaScript for web, executable for desktop).<br><br><b>test</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs the tests defined in your Flutter project. Supports unit, widget, and integration tests.<br><br><b>doctor</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks your development environment and displays a report of the status of your Flutter installation and any missing dependencies (SDKs, tools, IDEs).<br><br><b>clean</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes the 'build' directory and other generated files from your Flutter project. Useful for resolving build issues or reducing project size.<br><br><b>upgrade</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Upgrades your Flutter SDK to the latest available version. Also updates Dart SDK and installed packages.<br><br><b>pub</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Dart package dependencies for your Flutter project. Common uses include `pub get` to download dependencies and `pub upgrade` to update them.<br><br><b>install</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a Flutter application on a connected device without running it immediately. Useful for quick deployment of debug builds.<br><br><b>analyze</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Analyzes the Dart code in your project for potential issues, errors, warnings, and style violations.<br><br><b>config</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures Flutter settings such as device selection, analytics reporting, and enable/disable desktop development.<br><br><b>devices</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all connected physical devices and running emulators/simulators available for running Flutter applications.<br><br><b>emulators</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Manages Android emulators. Used to list, create, and launch Android Virtual Devices (AVDs).<br><br><b>format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Formats Dart code according to Flutter's style guide.<br><br>


title: DESCRIPTION
content:
<i>The <b>flutter</b> command is the primary command-line interface (CLI) tool for interacting with the Flutter SDK. Flutter is an open-source UI software development kit created by Google for building beautiful, natively compiled applications for mobile (Android, iOS), web, and desktop (Windows, macOS, Linux) from a single codebase. The command provides a comprehensive set of functionalities for managing the entire application development lifecycle. This includes creating new projects, running applications on various devices (simulators, emulators, physical devices, web browsers, desktop environments), building production-ready packages, testing code, analyzing project health, and upgrading the SDK itself.<br><br>The <b>flutter</b> CLI simplifies complex tasks such as dependency management (via Dart's pub package manager), debugging, and deployment. Its core philosophy revolves around rapid development with features like stateful hot reload, which allows developers to see changes instantly without losing application state. It acts as the gateway to the Flutter ecosystem, enabling developers to leverage Dart language features and a rich set of pre-built widgets to create highly performant and visually appealing user interfaces across multiple platforms.</i>


title: CAVEATS
content:
<i>The <b>flutter</b> command relies heavily on a properly configured development environment. Key caveats include:<br><ul><li><b>SDK Dependencies:</b> Requires the Flutter SDK to be installed and its path added to the system's PATH variable.</li><li><b>Platform-Specific SDKs:</b> For mobile development, it necessitates the installation of Android SDK (Android Studio) and Xcode (for iOS on macOS). These platform SDKs provide the necessary compilers, emulators, and tools.</li><li><b>IDE/Editor Integration:</b> While CLI-driven, optimal development often requires integration with an IDE like VS Code or Android Studio, which provide Flutter plugins for advanced features (debugging, hot reload shortcuts).</li><li><b>Dart Language:</b> Flutter applications are written in Dart, so familiarity with Dart syntax and concepts is crucial.</li><li><b>Resource Intensive:</b> Building and running Flutter applications, especially emulators, can be resource-intensive, requiring sufficient RAM and CPU.</li><li><b>Network Access:</b> `flutter pub get` and `flutter upgrade` require internet access to download packages and SDK updates.</li></ul></i>


title: GLOBAL OPTIONS
content:
<i>The <b>flutter</b> command supports a few global options that apply to any subcommand:<ul><li><b>--version:</b> Shows the Flutter SDK version.</li><li><b>--verbose:</b> Shows additional diagnostic output.</li><li><b>--color:</b> Use terminal colors (auto-detected by default).</li><li><b>--no-color:</b> Do not use terminal colors.</li><li><b>--device-id &lt;id&gt;:</b> Specifies the ID of the device to target when running or building applications.</li></ul></i>


title: ENVIRONMENT VARIABLES
content:
<i>The <b>flutter</b> command respects several environment variables for configuration:<ul><li><b>FLUTTER_ROOT:</b> Specifies the path to the Flutter SDK installation. Typically set automatically during setup.</li><li><b>PUB_CACHE:</b> Specifies the directory where Dart packages are cached.</li><li><b>FLUTTER_CHANNEL:</b> Defines the update channel for the Flutter SDK (e.g., 'stable', 'beta', 'dev'). This affects which version `flutter upgrade` fetches.</li></ul></i>


title: HOT RELOAD VS. HOT RESTART
content:
<i>Two fundamental features for rapid development:<ul><li><b>Hot Reload:</b> Injects updated source code files into the running Dart Virtual Machine (VM). Most changes, including UI and logic, can be applied instantly without losing application state.</li><li><b>Hot Restart:</b> Flushes all application state and rebuilds the widget tree from scratch. This is necessary for changes to `main()` or stateful objects not tracked by hot reload. Both are typically invoked via `flutter run` or IDE shortcuts.</i>


title: HISTORY
content:
<i>Flutter was initially released by Google in May 2017 (alpha release). Its development began as "Sky" in 2015. The first stable release, Flutter 1.0, was announced in December 2018 at the Flutter Live event, focusing primarily on mobile development for Android and iOS. A key development was the introduction of "hot reload," allowing developers to inject code changes into a running app without losing its state, significantly speeding up development cycles. <br><br>Subsequent versions expanded Flutter's capabilities to new platforms. Flutter 1.9 introduced web support (beta), and Flutter 2.0, released in March 2021, brought stable web support and broadened desktop application development to stable releases for Windows, macOS, and Linux. This multi-platform capability from a single codebase has been a significant driver of its adoption, making the <b>flutter</b> command an indispensable tool for cross-platform developers.</i>


title: PARAMETERS
content:
<b>--offline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <I>pub</I> to resolve dependencies using only the packages already in the local cache, without attempting to connect to the network. This is useful for working without an internet connection or ensuring reproducibility.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Simulates the command's execution without making any actual changes to files or the system. This option is useful for previewing the effects of operations like adding, removing, or upgrading dependencies before committing them.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, displaying more detailed information about the command's execution process. This can be highly helpful for debugging issues or understanding complex operations.<br><br><b>--help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the <b><I>flutter pub</I></b> command or for a specific subcommand if provided (e.g., <b><I>flutter pub get --help</I></b>). It shows available options and usage examples.<br><br>


title: DESCRIPTION
content:
The <b><I>flutter pub</I></b> command is an essential tool for managing dependencies and executing various tasks related to packages within a Flutter project. It acts as a wrapper around the <I>Dart Pub</I> package manager, integrating its powerful functionality directly into the Flutter workflow.<br><br>While <b><I>flutter pub</I></b> itself does not have many direct options, its power comes from its extensive set of subcommands, each designed for specific tasks such as fetching, updating, or publishing packages, running executables, managing global packages, and more. Users typically invoke <b><I>flutter pub</I></b> followed by a subcommand and its specific options.


title: CAVEATS
content:
The core functionality of <b><I>flutter pub</I></b> is exposed through its subcommands, and most options are specific to these subcommands rather than to the main <b><I>flutter pub</I></b> command itself.<br><br>For most operations, ensure you are in the root directory of your Flutter project (where the <I>pubspec.yaml</I> file is located), as commands operate on the project's defined dependencies.


title: KEY SUBCOMMANDS
content:
While the 'parameters' section outlines common options, the primary utility of <b><I>flutter pub</I></b> stems from its versatile subcommands:<br><b><I>get</I></b>: Downloads all dependencies listed in the <I>pubspec.yaml</I> file.<br><b><I>upgrade</I></b>: Updates all dependencies in the <I>pubspec.yaml</I> to their latest compatible versions.<br><b><I>add</I></b>: Adds a new dependency to your <I>pubspec.yaml</I> and automatically runs <b><I>pub get</I></b>.<br><b><I>remove</I></b>: Removes an existing dependency from your <I>pubspec.yaml</I> and automatically runs <b><I>pub get</I></b>.<br><b><I>publish</I></b>: Publishes the current package to the <I>pub.dev</I> package repository, making it available to others.<br><b><I>run</I></b>: Executes a script or program defined in a package listed in your <I>pubspec.yaml</I>.<br><b><I>global</I></b>: Manages globally activated Dart packages, allowing their executables to be run from any directory.<br><b><I>outdated</I></b>: Lists dependencies that have newer versions available than currently used.<br><b><I>deps</I></b>: Prints a detailed dependency graph of your project, showing all transitive dependencies.


title: PUBSPEC.YAML FILE
content:
The <I>pubspec.yaml</I> file is central to <b><I>flutter pub</I></b>'s operation. It defines a Flutter project's metadata, its declared dependencies (including regular and dev dependencies), asset specifications, and other project-specific configurations. All <b><I>flutter pub</I></b> commands read from and/or modify this file to manage the project's external package requirements effectively.


title: HISTORY
content:
The <I>pub</I> package manager has been a foundational component of the Dart ecosystem since its inception, facilitating robust dependency management for all Dart projects. As Flutter emerged as a prominent UI toolkit built on Dart, the <I>pub</I> command was seamlessly integrated into the Flutter SDK as <b><I>flutter pub</I></b>. This integration ensures that Flutter developers have a consistent and powerful tool for managing their project's external libraries and packages, leveraging the vast ecosystem of the Dart package repository (pub.dev).


title: SYNOPSIS
content:
`fluxctl` is structured with subcommands, where each subcommand has its own set of options and arguments. The general syntax is:<br><b>`fluxctl [global-options] <command> [command-options] [arguments...]`</b><br><br>Common subcommands include:<br>- `fluxctl <b>sync</b>`: Forces a sync of the cluster with Git.<br>- `fluxctl <b>release</b>`: Deploys a new image version to a workload.<br>- `fluxctl <b>automate</b>`: Configures image automation for a workload.<br>- `fluxctl <b>deautomate</b>`: Disables image automation for a workload.<br>- `fluxctl <b>suspend</b>`: Suspends reconciliation or image automation for a workload.<br>- `fluxctl <b>resume</b>`: Resumes reconciliation or image automation for a workload.<br>- `fluxctl <b>identity</b>`: Shows the public key for Git deployment.<br>- `fluxctl <b>logs</b>`: Shows logs from the Flux daemon.<br>- `fluxctl <b>version</b>`: Displays the client and server versions.<br>- `fluxctl <b>help</b>`: Shows help for a command.


title: PARAMETERS
content:
<b>--kubeconfig path</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global)</i> Path to the kubeconfig file to use for Kubernetes API communication.<br><br><b>--context name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global)</i> The name of the kubeconfig context to use.<br><br><b>--namespace name</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global)</i> The Kubernetes namespace where Flux is running, typically 'flux-system' or 'default'.<br><br><b>--url URL</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global)</i> URL of the Flux daemon to connect to (e.g., http://localhost:3030). Usually derived from kubeconfig.<br><br><b>--k8s-fwd-ns namespace</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Global)</i> Use Kubernetes port-forwarding to connect to the daemon in the specified namespace.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Common for subcommands)</i> Show what would happen without making actual changes.<br><br><b>--output format</b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Common for subcommands)</i> Output format (e.g., 'json', 'yaml', 'table').<br><br><b>(Subcommand-specific options)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Each subcommand (e.g., `release`, `automate`) has its own specific options and arguments. Use `fluxctl <command> --help` for detailed information.<br><br>


title: DESCRIPTION
content:
`fluxctl` is the official command-line interface (CLI) for <b>Flux CD</b>, a GitOps tool for Kubernetes. It allows users to interact with a Flux daemon running inside a Kubernetes cluster to manage application deployments and configurations based on a Git repository. Flux automates the deployment of services to Kubernetes by synchronizing the state of a Git repository with the cluster. <br><br>With `fluxctl`, users can perform operations such as releasing new images, automating image updates, suspending or resuming deployments, inspecting logs, and managing Git repository synchronization. It acts as a bridge between the user and the automated GitOps workflow managed by Flux, enabling declarative infrastructure and application management.


title: CAVEATS
content:
`fluxctl` requires a running <b>Flux daemon</b> within a Kubernetes cluster to operate effectively; it does not function standalone to manage Git or Kubernetes directly. <br><br>Proper Kubernetes <b>authentication and authorization</b> are essential, as `fluxctl` leverages your kubeconfig to connect to the cluster and subsequently to the Flux daemon. <br><br>The commands executed via `fluxctl` ultimately rely on the <b>Git repository</b> configured for Flux, meaning changes applied via `fluxctl` are often reflected by updates pushed to Git by Flux itself, or by triggering Flux to pull from Git.


title: <B>GITOPS PRINCIPLE</B>
content:
Flux CD, and by extension `fluxctl`, embodies the <i>GitOps</i> principle: using Git as the single source of truth for declarative infrastructure and applications. All changes to the cluster state are made through Git, which then automatically triggers updates via Flux's reconciliation loop.


title: <B>RECONCILIATION LOOP</B>
content:
The Flux daemon continuously monitors the configured Git repository for changes. When changes are detected, it reconciles the cluster state to match the desired state declared in Git. `fluxctl` commands often interact with or trigger this reconciliation process.


title: <B>IMAGE AUTOMATION</B>
content:
A powerful feature of Flux is its ability to automate image updates. `fluxctl` allows you to 'automate' workloads, meaning Flux will scan container registries for new image versions (e.g., 'latest') and automatically commit updates to your Git repository, which then triggers a deployment.


title: HISTORY
content:
Flux originated as a project by <b>Weaveworks</b>, a pioneer in the GitOps movement. It was one of the earliest and most prominent tools to implement the GitOps principles, automating continuous delivery for cloud-native applications. Initially part of Weaveworks' product suite, Flux later became a core project within the <b>Cloud Native Computing Foundation (CNCF)</b> sandbox, and then graduated to incubating status, signifying its maturity and widespread adoption in the Kubernetes ecosystem. Its development continues as a community-driven project, focusing on robust and scalable GitOps solutions.


title: SYNOPSIS
content:
The Fluxion tool is typically invoked as a shell script with superuser privileges, often executed from its directory.<br><br><b><i>Usage:</i></b><br><b>sudo ./fluxion.sh</b>


title: PARAMETERS
content:
<b><i>(Interactive Menu Options)</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Fluxion is primarily an interactive, menu-driven tool. The following are the main operational phases or choices presented to the user after initial invocation:</i><br><br><b><b>Target Selection</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Allows the user to scan for available Wi-Fi networks and select a target.</i><br><br><b><b>Handshake Sniffing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Initiates deauthentication attacks and attempts to capture a WPA/WPA2 handshake from the target network's clients.</i><br><br><b><b>Fake AP Setup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Configures a rogue access point mimicking the legitimate target network.</i><br><br><b><b>Web Interface Setup</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets up a captive portal/phishing page to prompt users for their Wi-Fi password.</i><br><br><b><b>Deauthentication Attack</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Continuously deauthenticates clients from the legitimate access point to force them to reconnect to the fake AP.</i><br><br><b><b>SSL Certificate Generation</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Generates self-signed SSL certificates for the fake portal to appear more legitimate.</i><br><br><b><b>DNS Server Configuration</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Sets up a local DNS server to redirect traffic to the phishing page.</i><br><br><b><b>Credential Verification</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Verifies captured passwords against the network's handshake or against common password lists.</i><br><br>


title: DESCRIPTION
content:
<i>Fluxion</i> is an advanced, automated wireless security auditing and penetration testing framework designed to simulate sophisticated phishing attacks against Wi-Fi networks. It primarily targets WPA/WPA2-PSK networks. The tool works by leveraging a series of techniques including the creation of a rogue access point (Fake AP), deauthentication attacks to disconnect legitimate clients, and a web-based phishing portal. When clients attempt to reconnect to what they perceive as their original network, they are redirected to a convincing fake login page, prompting them to enter the Wi-Fi password. This method aims to capture the WPA/WPA2 handshake or directly obtain the passphrase through social engineering. Fluxion integrates various well-known tools like <b>aircrack-ng</b>, <b>hostapd</b>, <b>dnsmasq</b>, and web servers to automate these complex steps, making it accessible even for users with moderate technical skills. It's often used by penetration testers to assess network vulnerabilities and user awareness.


title: CAVEATS
content:
Using Fluxion for unauthorized access to Wi-Fi networks is illegal and unethical. It should only be used in environments where explicit permission has been granted, such as for penetration testing with a "get out of jail free" card, or for educational purposes on personal networks. The tool relies on several external dependencies (e.g., <b>aircrack-ng</b> suite, <b>hostapd</b>, <b>dnsmasq</b>, <b>php</b>, <b>xterm</b>) which must be installed and properly configured. Detection by intrusion detection systems (IDS) is possible, as its deauthentication and fake AP activities are prominent. Effectiveness can vary based on network security measures, client behavior, and specific Wi-Fi adapter capabilities.


title: DEPENDENCIES
content:
<i>Fluxion relies heavily on other established tools for its functionality. Key dependencies include the <b>aircrack-ng</b> suite for wireless attacks and handshake capture, <b>hostapd</b> for creating the fake access point, <b>dnsmasq</b> for DNS and DHCP services, and <b>php</b> for serving the phishing web pages. Xterm or similar terminal emulators are often required for spawning multiple terminal windows for different processes. Users must ensure all these tools are installed and properly configured on their system, typically Kali Linux or similar Debian-based distributions.</i>


title: ATTACK METHODOLOGY
content:
<i>The core methodology of Fluxion involves creating an "Evil Twin" attack. It first scans for a target network and its clients. Then, it deauthenticates clients from the legitimate AP, forcing them to disconnect. Simultaneously, it spawns a fake access point with the same SSID as the target. When clients attempt to reconnect, they are directed to the fake AP, which then presents a convincing phishing page (e.g., a router's firmware update page or a network login page) prompting for the Wi-Fi password. Once entered, the password can be captured and, in some cases, verified against the captured handshake or known credentials.</i>


title: HISTORY
content:
Fluxion evolved from earlier Wi-Fi hacking scripts like "linset" and "wifislax," aiming to automate and improve the process of capturing WPA/WPA2 handshakes via social engineering. It gained significant popularity within the cybersecurity community, particularly among users of Kali Linux and other penetration testing distributions, due to its user-friendly, menu-driven interface and comprehensive automation of complex attack vectors. Development continues through various forks on platforms like GitHub, driven by community contributions to adapt to new Wi-Fi security measures and improve reliability.


title: PARAMETERS
content:
<b><b>--target</b>, <b>-t</b> <I>TARGET_NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Concourse target (alias) to interact with. This is usually set via <b>fly login</b>.<br><br><b><b>--insecure</b>, <b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips SSL certificate verification for the Concourse server. Use with caution in production environments.<br><br><b><b>--version</b>, <b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>fly</b> CLI version and exits.<br><br><b><b>login</b> [<I>ALIAS</I>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Authenticates <b>fly</b> with a Concourse server, creating or updating a target alias. This is typically the first command executed.<br><br><b><b>set-pipeline</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A command used for creating or updating a pipeline on a Concourse server.<br><br><b><b>--pipeline</b>, <b>-p</b> <I>PIPELINE_NAME</I> (with <b>set-pipeline</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Name of the pipeline to set or update. Used with the <b>set-pipeline</b> command.<br><br><b><b>--config</b>, <b>-c</b> <I>PATH_TO_CONFIG</I> (with <b>set-pipeline</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the YAML file containing the pipeline definition to upload. Used with the <b>set-pipeline</b> command.<br><br><b><b>trigger-build</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A command used for manually triggering a job within a pipeline.<br><br><b><b>--job</b>, <b>-j</b> <I>PIPELINE/JOB</I> (with <b>trigger-build</b>)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the job within the pipeline to trigger, e.g., <i>my-pipeline/my-job</i>. Used with the <b>trigger-build</b> command.<br><br><b><b>watch</b> <I>BUILD_ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Streams logs of a specific build to the console, useful for real-time monitoring and debugging.<br><br>


title: DESCRIPTION
content:
<b>fly</b> is the command-line interface (CLI) for <i>Concourse CI</i>, an open-source automation server designed for continuous integration and delivery. It serves as the primary tool for users to interact with a Concourse server instance, enabling comprehensive management of CI/CD pipelines, builds, and resources. <br><br>With <b>fly</b>, users can authenticate to various Concourse targets, define and update pipelines from YAML configuration files, trigger and monitor builds, and inspect the status of jobs and resources. It provides essential functionalities for both developers and operators, facilitating tasks such as managing teams and users, viewing build logs, pausing or unpausing pipelines, and debugging pipeline issues. <br><br>The design philosophy of Concourse CI emphasizes "pipelines as code," and <b>fly</b> is instrumental in translating this philosophy into practice by allowing declarative pipeline definitions to be pushed to the server. Its extensive set of commands makes it an indispensable component for anyone utilizing or administering a Concourse CI environment.


title: CAVEATS
content:
<b>fly</b> is a client for <i>Concourse CI</i>; it requires a running Concourse server instance to be functional. <br><br>Authentication via <b>fly login</b> is typically the first step before executing most commands. <br><br>The behavior and available commands can be specific to the version of <i>Concourse CI</i> being used, so ensuring client and server compatibility is important.


title: TARGETS MANAGEMENT
content:
<b>fly</b> manages different <i>Concourse CI</i> server connections through named "targets." A target encapsulates the server URL and authentication tokens, allowing users to switch easily between development, staging, and production Concourse environments using the <b>-t</b> global option.


title: PIPELINES AS CODE
content:
<b>fly</b> primarily works with YAML files to define pipelines. Commands like <b>set-pipeline</b> upload these declarative configurations to the <i>Concourse CI</i> server, enabling version control and collaborative review of CI/CD logic alongside application code.


title: HISTORY
content:
<b>fly</b> was developed as an integral part of the <i>Concourse CI</i> project, which began development around 2014-2015, primarily by engineers at Pivotal (now part of VMware Tanzu). <br><br>Its evolution has mirrored that of Concourse itself, focusing on a declarative, "pipelines as code" approach to CI/CD. <br><br>Initially designed to work seamlessly with Concourse's unique resource and task model, <b>fly</b> has seen continuous improvements in its command set, robustness, and user experience, adapting to the growing demands of modern software delivery pipelines.


title: SYNOPSIS
content:
<b>flyctl</b> <I>[global-options]</I> <I>command</I> <I>[subcommand]</I> <I>[options]</I> <I>[arguments]</I><br><br>Examples:<br><i>flyctl launch</i><br><i>flyctl deploy</i><br><i>flyctl apps list</i><br><i>flyctl logs</i><br><i>flyctl ssh console</i>


title: PARAMETERS
content:
<b><I>--access-token <token></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Authenticates commands using a specific API access token, overriding any locally stored token.</i><br><br><b><I>--app <name></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the application name to operate on. If omitted, it's often inferred from the current directory's 'fly.toml' file.</i><br><br><b><I>--config <path></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Provides an alternative path to the 'flyctl' configuration file, typically 'fly.toml'.</i><br><br><b><I>--debug</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables debug logging, printing detailed information about command execution for troubleshooting.</i><br><br><b><I>--help</I>, <I>-h</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Displays help information for the 'flyctl' command itself or a specific subcommand.</i><br><br><b><I>--json</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Formats the command's output as JSON, which is highly useful for scripting and programmatic consumption.</i><br><br><b><I>--org <name></I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specifies the organization context under which the command should operate.</i><br><br><b><I>--verbose</I>, <I>-v</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enables verbose output, providing more detailed status messages and progress updates during command execution.</i><br><br>


title: DESCRIPTION
content:
<b>flyctl</b> is the official command-line interface (CLI) for interacting with the Fly.io platform. Fly.io provides a global application delivery network, allowing users to deploy and run full-stack applications closer to their users, reducing latency. <br><br><b>flyctl</b> empowers developers to manage every aspect of their Fly.io applications, from initial setup and deployment to scaling, monitoring, and debugging. It facilitates tasks such as creating new applications, deploying code updates, configuring services, managing databases, viewing logs, setting up custom domains, and much more. The CLI abstracts away complex infrastructure details, enabling developers to focus on their code.<br><br>It's a crucial tool for anyone building and operating internet-facing applications on the Fly.io infrastructure, providing a streamlined workflow for development and operations.


title: CAVEATS
content:
<i><b>flyctl</b> requires an active Fly.io account and successful authentication (e.g., via <b>flyctl auth login</b>) for most operations. An internet connection is essential as it interacts with the remote Fly.io platform. The behavior of commands often depends heavily on the presence and content of the <b>fly.toml</b> configuration file in your application directory. Due to Fly.io's rapid development, certain commands, flags, or features may evolve or be deprecated over time, requiring users to keep their <b>flyctl</b> version updated.</i>


title: CONFIGURATION FILE (FLY.TOML)
content:
<i>Many <b>flyctl</b> commands rely heavily on the <b>fly.toml</b> file, which resides in your application's root directory. This TOML-formatted file defines your application's build process, services, environment variables, regions, and other deployment configurations. Understanding and correctly configuring <b>fly.toml</b> is crucial for effective application management on Fly.io.</i>


title: AUTHENTICATION
content:
<i>To use <b>flyctl</b>, you must authenticate with your Fly.io account. The most common method is running <b>flyctl auth login</b>, which typically opens a browser window for a secure OAuth login flow. Upon successful authentication, an access token is stored locally, allowing subsequent <b>flyctl</b> commands to interact with your Fly.io resources.</i>


title: HISTORY
content:
<i>Fly.io, originally known as Nanobox, relaunched in 2019 with a renewed focus on edge deployments and global application distribution. <b>flyctl</b> has been a cornerstone of this transformation, continuously evolving to support the platform's expanding capabilities, including Fly Machines, Volumes, built-in Postgres, and more. Its development reflects Fly.io's commitment to simplifying the deployment and management of web applications (such as Node.js, Ruby on Rails, Phoenix, etc.) across a global infrastructure. It is actively maintained and frequently updated to keep pace with platform innovations and user needs.</i>


title: PARAMETERS
content:
<b><i>-w WIDTH</i>, <i>--width=WIDTH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum line width for the output. Lines will be wrapped to this width. The default width is usually 75 characters.<br><br><b><i>-WIDTH</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A shorthand for <i>-w WIDTH</i>. For example, <i>-72</i> sets the width to 72 characters.<br><br><b><i>-c</i>, <i>--crown-margin</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Preserves the indentation of the first two lines of a paragraph, but reflows subsequent lines to match the second line's indentation.<br><br><b><i>-p PREFIX</i>, <i>--prefix=PREFIX</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reformat only lines that begin with <i>PREFIX</i>, preserving the prefix and its indentation. Other lines are passed through unchanged.<br><br><b><i>-s</i>, <i>--split-only</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Splits long lines that exceed the target width, but does not reflow shorter lines or combine lines to fill space. Useful for simple line breaking without full reformatting.<br><br><b><i>-t</i>, <i>--tagged-paragraph</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats the first line of a paragraph as a tag. Subsequent lines are indented to align with the first non-whitespace character of the first line.<br><br><b><i>-u</i>, <i>--uniform-spacing</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses uniform spacing: one space between words, and two spaces between sentences (after a period, question mark, or exclamation point followed by a space).<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information and exits.<br><br>


title: DESCRIPTION
content:
The <b>fmt</b> command is a straightforward utility used to format plain text files or standard input. Its primary function is to reflow text paragraphs to fit a specified maximum line width. It automatically breaks lines, preserving blank lines and initial indentation as paragraph separators. This makes it ideal for cleaning up emails, code comments, or general plain text documents where consistent line length is desired. By default, <b>fmt</b> attempts to produce output that is easy to read, handling word breaks and spacing intelligently. It reads input from files provided as arguments or from standard input if no files are specified, and writes the formatted output to standard output.


title: CAVEATS
content:
<b>fmt</b> is a simple text formatter and has certain limitations. It treats blank lines as strict paragraph separators, which might not be desirable for all document types (e.g., source code). It lacks advanced features found in word processors, such as handling tables, lists, or complex nested structures. Using options like <i>--prefix</i> or <i>--tagged-paragraph</i> requires careful consideration to avoid unintended formatting of content that doesn't strictly adhere to the expected pattern. For very complex or structured documents, more powerful text processing tools or dedicated markup languages might be more appropriate.


title: PARAGRAPH DEFINITION
content:
<b>fmt</b> defines a paragraph as a sequence of non-blank lines separated by one or more blank lines. Each paragraph is formatted independently.


title: INPUT AND OUTPUT
content:
If no <i>FILE</i> arguments are given, <b>fmt</b> reads from standard input and writes to standard output. If <i>FILE</i>s are provided, it processes each file sequentially. Output is always written to standard output, making it suitable for piping with other commands.


title: HISTORY
content:
The <b>fmt</b> command is a venerable utility that has been a standard part of Unix-like operating systems for decades. It originated in early Unix versions, with its core functionality of simple paragraph reflowing remaining largely consistent. In the GNU ecosystem, it is part of the <B>GNU Core Utilities</B> (coreutils) package, which provides essential command-line tools. Its development within coreutils focuses on maintaining compatibility, robustness, and performance across various Linux distributions, ensuring its continued relevance for basic text manipulation tasks.


title: SYNOPSIS
content:
<b>fnm</b> <i>[options]</i> <command><br><b>fnm</b> install <i>[version]</i><br><b>fnm</b> use <i>[version]</i><br><b>fnm</b> default <i>[version]</i><br><b>fnm</b> exec <i>[version]</i> -- <command><br><b>fnm</b> env


title: PARAMETERS
content:
<b>install <i>[version]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Installs a specific Node.js version. Can be 'latest', 'lts', or a precise version number (e.g., '16.14.0').<br><br><b>use <i>[version]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Switches the current shell to use a specified Node.js version. Prompts for installation if the version isn't already present.<br><br><b>default <i>[version]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets a specific Node.js version as the system-wide default for future shell sessions.<br><br><b>list | ls</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all Node.js versions currently installed by <i>fnm</i>.<br><br><b>uninstall <i>[version]</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes a specified Node.js version from the system.<br><br><b>current</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the Node.js version currently active in the shell.<br><br><b>exec <i>[version]</i> -- <command></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a command using a specified Node.js version without altering the shell's active version.<br><br><b>env</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs shell commands (e.g., export PATH) required to set up <i>fnm</i>. Must be sourced in your shell's configuration file.<br><br><b>--help | -h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for <i>fnm</i> or a specific subcommand.<br><br><b>--version | -v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the installed <i>fnm</i> version.<br><br><b>--force | -f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces an operation, such as re-installing an existing Node.js version.<br><br>


title: DESCRIPTION
content:
<i>fnm</i> (Fast Node Manager) is a Node.js version manager developed in Rust, designed to be significantly faster and more lightweight than traditional alternatives like <i>nvm</i>.<br><br>It enables users to easily install, switch between, and manage multiple Node.js versions on their system. <i>fnm</i> automatically detects Node.js versions via <b>.node-version</b> or <b>.nvmrc</b> files, streamlining development workflows. Its performance benefits are especially noticeable in environments requiring frequent Node.js version changes, such as CI/CD pipelines or large monorepos. <i>fnm</i> integrates seamlessly with common shells by providing environment setup commands, ensuring a smooth user experience across various platforms including Linux, macOS, and Windows.


title: CAVEATS
content:
For <i>fnm</i> to function correctly across shell sessions, the output of <b>fnm env</b> must be sourced in your shell's configuration file (e.g., <b>.bashrc</b>, <b>.zshrc</b>). This ensures the correct PATH and other environment variables are set. While highly performant, it may not support every niche feature found in more mature Node.js managers like <i>nvm</i>.


title: AUTOMATIC VERSION SWITCHING
content:
<i>fnm</i> supports automatic Node.js version switching based on <b>.node-version</b> or <b>.nvmrc</b> files located in the current directory or any parent directory. This feature helps maintain consistent Node.js environments across different projects without manual intervention.


title: CROSS-PLATFORM COMPATIBILITY
content:
Built with Rust, <i>fnm</i> offers excellent cross-platform compatibility, providing a consistent Node.js management experience on Linux, macOS, and Windows operating systems.


title: HISTORY
content:
<i>fnm</i> was created by Gal Schlezinger (Schniz) and first publicly released in 2019. Its development was driven by a need for a faster and more efficient Node.js version manager, particularly for scenarios where <i>nvm</i>'s performance could be a bottleneck. By being written in Rust, <i>fnm</i> achieves native performance and a smaller footprint, quickly gaining popularity in the Node.js ecosystem.


title: PARAMETERS
content:
<b><b>-b</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate byte-order independent output for font data (typically big-endian).<br><br><b><b>-c</b> <I>column</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the number of characters per line when outputting bitmap data arrays.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate glyph tables for the font, including character mappings.<br><br><b><b>-h</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate only a header file (.h) with font declarations, without the full C source.<br><br><b><b>-o</b> <I>outputfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the name of the output C source file. If not provided, output goes to standard output.<br><br><b><b>-p</b> <I>prefix</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a string to be used as a prefix for all font symbol names in the generated code.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output raw bitmap data only, without including font structures or metadata.<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include character size information within the generated font data structures.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use tab characters for indentation in the generated C code instead of spaces.<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume that the input BDF file uses UTF-8 character encoding.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing progress and additional information during conversion.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Output bitmap data in Y-major (vertical scanline first) order rather than X-major.<br><br>


title: DESCRIPTION
content:
<i>font2c</i> is a utility that converts font files, specifically those in the <b>Bitmap Distribution Format (BDF)</b>, into C source code.<br>This C code typically defines data structures and arrays representing the font's characters (glyphs) and their raw bitmap data.<br>Its primary use case is embedding font data directly into applications, especially in environments where dynamic font loading is not feasible or desired, such as embedded systems, graphics libraries, or bootloaders.<br>By compiling the font data directly into the executable, it eliminates the need for external font files at runtime and ensures consistent font availability.<br>The generated C code can then be compiled alongside the application's source, providing a static, portable, and efficient way to integrate fonts into software projects.<br>The tool offers various options to control the output format, naming conventions, and specific data inclusions like character sizes or byte order.


title: CAVEATS
content:
<i>font2c</i> primarily supports the <b>Bitmap Distribution Format (BDF)</b> as its input; it cannot directly convert other modern font formats like TrueType (TTF) or OpenType (OTF).<br>The specific structure and contents of the generated C code can vary slightly between different implementations or versions of <i>font2c</i> (e.g., the X.Org version often named <i>xfnt2c</i> versus other embedded-specific tools).<br>Embedding font data directly into an executable, while convenient, will increase the overall size of the compiled binary.


title: INPUT FONT FORMAT
content:
The utility exclusively uses the <b>Bitmap Distribution Format (BDF)</b> as its input. BDF is a plain-text format for bitmap fonts, describing glyphs as an array of pixels. This makes it suitable for tools like <i>font2c</i> to parse and convert directly into structured C data.


title: OUTPUT STRUCTURE
content:
The generated C code typically includes a structure (e.g., <code>FontRec</code>) containing metadata about the font (like character metrics, default character, first/last character) and arrays holding the raw bitmap data for each glyph. This allows applications to directly access pixel data for rendering without external font files.


title: HISTORY
content:
The concept of converting font bitmaps into C code has a long history, particularly in the context of early graphical user interfaces and the X Window System. The <i>font2c</i> utility, often implemented as <i>xfnt2c</i> as part of the X.Org font utilities, emerged to address the need for embedding font data directly into X server modules or applications requiring static font resources. Its design reflects the bitmap-centric approach to fonts prevalent in earlier graphical environments, providing a means to compile font resources directly into executable code for efficiency and portability.


title: SYNOPSIS
content:
<i><b>fontforge</b></i> [<i><b>-script</b></i> <I>scriptfile</I>] [<i><b>-c</b></i> <I>script-string</I>] [<i><b>-lang</b></i> <I>language</I>] [<i><b>-new</b></i>] [<i><b>-quit</b></i>] [<i><b>-dry</b></i>] [<i><b>-csv</b></i> <I>file</I>] [<i><b>-depth</b></i> <I>num</I>] [<i><b>-display</b></i> <I>display</I>] [<i><b>-sync</b></i>] [<i><b>-version</b></i>] [<i><b>-usage</b></i>] [<i><b>-help</b></i>] [<I>fontfile ...</I>]


title: PARAMETERS
content:
<b><i><fontfile ...></fontfile></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more font files to open or process. If no files are specified, <i><b>FontForge</b></i> starts with an empty font.<br><br><b><i><b>-script</b></i> <I>scriptfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes the specified script file. <i><b>FontForge</b></i> can run scripts written in its own language or Python. If this option is used, <i><b>FontForge</b></i> typically operates in a non-GUI mode unless the script explicitly invokes the GUI.<br><br><b><i><b>-c</b></i> <I>script-string</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes a string as a script. This is useful for short, inline scripting commands, often used in conjunction with <i><b>-quit</b></i> for batch operations.<br><br><b><i><b>-lang</b></i> <I>language</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the user interface language. For example, 'en' for English, 'fr' for French.<br><br><b><i><b>-new</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts <i><b>FontForge</b></i> with a new, empty font. This is the default if no font files are specified.<br><br><b><i><b>-quit</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exits <i><b>FontForge</b></i> immediately after executing a script or processing command-line arguments. Essential for batch processing.<br><br><b><i><b>-dry</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a 'dry run' for scripting operations, meaning it will not save any changes to files. Useful for testing scripts.<br><br><b><i><b>-csv</b></i> <I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Outputs character information (glyph names, encodings, etc.) to the specified CSV file.<br><br><b><i><b>-depth</b></i> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the display depth (color depth) for the X server. Relevant for GUI mode.<br><br><b><i><b>-display</b></i> <I>display</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X display to use. Standard X option.<br><br><b><i><b>-sync</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synchronizes X operations. Can be useful for debugging display issues.<br><br><b><i><b>-version</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <i><b>FontForge</b></i> version information and exits.<br><br><b><i><b>-usage</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a brief usage message and exits.<br><br><b><i><b>-help</b></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints a detailed help message describing command-line options and exits.<br><br>


title: DESCRIPTION
content:
<i><b>FontForge</b></i> is a powerful open-source font editor that allows users to create, modify, and convert various font formats. It supports a wide array of outline font formats, including TrueType, OpenType, PostScript Type1, CID-keyed PostScript, multi-master fonts, and SVG fonts. Beyond its graphical user interface for detailed glyph editing, <i><b>FontForge</b></i> offers extensive scripting capabilities, allowing for automated font manipulation, batch processing, and complex transformations using either its internal scripting language or Python. This makes it an invaluable tool for professional typographers, font designers, and developers working with typography, enabling precise control over character shapes, kerning, hinting, and font metrics. It is widely used in the open-source community for developing and maintaining free fonts.


title: CAVEATS
content:
<i><b>FontForge</b></i>'s primary mode of operation involves a graphical user interface (GUI), which typically requires an X server running on Linux systems. When used without an X server, or for automated tasks, it relies heavily on its powerful scripting capabilities (via <i><b>-script</b></i> or <i><b>-c</b></i> options) as the GUI will not be available. While extremely versatile, its extensive features can present a steep learning curve for new users, particularly for advanced font design concepts like hinting and OpenType features.


title: SCRIPTING CAPABILITIES
content:
<i><b>FontForge</b></i>'s strength lies significantly in its scripting capabilities, supporting both its own internal scripting language and Python. This allows users to automate complex font operations, such as applying transformations to all glyphs, generating font variants, or performing format conversions in batch. This headless operation is crucial for integration into build systems or for large-scale font processing tasks without manual GUI interaction.


title: BATCH PROCESSING
content:
The command-line interface, especially when combined with the <i><b>-script</b></i> or <i><b>-c</b></i> options and the <i><b>-quit</b></i> flag, enables <i><b>FontForge</b></i> to be used effectively for batch processing. This means it can be invoked from shell scripts to convert hundreds of font files from one format to another, apply a set of standard corrections, or generate different font versions (e.g., hinted vs. unhinted) automatically, greatly enhancing productivity for font developers.


title: HISTORY
content:
<i><b>FontForge</b></i> was originally created by <i>George Williams</i> under the name <i>PfaEdit</i>, with the first version released in 2001. It was developed to provide a free and open-source alternative to commercial font editing software. Renamed to <i><b>FontForge</b></i>, it quickly became a cornerstone tool for the open-source typography community, enabling the creation and modification of numerous libre fonts. Its development has been community-driven since <i>George Williams</i> stepped down from active maintenance, ensuring its continued evolution and adaptation to new font technologies and user needs. It remains the go-to open-source solution for comprehensive font development.


title: PARAMETERS
content:
<b><b>-s</b> <i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the font point size for rendering characters in the image.<br><br><b><b>-e</b> <i>&lt;encoding&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the character encoding for the input text, e.g., <i>latin1</i>, <i>utf8</i>.<br><br><b><b>-c</b> <i>&lt;char_list&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A list of characters or character ranges to display, such as "<i>A-Z</i>" or "<i>32-126</i>".<br><br><b><b>-w</b> <i>&lt;width&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the width of the output image in pixels.<br><br><b><b>-h</b> <i>&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the height of the output image in pixels.<br><br><b><b>-o</b> <i>&lt;output_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the output image file. Defaults to "<i>font.gif</i>".<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders the font at standard resolution without anti-aliasing, resulting in pixelated edges.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Renders font glyphs as solid filled shapes rather than outlines or stroked paths.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of the <b>fontimage</b> utility.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays all characters found within the specified font file, potentially including unassigned glyphs.<br><br><b><b>-p</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Pads characters with extra space to ensure proper separation in the output image.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses an older or alternative character dumping method; generally not recommended for modern use.<br><br>


title: DESCRIPTION
content:
The <b>fontimage</b> command is a utility designed to generate a GIF image from a specified font file.<br>It's commonly used for previewing fonts, allowing users to visualize how characters look at various sizes and with different rendering options.<br>This tool is particularly useful for designers, developers, or anyone needing to inspect font glyphs without installing the font system-wide or opening a dedicated font viewer.<br>It can render specific character ranges, adjust point sizes, and control anti-aliasing, providing a quick visual reference for a font's appearance.<br>The output is typically saved as a GIF file, making it easily viewable and shareable.


title: CAVEATS
content:
The <b>fontimage</b> command primarily generates images in GIF format, which might be a limitation for users requiring other image types.<br>Its functionality is deeply tied to the FreeType library; issues with FreeType installation or configuration can affect its operation.<br>Character encoding issues can arise if the specified encoding does not match the font's actual encoding or the input character list.


title: COMMON USAGE
content:
<b>fontimage</b> is often used to quickly check a font's appearance with specific text or character sets.<br>For instance, to generate an image of "Hello World" from "<i>myfont.ttf</i>" at 24pt, you might use: <i>fontimage -s 24 -c "Hello World" myfont.ttf -o output.gif</i>.<br>To see all ASCII characters (32-126) from a font, you could use: <i>fontimage -s 16 -c "32-126" myfont.ttf</i>.


title: DEPENDENCIES
content:
This command relies on the FreeType library for font rendering. Ensure FreeType and its development headers are properly installed on your system for <b>fontimage</b> to compile and run correctly.


title: HISTORY
content:
The <b>fontimage</b> utility is distributed as part of the FreeType font rendering library's demonstration programs.<br>It serves as a practical example of how to use FreeType's APIs to render fonts and manipulate glyphs, rather than being a standalone command with a distinct, long development history independent of FreeType itself.<br>Its primary purpose has always been to showcase FreeType's capabilities for font previewing.


title: PARAMETERS
content:
<b>-o <I>outfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output filename for the converted font or font collection.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Create a TrueType Collection (TTC) from the input fonts. When this option is used, all input fonts are combined into a single .ttc file.<br><br><b>-g <I>mapfile</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Use the specified glyph name mapping file for conversion. This allows custom mapping of PostScript glyph names to Unicode code points.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the conversion process.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a help message and exit, showing available options and usage.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information of the <b>fonttosfnt</b> utility and exit.<br><br>


title: DESCRIPTION
content:
<b>fonttosfnt</b> is a command-line utility designed to convert PostScript Type 1 font files (both ASCII-encoded PFA and binary-encoded PFB) into the Scalable Font Format (SFNT), which primarily encompasses TrueType and OpenType fonts. This tool is part of the X.Org font utilities and is crucial for environments that require fonts in the SFNT format but only have them available in PostScript Type 1. It can create individual TrueType/OpenType files or consolidate multiple fonts into a single TrueType/OpenType Collection (TTC) file, which is useful for bundling font families. The conversion process involves embedding PostScript outlines within the SFNT wrapper, allowing them to be rendered by TrueType/OpenType compatible renderers. It's particularly useful in X Window System environments for preparing fonts for display and ensuring broader compatibility.


title: CAVEATS
content:
This utility primarily converts PostScript Type 1 outlines into an SFNT wrapper. While it enables use of these fonts in TrueType/OpenType environments, it may not support the full range of advanced OpenType features beyond basic outline embedding. Glyph mapping, especially for non-standard encodings or very specific typographic requirements, might require careful configuration using a <code>-g</code> map file.


title: INPUT/OUTPUT FORMATS
content:
The command takes PostScript Type 1 font files, either ASCII PFA (<code>.pfa</code>) or binary PFB (<code>.pfb</code>), as input. It outputs them as TrueType (<code>.ttf</code>), OpenType (<code>.otf</code>), or TrueType Collection (<code>.ttc</code>) files, effectively embedding the PostScript outlines within the SFNT wrapper for compatibility with modern font rendering engines.


title: INTEGRATION WITH X.ORG FONT SYSTEM
content:
<code>fonttosfnt</code> is an integral part of the X.Org font infrastructure, enabling the use of a wider range of fonts within the X Window System. After conversion, the generated SFNT files can be placed in standard X font paths. To make these fonts available to applications, utilities like <code>mkfontscale</code> and <code>mkfontdir</code> are typically run in the font directory to generate font index files (<code>fonts.scale</code> and <code>fonts.dir</code>).


title: HISTORY
content:
Part of the X.Org font utilities, <b>fonttosfnt</b> emerged to bridge the gap between widely available PostScript Type 1 fonts and the growing adoption of SFNT formats like TrueType and OpenType within the X Window System. Its development reflects the need for X servers and applications to render fonts efficiently using a unified font subsystem, integrating older PostScript outlines into modern scalable font architectures. It has been a stable component within the X.Org ecosystem for preparing fonts for display.


title: SYNOPSIS
content:
<b>foo2hbpl2</b> [<i>OPTIONS</i>] [<i>FILE</i>]<br><br><i>FILE</i>: The PostScript input file. If omitted, <b>foo2hbpl2</b> reads from standard input.<br><i>OPTIONS</i>: Various options to control printing parameters, typically used by CUPS or for testing.


title: PARAMETERS
content:
<b>-r &lt;resolution&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired printing resolution (e.g., <i>600</i>, <i>1200</i> dpi).<br><br><b>-d &lt;duplex_mode&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (double-sided) printing. Common modes: <i>1</i> (long edge), <i>2</i> (short edge).<br><br><b>-c &lt;color_mode&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the color mode. Typically <i>cmyk</i> for color, <i>grayscale</i> for monochrome.<br><br><b>-m &lt;media_size&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the media (paper) size (e.g., <i>Letter</i>, <i>A4</i>, <i>Legal</i>).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates toner save mode, reducing toner consumption at the expense of print quality.<br><br><b>-s &lt;source_type&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source or tray.<br><br><b>-L &lt;level&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for verbose output, useful for troubleshooting.<br><br>


title: DESCRIPTION
content:
<b>foo2hbpl2</b> is an open-source printer driver that translates PostScript input into the proprietary HBPL2 (HP Bi-directional Printer Language 2) data format used by certain Hewlett-Packard LaserJet printers. It is part of the <i>foo2zjs</i> project, a suite of drivers designed to support printers that employ various custom data streams, including ZJS, QPD, HBPL1, and HBPL2. This utility functions primarily as a filter within the Common Unix Printing System (CUPS) pipeline. When a user prints a document, CUPS typically converts it to PostScript, which <b>foo2hbpl2</b> then processes. The driver handles the conversion of vector graphics, text, and raster images into the specific commands and data structures understood by HBPL2-compatible printers. It allows Linux and Unix-like systems to print to a range of HP LaserJet devices that would otherwise lack native driver support, enabling features like resolution control, duplex printing, and media size selection.


title: CAVEATS
content:
<b><br></b><br><b>Requires:</b> A PostScript interpreter like <i>Ghostscript</i> (<b>gs</b>) to be installed, as it processes PostScript input.<br><b>Compatibility:</b> Only supports specific HP LaserJet printers that utilize the HBPL2 language.<br><b>Limitations:</b> Full printer functionality (e.g., advanced finishing options) might not be exposed or supported by the driver.<br><b>Configuration:</b> May require manual configuration within CUPS for optimal performance or specific features.


title: HISTORY
content:
The <b>foo2hbpl2</b> driver is part of the <i>foo2zjs</i> project, initiated by Rick Richardson. This project emerged to provide open-source support for a range of Hewlett-Packard and Samsung printers that use proprietary page description languages (PDLs) instead of standard PostScript or PCL. Development began as reverse-engineering efforts to understand these proprietary protocols, including HP's HBPL2. The <i>foo2zjs</i> suite, including <b>foo2hbpl2</b>, became an essential component for enabling Linux and Unix-like systems to utilize these printers, filling a significant gap left by official vendor driver support. It has been continually updated to support new printer models and improve compatibility.


title: PARAMETERS
content:
<b>-r <i><xres>x<yres></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printer resolution in dots per inch (DPI), e.g., 600x600.<br><br><b>-d<i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies duplex (double-sided) printing mode. Common values are <i>1</i> for long-edge binding and <i>2</i> for short-edge binding.<br><br><b>-p<i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper size. For example, <i>0</i> for Letter, <i>1</i> for Legal, <i>2</i> for A4. Specific values depend on the printer model.<br><br><b>-m<i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the media type. For example, <i>0</i> for Plain Paper, <i>1</i> for Transparency.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables toner save mode, reducing toner consumption for draft quality.<br><br><b>-l <i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the darkness/lightness of the printout. Values typically range from <i>0</i> (lightest) to <i>100</i> (darkest).<br><br><b>-s <i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the input paper tray. For example, <i>0</i> for the main tray, <i>1</i> for the manual feed slot.<br><br><b>-A</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically determines paper size from the input document's PostScript/PDF properties.<br><br><b>-G <i><gamma></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies gamma correction to the output image to adjust brightness and contrast.<br><br><b>-L</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints in landscape orientation, rotating the image 90 degrees.<br><br><b>-o <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the output to a specified <i>file</i> instead of standard output (stdout).<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing progress and debug information to stderr.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available options and their usage.<br><br>


title: DESCRIPTION
content:
The <b>foo2hbpl2-wrapper</b> command acts as a crucial interface for Linux systems to print to specific Host-Based (GDI) HP LaserJet printers, particularly the 1000 and 1005 series, that use the proprietary HbPL2 (Host-based Printer Language 2) page description language. Unlike PostScript or PCL printers, these devices rely on the host computer to render print jobs into a raster image, which is then sent to the printer. <br><br>This wrapper script typically receives PostScript or PDF input (often from CUPS, Ghostscript, or directly via a pipe), processes it, converts it into the printer's native HbPL2 format, and then sends the raw data to the printer. It is an integral part of the <b>foo2zjs</b> project, enabling broad support for many otherwise unsupported HP printers on Linux.


title: CAVEATS
content:
<b>Firmware Dependency</b>: Some HP LaserJet 1000/1005 models require a proprietary firmware file to be downloaded to the printer at startup. This firmware is often not included with the driver and must be obtained separately or installed via a helper script (e.g., <b>foo2zjs-install</b>). Without the correct firmware, the printer will not function.<br><br><b>Monochrome Only</b>: The HbPL2 language and associated printers are monochrome (black and white) only. Color information in input documents will be converted to grayscale.<br><br><b>Host-Based Processing</b>: As a host-based solution, significant CPU resources on the host computer are used to render the print job, which can be slower than PCL or PostScript printers that handle rendering internally.


title: FIRMWARE DOWNLOAD
content:
For HP LaserJet 1000/1005 printers, a small proprietary firmware file must be downloaded to the printer's RAM each time the printer is powered on. This is often handled by a helper script or by CUPS, but users should be aware that the printer may appear unresponsive until this firmware is loaded.


title: HISTORY
content:
The <b>foo2hbpl2-wrapper</b> command is an integral part of the <b>foo2zjs</b> open-source project, initiated and primarily developed by Rick van Rein. The project began in the early 2000s to provide Linux support for a wide range of previously unsupported Host-Based (GDI) printers, particularly those from HP, Lexmark, and Minolta, which used proprietary page description languages like ZjStream, HbPL2, and ZjStream. Its development filled a critical gap, enabling users to continue using affordable consumer-grade printers on Linux without manufacturer-supplied drivers.


title: PARAMETERS
content:
<b><b>-r</b> <I>res</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the resolution for the output, in dots per inch (DPI). Common values include 600 or 1200.<br><br><b><b>-g</b> <I>gamma</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a gamma correction value to adjust image brightness and contrast. A value of 1.0 indicates no correction.<br><br><b><b>-d</b> <I>duplex</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the duplex printing mode: <I>0</I> for no duplex, <I>1</I> for long-edge binding, or <I>2</I> for short-edge binding.<br><br><b><b>-c</b> <I>color</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the color mode for printing: <I>0</I> for greyscale (monochrome) or <I>1</I> for color output.<br><br><b><b>-L</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls linear mode for dithering, affecting how colors are rendered. Typically <I>0</I> (off) or <I>1</I> (on).<br><br><b><b>-m</b> <I>media</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the media (paper) size, e.g., <I>Letter</I>, <I>Legal</I>, <I>A4</I>, <I>A5</I>.<br><br><b><b>-p</b> <I>source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source or tray, usually an integer representing the tray number (e.g., <I>1</I> for main tray).<br><br><b><b>-n</b> <I>N-up</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables N-up printing, where multiple pages are printed per physical sheet of paper (e.g., <I>2</I> for 2-up, <I>4</I> for 4-up).<br><br><b><b>-s</b> <I>source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input source. <I>0</I> typically denotes standard input (stdin).<br><br><b><b>-t</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the top offset for printing, in points.<br><br><b><b>-b</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bottom offset for printing, in points.<br><br><b><b>-l</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the left offset for printing, in points.<br><br><b><b>-R</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the right offset for printing, in points. Note: The option is capitalized 'R' to distinguish from lowercase 'r' for resolution.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically scales pages to fit the selected media size.<br><br><b><b>-G</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs the command to use Ghostscript's own gamma processing, rather than internal adjustments.<br><br><b><b>-X</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the horizontal (X) offset in pixels.<br><br><b><b>-Y</b> <I>num</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the vertical (Y) offset in pixels.<br><br><b><b>-P</b> <I>printer</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific printer model or variant if the driver supports multiple devices under the Hiper protocol.<br><br><b><b>-u</b> <I>units</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the units for offset parameters: <I>0</I> (points), <I>1</I> (pixels), <I>2</I> (mils), <I>3</I> (mm).<br><br><b><b>-D</b> <I>level</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for verbose output, useful for troubleshooting. Higher numbers typically mean more detailed output.<br><br>


title: DESCRIPTION
content:
<b>foo2hiperc</b> is a utility that converts PostScript (PS) files into a proprietary raster format used by certain printers, particularly those employing the Hiper protocol, often associated with Zenographics ZjStream. It is part of the <I>foo2zjs</I> project, a collection of drivers and filters designed to support various GDI (Graphics Device Interface) printers that lack native PostScript support. This command acts as a filter, typically taking PostScript input from <I>stdin</I> or a specified file and outputting the printer-specific data to <I>stdout</I>. It handles various aspects of print job preparation, including resolution, paper size, duplexing, and color adjustments, enabling Linux users to print to otherwise unsupported hardware.


title: CAVEATS
content:
<b>foo2hiperc</b> requires a Ghostscript installation to convert PostScript input into an intermediate bitmap format before generating the printer-specific output. Its output is binary data tailored for Hiper-compatible printers and is not human-readable. Support is dependent on the specific printer's compatibility with the reverse-engineered Hiper protocol.


title: DEPENDENCIES
content:
A functional Ghostscript installation is mandatory for <b>foo2hiperc</b> to operate, as it relies on Ghostscript to render PostScript files into an intermediate raster format before conversion to the printer's native language.


title: TYPICAL USAGE FLOW
content:
<b>foo2hiperc</b> is commonly employed as a backend filter within a print spooling system like CUPS (Common Unix Printing System). A PostScript print job is directed to <b>foo2hiperc</b>, which processes it, and the resulting printer-specific binary data is then sent directly to the printer device, often via a USB or network interface.


title: HISTORY
content:
The <b>foo2hiperc</b> command is an integral part of the <I>foo2zjs</I> open-source project, initiated by Rick Richardson. This project emerged to address the lack of Linux drivers for various GDI-based laser printers that utilized proprietary, host-based print languages like Zenographics ZjStream. <b>foo2hiperc</b> specifically targets printers communicating via the Hiper protocol. The <I>foo2zjs</I> suite gained significant popularity as it provided a robust open-source solution, allowing Linux users to utilize otherwise unsupported and often more affordable laser printers, thereby filling a crucial gap in printer driver availability, particularly in the early 2000s.


title: PARAMETERS
content:
<b>-r <xres>x<yres></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printing resolution, e.g., <br><b>-r 600x600</b><br>.<br><br><b>-g <gamma></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies gamma correction, e.g., <br><b>-g 1.8</b><br>.<br><br><b>-d <duplex></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing.<br><b>1</b><br> for long-edge binding, <br><b>2</b><br> for short-edge binding.<br><br><b>-c <color></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the color mode.<br><b>1</b><br> for black and white/grayscale, <br><b>3</b><br> for full color.<br><br><b>-m <media></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the media type, such as <br><b>0</b><br> for plain paper, <br><b>1</b><br> for photo paper.<br><br><b>-p <paper></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the paper size (e.g., <br><b>0</b><br> for A4, <br><b>1</b><br> for Letter).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Activates toner save mode, which uses less ink/toner.<br><br><b>-s <source></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Chooses the input tray/source.<br><br><b>-T <text_quality></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the text print quality level.<br><br><b>-P <photo_quality></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the photo print quality level.<br><br><b>-k</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces printing to use black ink only (K-only mode).<br><br><b>-o <outfile></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an output file instead of standard output.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays usage information and exits.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information and exits.<br><br>


title: DESCRIPTION
content:
<i>foo2hp</i> is a <br>Ghostscript <br>driver for printers that use the <br>HP Inkjet Photo (HP-IJP) <br>language, specifically supporting models like the <br>HP DeskJet 1200C <br>and <br>HP Color Inkjet cp1700<br>. It is an essential component of the <br>foo2zjs <br>project, which provides open-source drivers for various proprietary printer languages.<br><br>The primary function of <br>foo2hp <br>is to convert <br>PostScript <br>data, typically generated by <br>Ghostscript (gs)<br>, into the native HP-IJP format that these specific HP inkjet printers understand. This enables Linux users to print to these devices, bridging the gap between standard PostScript output and the printer's proprietary language.<br><br>It typically operates as part of a printing pipeline, receiving PostScript input from <br>Ghostscript <br>via a pipe, processing it, and then sending the formatted data either to standard output (which can then be piped to a print spooler like <br>lpr <br>or a device file) or directly to an output file. This allows for fine-grained control over print quality, resolution, paper handling, and color management.


title: CAVEATS
content:
<i>foo2hp</i> is specifically designed for older HP Inkjet Photo printers that use the <br>HP-IJP <br>language, such as the <br>HP DeskJet 1200C <br>and <br>HP Color Inkjet cp1700<br>. It will <br>not <br>work with modern HP printers that typically use <br>PCL<br>, <br>PostScript<br>, or <br>HP PCL3 GUI<br>.<br><br>Its functionality relies on <br>Ghostscript <br>to provide the initial PostScript input, making it part of a larger printing workflow rather than a standalone printer driver. As a component of the <br>foo2zjs <br>project, users might need to install the entire suite for full functionality or proper integration with CUPS.


title: TYPICAL WORKFLOW
content:
<i>foo2hp</i> is commonly used in a pipeline with <br>Ghostscript <br>and a print spooler like <br>lpr<br>:<br><br><b>gs -q -dBATCH -dNOPAUSE -sDEVICE=foo2hp -sOutputFile='|foo2hp -r 600x600 -p 0 -c 3 -' - | lpr</b><br><br>This command chain takes a PostScript input (implicitly from stdin due to <br>gs<br> options), processes it with <br>Ghostscript <br>using the <br>foo2hp <br>device, pipes the output through <br>foo2hp <br>with specific options, and then sends the final printer-ready data to the default printer via <br>lpr<br>.


title: INTEGRATION WITH CUPS
content:
For modern Linux distributions, <br>foo2hp <br>is often integrated with the <br>Common Unix Printing System (CUPS)<br>. CUPS can be configured to use <br>foo2hp <br>as a filter in its printing pipeline, abstracting the command-line usage from the end-user. This provides a user-friendly way to manage and print to supported HP-IJP printers through graphical interfaces or standard printing dialogues.


title: HISTORY
content:
<i>foo2hp</i> emerged as part of the broader <br>foo2zjs <br>project, initiated by <br>Rick Richardson<br>. The project aimed to provide open-source drivers for various budget-friendly printers that utilized proprietary page description languages (PDLs) instead of standard <br>PostScript <br>or <br>PCL<br>. <br>foo2hp <br>was specifically developed to support HP printers using the <br>HP Inkjet Photo (HP-IJP) <br>protocol, which was a common language for certain HP inkjet models in the late 1990s and early 2000s, such as the <br>HP DeskJet 1200C<br> and <br>HP Color Inkjet cp1700<br>.<br><br>Its development allowed Linux and Unix users to gain printing capabilities for these specific devices, which would otherwise have been unsupported due to the proprietary nature of their communication protocols. It represents a significant effort in the open-source community to ensure hardware compatibility.


title: PARAMETERS
content:
<b>-r &lt;resolution&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the print resolution, typically <i>600 dpi</i>. This option is passed to the underlying <b>foo2hp2600</b> filter.<br><br><b>-d &lt;duplex_mode&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (double-sided) printing. Common modes are <i>1</i> for long-edge binding and <i>2</i> for short-edge binding. Default is simplex (no duplex).<br><br><b>-s &lt;source_tray&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source tray. For example, <i>0</i> for auto-select, <i>1</i> for tray 1 (manual feed), etc. This depends on printer capabilities.<br><br><b>-p &lt;paper_size&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper size for the print job, such as <i>letter</i>, <i>A4</i>, or <i>legal</i>. Default is usually 'letter'.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces color output. This is often the default behavior for color printers.<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces monochrome (black and white) output. This option overrides any color settings.<br><br><b>-n &lt;copies&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the number of copies to print for the current job. Default is <i>1</i>.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Runs in quiet mode, suppressing most status and informational messages from the filter.<br><br><b>-X &lt;dump_file&gt;</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Dumps the raw printer data stream to the specified file, useful for debugging purposes.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <b>foo2hp2600</b> filter and related components.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message, listing available command-line options.<br><br>


title: DESCRIPTION
content:
The <b>foo2hp2600-wrapper</b> is a shell script primarily designed to facilitate printing to the HP Color LaserJet 2600n printer on Linux systems, typically through the CUPS (Common Unix Printing System) spooler.<br><br>It acts as an intermediary, taking Ghostscript output and piping it through the underlying <b>foo2hp2600</b> filter. This filter converts the standard Ghostscript (PostScript/PDF) stream into the proprietary raster format understood by the HP 2600n. The wrapper simplifies configuration, often setting default options like resolution and handling printer-specific behaviors based on CUPS environment variables or PPD file selections. It ensures that print jobs are correctly prepared and sent to the printer, supporting features like duplexing, color/monochrome output, and various paper handling options. This command is a crucial component of the <i>foo2zjs</i> family of drivers, enabling full functionality for specific HP laser printers not natively supported by generic drivers.


title: CAVEATS
content:
The <b>foo2hp2600-wrapper</b> command requires the <b>foo2hp2600</b> filter and Ghostscript (<b>gs</b>) to be installed on the system to function correctly.<br><br>It is specifically designed for the HP Color LaserJet 2600n and compatible models, and may not work with other printer models. Proper integration with CUPS often depends on having the correct PPD (PostScript Printer Description) file installed and configured. Color calibration might be necessary for accurate color reproduction.


title: CUPS INTEGRATION
content:
This wrapper is primarily designed to be invoked by the Common Unix Printing System (CUPS). It processes print jobs queued by CUPS, leveraging the system's PPD (PostScript Printer Description) files to determine specific printer settings and job options provided by the user or defaults from the system.


title: PROPRIETARY PROTOCOL
content:
The HP Color LaserJet 2600n utilizes a proprietary raster image protocol for print data, not standard PostScript or PCL. The <b>foo2hp2600</b> filter, which this wrapper orchestrates, is crucial for converting printable data from Ghostscript into this specific, printer-understandable format.


title: HISTORY
content:
The <b>foo2hp2600</b> driver is part of the broader <i>foo2zjs</i> project, an open-source initiative led by Rick Richardson. This project emerged to address the lack of open-source drivers for various HP and other laser printers that utilized proprietary data streams, such as HP's internal protocol for the LaserJet 2600n, rather than standard PostScript or PCL.<br><br>The <b>foo2hp2600-wrapper</b> script was developed to streamline the integration of the <b>foo2hp2600</b> filter into standard Linux printing environments, particularly CUPS. It automates common setup tasks and argument passing, simplifying the user experience and ensuring seamless operation for the HP 2600n. The <i>foo2zjs</i> project, including this wrapper, has been continuously updated to maintain compatibility with new Linux kernels and Ghostscript versions, providing a long-standing solution for these printers.


title: SYNOPSIS
content:
<b>foo2lava</b> [<i>options</i>] &lt; <i>infile</i> &gt; <i>outfile</i><br><b>foo2lava</b> [<i>options</i>] <i>infile</i> [<i>&gt; outfile</i>]


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;xres&gt;x&lt;yres&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired resolution for printing in dots per inch (DPI), e.g., <b>-r</b> <i>600x600</i>.<br><br><b><b>-g</b> <i>&lt;gamma&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies gamma correction to the output. A value of 1.0 is no correction.<br><br><b><b>-d</b> <i>&lt;duplex_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls duplex (two-sided) printing. Common modes include 0=off, 1=long-edge binding, 2=short-edge binding.<br><br><b><b>-m</b> <i>&lt;media_type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the media type (e.g., plain, glossy) to adjust print characteristics.<br><br><b><b>-c</b> <i>&lt;color_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color mode: 0 for monochrome (grayscale) and 1 for color printing.<br><br><b><b>-p</b> <i>&lt;paper_size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the paper size for the output (e.g., <i>A4</i>, <i>Letter</i>, <i>Legal</i>).<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables landscape orientation for the print job.<br><br><b><b>-q</b> <i>&lt;quality&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the print quality setting. Specific values depend on the printer model.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version number of <i>foo2lava</i> and exits.<br><br>


title: DESCRIPTION
content:
<i>foo2lava</i> is a Linux command-line utility designed to convert printer-specific data streams, particularly those generated for "Lava" family Zenographics ZjStream-based printers, into a standard PostScript format. Many Lexmark, Samsung, Dell, and HP printers use the ZjStream protocol. This conversion is crucial for printing on Linux systems, as it allows the raw printer data, which is often unintelligible to standard rendering engines, to be processed by widely supported tools like <i>Ghostscript</i> (<i>gs</i>).<br><br>The typical workflow involves an application generating ZjStream data, <i>foo2lava</i> converting it to PostScript, and then <i>Ghostscript</i> rendering the PostScript into a bitmap image suitable for the printer or display. <i>foo2lava</i> works as part of the <i>foo2zjs</i> driver suite, providing open-source support for a range of otherwise proprietary printer protocols. It is commonly used within CUPS (Common Unix Printing System) as a filter.


title: CAVEATS
content:
<i>foo2lava</i> requires input in the specific raw ZjStream "Lava" printer data format; it cannot process other printer languages like PCL or XPS directly. The output is PostScript, which then requires a PostScript interpreter like <i>Ghostscript</i> for rendering to a printer's native format or a display. The effectiveness and feature support can vary depending on the specific printer model and its firmware version. It is designed for specific Zenographics-based printers and is not a universal printer driver.


title: CUPS INTEGRATION
content:
<i>foo2lava</i> is commonly used as a filter within the Common Unix Printing System (CUPS). When a print job is submitted, CUPS can be configured to use <i>foo2lava</i> to convert the printer's native data stream into PostScript, which <i>Ghostscript</i> then processes before sending the final rasterized image to the printer.


title: DEPENDENCIES
content:
The primary dependency for <i>foo2lava</i>'s output processing is <i>Ghostscript</i>. While <i>foo2lava</i> generates PostScript, <i>Ghostscript</i> is essential for rendering that PostScript into a format that the printer can understand (a bitmap) or for displaying it.


title: HISTORY
content:
<i>foo2lava</i> is a component of the larger <i>foo2zjs</i> project, initiated by Rickard E. (Rick) Faith. The project's primary goal was to provide open-source printer drivers for a range of consumer-grade laser printers from manufacturers like Lexmark, Samsung, Dell, and HP, which utilized the proprietary Zenographics ZjStream protocol and lacked official Linux support. Developed out of a need to overcome these proprietary barriers, <i>foo2lava</i> specifically targets the "Lava" subset of ZjStream printers. Its development has contributed significantly to improving Linux's interoperability with a class of printers that would otherwise be unsupported, and it has been widely adopted and integrated into various Linux distributions' printing systems, most notably CUPS.


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;resolution&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the print resolution, e.g., '600x600' or '1200x600'.<br><br><b><b>-d</b> <i>&lt;duplex_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (double-sided) printing. Common modes include 'long' (long-edge binding) or 'short' (short-edge binding).<br><br><b><b>-p</b> <i>&lt;paper_size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper size, e.g., 'letter', 'a4', 'legal', 'executive', 'env10'.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces color printing, if the printer and driver support it. Otherwise, defaults to grayscale.<br><br><b><b>-m</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints multiple pages per sheet (N-up printing), where <i>N</i> is the number of pages (e.g., 2, 4, 6, 9, 16).<br><br><b><b>-s</b> <i>&lt;source_tray&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source tray, e.g., 'auto', 'manual', 'tray1', 'tray2'.<br><br><b><b>-t</b> <i>&lt;toner_save&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables toner save mode. Usually '1' for enabled, '0' for disabled.<br><br><b><b>-T</b> <i>&lt;text_quality&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts text print quality. Specific values depend on the driver version.<br><br><b><b>-C</b> <i>&lt;graphics_quality&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts graphics print quality. Specific values depend on the driver version.<br><br><b><b>-O</b> <i>&lt;output_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output mode, such as 'draft', 'normal', 'best'.<br><br><b><b>-L</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the PostScript language level to emulate (e.g., '2', '3').<br><br><b><b>-i</b> <i>&lt;input_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the input PostScript/PDF file. If omitted, input is read from standard input (stdin).<br><br><b><b>-o</b> <i>&lt;output_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the output LavaFlow file. If omitted, output is written to standard output (stdout).<br><br><b><b>--foo2lava-options</b> <i>"&lt;options&gt;"</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes raw, unparsed options directly to the underlying <i>foo2lava</i> binary.<br><br><b><b>--gs-options</b> <i>"&lt;options&gt;"</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes raw, unparsed options directly to the <i>Ghostscript</i> (gs) command.<br><br>


title: DESCRIPTION
content:
The <b>foo2lava-wrapper</b> is a shell script that acts as a convenient front-end for the <i>foo2lava</i> Ghostscript driver. It simplifies the process of converting PostScript (PS) or Portable Document Format (PDF) files into the proprietary LavaFlow printer language, primarily used by certain Samsung and other compatible laser printers.<br><br>This wrapper script automatically handles the invocation of <i>Ghostscript</i> (gs) and passes standard print options, such as resolution, paper size, and duplex settings, directly to the <i>foo2lava</i> driver. It's commonly used in Linux printing environments, particularly as a filter in the Common Unix Printing System (CUPS), to enable compatibility with printers that do not natively support standard languages like PostScript or PCL.<br><br>By abstracting the complexities of <i>Ghostscript</i> command-line arguments and <i>foo2lava</i>-specific options, <b>foo2lava-wrapper</b> provides a user-friendly interface for configuring print jobs, making it easier for users and system administrators to manage print output for supported LavaFlow-based printers.


title: CAVEATS
content:
The <b>foo2lava-wrapper</b> depends on the <i>foo2lava</i> binary and <i>Ghostscript</i> (gs) being installed and accessible in the system's PATH. It is designed for printers that use the proprietary LavaFlow language. Not all options may be supported by every specific printer model or every version of the <i>foo2lava</i> driver. Ensure you have the correct PPD file configured when using this wrapper as a CUPS filter.


title: USAGE WITH CUPS
content:
In a CUPS environment, <b>foo2lava-wrapper</b> is typically configured as a backend filter. The PPD (PostScript Printer Description) file associated with the printer will define how CUPS passes job options to this wrapper. When a print job is sent, CUPS converts it to PostScript (if necessary) and then pipes it to <b>foo2lava-wrapper</b>, which in turn processes it for the target LavaFlow printer.


title: DEPENDENCIES
content:
This wrapper script relies on several external components:<br><i>Ghostscript</i> (gs): The core PostScript/PDF interpreter and rasterizer.<br><i>foo2lava</i> binary: The actual driver that converts Ghostscript output into the LavaFlow language.<br>Standard Linux utilities (e.g., sed, grep, basename) for script execution.<br>Ensure these are correctly installed and configured for <b>foo2lava-wrapper</b> to function properly.


title: HISTORY
content:
<b>foo2lava-wrapper</b> is part of the larger <i>foo2zjs</i> project, which was initiated by Rick Richardson. The project aims to provide open-source drivers for printers that use proprietary page description languages, particularly those based on ZjStream. <i>foo2lava</i> specifically targets printers that use the LavaFlow language, often found in older Samsung laser printers. The wrapper script was developed to simplify the command-line usage of the <i>foo2lava</i> Ghostscript driver, abstracting complex <i>Ghostscript</i> arguments and providing a more intuitive interface for common printing tasks.


title: SYNOPSIS
content:
<b>foo2oak</b> [<i>options</i>] &lt; <i>input.ps</i> &gt; <i>output.oak</i><br>or<br><i>command</i> | <b>foo2oak</b> [<i>options</i>] &gt; <i>output.oak</i>


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;resolution&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printer resolution in DPI (dots per inch). Common values include <i>600</i> or <i>1200</i>.<br><br><b><b>-g</b> <i>&lt;width&gt;x&lt;height&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the media size in pixels. For example, <i>2480x3508</i> for A4 at 300 DPI. Overrides <b>-p</b>.<br><br><b><b>-p</b> <i>&lt;paper_size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper size. Examples: <i>A4</i>, <i>Letter</i>, <i>Legal</i>, <i>Executive</i>. Refer to <i>papersize.h</i> for supported types.<br><br><b><b>-L</b> <i>&lt;level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level. A higher number provides more verbose output for troubleshooting.<br><br><b><b>-n</b> <i>&lt;copies&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the specified number of copies of the document.<br><br><b><b>-d</b> <i>&lt;duplex&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing. <i>1</i> for short-edge binding, <i>2</i> for long-edge binding.<br><br><b><b>-s</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the paper input source tray (e.g., <i>1</i> for auto, <i>2</i> for manual feeder).<br><br><b><b>-c</b> <i>&lt;colorspace&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the color space. <i>1</i> for monochrome (black and white), <i>3</i> for color.<br><br><b><b>-t</b> <i>&lt;tumble&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the duplex tumble option. <i>1</i> for tumble, <i>0</i> for no tumble.<br><br><b><b>-O</b> <i>&lt;offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets an output offset value for page positioning.<br><br><b><b>-u</b> <i>&lt;x_offset&gt;,&lt;y_offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Offsets the image on the page by the specified X and Y coordinates in pixels.<br><br><b><b>-Z</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables toner save mode, reducing toner consumption at the cost of print quality.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables auto-rotation of pages to best fit the selected paper size.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Inserts a form feed character at the end of the print job.<br><br><b><b>-k</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps intermediate temporary files generated during processing for debugging purposes.<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables raw debug output, showing the unprocessed printer commands.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Swaps the X and Y dimensions (width and height).<br><br><b><b>-Y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Swaps the Y and X dimensions (height and width). Similar to -X, but can have different behavior depending on context.<br><br>


title: DESCRIPTION
content:
<i>foo2oak</i> is a printer driver for the <i>foo2zjs</i> project. It converts <i>Ghostscript</i> output, typically PostScript, into a raw raster format compatible with laser printers using the "Oak" rendering engine. These printers often include specific models from Samsung, Xerox, and Dell. <br><br>The command acts as an integral part of the Linux printing system, usually invoked by <i>foomatic-rip</i> or directly by a print spooler like CUPS. It takes PostScript data from standard input, processes it, and outputs the proprietary Oak printer data to standard output, which is then sent to the printer. Its primary purpose is to enable Linux users to print to printers that do not have native Linux drivers, by translating standard print job formats into the specific language understood by the printer hardware.


title: CAVEATS
content:
<i>foo2oak</i> relies on the Ghostscript engine to render PostScript into a bitmap image, which is then converted to the Oak format. Therefore, issues with Ghostscript (e.g., version compatibility, font rendering) can affect <i>foo2oak</i>'s output. <br><br>The quality and feature support can vary significantly between different Oak-based printer models due to variations in their firmware and specific command sets. Some advanced printer features might not be fully accessible or properly emulated.


title: SUPPORTED PRINTERS
content:
<i>foo2oak</i> specifically targets printers that use the "Oak" raster language. This includes various Samsung, Xerox, and Dell laser printers. Users should verify their printer model is supported by consulting the <i>foo2zjs</i> project website or documentation, as support is not universal for all models from these brands.


title: USAGE WITH CUPS
content:
In a typical Linux printing setup, <i>foo2oak</i> is not invoked directly by the user. Instead, it is configured as the backend filter for a printer queue in CUPS (Common Unix Printing System). When a print job is sent to such a queue, CUPS uses <i>foomatic-rip</i> to pipe the PostScript data through <i>foo2oak</i>, which then sends the processed data to the printer device (e.g., via USB or network).


title: HISTORY
content:
<i>foo2oak</i> is part of the larger <i>foo2zjs</i> project, an open-source printer driver suite initiated by Rick Richardson. The project aims to provide Linux/UNIX drivers for many inexpensive laser printers that use proprietary raster languages instead of standard PostScript or PCL. The "Oak" engine specific support was developed to extend compatibility to printers utilizing this particular command set, filling a critical gap for users of such hardware.


title: SYNOPSIS
content:
<b>foo2oak-wrapper</b> [<i>options</i>] &lt;<i>input_file(s)</i>&gt;<br><b>foo2oak-wrapper</b> [<i>options</i>] &lt;<i>input_file</i>&gt; &gt; &lt;<i>output_file</i>&gt;<br>cat &lt;<i>input_file</i>&gt; | <b>foo2oak-wrapper</b> [<i>options</i>] &gt; &lt;<i>output_file</i>&gt;


title: PARAMETERS
content:
<b>-r <<i>resolution</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the print resolution, e.g., <b>600</b> or <b>1200</b> dpi.<br><br><b>-m <<i>media_size</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the media size, such as <b>Letter</b>, <b>A4</b>, <b>Legal</b>, etc.<br><br><b>-d <<i>duplex_mode</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Configures duplex printing. Common modes include <b>longedge</b>, <b>shortedge</b>, or <b>none</b>.<br><br><b>-p <<i>paper_type</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper type, e.g., <b>plain</b>, <b>glossy</b>, <b>transparency</b>.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables color printing, if supported by the printer and driver.<br><br><b>-o <<i>output_file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Redirects the processed printer data to the specified file instead of standard output.<br><br><b>-X <<i>offset_x</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the X-axis offset for the printed image.<br><br><b>-Y <<i>offset_y</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the Y-axis offset for the printed image.<br><br><b>-Z</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces landscape orientation for printing.<br><br><b>-C <<i>copies</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of copies to print.<br><br><b>-l <<i>level</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the debug level for the wrapper or underlying <b>foo2oak</b> driver.<br><br><b>-L <<i>level</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Ghostscript language level to use.<br><br>


title: DESCRIPTION
content:
The <b>foo2oak-wrapper</b> is a utility designed to simplify the use of the <b>foo2oak</b> Ghostscript printer driver. <b>foo2oak</b> is a driver developed for printers that utilize the 'Oak Technology' page description language or chipset, similar to how <b>foo2zjs</b> handles ZjStream printers.<br><br>This wrapper script acts as an intermediary, taking common printing options and input files, then intelligently invoking the underlying <b>foo2oak</b> driver along with Ghostscript (<b>gs</b>) to convert various input formats (like PostScript or PDF) into a format suitable for an Oak-based printer.<br><br>Its primary purpose is to abstract away the complexities of directly calling Ghostscript with the correct <b>foo2oak</b> device and parameters. Users can specify resolutions, paper sizes, duplex modes, and other print job attributes using straightforward command-line options. The wrapper handles the proper syntax and argument passing to <b>gs</b> and <b>foo2oak</b>, streamlining the process of printing to compatible devices, often as part of a CUPS (Common Unix Printing System) setup or for direct file conversion.


title: CAVEATS
content:
The <b>foo2oak-wrapper</b> command is not a standard part of most Linux distributions. It typically needs to be installed as part of the <b>foo2zjs.org</b> driver suite or compiled from source.<br><br>It requires a functional Ghostscript (<b>gs</b>) installation and the <b>foo2oak</b> binary (which is usually generated when compiling the <b>foo2zjs.org</b> drivers).<br><br>This driver is specific to printers utilizing the 'Oak Technology' page description language or chipset, and will not work with printers using other languages (e.g., PCL, PostScript, ZjStream, QPDL).


title: DEPENDENCIES AND INSTALLATION
content:
To use <b>foo2oak-wrapper</b>, ensure you have Ghostscript installed. The <b>foo2oak</b> driver and its wrapper typically need to be compiled and installed from the <b>foo2zjs.org</b> source code package. This often involves downloading the source, running <i>make</i>, and <i>sudo make install</i> to place the binaries and support files in the correct system paths. It's crucial that the <b>foo2oak</b> binary itself is accessible in the system's PATH or within the wrapper's expected location.


title: HISTORY
content:
The <b>foo2oak-wrapper</b> is part of the <b>foo2zjs.org</b> project, an open-source initiative that provides Linux printer drivers for devices using various proprietary page description languages. The project began with the reverse-engineering of the ZjStream language for HP printers, leading to the <b>foo2zjs</b> driver. Over time, it expanded to support other proprietary languages like QPDL (<b>foo2qpdl</b>), and presumably, Oak Technology's language (<b>foo2oak</b>). These drivers aim to enable Linux users to utilize printers that would otherwise lack native support due to vendor-specific, closed-source protocols.


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;res&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the print resolution in dots per inch (DPI), e.g., 600 for 600x600 DPI.<br><br><b><b>-d</b> <i>&lt;duplex&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing. <b>1</b> for long-edge binding, <b>2</b> for short-edge binding. Requires printer support.<br><br><b><b>-p</b> <i>&lt;paper&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies paper size. Common values include <b>0</b>=Letter, <b>1</b>=Legal, <b>2</b>=A4, <b>3</b>=Executive, <b>4</b>=B5(JIS), <b>5</b>=A5, <b>6</b>=C5_Env, <b>7</b>=DL_Env, <b>8</b>=B5_Env, <b>9</b>=Monarch_Env, <b>10</b>=Comm_Env.<br><br><b><b>-m</b> <i>&lt;media&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets media type. Common values include <b>0</b>=Plain, <b>1</b>=Glossy, <b>2</b>=Transparency, <b>3</b>=Bond, <b>4</b>=Labels, <b>5</b>=Envelope, <b>6</b>=CardStock, <b>7</b>=Preprinted, <b>8</b>=Colored, <b>9</b>=Light, <b>10</b>=Heavy.<br><br><b><b>-s</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects paper source/tray. <b>0</b>=Auto, <b>1</b>=Tray1 (main tray), <b>2</b>=Manual Feed, <b>3</b>=Tray2 (optional tray).<br><br><b><b>-t</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets output type. <b>0</b> for grayscale, <b>1</b> for color (if printer supports color QPDL).<br><br><b><b>-c</b> <i>&lt;copies&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the specified number of copies.<br><br><b><b>-u</b> <i>&lt;x_offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the image X-offset in dots.<br><br><b><b>-l</b> <i>&lt;y_offset&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the image Y-offset in dots.<br><br><b><b>-C</b> <i>&lt;gamma&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printer gamma correction value (0-100). Higher values lighten the image.<br><br><b><b>-G</b> <i>&lt;gamma&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Alternative gamma correction setting (0-100).<br><br><b><b>-b</b> <i>&lt;bits&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the bits per pixel for output (e.g., 1 for monochrome, 8 for grayscale).<br><br><b><b>-D</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output to stderr, useful for troubleshooting.<br><br><b><b>-L</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces landscape orientation.<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces portrait orientation.<br><br><b><b>-W</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces wide format, adjusting output for wider paper sizes.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables automatic paper selection.<br><br><b><b>-K</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Keeps temporary files generated during processing for inspection.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays version information for <i>foo2qpdl</i>.<br><br>


title: DESCRIPTION
content:
<i>foo2qpdl</i> is a GPL Ghostscript filter that converts PostScript into a printer-specific raster format for printers that use the Quick Printer Description Language (QPDL). These are typically 'host-based' or 'Windows-only' HP LaserJet printers, such as the HP LaserJet P1005, P1006, P1007, P1008, P1505, and P1505n, among others. These printers do not understand standard printer languages like PCL or PostScript directly; instead, they rely on the host computer to render the print job into a proprietary raster format. <br><br><i>foo2qpdl</i> fills this gap for Linux and Unix-like operating systems, allowing users to print to these devices. It acts as a crucial component in the CUPS (Common Unix Printing System) printing pipeline, typically receiving PostScript output from applications or Ghostscript itself, processing it, and sending the QPDL-formatted data to the printer.


title: CAVEATS
content:
<i>foo2qpdl</i> is specifically designed for printers using the QPDL protocol, primarily certain HP LaserJet models. It will not work with printers that use standard printer languages like PCL, PostScript, or other proprietary formats (e.g., ZJS, PCLm). Due to the host-based nature of these printers, some advanced printer features might not be fully supported by the driver, and performance may vary depending on the host system's processing power.


title: INTEGRATION WITH CUPS
content:
In a typical Linux printing setup, <i>foo2qpdl</i> is configured as a filter within CUPS. When a print job is sent, CUPS passes the PostScript data through Ghostscript (<i>gs</i>), which then pipes its output to <i>foo2qpdl</i>. <i>foo2qpdl</i> processes this data, converts it to the QPDL raster format, and sends the resulting binary stream directly to the printer device, usually via USB.


title: INPUT AND OUTPUT
content:
The expected input for <i>foo2qpdl</i> is PostScript data, typically generated by Ghostscript or applications. Its output is a raw binary stream in the proprietary QPDL format, which is then sent directly to the printer hardware.


title: HISTORY
content:
<i>foo2qpdl</i> is part of the larger <i>foo2zjs</i> project, an open-source suite of GPL Ghostscript drivers for printers that use ZjStream (ZJS) and other proprietary languages. The project was initiated by Rick S. P. Holt, who reverse-engineered the protocols to enable Linux support for these otherwise unsupported 'host-based' or 'Windows-only' printers. <i>foo2qpdl</i> specifically addresses the QPDL protocol used by certain HP LaserJet P1000/P1500 series printers, filling a critical void in open-source printer driver availability for these devices.


title: SYNOPSIS
content:
<b>foo2qpdl-wrapper</b> [<i>OPTIONS</i>] [<i><input_file</i>] [<i>>output_file</i>]<br><i>(Typically invoked by CUPS, reading from stdin and writing to stdout)</i>


title: PARAMETERS
content:
<b>-r <i>&lt;resolution&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the output resolution in DPI, e.g., 600, 1200.<br><br><b>-d <i>&lt;duplex_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify duplex printing mode: 0 (simplex), 1 (long edge), 2 (short edge).<br><br><b>-p <i>&lt;paper_size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Define the paper size, e.g., letter, legal, a4, a5.<br><br><b>-c <i>&lt;color_mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Select color mode: 0 (grayscale), 1 (color).<br><br><b>-m <i>&lt;media_type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the media type, e.g., plain, glossy, transparency.<br><br><b>-s <i>&lt;source_tray&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the paper source tray, e.g., upper, lower, manual.<br><br><b>-n <i>&lt;N-up&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print multiple pages per sheet (N-up), e.g., 2, 4, 6.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable toner save mode.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for debugging.<br><br>


title: DESCRIPTION
content:
The <b>foo2qpdl-wrapper</b> command is a utility that acts as a front-end for the <b>foo2qpdl</b> driver, which in turn converts PostScript data into the Quick Printer Description Language (QPDL) format. QPDL is a proprietary page description language used by certain Hewlett-Packard, Canon, Lexmark, and Samsung laser printers.<br><br>This wrapper is typically used within the Common Unix Printing System (CUPS) as a filter. When a print job is submitted to a CUPS queue configured for a QPDL printer, CUPS passes the PostScript data to <b>foo2qpdl-wrapper</b>. The wrapper then parses command-line options (often derived from CUPS job options) and environment variables, translating them into the appropriate arguments for the underlying <b>foo2qpdl</b> executable. It then executes <b>foo2qpdl</b>, passing the PostScript input and writing the resulting QPDL output to standard output, which is then sent to the printer.<br><br>The <b>foo2qpdl</b> project aims to provide an open-source driver for various printers that use proprietary page description languages like QPDL, ZjStream, and PCLm, enabling their use with Linux and other Unix-like operating systems.


title: CAVEATS
content:
Printer support depends on the underlying <b>foo2qpdl</b> driver and its firmware/ICM file availability. Some advanced printer features might not be fully supported. Performance can vary depending on document complexity and printer resolution settings. Debugging often requires examining the output of <b>foo2qpdl</b> itself or the CUPS error logs.


title: CUPS INTEGRATION
content:
When used with CUPS, <b>foo2qpdl-wrapper</b> typically receives printer options via CUPS environment variables (like <i>PPD_OPTIONS</i>) or as command-line arguments passed by the CUPS backend. It then translates these into the appropriate <b>foo2qpdl</b> options. Configuration is usually handled automatically when adding a printer via CUPS, especially if a PPD file generated by the <i>foo2zjs</i> tools is used.


title: HISTORY
content:
The <b>foo2qpdl-wrapper</b> is part of the larger <i>foo2zjs</i> project, which began in 2004 to provide open-source drivers for various ZjStream, QPDL, and PCLm based laser printers, primarily from HP, Canon, Lexmark, and Samsung, that lacked native Linux support. The project was initiated to reverse-engineer these proprietary protocols, allowing users to leverage their hardware without relying on vendor-provided binary blobs or Windows drivers. Over time, it has evolved to support a wide range of devices, becoming a crucial component for many Linux users with such printers.


title: SYNOPSIS
content:
<i>foo2slx</i> <i>[options]</i> < <i><input.ps></i> > <i><output.slx></i><br><br>Commonly used in a pipeline with <b>Ghostscript</b>:<br><code>gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOutputFile=- &lt;input.pdf&gt; | foo2slx [options] &gt; &lt;output.slx&gt;</code>


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;xres&gt;x&lt;yres&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired <i>printer resolution</i> in dots per inch (DPI), e.g., 600x600.<br><br><b><b>-g</b> <i>&lt;gamma&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the <i>gamma correction</i> for print output, typically a floating-point value.<br><br><b><b>-t</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables <i>toner save mode</i>, which reduces the amount of toner used, often resulting in lighter prints.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the output to be in <i>color mode</i>, even if the input is grayscale or the printer default is mono.<br><br><b><b>-m</b> <i>&lt;N&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies <i>N-up printing</i>, arranging N pages onto a single sheet of paper.<br><br><b><b>-P</b> <i>&lt;pagesize&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>paper size</i>, e.g., letter, a4, legal.<br><br><b><b>-s</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the <i>paper source tray</i>, e.g., tray1, manual.<br><br><b><b>-d</b> <i>&lt;density&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the <i>print density</i>, typically a value from 0 to 100.<br><br><b><b>-q</b> <i>&lt;quality&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>print quality level</i>, often influencing speed and detail.<br><br>


title: DESCRIPTION
content:
<i>foo2slx</i> is a <i>free software driver</i> for printers that utilize the <i>Samsung SLX raster format</i>. It acts as a crucial intermediary, taking <i>PostScript output</i> (typically generated by <b>Ghostscript</b>) and transforming it into the specific proprietary SLX raster format that these printers understand.<br><br>This enables <b>Linux</b> and <b>Unix-like</b> operating system users to effectively print to certain <b>Samsung color laser printers</b>, such as those in the <i>SL-C4x00 series</i>. The command is an integral component of the broader <i>foo2zjs project</i>, which provides drivers for various ZjStream-based printers. Its primary function is to manage <i>color correction</i>, <i>resolution scaling</i>, and <i>page formatting</i> to ensure accurate and high-quality prints.


title: CAVEATS
content:
<ul><li>Requires <b>Ghostscript</b> to convert source documents (like PDF) into PostScript format, which <i>foo2slx</i> then processes.</li><li>Designed specifically for <i>Samsung SLX raster printers</i>; not compatible with other printer languages or manufacturers.</li><li>Advanced printer features like specific finishing options might not be directly supported by command-line options and may require CUPS configuration.</li></ul>


title: INTEGRATION WITH CUPS
content:
<i>foo2slx</i> is commonly used within the <b>CUPS (Common Unix Printing System)</b> framework. When a compatible printer is configured in CUPS, a <i>PPD (PostScript Printer Description)</i> file for the printer often instructs CUPS to use <i>foo2slx</i> as a filter in the printing pipeline. This allows users to print from any application via CUPS without directly invoking <i>foo2slx</i> themselves.


title: INPUT/OUTPUT
content:
The command typically reads <i>PostScript data</i> from <i>standard input</i> and writes the converted <i>SLX raster data</i> to <i>standard output</i>, making it highly suitable for piping operations in shell scripts or printer spooling systems.


title: HISTORY
content:
The <i>foo2slx</i> command is part of the broader <i>foo2zjs project</i>, initiated and primarily developed by <b>Rick van Rein</b>. The project began as an effort to provide open-source <b>Linux</b> drivers for printers that utilize proprietary <i>ZjStream</i> data formats, which were prevalent in many <b>Samsung</b>, <b>Xerox</b>, and <b>Dell</b> printers. <i>foo2slx</i> specifically targets newer <b>Samsung</b> printers using the <i>SLX raster format</i>, extending the <i>foo2zjs</i> suite's compatibility to these devices. Its development has been driven by the need for robust and functional drivers in environments where manufacturer-provided <b>Linux</b> drivers are absent or inadequate.


title: SYNOPSIS
content:
<b>foo2slx-wrapper</b> [<I>-r &lt;resolution&gt;</I>] [<I>-c</I>] [<I>-p</I>] [<I>-L &lt;level&gt;</I>] [<I>-m &lt;model&gt;</I>] [>] <I>output.ppd</I>


title: PARAMETERS
content:
<b>-r <resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the desired print resolution in dots per inch (dpi) for the generated PPD file. Common values include <I>600</I> or <I>1200</I>.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables color printing capabilities within the generated PPD file, indicating the printer supports color output (for color-capable SLX printers).<br><br><b>-p</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables duplex (two-sided) printing capabilities in the generated PPD, allowing for automatic double-sided printing if the printer hardware supports it.<br><br><b>-L <level></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the PostScript language level (e.g., <I>2</I> or <I>3</I>) to be declared in the PPD file. This influences how applications send print data.<br><br><b>-m <model></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular printer model or variant. This can be used to fine-tune the PPD settings for specific printer configurations or quirks.<br><br>


title: DESCRIPTION
content:
The <b>foo2slx-wrapper</b> is a utility script associated with the <I>foo2slx</I> printer driver, which is part of the larger <I>foo2zjs</I> open-source project. <I>foo2slx</I> provides driver support for specific Samsung and Xerox laser printers that utilize the SLX page description language.<br><br>The primary function of <b>foo2slx-wrapper</b> is to generate a PostScript Printer Description (PPD) file. This PPD file is crucial for integrating the <I>foo2slx</I> driver with the Common Unix Printing System (CUPS). It allows system administrators to define and configure printer capabilities such as resolution, color support, and duplex printing directly into a standardized format that CUPS can interpret.<br><br>Typically, the output of this wrapper script is redirected to a <I>.ppd</I> file, which is then used by the <I>lpadmin</I> command to register the printer and its capabilities with CUPS, making the printer available for use across the Linux system.


title: CAVEATS
content:
The <b>foo2slx-wrapper</b> only generates a PPD file; it does not directly install or configure the printer in CUPS. Subsequent steps involving commands like <b>lpadmin</b> are required to integrate the printer. The effectiveness of the generated PPD and the driver depends heavily on the specific printer model's support within the <I>foo2slx</I> project. It assumes the underlying <I>foo2slx</I> driver binaries are correctly installed and compiled.


title: PPD FILE GENERATION
content:
The primary purpose of <b>foo2slx-wrapper</b> is to generate a PostScript Printer Description (PPD) file. This PPD file contains all the necessary information about the printer's capabilities (such as resolution, paper sizes, color support, and duplexing) that CUPS needs to correctly manage print jobs. The output of the wrapper script is typically redirected to a <I>.ppd</I> file (e.g., <I>foo2slx-wrapper > foo2slx.ppd</I>), which is then used by the <b>lpadmin</b> command to add the printer to CUPS.


title: INTEGRATION WITH CUPS
content:
After generating the PPD file, the next step in printer setup usually involves using the <I>lpadmin</I> command. For example, to add a USB printer named 'MySLXPrinter':<br><br><I>sudo lpadmin -p MySLXPrinter -m foo2slx.ppd -v usb:/dev/usb/lp0 -E</I><br><br>This command registers 'MySLXPrinter' with CUPS, links it to the generated PPD, specifies the printer's device URI, and enables the printer.


title: HISTORY
content:
The <I>foo2slx</I> driver, along with its wrapper scripts like <b>foo2slx-wrapper</b>, is a component of the broader <I>foo2zjs</I> open-source project. This project was initiated by Rick Richardson with the goal of providing free software drivers for various laser printers that use proprietary page description languages (like ZjStream, QPDL, SLX, etc.) instead of standard PostScript. The wrapper scripts were developed to simplify the process of generating CUPS-compatible PPD files, thereby facilitating the integration of these specialized drivers into Linux and other Unix-like printing environments, making otherwise unsupported printers usable.


title: SYNOPSIS
content:
<i><b>foo2xqx</b> [options] [<input.ps>]</i><br><i>(Often used with <I>Ghostscript</I> as: <I>gs ... | <b>foo2xqx</b> [options] | lpr</I>)


title: PARAMETERS
content:
<b><b>-r</b> <i>&lt;res&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the printer resolution in dots per inch (dpi), e.g., -r 600.</i><br><br><b><b>-g</b> <i>&lt;gamma&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Apply gamma correction to the output image, typically between 0.0 and 4.0.</i><br><br><b><b>-m</b> <i>&lt;model&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the printer model number if auto-detection fails.</i><br><br><b><b>-t</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Set the media type for printing (e.g., plain, glossy).</i><br><br><b><b>-c</b> <i>&lt;color&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Force color (1) or grayscale (0) output.</i><br><br><b><b>-d</b> <i>&lt;duplex&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable duplex printing: 0 (off), 1 (long-edge), 2 (short-edge).</i><br><br><b><b>-p</b> <i>&lt;paper&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Specify the paper size (e.g., Letter, A4, Legal).</i><br><br><b><b>-n</b> <i>&lt;N-up&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Print multiple pages per sheet (N-up printing).</i><br><br><b><b>-S</b> <i>&lt;source&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Select the paper source tray (e.g., 0 for auto, 1 for tray1).</i><br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Enable verbose output for debugging purposes.</i><br><br>


title: DESCRIPTION
content:
<i>The <b>foo2xqx</b> command is a free software printer driver that converts PostScript into the native XQX printer language. It is specifically designed to support various laser printers that use the XQX protocol, including certain models from Konica Minolta. As a crucial component of the <I>foo2zjs</I> project, <b>foo2xqx</b> enables these host-based printers, which often lack onboard PostScript interpreters, to function correctly on Linux and other Unix-like operating systems.</i><br><br><i>Typically, <b>foo2xqx</b> is used in conjunction with <I>Ghostscript</I> (<I>gs</I>). <I>Ghostscript</I> renders PostScript or PDF documents into a raw image format, which is then piped as input to <b>foo2xqx</b>. <b>foo2xqx</b> takes this rendered data and converts it into the proprietary XQX data stream, which can then be sent directly to the printer via a USB, network, or parallel port. This process effectively bridges the gap between standard document formats and the specific requirements of XQX-based printers, allowing users to print documents that would otherwise be unsupported.</i>


title: CAVEATS
content:
<i><b>foo2xqx</b> requires <I>Ghostscript</I> (<I>gs</I>) to convert PostScript or PDF documents into a suitable raster format before processing. It is specifically designed for XQX-based printers and will not work with printers using other languages (e.g., PCL, PostScript, ZjStream). Some printer models may require proprietary firmware uploads to the printer, which are often provided separately by the <I>foo2zjs</I> project. Full printer functionality, such as advanced finishing options, might not be completely supported for all models.</i>


title: INPUT AND OUTPUT
content:
<i><b>foo2xqx</b> typically accepts PostScript data (usually from <I>Ghostscript</I>) on standard input and outputs raw XQX printer data to standard output, which is then usually piped directly to the printer device.</i>


title: DEPENDENCIES
content:
<i>The primary external dependency for <b>foo2xqx</b> to function correctly is <I>Ghostscript</I> (<I>gs</I>), which handles the initial rendering of documents.</i>


title: HISTORY
content:
<i>The <b>foo2xqx</b> driver is an integral part of the <I>foo2zjs</I> project, initiated and primarily developed by Rick Richardson. This project emerged from the need to provide open-source drivers for various "host-based" printers that relied on proprietary communication protocols rather than standard printer languages like PCL or PostScript. <b>foo2xqx</b> specifically targets printers using the XQX protocol, which was reverse-engineered to allow Linux users to utilize these devices. Its development, alongside other <I>foo2*</I> drivers, has significantly contributed to extending printer compatibility within the open-source ecosystem, providing a vital bridge for hardware that would otherwise be unsupported.</i>


title: PARAMETERS
content:
<b>-r <I>resolution</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output resolution in dots per inch (DPI), e.g., <I>600</I> or <I>1200</I>. This option significantly influences the clarity and detail of the printed output.<br><br><b>-d <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the duplex printing mode. Common modes include <I>sim</I> (simplex/one-sided), <I>duplex</I> (long-edge duplex), or <I>duplexshort</I> (short-edge duplex), if supported by the printer.<br><br><b>-m <I>media_size</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output media size, such as <I>letter</I>, <I>a4</I>, or <I>legal</I>. This ensures the print job is correctly scaled and positioned for the loaded paper dimensions.<br><br><b>-p <I>paper_source</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper source or tray from which paper should be fed, e.g., <I>tray1</I>, <I>manual</I>, or <I>auto</I>.<br><br><b>-c <I>mode</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls the color printing mode. Typically <I>0</I> for monochrome (black and white) or <I>1</I> for color output, assuming the printer has color capabilities.<br><br><b><I>file</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The input PostScript file to be processed. If not specified, <b>foo2xqx-wrapper</b> reads PostScript data from standard input (stdin), which is the default behavior when invoked by CUPS.<br><br>


title: DESCRIPTION
content:
The <b>foo2xqx-wrapper</b> command is a crucial component of the <I>foo2zjs</I> family of open-source printer drivers, specifically designed to support printers that utilize the Xerox Query Language (XQX) protocol. It acts as a wrapper script that orchestrates the printing process, primarily by converting standard PostScript data into the proprietary raster format understood by XQX-based printers, such as certain Xerox, Dell, and Phaser models.<br><br>Typically, <b>foo2xqx-wrapper</b> is invoked by the Common Unix Printing System (CUPS) as a filter. When a print job is submitted to a CUPS queue configured for an XQX printer, CUPS pipes the PostScript data through this wrapper. The wrapper then processes the data, often utilizing Ghostscript internally to render the PostScript pages into bitmaps, and finally encodes these bitmaps into the specific XQX printer language. This output is then sent directly to the printer. Its primary role is to bridge the gap between standard PostScript input and the unique requirements of XQX hardware, enabling these printers to be used on Linux and Unix-like systems.


title: CAVEATS
content:
The <b>foo2xqx-wrapper</b> command relies heavily on the underlying <I>foo2xqx</I> filter and Ghostscript for its core functionality. It is specifically designed for certain Xerox, Dell, and Phaser printers that use the XQX protocol, which are typically older models. Compatibility can vary depending on the printer's specific XQX implementation and the accuracy of its corresponding PPD (PostScript Printer Description) file. This driver suite may not be relevant for newer printers that utilize different standard protocols (e.g., PCL, PostScript native, PDF direct) or come with modern vendor-supplied drivers.


title: ROLE IN CUPS
content:
In a CUPS (Common Unix Printing System) environment, <b>foo2xqx-wrapper</b> typically serves as a backend filter within the printing pipeline. CUPS uses PPD files to determine the necessary processing steps and filters for a given printer. When an XQX-compatible PPD file is configured for a printer queue, CUPS automatically pipes the incoming PostScript print job data through <b>foo2xqx-wrapper</b>. This wrapper then translates the PostScript into the printer-specific XQX data stream, which CUPS subsequently sends to the physical printer. This seamless integration allows applications to print to supported XQX printers without needing to understand the printer's native language.


title: HISTORY
content:
<b>foo2xqx-wrapper</b> is an integral part of the <I>foo2zjs</I> open-source printer driver project, primarily developed by Rick Richardson. The project originated to provide robust Linux and Unix support for a range of GDI (Graphics Device Interface) and host-based printers that lacked native PostScript interpreters and relied on proprietary protocols like XQX. It emerged as a vital solution for users facing challenges with vendor-supplied drivers or the absence of drivers for their operating systems, enabling wider hardware compatibility.


title: PARAMETERS
content:
<b>-d <i>bits</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Converts ICC profile data to the specified number of bits per channel. The default value is 8 bits.<br><br><b>-g <i>gamma</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a gamma correction to the generated Postscript color rendering dictionary. The default value is 1.0 (no correction).<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with command usage and available options.<br><br><b>-i <i>intent</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the rendering intent for the ICC profile conversion:<br><i>0 = Perceptual</i><br><i>1 = Relative Colorimetric</i><br><i>2 = Saturation</i><br><i>3 = Absolute Colorimetric</i><br>The default intent is Perceptual (0).<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints tag information found within the ICC profile.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <b>icc2ps</b> utility.<br><br>


title: DESCRIPTION
content:
<i>icc2ps</i> is a utility within the <b>foo2zjs</b> printer driver suite. Its primary function is to read an <I>ICC (International Color Consortium)</I> color profile, typically from standard input, and convert it into a <I>Postscript Color Rendering Dictionary (CRD)</I>. This generated dictionary is then written to standard output. The resulting Postscript CRD is crucial for color management, particularly when used by other <b>foo2zjs</b> utilities like <i>foo2zjs-pstops</i>. It enables the conversion of Postscript color information into the specific color space and characteristics understood by the printer, ensuring accurate color reproduction based on the provided ICC profile. This tool is vital for users who require precise color matching and calibration with their ZjStream-based printers, integrating color management into the Linux printing workflow.


title: CAVEATS
content:
Requires a valid ICC profile as input via standard input. The output Postscript CRD is specifically designed for integration with <i>foo2zjs-pstops</i> and may not be universally compatible with all Postscript interpreters or workflows. Accurate color reproduction depends on the quality of the input ICC profile and proper calibration of the printer.


title: INPUT AND OUTPUT
content:
The command typically expects an ICC profile to be supplied via standard input (e.g., using a pipe or input redirection like <<i>profile.icc</i>). It writes the resulting Postscript Color Rendering Dictionary to standard output (e.g., using output redirection like ><i>profile.ps</i>). This design allows for flexible pipelining with other commands in a script or command-line environment.


title: ROLE IN COLOR MANAGEMENT
content:
This utility is a key piece in the color management pipeline for <b>foo2zjs</b> printers. It bridges the gap between device-independent color spaces defined by ICC profiles and the device-dependent color output required by the printer through Postscript, allowing for consistent and accurate color reproduction across different devices and applications within the <b>foo2zjs</b> printing ecosystem.


title: HISTORY
content:
The <b>foo2zjs-icc2ps</b> utility is part of the <b>foo2zjs</b> project, an open-source printer driver that provides support for printers using the ZjStream wire protocol. It was developed by Ralph M. Giannella as a component to enable robust color management for these printers by allowing ICC profiles to be integrated directly into the Postscript printing workflow, addressing a common need for accurate color reproduction in Linux environments.


title: SYNOPSIS
content:
<I><b>foo2zjs-pstops</b> [<I>options</I>] [<I>input.ps</I>] [<I>output.ps</I>]<br><I><b>foo2zjs-pstops</b> [<I>options</I>] < <I>input.ps</I> > <I>output.ps</I></I>


title: PARAMETERS
content:
<b>-l <pages></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects specific pages to print. <I>pages</I> can be a comma-separated list of page numbers or ranges (e.g., '1,3-5,7').<br><br><b>-n <N></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables N-up printing, arranging <I>N</I> logical pages onto a single physical sheet. Common values are 2, 4, 6, 8, etc.<br><br><b>-o <orientation></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output orientation of the pages. Common values include 'portrait' or 'landscape'.<br><br><b>-s <scale></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scales the content of the pages by the specified factor. For example, '0.5' for half size.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reverses the page order, typically used for back sides in duplex printing.<br><br><b>-e</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints only even-numbered pages.<br><br><b>-N</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables booklet mode, arranging and reordering pages for proper folded booklet printing.<br><br><b>-S <src-page></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the source page size (e.g., 'A4', 'Letter').<br><br><b>-P <dst-page></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the destination page size for output (e.g., 'A4', 'Letter').<br><br><b>-W <width></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output width in PostScript points.<br><br><b>-H <height></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output height in PostScript points.<br><br><b>-X <x_offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the X-axis offset of the content on the page in PostScript points.<br><br><b>-Y <y_offset></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adjusts the Y-axis offset of the content on the page in PostScript points.<br><br>


title: DESCRIPTION
content:
<I>The <b>foo2zjs-pstops</b> command is a specialized utility included with the <b>foo2zjs</b> printer driver suite, designed to preprocess PostScript files before they are sent to printers utilizing the proprietary ZjStream protocol or similar formats supported by <b>foo2zjs</b>.</I><br><br><I>Unlike generic PostScript manipulation tools, <b>foo2zjs-pstops</b> is tailored to integrate seamlessly with the <b>foo2zjs</b> workflow. Its primary function is to manipulate the layout and order of pages within a PostScript document. This includes selecting specific pages, reversing page order for duplex printing, arranging multiple pages per sheet (N-up printing), creating booklets, and adjusting page scaling and positioning.</I><br><br><I>It takes a PostScript file as input (either from standard input or a specified file) and produces a modified PostScript file on standard output or to an output file. This processed PostScript is then typically piped as input to the main <b>foo2zjs</b> rasterizer, which converts it into the printer's native language. <b>foo2zjs-pstops</b> is an essential component for users needing advanced print layout capabilities with their <b>foo2zjs</b>-compatible printers, such as printing brochures, manuals, or saving paper by consolidating content.</I>


title: CAVEATS
content:
<I><b>foo2zjs-pstops</b> requires a valid PostScript file as input; it cannot process other document formats directly. It is a pre-processor and does not perform the final rasterization or direct printer communication; its output must typically be piped to the main <b>foo2zjs</b> filter for actual printing. Complex or non-standard PostScript constructs might not be handled as expected, though it generally works well with standard PostScript produced by applications.</I>


title: CUPS INTEGRATION
content:
<I>When used within the Common Unix Printing System (CUPS), <b>foo2zjs-pstops</b> typically acts as a filter in the print job pipeline, often invoked by a wrapper script like <b>foo2zjs-wrapper</b>. This allows users to leverage its capabilities through standard print commands like <I>lpr</I> or through graphical print dialogs, with options being passed by CUPS.</I>


title: USAGE PIPELINE
content:
<I>A common usage pattern involves piping the output of <b>foo2zjs-pstops</b> to the main <b>foo2zjs</b> driver: <I>cat document.ps | foo2zjs-pstops -n 2 | foo2zjs | lp</I>. This example demonstrates taking a PostScript document, arranging two pages per sheet, converting it to the printer's native format, and then sending it to the default printer.</I>


title: HISTORY
content:
<I><b>foo2zjs-pstops</b> is an integral part of the <b>foo2zjs</b> open-source printer driver project, primarily developed by Rick Richardson. The <b>foo2zjs</b> suite emerged to provide robust Linux/Unix support for a range of laser printers that use proprietary data streams (like ZjStream), for which native manufacturer drivers were often unavailable or inadequate. <b>foo2zjs-pstops</b> was created to extend the functionality of the driver, allowing users to perform common PostScript page manipulations – such as N-up printing, duplexing, and booklet creation – directly within the <b>foo2zjs</b> processing pipeline, thus enhancing flexibility and resource efficiency for these specific printer models.</I>


title: SEE ALSO
content:
<I>foo2zjs(1)</I>, <I>foo2zjs-wrapper(1)</I>, <I>pstops(1)</I>, <I>psbook(1)</I>, <I>psselect(1)</I>, <I>psnup(1)</I>, <I>gs(1)</I>


title: PARAMETERS
content:
<b>FILE</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The PostScript file to be processed. If no file is specified, <b>foo2zjs-wrapper</b> reads from standard input (stdin).<br><br><b>-r <resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the printer resolution, e.g., 600 or 1200 DPI. This option is passed directly to <i>foo2zjs</i> and can also influence Ghostscript rendering.<br><br><b>-d <duplex_mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies duplex (double-sided) printing mode. Common values include 'Simplex', 'DuplexNoTumble', or 'DuplexTumble'.<br><br><b>-p <papersize></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the paper size, such as 'Letter', 'A4', 'Legal', etc.<br><br><b>-c <color_mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the color rendering mode, e.g., '1' for color, '0' for monochrome/grayscale.<br><br><b>-n <N-up></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints multiple pages per sheet. For example, '-n 2' for 2-up, '-n 4' for 4-up.<br><br><b>-t <toner_save_mode></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables or disables toner save mode, typically '0' for normal, '1' for toner save.<br><br><b>-G</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces grayscale rendering of the output, even for color input.<br><br><b>-s <source_tray></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the paper input tray or source, e.g., '1' for tray 1, '2' for manual feed.<br><br><b>-N <copies></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of copies to print. While CUPS often handles copies, this option can also be passed to the driver.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more details about the processing steps and options used.<br><br><b>-K <resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the resolution for Ghostscript rendering (often for internal PPM conversion, passed to <i>gs</i>).<br><br><b>-R <resolution></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Similar to -K, sets the Ghostscript resolution for input rendering (passed to <i>gs</i>).<br><br><b>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Many other options supported by the underlying <i>foo2zjs</i> driver are passed through by the wrapper. Refer to the <i>foo2zjs(1)</i> man page for a comprehensive list.<br><br>


title: DESCRIPTION
content:
The <b>foo2zjs-wrapper</b> command acts as a convenient front-end for the <i>foo2zjs</i> printer driver, primarily designed to simplify the printing of PostScript files to ZjS-based laser printers. It typically takes a PostScript input stream or file, processes it through <i>Ghostscript</i> (gs) to convert it into a raw PPM (Portable PixMap) image, and then feeds this PPM data to the <i>foo2zjs</i> driver to generate the printer-specific ZjS (Zjs Imaging System) language output.<br><br>This wrapper is particularly useful in environments like CUPS (Common Unix Printing System) where print jobs are often submitted as PostScript. It abstracts away the multi-step conversion process, allowing users or CUPS to simply send a PostScript file to the wrapper, which then handles the entire conversion pipeline to produce the printer-ready data. Many common printing options, such as resolution, paper size, duplexing, and color mode, are passed directly through to the underlying <i>foo2zjs</i> driver, providing a unified interface for configuration and printing.


title: CAVEATS
content:
The <b>foo2zjs-wrapper</b> command relies on the presence and correct configuration of both the <i>foo2zjs</i> driver and <i>Ghostscript</i> (gs) on the system. It is primarily designed to handle PostScript input; other input formats may require prior conversion. The output is raw printer data, which typically needs to be directed to a printer queue (e.g., via <i>lpr</i>) or directly to a printer device.


title: INTEGRATION WITH CUPS
content:
In a CUPS environment, <b>foo2zjs-wrapper</b> is often configured as a filter. When a print job is sent to a printer queue that uses a <i>foo2zjs</i> PPD (PostScript Printer Description) file, CUPS will typically invoke this wrapper with the PostScript job data. The wrapper then processes the job and sends the resulting printer-ready ZjS data back to CUPS, which in turn sends it to the physical printer.


title: INPUT AND OUTPUT
content:
The expected input for <b>foo2zjs-wrapper</b> is PostScript data, which can be provided via standard input (piped from another command) or by specifying a file path as an argument. The command's output is the raw ZjS printer language data, which is written to standard output. This output is usually redirected to a printer device or piped to a print spooler command like <i>lpr</i>.


title: HISTORY
content:
The <i>foo2zjs</i> project, which includes the <b>foo2zjs-wrapper</b>, was initiated by Rick S. Casey. Its development stemmed from the need for open-source drivers for printers utilizing the ZjS (Zjs Imaging System) language, which is common in many HP, Xerox, Minolta, Konica, Samsung, and Lexmark laser printers that lack native PostScript support. The wrapper was created to streamline the workflow, particularly for CUPS integration, by automating the Ghostscript-to-PPM and PPM-to-ZjS conversion pipeline, making these printers more accessible on Linux and Unix-like systems.


title: SYNOPSIS
content:
<B>foomatic-rip</B> [<I>-P printer</I>] [<I>-J job-id</I>] [<I>-o option=value</I> ...] [<I>-raw</I>] [<I>-V</I>] [<I>-D</I>] [<I>file</I> ...]


title: PARAMETERS
content:
<b><I>-P printer</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the name of the printer to use. This is typically the queue name known to the print spooler.<br><br><b><I>-J job-id</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the job ID assigned by the print spooler. This is primarily for logging and job management purposes.<br><br><b><I>-o option=value</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes specific printer options and their values, as defined in the printer's PPD file. Examples include <I>PageSize=A4</I>, <I>Duplex=DuplexNoTumble</I>, or <I>Resolution=600dpi</I>.<br><br><b><I>-raw</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>foomatic-rip</i> to pass the input data directly to the printer without any processing or filtering. This is typically used for PostScript printers receiving raw PostScript data.<br><br><b><I>-V</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the version information of <i>foomatic-rip</i>.<br><br><b><I>-D</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output to standard error, useful for troubleshooting printing issues.<br><br><b><I>-L</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Logs debug information to the system's syslog facility, often used when <I>-D</I> output is not practical.<br><br><b><I>file ...</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more input files to be processed and sent to the printer. If no files are specified, <i>foomatic-rip</i> reads from standard input.<br><br>


title: DESCRIPTION
content:
<i>foomatic-rip</i> is a crucial component of the <B>Foomatic</B> printing system, designed to act as a universal print filter. It bridges the gap between print spoolers (like <B>CUPS</B> or <B>LPD</B>) and the actual printer drivers, converting print job data into a format that a specific printer can understand. <br><br>When a user sends a print job, <i>foomatic-rip</i> takes the input (often PostScript or PDF), consults a <B>PPD</B> (PostScript Printer Description) file for the selected printer, and processes any user-specified options (e.g., paper size, resolution, duplexing). It then pipes the transformed data to the appropriate backend driver, which is often a <B>Ghostscript</B> command or another printer-specific utility. This modular design allows <i>foomatic-rip</i> to support an extensive range of printers and drivers, making it a cornerstone of Linux printing environments for many years, simplifying printer setup and management.


title: CAVEATS
content:
Several options like <I>-u</I> (no PPD) and <I>-X</I> (no PPD options) are considered <B>deprecated</B> and should be avoided in modern setups. <br><br>Proper functionality of <i>foomatic-rip</i> relies heavily on the availability of correct Foomatic PPD files and the underlying printer drivers (often <B>Ghostscript</B> or vendor-specific binaries). Configuration errors in PPDs or missing drivers are common sources of printing problems. <br><br>As <i>foomatic-rip</i> executes external commands based on PPD definitions, security considerations are paramount. Ensure PPD files are sourced from trusted locations to prevent arbitrary command execution vulnerabilities.


title: INTEGRATION WITH SPOOLERS
content:
<i>foomatic-rip</i> is typically invoked by a print spooler (e.g., <B>CUPS</B> or <B>LPD</B>) as a filter. The spooler provides the necessary environment variables and command-line arguments, such as the printer name (<I>-P</I>), job ID (<I>-J</I>), and input file or standard input. It acts as the final processing step before the data is sent to the printer's physical device.


title: ROLE OF PPD FILES
content:
At the heart of <i>foomatic-rip</i>'s operation are <B>PPD</B> (PostScript Printer Description) files. These files contain detailed information about a printer's capabilities, supported options, and the specific commands (often <B>Ghostscript</B> invocations) required to convert print data into the printer's native language. <i>foomatic-rip</i> parses these PPDs to correctly interpret user options and generate the appropriate output for the printer.


title: HISTORY
content:
<B>Foomatic-rip</B> emerged as a core component of the <B>Foomatic</B> project, which was initiated around the year 2000. Its primary goal was to provide a standardized, flexible, and unified approach to printer driver management on Linux and Unix-like systems, especially for the vast number of non-PostScript printers available. <br><br>Developed by various contributors, including MandrakeSoft (later Mandriva), Foomatic aimed to abstract away the complexities of different printer technologies by leveraging <B>PPD</B> files and <B>Ghostscript</B>. <i>foomatic-rip</i> quickly became an essential part of most Linux distributions' printing stacks, integrated seamlessly with print spoolers like <B>CUPS</B> and <B>LPD</B>. While newer driverless printing technologies (e.g., IPP Everywhere) are gaining traction, <i>foomatic-rip</i> remains vital for supporting a wide legacy of printers and proprietary drivers.


title: SYNOPSIS
content:
<I>Iterate over a list:</I><br><b>for</b> <I>VARIABLE</I> <b>in</b> <I>LIST</I><b>; do</b><br>  <I>COMMANDS</I><br><b>done</b><br><br><I>C-style arithmetic for loop (Bash/Zsh):</I><br><b>for ((</b> <I>INIT</I><b>;</b> <I>CONDITION</I><b>;</b> <I>INCREMENT</I> <b>)); do</b><br>  <I>COMMANDS</I><br><b>done</b>


title: PARAMETERS
content:
<b><I>VARIABLE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A variable that takes on the value of each item in the <I>LIST</I> during each iteration of the loop.<br><br><b><I>LIST</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A space-separated list of words, which can be filenames, strings, command substitutions, or shell expansions. The loop iterates once for each word in this list.<br><br><b><I>INIT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(C-style loop) An arithmetic expression executed once before the loop begins, typically for initializing a counter variable.<br><br><b><I>CONDITION</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(C-style loop) An arithmetic expression evaluated before each iteration. If it evaluates to non-zero (true), the loop continues; otherwise, it terminates.<br><br><b><I>INCREMENT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(C-style loop) An arithmetic expression executed after each iteration of the loop, typically for updating the counter variable.<br><br><b><I>COMMANDS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The block of one or more shell commands to be executed during each iteration of the loop.<br><br>


title: DESCRIPTION
content:
The <b>for</b> command in Linux shell scripting is a fundamental control flow construct used for iterative execution. It allows a set of commands to be executed repeatedly, either for each item in a given list of words or by iterating through a sequence of arithmetic operations similar to C-style for loops. The primary use case is processing files, directories, numbers, or any sequence of strings. It's an essential tool for automating repetitive tasks, processing data sets, and manipulating file systems efficiently within shell scripts.


title: CAVEATS
content:
The <b>for in list</b> loop performs word splitting and pathname expansion on the <I>LIST</I> before iteration. This can lead to unexpected behavior if filenames contain spaces or special characters, unless proper quoting (e.g., `"$item"`) or adjustments to <b>IFS</b> are made. The C-style <b>for ((...))</b> loop is a Bash/Zsh extension and not universally portable to all POSIX shells like standard Bourne shell.


title: USAGE EXAMPLES
content:
<b><I>Iterating over files:</I></b><br><b>for</b> file <b>in</b> *.txt<b>; do</b><br>  <b>echo</b> "Processing $file"<br>  <b>cat</b> "$file"<br><b>done</b><br><br><b><I>C-style loop for numbers:</I></b><br><b>for ((</b> i=1<b>;</b> i<=5<b>;</b> i++ <b>)); do</b><br>  <b>echo</b> "Number: $i"<br><b>done</b><br><br><b><I>Looping through command output:</I></b><br><b>for</b> user <b>in $(cut</b> -d: -f1 /etc/passwd<b>); do</b><br>  <b>echo</b> "User: $user"<br><b>done</b>


title: HISTORY
content:
The <b>for</b> loop is a foundational construct present in the original Bourne shell (sh) from the late 1970s, making it a cornerstone of Unix shell scripting. The basic <b>for VARIABLE in LIST; do ...; done</b> syntax has remained largely consistent across various shells. The C-style arithmetic <b>for ((...)); do ...; done</b> loop was introduced later with Bash (Bourne Again SHell) to provide a more familiar looping paradigm for programmers coming from C-like languages.


title: SYNOPSIS
content:
<b>foreman</b> <I>command</I> [<I>options</I>] [<I>arguments</I>]<br><br>Common commands include:<br><b>foreman start</b> [<I>PROCESS</I>]<br><b>foreman run</b> <I>COMMAND</I> [<I>ARGS</I>]<br><b>foreman export</b> <I>FORMAT DIRECTORY</I><br><b>foreman check</b><br><b>foreman help</b> [<I>COMMAND</I>]


title: PARAMETERS
content:
<b><b>--procfile</b> <I>path</I>, <b>-f</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <i>Procfile</i> to load instead of the default <i>./Procfile</i>.<br><br><b><b>--env</b> <I>path</I>, <b>-e</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies one or more <i>.env</i> files from which to load environment variables. Can be specified multiple times.<br><br><b><b>--port</b> <I>port</I>, <b>-p</b> <I>port</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the base port for web processes (e.g., via the `PORT` environment variable), defaulting to 5000.<br><br><b><b>--concurrency</b> <I>spec</I>, <b>-c</b> <I>spec</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the number of processes to start for each process type (e.g., <i>web=2,worker=1</i>).<br><br><b><b>--root</b> <I>path</I>, <b>-r</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the application's root directory, used to locate the <i>Procfile</i> and <i>.env</i> files.<br><br><b><b>--full-color</b>, <b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces full color output, even when output is redirected or piped.<br><br><b><b>--no-color</b>, <b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables color output from processes.<br><br><b><b>--index</b>, <b>-i</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Indexes processes with a suffix (e.g., <i>web.1, web.2</i>) for unique identification.<br><br>


title: DESCRIPTION
content:
<i>foreman</i> is a command-line tool that facilitates the management of application process groups, primarily by reading definitions from a <i>Procfile</i>. A <i>Procfile</i> specifies various process types required by an application, such as web servers, background workers, or databases. When executed, <i>foreman</i> launches all defined processes concurrently, directing their standard output and error streams to the console. To enhance readability, each process's output is color-coded. A key feature is its default behavior: if any process defined in the <i>Procfile</i> terminates unexpectedly, <i>foreman</i> automatically shuts down all other running processes, ensuring a clean exit. This makes it exceptionally useful for orchestrating complex, multi-service applications during local development, providing a consistent way to start and monitor all application components. It also integrates with <i>.env</i> files for loading environment variables.


title: CAVEATS
content:
<i>foreman</i> is primarily designed for local development environments and is generally not recommended for production deployment without using its <i>export</i> functionality to generate system-specific service files (like Upstart or Systemd units). Its process monitoring is basic; it simply shuts down all processes if one fails, without advanced restart strategies. Managing output from many concurrent processes can be challenging without proper logging configuration.


title: THE PROCFILE
content:
<i>foreman</i> relies heavily on the <i>Procfile</i>, a simple text file typically located in the root directory of an application. This file defines the commands required to start each process type for the application. For example:<br><i>web: bundle exec rails s<br>worker: bundle exec sidekiq</i><br>Each line specifies a process type (e.g., 'web', 'worker') followed by a colon and the command to execute it.


title: ENVIRONMENT VARIABLES (.ENV)
content:
<i>foreman</i> can automatically load environment variables from <i>.env</i> files. These files, usually named <i>.env</i>, <i>.env.development</i>, etc., contain key-value pairs that are loaded into the environment of the processes started by <i>foreman</i>. This provides a convenient way to manage configuration without hardcoding sensitive information or specific settings directly into the <i>Procfile</i>.


title: EXPORTING PROCESSES
content:
While primarily for development, <i>foreman</i> includes an <i>export</i> command that can generate configuration files for various process management systems. This allows for a more production-ready deployment of applications defined by a <i>Procfile</i>. Supported export formats include Upstart, Systemd, Bluepill, Runit, launchd, inittab, and Supervisord.


title: HISTORY
content:
The <b>foreman</b> tool was inspired by Heroku's process model, which advocates for defining application processes in a <i>Procfile</i>. It was originally developed by David Dollar and is written in Ruby. Its popularity, particularly within the Ruby on Rails community, led to the creation of numerous cross-language implementations and alternatives, such as <i>honcho</i> (Python) and <i>goreman</i> (Go), aiming to replicate its simple yet powerful process management capabilities for local development across different technology stacks.


title: SYNOPSIS
content:
<b>foremost</b> [-vVwq] [-a] [-b <size>] [-c <config>] [-d] [-D <num>] [-e <num>] [-f <file>] [-i <file>] [-o <dir>] [-s <num>] [-t <type>] [-T] [-x] [-X]


title: PARAMETERS
content:
<b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show version information and exit.<br><br><b><b>-w</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Write only the audit file, no actual file recovery. Useful for testing configurations.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn off all error messages. Only warnings and fatal errors will be displayed.<br><br><b><b>-b</b> <i>&lt;size&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the block size for reading the input file. Default is 512 bytes. Useful for certain raw disk formats.<br><br><b><b>-c</b> <i>&lt;configfile&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a configuration file to use. Default is <i>/etc/foremost.conf</i>.<br><br><b><b>-d</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable data deduplication. If turned on, all recovered files are stored in a single directory and duplicate files are not written.<br><br><b><b>-D</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares that the footer search will not exceed <i>&lt;num&gt;</i> bytes from the beginning of the header. For variable length headers.<br><br><b><b>-e</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Declares that the header search will not exceed <i>&lt;num&gt;</i> bytes from the end of the footer. For variable length footers.<br><br><b><b>-f</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a file or device to write the recovered data to. (Deprecated, use <b>-o</b>)<br><br><b><b>-i</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the input file (e.g., disk image, partition, or whole device) to scan. If omitted, standard input is used.<br><br><b><b>-o</b> <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the output directory for recovered files. <b>foremost</b> will create subdirectories for each file type.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quick mode. Only search for headers, do not perform full data carving using footers or internal structures.<br><br><b><b>-s</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the block size for sparse file detection. Useful for detecting sparse blocks in disk images.<br><br><b><b>-t</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify file types to search for (e.g., <i>jpg</i>, <i>pdf</i>, <i>doc</i>, or <i>all</i>). Multiple types can be separated by commas.<br><br><b><b>-T</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Timestamp the output directory. The output directory will be named with the current date and time (e.g., <i>output_YYYYMMDDHHMMSS</i>).<br><br><b><b>-x</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically create an audit file named <i>audit.txt</i> in the output directory, logging the carving process.<br><br><b><b>-X</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output for all file types during a scan, showing details for each file found.<br><br>


title: DESCRIPTION
content:
<b>foremost</b> is a console-based data carving program designed to recover files based on their headers, footers, and internal data structures. It can work on image files (like <i>dd</i> images) or directly on a raw storage device (e.g., hard drive, USB drive, memory card). <b>foremost</b> ignores the filesystem structure, making it effective for recovering files from corrupted, formatted, or partially overwritten media.<br><br>It uses a configuration file (typically <i>foremost.conf</i>) to define file types it can recover, specifying magic numbers, file extensions, and maximum file sizes. When run, it extracts files into a specified output directory, organizing them by type (e.g., <i>jpg</i>, <i>doc</i>, <i>pdf</i>). It's commonly used in digital forensics and data recovery scenarios when traditional filesystem-aware recovery tools are insufficient.


title: CAVEATS
content:
<b>foremost</b> recovers files based on signatures, ignoring filesystem metadata. This means:<br><ul><li>Recovered files may be fragmented, partial, or corrupted.</li><li>File names and original directory structures are not preserved.</li><li>It can be a resource-intensive and time-consuming process on large drives or images.</li><li>Always work on a copy of the evidence or in a read-only manner to prevent further data loss.</li></ul>


title: CONFIGURATION FILE (<I>FOREMOST.CONF</I>)
content:
<b>foremost</b> relies heavily on its configuration file (by default, <i>/etc/foremost.conf</i> or specified by <b>-c</b>) to define the file types it can recognize and recover. This file specifies the file extension, whether the search is case-sensitive, the maximum file size, and the hexadecimal or ASCII values for the file's header and footer. Users can customize this file to add support for new or proprietary file types, or to adjust the recovery parameters for existing ones.


title: OUTPUT DIRECTORY STRUCTURE
content:
Upon successful recovery, <b>foremost</b> organizes the extracted files into subdirectories within the specified output folder (e.g., <i>output/jpg</i>, <i>output/pdf</i>). Each recovered file is renamed numerically (e.g., <i>000000.jpg</i>). An <i>audit.txt</i> file is also created in the main output directory, providing a log of the carving process, including details like the original offset of each recovered file on the input media and its new name.


title: HISTORY
content:
<b>foremost</b> was originally developed by Kris Kendall and Jesse Kornblum while working for the United States Air Force Office of Special Investigations (AFOSI) and the Center for Information Systems Security Studies and Research (CISSR) at Naval Postgraduate School. It was designed as an open-source tool for digital forensic investigations, initially released around 2001-2002. Its development aimed to provide a reliable method for recovering data from damaged or fragmented media by focusing on file signatures rather than filesystem metadata, a technique known as 'data carving.' It has since been maintained and updated by the open-source community, remaining a staple in many digital forensics toolkits.


title: SYNOPSIS
content:
<b>forever</b> [<i>options</i>] <i><script.js></i> [<i>script-args</i>]<br><b>forever</b> <i><command></i> [<i>options</i>]


title: PARAMETERS
content:
<b>start</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the script and daemonizes it, keeping it running in the background.<br><br><b>stop <i><uid|script></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops the <i>forever</i> process identified by its unique ID (UID) or script path.<br><br><b>stopall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Stops all <i>forever</i> processes currently running.<br><br><b>restart <i><uid|script></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts a specific <i>forever</i> process by its UID or script path.<br><br><b>restartall</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Restarts all <i>forever</i> processes.<br><br><b>list</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Lists all <i>forever</i> processes that are currently running, showing their status and UIDs.<br><br><b>logs <i><uid|script></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the logs (<i>stdout</i>/<i>stderr</i>) for a specific <i>forever</i> process.<br><br><b>cleanlogs</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Cleans up old <i>forever</i> log files.<br><br><b>-s, --silent</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses output messages from <i>forever</i> itself, showing only errors from the managed script.<br><br><b>-o, --outFile <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file for capturing the standard output (<i>stdout</i>) of the script.<br><br><b>-e, --errFile <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file for capturing the standard error (<i>stderr</i>) of the script.<br><br><b>-l, --logFile <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to the <i>forever</i> log file, which records <i>forever</i>'s internal messages and actions.<br><br><b>-p, --pidFile <i><file></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Path to a file for storing the <i>forever</i> process's Process ID (PID).<br><br><b>-c, --command <i><cmd></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The command used to execute the script (default: <i>node</i> for .js files).<br><br><b>-a, --append</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Appends logs to the specified <i>outFile</i>, <i>errFile</i>, and <i>logFile</i> instead of overwriting them.<br><br><b>-w, --watch [<i>dir</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Watches for file changes in the script's directory (or specified directory) and automatically restarts the script upon modification.<br><br><b>--minUptime <i><ms></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Minimum uptime in milliseconds before a script is considered stable (default: 0).<br><br><b>--spinSleepTime <i><ms></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Time in milliseconds to wait before restarting a script after it crashes (default: 5000ms).<br><br><b>--killSignal <i><signal></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The signal to send to the process to terminate it (e.g., <i>SIGTERM</i>, <i>SIGKILL</i>).<br><br><b>--uid <i><name></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a unique ID to the <i>forever</i> process, making it easier to manage and identify (e.g., <i>my-app</i>).<br><br><b>--sourceDir <i><dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Absolute path to the script's source directory, used when <i>forever</i> changes directory.<br><br><b>--workingDir <i><dir></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Absolute path to the script's working directory, where the script will be executed.<br><br><b>--max <i><n></i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The maximum number of times <i>forever</i> will attempt to restart the script before giving up.<br><br><b>--plain</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables colors from <i>forever</i> output, useful for plain text logging.<br><br>


title: DESCRIPTION
content:
<i>forever</i> is a simple command-line interface (CLI) tool for Node.js applications designed to ensure that a given script runs continuously. It daemonizes the specified Node.js script, keeping it alive even if it crashes or exits unexpectedly. When a script monitored by <i>forever</i> terminates, <i>forever</i> automatically restarts it, providing basic process uptime management. It supports redirecting standard output and error to log files, watching for file changes to trigger restarts, and managing multiple Node.js processes concurrently. While not as feature-rich as more advanced process managers like PM2 or systemd, <i>forever</i> remains a popular choice for straightforward deployments and background script execution due to its simplicity and ease of use.


title: CAVEATS
content:
While <i>forever</i> is excellent for simple Node.js process management, it has limitations. It lacks advanced features found in PM2, such as built-in clustering, load balancing, or detailed monitoring dashboards. It doesn't integrate directly with system-level init systems like <i>systemd</i> without additional configuration. For complex production environments or applications requiring high availability and sophisticated scaling, more robust solutions might be preferred. Furthermore, if the <i>forever</i> process itself crashes, it will cease to monitor and restart any daemonized scripts.


title: INSTALLATION
content:
<i>forever</i> is typically installed via npm (Node Package Manager). To install it globally on your system, use the command:<br><i>npm install -g forever</i>


title: USAGE EXAMPLES
content:
To start a Node.js script:<br><i>forever start app.js</i><br><br>To start a script and redirect its output to specific log files:<br><i>forever start -o /var/log/my_app_out.log -e /var/log/my_app_err.log app.js</i><br><br>To list all running <i>forever</i> processes:<br><i>forever list</i><br><br>To stop a specific process by its UID (e.g., if '0' is its UID from <i>forever list</i>):<br><i>forever stop 0</i><br><br>To watch for changes in the script's directory and restart it automatically:<br><i>forever start -w app.js</i>


title: HISTORY
content:
<i>forever</i> originated as a practical utility for Node.js developers in the early days of Node.js, when deploying and maintaining long-running Node.js processes was a common challenge. It provided a straightforward way to keep scripts running in the background and automatically restart them upon failure. Its development focused on simplicity and ease of use, quickly becoming a popular choice for smaller projects and development environments. Although more feature-rich alternatives like PM2 have emerged, <i>forever</i> remains a relevant tool, especially for those seeking a lightweight and low-overhead solution for continuous script execution.


title: SYNOPSIS
content:
<b>fortune</b> [ <i>-a | -l | -o</i> ] [ <i>-e | -s | -i</i> ] [ <i>-c | -f | -w</i> ] [ <i>-D file</i> ] [ <i>-m pattern</i> ] [ <i>-n number</i> ] [ <i>-N number</i> ] [ <i>-F file</i> ] [ <i>-x</i> ] [ <i>-u</i> ] [ <i>percentfile ...</i> ]


title: PARAMETERS
content:
<b><b>-a</b>, <b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Consider all fortune files, including potentially offensive ones, not just the 'good' ones.<br><br><b><b>-c</b>, <b>--censored</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Censor offensive fortunes. This is the default behavior.<br><br><b><b>-e</b>, <b>--equal-chance</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Give all fortunes an equal chance of being picked, regardless of their file size. Useful for small files.<br><br><b><b>-f</b>, <b>--offend</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Include offensive fortunes in the selection, but they are not chosen exclusively.<br><br><b><b>-l</b>, <b>--long-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print only long fortunes. A 'long' fortune is typically more than 160 characters.<br><br><b><b>-o</b>, <b>--off</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only print offensive fortunes. This option overrides <b>-c</b>.<br><br><b><b>-s</b>, <b>--short-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print only short fortunes. A 'short' fortune is typically 160 characters or less.<br><br><b><b>-i</b>, <b>--insensitive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a case-insensitive match when using the <b>-m</b> option.<br><br><b><b>-m <i>pattern</i></b>, <b>--match <i>pattern</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print fortunes that contain the specified regular expression <i>pattern</i>.<br><br><b><b>-w</b>, <b>--wrap</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wrap long lines of text to fit the terminal width, useful for readability.<br><br><b><b>-F <i>file</i></b>, <b>--fortune-file <i>file</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read fortunes from the specified <i>file</i> instead of the default databases.<br><br><b><b>-x</b>, <b>--exclude</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Exclude specific fortune files or directories from consideration.<br><br><b><b>-u</b>, <b>--unbuffered</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Turn off output buffering. Useful for scripts that need immediate output.<br><br><b><b>-D <i>file</i></b>, <b>--directory <i>file</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read fortunes from the specified <i>directory</i>, treating it as a collection of fortune files.<br><br><b><b>-n <i>number</i></b>, <b>--number <i>number</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Deprecated)</i> Show a specific fortune by its 0-indexed <i>number</i> within the selected files.<br><br><b><b>-N <i>number</i></b>, <b>--nth <i>number</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>(Deprecated)</i> Show the <i>number</i>-th fortune (1-indexed) within the selected files.<br><br><b><b><i>percentfile ...</i></b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify a list of fortune files or directories along with their percentage chances of being selected. E.g., '<i>literature%20 science%80</i>'.<br><br>


title: DESCRIPTION
content:
The <b>fortune</b> command is a classic Unix utility that displays a random message, often called a 'fortune', from a database of quotations. These messages can vary widely, from humorous jokes and puns to insightful sayings, historical quotes, or short stories. It's commonly used by users in their shell startup scripts (like <i>.bashrc</i> or <i>.profile</i>) to provide a fresh, entertaining, or thought-provoking message each time they log in or open a new terminal. The command reads from pre-compiled fortune databases, typically located in system directories like <i>/usr/share/games/fortune/</i>. Users can choose to include or exclude categories of fortunes, such as offensive content, or filter fortunes based on length or specific patterns. It serves as a simple yet effective way to inject a bit of randomness and fun into the command-line experience.


title: CAVEATS
content:
The <b>-n</b> and <b>-N</b> options are deprecated and may not work as expected or be removed in future versions. The variety and nature of fortunes depend entirely on the installed fortune databases on the system. Some distributions may not include offensive fortunes by default.


title: FILES
content:
Common locations for fortune databases include <i>/usr/share/games/fortune/</i> and <i>/usr/local/share/games/fortune/</i>. Users can also create their own fortune files, typically stored in their home directory, like <i>~/.fortune</i>.


title: CUSTOM FORTUNES
content:
To create custom fortune files, simply put each fortune on a new line, separating fortunes with a '<i>%</i>' character on a line by itself. Then, run <i>strfile</i> on your custom file to create the necessary <i>.dat</i> index file for <b>fortune</b> to read it efficiently.


title: HISTORY
content:
The <b>fortune</b> command is one of the oldest and most beloved utilities in the Unix ecosystem, originating from the early BSD distributions. Its primary purpose was to provide a bit of lightheartedness and entertainment in the command-line environment. The accompanying <b>strfile</b> utility was developed specifically to efficiently store and retrieve these textual fortunes, allowing for quick access to large databases. Over the decades, it has remained a staple for many users, often appearing in login messages or shell prompts.


title: SYNOPSIS
content:
<b>fossa</b> <I>command</I> [<I>options</I>] [<I>arguments</I>]<br><br>Common commands:<br><b>fossa analyze</b> [<I>options</I>]<br><b>fossa init</b> [<I>options</I>]<br><b>fossa report</b> [<I>options</I>]


title: PARAMETERS
content:
<b><b>analyze</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Scans the current project or specified path to identify dependencies and their licenses. This is the core command for initiating a scan.<br><br><b><b>init</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes a <b>fossa</b> project configuration in the current directory. This command sets up the necessary files for <b>fossa</b> to operate.<br><br><b><b>test</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Executes compliance tests against your project's dependencies based on configured policies, often used in CI/CD pipelines to enforce license compliance.<br><br><b><b>report</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generates a compliance report for a specified project. Various output formats (e.g., SPDX, JSON, HTML) are supported.<br><br><b><b>upload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uploads pre-generated scan results (e.g., SBOMs) to the FOSSA platform for analysis and reporting.<br><br><b><b>--organization</b> <I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the organization ID to associate the scan or action with. Required for multi-organization setups.<br><br><b><b>--project</b> <I>ID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the project ID within the organization. If not provided, <b>fossa</b> attempts to infer it from the Git remote or configuration.<br><br><b><b>--revision</b> <I>name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the specific revision (e.g., Git commit hash, branch name) for the scan or report.<br><br><b><b>--output</b> <I>format</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the output format for commands like <b>report</b> (e.g., <I>json</I>, <I>spdx</I>, <I>html</I>).<br><br><b><b>--config</b> <I>path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the <b>fossa</b> configuration file (typically <I>.fossa.yml</I>).<br><br><b><b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debugging output for troubleshooting.<br><br>


title: DESCRIPTION
content:
The <b>fossa</b> command-line interface (CLI) provides a powerful suite of tools for <I>software composition analysis (SCA)</I>. It helps organizations understand, manage, and comply with open-source software licenses across their codebases. <b>fossa</b> works by scanning your projects to identify all direct and transitive dependencies, their associated licenses, and potential security vulnerabilities. It then builds a <I>Software Bill of Materials (SBOM)</I> and generates reports that can be used for license compliance, risk management, and due diligence. Designed for integration into CI/CD pipelines, <b>fossa</b> enables automated compliance checks and policy enforcement, ensuring that only approved open-source components are used. Its capabilities are crucial for developers, legal teams, and compliance officers looking to maintain a transparent and compliant open-source posture.


title: CAVEATS
content:
The <b>fossa</b> CLI tool typically requires an API key or authentication with the FOSSA SaaS platform for full functionality, as it uploads scan data and retrieves policies from the cloud service. It is not a standard, pre-installed Linux utility and must be installed separately. Performance can vary significantly based on project size and complexity, potentially consuming considerable CPU and memory resources for large codebases. Its accuracy depends on the quality of its internal knowledge base and the completeness of the project's dependency resolution.


title: INSTALLATION
content:
The <b>fossa</b> CLI is generally installed via a package manager (e.g., <I>brew</I> on macOS, or <I>curl</I> script for Linux) or downloaded directly as a binary. It's not part of standard Linux distributions. Users typically need to configure their environment with an API key, often via an environment variable (<I>FOSSA_API_KEY</I>) or a configuration file.


title: INTEGRATION
content:
<b>fossa</b> is commonly integrated into CI/CD pipelines (e.g., Jenkins, GitLab CI, GitHub Actions) to run automated scans on every commit or pull request. This ensures continuous compliance and early detection of license conflicts or vulnerabilities. The <I>test</I> command is particularly useful in this context, allowing builds to fail if policy violations are detected.


title: HISTORY
content:
FOSSA was founded by Alex Solomon with a vision to automate open-source compliance and security. It emerged as a leading solution in the Software Composition Analysis (SCA) space, particularly gaining traction for its robust policy engine, deep dependency scanning capabilities, and strong integration with developer workflows and CI/CD pipelines. Its development has focused on providing comprehensive, automated compliance and security insights for enterprises leveraging open-source software, addressing the growing complexities of license obligations and vulnerability management.


title: SEE ALSO
content:
git(1) (for version control integration), npm(1) (for Node.js package management), pip(1) (for Python package management), WhiteSource (SCA tool), Black Duck (SCA tool), Snyk (SCA tool), SPDX (Software Package Data Exchange standard), CycloneDX (SBOM standard)


title: PARAMETERS
content:
<b>init</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new, empty Fossil repository file.<br><br><b>clone</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a local copy of a remote Fossil repository.<br><br><b>open</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens an existing repository file and creates a working directory.<br><br><b>add</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds files or directories to the current checkout.<br><br><b>commit</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Records changes from the working directory into the repository.<br><br><b>pull</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Fetches changes from a remote repository.<br><br><b>push</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sends local changes to a remote repository.<br><br><b>status</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the status of files in the current checkout.<br><br><b>web</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Starts the built-in web server for the repository.<br><br><b>ui</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Opens the web interface in a browser (alias for 'web --browse').<br><br><b>--repository <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the repository file to use instead of the default.<br><br><b>--chdir <i>&lt;dir&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Changes the current directory before processing the command.<br><br>


title: DESCRIPTION
content:
Fossil is a simple, distributed, self-contained software configuration management system. It integrates version control, a bug tracking system, a wiki, and a forum into a single, compact binary. Developed by D. Richard Hipp, the creator of SQLite, Fossil stores an entire project's history, including code, wiki pages, forum posts, and bug reports, within a single SQLite database file. Its design emphasizes ease of deployment, minimal dependencies, and robustness, making it suitable for small to medium-sized projects. Fossil includes a powerful built-in web interface for browsing repositories, managing tickets, and interacting with the wiki and forum, accessible directly from the command line. It supports both centralized and distributed workflows, allowing developers to clone repositories, commit changes locally, and then push/pull updates between repositories.


title: CAVEATS
content:
Fossil is less widely adopted than Git or Mercurial, which may mean fewer community resources and integrations. While distributed, its typical usage often leans towards a centralized hub model due to its integrated project management features. Performance for very large binary files or extremely massive repositories might not match specialized version control systems.


title: INTEGRATED PROJECT MANAGEMENT
content:
Fossil is unique in bundling version control with a wiki, bug tracking, and a forum into a single repository file and a single executable. This significantly simplifies project setup and management for small to medium-sized teams, fostering a complete project ecosystem.


title: SINGLE FILE REPOSITORY
content:
All project data, including code history, wiki content, tickets, and forum discussions, is stored within a single SQLite database file. This design makes backup, cloning, and archiving extremely straightforward and simplifies repository management.


title: BUILT-IN WEB INTERFACE
content:
Fossil includes a powerful and fully functional web interface that can be launched directly from the command line using the <b>web</b> or <b>ui</b> subcommands. This allows users to browse the repository, view file history, manage tickets, and interact with the wiki and forum using just a web browser, without needing a separate web server setup.


title: HISTORY
content:
Fossil was created by D. Richard Hipp, the primary author of SQLite, starting around 2007-2008. His motivation was to develop a robust, self-contained, and easy-to-deploy SCM that also integrated project management tools like a wiki and bug tracker, similar to how he managed SQLite's development. It was designed to be simple, reliable, and to have minimal external dependencies, compiling into a single executable. Fossil is self-hosting, meaning its own source code is managed using Fossil itself. It has gained traction among projects that prioritize simplicity, single-file distribution, and integrated project management features, especially those that appreciate the robustness and simplicity of SQLite.


title: PARAMETERS
content:
<b>-R <REPOSITORY>, --repository <REPOSITORY></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Fossil repository database file to operate on.<br><br><b>-f, --force</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the addition of files, even if they are currently ignored or if there are conflicts.<br><br><b>-r, --recursive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds files within specified directories recursively. This is often the default behavior when adding a directory, but ensures all subdirectories are processed.<br><br><b>-v, --verbose</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints additional details about the files being added.<br><br><b>--dry-run</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a trial run without actually adding files, showing what would be added.<br><br><b>--glob</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Treats <I>FILE</I> arguments as glob patterns rather than literal filenames.<br><br><b>--case-sensitive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <I>--glob</I>, treats patterns as case-sensitive.<br><br><b>--no-case-sensitive</b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <I>--glob</I>, treats patterns as case-insensitive (default on Windows/macOS).<br><br><b>--once</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only adds a file if it is not already tracked by Fossil.<br><br><b>--</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Marks the end of command-line options, allowing subsequent arguments to be treated as filenames even if they start with a hyphen.<br><br><b><I>FILE</I>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories to add to the repository.<br><br>


title: DESCRIPTION
content:
<I>fossil add</I> is a command used in the <I>Fossil SCM</I> (Source Code Management) system to mark new files or directories for inclusion in the repository. It scans the provided paths, determines which files are not yet tracked, and stages them for the next commit. This command is analogous to <I>git add</I> in Git.<br><br>When adding directories, <I>fossil add</I> can operate recursively to include all new files within that directory and its subdirectories. It ensures that only actual file content is tracked, meaning empty directories are not added to the repository directly. Files can be specified individually, via wildcards, or by pointing to a directory. After using <I>fossil add</I>, the changes must be finalized with a <I>fossil commit</I> command.


title: CAVEATS
content:
<I>fossil add</I> only stages files for addition; a subsequent <I>fossil commit</I> is required to finalize the changes in the repository.<br>By default, files matching patterns in <I>ignore-glob</I> settings (e.g., in <I>.fossil-settings/ignore-glob</I>) are not added unless the <I>--force</I> option is used.<br>Fossil does not track empty directories. If a directory contains no files, it will not be added to the repository.


title: ADDING DIRECTORIES
content:
When a directory is specified as an argument to <I>fossil add</I>, the command will recursively scan the directory and all its subdirectories for new files. These files will be staged for inclusion in the repository. Empty directories are not tracked.


title: INTERACTION WITH IGNORE SETTINGS
content:
<I>fossil add</I> respects the global and local ignore settings (e.g., defined via <I>fossil setting ignore-glob</I> or <I>.fossil-settings/ignore-glob</I> files). Files matching these patterns will typically be skipped during the add process. To override this behavior and force the addition of an ignored file, the <I>--force</I> option must be used.


title: HISTORY
content:
The <I>fossil-add</I> command is an integral part of the <I>Fossil SCM</I> system, which was created by <B>D. Richard Hipp</B>, the developer behind SQLite. Fossil was designed as a simple, distributed version control system that integrates project management (bug tracking, wiki, forum) within a single self-contained executable. The <I>add</I> command has been a fundamental component since Fossil's early development, reflecting its role as a core operation for bringing new content under version control, much like its counterparts in other SCMs like Git or Subversion.


title: SYNOPSIS
content:
<i>fossil ci</i> <br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--status</i> <I>STATUS</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--tag</i> <I>TAG</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--url</i> <I>URL</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--user</i> <I>USER</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--hash</i> <I>UUID</I> | <i>--branch</i> <I>BRANCH</I> | <i>--checkin</i> <I>UUID</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--desc</i> <I>TEXT</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--ci-name</i> <I>NAME</I>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--verbose</i>]<br>&nbsp;&nbsp;&nbsp;&nbsp;[<i>--repository</i> <I>FILE</I>]


title: PARAMETERS
content:
<b><i>--status</i> <I>STATUS</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the CI status. <I>STATUS</I> can be 'ok' (success), 'fail' (failure), 'error' (system error), or 'pending' (in progress).<br><br><b><i>--tag</i> <I>TAG</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a CI tag (e.g., 'ci/build/linux-amd64' or 'ci/test/unit') to categorize the CI result.<br><br><b><i>--url</i> <I>URL</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides a URL pointing to the detailed output, logs, or dashboard of the CI job for more information.<br><br><b><i>--user</i> <I>USER</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user or system that performed the CI operation (e.g., 'jenkins', 'gitlab-ci', 'github-actions').<br><br><b><i>--hash</i> <I>UUID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The UUID of the specific check-in for which the CI status applies. Typically provided by the CI environment.<br><br><b><i>--branch</i> <I>BRANCH</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the branch being built/tested. If <i>--hash</i> or <i>--checkin</i> is not provided, the CI result will be linked to the tip of this branch.<br><br><b><i>--checkin</i> <I>UUID</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Synonym for <i>--hash</i>, specifying the check-in UUID. Use either <i>--hash</i> or <i>--checkin</i>.<br><br><b><i>--desc</i> <I>TEXT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Adds an optional short description or message for the CI result, often summarizing the outcome.<br><br><b><i>--ci-name</i> <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A unique identifier for the CI system or workflow that produced the result (e.g., 'Jenkins-Project-X', 'GitHub-Actions-Lint').<br><br><b><i>--verbose</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, displaying more details about the command's execution and internal operations.<br><br><b><i>--repository</i> <I>FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the Fossil repository file. If omitted, the command attempts to find the repository in the current directory or parent directories.<br><br>


title: DESCRIPTION
content:
The <b>fossil-ci</b> command, usually invoked as <i>fossil ci</i>, is a subcommand of the Fossil SCM (Self-Contained Distributed Software Configuration Management System). Its primary purpose is to enable continuous integration (CI) systems to communicate build and test results back to the Fossil repository. When a CI job completes, <b>fossil-ci</b> is used to record the status (e.g., success, failure, pending), associate it with a specific check-in, and optionally provide a URL to the CI job's output and a descriptive tag. This allows developers to see the CI status directly within the Fossil repository's web interface, providing immediate feedback on the health of the codebase.


title: CAVEATS
content:
The <b>fossil-ci</b> command expects to be run within a Fossil repository clone or with the <i>--repository</i> option pointing to a valid repository file. It requires appropriate write permissions to record CI events. It's crucial for CI systems to correctly identify the check-in UUID (via <i>--hash</i> or <i>--checkin</i>) to ensure CI results are associated with the precise code version. Incorrect usage might lead to CI status not being displayed or being displayed for the wrong commit. The command generally returns a non-zero exit code on failure to record the CI status, which CI systems can use to determine script success.


title: USAGE IN CI WORKFLOWS
content:
Typically, a CI script will check out a Fossil repository, perform build and test steps, and then invoke <b>fossil ci</b> to report the outcome before cleanup. For example, after a successful build, a script might run: <br><code>fossil ci --status ok --tag "ci/build/linux" --url "$CI_JOB_URL" --hash "$FOSSIL_COMMIT_UUID" --ci-name "MyBuildSystem"</code><br>This integrates the CI status seamlessly into Fossil's built-in web interface, allowing anyone browsing the repository to see the health of specific check-ins without leaving the Fossil UI.


title: INTEGRATION WITH FOSSIL UI
content:
The CI status recorded by <b>fossil-ci</b> is prominently visible in the Fossil web UI. For instance, on the timeline or individual check-in pages, entries that have associated CI results will often display a distinctive icon (e.g., a green checkmark for 'ok', a red X for 'fail') indicating their build status. Clicking on these icons typically leads to the URL provided by the <i>--url</i> option, directing users to the detailed CI job output.


title: HISTORY
content:
The continuous integration features, including the <b>fossil ci</b> command, were introduced in Fossil SCM to provide native support for tracking build and test statuses directly within the repository. This functionality enhances Fossil's self-contained nature by allowing CI results to be stored and viewed alongside the source code, tickets, and wiki, rather than relying solely on external CI dashboards. Its development reflects the growing importance of automated testing and build processes in modern software development workflows, making Fossil a more comprehensive SCM solution for projects utilizing CI.


title: PARAMETERS
content:
<b><B>-m</B> <I>MESSAGE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the commit message directly on the command line. This is the most common way to provide the required check-in description.<br><br><b><B>-F</B> <I>FILENAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads the commit message from the specified <I>FILENAME</I>. Useful for longer messages or when scripting commits.<br><br><b><B>--branch</B> <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates a new branch named <I>NAME</I> at the point of this check-in. If the branch already exists, it is reused.<br><br><b><B>--tag</B> <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies a tag named <I>NAME</I> to the newly created check-in. This allows for marking significant points in the repository history, such as releases.<br><br><b><B>--no-case-check</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables the check for case-insensitivity conflicts in filenames. Use with caution, as it can lead to issues on case-sensitive file systems.<br><br><b><B>--squash</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Attempts to combine the current commit with the previous one. This modifies the history and should be used carefully.<br><br><b><B>--allow-same-content</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Permits committing a file even if its content is identical to its previous version in the repository. By default, Fossil optimizes by not committing identical content.<br><br><b><B>--add</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically adds any new, untracked files in the working directory to the commit. This is equivalent to running <I>fossil add</I> for all new files before committing.<br><br><b><B>--rm</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically removes any missing files from the commit that are present in the repository. This is equivalent to running <I>fossil rm</I> for all missing files before committing.<br><br><b><B>--verbatim</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents Fossil from normalizing the commit message (e.g., removing leading/trailing whitespace). The message is stored exactly as provided.<br><br>


title: DESCRIPTION
content:
The <I>fossil-commit</I> command is a fundamental operation within the Fossil SCM system, analogous to 'commit' in other version control systems like Git or Mercurial. It is used to permanently record changes from the local working directory into the Fossil repository. This includes modifications to existing files, the addition of new files (previously added using <I>fossil-add</I>), and the deletion of files (previously marked for removal using <I>fossil-rm</I>).<br><br>When executed, <I>fossil-commit</I> creates a new immutable 'check-in' (also known as a 'changeset') that encapsulates all the staged changes. Each check-in is uniquely identified and includes metadata such as the author, timestamp, and a mandatory commit message describing the changes. This command is an atomic operation, meaning all changes are recorded as a single unit, ensuring data integrity and consistency within the repository's history.


title: CAVEATS
content:
A commit message is mandatory; if not provided via <B>-m</B> or <B>-F</B>, Fossil will typically open an editor for input.<br>By default, <I>fossil-commit</I> only records changes to files that have been explicitly added (<I>fossil-add</I>) or marked for removal (<I>fossil-rm</I>). Untracked or modified but unstaged files will not be included unless <B>--add</B> or <B>--rm</B> options are used.<br>Committing changes does not automatically push them to a remote repository; a subsequent <I>fossil-push</I> command is required for synchronization.


title: TYPICAL WORKFLOW
content:
A common workflow involves: <br>1. Modifying existing files or creating new ones. <br>2. Using <I>fossil add</I> to stage new files or <I>fossil rm</I> to mark files for deletion. <br>3. Reviewing changes with <I>fossil status</I> or <I>fossil diff</I>. <br>4. Finally, executing <I>fossil commit</I> to record all staged changes into the repository.


title: CHECK-IN VS. COMMIT
content:
In Fossil's terminology, the result of a successful <I>fossil-commit</I> operation is often referred to as a 'check-in' or 'changeset'. These terms are largely synonymous with 'commit' in other VCS systems, representing a distinct, immutable snapshot of the repository at a specific point in time.


title: HISTORY
content:
The <I>fossil-commit</I> command is a core component of the Fossil SCM system, which was created by D. Richard Hipp, the author of SQLite, and first released in 2008. From its inception, Fossil was designed as a self-contained, lightweight, and single-executable distributed version control system. The 'commit' operation has been central to its workflow, reflecting the established practices of version control while integrating Fossil's unique features like built-in ticketing, wiki, and web interface. Its implementation emphasizes atomicity and immutability for repository history.


title: PARAMETERS
content:
<b><i>FILENAME...</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>One or more paths to files or directories</i> that are to be deleted from the working directory and marked for removal from the Fossil repository.<br><br><b><b>-R</b> <i>&lt;REPOSITORY&gt;</i> or <b>--repository</b> <i>&lt;REPOSITORY&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>path to the Fossil repository database</i> file on which the command should operate. If omitted, Fossil attempts to find a repository in the current directory or parent directories.<br><br><b><b>-f</b> or <b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces the deletion, even if the target file has <i>uncommitted local modifications</i>. Using this option will discard any unsaved changes to the file before deleting it.<br><br><b><b>-i</b> or <b>--ignore-missing</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses error messages if any specified <i>FILENAME</i> does not exist in the working directory or is not currently tracked by Fossil.<br><br><b><b>-n</b> or <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a <i>simulation</i> of the delete operation. It shows which files would be deleted without actually modifying the filesystem or the repository state.<br><br><b><b>--case-sensitive</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Applies <i>case-sensitive matching</i> when comparing <i>FILENAME</i> arguments, overriding the repository's default or the underlying filesystem's case sensitivity.<br><br><b><b>--exact</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Disables globbing for <i>FILENAME</i> arguments, treating them as <i>literal file paths</i> rather than patterns.<br><br><b><b>--glob</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interprets <i>FILENAME</i> arguments as <i>glob patterns</i> (e.g., <i>*.txt</i>) to match multiple files, which is often the default behavior but can be explicitly enabled.<br><br>


title: DESCRIPTION
content:
The <i>fossil delete</i> command is a fundamental utility within the Fossil SCM (Self-Contained Distributed Software Configuration Management) system, designed to manage the removal of files from a project. Its primary function is to remove one or more specified <i>FILENAME</i>s from both the working directory and to mark them for deletion within the Fossil repository's version control. <br><br>Unlike a simple operating system's <i>rm</i> command, <i>fossil delete</i> performs a crucial dual role: it physically removes the file from your local filesystem and, more importantly, it informs Fossil that these files are no longer part of the project's tracked history. This action stages the deletion, meaning the removal is noted by Fossil and will be permanently recorded in the repository only upon the next <i>fossil commit</i>. This staging mechanism provides a safety net, allowing users to review or undo the deletion before it becomes a permanent part of the project's version history. <br><br>The command is essential for maintaining a clean and accurate project structure, ensuring that obsolete or unwanted files are properly removed from source control, reflecting the project's current state. It intelligently handles various scenarios, such as preventing deletion of modified files unless explicitly forced, and can be configured to ignore missing files, making it robust for scripting and automated workflows.


title: CAVEATS
content:
Files are marked for deletion in the repository, but the deletion is only permanent after a <i>fossil commit</i>. <br>If not committed, the deletion can be easily undone using <i>fossil undo</i>. <br>Using the <b>-f</b> or <b>--force</b> option will discard any local uncommitted changes to the file, so use with caution.


title: STAGING DELETIONS
content:
Deleting a file with <i>fossil delete</i> doesn't immediately remove it from the repository's historical record. Instead, it <i>stages</i> the deletion for the next commit. This crucial feature provides a safety net, allowing users to review the planned removal, potentially revert the action, or amend the commit before the file's deletion becomes a permanent part of the current branch's history.


title: DIFFERENCE FROM 'RM'
content:
The standard Linux <i>rm</i> command only removes files from the filesystem. In contrast, <i>fossil delete</i> performs a dual action: it removes the file from the filesystem <i>and</i>, critically, informs the Fossil SCM system that this file should no longer be tracked. Simply using <i>rm</i> on a tracked file would leave it as a 'missing' file in Fossil's view, requiring further manual intervention to remove it from version control.


title: HISTORY
content:
Fossil SCM, created by D. Richard Hipp (also known for SQLite), was designed with a focus on simplicity, self-containment, and reliability. The <i>fossil delete</i> command has been an integral part of Fossil's core file management capabilities since its early versions, reflecting Fossil's philosophy of explicit version control actions rather than implicit tracking, ensuring developers have clear control over their project's file lifecycle.


title: PARAMETERS
content:
<b>--dry-run | -n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a trial run without making any actual changes. This option displays what files would be forgotten, but does not modify the manifest or the filesystem.<br><br><b>--hard | -H</b><br>&nbsp;&nbsp;&nbsp;&nbsp;In addition to forgetting the files from the repository's manifest, this option also removes the specified files from the local working directory on disk. This effectively makes <b>fossil forget --hard</b> behave identically to <b>fossil rm</b>.<br><br>


title: DESCRIPTION
content:
The <b>fossil-forget</b> command is an essential tool within the <I>Fossil SCM</I> (Source Code Management) system, designed to cease tracking one or more files in the repository's manifest without removing them from your local working directory. It marks specified files for removal from the project's version control oversight. This operation is <I>staged</I> and only becomes permanent in the repository's history after a subsequent <b>fossil commit</b> command. This command is particularly useful for rectifying accidental additions of files, or for gracefully untracking files that are no longer considered part of the project's source code but should remain accessible in the local workspace (e.g., temporary build artifacts, local configuration files, or user-specific settings). By default, <b>fossil-forget</b> ensures the physical file remains untouched on your disk, providing flexibility to manage it independently or to add its pattern to the <I>.fossil-settings/ignore-glob</I> file for future automatic exclusion from tracking.


title: CAVEATS
content:
Using <b>fossil forget</b> only stages the untracking action; a subsequent <b>fossil commit</b> is required to make the change permanent in the repository's history. <br>By default, <b>fossil forget</b> does NOT delete files from your local disk. If you wish to remove them from disk as well, use the <b>--hard</b> option. <br>Once a file is forgotten and committed, it will no longer be tracked in new check-ins from that point forward, though its history prior to the forget operation remains accessible.


title: STAGING OPERATION
content:
The <b>fossil forget</b> command operates as a <I>staging</I> operation. It prepares the list of files to be untracked for the next commit. The change is not permanent in the repository until you explicitly run <b>fossil commit</b>. Until then, you can revert the 'forget' action by simply re-adding the file using <b>fossil add</b>, or by reverting your changes.


title: IGNORING VS. FORGETTING
content:
It's important to distinguish between 'forgetting' a file and 'ignoring' one. <b>fossil forget</b> removes a file that <I>was</I> previously tracked. To prevent <I>new</I> or existing untracked files from ever being added to version control, you should define patterns in the <I>.fossil-settings/ignore-glob</I> file (or similar global ignore configurations). This helps maintain a clean working directory status and prevents accidental additions of transient files.


title: HISTORY
content:
Fossil SCM, developed by D. Richard Hipp (the creator of SQLite), emerged as a single, self-contained executable integrating version control, bug tracking, wiki, and forum functionalities. Its design emphasizes simplicity, reliability, and ease of deployment. The inclusion of the <b>forget</b> command, distinct from a direct file deletion, reflects a deliberate design principle common in modern SCMs (like Git's <b>rm --cached</b>). This separation allows developers fine-grained control over their working directory, enabling them to untrack files from the version control system without necessarily losing their local copies. This flexibility is key to managing project artifacts efficiently, especially in scenarios where certain files are generated or used locally but should not be part of the shared repository history.


title: PARAMETERS
content:
<b><code><b>-A</b></code>, <code><b>--admin-user</b></code> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the administrator user's name for the new repository. If not provided, the command prompts for it.<br><br><b><code><b>-D</b></code>, <code><b>--admin-pass</b></code> <i>PASSWORD</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the administrator user's password. If not provided, the command prompts for it.<br><br><b><code><b>-F</b></code>, <code><b>--force</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites an existing repository file if it already exists at the specified path, without prompting for confirmation.<br><br><b><code><b>-h</b></code>, <code><b>--help</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message and exits.<br><br><b><code><b>-k</b></code>, <code><b>--no-fsck</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Skips the initial integrity check (fsck) after repository creation. Use with caution as it bypasses a verification step.<br><br><b><code><b>-u</b></code>, <code><b>--user</b></code> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the default user associated with initial check-ins for the new repository.<br><br><b><code><b>--project-name</b></code> <i>NAME</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assigns a human-readable name to the new project, which can be displayed in the Fossil web UI.<br><br><b><code><b>--template</b></code> <i>TEMPLATE_REPO</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Initializes the new repository using a pre-existing template repository, copying its initial structure and settings.<br><br><b><code><b>--create-directory</b></code></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Creates the parent directory for the repository file if it does not already exist during initialization.<br><br>


title: DESCRIPTION
content:
<code><b>fossil init</b></code> is the foundational command for starting a new project managed by the Fossil SCM system. It creates an empty Fossil repository file, which is a single, self-contained SQLite database. This database will store all project data, including source code versions, commit history, wiki content, ticketing system, forum discussions, and project timeline.<br><br>Unlike other SCMs that might scatter data across <code><i>.git</i></code> or <code><i>.svn</i></code> directories, Fossil consolidates everything into one file, making it exceptionally portable and easy to back up. When executed, <code><b>fossil init</b></code> prompts for an administrator username and password (unless provided via options), which are essential for managing the new repository. This command is typically the first step before adding files, making commits, or sharing the repository. The resulting repository file can be directly used for local operations or served via HTTP for remote access.


title: CAVEATS
content:
If the target <code><i>REPOSITORY_FILENAME</i></code> already exists, <code><b>fossil init</b></code> will abort unless the <code><b>-F</b></code> or <code><b>--force</b></code> option is used. Using <code><b>--force</b></code> will irrevocably delete and overwrite the existing repository. The administrator username and password are critical for future repository management; choose strong credentials and remember them.


title: REPOSITORY STRUCTURE
content:
A Fossil repository is fundamentally a single SQLite database file (e.g., <code><i>project.fossil</i></code>). This file contains all versions of all files, the complete commit history, wiki pages, forum posts, tickets, and user accounts. This unique design greatly simplifies backup, migration, and general management, as the entire project history and data reside within one portable file.


title: ADMINISTRATOR CREDENTIALS
content:
Upon initialization, <code><b>fossil init</b></code> requires an administrator username and password. These credentials are vital for managing repository settings, user accounts, and permissions within the Fossil web interface. If not provided via the <code><b>-A</b></code> or <code><b>-D</b></code> command-line options, Fossil will interactively prompt the user to enter them.


title: HISTORY
content:
Fossil SCM was created by D. Richard Hipp, the author of SQLite, in 2007. Designed to be simple, self-contained, and reliable, <code><b>fossil init</b></code> has been a core command since its inception. It embodies Fossil's design philosophy of a single-file repository that encapsulates all project data, including source control, bug tracking, wiki, and forum functionalities, offering a unique and robust approach to software configuration management.


title: PARAMETERS
content:
<b><I>REPOSITORY_FILE</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path and filename for the new Fossil repository. This file will be created and must not already exist.<br><br><b>--admin-user <I>USERNAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the initial administrator username for the repository's web interface. If omitted, Fossil will prompt for one or use a default if running non-interactively.<br><br><b>--project-name <I>NAME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial project name. This name is displayed in the repository's web interface.<br><br><b>--description <I>TEXT</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides an initial description for the project, which is also visible in the web interface.<br><br><b>--autoonline</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically enables the 'autoonline' setting for the new repository, facilitating automatic synchronization with remote repositories.<br><br><b>--set-date <I>DATETIME</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the initial date and time for the repository. If not specified, the current system time is used.<br><br>


title: DESCRIPTION
content:
The <I>fossil-new</I> command is used to create an empty, self-contained Fossil SCM repository file. This command is the essential first step for initiating a new project or managing an existing one under Fossil's version control system. Unlike other SCMs that might create a directory structure, <I>fossil-new</I> generates a single SQLite database file that will store all project history, branches, tags, as well as integrated features like the project wiki, bug tracking system, and forum.<br><br>The repository file is designed to be highly portable and robust. After creation, this file serves as the central hub for all version control operations. Users can then 'open' this repository to begin adding source code, commits, and interacting with Fossil's comprehensive web interface.


title: CAVEATS
content:
The <I>fossil-new</I> command will not overwrite an existing file; it will report an error and exit if the specified <I>REPOSITORY_FILE</I> already exists. Users must have appropriate write permissions in the target directory to create the repository file. This command only creates the repository file itself, not a working directory or checkout; additional commands like 'fossil open' or 'fossil clone' are needed to start working with project files.


title: DEFAULT ADMIN USER PROMPT
content:
If the <I>--admin-user</I> option is not provided, <I>fossil-new</I> will interactively prompt the user to enter an administrator username and password unless running in a non-interactive environment.


title: REPOSITORY CONTENTS
content:
The newly created repository file is an empty Fossil database. It contains only the necessary schema and initial configuration; no project files or source code are present until they are added and committed using subsequent Fossil commands.


title: HISTORY
content:
Fossil SCM was created by D. Richard Hipp, the author of SQLite, and first released in 2007. The <I>fossil-new</I> command has been a fundamental part of Fossil since its inception, serving as the primary method for initializing new projects. Its design reflects Fossil's core philosophy of simplicity and self-containment, with the entire repository residing in a single, robust SQLite database file. The command's functionality has remained consistent, underscoring its foundational role in the Fossil ecosystem.


title: PARAMETERS
content:
<b><i>FILENAME</i>...</b><br>&nbsp;&nbsp;&nbsp;&nbsp;One or more paths to files or directories to be marked for removal from the repository. If a directory is specified, all tracked files within it are recursively marked for removal.<br><br><b><b>--if-exists</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not generate an error if a named file or directory does not currently exist in the repository.<br><br><b><b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show which files would be removed without actually performing the operation or modifying the repository.<br><br><b><b>--repository </b><i>FILE</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the Fossil repository database file to use instead of the one found in the current directory or specified by the FOSSIL_REPOSITORY environment variable.<br><br>


title: DESCRIPTION
content:
The <b>fossil-rm</b> command is used to mark one or more files or directories for deletion from the Fossil SCM repository. This operation stages the files for removal, similar to <b>git rm</b> or <b>svn delete</b> in other version control systems. The actual deletion from the repository's history only takes effect after a subsequent <b>fossil commit</b> operation. By default, <b>fossil-rm</b> only marks the file for deletion within Fossil; it does <i>not</i> remove the file from the local working directory. It is crucial to understand that files marked for removal with <b>fossil-rm</b> are still part of the repository's history and can be recovered using <b>fossil undo</b> or by checking out an earlier version.


title: CAVEATS
content:
<b>fossil-rm</b> only marks files for deletion; they are not actually removed from the repository's history until a subsequent <b>fossil commit</b> is performed.<br><br>By default, <b>fossil-rm</b> does <i>not</i> delete the file from the local working directory. You must manually remove it using <b>rm</b> or similar if you wish to clear it from your filesystem.<br><br>Removed files are still part of the repository's historical record and can be retrieved later using commands like <b>fossil checkout</b> or <b>fossil undo</b>.


title: WORKING DIRECTORY IMPACT
content:
Unlike some other version control systems where the remove command might also delete the file from the local filesystem, <b>fossil-rm</b> by default only stages the deletion for the repository. This distinction is important for users transitioning from other SCMs.


title: RECURSIVE REMOVAL
content:
When a directory name is specified as an argument, <b>fossil-rm</b> recursively marks all tracked files within that directory for removal from the repository.


title: HISTORY
content:
<b>fossil-rm</b> is an integral command within the Fossil SCM system, which was created by D. Richard Hipp (also known for SQLite) and first publicly released in 2007. It provides essential version control functionality for managing file lifecycle within Fossil repositories. Its design aligns with Fossil's overall philosophy of being a simple, self-contained, and single-file executable for source code management.


title: SYNOPSIS
content:
<b>fping</b> [<i>options</i>] [<i>target_hosts</i>...]<br><b>fping</b> [<i>options</i>] <b>-f</b> <i>file_with_hosts</i><br><b>fping</b> [<i>options</i>] <b>-g</b> <i>start_ip end_ip</i> | <i>CIDR_notation</i>


title: PARAMETERS
content:
<b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only systems that are alive and reachable.<br><br><b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display target IP addresses instead of hostnames in the output.<br><br><b><b>-b</b> <i>&lt;length&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the size of the ping data payload in bytes (default: 56).<br><br><b><b>-c</b> <i>&lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of ICMP echo requests to send to each target (default: 1).<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Read list of target hosts from a specified file instead of command line arguments.<br><br><b><b>-g</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Generate target IP addresses from a given start/end IP range or CIDR block (e.g., <i>192.168.1.0/24</i>).<br><br><b><b>-i</b> <i>&lt;interval&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the minimum interval (in milliseconds) between sending packets to any target (default: 10ms).<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Loop indefinitely, continuously pinging targets until interrupted.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display IP addresses instead of hostnames in the output. This can speed up execution by avoiding DNS lookups.<br><br><b><b>-q</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Quiet mode; suppress output for hosts that respond. Only unresponding hosts are displayed.<br><br><b><b>-r</b> <i>&lt;retries&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Number of times to retry sending a packet to a target if no reply is received (default: 3).<br><br><b><b>-s</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display summary statistics at the end of execution, including count of alive/unreachable hosts.<br><br><b><b>-t</b> <i>&lt;timeout&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Set the initial timeout (in milliseconds) for a host reply. If no reply is received within this time, the host is considered unreachable (default: 500ms).<br><br><b><b>-u</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show only systems that are unreachable.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provide verbose output, showing more details about the ping process and results.<br><br>


title: DESCRIPTION
content:
<i>fping</i> is a powerful command-line utility designed for rapidly sending ICMP echo requests (pings) to multiple network hosts. Unlike the traditional <i>ping</i> command, which typically processes one host at a time, <i>fping</i> operates in a highly efficient, parallel, and round-robin fashion. This allows it to check the reachability of a large number of hosts much faster by sending packets to the next host as soon as a reply is received or a timeout occurs for the current host.<br><br>It's widely used by network administrators for quick network scanning, host discovery, and monitoring host availability. <i>fping</i> supports various output formats, including summarized statistics, and can read target host lists from standard input or a file, making it highly scriptable for automated network checks. Its capabilities make it an invaluable tool for maintaining and troubleshooting network infrastructure.


title: CAVEATS
content:
<i>fping</i> requires root privileges or the <b>CAP_NET_RAW</b> capability to create raw ICMP sockets. Improper use on large network ranges can generate significant network traffic. DNS lookups (when not using <b>-n</b>) can slow down the process considerably.


title: EXIT STATUS
content:
<i>fping</i> provides meaningful exit codes for scripting and automation:<br><b>0</b>: All target hosts are alive.<br><b>1</b>: Some target hosts are alive, while others are unreachable.<br><b>2</b>: All target hosts are unreachable.<br><b>3</b>: A fatal error occurred (e.g., incorrect usage, permission issues).


title: PERMISSIONS
content:
Due to its use of raw sockets for ICMP, <i>fping</i> typically needs root privileges or the <b>CAP_NET_RAW</b> Linux capability. This capability can be set with: <i>sudo setcap cap_net_raw+ep /usr/sbin/fping</i> (note: the path to fping may vary on different systems).


title: HISTORY
content:
<i>fping</i> was initially written by Roland Schemers in 1992 as a faster alternative to the standard <i>ping</i> utility for scanning multiple hosts. It introduced the concept of sending multiple pings in a round-robin fashion, significantly improving efficiency for network discovery and monitoring tasks. Over the years, it has been maintained and improved by various contributors, solidifying its role as a fundamental tool for network administrators.


title: SYNOPSIS
content:
While `<i>fprind</i>` is not a direct command, it represents the `<b>fprintd</b>` daemon and its associated client utilities. Common commands used to interact with the fingerprint system are:<br>`<b>fprintd-enroll</b> [<i>OPTIONS</i>] <i>DEVICE_ID</i><br>`<b>fprintd-verify</b> [<i>OPTIONS</i>] <i>DEVICE_ID</i><br>`<b>fprintd-list</b><br>`<b>fprintd-delete</b> <i>DEVICE_ID</i><br>These commands interact with the running `<b>fprintd</b>` daemon to perform specific fingerprint-related tasks, where `<i>DEVICE_ID</i>` is the identifier of the fingerprint device.


title: PARAMETERS
content:
<b>-h, --help</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits for the specific `<b>fprintd</b>` client command (e.g., `<b>fprintd-enroll</b>`).<br><br><b>-f, --finger <finger></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which finger to enroll or verify (e.g., `<b>left-thumb</b>`, `<b>right-index-finger</b>`). For `<b>fprintd-enroll</b>`, if not specified, it will prompt interactively. For `<b>fprintd-verify</b>`, it limits the verification to a specific finger.<br><br><b>-u, --user <username></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user for whom to enroll or verify the fingerprint. Defaults to the current user.<br><br><b>-p, --prompt</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces interactive prompting for the finger to use during enrollment with `<b>fprintd-enroll</b>`.<br><br><b>-r, --retrieve</b><br>&nbsp;&nbsp;&nbsp;&nbsp;For `<b>fprintd-enroll</b>`, allows re-enrolling an existing fingerprint for a user without prior deletion (requires confirmation). Not applicable to `<b>fprintd-verify</b>`.<br><br>


title: DESCRIPTION
content:
The term `<i>fprind</i>` often refers to the `<b>fprintd</b>` system daemon, which provides a standardized D-Bus interface for interacting with fingerprint readers on Linux systems. It is not a direct command-line utility itself, but rather a background service. Applications, and more commonly, user-facing client commands like `<b>fprintd-enroll</b>` and `<b>fprintd-verify</b>`, communicate with `<b>fprintd</b>` to manage fingerprint data, including enrolling new fingerprints and verifying existing ones. `<b>fprintd</b>` aims to abstract away the complexities of different fingerprint reader hardware, offering a unified way for the desktop environment, login managers, and other applications to use fingerprint authentication. This enables features such as logging into your desktop environment, authenticating `<b>sudo</b>` commands, or unlocking screens using your fingerprint.


title: CAVEATS
content:
The term `<i>fprind</i>` is not a standard Linux command. It is commonly a misspelling or an informal reference to the `<b>fprintd</b>` daemon and its associated client utilities like `<b>fprintd-enroll</b>` and `<b>fprintd-verify</b>`. Direct execution of `<b>fprind</b>` or `<b>fprintd</b>` (without specific arguments or as a service command) from the terminal will typically result in a "command not found" error or usage information for the daemon itself. Fingerprint functionality relies on `<b>fprintd</b>` being installed, running, and having compatible hardware.


title: PAM INTEGRATION
content:
`<b>fprintd</b>` integrates with the Pluggable Authentication Modules (PAM) framework through the `<b>pam_fprintd</b>` module. This allows system-wide authentication tasks, such as login (graphical or console), `<b>sudo</b>` command execution, or screen unlocking, to leverage fingerprint authentication. To enable this, `<b>pam_fprintd</b>` needs to be configured in the relevant PAM service files (e.g., `/etc/pam.d/sudo`, `/etc/pam.d/login`, `/etc/pam.d/gdm-password`). After configuration, users can authenticate using their enrolled fingerprints in addition to or instead of their traditional password.


title: HARDWARE SUPPORT
content:
The functionality of `<b>fprintd</b>` is dependent on the underlying `<b>libfprint</b>` library's support for specific fingerprint reader hardware. While `<b>libfprint</b>` supports a wide range of devices, not all fingerprint readers are supported out-of-the-box, particularly newer or proprietary models. Users should check `<b>libfprint</b>` documentation or community resources for compatibility with their specific device.


title: HISTORY
content:
The `<b>fprintd</b>` project emerged from the `<b>libfprint</b>` library, which was created to provide a generic, open-source library for accessing fingerprint readers. `<b>fprintd</b>` was developed to provide a standardized D-Bus interface on top of `<b>libfprint</b>`, making fingerprint authentication easily integratable into desktop environments and other applications, independent of the specific hardware or application framework. Its development aimed to bring robust and user-friendly fingerprint authentication to the Linux desktop, improving upon earlier, more fragmented solutions. It became a widely adopted solution for fingerprint support in many Linux distributions.


title: PARAMETERS
content:
<b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, providing more detailed information during operation.<br><br><b><b>-f</b>, <b>--foreground</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents the daemon from forking into the background, useful for debugging.<br><br><b><b>-d</b>, <b>--debug</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables debugging output, offering extensive diagnostic messages.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version information of the <i>fprintd</i> daemon.<br><br>


title: DESCRIPTION
content:
<i>fprintd</i> is the D-Bus system service that manages fingerprint readers and operations on Linux. It provides a standardized interface for applications and PAM modules (like <i>pam_fprintd</i>) to interact with various fingerprint hardware devices. This service handles tasks such as enrolling new fingerprints, verifying existing fingerprints, deleting enrolled prints, and managing a list of enrolled users.<br><br>By centralizing these operations, <i>fprintd</i> abstracts away the complexities of different fingerprint hardware, offering a unified API for biometric authentication. It typically runs in the background as a system service, listening for D-Bus requests from clients that need to perform fingerprint-related actions, enhancing system security and user convenience.


title: CAVEATS
content:
Hardware compatibility relies heavily on the underlying <i>libfprint</i> library, which might not support all fingerprint readers, particularly newer or proprietary models. While <i>fprintd</i> aims for secure biometric authentication, overall system security also depends on the integrity of the operating system and the hardware. Sensitive fingerprint data must be handled with care.


title: D-BUS INTERFACE
content:
<i>fprintd</i> exposes a well-defined D-Bus interface, typically under the service name <b>net.reactivated.fprint</b>. This interface allows other processes, such as desktop environments, login managers (like GDM), and command-line tools, to communicate with the service and perform fingerprint-related operations.


title: USER INTERACTION
content:
Most user interaction with <i>fprintd</i> is indirect. Users rarely invoke <i>fprintd</i> directly from the command line. Instead, they interact with higher-level applications (e.g., graphical user interface settings panels) or PAM modules (e.g., during login or sudo prompts) that utilize <i>fprintd</i>'s D-Bus API to manage and use fingerprints.


title: HISTORY
content:
<i>fprintd</i> is a key component of the broader <i>libfprint</i> project, which was initiated to provide a free and open-source library for fingerprint reader support on Linux. Its development aimed to standardize fingerprint integration across various Linux distributions and desktop environments, moving away from fragmented, hardware-specific solutions. It has become a foundational element for biometric authentication in modern Linux systems since its inception.


title: SEE ALSO
content:
libfprint(7), pam_fprintd(8), fprintd-enroll(1), fprintd-verify(1), fprintd-delete(1), systemd(1), dbus-daemon(1)


title: SYNOPSIS
content:
<i>fprintd-delete</i> [<i>OPTIONS</i>] [<i>FINGER_ID</i>]<br><i>fprintd-delete</i> <b>--all</b> [<i>OPTIONS</i>]


title: PARAMETERS
content:
<b><b>-u</b>, <b>--user</b> <i>USER</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user whose fingerprints are to be deleted. If omitted, the command operates on the fingerprints of the current user.<br><br><b><i>FINGER_ID</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The unique identifier of the specific fingerprint to be deleted. If this is omitted and <b>--all</b> is not used, the command may list available fingerprints and prompt for selection.<br><br><b><b>--all</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Deletes all enrolled fingerprints for the specified user (or the current user if <b>--user</b> is not provided).<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message and exits.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows version information and exits.<br><br>


title: DESCRIPTION
content:
<i>fprintd-delete</i> is a command-line utility for managing biometric data within the <i>fprintd</i> (Fingerprint Daemon) framework. It allows users or administrators to securely remove previously enrolled fingerprints from the system. This command is crucial for maintaining privacy, enhancing security by removing outdated or compromised prints, or simply reconfiguring biometric authentication. It supports deleting specific fingerprints by their ID or removing all enrolled prints for a specified user. Proper permissions are required to operate this command, especially when managing fingerprints for users other than the current one.


title: CAVEATS
content:
<ul><li><b>Permissions:</b> Deleting fingerprints for other users typically requires root privileges (e.g., using <code>sudo</code>).</li><li><b>Irreversible:</b> Once a fingerprint is deleted, it cannot be recovered. It must be re-enrolled using <i>fprintd-enroll</i>.</li><li><b>Service Status:</b> The <i>fprintd</i> daemon must be running for this command to function correctly.</li><li><b>Fingerprint IDs:</b> The <i>FINGER_ID</i> argument might be session-specific. It is generally safer to use the interactive prompt or the <b>--all</b> option to avoid errors due to changing IDs after reboots or service restarts.</li></ul>


title: INTERACTIVE DELETION
content:
If no <i>FINGER_ID</i> is provided and <b>--all</b> is not used, <i>fprintd-delete</i> may prompt the user to select which fingerprint to delete from a list of currently enrolled prints, providing a user-friendly way to manage individual prints.


title: SECURITY IMPLICATIONS
content:
Regularly deleting old or unused fingerprints is a good security practice, especially if a fingerprint sensor is replaced or if there's any concern about the integrity of biometric data. This helps minimize the attack surface related to stored biometric identifiers.


title: HISTORY
content:
The <i>fprintd</i> project, which includes <i>fprintd-delete</i>, was developed to standardize fingerprint reader support and integrate biometric authentication seamlessly into Linux desktop environments and system-wide authentication. It provides a common API for different fingerprint hardware and a daemon to manage enrolled prints, addressing the previous fragmentation in Linux fingerprint support.


title: PARAMETERS
content:
<b><b>-f</b>, <b>--finger</b> <I>finger_name</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies which finger to enroll (e.g., 'left-thumb', 'right-index', 'left-middle'). This helps label the enrolled fingerprint for easier management.<br><br><b><b>-u</b>, <b>--user</b> <I>username</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the user account for which the fingerprint should be enrolled. If omitted, the command typically defaults to the current logged-in user.<br><br><b><b>-d</b>, <b>--device</b> <I>device_path</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects a specific fingerprint device to use if multiple are available. The path can usually be obtained from <b><I>fprintd-list-devices</I></b>.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the verbosity of the output, displaying more detailed information about the enrollment process, which can be useful for debugging.<br><br><b><b>--force</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Overwrites any existing fingerprint data for the specified finger and user without prompting for confirmation. Use with caution.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a brief help message including usage instructions and a list of available options.<br><br>


title: DESCRIPTION
content:
<br><b><I>fprintd-enroll</I></b> is a command-line utility used to enroll a new fingerprint into the <I>fprintd</I> (Fingerprint Daemon) service. It acts as an interface between the user and the daemon, facilitating the capture of biometric data from a connected fingerprint scanner. During the enrollment process, the user is typically prompted to repeatedly place or swipe their finger on the sensor until sufficient data is collected for accurate and reliable recognition.<br><br>This tool is fundamental for setting up biometric authentication on Linux systems, enabling users to log in, unlock their screen, or perform privileged operations using their enrolled fingerprints instead of traditional password-based authentication. It ensures the captured fingerprint data is securely processed, stored, and managed by the <I>fprintd</I> daemon for future verification.


title: CAVEATS
content:
<b><I>fprintd-enroll</I></b> requires the <b><I>fprintd</I></b> (Fingerprint Daemon) service to be running and properly configured.<br>Enrolling fingerprints, especially for other users or for system-wide authentication, typically requires elevated privileges (e.g., root access or appropriate Polkit authorization).<br>The success and quality of enrollment are highly dependent on the specific fingerprint sensor hardware and the installed <b><I>libfprint</I></b> drivers.<br>User interaction (repeatedly touching/swiping the finger) is mandatory throughout the enrollment process.


title: INTERACTIVE ENROLLMENT PROCESS
content:
The command is highly interactive. Once executed, it will guide the user through a series of steps, prompting them to place their finger on the scanner multiple times from different angles until enough data is captured to create a comprehensive biometric template.


title: PERMISSIONS AND AUTHENTICATION
content:
To enroll a fingerprint, especially for another user or if not running as root, a Polkit authentication prompt will typically appear. This prompt requires the user to authenticate themselves (e.g., with their password) to grant <b><I>fprintd-enroll</I></b> the necessary privileges to modify fingerprint data managed by the daemon.


title: HISTORY
content:
<b><I>fprintd-enroll</I></b> is an integral part of the <b><I>fprintd</I></b> project, which was initiated to provide a standardized D-Bus interface for various fingerprint readers on Linux and a robust framework for integrating biometric authentication into system services. Its development has progressed alongside the evolution of the underlying <b><I>libfprint</I></b> library, aiming to offer broader hardware support and improved reliability for fingerprint authentication on open-source platforms.


title: SEE ALSO
content:
<b><I>fprintd</I></b>(8), <b><I>fprintd-list-devices</I></b>(1), <b><I>fprintd-verify</I></b>(1), <b><I>fprintd-delete</I></b>(1), <b><I>pam_fprintd</I></b>(8)


title: DESCRIPTION
content:
<i>fprintd-list</i> is a command-line utility used to interact with the <b>fprintd</b> (Fingerprint Daemon) service. Its primary function is to display a list of all currently enrolled fingerprints on the system. It queries the <i>fprintd</i> daemon, which manages fingerprint reader devices and biometric data.<br><br>The output typically includes the user associated with the fingerprint and a unique identifier for the enrolled print. This command is useful for system administrators or users to verify which fingerprints are registered and to which accounts, especially when managing multiple users or ensuring that only authorized biometric data is stored. It doesn't modify data; it only provides an overview of the existing fingerprint enrollments.


title: CAVEATS
content:
<b>Caveats and Limitations:</b><br><i>fprintd-list</i> requires the <i>fprintd</i> service to be running.<br>To list fingerprints for all users, you often need root privileges (e.g., using <b>sudo</b>). Otherwise, it might only show prints for the current user.<br>The output identifiers (e.g., <i>user@0</i>, <i>user@1</i>) are internal to <i>fprintd</i> and may not directly map to a specific finger without prior knowledge.


title: PERMISSIONS
content:
Depending on your system's configuration and the specific version of <i>fprintd</i>, you might need <b>sudo</b> privileges to list fingerprints for all users. Without <b>sudo</b>, the command may only display enrollments associated with your current user account, or it might fail if permissions are too restrictive.


title: OUTPUT FORMAT
content:
The output typically shows the user and a unique identifier for each enrolled fingerprint, such as <i>username@0</i> or <i>username@1</i>. The number following the '<i>@</i>' symbol represents a unique identifier for a specific enrollment, which can correspond to different fingers or multiple enrollments of the same finger for that user.


title: HISTORY
content:
<i>fprintd</i> is part of the <i>libfprint</i> project, which aims to provide a standardized D-Bus interface for fingerprint readers on Linux. <i>fprintd-list</i> is one of the client utilities provided to interact with this daemon. It emerged as part of the broader effort to simplify fingerprint reader integration and management on Linux desktop environments, offering a consistent way to handle biometric authentication.


title: DESCRIPTION
content:
<i>fprintd-verify</i> is a command-line utility used to verify a user's fingerprint against previously enrolled biometric data. Part of the <i>fprintd</i> (fingerprint daemon) ecosystem, its primary function is to prompt the user to scan their finger and then compare the captured biometric information with the fingerprints already stored for that specific user. This tool is often invoked internally by authentication mechanisms, such as the <i>PAM</i> (Pluggable Authentication Modules) module <i>pam_fprintd</i>, to enable biometric login or sudo authentication. It exits with a status code of 0 on successful verification and a non-zero value on failure, making it suitable for scripting and integration into larger authentication workflows.


title: CAVEATS
content:
The <i>fprintd</i> daemon must be running for <i>fprintd-verify</i> to function. Users must have at least one fingerprint enrolled using <i>fprintd-enroll</i> prior to verification. Success depends on the quality of the fingerprint scan and the sensor hardware. Polkit policies may affect its execution permissions, potentially requiring administrative privileges for certain operations.


title: EXIT STATUS
content:
<i>fprintd-verify</i> returns an exit status of <b>0</b> on successful fingerprint verification, indicating that the scanned fingerprint matches an enrolled one. A non-zero exit status indicates failure, which could be due to a mismatch, a poor scan, or an error in communication with the <i>fprintd</i> daemon.


title: POLKIT INTEGRATION
content:
The command utilizes <i>Polkit</i> (formerly PolicyKit) for authentication and authorization. This means that appropriate Polkit rules must be in place to allow a user to perform fingerprint verification, especially in graphical environments or when escalated privileges are involved. The exact rules may vary depending on the system configuration.


title: HISTORY
content:
<i>fprintd-verify</i> is a component of the <i>libfprint</i> and <i>fprintd</i> project, which aims to provide a standardized framework for fingerprint reader support on Linux. Developed to integrate seamlessly with desktop environments like GNOME and KDE, the project allows users to utilize fingerprint authentication for system login, sudo, and other authentication prompts. The command's existence reflects the increasing adoption of biometric security features in mainstream Linux distributions.


title: PARAMETERS
content:
<b><b>-s</b>, <b>--src</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>source directory</i> for synchronization.<br><br><b><b>-d</b>, <b>--dst</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <i>destination directory</i> for synchronization.<br><br><b><b>-t</b>, <b>--type</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Defines the <i>transfer command</i> to use: <b>rsync</b>, <b>cp</b>, <b>mv</b>, or <b>tar</b>.<br><br><b><b>-o</b>, <b>--opts</b> <i>&lt;options&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Passes <i>additional options</i> to the underlying transfer command specified by <b>-t</b>. Use quotes for multiple options, e.g., '<b>-avz</b>'.<br><br><b><b>-n</b>, <b>--num</b> <i>&lt;num&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <i>number of parallel workers</i> or processes to use for transfers.<br><br><b><b>-r</b>, <b>--redo</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Forces <i>re-generation</i> of file lists and re-transfer, even if previous lists exist.<br><br><b><b>-X</b>, <b>--rm-ext</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes <i>extraneous files</i> from the destination directory <i>after</i> transfer. Use with extreme caution.<br><br><b><b>-R</b>, <b>--rm-first</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Removes <i>extraneous files</i> from the destination directory <i>before</i> transfer. Use with extreme caution.<br><br><b><b>-e</b>, <b>--exclude</b> <i>&lt;pattern&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<i>Excludes files or directories</i> matching the specified pattern from synchronization.<br><br><b><b>-E</b>, <b>--exclude-file</b> <i>&lt;file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Reads <i>exclusion patterns</i> from the specified file.<br><br><b><b>-D</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs a <i>test run</i> without making any actual changes or transfers.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Increases the <i>verbosity</i> of the output.<br><br><b><b>-W</b>, <b>--workdir</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a <i>working directory</i> for temporary files generated during the process. Defaults to <b>/tmp</b>.<br><br><b><b>-l</b>, <b>--list-only</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Only <i>generates file lists</i>; does not perform any actual transfers.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help message and exits.<br><br>


title: DESCRIPTION
content:
<i>fpsync</i> is a powerful and efficient command-line utility designed for synchronizing file systems, especially optimized for large directories containing millions of files. It is part of the <i>fpart</i> project and significantly differentiates itself from tools like <i>rsync</i> by leveraging parallelism in both the file listing/partitioning phase and the actual transfer phase.<br><br>Instead of generating a single, potentially huge, file list, <i>fpsync</i> dynamically partitions files into smaller, manageable chunks. These chunks are then processed and transferred in parallel by multiple worker processes, utilizing underlying tools such as <i>rsync</i>, <i>cp</i>, <i>mv</i>, or <i>tar</i> (often over SSH).<br><br>This parallel approach drastically reduces synchronization times for scenarios involving numerous small files, making it ideal for large-scale data migrations, incremental backups, or maintaining consistency across extensive datasets. It intelligently handles source and destination directories, offering flexible and robust synchronization strategies.


title: CAVEATS
content:
<i>fpsync</i> relies on other standard Linux utilities (<i>find</i>, <i>sort</i>, <i>rsync</i>, <i>cp</i>, <i>mv</i>, <i>tar</i>), which must be present on the system.<br>Parallelism can be resource-intensive, potentially consuming significant CPU, memory, and I/O. Tune the number of workers (<b>-n</b>) based on system resources.<br>The temporary working directory (specified by <b>-W</b> or defaulting to <b>/tmp</b>) can accumulate large temporary files, especially with many workers or huge datasets. Ensure sufficient disk space.<br>When using <b>tar</b> as a transfer type, <i>fpsync</i> does not preserve sparse files, hard links, or certain extended attributes as <i>rsync</i> might.<br>The <b>-R</b> and <b>-X</b> options (remove extraneous files) are powerful and potentially destructive; always perform a <b>--dry-run</b> first when using them.


title: HOW FPSYNC WORKS
content:
<i>fpsync</i> operates in two primary phases:<br>1.  <b>File Listing and Partitioning:</b> It first uses <i>fpart</i> (and internally <i>find</i>) to recursively list files in the source directory. Instead of one large list, <i>fpart</i> can partition these files into smaller, more manageable subsets based on size or number of files.<br>2.  <b>Parallel Transfer:</b> Once partitioned, <i>fpsync</i> dispatches these subsets to multiple worker processes (specified by <b>-n</b>). Each worker then independently executes the chosen transfer command (<b>rsync</b>, <b>cp</b>, <b>mv</b>, or <b>tar</b>) to synchronize its assigned subset of files to the destination. This parallel execution minimizes idle time and maximizes throughput.


title: CHOOSING A TRANSFER TYPE (<B>-T</B>)
content:
The <b>-t</b> option allows selection of the underlying transfer command:<br><ul><li><b>rsync:</b> The most common and feature-rich choice, preserving permissions, timestamps, and handling incremental updates efficiently. Supports remote transfers via SSH.<br><li><b>cp:</b> A simple copy command. Best for local transfers where advanced features are not needed.<br><li><b>mv:</b> Moves files rather than copies. Use with extreme caution as it removes files from the source.<br><li><b>tar:</b> Creates a tar archive of files and extracts them on the destination, often over SSH. Can be efficient for remote transfers but may have limitations compared to <i>rsync</i> regarding incremental updates or specific file attributes.


title: HISTORY
content:
<i>fpsync</i> was developed by Ganaël Laplanche as a key component of the <i>fpart</i> project. Its primary motivation was to overcome the performance limitations of traditional synchronization tools, particularly <i>rsync</i>, when confronted with extremely large numbers of small files. Traditional tools often struggle with the overhead of building a single, monolithic file list, which can become a significant bottleneck.<br><br><i>fpsync</i> was engineered to parallelize this process, dynamically partitioning file lists and distributing the transfer workload across multiple CPU cores or even different machines (via SSH for <i>rsync</i>/<i>tar</i> types). This design significantly accelerates synchronization operations for high-volume datasets, making it an essential tool for large-scale data migrations and backups in critical infrastructure environments.


title: PARAMETERS
content:
<b><i>-b, --bytes</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the amount of memory in bytes.<br><br><b><i>-k, --kilo</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the amount of memory in kilobytes (this is the default unit).<br><br><b><i>-m, --mega</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the amount of memory in megabytes.<br><br><b><i>-g, --giga</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the amount of memory in gigabytes.<br><br><b><i>-h, --human</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Show all output fields automatically scaled to the shortest three-digit unit and display unit suffixes (e.g., M, G, T). This is highly recommended for readability.<br><br><b><i>-t, --total</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display a line showing the total of physical and swap memory combined.<br><br><b><i>-s &lt;delay&gt;, --seconds &lt;delay&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Repeat the display every <i>delay</i> seconds. This allows for continuous monitoring.<br><br><b><i>-c &lt;count&gt;, --count &lt;count&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Update the display <i>count</i> times, then exit. Often used in conjunction with <i>-s</i>.<br><br><b><i>-w, --wide</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Wide output format. This can prevent truncation of numbers.<br><br><b><i>-o, --old</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't display the "buffers/cache" line. This option makes the output compatible with older versions of <b>free</b>.<br><br><b><i>-v, --version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br>


title: DESCRIPTION
content:
The <b>free</b> command in Linux is a utility used to display the total amount of free and used physical memory and swap space in the system. It provides a quick snapshot of the system's current memory status, which is crucial for monitoring performance and diagnosing memory-related issues. The command retrieves its information from the <i>/proc/meminfo</i> pseudo-filesystem, which is maintained by the Linux kernel.<br><br>Beyond just physical RAM and swap, <b>free</b> also reports on memory categorized as shared, buffers, and cache. Modern versions of <b>free</b>, especially when used with the <i>-h</i> (human-readable) option, include an "available" memory column. This column is particularly important as it attempts to show how much memory is available for new applications without needing to swap, taking into account reclaimable memory from caches and buffers. Understanding the output of <b>free</b> helps administrators and users gauge memory pressure, identify potential bottlenecks, and ensure optimal system operation.


title: CAVEATS
content:
One common misconception when interpreting <b>free</b> output, especially with older versions or without the <i>available</i> column, is that the <i>free</i> column alone represents all usable memory. Linux actively uses available RAM for disk caching (buffers and cache) to improve performance. This memory is not truly "used" in the sense that it's unavailable for applications; it can be quickly reclaimed if an application needs it.<br><br>The <i>available</i> column (introduced in Linux kernel 3.14 and visible with <b>free -h</b> on modern systems) provides a more accurate representation of how much memory is truly available for new application processes without swapping. Users should rely on the <i>available</i> column for a realistic view of usable memory.


title: UNDERSTANDING <B>FREE</B> OUTPUT COLUMNS
content:
The typical output of <b>free</b> includes several columns, each providing insight into memory usage:<br><br><b>total:</b> The total amount of installed physical memory (RAM) or swap space.<br><b>used:</b> The total amount of memory currently in use by the system, including applications, kernel, and buffers/cache.<br><b>free:</b> The amount of memory that is completely unused and immediately available.<br><b>shared:</b> Memory used by <i>tmpfs</i> (shared memory and RAM disks) and shared libraries.<br><b>buffers:</b> Memory used by kernel buffers, primarily for disk block I/O operations.<br><b>cache:</b> Memory used as page cache by the kernel for filesystem data (e.g., recently accessed files).<br><b>buff/cache:</b> (Often combined in newer versions) The sum of memory used for buffers and cache. This memory is generally reclaimable.<br><b>available:</b> (Modern <b>free</b> versions, especially with <i>-h</i>) An estimate of how much memory is truly available for starting new applications without swapping. This value considers both the <i>free</i> memory and memory that can be reclaimed from <i>buffers</i> and <i>cache</i> without significant performance penalties.


title: HISTORY
content:
The <b>free</b> command is a standard utility provided by the <i>procps</i> (or <i>procps-ng</i> for newer systems) package, which is a collection of utilities that provide system information from the <i>/proc</i> filesystem. Its origins trace back to the early days of Linux, relying on the kernel's <i>/proc/meminfo</i> interface for memory statistics.<br><br>A significant development in the command's evolution was the addition of the "available" memory field. Before its introduction, users often misinterpreted "free" memory as only the explicitly unused RAM, leading to confusion about why systems with large amounts of cached memory appeared to be "running out of memory." The "available" field, which accounts for reclaimable cache/buffer memory, was a crucial improvement in providing a more accurate and intuitive understanding of system memory availability, aligning <b>free</b>'s output with modern Linux memory management practices.


title: SYNOPSIS
content:
The <I>freeipmi</I> project provides a suite of independent command-line tools. The general syntax for using these tools is:<br><B>tool_name</B> [<I>global_options</I>] [<I>tool_specific_options</I>] [<I>arguments</I>]<br><br>Commonly used tools within the suite include:<br><B>ipmi-sensors</B> [<I>options</I>]<br><B>ipmi-sel</B> [<I>options</I>]<br><B>ipmi-chassis</B> [<I>options</I>]<br><B>bmc-info</B> [<I>options</I>]


title: PARAMETERS
content:
<b><B>-h</B>, <B>--help</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the specific tool being used.<br><br><b><B>-V</B>, <B>--version</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows the version of the <B>freeipmi</B> suite.<br><br><b><B>-D</B>, <B>--debug</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose debug output, useful for troubleshooting.<br><br><b><B>-H</B> <I>&lt;hostname&gt;</I>, <B>--hostname=</B><I>&lt;hostname&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the remote host IP address or hostname for LAN-based IPMI communication.<br><br><b><B>-U</B> <I>&lt;username&gt;</I>, <B>--username=</B><I>&lt;username&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the username for authentication when connecting to the BMC.<br><br><b><B>-P</B> <I>&lt;password&gt;</I>, <B>--password=</B><I>&lt;password&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides the password for authentication when connecting to the BMC.<br><br><b><B>-l</B> <I>&lt;level&gt;</I>, <B>--level=</B><I>&lt;level&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the privilege level for the IPMI session (e.g., callback, user, operator, administrator).<br><br><b><B>-N</B>, <B>--lan</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the LAN interface for remote IPMI communication.<br><br><b><B>-I</B>, <B>--openipmi</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Uses the OpenIPMI Linux kernel driver interface for local IPMI communication.<br><br><b><B>-K</B>, <B>--kcs</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the Keyboard Controller Style (KCS) interface for local IPMI communication.<br><br><b><B>-S</B>, <B>--smbus</B></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Selects the SMBus interface for local IPMI communication.<br><br><b><B>-R</B> <I>&lt;seconds&gt;</I>, <B>--register-timeout=</B><I>&lt;seconds&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout in seconds for registering with the BMC over LAN.<br><br><b><B>-T</B> <I>&lt;seconds&gt;</I>, <B>--transaction-timeout=</B><I>&lt;seconds&gt;</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the timeout in seconds for individual IPMI transactions over LAN.<br><br>


title: DESCRIPTION
content:
<B>freeipmi</B> is an open-source, standards-compliant implementation of the Intelligent Platform Management Interface (IPMI) specification. It provides a robust suite of command-line tools for local and remote out-of-band management, monitoring, and control of IPMI-enabled hardware.<br><br>The suite includes utilities for tasks such as reading sensor data (temperature, voltage, fan speed), managing the System Event Log (SEL), retrieving Field Replaceable Unit (FRU) information, controlling chassis power, and performing raw IPMI commands. <B>freeipmi</B> supports various IPMI interfaces, including Keyboard Controller Style (KCS), SMBus, OpenIPMI (Linux kernel driver), and LAN (Remote Management). Its design emphasizes security, performance, and adherence to IPMI 1.5, 2.0, and DCMI standards, making it a powerful tool for system administrators and developers managing server infrastructure.


title: CAVEATS
content:
Using <B>freeipmi</B> requires hardware with a functioning and configured Baseboard Management Controller (BMC). For LAN communication, proper network connectivity and firewall rules must be established between the client system and the BMC. Users should exercise caution with sensitive authentication credentials (passwords) and avoid exposing them directly on the command line in scripts unless robust security measures are implemented. IPMI implementations can vary between hardware vendors, potentially leading to slight behavioral differences or compatibility quirks.


title: TOOLS OVERVIEW
content:
The <B>freeipmi</B> suite comprises numerous specialized tools, each designed for specific IPMI management tasks. Key utilities include <B>ipmi-sensors</B> for reading various sensor data (e.g., temperature, voltage, fan speed), <B>ipmi-sel</B> for managing the System Event Log (viewing, clearing entries), <B>ipmi-fru</B> for accessing Field Replaceable Unit information (e.g., serial numbers, manufacturing dates), <B>ipmi-chassis</B> for chassis control (like power on/off, reset), <B>bmc-info</B> for retrieving BMC details, and <B>ipmi-raw</B> for executing arbitrary raw IPMI commands. Other tools like <B>ipmi-config</B> and <B>ipmi-dcmi</B> provide advanced configuration and DCMI (Data Center Manageability Interface) functionalities, respectively.


title: IPMI INTERFACES
content:
<B>freeipmi</B> supports several communication interfaces to interact with the Baseboard Management Controller (BMC). <B>KCS</B> (Keyboard Controller Style) and <B>SMBus</B> are typically used for local, in-band communication directly via hardware registers. The <B>OpenIPMI</B> interface leverages the Linux kernel's <I>openipmi</I> driver, providing a robust local communication channel. For remote management, the <B>LAN</B> interface is used, enabling communication over a network using the IPMI-over-LAN protocol. Choosing the correct interface (specified by options like <B>-K</B>, <B>-S</B>, <B>-I</B>, or <B>-N</B>) is crucial for successful operation based on whether you're managing locally or remotely.


title: HISTORY
content:
The <B>freeipmi</B> project was initiated in 2004, aiming to provide a comprehensive, free, and open-source implementation of the IPMI standard. It was developed to offer a robust and secure alternative to existing proprietary and open-source IPMI tools, such as <I>ipmitool</I>, with a strong emphasis on adhering to IPMI specifications (1.5, 2.0, DCMI). Maintained as part of the GNU project, <B>freeipmi</B> has continuously evolved to support new IPMI features, improve performance, and enhance security, establishing itself as a vital tool for server management in various environments.


title: PARAMETERS
content:
<b><b>-s</b> <i>sender</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters the output to only show messages sent by the specified <i>sender</i>.<br><br><b><b>-c</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instead of listing individual messages, prints only the total number of messages. If a <i>sender</i> is specified with <b>-s</b>, it counts messages from that specific sender; otherwise, it counts all messages in the mailbox.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Instructs <i>from</i> to print the "Author" field from the 'From ' line. This field is considered very obscure and was primarily used in older ARPANET environments.<br><br><b><i>file</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative mailbox <i>file</i> to check. If this argument is omitted, the command defaults to checking the user's primary system mailbox (e.g., <i>/var/spool/mail/user</i>).<br><br>


title: DESCRIPTION
content:
The <i>from</i> command is a classic Unix utility designed to inspect mailboxes and extract information about the origin of mail messages. It functions by parsing mail headers, specifically seeking out the 'From ' (note the trailing space) lines that mark the beginning of each message in traditional mail spool files. These lines typically encapsulate crucial details such as the sender's name and the exact date and time the message was sent. By default, <i>from</i> examines the current user's primary system mailbox, commonly found at <i>/var/spool/mail/user</i> on most Linux systems. However, its versatility allows users to specify an alternative mailbox file as an argument, enabling inspection of other users' mailboxes or archived mail folders. This command is fundamentally tied to the legacy <b>mbox</b> format, where mail messages are concatenated into a single file, making it a valuable tool for interacting with such mail storage methods in a command-line environment.


title: CAVEATS
content:
The <i>from</i> command is not very effective for mailboxes in <b>mbox</b> format if they have been compacted or processed in a way that removes the specific 'From ' header line delimiters. Such mailboxes will not yield accurate results. Additionally, the use of the <b>-a</b> option is for a very obscure and rarely seen mail header field.


title: EXIT STATUS
content:
The <i>from</i> command provides standard exit codes to indicate its operational outcome:<br><ul><li><b>0</b>: Success – The command executed without errors.</li><li><b>1</b>: Failure – An error occurred, such as the specified <i>file</i> not being found or unreadable.</li><li><b>2</b>: Syntax Error – The command was invoked with incorrect arguments or options.</li></ul>


title: MAILBOX FORMAT DEPENDENCY
content:
The core functionality of <i>from</i> relies heavily on the specific 'From ' line (with a trailing space) that traditionally marks the beginning of a new message in <b>mbox</b> format mailboxes. Without this precise header line, which acts as a separator and contains key sender information, the command cannot correctly parse or display message details. This dependency explains why compacted or non-standard mailboxes may not yield expected results when used with <i>from</i>.


title: HISTORY
content:
The <i>from</i> command originates from early Unix systems, serving as a simple utility to check mail status in a command-line environment. Its design is intrinsically linked to the traditional <b>mbox</b> mail spool format, which stores mail messages in a single file, delimited by 'From ' lines. While its direct utility has diminished with the widespread adoption of modern mail protocols (like IMAP and POP3) and webmail interfaces, it remains a part of standard Unix/Linux distributions, often bundled with mail processing utilities like <b>mailx</b> or <b>procmail</b>. It represents a piece of historical functionality for local mail management.


title: SYNOPSIS
content:
<b>frps</b> [<i>-c</i> <<i>config_file</i>>] [<i>--version</i>] [<i>--help</i>]<br><b>frpc</b> [<i>-c</i> <<i>config_file</i>>] [<i>--version</i>] [<i>--help</i>]


title: PARAMETERS
content:
<b><i>-c</i> <<i>config_file</i>>, <i>--config</i> <<i>config_file</i>></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the configuration file. For <b>frps</b>, this is typically <i>frps.ini</i>; for <b>frpc</b>, it's <i>frpc.ini</i>.<br><br><b><i>--version</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>frp</b> version information and exits.<br><br><b><i>--help</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a comprehensive help message for the command and exits.<br><br>


title: DESCRIPTION
content:
<b>frp</b> (<i>fast reverse proxy</i>) is an open-source project designed to help you expose a local service behind a NAT or firewall to the Internet. It typically consists of two main components: a server (<b>frps</b>) and a client (<b>frpc</b>). The server runs on a public-facing machine, while the client runs on the local machine with the service you want to expose.<br><br><b>frp</b> facilitates secure connections and data forwarding through various protocols like TCP, UDP, HTTP, and HTTPS. It's commonly used for scenarios such as accessing SSH servers behind a NAT, exposing local web servers for testing, or providing access to internal services without complex network configurations. Its flexibility allows for both basic port forwarding and more advanced features like subdomain and custom domain routing, load balancing, and secure communication via TLS. It simplifies the process of making internal services externally accessible, bypassing network restrictions efficiently.


title: CAVEATS
content:
<b>Server Requirement:</b> <b>frp</b> requires a publicly accessible server to run the <b>frps</b> component.<br><b>Security:</b> Exposing local services carries inherent security risks. It's crucial to use strong authentication tokens, enable TLS for secure communication, and restrict access to only necessary ports and services.<br><b>Performance:</b> The performance of proxied services is dependent on the network bandwidth and latency between the client, server, and the end-user.<br><b>Installation:</b> <b>frp</b> is not a standard Linux utility and must be manually downloaded, compiled, or installed from pre-built binaries.


title: CONFIGURATION FILES
content:
<b>frp</b> heavily relies on configuration files (typically <i>frps.ini</i> for the server and <i>frpc.ini</i> for the client) to define its operational behavior. These files specify critical parameters such as the listening ports, authentication tokens, server address, proxy types (TCP, UDP, HTTP, HTTPS), local service addresses, and advanced routing rules. Proper configuration is essential for <b>frp</b> to function correctly and securely.


title: CLIENT-SERVER ARCHITECTURE
content:
The core of <b>frp</b>'s operation is its client-server architecture. An <b>frps</b> instance runs on a public server, acting as the central relay. One or more <b>frpc</b> instances run on local machines, connecting to the <b>frps</b> server. Upon connection, <b>frpc</b> establishes tunnels for specific services, making them accessible to external users via the public server's address and designated ports. This setup allows private services to bypass NATs and firewalls.


title: HISTORY
content:
<b>frp</b> was initially developed by Chinese developer <i>fatedier</i>, with its first public release around 2016. It quickly gained significant popularity as a free and open-source alternative to commercial tunneling services like Ngrok, primarily due to its self-hosting capabilities, extensive features, and flexibility in exposing various types of local services. The project is actively maintained on GitHub, benefiting from a large and engaged community that contributes to its continuous development and improvement.


title: SYNOPSIS
content:
<b>frpc</b> [<i>global options</i>] <i>command</i> [<i>command options</i>] [<i>arguments...</i>]<br><br>Common usage examples:<br><b>frpc</b> <i>start</i> <b>-c</b> <i>/path/to/frpc.ini</i><br><b>frpc</b> <b>-c</b> <i>/path/to/frpc.ini</i>


title: PARAMETERS
content:
<b><b>-c</b> <i>&lt;config_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <b>path</b> to the client <i>configuration file</i> (e.g., <i>frpc.ini</i>).<br><br><b><b>-t</b> <i>&lt;token&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <b>authentication token</b> used to connect to the <i>frps</i> server. Can also be defined in the configuration file.<br><br><b><b>-l</b> <i>&lt;log_file&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <b>path</b> where <i>frpc</i> will write its <i>log messages</i>.<br><br><b><b>-L</b> <i>&lt;log_level&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the <b>logging level</b>. Common levels include <i>info</i>, <i>warn</i>, <i>error</i>, <i>debug</i>, and <i>trace</i>.<br><br><b><b>-p</b> <i>&lt;profile_port&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the <b>pprof listening port</b> for profiling and debugging <i>frpc</i> performance.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the <b>version information</b> of the <i>frpc</i> client.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <b>help message</b>, showing available commands and options.<br><br><b><b>start</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The primary <b>command</b> to <i>start</i> the <i>frpc</i> client and initiate proxy connections.<br><br><b><b>reload</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<b>Reloads</b> the client's configuration file without restarting the entire <i>frpc</i> process.<br><br>


title: DESCRIPTION
content:
<i>frpc</i> (FRP client) is the <b>client-side executable</b> of the open-source <i>Fast Reverse Proxy</i> project.<br>Its primary function is to <b>expose local services</b>, such as web servers, SSH, or game servers, that are behind a NAT or firewall, to the public internet.<br>It achieves this by establishing a <b>persistent connection</b> to an <i>frps</i> (FRP server) instance, which is typically hosted on a public server.<br>Through this established tunnel, <i>frpc</i> forwards incoming requests from the <i>frps</i> server to the designated local service and sends responses back.<br>This makes services accessible from outside the local network without requiring complex firewall configurations or public IP addresses for the local machine.<br><i>frpc</i> supports various <b>proxy types</b> including TCP, UDP, HTTP, HTTPS, and SOCKS5, and offers features like <i>domain-based routing</i>, <i>subdomain forwarding</i>, and <i>connection multiplexing</i>, making it a versatile tool for remote access and service exposure.


title: CAVEATS
content:
<b>Security Risk</b>: Exposing local services directly to the internet via <i>frp</i> requires careful consideration of security.<br>Ensure strong authentication tokens and proper network security measures.<br><b>Server Dependency</b>: <i>frpc</i> requires a running <i>frps</i> server instance with public accessibility.<br><b>Performance</b>: Performance can be limited by the bandwidth and latency of the <i>frps</i> server and the network path between client and server.<br><b>Configuration Complexity</b>: Managing multiple proxy rules and advanced features can lead to complex configuration files.


title: <B>CONFIGURATION FILE</B>
content:
The core of <i>frpc</i> operation relies on its <b>configuration file</b>, typically named <i>frpc.ini</i>.<br>This file defines the <i>server connection details</i> (e.g., server address, port, token) and <i>all local services</i> to be exposed, including their types (e.g., TCP, HTTP), local ports, and remote mappings.<br>It supports multiple proxy sections, allowing a single <i>frpc</i> instance to manage connections for various services simultaneously.


title: <B>PROXY TYPES</B>
content:
<i>frpc</i> supports several <b>proxy types</b>, each tailored for different use cases:<br><b>TCP</b>: For general-purpose TCP connections, like SSH or custom applications.<br><b>UDP</b>: For UDP-based services, such as gaming or DNS.<br><b>HTTP</b>/<b>HTTPS</b>: For exposing web services, with support for virtual hosts and subdomain routing.<br><b>SOCKS5</b>: To establish a SOCKS5 proxy that can be used by any SOCKS5-compatible client to access the local network.


title: HISTORY
content:
<i>FRP</i>, including the <i>frpc</i> client, is an <b>open-source project</b> initiated by <i>Fatedier</i>.<br>It quickly gained popularity in the developer community for its elegant solution to <b>NAT traversal</b> and remote access.<br>Since its inception, <i>FRP</i> has undergone continuous development, adding support for more proxy types, enhanced security features, and improved performance.<br>Its usage has grown significantly among users needing to bypass restrictive network environments to access their local services remotely.


title: SEE ALSO
content:
frps(1) - <i>FRP server component</i>, ssh(1) - <i>Secure Shell (can be used for port forwarding)</i>, nginx(8) - <i>High-performance HTTP and reverse proxy server</i>


title: SYNOPSIS
content:
<b>frps</b> <i>[-c &lt;config_file&gt; | --config &lt;config_file&gt;]</i><br><b>frps</b> <i>[--version | -v]</i><br><b>frps</b> <i>[--help]</i>


title: PARAMETERS
content:
<b><b>-c &lt;path&gt;</b>, <b>--config &lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path to the <i>frps</i> configuration file (e.g., <i>frps.ini</i>). This is the most common way to configure the server's behavior.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of the <i>frps</i> server and exits.<br><br><b><b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays a help message with available command-line options and exits.<br><br><b><b>--log-file &lt;path&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the path for the log file. If not set, logs may be directed to standard output or syslog.<br><br><b><b>--log-level &lt;level&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the logging level. Possible values include <i>info</i>, <i>warn</i>, <i>error</i>, <i>debug</i>, and <i>trace</i>. Defaults to <i>info</i>.<br><br><b><b>--log-max-days &lt;days&gt;</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the maximum number of days to retain log files. Older logs will be automatically deleted.<br><br><b><b>--disable-log-redirect</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prevents <i>frps</i> from redirecting standard output and standard error to the log file, ensuring they are output to the console.<br><br>


title: DESCRIPTION
content:
<i>frps</i> (Fast Reverse Proxy Server) is the server-side component of the <i>frp</i> project, an open-source reverse proxy solution. It is designed to facilitate network traversal, allowing services located behind a NAT or firewall to be exposed to the public internet. This is achieved by establishing a persistent connection from a client (<i>frpc</i>) within the private network to the <i>frps</i> server, which typically resides on a publicly accessible IP address.<br><br><i>frps</i> acts as an intermediary, forwarding requests from the public internet to the appropriate local service via the established tunnel. It supports various protocols, including TCP, UDP, HTTP, and HTTPS, making it a versatile tool for remote access, web service publishing, and secure internal network communication. Its primary use case is to make services accessible that would otherwise be unreachable due to network restrictions or complex firewall configurations.


title: CAVEATS
content:
When deploying <i>frps</i>, security is paramount. Improper configuration, such as using weak authentication tokens, exposing unnecessary ports, or not enabling TLS, can lead to unauthorized access to internal network resources. It's crucial to use strong tokens, enable TLS encryption where possible, and restrict access to the server.<br><br>While efficient, <i>frps</i> can become a performance bottleneck for services with very high traffic volumes, as all data passes through the server. Careful resource planning for the server hosting <i>frps</i> is advisable.


title: CONFIGURATION FILE (FRPS.INI)
content:
The primary configuration for <i>frps</i> is typically managed through a dedicated file, most commonly named <i>frps.ini</i>. This file contains settings for server binding ports (e.g., <i>bind_port</i>), dashboard settings (<i>dashboard_port</i>, <i>dashboard_user</i>, <i>dashboard_pwd</i>), authentication tokens (<i>token</i>), and virtual host configurations (<i>vhost_http_port</i>, <i>vhost_https_port</i>). Command-line options usually complement or override specific settings defined within this file.


title: DAEMONIZATION
content:
For production environments, <i>frps</i> is almost always run as a background service to ensure continuous operation. This is commonly achieved using process managers like <i>systemd</i> on Linux, which can automatically start <i>frps</i> on system boot, restart it upon crashes, and manage its logging.


title: WEB DASHBOARD
content:
<i>frps</i> includes an optional web-based dashboard, which can be enabled and configured within the <i>frps.ini</i> file. This dashboard provides real-time monitoring of active <i>frpc</i> client connections, traffic statistics, and overall server status, offering a convenient way to oversee the proxy's operation.


title: HISTORY
content:
The <i>frp</i> project, including <i>frps</i>, was initiated by fatedier as an open-source solution on GitHub. It quickly gained popularity for its lightweight design and versatility in addressing common network traversal challenges. Its development focused on providing a user-friendly and efficient alternative to more complex VPNs or firewall configurations for exposing internal services. The project has seen continuous development and community contributions, enhancing its features, stability, and protocol support, making it a widely adopted tool for both personal and enterprise use cases.


title: SEE ALSO
content:
frpc (1) - The client component of the frp project for connecting to frps., ssh (1) - Secure Shell, often used for similar port forwarding and tunneling purposes., socat (1) - A versatile relay for various protocols, capable of complex network manipulations., nginx (8) - A powerful web server and reverse proxy that can also handle similar traffic forwarding scenarios, though typically at the application layer.


title: PARAMETERS
content:
<b><b>-A</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Checks all filesystems listed in <i>/etc/fstab</i>. Filesystems are checked in the order specified by their pass number in <i>fstab</i>.<br><br><b><b>-a</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically repair filesystem errors without prompting. This option should be used with extreme caution as it might delete data.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively repair filesystem errors. This prompts the user for confirmation on each detected issue.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Assume 'yes' to all questions asked by the filesystem-specific checker. Similar to <b>-a</b>, but more aggressive and less cautious.<br><br><b><b>-N</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Don't execute the check; merely show what would be done (a 'dry run').<br><br><b><b>-P</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>-A</b>, check filesystems in parallel. This can speed up the process but should be used carefully.<br><br><b><b>-R</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used with <b>-A</b>, skip checking the root filesystem (<i>/</i>). The root filesystem is typically checked automatically at boot time.<br><br><b><b>-S</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Serialize filesystem checks. Useful when checking multiple filesystems to avoid resource contention.<br><br><b><b>-t</b> <i>fstype</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specify the filesystem type(s) to be checked (e.g., <i>ext4</i>, <i>xfs</i>, <i>vfat</i>). Multiple types can be specified in a comma-separated list.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output, showing more details about the checks being performed.<br><br><b><b>-C</b> [<i>fd</i>]</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display completion/progress bars for those filesystem checkers that support it. The optional <i>fd</i> specifies the file descriptor to send the progress info to.<br><br><b><b>-M</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check mounted filesystems. This is a safety measure to prevent data corruption.<br><br><b><b>-F</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force checking even if the filesystem appears clean. This overrides the clean flag often set by journaling filesystems.<br><br>


title: DESCRIPTION
content:
The <b>fsck</b> (file system consistency check) command is a crucial utility used to check the consistency of a Linux filesystem and, if necessary, repair it. It's typically invoked when a filesystem becomes corrupted due to improper shutdowns, hardware failures, or software errors. <b>fsck</b> acts as a front-end for various filesystem-specific checker programs (e.g., <i>fsck.ext4</i> for Ext4 filesystems, <i>fsck.xfs</i> for XFS). When executed, <b>fsck</b> examines the filesystem's metadata (superblock, inodes, directories, etc.) to ensure that its internal structure is consistent. If inconsistencies are found, it attempts to correct them, often by asking the user for confirmation (interactive mode) or by automatically applying fixes. Regular use, especially after an unclean shutdown, helps maintain data integrity and prevent data loss on disk partitions or volumes.


title: CAVEATS
content:
<b><br>WARNING:</b> Never run <b>fsck</b> on a <i>mounted</i> filesystem, especially if it's mounted read-write. Doing so can lead to severe data corruption and data loss. The filesystem must be unmounted or mounted read-only before running <b>fsck</b>. For the root filesystem (<i>/</i>), it is usually checked automatically by the init system during boot, or it may require booting from a live CD/USB to unmount it before checking.


title: EXIT CODES
content:
<b>fsck</b> returns a bitmask of the following exit codes, which are useful for scripting:<br><ul><li><b>0</b>: No errors.</li><li><b>1</b>: Filesystem errors corrected.</li><li><b>2</b>: System should be rebooted.</li><li><b>4</b>: Filesystem errors uncorrected.</li><li><b>8</b>: Operational error (e.g., fsck process failed to run).</li><li><b>16</b>: Usage or syntax error.</li><li><b>32</b>: Fsck canceled by user request.</li><li><b>128</b>: Shared library error.</li></ul><br>Multiple codes can be combined (e.g., 3 means errors corrected and reboot is needed: 1 + 2).


title: WRAPPER FUNCTIONALITY
content:
It's important to understand that <b>fsck</b> is not the actual filesystem checker. Instead, it's a wrapper script or program that searches for the appropriate filesystem-specific checker (e.g., <i>fsck.ext4</i>, <i>fsck.xfs</i>) in your system's PATH (typically <i>/sbin/</i>). It then executes that specific checker, passing along the options and the filesystem device. This modular design allows <b>fsck</b> to support a wide variety of filesystem types without needing to be rewritten for each one.


title: HISTORY
content:
The concept of filesystem checking dates back to early Unix systems, where utilities like <i>checkfs</i> and <i>dcheck</i> were used to verify filesystem integrity. The <b>fsck</b> command emerged as a standardized utility, evolving into a front-end that calls filesystem-specific checkers. Its design as a wrapper allowed it to adapt to various filesystem types as they were developed (e.g., ext2, ext3, ext4, XFS). While journaling filesystems (like Ext3, Ext4, XFS) have significantly reduced the frequency of requiring manual <b>fsck</b> runs after unclean shutdowns, the command remains an indispensable tool for diagnosing and repairing severe filesystem corruption.


title: PARAMETERS
content:
<b>-a</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically repair the filesystem without prompting. Equivalent to -y.<br><br><b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Build the bad block list by checking all clusters.<br><br><b>-c</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Check for bad blocks during the filesystem scan. This can be very slow on large devices.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force checking even if the filesystem is marked clean.<br><br><b>-l</b><br>&nbsp;&nbsp;&nbsp;&nbsp;List the filenames of bad blocks (requires -c or -t).<br><br><b>-n</b><br>&nbsp;&nbsp;&nbsp;&nbsp;No changes to the filesystem; just show what would be done (dry run).<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively repair the filesystem, prompting for confirmation on each correction.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enable verbose output, showing more details about the check progress and findings.<br><br><b>-V</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display version information and exit.<br><br><b>-y</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically repair the filesystem without prompting. Equivalent to -a.<br><br><b>-I</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not check for invalid filenames (e.g., those containing invalid characters or starting with a space).<br><br><b>-M</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Do not move bad clusters to a special bad block area; just mark them as bad.<br><br><b>-t</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Test for bad blocks (implies -c) and add them to the bad block list if found.<br><br>


title: DESCRIPTION
content:
fsck.fat is a utility from the <I>dosfstools</I> package used to check and repair FAT (FAT12, FAT16, FAT32) filesystems. Its primary function is to maintain the integrity of FAT-formatted storage devices, such as USB drives, SD cards, and legacy partitions, particularly on systems where data might be written or read by both Linux and Windows. When executed, it scans the specified device for inconsistencies, including errors in the boot sector, File Allocation Tables (FATs), directory entries, and cluster chains. <br><br>Common issues it addresses include cross-linked files, lost clusters, incorrect file sizes, and directory corruption that can arise from improper shutdowns, system crashes, or hardware failures. While fsck.fat attempts to automatically correct many errors, it also provides an interactive mode for manual intervention. It's crucial to understand that fsck.fat operates on the raw filesystem structure and should <B>never</B> be run on a mounted device to prevent data loss or further corruption. It is the specific backend for FAT filesystems when fsck is invoked.


title: CAVEATS
content:
fsck.fat must <B>NEVER</B> be run on a mounted filesystem. Doing so can lead to severe data corruption and loss. Always unmount the device (e.g., using <I>umount</I>) before running this command. <br><br>While it attempts to recover data, severe filesystem corruption might result in some data loss. It's always advisable to back up critical data before running fsck.fat. <br><br>The -c or -t options for checking bad blocks can be very time-consuming on large devices, as they involve reading the entire disk surface.


title: EXIT STATUS
content:
fsck.fat returns an exit code indicating the outcome of the operation. A value of <I>0</I> means no errors were found or all errors were corrected. A non-zero value indicates that errors were found, and possibly not all could be corrected, which is crucial for scripting and automated checks.


title: DEVICE SPECIFICATION
content:
The <I>DEVICE</I> argument must specify the raw block device (e.g., <B>/dev/sdb1</B>), not a mount point (e.g., <B>/mnt/usb</B>). Ensuring you identify the correct device is critical to avoid unintended data loss on other partitions.


title: HISTORY
content:
fsck.fat is a core component of the <I>dosfstools</I> project, which provides utilities for creating, checking, and managing FAT filesystems on Linux. Its lineage can be traced back to the need for Unix-like systems to interact reliably with the widely used FAT filesystem, prevalent on removable media and older PC systems. Over the years, it has been continually refined to support various FAT versions (FAT12, FAT16, FAT32) and ensure compatibility with different operating systems, making it an essential tool for data exchange across platforms.


title: SYNOPSIS
content:
<b>fsck.jfs</b> [ <i>-a</i> ] [ <i>-f</i> ] [ <i>-v</i> ] [ <i>-V</i> ] <i>device</i><br><b>fsck.jfs</b> <i>-r device</i><br><b>fsck.jfs</b> <i>-s device</i>


title: PARAMETERS
content:
<b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the JFS block device to check (e.g., <i>/dev/sdb1</i>).<br><br><b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically repair the file system without prompting for confirmation. Use with caution as it might make choices you wouldn't.<br><br><b><i>-f</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force a check, even if the file system appears clean and does not need checking.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output, showing more details about the checks being performed.<br><br><b><i>-V</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Print the version information for <i>fsck.jfs</i>.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Perform a replay of the file system's journal only. This is a faster check, suitable if the file system was unmounted cleanly but an integrity check is desired.<br><br><b><i>-s</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display the superblock information of the specified JFS device without performing any checks or repairs.<br><br>


title: DESCRIPTION
content:
<i>fsck.jfs</i> is the utility used to check and repair the integrity of a JFS (Journaled File System) on Linux. It is typically invoked automatically by the generic <i>fsck</i> command when a JFS partition needs checking, or it can be run directly. JFS is a robust journaling file system developed by IBM.<br><br>The primary function of <i>fsck.jfs</i> is to ensure data consistency. It first attempts a fast recovery by replaying the file system's journal (log file) to bring the metadata into a consistent state. If the journal is unrecoverable or if explicitly forced, it performs a full file system scan, checking for and correcting various inconsistencies such as corrupted superblocks, incorrect inode entries, bad block pointers, and directory structure errors.<br><br>Running <i>fsck.jfs</i> is crucial for maintaining the health and reliability of JFS partitions, especially after unclean shutdowns or system crashes. It should always be run on an unmounted file system to prevent data corruption.


title: CAVEATS
content:
<b>Never</b> run <i>fsck.jfs</i> on a mounted file system that is actively being written to. Doing so can lead to severe data corruption and loss. Always unmount the JFS partition before running this command for repairs. If a mounted filesystem must be checked, ensure it is mounted read-only (though <i>fsck.jfs</i> itself does not have a read-only flag, the generic <i>fsck</i> front-end might handle it).


title: EXIT STATUS
content:
<i>fsck.jfs</i> returns specific exit codes indicating the result of the operation:<br><b>0</b>: No errors were found.<br><b>1</b>: File system errors were corrected.<br><b>2</b>: File system errors were corrected, and the system should be rebooted.<br><b>4</b>: File system errors were left uncorrected.<br><b>8</b>: Operational error during check.<br><b>16</b>: Usage or syntax error.<br><b>32</b>: <i>fsck.jfs</i> was canceled by the user (e.g., via Ctrl+C).<br><b>128</b>: Shared library error.<br>These exit codes are useful for scripting and automated system maintenance.


title: HISTORY
content:
JFS, the Journaled File System, was originally developed by IBM for its AIX and OS/2 operating systems. IBM open-sourced JFS for Linux in 2000, and it was integrated into the Linux kernel shortly thereafter. <i>fsck.jfs</i> is an integral part of the <i>jfsutils</i> package, which provides various user-space tools for managing JFS file systems on Linux. Its development and maintenance closely follow the evolution of the JFS support within the Linux kernel, ensuring compatibility and reliability for JFS users.


title: PARAMETERS
content:
<b><i>-a</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Automatically fix file system errors without prompting.<br><br><b><i>-f</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Force checking even if the file system appears clean.<br><br><b><i>-m</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Mark the file system as clean if no errors are found during the check.<br><br><b><i>-r</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Interactively repair errors, prompting for confirmation. This is the default if <i>-a</i> is not used.<br><br><b><i>-v</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produce verbose output, showing more details of the check.<br><br><b><i>-l</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;List all bad blocks on the device. Note: This option does <i>not</i> perform a consistency check or repair.<br><br><b><i>device</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The special file (e.g., /dev/sdb1) corresponding to the Minix file system to be checked.<br><br>


title: DESCRIPTION
content:
<b>fsck.minix</b> is a utility designed to check and optionally repair consistency problems within a Minix file system. It scrutinizes the file system's structure for issues such as invalid block or inode counts, incorrect directory entries, and orphaned inodes. When run without the <i>-a</i> (automatic repair) option, it typically operates interactively, prompting the user for confirmation before attempting to fix detected errors. It is absolutely critical to unmount the Minix file system <i>before</i> running <b>fsck.minix</b> to prevent potential data corruption, as operating on a mounted file system can lead to severe inconsistencies. While less common in modern Linux systems, this command remains relevant for legacy Minix partitions or specific embedded systems using the Minix file system. It's often invoked indirectly by the generic <b>fsck</b> command.


title: CAVEATS
content:
<i><b>Critical Unmount:</b></i> Always ensure the Minix file system is unmounted before running <b>fsck.minix</b>. Running it on a mounted file system can lead to severe data corruption and loss.<br><i><b>Minix Specific:</b></i> This command is exclusively for Minix file systems, which are rarely used in modern Linux distributions. It is not suitable for ext4, XFS, or other common file systems.<br><i><b>Bad Block Listing:</b></i> The <b>-l</b> option only lists bad blocks and does not perform a full consistency check or repair.


title: EXIT STATUS
content:
<b>fsck.minix</b> returns an exit status indicating the outcome:<br><i>0</i> - No errors.<br><i>1</i> - File system errors corrected.<br><i>2</i> - File system errors corrected, system should be rebooted.<br><i>4</i> - File system errors uncorrected.<br><i>8</i> - Operational error (e.g., file system not found or I/O error).<br><i>16</i> - Usage or syntax error.<br><i>32</i> - <b>fsck.minix</b> was canceled by user.<br><i>128</i> - Shared library error.


title: HISTORY
content:
The Minix file system was originally developed by Andrew S. Tanenbaum for the Minix operating system, an early Unix-like system. Linux itself was initially developed on Minix, and the Minix file system was one of the first file systems supported by the Linux kernel. <b>fsck.minix</b> has thus been a fundamental utility in Linux since its early days, essential for maintaining the integrity of Minix partitions. While its direct usage has become less common due to the prevalence of more advanced file systems like ext4, it remains a historical and functional component for specific legacy or embedded use cases.


title: PARAMETERS
content:
<b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Force</I> checking. Although XFS usually doesn't need force checks due to journaling, this option might be passed by the generic <b>fsck</b> command and can force specific behaviors in <b>xfs_repair</b>.<br><br><b><b>-n</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>No action</I> (read-only check). Simulates repairs without writing changes, displaying what <I>would</I> be done.<br><br><b><b>-V</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Verbose</I> output. Increases the verbosity of the operation, showing more details about the checks or repairs.<br><br><b><b>-y</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;<I>Assume yes</I> to all questions. Automatically answers "yes" to any repair prompts, though <b>xfs_repair</b> often handles repairs automatically or requires specific flags like <b>-L</b>.<br><br><b><I>device</I></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The XFS filesystem <I>device</I> to check or repair, e.g., <b>/dev/sda1</b> or a UUID. This is a mandatory argument.<br><br>


title: DESCRIPTION
content:
<b>fsck.xfs</b> is the XFS-specific filesystem check utility, primarily designed to be invoked by the generic <b>fsck</b> command. Unlike traditional <b>fsck</b> tools for non-journaling filesystems, <b>fsck.xfs</b> typically acts as a simple wrapper or symbolic link to <b>xfs_repair(8)</b>.<br><br>Due to XFS's journaling nature, routine filesystem checks after an unclean shutdown are handled by the journal replay mechanism upon mounting. Consequently, <b>fsck.xfs</b> (and <b>xfs_repair</b>) is primarily used for repairing severely corrupted XFS filesystems that cannot be mounted. It requires the filesystem to be <I>unmounted</I> for any repair operations. Running <b>fsck.xfs</b> on a healthy, unmounted XFS filesystem will usually result in a message indicating no errors were found, or it will simply exit without performing extensive checks. Its primary role is to integrate XFS into the standard Linux <b>fsck</b> utility framework.


title: CAVEATS
content:
<b>fsck.xfs</b> is largely a wrapper for <b>xfs_repair(8)</b>. Unlike traditional <b>fsck</b> commands, it does <I>not</I> perform a comprehensive consistency check (like inode counts, block usage) on a healthy XFS filesystem due to XFS's journaling design.<br><br>It requires the XFS filesystem to be <I>unmounted</I> for any repair operations. Running it on a mounted filesystem will usually result in an error or a warning, as <b>xfs_repair</b> cannot operate on a mounted filesystem.<br><br>For serious corruption, it's often better to directly use <b>xfs_repair(8)</b> as it offers more fine-grained control and specific recovery options (e.g., clearing the journal with <b>-L</b>).


title: WRAPPER NATURE
content:
<b>fsck.xfs</b> is typically a simple symbolic link or script that invokes <b>xfs_repair</b>. Therefore, understanding <b>xfs_repair</b> is essential when troubleshooting XFS filesystem issues, as <b>fsck.xfs</b> offers no unique functionality beyond passing arguments.


title: JOURNALING BENEFITS
content:
Due to XFS's journaling, an unclean shutdown typically only requires a journal replay at mount time to ensure consistency. This means <b>fsck.xfs</b> (and by extension <b>xfs_repair</b>) is necessary only for severe, unmountable filesystem corruption, not for routine post-crash checks.


title: HISTORY
content:
<b>fsck.xfs</b> was developed as part of the <b>xfsprogs</b> package, which provides various utilities for managing XFS filesystems. Its existence is primarily to fulfill the standard Linux <b>fsck</b> framework's expectation that a <b>fsck.<fstype></b> helper exists for each filesystem type. This allows commands like <b>fsck -A</b> (check all filesystems) to correctly handle XFS. From its inception, its role has been to act as a front-end to <b>xfs_repair</b>, leveraging XFS's robust journaling capabilities which generally preclude the need for exhaustive post-crash checks common to non-journaling filesystems.


title: SYNOPSIS
content:
fscrypt [GLOBAL_OPTIONS] &lt;COMMAND&gt; [COMMAND_OPTIONS] [ARGUMENTS]<br><br>Examples:<br><i>fscrypt setup &lt;mountpoint&gt;</i><br><i>fscrypt enroll &lt;directory&gt;</i><br><i>fscrypt unlock &lt;mountpoint&gt;</i><br><i>fscrypt status &lt;mountpoint_or_path&gt;</i>


title: PARAMETERS
content:
<b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays help information for the main command or a specific subcommand.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing more detailed information about operations.<br><br><b><b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the <i>fscrypt</i> version information.<br><br><b><b>--owner=</b><i>&lt;user&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the owner (user or group ID or name) for the encryption policy (e.g., used with <i>enroll</i>).<br><br><b><b>--source=</b><i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the source of the encryption key, such as <i>passphrase</i>, <i>tpm2</i>, <i>pam_passphrase</i>, or <i>pkcs11</i>.<br><br><b><b>--hash=</b><i>&lt;algorithm&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the passphrase hashing algorithm to use, commonly <i>scrypt</i> or <i>pbkdf2</i>.<br><br><b><b>--hkdf=</b><i>&lt;algorithm&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the HKDF (HMAC-based Key Derivation Function) algorithm, typically <i>sha256</i>.<br><br><b><b>--fs-config-uuid=</b><i>&lt;uuid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a particular filesystem configuration by its UUID, especially useful for systems with multiple configurations.<br><br><b><b>--policy-uuid=</b><i>&lt;uuid&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Refers to an existing encryption policy by its UUID for operations like modifying or managing.<br><br><b><b>--wipe-keys</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;(Used with <i>lock</i>) Instructs <i>fscrypt</i> to securely wipe the decryption keys from kernel memory upon locking.<br><br>


title: DESCRIPTION
content:
<i>fscrypt</i> is a user-space tool that provides an easy-to-use interface for the Linux kernel's <i>fscrypt</i> feature. It enables transparent, per-directory encryption on supported filesystems like <b>ext4</b>, <b>f2fs</b>, and <b>ubifs</b>. Rather than encrypting entire partitions, <i>fscrypt</i> allows users to encrypt specific directories, with all files created within an encrypted directory automatically being encrypted.<br><br>The tool handles the complex tasks of key management, passphrase hashing, and interacting with the kernel's encryption keyring. It supports various key sources, including user-provided passphrases, system login passphrases via PAM, and hardware security modules like TPM 2.0 or PKCS#11 tokens.<br><br>By simplifying the setup and ongoing management of encrypted data, <i>fscrypt</i> helps users protect sensitive information stored on their Linux systems without requiring full disk encryption or complex manual key handling. It ensures that data is encrypted at rest, enhancing data security.


title: CAVEATS
content:
<i>fscrypt</i> relies on specific Linux kernel features (the <i>fscrypt</i> module) and filesystem versions (<b>ext4</b> with the `encrypt` feature enabled, <b>f2fs</b>, and <b>ubifs</b>). It does not provide full disk encryption; instead, it encrypts specific directories. It is crucial to ensure proper backup of passphrases or key material, as losing them will result in irreversible data loss. While it supports encryption at rest, data is decrypted in memory during use, which may have minor performance implications.


title: KEY STORAGE AND MANAGEMENT
content:
<i>fscrypt</i> manages encryption keys in user-space (e.g., in `~/.fscrypt` for passphrase-derived keys) and securely loads them into the kernel's keyring for actual file system operations. This allows keys to be automatically loaded on system boot (if configured) or manual unlock, and securely purged from kernel memory when no longer needed.


title: FILESYSTEM REQUIREMENTS
content:
For <b>ext4</b>, the filesystem must be created with the `encrypt` feature enabled (e.g., using `mkfs.ext4 -O encrypt /dev/sdX`). For <b>f2fs</b> and <b>ubifs</b>, encryption support is generally available without special creation flags, but they must be mounted with the correct options to utilize <i>fscrypt</i> effectively. It's recommended to check the filesystem's `dump-features` or similar commands to confirm <i>fscrypt</i> support.


title: HISTORY
content:
The <i>fscrypt</i> kernel feature was initially developed for ChromeOS and introduced into the Linux kernel in version 4.1. The <i>fscrypt</i> user-space tool was subsequently created to provide a convenient, user-friendly interface to manage this kernel functionality. Its development has focused on simplifying the deployment and ongoing management of directory-level encryption on Linux systems, aiming for broader adoption beyond its initial ChromeOS roots.


title: PARAMETERS
content:
<b><b>-t</b> <i>&lt;type&gt;</i>, <b>--type</b> <i>&lt;type&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Filters results by file type. Common types include <i>f</i> (file), <i>d</i> (directory), <i>l</i> (symlink), <i>s</i> (socket), <i>p</i> (fifo), <i>b</i> (block device), <i>c</i> (char device).<br><br><b><b>-x</b>, <b>--exclude-dir</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Excludes directories from the search results, returning only files that match the criteria.<br><br><b><b>-p</b>, <b>--print0</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints results separated by a null character, useful for piping output to other commands like <i>xargs -0</i>.<br><br><b><b>-i</b>, <b>--ignore-case</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Performs case-insensitive matching for string comparisons within the query conditions.<br><br><b><b>-s</b> <i>&lt;char&gt;</i>, <b>--separator</b> <i>&lt;char&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the column separator character for table-formatted output.<br><br><b><b>-S</b>, <b>--no-headers</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Suppresses the printing of the header row in table-formatted output.<br><br><b><b>-c</b> <i>&lt;mode&gt;</i>, <b>--color</b> <i>&lt;mode&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Controls colored output. Modes can be <i>auto</i>, <i>always</i>, or <i>never</i>.<br><br><b><b>-d</b> <i>&lt;path&gt;</i>, <b>--database</b> <i>&lt;path&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative path to the database file for potentially cached searches.<br><br><b><b>-o</b> <i>&lt;format&gt;</i>, <b>--output</b> <i>&lt;format&gt;</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Sets the output format. Supported formats include <i>table</i> (default), <i>json</i>, <i>tsv</i>, <i>csv</i>, and <i>lines</i>.<br><br><b><b>-j</b>, <b>--json</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;A shortcut for <i>--output json</i>, outputting results in JSON format.<br><br><b><b>-n</b>, <b>--dry-run</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Parses the query and shows what it would do without actually performing the search.<br><br><b><b>-h</b>, <b>--help</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Displays the help message with command options and examples.<br><br><b><b>-v</b>, <b>--version</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Prints the version information of <b>fselect</b>.<br><br>


title: DESCRIPTION
content:
<b>fselect</b> is a powerful command-line tool that enables users to search for files and directories using an intuitive, SQL-like query language. It provides a modern alternative to traditional file search utilities like <i>find</i>, allowing for more expressive and readable search criteria.<br><br>Users can construct queries to filter results based on various attributes such as file name, path, size, modification date, permissions, owner, and type. It supports advanced features like regular expressions, case-insensitive matching, sorting (<i>ORDER BY</i>), and limiting results (<i>LIMIT</i>).<br><br>Written in Rust, <b>fselect</b> is designed for high performance and efficiency, making complex file system searches faster and more manageable. It supports diverse output formats, including plain text, CSV, TSV, and JSON, facilitating seamless integration into scripts and workflows.


title: CAVEATS
content:
While powerful and intuitive, <b>fselect</b> is not typically pre-installed on all Linux distributions like <i>find</i>. Its SQL-like query language, while beneficial for those familiar with SQL, may present a slight learning curve for users accustomed to traditional command-line syntax.


title: QUERY LANGUAGE
content:
The core strength of <b>fselect</b> lies in its SQL-like query syntax. Users can specify which columns to <i>SELECT</i> (e.g., <i>name</i>, <i>path</i>, <i>size</i>, <i>date</i>, <i>perm</i>, <i>owner</i>, <i>group</i>, <i>inode</i>, <i>type</i>), the starting directory with <i>FROM</i> (e.g., <i>.</i> for current directory, <i>/</i> for root), and filtering conditions using <i>WHERE</i> (e.g., <i>size > 1m</i>, <i>name ~ ".*\.txt"</i>, <i>date > "2023-01-01"</i>). Results can be sorted with <i>ORDER BY</i> and limited in quantity using <i>LIMIT</i>.


title: PERFORMANCE CONSIDERATIONS
content:
Implemented in Rust, <b>fselect</b> is optimized for speed and efficiency. It often processes complex search queries faster than traditional tools by leveraging Rust's concurrency features and optimized data structures. This makes it particularly effective for large file systems or intricate search criteria.


title: HISTORY
content:
<b>fselect</b> was created by <i>junegunn</i> (Jun G. Lee) and first released around 2018. It rapidly gained traction as a modern, user-friendly alternative to more complex file search utilities, leveraging the performance benefits of Rust. Its development has focused on providing a more expressive and accessible query interface for file system navigation.


title: PARAMETERS
content:
<b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Freezes the specified filesystem, suspending all I/O operations.<br><br><b>-u</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Unfreezes the specified filesystem, resuming all I/O operations.<br><br><b><mountpoint></b><br>&nbsp;&nbsp;&nbsp;&nbsp;The path to the mounted filesystem to be frozen or unfrozen (e.g., /mnt/data).<br><br>


title: DESCRIPTION
content:
The <i>fsfreeze</i> command is used to suspend and resume access to a filesystem, effectively pausing all I/O operations on it. This state is known as "frozen." It's primarily employed to create consistent backups or snapshots of a filesystem without applications writing data during the snapshot process. When a filesystem is frozen, any new write attempts will block until the filesystem is unfrozen. This ensures data integrity for operations like LVM snapshots or raw disk imaging (e.g., with <i>dd</i>). It typically works by issuing <i>FIFREEZE</i> and <i>FITHAW</i> <i>ioctl</i> calls to the kernel. After the snapshot operation is complete, the filesystem must be unfrozen to allow normal I/O to resume.


title: CAVEATS
content:
<b>Requires root privileges:</b> The command must be run as root or with sufficient capabilities (<i>CAP_SYS_ADMIN</i>).<br><b>Temporary I/O suspension:</b> Filesystems should only be frozen for the shortest possible duration to avoid significant application disruption or potential deadlocks.<br><b>Filesystem support:</b> Not all filesystems support freezing. Modern journaling filesystems like <i>ext4</i>, <i>XFS</i>, and <i>Btrfs</i> typically do.<br><b>System crashes:</b> If the system crashes while a filesystem is frozen, it might remain in a frozen state upon reboot, requiring manual unfreezing.


title: MECHANISM
content:
<i>fsfreeze</i> utilizes <i>ioctl</i> commands (<i>FIFREEZE</i> and <i>FITHAW</i>) that communicate directly with the kernel's filesystem driver to suspend or resume I/O.


title: HISTORY
content:
<i>fsfreeze</i> was introduced as a generic tool in the <i>util-linux</i> package to provide filesystem freezing capabilities independent of the specific filesystem, unlike its predecessor <i>xfs_freeze</i> which was specific to XFS. Its development aimed to standardize the interface for pausing filesystem I/O across various Linux filesystems, making it easier for backup and snapshot tools to integrate.


title: SYNOPSIS
content:
<b>fslsfonts</b> [-server <i>servername</i>] [-l | -m] [-C] [-o] [-f] [-r] [-v] [-dir <i>directory</i>] [-fn <i>pattern</i>]


title: PARAMETERS
content:
<b><b>-server</b> <i>servername</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X font server to query. The server name typically includes a hostname and port, e.g., <i>myhost:7100</i>, or <i>unix/:7100</i> for a local socket.<br><br><b><b>-l</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces a long listing for each font, including detailed properties like Foundry, Family, Weight, Slant, Setwidth, Addstyle, Pixelsize, Pointsize, ResolutionX, ResolutionY, Spacing, AverageWidth, CharsetRegistry, and CharsetEncoding.<br><br><b><b>-m</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Produces a medium listing, which is more concise than the long listing but provides more details than the default short listing, often showing fewer properties than the <b>-l</b> option.<br><br><b><b>-C</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows character set names (e.g., <i>ISO8859-1</i>) rather than the internal encodings, which can be more human-readable.<br><br><b><b>-o</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows font server internal opcode information, which is primarily useful for debugging font server protocols or understanding font server operations at a low level.<br><br><b><b>-f</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Shows fonts that have been 'forced' by the font server's configuration, meaning they are always available regardless of whether they are explicitly requested or configured.<br><br><b><b>-r</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;When used in conjunction with the <b>-dir</b> option, this flag causes <i>fslsfonts</i> to recursively search for fonts within the specified directory and its subdirectories.<br><br><b><b>-v</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, providing more detailed information about the command's operation, such as connection attempts, configuration details, and encountered errors.<br><br><b><b>-dir</b> <i>directory</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a local directory to list fonts from, instead of querying a running font server. This option allows browsing font files directly on the filesystem.<br><br><b><b>-fn</b> <i>pattern</i></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies a font name pattern to match. Only fonts whose names match the provided <i>pattern</i> (which can include wildcards like <i>*</i> and <i>?</i>) will be listed. The pattern should typically conform to the XLFD (X Logical Font Description) naming convention.<br><br>


title: DESCRIPTION
content:
<i>fslsfonts</i> is a utility designed to list fonts available from an X font server (<i>fs</i>). It connects to the specified font server, or the default one, and queries it for a list of font names it serves. Users can specify patterns to filter the font list and choose different output formats, from simple names to detailed font properties. This command is particularly useful for system administrators managing X font servers and for users debugging font-related issues within an X environment. While its direct relevance has waned with the shift towards client-side font rendering, it remains a valuable tool for legacy X font server setups.


title: CAVEATS
content:
<i>fslsfonts</i> relies on an active and accessible X font server (<i>fs</i>). If no font server is running or if connection cannot be established, the command will fail or report an error. Its utility has decreased significantly in modern Linux/X environments, which predominantly use client-side font rendering libraries (like Fontconfig and FreeType) that directly access font files on the local filesystem, bypassing the need for a separate font server. Therefore, it is less commonly used in contemporary desktop setups.


title: DEFAULT FONT SERVER
content:
By default, <i>fslsfonts</i> attempts to connect to the font server specified by the <i>FONTSERVER</i> environment variable. If this variable is not set, it typically defaults to <i>unix/:7100</i> for a local connection to the X font server's standard Unix domain socket, or a specified hostname and port for remote servers. The standard network port for an X font server is 7100.


title: FONT NAMING CONVENTION
content:
Fonts listed by <i>fslsfonts</i> are typically identified using the XLFD (X Logical Font Description) naming convention. This is a very detailed, 14-field specification that describes various properties of a font, including foundry, family, weight, slant, pixel size, point size, and character set. Understanding XLFD is key to effectively using the <b>-fn</b> option with patterns.


title: HISTORY
content:
<i>fslsfonts</i> is a part of the X.Org (and previously XFree86) distribution. It emerged in an era where centralized font servers (<i>fs</i>) were a common and efficient way to provide fonts to multiple X clients across a network, particularly in environments with limited local storage or shared resources. Its usage has diminished as modern X applications and desktop environments have largely transitioned to client-side font rendering, relying on libraries such as Fontconfig and FreeType to manage and render fonts directly from local font files, making centralized font servers less critical.


title: PARAMETERS
content:
<b>-b</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display block group information. Shows details for each block group, including free blocks, free inodes, and directory count.<br><br><b>-d</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display directory entry information. Provides details about the content of directory blocks.<br><br><b>-f</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display superblock information. Shows global filesystem statistics like block and inode counts, free space, and various timestamps. This is the default output if no other options are specified.<br><br><b>-i</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display inode table information. Provides details about inode usage and allocation.<br><br><b>-s</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display summary statistics. Presents a high-level overview of the filesystem's state, including total blocks, free blocks, total inodes, and free inodes.<br><br><b>-v</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be verbose. Increases the verbosity of the output, providing more detailed information.<br><br><b>-q</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Be quiet. Suppresses some output or warnings.<br><br><b>-r</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display raw output. Shows some information in raw (hexadecimal) format, useful for debugging.<br><br><b>-h</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Display help message and exit.<br><br><b>filesystem</b><br>&nbsp;&nbsp;&nbsp;&nbsp;The device file (e.g., <i>/dev/sda1</i>) or mount point (e.g., <i>/mnt/data</i>) of the filesystem to analyze.<br><br>


title: DESCRIPTION
content:
<i>fsstat</i> is a command-line utility used to report various statistics about an <i>ext2</i>, <i>ext3</i>, or <i>ext4</i> filesystem. Unlike the <i>stat</i> command which provides information about individual files or directories, <i>fsstat</i> focuses on the overall filesystem structure and health. It can display details such as block and inode usage, last access, modification, and change times for the superblock, and information about individual block groups.<br><br>This tool is particularly useful for system administrators and developers to diagnose filesystem issues, monitor usage patterns, and verify the integrity of filesystem metadata. It provides a deeper insight into how space is allocated and how inodes are utilized, aiding in troubleshooting and performance tuning of <i>ext</i>-family filesystems. It's part of the <i>e2fsprogs</i> suite, a collection of utilities for maintaining <i>ext</i> filesystems.


title: CAVEATS
content:
<i>fsstat</i> is primarily designed for <i>ext2</i>, <i>ext3</i>, and <i>ext4</i> filesystems. Its functionality and output may be limited or incompatible with other filesystem types like <i>XFS</i>, <i>Btrfs</i>, or <i>ZFS</i>.<br><br>To access raw device files (e.g., <i>/dev/sda1</i>), <i>fsstat</i> often requires root privileges.<br><br>Interpreting the detailed output, especially with options like <b>-b</b> or <b>-d</b>, requires a good understanding of <i>ext</i> filesystem internals.


title: COMMON USE CASES
content:
<i>fsstat</i> is invaluable for monitoring filesystem health, diagnosing issues like inode exhaustion, or understanding disk space allocation at a granular level. For instance, <b>fsstat -s /dev/sda1</b> quickly shows overall usage, while <b>fsstat -b /dev/sda1</b> helps pinpoint specific block groups that might be full or fragmented.


title: OUTPUT DETAILS
content:
The output can be quite rich, providing timestamps for last mount, last write, and last check for the filesystem superblock. It also details the number of free blocks, free inodes, and information about the various block groups, including their block and inode bitmaps and inode table locations.


title: HISTORY
content:
<i>fsstat</i> is an integral part of the <i>e2fsprogs</i> package, a comprehensive suite of utilities for maintaining <i>ext2</i>, <i>ext3</i>, and <i>ext4</i> filesystems on Linux. The <i>e2fsprogs</i> project, primarily maintained by Theodore Ts'o, has been a cornerstone of Linux filesystem management since the early days of <i>ext2</i>. <i>fsstat</i> has evolved alongside these filesystem versions, providing consistent and detailed diagnostic capabilities. Its presence reflects the deep understanding and robust tooling provided for the default Linux filesystems.


title: PARAMETERS
content:
<b><b>FSTAB_FILE</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies an alternative <i>fstab</i> file to decode. If omitted, <i>/etc/fstab</i> is used by default.<br><br><b><b>-v</b>, <b>--verbose</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Enables verbose output, showing the original <i>fstab</i> line alongside its decoded device path.<br><br><b><b>-l</b>, <b>--long</b></b><br>&nbsp;&nbsp;&nbsp;&nbsp;Provides more detailed information about each entry, including filesystem type, mount options, and dump/pass values.<br><br><b><b>--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>


title: DESCRIPTION
content:
The command <b>fstab-decode</b>, while not a universally standard standalone utility across all Linux distributions, represents a crucial functionality: the translation of entries in the <i>/etc/fstab</i> file into their actual device paths. Modern Linux systems often use symbolic identifiers like <b>LABEL=</b> and <b>UUID=</b> within <i>fstab</i> for more robust and flexible filesystem mounting, as these identifiers are persistent even if device enumeration changes (e.g., <i>/dev/sda1</i> becoming <i>/dev/sdb1</i>).<br><br>A hypothetical <b>fstab-decode</b> command would serve to resolve these symbolic names, providing the corresponding <i>/dev/</i> path. This is invaluable for debugging mounting issues, verifying <i>fstab</i> configurations, or understanding how a system resolves its filesystem dependencies during boot. Its core purpose is to give administrators clarity on which physical device corresponds to each <i>fstab</i> entry, aiding in troubleshooting and system maintenance.


title: CAVEATS
content:
It is important to note that <b>fstab-decode</b> is <i>not</i> a standard, pre-installed command on most Linux distributions. Its functionality is typically achieved through other standard utilities such as <b>findfs</b>, <b>blkid</b>, <b>lsblk</b>, or by system components like <b>systemd-fstab-generator</b> (which processes <i>fstab</i> internally). Some environments might have a custom script or wrapper named <b>fstab-decode</b>, but there isn't a universally recognized binary of this name provided by core packages like <i>util-linux</i> or <i>systemd</i>.


title: USAGE EXAMPLES (CONCEPTUAL)
content:
<br><b>Decode default fstab:</b><br><pre>fstab-decode</pre><br>This would process <i>/etc/fstab</i> and print the resolved device paths for each entry.<br><br><b>Decode a custom fstab file:</b><br><pre>fstab-decode -f /tmp/my_test_fstab</pre><br>Useful for testing new configurations without modifying the live <i>/etc/fstab</i>.<br><br><b>Verbose decoding:</b><br><pre>fstab-decode -v</pre><br>Displays the original <i>fstab</i> line along with its resolved device path, making it easier to correlate.


title: COMMON DECODING METHODS (ACTUAL COMMANDS)
content:
<br>Since <b>fstab-decode</b> is not standard, administrators typically use:<br><br><b>1. Using <i>findfs</i>:</b><br><pre>findfs LABEL=my_data_partition<br>findfs UUID=a1b2c3d4-e5f6-7890-abcd-1234567890ab</pre><br>This command directly finds the device path for a given label or UUID.<br><br><b>2. Using <i>blkid</i>:</b><br><pre>blkid -o export /dev/sda1<br>blkid -s LABEL -o value /dev/sda1<br>blkid -s UUID -o value /dev/sdb2</pre><br><i>blkid</i> queries block devices for their attributes like UUIDs and labels. It can also be used to list all available UUIDs/labels on the system.<br><br><b>3. Inspecting <i>/dev/disk/by-uuid/</i> or <i>/dev/disk/by-label/</i>:</b><br><pre>ls -l /dev/disk/by-uuid/<br>ls -l /dev/disk/by-label/</pre><br>These directories contain symbolic links from UUIDs/LABELS to their corresponding <i>/dev/sdXN</i> paths, making it easy to manually look up mappings.


title: HISTORY
content:
The concept behind 'fstab decoding' emerged with the widespread adoption of persistent device naming using <b>UUIDs</b> and <b>LABELS</b> in <i>/etc/fstab</i>. Prior to this, relying solely on device names like <i>/dev/sda1</i> was problematic due to their potential to change across reboots or hardware modifications. While no single command historically named <b>fstab-decode</b> became a standard, the *need* for such a capability led to the development and integration of tools like <b>findfs</b> and <b>blkid</b>, and more recently, the internal handling of <i>fstab</i> by init systems like <i>systemd</i> (via <b>systemd-fstab-generator</b>) which inherently perform this decoding process.


title: PARAMETERS
content:
<b>-s server</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X font server to connect to. The server is typically given as <i>hostname:port</i> (e.g., <i>localhost:7100</i>). If omitted, <b>fstobdf</b> checks the FONTSERVER environment variable or defaults to <i>unix:7100</i>.<br><br><b>-id font-id</b><br>&nbsp;&nbsp;&nbsp;&nbsp;Specifies the X Logical Font Description (XLFD) of the font to be extracted. If this option is not provided, <b>fstobdf</b> uses a default font (e.g., <i>-misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1</i>).<br><br>


title: DESCRIPTION
content:
<i>fstobdf</i> is a utility program from the X.Org font server (xfs) suite. Its primary function is to extract a font directly from an X Font Server and output it to standard output in the Bitmap Distribution Format (BDF). This is particularly useful for scenarios where the original BDF file for a specific font is not readily available, but the font is accessible via an X Font Server. It also serves as a diagnostic tool, allowing users to inspect the glyphs and properties of fonts served by xfs.<br><br>The command connects to a specified font server, requests a font using its X Logical Font Description (XLFD), and then generates the BDF representation. This capability facilitates the archiving, sharing, or re-creation of BDF files from fonts managed by an X Font Server.


